Re: [aqm] Who supports tsvwg adoption of adding ECN to L2 or tunnel protocols?

[Bob Briscoe <[e-mail]>]

Andrew,

Thx for supporting words and offer of help.

At 23:04 04/11/2013, Andrew Mcgregor wrote:
>This seems like valuable work.  One question is, can we put in scope 
>notification that losses are NOT due to congestion?

Eyooow. That really does not belong in this scope.

This is about the interface between lower layers and the ECN field in 
the IP header. We can't really talk about new semantics in lower 
layers that aren't even defined in ECN at the IP layer.

Naively, one could imagine some text treating the ECN field as 4 
opaque codepoints, and propagating  a similar 4 opaque codepoints 
from each lower layer protocol. Then if something new were defined in 
IP-ECN like a non-congestive loss codepoint, it could also be defined 
in lower layers...

But that's naive, because each lower layer has it's own constraints 
and ways of handling concepts like "ECN-capable transport", none of 
which easily translates to a simple mapping of codepoints.

Explicit signalling of non-congestive loss is a research problem, because...
* Clearly a link cannot signal that a loss was not due to congestion 
using the lost frame itself (there aren't any bits :)
* So the link would have to signal in another frame that didn't get corrupted.
   - That frame may go to another process that didn't see any loss; 
then what does the process do?
   - or the link has to use DPI to signal only in frames going to the 
same process as the lost frame.
   - that means the link has to understand all transport protocols

There's other hard problems
* A transmission loss doesn't always mean there is no congestion loss
* At my last count, there were at least nine different reasons for 
packet loss. If we had 4 bits spare in each lost packet... :)



Bob


>Willing to comment and review, at least.
>
>
>On 5 November 2013 09:03, Bob Briscoe 
><<mailto:[e-mail]>[e-mail]> wrote:
>Folks,
>
>Pls respond if you support this being adopted as a work-group item 
>in the IETF transport services w-g (tsvwg). The WG chairs need 
>visibility of interest.
>Even better, if you're willing to read / comment / review / implement
>
>Guidelines for Adding Congestion Notification to Protocols that Encapsulate IP
><<http://tools.ietf.org/html/draft-briscoe-tsvwg-ecn-encap-guidelines>http://tools.ietf.org/html/draft-briscoe-tsvwg-ecn-encap-guidelines>
>
>Abstract
>
>    The purpose of this document is to guide the design of congestion
>    notification in any lower layer or tunnelling protocol that
>    encapsulates IP.  The aim is for explicit congestion signals to
>    propagate consistently from lower layer protocols into IP.  Then the
>    IP internetwork layer can act as a portability layer to carry
>    congestion notification from non-IP-aware congested nodes up to the
>    transport layer (L4).  Following these guidelines should assure
>    interworking between new lower layer congestion notification
>    mechanisms, whether specified by the IETF or other standards bodies.
>
>
>[Cross-posting tsvwg & aqm, just in case]
>
>
>Bob Briscoe,
>also for co-authors Pat Thaler and John Kaippallimalil
>
>
>________________________________________________________________
>Bob Briscoe,                                                  BT
>_______________________________________________
>aqm mailing list
><mailto:[e-mail]>[e-mail]
>https://www.ietf.org/mailman/listinfo/aqm
>
>
>
>
>--
>Andrew McGregor | SRE | 
><mailto:[e-mail]>[e-mail] | [phone]
>_______________________________________________
>aqm mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/aqm

________________________________________________________________
Bob Briscoe,                                                  BT