[e2e] end2end-interest Digest, Vol 18, Issue 9

[Detlef Bosau]

Alok wrote:


>>To my understanding, queues have two purposes.
>>
>>1. Rate adaptation, this includes adaptation of a flow to possible MAC
>>delays.
> 
> 
> Which means you have a bandwidth gradient and you buffer to handle the
> gradient.

Yes.

> Which again means you have to "work on windows" and "buffer for windows" as
> far as TCP is concerned
> 
> Simply put:
> ------->10Mbps---->R1----->1Mbps--->
> 
> Implies R1 has to buffer , and the buffer size can be *finite* only if the
> traffic has a window/burst size is finite.
> 
> 

Yes.

It´s interesting. Some weeks ago, I got criticism why I beat the 
conservation principle drum here.

<ignore criticism>

taram! taram! tataram! I beat the con-principle drum!

</ignore criticism>

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

> The only time you can do a buffer is if there is an window on top capping ur
> burst
> 

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

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
> async,


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?

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?

Exactly.

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

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.

Detlef

-- 
Detlef Bosau
Galileistrasse 30
70565 Stuttgart
Mail: detlef.bosau at web.de
Web: http://www.detlef-bosau.de
Mobile: +49 172 681 9937