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. > > 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. > > [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.zip ) > > > >/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 _______________________________________________ aqm mailing list [email protected] https://www.ietf.org/mailman/listinfo/aqm
