R: R: [e2e] [Fwd: RED-->ECN]

Saverio Mascolo mascolo at poliba.it
Thu Feb 1 09:06:57 PST 2001


Could someone point me to  some paper comparing ECN to RED? Thanks
Saverio

----- Original Message -----
From: Jon Crowcroft <J.Crowcroft at cs.ucl.ac.uk>
To: end2end-interest <end2end-interest at postel.org>; ecn-interest
<ecn-interest at research.att.com>; <J.Crowcroft at cs.ucl.ac.uk>
Sent: Thursday, February 01, 2001 5:39 PM
Subject: Re: R: [e2e] [Fwd: RED-->ECN]


>
> In message <008c01c08c6b$4655eec0$723bccc1 at poliba.it>, Saverio Mascolo
typed:
>
>  >>I would introduce another element of discussion...Explicit congestion
>  >>indication was proposed in the ATM community...after a while they
concluded
>  >>that it was necessary a richer feedback in order to obtain an effective
>  >>"regularization" of queue dynamics, utilization etc...thus it was
proposed
>  >>explicit rate indication such ERICA algorithm.
>
> the difference between explicit rate feedback and binary feedback can
> be overstated -
> 1/the bit can be set for a number of flows - if the number of flows is
> large, and they respond corectly then the effect can be nearly the same
> as setting the "right" explicit rate per flow
>
> 2/ the rate of change of flows per "rtt" might be such that telling
> someone the "right" explicit rate half an rtt ago maybe no better and
> might be worse than binary feedback per flow.
>
> in some of the discussion below, the distinction between the reason
> for drop tail (demand >= supply) and RED+ECN (demand is _approaching_
supply
> and AQM triggers set) is correctly made - the AQM mechanism can take
> into account a lot of other factors (number of current flows, rate of
> change of number of flows, even relative RTT of flows (hard to measure
> though, esp. in today's assymetric routed interdomain path internet:-))
>
> by the way, the idea of a "quantum mechanics" of queues had occurred
> to me - not to "perform magic" like quantum tunneling, but the use of
> quantum statistics to model the population of queues for very large
> systems might not be so far fetched..(yes, i know there are a few
> orders of magnitude of orders of magnitude difference in scale, but
> its still fun to think of)
>
>  >>>    Thu, 1 Feb 2001 13:21:27 +0200
>  >>>    julian_satran at il.ibm.com
>  >>>
>  >>>    I would be very interested to understand how you see the
>  >>"virtual-measure",
>  >>>    you are suggesting exists,  relate to accepted  theory.  It is
usually
>  >>>    though that high utilization rates and long queues are related
(i.e.,
>  >>you
>  >>>    have long queues when utilization goes up)
>  >>>
>  >>> A quibble: Queue length is a function of variance (burstiness), not
(just)
>  >>> of arrival rate.  If the input rate exceeds the output rate, queue
length
>  >>> *becomes* unbounded ("infinite").  If the input rate is less than the
>  >>> output rate, then (independent of variations in inter-arrival time)
the
>  >>> queue length is 0 -- always empty.  For an arbitrarily low *average*
input
>  >>> rate, and a long enough interval, and an unbounded queue, I can
construct
>  >>> an arrival schedule that will cause an arbitrarily high *average*
queue
>  >>> length.
>  >>>
>  >>> However, what you say is _basically_ true in the real world because
as the
>  >>> input rate approaches the output rate the queue length becomes much
more
>  >>> sensitive to smaller and smaller variations (not to mention that max
queue
>  >>> length *is* bounded), so queue length in practice is probably usually
a
>  >>> reasonable indicator of load.  The control needed to smooth flows as
>  >>> arrival rates get higher is likely to be fragile, and is probably
>  >>> inconsistent with the philosophy of most people on end2end.  But
Steven
>  >>> Low's statements are not immediately dismissable as being totally
>  >>> self-contradictory, or in the category of perpetual motion machines.
>  >>> Not to say that there aren't plenty of other arguments to be made,
but
>  >>> dismissing it out of hands on the grounds of ludicrousness isn't one
of
>  >>> them.
>  >>>
>  >>> and this is the reason queue
>  >>>    length is used as a measure of congestion.  And this is true for
all
>  >>>    accepted queueing models.  Do you have in mind some "quantum
>  >>statistics"
>  >>>    for networks that we are all unaware of? Do those have some tunnel
>  >>effects
>  >>>    that allow you to dream about high utilization AND short queues?
Is
>  >>there
>  >>>    some mathematics that can support your statements?
>  >>>
>  >>>    Julo
>  >>>
>  >>>    Julian Satran
>  >>>    IBM Research Lab. at Haifa
>  >>>
>  >>>
>  >>>
>  >>>    Steven Low <slow at caltech.edu> on 01/02/2001 10:23:33
>  >>>
>  >>>    Please respond to slow at caltech.edu
>  >>>
>  >>>    To:   Alhussein Abouzeid <hussein at ee.washington.edu>
>  >>>    cc:   end2end-interest at postel.org, ecn-interest at research.att.com
>  >>>    Subject:  Re: [e2e] [Fwd: RED-->ECN]
>  >>>
>  >>>
>  >>>
>  >>>
>  >>>    Hi Alhussein
>  >>>
>  >>>    I should clarify what I meant by 'decoupling of congestion measure
>  >>>    from performance measure'.
>  >>>
>  >>>    I want to distinguish between the
>  >>>    *measure* of congestion and the *feedback* of congestion.  The
>  >>>    measure of congestion, vaguely, should track the number of users
>  >>>    or available capacity and this is the information to which users
>  >>>    react by adjusting their rates (windows).   For example, DropTail
>  >>>    measures congestion by loss rate (i.e. congestion = high loss),
>  >>>    the original RED measures it by average queue
>  >>>    (ie. congestion = high queue).   Alternatively, you can measure
>  >>>    it by a number you compute, e.g., based on queue length and rate,
>  >>>    as you suggested.  Then, congestion can simply mean
'demand>supply',
>  >>>    but it is possible to update the congestion measure in a way that
>  >>>    drives the queue or loss to a very low value, and therefore, the
>  >>>    congestion measure can settle down to a high value, telling
sources
>  >>>    to keep their rates low, while loss and delay are kept low.
>  >>>    This is the key benefit, which cannot be achieved without
decoupling,
>  >>>    for otherwise congestion measure (in this case, loss or queue)
must
>  >>>    be kept high to send the right signal to users (unless one adapts
RED
>  >>>    parameters dynamically).  This is the first type of decoupling.
>  >>>
>  >>>    Note that even with the first type fo decoupling,
>  >>>    performance measures such as loss, queue, delay or rate,
>  >>>    are used to *update* the congestion measure, but the equilibrium
>  >>>    *value* of the congestion measure is determined "solely" (in an
>  >>>    idealized
>  >>>    world) by the network topology, number of users etc, not by the
>  >>>    flow control algorithm.
>  >>>
>  >>>    Now, how is the congestion measure fed back?   This can be done
>  >>>    implicitly through what can be observed at the source, e.g. loss
>  >>>    or delay.   Or it can be done explicitly using ECN or management
>  >>>    packets.   This is decoupling the *feedback* of congestion measure
>  >>>    from performance measure.
>  >>>
>  >>>    By "decoupling", I always meant the first kind of decoupling,
which
>  >>>    I think is more important in determining the equilibrium behavior
>  >>>    of congestion control.
>  >>>
>  >>>    I agree with you completely that ECN helps in the second type of
>  >>>    decoupling,
>  >>>    but not the first type which has to do with the design of AQM
(choice
>  >>>    of congestion measure and its update rule).   In wireless
environment,
>  >>>    however,
>  >>>    because of the two kinds of losses (congestion & random loss), the
>  >>>    second
>  >>>    type of decoupling becomes useful as well.
>  >>>
>  >>>    Regarding your mice-elephant comment, mice invasion may indeed be
a
>  >>>    problem.   But that makes it all the more important that elephants
are
>  >>>    controlled to leave queues empty (in the absence of mice), and
this
>  >>>    seems
>  >>>    hard to do if congestion measure is coupled with performance
measure -
>  >>>    empty queue then automatically invites elephants to raise their
rates.
>  >>>    If empty queue does not mean "increase you rate", then elephants
must
>  >>>    be fed back (through ECN or probabilistical dropping) other
necessary
>  >>>    information to set their rates.
>  >>>
>  >>>    Steven
>  >>>
>  >>>
>  >>>    Alhussein Abouzeid wrote:
>  >>>    >
>  >>>    > Hi Steven,
>  >>>    >
>  >>>    > I generally agree with your approach below but have three, also
>  >>>    > philosophical, comments that I'd like to share with you
regarding the
>  >>>    > decoupling of congestion measures from performance measures.
>  >>>    >
>  >>>    > Clearly, decoupling these two measures may greatly help in the
design
>  >>of
>  >>>    > congestion control algorithms, since the congestion information
>  >>becomes
>  >>>    > explicitly available (through say, ECN). However, even with
>  >>>    > the use of ECN, full decoupling is not possible. The reason is
that
>  >>ECN
>  >>>    > packets themselves might be lost if sudden congestion takes
place.
>  >>>    >
>  >>>    > Another point is regarding your argument that controlling
"elephants"
>  >>>    will
>  >>>    > result in low queue levels and hence "mice" will be able to run
>  >>quickly
>  >>>    > through the network. While this argument seems quite sensible,
at
>  >>least
>  >>>    to
>  >>>    > me, it is problematic if you imagine the arrival of many such
mice -
>  >>say
>  >>>    a
>  >>>    > mice invasion. Will the ECN marking rate/scheme used for
signaling
>  >>the
>  >>>    > elephants be enough to pro-actively avoid congestion from this
mice
>  >>>    > invasion? I think that, at least, this is an important part of
the
>  >>puzzle
>  >>>    > that should not be taken lightly. In other words, the so called
>  >>>    > *transient* effect due to the mice population has to be
accommodated
>  >>and
>  >>>    > handled as carefully as the elephants' *steady state* effect.
>  >>>    >
>  >>>    > Finally, I'd like to add one more point; that the same level of
>  >>>    > decoupling that you propose can still be achieved using AQM
without
>  >>ECN.
>  >>>    > In one context, RED can be viewed as a controller that estimates
the
>  >>>    state
>  >>>    > and acts upon the estimate. The average queue size is taken as a
>  >>measure
>  >>>    > of the state and the feedback signal is a function of the state
>  >>>    > estimate. However, the average queue size need not be the only
>  >>measure of
>  >>>    > congestion. Indeed, some recent works suggested measuring the
arrival
>  >>>    rate
>  >>>    > directly (using some filter to smooth out transients) and using
this
>  >>as
>  >>>    > the measure of congestion. In some sense, such schemes attempts
to
>  >>>    achieve
>  >>>    > the rightful objective you mentioned; decide whether demand
exceeds
>  >>>    > capacity. Both approaches (queue-based or rate-based) have some
>  >>problems
>  >>>    > that are too involved to detail here. If the AQM router uses a
>  >>>    > rate-based measure of congestion and drops packets when
>  >>>    > demand exceeds capacity (according to some reasonable
algorithm),
>  >>then
>  >>>    > we effectively achieve the same level of decoupling, and also in
this
>  >>>    > case, the (average) buffer level can be kept low.
>  >>>    >
>  >>>    > In summary, in my opinion, ECN is a much more decent way of
informing
>  >>the
>  >>>    > sources about congestion, instead of the "cruel" way of packet
>  >>>    > dropping. As mentioned by others, it also saves the efforts of
all
>  >>the
>  >>>    > routers (if any) that processed the packet before it was finally
>  >>dropped
>  >>>    > somewhere along the path, and also the effort of the source in
>  >>detecting
>  >>>    > the packet loss. It has other virtues along the same lines that
I am
>  >>not
>  >>>    > listing here. It can be used to distinguish between
>  >>congestion-related
>  >>>    > and non congestion-related losses only to some degree of
reliability.
>  >>>    > Other than that (which are by no means minor enhancements), I
don't
>  >>think
>  >>>    > ECN is *essential* for the decoupling between congestion control
and
>  >>>    > performance measures (e.g. queuing delay).
>  >>>    >
>  >>>    > Just a few thoughts. Sincerely,
>  >>>    >
>  >>>    > -Alhussein.
>  >>>    >
>  >>>    > On Fri, 26 Jan 2001, Steven Low wrote:
>  >>>    >
>  >>>    > >
>  >>>    > > > From: Steven Low <slow at ee.mu.OZ.AU>
>  >>>    > > > To: hari at lcs.mit.edu, slow at caltech.edu
>  >>>    > > > CC: cwcam at caltech.edu, ecn-interest at research.att.com,
>  >>>    end2end at isi.edu.rliu@yak.ugcs.caltech.edu, siew at its.caltech.edu,
>  >>>    wch at its.caltech.edu
>  >>>    > > >
>  >>>    > > >
>  >>>    > > > Hi Hari,
>  >>>    > > >
>  >>>    > > > I completely agree that there are unresolved issues with the
>  >>>    > > > third approach (drastically reduce buffer overslows so that
>  >>>    > > > losses become primarily due to wireless effects), and you
>  >>>    > > > nicely touch upon several of them.   But I'd like to make
two
>  >>>    > > > philosophical points about ECN & congestion control first
>  >>>    > > > (which I hope belongs to this list at least peripherally).
>  >>>    > > >
>  >>>    > > > I think the approach of
>  >>>    > > > congesting the network in order to obtain congestion
information
>  >>>    > > > as the current TCP does, which is necessary without ECN,
>  >>>    > > > becomes unnecessary with ECN.  With AQM, we can decouple
>  >>>    > > > congestion measure & feedback from performance measure such
>  >>>    > > > as loss, delay or queue length.   Then, 'congestion'
>  >>>    > > > means 'demand exceeds supply' and congestion signal curbs
demands
>  >>>    > > > but the queue can be controlled in a way that maintains good
>  >>>    > > > performance such as low loss & delay.   Whether REM can
succeed
>  >>>    > > > doing this is a separate matter, but I think this is the
approach
>  >>>    > > > we ought to take in designing our congestion control.
>  >>>    Alternatively,
>  >>>    > > > when we couple congestion measure with performance measure,
>  >>>    > > > 'congestion' necessarily means 'bad performance' such as
high
>  >>>    > > > loss or delay, and we do not have the *option* (even if we
have
>  >>>    > > > the means) of maintaing low loss & delay in times
>  >>>    > > > of congestion (i.e. when new sources joining or capacity
drops).
>  >>>    > > > In other words, when there are more sources, loss or delay
must
>  >>be
>  >>>    > > > increased in order to produce high enough signal intensity
for
>  >>>    > > > sources to futher cut back their rates; moreover signal
intensity
>  >>>    > > > must stay high not only during transient
>  >>>    > > > when new soruces first start but also afterwards.
>  >>>    > > >
>  >>>    > > > REM tries to fix this, not through the exponential form of
its
>  >>>    > > > marking probabiltiy function, but by using a different
congestion
>  >>>    > > > measure and update rule, that maintains high utilization and
low
>  >>>    > > > queue in equilibrium.   Again, there can be alternative ways
to
>  >>>    > > > achieving this, but I think this is what we should aim for.
>  >>>    > > > And to achieve this it is critical that we decouple
congestion
>  >>>    > > > measure from performance measure.
>  >>>    > > >
>  >>>    > > > The second philosophical point is an interesting implication
>  >>>    > > > of the recent extensive works on heavy-tailed traffics and
their
>  >>>    > > > origin.  It implies that the misc-elephant mix (i.e.
>  >>>    > > > most files are small but most packets belong to long files)
>  >>>    > > > that characterizes current traffics may be a permanent and
>  >>>    > > > essential feature, not an artifice of current applications
or
>  >>>    > > > user behavior.   The end-to-end congestion control, properly
>  >>>    > > > designed, can be an ideal mechanism in such an environment,
>  >>>    > > > where elephants (that care about bandwidth)
>  >>>    > > > are controlled to maximally utilize the network
>  >>>    > > > in such a way that leaves the queues close to empty, so that
>  >>>    > > > mice (that are delay sensitive) can fly through the network
>  >>>    > > > with little delay.   Again, this require a new TCP/AQM
strategy
>  >>>    > > > that achieves high utilization + low queue, and ECN (or
>  >>>    > > > explicit notification) helps.
>  >>>    > > >
>  >>>    > > > A common objection to end-to-end congestion control is that
>  >>>    > > > most TCP connections are short and hence end-to-end
congestion
>  >>>    > > > control is ineffective.  I believe the observation is
correct
>  >>>    > > > but not the conclusion.  Since HTTP uses TCP and web files
>  >>>    > > > have mice-elephant mix, most TCP connections are therefore
mice,
>  >>>    > > > which indeed should not be the primary object for end to end
>  >>>    > > > control.  End to end control should target elephants, not
mice.
>  >>>    > > > Mice suffer large delay currently, not because they are end
to
>  >>>    > > > end controlled, but because the current congestion control
(even
>  >>>    > > > just of elephants) can produce large queues in the path of
mice.
>  >>>    > > >
>  >>>    > > > So, with the a TCP/AQM strategy that maintains high
utilization
>  >>>    > > > and low queue in equilibrium (regardless of hte number of
>  >>sources),
>  >>>    > > > buffer is used *only* to absorb *transient* bursts.  This
can be
>  >>>    > > > very different with a scheme that uses, say, queue length to
>  >>>    > > > measure congestion; with such a scheme, we do not have
control
> >    > > > on the equilibrium value of the queue - it is determined solely
>  >>by
>  >>>    > > > the network topology and #sources and hence can be high
depending
>  >>>    > > > on scenario.   When queues are always high, they do not have
>  >>>    > > > reserve to handle burst.   But when queues are always low, I
>  >>>    > > > think bursts can be much better handled.
>  >>>    > > >
>  >>>    > > > So much for such vague philosophical discussions.  Since
this
>  >>>    > > > is getting too long, I'd defer discussion on the unresolved
>  >>>    > > > issues with the third approach to some other time (except to
>  >>>    > > > point out that one big challenge is the heterogeneity of
>  >>>    > > > routers during transition when some routers mark packets
>  >>>    > > > and some drop packets to indicate congestion).  Btw, I don't
>  >>>    > > > think the three approaches are mutually exclusive and can't
>  >>>    > > > complement each other.
>  >>>    > > >
>  >>>    > > > Steven
>  >>>    > > >
>  >>>    > > > ____________________________________________________________
>  >>>    > > > Steven Low,    Assoc Prof of CS and EE
>  >>>    > > > Caltech, Pasadena, CA91125
>  >>>    > > > Tel: +1 626 395 6767 Fax: +1 626 792 4257
>  >>>    > > > slow at caltech.edu
>  >>>    > > > netlab.caltech.edu
>  >>>    > > >
>  >>>    > > > >From owner-ecn-interest at research.att.com  Sat Jan 27
08:02:12
>  >>2001
>  >>>    > > > >Delivered-To: ecn-interest at research.att.com
>  >>>    > > > >X-url: http://nms.lcs.mit.edu/~hari/
>  >>>    > > > >To: slow at caltech.edu
>  >>>    > > > >Cc: ecn-interest at research.att.com, cwcam at caltech.edu,
>  >>>    wch at its.caltech.edu,
>  >>>    > > > >   siew at its.caltech.edu, rliu at yak.ugcs.caltech.edu
>  >>>    > > > >Subject: Re: RED-->ECN
>  >>>    > > > >Mime-Version: 1.0
>  >>>    > > > >Date: Fri, 26 Jan 2001 15:56:20 -0500
>  >>>    > > > >From: Hari Balakrishnan <hari at breeze.lcs.mit.edu>
>  >>>    > > > >
>  >>>    > > > >
>  >>>    > > > >Steven,
>  >>>    > > > >
>  >>>    > > > >REM is an interesting idea for using ECN, and I rather like
it
>  >>from
>  >>>    a research
>  >>>    > > > >standpoint because it doesn't have discontinuities (cf.
RED)
>  >>that
>  >>>    make analysis
>  >>>    > > > >harder.  However, I'm generally skeptical that any scheme
can be
>  >>>    shown to
>  >>>    > > > >eliminate essentially all buffer overflow losses under
_all_
>  >>>    conditions
>  >>>    > > > >(offered load), and yet accommodate bursts and provide
>  >>reasonably
>  >>>    low delays...
>  >>>    > > > > especially when not all offered traffic is reacting or
reacting
>  >>in
>  >>>    different
>  >>>    > > > >ways from multiplicative-decrease.  Even a small fraction
of
>  >>>    unresponsive
>  >>>    > > > >traffic may make life problematic.
>  >>>    > > > >
>  >>>    > > > >Some years ago, I found it pretty hard to tune RED for
this, to
>  >>>    enhance my ELN
>  >>>    > > > >scheme.  REM may be more promising, but my gut feeling (as
a
>  >>network
>  >>>    engineer)
>  >>>    > > > >tells me that it wouldn't be prudent to such implicit
deductions
>  >>>    about loss
>  >>>    > > > >causes in practice...
>  >>>    > > > >
>  >>>    > > > >Hari
>  >>>    > > > >
>  >>>    > > > >On Fri, 26 Jan 2001 12:34:52 PST, you wrote:
>  >>>    > > > >
>  >>>    > > > >> [Sorry for the previous broken msg...]
>  >>>    > > > >>
>  >>>    > > > >> Hi Saverio,
>  >>>    > > > >>
>  >>>    > > > >> Another point I'd like to add is that the addition of ECN
>  >>>    > > > >> may open up new opportunities for network control, some
of
>  >>>    > > > >> which we may not even envision now.  Without ECN we are
>  >>>    > > > >> stuck with using loss (or delay) as the only means to
>  >>>    > > > >> communicate between network and TCP sources.
>  >>>    > > > >> Let me give an example.
>  >>>    > > > >>
>  >>>    > > > >> There are two types of losses in wireless environment:
>  >>>    > > > >> 1. due to congestion (e.g. buffer overflow), and
>  >>>    > > > >> 2. due to wireles effect (handoffs, fast fading,
interference
>  >>>    etc).
>  >>>    > > > >> One problem with TCP over wireless links is that TCP
cannot
>  >>>    > > > >> differentiate
>  >>>    > > > >> between the two and essentially assume all losses are due
to
>  >>>    > > > >> congestion and reduce its rate.  Most of the current
proposed
>  >>>    > > > >> solutions are based on two ideas.
>  >>>    > > > >>
>  >>>    > > > >> The first idiea is to hide type 1 (wireless) losses from
TCP
>  >>>    source,
>  >>>    > > > >> so it sees only congestion losses and react properly.
>  >>Examples
>  >>>    > > > >> are various local recovery schemes, snoop, split TCP etc.
>  >>>    > > > >> The first idea is to inform the TCP source which of the
two
>  >>>    > > > >> types a loss belongs, so that TCP can react properly;
e.g. ELN
>  >>>    schemes.
>  >>>    > > > >>
>  >>>    > > > >> Availability of ECN allows a third approach: to eliminate
type
>  >>2
>  >>>    > > > >> (congestion) losses, so that TCP source only sees
wireless
>  >>losses
>  >>>    > > > >> and therefore know how to react.   But we still need to
>  >>measure
>  >>>    and
>  >>>    > > > >> feedback 'congestion' so that sources know to reduce
their
>  >>rates
>  >>>    > > > >> when new sources join or capacity drops.   By
'congestion', I
>  >>>    don't
>  >>>    > > > >> mean 'high loss', but simply 'demand exceeds supply' so
>  >>everyone
>  >>>    > > > >> should reduce their demand.   Since buffer overflow is
now
>  >>>    eliminated
>  >>>    > > > >> (assume we can do this, see below), we need a different
>  >>mechanism
>  >>>    to
>  >>>    > > > >> measure and to feedback this 'congestion' information.
Here
>  >>is
>  >>>    > > > >> where ECN comes in.   When we decouple the
measure+feedback of
>  >>>    > > > >> congestion from loss, we must have ECN to provide the
>  >>feedback.
>  >>>    > > > >>
>  >>>    > > > >> Now, can we possibly keep the queue small (greatly reduce
>  >>buffer
>  >>>    > > > >> overflow) *yet highly utilized*?    Recent research works
seem
>  >>to
>  >>>    > > > >> provide
>  >>>    > > > >> reasons to be optimistic.     One example is in our
paper:
>  >>>    > > > >>      REM: Active Queue Management
>  >>>    > > > >> on our website:
>  >>>    > > > >>      netlab.caltech.edu
>  >>>    > > > >>
>  >>>    > > > >> Steven
>  >>>    > > > >>
>  >>>    > > > >>
>  >>>    > > > >>
>  >>>    > > > >>
>  >>>    > > > >> >Date: Fri, 26 Jan 2001 12:35:44 -0500
>  >>>    > > > >> >From: "K. K. Ramakrishnan" <kk at teraoptic.com>
>  >>>    > > > >> >To: Saverio Mascolo <mascolo at poliba.it>
>  >>>    > > > >> >Cc: ecn-interest at research.att.com
>  >>>    > > > >> >
>  >>>    > > > >> >Saverio,
>  >>>    > > > >> >I am glad you see ECN as an evolution from RED.
>  >>>    > > > >> >This is our motivation also:
>  >>>    > > > >> >to have ECN incorporated and deployed with an
>  >>>    > > > >> >Active Queue Management scheme.
>  >>>    > > > >> >
>  >>>    > > > >> >However, it is difficult to agree with the other
observations
>  >>you
>  >>>    make:
>  >>>    > > > >> >if congestion was only caused by "one packet" as you
say,
>  >>then
>  >>>    > > > >> >one might wonder why we need to actually do a whole lot
to
>  >>>    > > > >> >one might wonder why we need to actually do a whole lot
to
>  >>>    > > > >> >either react to or avoid congestion. Unfortunately, that
>  >>isn't
>  >>>    the case.
>  >>>    > > > >> >
>  >>>    > > > >> >If you look at a congestion epoch, there are likely to
be
>  >>>    multiple
>  >>>    > > > >> >packets,
>  >>>    > > > >> >potentially from multiple flows, that are impacted:
>  >>>    > > > >> >either being marked or dropped.
>  >>>    > > > >> >ECN helps substantially in not dropping packet*s* - and
>  >>>    especially
>  >>>    > > > >> >when the window size for those flows that have their
packets
>  >>>    > > > >> >marked, it helps by not having them suffer a time-out.
>  >>>    > > > >> >
>  >>>    > > > >> >Further: the amount of complexity in either the router
>  >>>    (especially
>  >>>    > > > >> >in the router) or the end-system is not significant. I
know
>  >>that
>  >>>    > > > >> >may be a matter of opinion.
>  >>>    > > > >> >But in a router, the change is so minimal, I haven't
heard
>  >>anyone
>  >>>    > > > >> >complain of complexity of implementation.
>  >>>    > > > >> >
>  >>>    > > > >> >There is no violation of layering, at all. I don't see
why
>  >>you
>  >>>    say so.
>  >>>    > > > >> >
>  >>>    > > > >> >   K. K. Ramakrishnan
>  >>>    > > > >> >Saverio Mascolo wrote:
>  >>>    > > > >> >
>  >>>    > > > >> >> Hi All, I see ECN as an evolution of RED. Basically
ECN
>  >>saves
>  >>>    one
>  >>>    > > > >> >> packet, which is the packet that
>  >>>    > > > >> >> RED would drop to signal congestion, by setting a bit
in
>  >>the
>  >>>    header.
>  >>>    > > > >> >> Thus, to save just
>  >>>    > > > >> >> ONE PACKET, ECN introduces  complexity in routers, in
the
>  >>>    > > > >> >> protocol, violation of layering, etc...For these
reasons I
>  >>>    don't think
>  >>>    > > > >> >> that ECN would give an improvement to RED that is
>  >>commensurate
>  >>>    to its
>  >>>    > > > >> >> complexity.Is there any point that I miss? Saverio
>  >>>    > > > >> >>
>  >>>    > > > >> >>
http://www-dee.poliba.it/dee-web/Personale/mascolo.html
>  >>>    > >
>  >>>    > > --
>  >>>    > >
__________________________________________________________________
>  >>>    > > Steven Low, Assoc Prof of CS & EE
>  >>>    > > slow at caltech.edu                      netlab.caltech.edu
>  >>>    > > Tel: (626) 395-6767                   Caltech MC256-80
>  >>>    > > Fax: (626) 792-4257                   Pasadena CA 91125
>  >>>    > > _______________________________________________
>  >>>    > > end2end-interest mailing list
>  >>>    > > end2end-interest at postel.org
>  >>>    > > http://www.postel.org/mailman/listinfo/end2end-interest
>  >>>    > >
>  >>>
>  >>>    --
>  >>>    __________________________________________________________________
>  >>>    Steven Low, Assoc Prof of CS & EE
>  >>>    slow at caltech.edu              netlab.caltech.edu
>  >>>    Tel: (626) 395-6767           Caltech MC256-80
>  >>>    Fax: (626) 792-4257           Pasadena CA 91125
>  >>>
>  >>>
>  >>>
>  >>>
>  >>
>
>  cheers
>
>    jon
>




More information about the end2end-interest mailing list