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

[Agarwal, Anil]

Detlef,

You wrote  

> > One can construct many other similar scenarios, where one 
> connection 
> > is selectively favored over another. Perhaps, one more 
> reason to use RED.
> >  
> 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.

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

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.

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.

Regards,
Anil