[e2e] how to control the traffic rate below a defined value at the network node????

John Kristoff jtk at depaul.edu
Thu Oct 10 06:49:36 PDT 2002

On Wed, 9 Oct 2002 11:52:00 +0530
"alok" <alok.dube at apara.com> wrote:

> to all those who answered....with packeteers example...
> what do u do for UDP and ICMP traffic...or basically internet traffic
> which has no flowcontrol in the upper layer?

You can design the network to not have any congestion, which essentially
means building all links bigger than all the potential capacity that
could be delivered on them.  Since this is probably not going to happen
for the entire public Internet any time soon, you have to accept some
congestion and generally with those types of protocols, you'll have to

You would probably not want to buffer data in the network for very long.
 While there may be some reason to do this (e.g. batch processes), you
can end up with stale data, network delays causing poor performance
and/or cause a cascading effect of delays for new data.

Assuming you have to accept congestion and hence dropped data, it is
often better to drop data somewhere in the middle rather than have it be
delivered all the way to far end and be delayed due to buffering.  In
fact, if the network is congested sufficiently, you will have no choice.
Some real-time applications may not be able to use data that arrives too
far in the future anyway.  You might want to drop earlier rather than
later, especially if earlier drops can act as a faster hint for ends to
slow down, as in the case with TCP and RED.

Another way to design a network without cogestion (or with less
congestion more likely) is to design protocols and mechanisms on end
hosts that will help end avoid congestion.  For ICMP/UDP this probably
means not using those protocols and doing something different.  There is
some work in progress in this area.  I suppose you could build
rudimentary mechanisms like rate limiting and pacing into end host
stacks that work on ICMP and UDP, but this just hides the dropping
effect from the net.  You probably still need to deal with whatever
congestion problems are happening in the end host somehow.


More information about the end2end-interest mailing list