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 <bob.bris...@bt.com> 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 <bob.bris...@bt.com> 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 > aqm@ietf.org > https://www.ietf.org/mailman/listinfo/aqm > > > > > -- > Andrew McGregor | SRE | andrewm...@google.com | +61 4 8143 7128 > _______________________________________________ > aqm mailing list > aqm@ietf.org > https://www.ietf.org/mailman/listinfo/aqm > > ________________________________________________________________ > Bob Briscoe, BT > -- Andrew McGregor | SRE | andrewm...@google.com | +61 4 8143 7128
_______________________________________________ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm
