[e2e] How shall we deal with servers with different bandwidthsand a common bottleneck to the client?

Detlef Bosau detlef.bosau at web.de
Wed Dec 27 09:47:52 PST 2006


Agarwal, Anil wrote:
>>
>> I´m not quite sure about the relationship to RED here. (In 
>> fact, I still have no personal opinion to RED, however I have 
>> numerous questions to RED, but I think that´s not the question here.)
>>     
>
> RED will probabilistically discard packets before the queue gets full, resulting in packet discards for both connections. RED will be biased against the larger connection. Eventually, both TCP connections will reach the same (statistical) rate and experience the same packet drop rate.
>   

However, the latter is no consequence of RED but the basic goal of AIMD.

>   
>> Again we have two cases.
>>
>> 1.: The path tail runs TCP or some other window controlled protocol 
>> which maintains available ressource. Hopefully, the flow from 
>> sender(1) 
>> will achieve something about 2 Mbps and the flow from 
>> sender(0) will get 
>> the rest. I don´t know. I´m actually trying to find out.
>>
>> 2.: The path tail runs some rate controlled protocol as it would make 
>> sense e.g. in satellite connections where the startup 
>> behaviour of TCP 
>> is extremely annoying. Now: How will this protocol distrute 
>> the availabe 
>> ressources among the flows? One could give equal shares to 
>> them, i.e. 5 
>> Mbps to each.
>> However, because the flow from sender(1) cannot send faster 
>> than 2 Mbps, 
>> 3 Mbps would remain unused.
>>
>> Particularly the latter scenario seems to be some kind of 
>> "end to end" 
>> problem: The splitter node does not know the end to end ressource 
>> situation and thus have to leave the distribution of 
>> ressources to the 
>> end nodes.
>>
>> Do I go wrong here?
>>     
>
> A "good" TCP-splitter should produce correct (desired) results in this scenario and many others. It should produce correct results with 2 or 200 connections, with 2 or 200 different network segments and bottlenecks, some before and some after the TCP-splitter; it should produce correct results when the amount of bandwidth available over the various network segments (especially over the satellite network segment) is variable and not known a priori; it should produce correct results when there is cross traffic on the bottleneck links in the network segments, which does not traverse the TCP-splitter.
>   

It should. However I find it not easy to understand how this is achieved 
in each individual case. I even do not know that much literature on this 
issue. I know the works of Rajiv Chakravorthy and Rami Mukhtar, but I´m 
not aware of more works in this area.
If you know some additional work, I would appreciate any hint.

> A TCP-splitter that "splits" bandwidth "equally" among various connections will not make the cut.
>
> Hint: TCP by itself does a commendable, although not perfect, job of meeting the above scenarios.
>
>   
Yes, of course. However, introducing a splitter into a path has 
consequences for the end-to-end semantics of ACK ackets and thus for TCP 
selfclocking, the RTT, the path capacity as seen by the sender.  So, if 
TCP does a good job in the absence of a splitter it is not clear by 
itself, that id did a good job in the presence of a splitter ;-)

> I don't know how well other commercial TCP-splitters perform in these scenarios, but I can speak for one - we use our (my) own TCP PEP product over our VSAT networks; it works fairly well over many such scenarios (not quite 200 network segments :)). I tried out a few more scenarios, including yours, since your last email.
>
>   

Do you have any literature on this one?

It´s sometimes a pity that commercial products are often poorly 
documented. This might be understood from a commercial point of view 
where it is always a concern to get an advantage about possible 
competitors. But it´s quite insatisfactory for a scientific discussion.

In addition: I´m  generally quite reluctant towards simulation. I think 
it´s always better to understand why a middlebox/splitter does or does 
not behave in a certain way. I often read papers where it is not quite 
clear why certain scenarios are chosen for simulations and other ones 
are left out. However, simulation can help to understand a certain 
behaviour. So, what I´m mostly interested in is the rationale behind the 
statement that a certain scenario will work.

Detlef




More information about the end2end-interest mailing list