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

[Andrew Mcgregor <[e-mail]>]

That's about what I thought the answer would be... but it's worth having
that in the record :-)


On 5 November 2013 11:00, Bob Briscoe <[e-mail]> wrote:

>  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 <[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 >
>
> 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
> [e-mail]
>  https://www.ietf.org/mailman/listinfo/aqm
>
>
>
>
> --
> Andrew McGregor | SRE | [e-mail] | [phone]
> _______________________________________________
> aqm mailing list
> [e-mail]
>  https://www.ietf.org/mailman/listinfo/aqm
>
>  ________________________________________________________________
> Bob Briscoe,                                                  BT
>



-- 
Andrew McGregor | SRE | [e-mail] | [phone]