IETF Logo Mail Archive

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

<Ruediger.Geib@telekom.de> Tue, 21 January 2014 07:38 UTC

Return-Path: <Ruediger.Geib@telekom.de>
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 EA1F31A005E; Mon, 20 Jan 2014 23:38:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.886
X-Spam-Level:
X-Spam-Status: No, score=-0.886 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.535] 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 AsUD4zxMU3uX; Mon, 20 Jan 2014 23:38:02 -0800 (PST)
Received: from tcmail23.telekom.de (tcmail23.telekom.de [80.149.113.243]) by ietfa.amsl.com (Postfix) with ESMTP id F1B491A0058; Mon, 20 Jan 2014 23:38:01 -0800 (PST)
Received: from he113657.emea1.cds.t-internal.com ([10.134.99.17]) by tcmail21.telekom.de with ESMTP/TLS/AES128-SHA; 21 Jan 2014 08:38:00 +0100
Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE113657.emea1.cds.t-internal.com ([::1]) with mapi; Tue, 21 Jan 2014 08:38:00 +0100
From: Ruediger.Geib@telekom.de
To: bob.briscoe@bt.com
Date: Tue, 21 Jan 2014 08:37:59 +0100
Thread-Topic: [tsvwg] Who supports tsvwg adoption of adding ECN to L2 or tunnel protocols?
Thread-Index: Ac7ZqeZ/7AQswgk0TByj6KTyywQpeg80Potg
Message-ID: <CA7A7C64CC4ADB458B74477EA99DF6F502347353E1@HE111643.EMEA1.CDS.T-INTERNAL.COM>
References: <201311042203.rA4M3lo0026458@bagheera.jungle.bt.co.uk>
In-Reply-To: <201311042203.rA4M3lo0026458@bagheera.jungle.bt.co.uk>
Accept-Language: en-US, de-DE
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US, de-DE
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailman-Approved-At: Tue, 21 Jan 2014 00:29:01 -0800
Cc: tsvwg@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 07:38:05 -0000

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

v2.23.0 | Report a Bug | By Email