Hi Sorry about the slow response and thanks for the L2/L3 clarification.
As regards to the more detailed specifics around ECN, agree, I believe that the AQM WG can be helpful here and give recommendations on how packets should be ECN marked. /Ingemar > -----Original Message----- > From: Bob Briscoe [mailto:[email protected]] > Sent: den 23 januari 2014 15:51 > To: Ingemar Johansson S > Cc: [email protected]; [email protected]; [email protected] > Subject: RE: [aqm] [tsvwg] Who supports tsvwg adoption of adding ECN to L2 > or tunnel protocols? > > Ingemar, inline... > > At 06:36 22/01/2014, Ingemar Johansson S wrote: > >Hi > > > >Please find answers inline > > > >/Ingemar > > > > > -----Original Message----- > > > From: Bob Briscoe [mailto:[email protected]] > > > Sent: den 21 januari 2014 23:50 > > > To: Ingemar Johansson S; [email protected] > > > Cc: [email protected]; [email protected] > > > Subject: Re: [aqm] [tsvwg] Who supports tsvwg adoption of adding ECN > > > to L2 or tunnel protocols? > > > > > > Ingemar, > > > > > > 1) Thx for the pointer. We should add this as another example where > > > a lower layer marks the IP header (the example we already have is > > > the L3 switch in the Ethernet world). > > > > > > 2) It doesn't talk about propagation of ECN markings during encap & > > > decap, which is one of the things ecn-encap-guidelines aims to give > guidelines on. > > > Do you think a doc like the draft we've done > > would be useful to help 3GPP in > > > this respect? Do you think a formal liaison > > would be useful to point it out? > >L2 in this respect are the PDCP, RLC and MAC layers (to be honest I am > >not fully clear what constitutes L2). The problem is that to given > >encap/decap a meaning in this case it becomes necessary to encode at > >least an ECN-CE bit into any of the PDCP or RLC or MAC headers, as PDCP > >is ciphered it probably needs to be in the RLC or MAC headers. > >Currently there are no standards efforts to add an ECN-CE bit to any of > >these headers. > > I didn't mean encap of L3 in L2, because that would indeed require major > protocol changes. In this case, the L2 node is marking L3 directly (see 1 > above). > > I meant L3 in L3 (tunnelling), which is prevalent in 3GPP. > > > > > > > 3) 3GPP TS 36.300 is ambiguous whether ECN > > marking is applied to all packets > > > to "indicate congestion", or whether it is applied with a frequency > > > or probability that depends on an AQM (it doesn't mention AQM, altho > > > obviously it refers to RFC3168 that is based on AQM). Do you know > > > whether it was meant to imply use of AQM? > >Yes, it is very ambiguous, I advocate for a frequency or probability as > >it makes most sense, but this is not specified at all. The ECN marking > >can imply the use of AQM but that is again not specified. In short, > >much of the actual implementation is vendor specific. > > OK. In general vendor-specific is good, and congestion control can be robust > to different behaviours. > > Our draft states that algorithm guidance is outside its scope, but... > > One of the purposes of the IETF's AQM guidance is to set bounds on how > much variety is feasible without losing interworking. There's a message in > 3GPP TS 36.300 on how the IETF's RFCs could be (mis)interpreted, if we don't > make them clear. > > > Bob > > > > > > > > [Ruediger, thx for the supportive words too] > > > > > > > > > Bob > > > > > > At 20:29 21/01/2014, Ingemar Johansson S wrote: > > > >Hi > > > > > > > >Please note that ECN over LTE radio access is already standardized > > > >in 3GPP TS 36.300 (see 11.6 in > > > >http://www.3gpp.org/ftp/specs/archive/36_series/36.300/36300-c00.zi > > > >p ) > > > > > > > >/Ingemar > > > > > -----Original Message----- > > > > > From: [email protected] > [mailto:[email protected]] > > > > > Sent: den 21 januari 2014 08:38 > > > > > To: [email protected] > > > > > Cc: [email protected]; [email protected] > > > > > Subject: Re: [aqm] [tsvwg] Who supports tsvwg adoption of adding > > > > > ECN to L2 or tunnel protocols? > > > > > > > > > > Hi Bob, > > > > > > > > > > I support the issue being picked up by IETF. What can be done > > > > > within the bounds of IETF responsibility should be done. If ECN > > > > > is seeing deployment, especially ECN support for IP over VLAN > > > > > over IP/MPLS may > > > be of interest. > > > > > Further, ECN over LTE radio Access may be relevant (but my > > > > > expertise is too limited to judge details). > > > > > > > > > > Regards, > > > > > > > > > > Ruediger > > > > > > > > > > -----Ursprüngliche Nachricht----- > > > > > Von: [email protected] [mailto:[email protected]] Im > > > > > Auftrag von Bob Briscoe > > > > > Gesendet: Montag, 4. November 2013 23:04 > > > > > An: tsvwg IETF list; AQM IETF list > > > > > Cc: [email protected] > > > > > Betreff: [tsvwg] Who supports tsvwg adoption of adding ECN to L2 > > > > > or tunnel protocols? > > > > > > > > > > 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 > > > >[email protected] > > > >https://www.ietf.org/mailman/listinfo/aqm > > > > > > > __________________________________________________________ > > > ______ > > > Bob Briscoe, BT > > __________________________________________________________ > ______ > Bob Briscoe, BT _______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm
