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

Weixinpeng <weixinpeng@huawei.com> Tue, 05 November 2013 01:08 UTC

Return-Path: <weixinpeng@huawei.com>
X-Original-To: aqm@ietfa.amsl.com
Delivered-To: aqm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A86211E8316; Mon, 4 Nov 2013 17:08:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level:
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id McFbWub1Eir8; Mon, 4 Nov 2013 17:08:49 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0E08611E8300; Mon, 4 Nov 2013 17:08:48 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AZV94252; Tue, 05 Nov 2013 01:08:47 +0000 (GMT)
Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 5 Nov 2013 01:08:09 +0000
Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 5 Nov 2013 01:08:44 +0000
Received: from NKGEML507-MBX.china.huawei.com ([169.254.5.4]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Tue, 5 Nov 2013 09:08:39 +0800
From: Weixinpeng <weixinpeng@huawei.com>
To: "tsvwg@ietf.org" <tsvwg@ietf.org>, "aqm@ietf.org" <aqm@ietf.org>
Thread-Topic: Who supports tsvwg adoption of adding ECN to L2 or tunnel protocols?
Thread-Index: AQHO2ar1vFFB2XF4BkqGsTlMgx3rlZoV0TJQ
Date: Tue, 05 Nov 2013 01:08:38 +0000
Message-ID: <C5C3BB522B1DDF478AA09545169155B43DA963DB@nkgeml507-mbx.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.76.176]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Subject: Re: [aqm] Who supports tsvwg adoption of adding ECN to L2 or tunnel protocols?
X-BeenThere: aqm@ietf.org
X-Mailman-Version: 2.1.12
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, 05 Nov 2013 01:08:54 -0000

I look through the whole document and I really think it's a good idea to propagate congestion signals through different networks,
it will be good to deal with the congestion situation especially when there are lower layer en route.



> >Date: Mon, 04 Nov 2013 22:03:45 +0000
> >To: "tsvwg IETF list" <tsvwg@ietf.org>, AQM IETF list <aqm@ietf.org>
> >From: Bob Briscoe <bob.briscoe@bt.com>
> >Subject: Who supports tsvwg adoption of adding ECN to L2 or tunnel
> protocols?
> >Cc: John Kaippallimalil <John.Kaippallimalil@huawei.com>, Pat Thaler
> ><pthaler@broadcom.com>,
> >draft-briscoe-tsvwg-ecn-encap-guidelines@tools.ietf.org
> >
> >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
> 
> ___________________________________________________________
> _____
> Bob Briscoe,                                                  BT