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

[Ingemar Johansson S <[e-mail]>]

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:[e-mail]]
> Sent: den 23 januari 2014 15:51
> To: Ingemar Johansson S
> Cc: [e-mail]; [e-mail]; [e-mail]
> 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:[e-mail]]
> > > Sent: den 21 januari 2014 23:50
> > > To: Ingemar Johansson S; [e-mail]
> > > Cc: [e-mail]; [e-mail]
> > > 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: [e-mail]
> [mailto:[e-mail]]
> > > > > Sent: den 21 januari 2014 08:38
> > > > > To: [e-mail]
> > > > > Cc: [e-mail]; [e-mail]
> > > > > 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: [e-mail] [mailto:[e-mail]] Im
> > > > > Auftrag von Bob Briscoe
> > > > > Gesendet: Montag, 4. November 2013 23:04
> > > > > An: tsvwg IETF list; AQM IETF list
> > > > > Cc: [e-mail]
> > > > > 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
> > > >[e-mail]
> > > >https://www.ietf.org/mailman/listinfo/aqm
> > >
> > >
> __________________________________________________________
> > > ______
> > > Bob Briscoe,                                                  BT
> 
> __________________________________________________________
> ______
> Bob Briscoe,                                                  BT