[e2e] High Packet Loss and TCP

[Cannara]

Durga, let me mention some experience with some real products developed for
the network edge/interior, whether security & load balancing, or just simple
routing...

1) The devices used now, Network Processors, Fabric Switches & Traffic
Managers, allow firmware setting of a wide variety of policies:  priority
queuing, weighted dropping and other forms of flow control outbound (to the
next interface/hop).  Traffic manager chips now available can do this for a
few hundred-thousand flows at multi-Gb rates.

2) The device input paths allow for a variety of hardware/Layer2 flow control
(e.g., CSIX, SPI4.2, etc.).

So, congestion is observed locally (within a box, a rack, or within a site) in
a packet environment; and over MUXes on a metro ring, in a Sonet-like
environment.  This means that you can often acquire congestion info from such
devices within portions of any network path.  Service providers at the edge
have direct requirements to limit flows, because their connections to the
network core are more limited than the aggregate flows they might have to
send/receive for subscribers.  

Because "rate limiting", "traffic shaping", or whatever other nice words are
used for "packet dropping", provide the only way edge folks currently have to
tell leaves in the net to slow down, this means that congestion exists at two
major spots:  edge services and core distribution (peering) points.  If you
were only to look at these places for congestion data, you'd do pretty well,
especially if you picked busy times for Inet traffic (e.g., daily cycles, or
as when the Monica Lewinsky report went out :).  I don't think simulations
will quite capture the reality of what goes on.  You might identify some spots
to examine and ask for data from various researchers, like the SLAC
"ping-around-the-world" folks (Cottrell...).

Alex

Durga Prasad Pandey wrote:
> 
> I am looking into the possibility of congestion in a delay tolerant
> network(Characterized by high latency, intermittent connectivity, and high
> error rates). Since I am new to this area, could I ask for suggestions on
> how to approach the task of checking congestion in the network as a whole?
> In other words, if we define congestion to occur when the net amount of
> data flowing into a network through various nodes is greater than the net
> amount of data flowing out, what parametsrs would one use to identify
> congestion?
> Another question is: Are there some free network simulators available on
> the web?
> 
> I will appreciate any help.
> 
> Durga
> 
> On Thu, 1 May 2003, David G. Andersen wrote:
> 
> > On Thu, May 01, 2003 at 03:40:42PM -0400, Ross Callon quacked:
> > > My understanding is that there is some level of packet loss
> > > which causes TCP to back off to the point of stopping. My
> > > impression is that this is a sufficiently high loss rate that it
> > > shouldn't happen in a network which is behaving properly,
> > > and if it happens this should be considered a network failure
> > > rather than a TCP problem. (I am pretty sure that I saw this
> > > sort of behavior a few years ago when trying to access large
> > > files over a very bad link).
> > >
> > > Is there a paper which would describe what the appropriate
> > > loss rate is that would cause this problem? Is there any
> > > general understanding of what level of packet loss will cause
> > > serious problems?
> >
> > My favorite source for this is from Padhye et al.,
> > which shows a pretty drastic knee in the TCP performance curve
> > when the loss rate starts to exceed about 30%.  It's not a
> > total "outage", but it does represent about a two order of
> > magnitude reduction in throughput, and renders the network
> > pretty unusable.
> >
> > J. Padhye, V. Firoiu, D. Towsley, and J. Kurose
> > Modeling TCP Throughput:  A Simple Model and its Empirical Validation.
> > In Proc. ACM SIGCOMM, September 1998.
> >
> > ftp://gaia.cs.umass.edu/pub/Padhye-Firoiu98-TCP-throughput.ps.Z
> >
> >    -Dave
> --
> Durga Prasad Pandey
> Assistant Online Editor, ACM Crossroads
> dpsmiles at acm.org