[e2e] TCP to exhibit MTU unfairness?

[Detlef Bosau]

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 
think?

Detlef

>   


-- 
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