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 http://sat-net.com/L.Wood/ ________________________________________ From: ietf-bounces@xxxxxxxx [ietf-bounces@xxxxxxxx] On Behalf Of Dearlove, Christopher (UK) [Chris.Dearlove@xxxxxxxxxxxxxx] Sent: 05 March 2013 11:55 To: mrex@xxxxxxx; braden@xxxxxxx Cc: ietf@xxxxxxxx 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 discussions. -- 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@xxxxxxxxxxxxxx | 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@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On Behalf Of Martin Rex Sent: 05 March 2013 00:42 To: braden@xxxxxxx Cc: ietf@xxxxxxxx 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: http://www.fujitsu.com/global/news/pr/archives/month/2013/20130129-02.html 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. -Martin ******************************************************************** 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. ********************************************************************