[e2e] end2end-interest Digest, Vol 18, Issue 9
alokdube at hotpop.com
Thu Aug 18 23:59:03 PDT 2005
----- Original Message -----
From: "Detlef Bosau" <detlef.bosau at web.de>
To: <end2end-interest at postel.org>
Sent: Friday, August 19, 2005 2:45 AM
Subject: Re: [e2e] end2end-interest Digest, Vol 18, Issue 9
> Alok wrote:
> >>>>Personally, I am in great doubt at this.
> >>RTT delay is influenced by the following factors:
> >>1. Speed of light delay in the path
> >>2. Retransmissions in the underlay
> >>3. Queues in buffers due to
> >> a. self queueing (queueing behind your own packets)
> >> b. queueing due to cross traffic
> > Do routers/ATM switches use queues for "congestion control" or because
> > of their cards and backplanes are asynchronous?
> 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
Implies R1 has to buffer , and the buffer size can be *finite* only if the
traffic has a window/burst size is finite.
> 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 only time you can do a buffer is if there is an window on top capping ur
For example, if the 10Meg guy pumps UDP at 10Meg continuously, no amount of
buffering is going to help you on the 1Meg link.
As far as I understand, queues are only as the inherent architecture is
Say I have
1M----| switching element |--------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?
More information about the end2end-interest