[e2e] How shall we deal with servers with different bandwidthsand a common bottleneck to the client?
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
>> 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.
More information about the end2end-interest