[e2e] congestion control? - (was Re: Appointment of a Transport Area Director)

l.wood@surrey.ac.uk l.wood at surrey.ac.uk
Tue Mar 5 04:22:50 PST 2013

The problem with the congestion/interference and corruption problem is that error notification does
not percolate up the stack.

If a MAC driver could say 'this frame is corrupt, failed CRC' and that information percolated up the layers into the flow to the endpoints,
TCP or similar might have more to go on. But that information is hard to convey, multiple links may be affected, it gets lost...
first hops benefit most. 

in other words, Explicit Corruption Notification would fail for the same reasons that Explicit Congestion Notification does.

And this is presuming that enough of the frame is recoverable to know which higher-layer flow it is associated with reliably, ie
some header check passes, but overall frame check fails so there's a discard, and state is around to signal the right flow.

And to make the header checks pass with a chance of decoding the headers have to  be coded better than the payloads - and
this applies at each layer, recursively. um.

But there's a paucity of cross-layer signalling, and a paucity of higher layers even sanity-checking their header with checksums.
And a paucity of available state to track and associate with flows.

Lloyd Wood

From: ietf-bounces at ietf.org [ietf-bounces at ietf.org] On Behalf Of Dearlove, Christopher (UK) [Chris.Dearlove at baesystems.com]
Sent: 05 March 2013 11:55
To: mrex at sap.com; braden at isi.edu
Cc: ietf at ietf.org
Subject: RE: congestion control? - (was Re: Appointment of a Transport  Area    Director)

I've no idea about the example quoted, but I can see some of their motivation.

TCP's assumptions (really simplified) that loss of packet = congestion => backoff
aren't necessarily so in a wireless network, where packets can be lost without
congestion. This means that TCP into, out of, or across, a MANET using TCP can be
bad. It then tends to happen that the MANET people don't fully understand TCP,
and the TCP people don't fully understand MANETs.

I don't have a single good reference for what I say above, in particular have
things got better (or worse) as TCP evolves, and therefore which references
are still valid? But the obvious Google search (TCP MANET) throws up various

Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124
chris.dearlove at baesystems.com | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

-----Original Message-----
From: ietf-bounces at ietf.org [mailto:ietf-bounces at ietf.org] On Behalf Of Martin Rex
Sent: 05 March 2013 00:42
To: braden at isi.edu
Cc: ietf at ietf.org
Subject: Re: congestion control? - (was Re: Appointment of a Transport Area Director)

Bob Braden wrote:
> On 3/4/2013 10:20 AM, Roger Jørgensen wrote:
> > I'll ask a rather basic question and hope someone will answer in an
> > educational way - Why is congestion control so important? And where
> > does it apply? ... :-)
> Ouch. Because without it (as we learned the hard way in the late 1980s) \
> the Internet may collapse and provide essentially no service.

It is PR like this one:


That gets me worried about folks might try to "fix" the internet
mostly due to the fact that they really haven't understood what
is already there any why.


This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.

More information about the end2end-interest mailing list