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

[Alok]

ok..either u have been smoking stuff..  or this is one helluva email :o)

----- Original Message ----- 
From: "Detlef Bosau" <detlef.bosau at web.de>
To: "Alok" <alokdube at hotpop.com>
Cc: <end2end-interest at postel.org>
Sent: Friday, August 19, 2005 6:57 PM
Subject: Re: [e2e] end2end-interest Digest, Vol 18, Issue 9


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.


Alok=> okie!


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.

Alok=> ahh!! and how do we "know that"??

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

Alok=> ? so?


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.

Alok=> :-) if u can find the freq, it will still beat!

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


Alok=> My ability to read is limited.

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

Not quite. Think of RED.


Alok==> how so?

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


Alok=> no doubts about that ;-)

Some administrators block ping.

The guys on my ISP´s newsgroup call those administrators bad guys.
I recall: "Good fences make good neighbours".

Alok=> good chics too...


> 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?

Alok=> depends. A collision is the inablity to send something due to a media
limitation, and *note*, the end host "orginiating" the packet experinces it
in the case of collision


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.

Alok=> define "too large"

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

Alok=> ok. where would you "drop" them is the fundamental question. on an
IS? then uve already wasted b/w and queues of an IS for no reason
(remember...everything is e2e)

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.

Alok=>$$ is a good reason ;-)

Queues should be small. IIRC, this is exactly what John Nagle, Raj Jain
and perhaps countless others told us twenty years ago.

Alok=> Yep except i lost a bit on nagle's theorem when he kinda didnt wrap
around the window.

However, in extremely asnchronous situations, think of mobile wireless
networks connected to the Internet, a reasonable amount of queuing is
unevitable.


Alok=> :-) they are good to steal other's passwds when sitting at an airport
with nothing to do :-)

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.


Alok=> yep................ but wrap around the window..right?

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.


Alok=> My inability to read does wonders... ;-)

Detlef

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