[e2e] Are we doing sliding window in the Internet?

Detlef Bosau detlef.bosau at web.de
Mon Jan 8 14:04:30 PST 2007


sisalem at fokus.fraunhofer.de wrote:
>> You will learn from that, that fairness enforcement _does_ exist.
>>     
> just a short remark: I would assume that the definition of fairness
> here is that two TCP connections with the same RTT and packet size
> would receive the same bandwidth share.
> Hence, fairness enforcement is only partially done. 
I agree with you here. However, one could understand Vadim that way, 
that we do no fairness consideration at all. And that´s simply wrong.


> Two
> TCP sessions with different congestion avoidance schemes (e.g., one
> with SACK and another one with Reno) will not achieve the same
> bandwidth share under the same RTT conditions (whether this is to be
> considered unfair though is another issue which has more to do with
> philosophy). And a UDP flow is not interested in fairness at all as
> well.
>
>   

 From my point of view, you mix up at least three issues here.

1. It´s a basic decision to make whether the Internet is built 
hierarchical or heterarchical. A heterarchical design is of course much 
more robust than a hierarchical one. A hierarchical desin is only robust 
against the failure of up to n (n to be defined) nodes. A heterarchical 
design will still work, when there is even _one_ path left between two 
nodes which want to communicate. I don´t know the discussions of the 
early 70s, because I as a schoolboy then, but I can imagine that 
robustness was a major issue then.

If the Internet were designed hierarchical, you could provide admission 
control and QoS assignments etc. and then you have fairness matching
any criteria you desire.

In a heterarchical design, it´s much more difficult, if possible, to 
enforce arbitrary fairness schemes.


2. That TCP/Tahoe will run unfair against TCP/Reno is no structural 
problem. It goes without argument that TCP flavours are basically fair 
if all parties use the same one. In my opinion, this is one decisive 
argument not to play around with an arbitrary number of TCP flavours and 
see what happens but to carefully consider which flavour is deployed and 
which consequences this will have.

3. It´s always a concern if protocols are responsive or not or if they 
are even TCP friendly. In this context please allow the question: What 
is a "UDP flow"? If you use UDP, the task of fairness / congestion 
control / TCP friendlyness / responsiveness is passed to the application.
> regarding the input about enforcing fairness in the network. I think
> that the painful experience ATM and ABR taught us already, that
> network based fairness enforcement schemes are theoretically great but
> practically too complex to be of practical use
>
>   
That´s perhaps even one reason more to use a heterarchical scheme.

And as I stated quite some time ago: When I consider all the arguments, 
why the Internet is supposed not to work, I´m always suprised that it 
works quite fine :-)

Detlef




More information about the end2end-interest mailing list