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

From: <[email-masked]>
Date: Tue, 21 Jan 2014 08:37:59 +0100

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-masked] [mailto:[email-masked]] Im Auftrag von Bob Briscoe
Gesendet: Montag, 4. November 2013 23:04
An: tsvwg IETF list; AQM IETF list
Cc: [email-masked]
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

---

From: Bob Briscoe <[email-masked]>
Date: Tue, 21 Jan 2014 22:49:35 +0000

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?

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?

[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-masked] [mailto:[email-masked]]
> > Sent: den 21 januari 2014 08:38
> > To: [email-masked]
> > Cc: [email-masked]; [email-masked]
> > 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
> >
> > 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.
> > Guidelines for Adding Congestion Notification to Protocols that Encapsulate
> > IP <http://tools.ietf.org/html/draft-briscoe-tsvwg-ecn-encap-guidelines>
> >
> > Abstract
> >
>_______________________________________________
>aqm mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/aqm

---

From: Bob Briscoe <[email-masked]>
Date: Thu, 23 Jan 2014 14:51:25 +0000

Ingemar, inline...

At 06:36 22/01/2014, Ingemar Johansson S wrote:
>Hi
>
>Please find answers inline
>
>/Ingemar
>
> > From: Bob Briscoe [mailto:[email-masked]]
> > Sent: den 21 januari 2014 23:50
> > To: Ingemar Johansson S; [email-masked]
> > 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.

> 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

> > >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
> > > > 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
> > > >
> > > > Pls respond if you support this being adopted as a work-group item
> > > > in the IETF transport services w-g (tsvwg). The WG
> > > > Guidelines for Adding Congestion Notification to Protocols that
> > > > Encapsulate IP
> > > > 
> <http://tools.ietf.org/html/draft-briscoe-tsvwg-ecn-encap-guidelines> > > >
> > > >
> > > > Abstract
> > > >

---

From: Ingemar Johansson S <[email-masked]>
Date: Tue, 21 Jan 2014 20:29:06 +0000

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
> IETF transport services w-g (tsvwg). The WG chairs need visibility of interest.

---

From: Ingemar Johansson S <[email-masked]>
Date: Wed, 22 Jan 2014 06:36:24 +0000

Hi

/Ingemar

> 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
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.

> > > <http://tools.ietf.org/html/draft-briscoe-tsvwg-ecn-encap-guidelines
> > > >
> > >
> > > Abstract
> > >

---

From: Ingemar Johansson S <[email-masked]>
Date: Thu, 30 Jan 2014 12:46:33 +0000

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

> Sent: den 23 januari 2014 15:51
> To: Ingemar Johansson S
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: RE: [aqm] [tsvwg] Who supports tsvwg adoption of adding ECN to L2
> or tunnel protocols?
> 
> Ingemar, inline...
> 
> > > 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.
> >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).
> 
> > > 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.
> 
> 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
> 
> 
> > >
> > > >Please note that ECN over LTE radio access is already standardized
> > > >in 3GPP TS 36.300 (see 11.6 in
> > > > > 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
> > > > >
> > > > > Pls respond if you support this being adopted as a work-group
> > > > > item in the IETF transport services w-g (tsvwg). The WG
> > <http://tools.ietf.org/html/draft-briscoe-tsvwg-ecn-encap-guidelines>
> > > > >
> > > > >
> > > > > Abstract
> > > > >