[e2e] A "Railway Model." Re: Codel and Wireless

Detlef Bosau detlef.bosau at web.de
Sat Dec 7 14:40:28 PST 2013

Am 07.12.2013 17:28, schrieb Jon Crowcroft:
> you have to read the literature  - the data center tcp variants that
> avoid incast do so by passing l2 feedback (which is part of the
> ethernet spec - you can send a control frame which indicates a new
> inter-frame gap) through the IP layer and on to TCP sources (actually,
> it doesn't HAVE to work that way- you can just  have per-flow queues
> in the soruce machine and apply the dynamic inter-frame gap/delay
> differently to different queues....

You should read the RFC about Nagle's algorithm. That's to these old
wife's tales with the interframe gap.
(BTW: I didn't write a word about interframe gaps. Guess why....)

> so there's no layer 2 congestion +control+ -

Of course there is.

It just has another name: Media access control.

And in dedicated media, there is no need for congestion control because
there is no media capacity to be shared among several senders.
>  just queue feedback that
> is from l2 and a mechanism to pace packets...

Pacing is a nice thing. Particularly if you pace with the right rate.....

Just a note: TCP is an asynchronous protocol. So, there is no real need
for any kind of pacing, particularly not on an end to end basis.
(Exactly this end to end pacing AKA self clocking is one of the central
fallacies of TCP congestion control. Perhaps the most important one.
This is just the very point where we never understood, that the Internet
is a packet switched network and not a reinvented telephone system with
a keyboard instead of a dial plate and routers which work as strowger
gears with noise insulation.)
> actually, you could do this in DCF in wifi too:)

Yes. Indeed. Wifi has a MAC scheme.

(What else is DCF than congestion control? It even uses inter frame gaps!)

(Perhaps, we should at least talk about Token Ring here, because it is
really a bit funny to talk about the allocation for media capacity on a
shared medium which can serve a maximum of ONE packet at any time. And
just as a gedankenexperiment: Imagine two nodes interconnected by an
Ethernet cabling: What's the use of VJCC then? Basically none. The best
idea is to turn it of - to avoid being bothered by this stuff.)

(Yes, I know the capture effect, so CSMA/CD isn't fair. What did Wes
Crusher say in StarTrek? "Life isn't always fair.")

In my opinion, it is basically a good idea to leave fairness to
schedulers and not to self scheduling and other sophisticated instances
of "swarm intelligence".

And yes, that makes use of technological progress: At the garden hose's
times, there was no alternative to CSMA/CD.
("There is no alternative", that was a long time ago. IIRC at the time,
when chancellor Merkel created the garden of Eden.)

Meanwhile (by the time of the stone age) switches have been invented -
and now, fairness is left to schedulers.

So, shared media could be left to courses on network history.

(Yes, this is no politcial blog here. But as many of you know, meanwhile
chancellor Merkel has admitted to be an Internet newbie. No one had the
slightest idea of this before...)

Detlef Bosau
Galileistraße 30   
70565 Stuttgart                            Tel.:   +49 711 5208031
                                           mobile: +49 172 6819937
                                           skype:     detlef.bosau
                                           ICQ:          566129673
detlef.bosau at web.de                     http://www.detlef-bosau.de

More information about the end2end-interest mailing list