[e2e] TCP to exhibit MTU unfairness?
detlef.bosau at web.de
Mon Nov 12 14:58:17 PST 2007
Lachlan Andrew wrote:
> Greetings Detlev
> On 12/11/2007, Detlef Bosau <detlef.bosau at web.de> wrote:
>> Lachlan Andrew wrote:
>>> Greetings Detlef and Daniel
>>> I think Daniel was pointing out that current TCP sets the window in
>>> terms of number of MTUs,
>> Excuse me, if I have something wrong in mind, but isn´t the window given
>> in bytes?
>> Or does this depend on the TCP flavour?
> The "additive increase" in Tahoe/Reno/NewReno is specified as
> increasing the window by one MTU.
Yes, I see. I think, it´s intentionally 1 MSS per RTT. So, a flow with
large MTU increases faster than one with a small MTU, correct?
O.k., than I see the problem. However, I don´t see an easy solution.
> It is certainly network capacity. The question is whether it is
> mainly limited by link capacity or router capacity. Each occurs in
> some parts of the network. Like you, I believe that the link capacity
> is more often a problem, but I don't have numbers to back that up.
To my knowledge, it´s common sense the router queues should not grow too
large, i.e. one must not worsen the problem by introducing to much
router capacity here. I always forget the correct rule of thumb, but
isn´t it something like: The router capacity should back up one end to
end line capaccity = one latentency throughput product end to end?
However, perhaps Daniel´s problem is not really that bad, because TCP
congestion control only achieves fairness when competing flows share a
common path. And hopefully (with fingers crossed....) in that case,
competing flows should negotiate similar MTU / MSS sizes, or what do you
Detlef Bosau Mail: detlef.bosau at web.de
Galileistrasse 30 Web: http://www.detlef-bosau.de
70565 Stuttgart Skype: detlef.bosau
Mobile: +49 172 681 9937
More information about the end2end-interest