[e2e] High Packet Loss and TCP

[dpsmiles at turing.acm.org]

>This means that you can often acquire congestion info from such
>devices within portions of any network path.  

How exactly is the congestion info acquired? In the context of a delay
tolerant network(DTN), we cannot use 'chatty' protocols, as they consume
valuable bandwidth. Looking at the techniques that are used in the normal
Internet:

1) Packet dropping: It is likely to go undetected for a long time, since 
the DTN model is very optimistic when it sends packets. To put it in
another way, there is a high expectation that the packet will reach the
destination. Thus the lifetimes of packets are long, compared to TCP
packets. 

2) Notification by setting a bit in a returning packet(piggybacking): Since
the connection is intermittent(and scheduled), I am not sure how much
really we can rely on this technique. It still has some scope, depending on
the availability of a packet on the return path.

3) Explicit notification by a choke packet: This will have to the last
resort, though a costly one. 

>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.  

I am not sure I understand this statement. Could you rephrase it?

Thoughts?

Thanks, Alex. 

PS: The DTN website is www.dtnrg.org

---------- Forwarded message ----------
Date: Thu, 01 May 2003 16:43:18 -0700
From: Cannara <cannara at attglobal.net>
To: end2end-interest at postel.org
Subject: Re: [e2e] High Packet Loss and TCP

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


--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .