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

Bob Briscoe <bob.briscoe@bt.com> Tue, 21 January 2014 22:49 UTC

Return-Path: <bob.briscoe@bt.com>
X-Original-To: aqm@ietfa.amsl.com
Delivered-To: aqm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D25411A0343; Tue, 21 Jan 2014 14:49:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.436
X-Spam-Level:
X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tnczsPyfm-0s; Tue, 21 Jan 2014 14:49:45 -0800 (PST)
Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.98]) by ietfa.amsl.com (Postfix) with ESMTP id 662A81A0256; Tue, 21 Jan 2014 14:49:44 -0800 (PST)
Received: from EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) by EVMHR66-UKRD.bt.com (10.187.101.21) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 21 Jan 2014 22:49:43 +0000
Received: from EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) by EVMHR71-UKRD.domain1.systemhost.net (10.36.3.109) with Microsoft SMTP Server (TLS) id 8.3.279.1; Tue, 21 Jan 2014 22:49:43 +0000
Received: from bagheera.jungle.bt.co.uk (132.146.168.158) by EPHR01-UKIP.domain1.systemhost.net (147.149.196.177) with Microsoft SMTP Server id 14.2.347.0; Tue, 21 Jan 2014 22:49:41 +0000
Received: from BTP075694.jungle.bt.co.uk ([10.111.123.72]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id s0LMneWw026346; Tue, 21 Jan 2014 22:49:41 GMT
Message-ID: <201401212249.s0LMneWw026346@bagheera.jungle.bt.co.uk>
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Tue, 21 Jan 2014 22:49:35 +0000
To: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>, "Ruediger.Geib@telekom.de" <Ruediger.Geib@telekom.de>
From: Bob Briscoe <bob.briscoe@bt.com>
In-Reply-To: <81564C0D7D4D2A4B9A86C8C7404A13DA31EC250B@ESESSMB205.ericss on.se>
References: <201311042203.rA4M3lo0026458@bagheera.jungle.bt.co.uk> <CA7A7C64CC4ADB458B74477EA99DF6F502347353E1@HE111643.EMEA1.CDS.T-INTERNAL.COM> <81564C0D7D4D2A4B9A86C8C7404A13DA31EC250B@ESESSMB205.ericsson.se>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format="flowed"
Content-Transfer-Encoding: quoted-printable
X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158
Cc: "tsvwg@ietf.org" <tsvwg@ietf.org>, "aqm@ietf.org" <aqm@ietf.org>
Subject: Re: [aqm] [tsvwg] Who supports tsvwg adoption of adding ECN to L2 or tunnel protocols?
X-BeenThere: aqm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussion list for active queue management and flow isolation." <aqm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/aqm>, <mailto:aqm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/aqm/>
List-Post: <mailto:aqm@ietf.org>
List-Help: <mailto:aqm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/aqm>, <mailto:aqm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Jan 2014 22:49:49 -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: Ruediger.Geib@telekom.de [mailto:Ruediger.Geib@telekom.de]
> > Sent: den 21 januari 2014 08:38
> > To: bob.briscoe@bt.com
> > Cc: tsvwg@ietf.org; aqm@ietf.org
> > 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: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] Im Auftrag
> > von Bob Briscoe
> > Gesendet: Montag, 4. November 2013 23:04
> > An: tsvwg IETF list; AQM IETF list
> > Cc: draft-briscoe-tsvwg-ecn-encap-guidelines@tools.ietf.org
> > 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
>aqm@ietf.org
>https://www.ietf.org/mailman/listinfo/aqm

________________________________________________________________
Bob Briscoe,                                                  BT