Hi all,

This document reminds of thinking of lower layer congestion and queuing 
mechanisms in network, sometimes which would leverage large coverage. The modes 
to guide seem all validated and even helpful for my scenarios of some IP-in-IP 
case as what is saying in draft. So, I would be good for adoption of this draft 
as a work item, and, would like to promote in this direction by something 
feedback to WG.

My always thought that the encoding of ECN marking, as in some case the ingress 
of a tunnel may need the space(s) for following layer3 entities to fill the ECT 
and location information (at lease e.g. IP address). Obviously, information of 
location would be only helpful to network operator, but the end point handling 
ECN marking. 

Best regards,
Zhu Lei
Mobile: +86-13910157020

-----邮件原件-----
发件人: [email protected] [mailto:[email protected]] 代表 Bob Briscoe
发送时间: 2013年11月5日 6:04
收件人: tsvwg IETF list; AQM IETF list
抄送: Pat Thaler; John Kaippallimalil; 
[email protected]
主题: [aqm] 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
[email protected]
https://www.ietf.org/mailman/listinfo/aqm
_______________________________________________
aqm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/aqm

Reply via email to