[e2e] end2end-interest Digest, Vol 18, Issue 9
detlef.bosau at web.de
Fri Aug 19 06:27:31 PDT 2005
>>To my understanding, queues have two purposes.
>>1. Rate adaptation, this includes adaptation of a flow to possible MAC
> Which means you have a bandwidth gradient and you buffer to handle the
> Which again means you have to "work on windows" and "buffer for windows" as
> far as TCP is concerned
> Simply put:
> Implies R1 has to buffer , and the buffer size can be *finite* only if the
> traffic has a window/burst size is finite.
It´s interesting. Some weeks ago, I got criticism why I beat the
conservation principle drum here.
taram! taram! tataram! I beat the con-principle drum!
I can only repeat it again and again: Exactly _this_ is the purporse of
ACK pacing and the conservation principle in TCP.
A flow must not have more packets in transit than the congestion window
allows (the "equilibrium window") and a packet must not be sent to the
network until some other packet was taken away.
_This_ and nothing else limits the "energy" put into the network (the
analogy to physics is obvious: We talk about energy conservation,
impulse conservation, sometimes I think, Van Jacobson and Sir Isaac are
best friends :-)) and hence bursts, oscillation etc. are limited.
Recall the Takoma bridge disaster, make the wind to stop blowing - the
Takoma bridge may oscillate to eternity, but at least it was still there.
>>2. Interleaving/Mixing of flows.
> Let me put the question in a simpler manner,
> assume no TOS/DSCP, why does one need queues at all????
The simple answer is: We do not need them.
The more complex answer can be found e.g. in Jains "Delay" paper:
Limited queues with a length thoroughly thought through can improve
> The only time you can do a buffer is if there is an window on top capping ur
Not quite. Think of RED.
> For example, if the 10Meg guy pumps UDP at 10Meg continuously, no amount of
> buffering is going to help you on the 1Meg link.
But this guy is really misbehaved: He is not responsive.
Responsiveness is no part of UDP. Therefore, the application is
responsible for responsiveness here.
Admittedly, people forget about this quite often.
It´s not an academic example, but on the support newsgroup of my ISP
some guys recently detected ping. Ping. PING.
Oh, you miss the rest of my post? The reason is simple: "NG" is yet to come.
So, once again I take my drum, taram, taram, tataram.....
Perhaps I can join a parade?
The Internet still remains a well behaved community.
Some administrators block ping.
The guys on my ISP´s newsgroup call those administrators bad guys.
I recall: "Good fences make good neighbours".
> As far as I understand, queues are only as the inherent architecture is
Even that would not _require_ a queue. Think of Ethernet. What else is a
"congestion" than a "collision", when there is no queueing on the router?
So, if we had no queues, the Internet would run. Perhaps the throughput
could be somewhat higher, perhaps the way the Internet runs would be
more similar to a turtle than to Achilles - but who cares? Isn´t there
still snail mail delievered sent by soldiers who served with General Custer?
However, too large a queue can have the same effect.
> Say I have
> 1M----| |--------1M
> 1M----| switching element |--------1M
> 1M----| |--------1M
> all my switching element needs to be able to do is to switch at round robin
> at 6*1M ...right?
> Now where and why do I need the queues? Only reason that comes to mind is
> the async. nature (each 1M is not clocked by the same clock etc), but the
> queue size still does not need to be that high, does it?
And even no queuing (called "cut through switching" in the good old days
from the past) would work.
But then, packets arriving at the switch at the same time would result
in the same effect as collisions.
However, this debate was conducted in the eighties. So, I´m curious why
some people buried tons of queueing memory in routers during the last
ten years (perhaps the disaster in Cobe was overcome and now there was
some amount of memory chips to be sold) and recently, researchers detect
that small queues could be useful.
Queues should be small. IIRC, this is exactly what John Nagle, Raj Jain
and perhaps countless others told us twenty years ago.
However, in extremely asnchronous situations, think of mobile wireless
networks connected to the Internet, a reasonable amount of queuing is
I got a paper submission rejected this year with the enlightning comment
"overqueing is bad, refer to Reiner Ludwigs PhD dissertation".
I know Reiner Ludwigs PhD dissertation.
When he claims, overqueueing is bad, he is perfectly right as all the
researchers before. It´s really an old story.
However, when service times oscillate from milliseconds to _minutes_(!)
at the last mile (refer to the relevant ETSI/ITU standards for GPRS
before calling me nuts), traffic might happen to be a little bursty if
not equalized by queues and appropriate techniques.
Mail: detlef.bosau at web.de
Mobile: +49 172 681 9937
More information about the end2end-interest