Re: (재전송) RE: End to End QoS across the Internet

[Sean Doran <smd at ebone.net>]

jinoo7 at samsung.co.kr writes:

> EPD and PPD, and all the congestion management schemes are aiming
> to resolve such problems. By the way, doesn't 'congestion' occur
> when incoming traffic overloads the switch's capacity?  

Congestion happens when there is a mismatch between 
input rate and output rate; the means of dealing with
congestion is a control theory problem.   In most cases
now, congestion is dealt with by a FIFO queue which
absorbs a small mismatch over a long period or a large
mismatch over a very short period; when the FIFO queue is
exceeded, drops occur.

If one imagines a switch to be a sort of abstract (or
real) LAN surrounded by specialized (abstract or real)
computers that shuffle traffic from various interfaces to
the high speed LAN, if the LAN is persistently busy,
congestion would result.  So yes, you could call
insufficient switching capacity 'congestion', just as you
would call insufficient LAN capacity 'congestion'.
However, in many cases this form of congestion is dealt
with by a queue of length zero, which is not a
particularly wonderful means of matching input rate to
output rate.

In any case, queue overflows will always match the input
rate to the output rate, although it might do it in a very
poor way.

The theory behind RED is that by dropping packets early
-- that is, when there is still space in a queue -- one
can take advantage of source dynamics to adjust an
input-to-output rate mismatch more quickly than FIFO
queuing, and with a minimal amount of lost data.

EPD causes ATM switches to behave like routers -- the
unit of traffic dealt with is a "frame" or packet, and
the entire packet is enqueued or dropped.   However,
EPD is typically a simple FIFO queueing discipline
with respect to packets, and as with routers, this
could be improved with a better control law.

> The point of PPD is to reduce the complexity of implementing
> EPD, and yes, it still works fine. 

Not fine.   However, it is better than nothing.

> EPD trys to aviod such a situation by dropping 'packets' from  
> the beginning when the buffer is expected to become full therefore
> there will be cells dropped otherwise.

EPD currently monitors the instantaneous queue length.
EPD should also monitor the long-term average queue
length, and at any particular average queue length drop
the entire next packet with a pre-determined probability.

A graph of this control-law, where the X axis is average
queue length and the Y axis is drop probability, should
show a roughly parabolic curve with zero at three or four
packets (or some comparable number of cells) and 0.1 at
the point where there would be 100ms of queueing delay.

Some of this will be described by Van Jacobson in a
forthcoming paper on RED, and has been described 
in his recent presentation at the NANOG conference, which
can be found here:

http://www.nanog.org/mtg-9806/agen0698.html   

(scan forward for Van Jacobson's name, and watch the Real
Video broadcast and read the slides)

> PPD doesn't drop the whole packet. Instead, it drops the 'remainder'
> -- not the middle nor the front---
> of packets which have already 'currupted' by losing cells.  
> 
> What do we do about the front of corrupted packet?
> Nothing.  
> 
> And that's it.

Exactly, and that's the problem -- when there is a serious
mismatch between input and output rate, the number of
partial packets occupying output bandwidth will increase.

These partial packets will be dropped later, but still
prevent intact packets from entering the FIFO queue, thus
worsening congestion.

PPD mitigates this behaviour to some degree -- statistically --
but at best will still cause one cell per frame to be transmitted.

The failure mode of PPD is when the mismatch is so great
that *no* intact packet is being transmitted, yet the
output line is completely filled.

EPD does not have this failure mode under any rate mismatch.

	Sean.