[e2e] Are we doing sliding window in the Internet?
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.
> 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
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 :-)
More information about the end2end-interest