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

[[e-mail]]

This message flow about ECN belongs in TSVWG - please do NOT cross post to
the AQM list.

If you are interested in the end-to-end usage of ECN or rules for tunnels,
etc then please do join the TSVWG list.

Gorry

---

> Joe,
>
> The approach of a BCP just about ECN doesn't preclude any of the
> following options for stds track docs:
> a) one RFC updating all tunnel specs about ECN
> b) one RFC updating all tunnel specs about ECN and Diffserv (the two
> fields that propagate up as well as down).
> c) one RFC updating all tunnel specs about everything
> d) one RFC per each tunnel spec to wrap up all updates around at the time
>
> These choices are for the relevant ADs and WGs to make.
> Writing a BCP in TSV gives the raw info that any of these approaches can
> use.
>
>
>
> Bob
>
> At 20:50 05/11/2013, Joe Touch wrote:
>
>
>>On 11/5/2013 10:59 AM, Bob Briscoe wrote:
>>>Joe,
>>>
>>>I envisage that a very brief standards track doc that explicitly UPDATES
>>>the relevant IETF tunnel specs will be written, and it will refer to
>>>this doc for rationale.
>>
>>Tunnels need to handle ingress/egress translation of all signals in
>>the header. This is no different.
>>
>>My concern is that putting these recommendations in separate places
>>gives an opportunity for different groups to have different
>>interpretations of that sort of translation, and that's a bad thing IMO.
>>
>>Joe
>>
>>
>>>
>>>See Appendix A (outstanding items), which I have also highlighted when
>>>presenting each time:
>>>
>>>     2.  Consider whether an IETF Standard Track doc will be needed to
>>>         Update the IP-in-IP protocols listed in Section 4.1--at least
>>>         those that the IETF controls--and which Area it should sit
>>> under.
>>>
>>>Does that address your concern?
>>>
>>>
>>>Bob
>>>
>>>At 18:40 05/11/2013, Joe Touch wrote:
>>>>IMO, these guidelines ought to come out in a single recommendation for
>>>>tunnels; we had a draft of that in INTAREA but insufficient momentum.
>>>>
>>>>Piecemeal recommendations are likely to be ignored/lost.
>>>>
>>>>Joe
>>>>
>>>>On 11/4/2013 11:36 PM, Michael Menth wrote:
>>>>>+1
>>>>>
>>>>>We need such guidelines for consistent congestion management.
>>>>>
>>>>>Best wishes,
>>>>>
>>>>>Michael
>>>>>
>>>>>Am 05.11.2013 00:16, schrieb Matt Mathis:
>>>>>>I think this is valuable work.  Having a single document that
>>>>>>describes the requirements and general principles will save future
>>>>>>tunnel inventor/implementers from rediscovering the same bugs
>>>>>>
>>>>>>Thanks,
>>>>>>--MM--
>>>>>>The best way to predict the future is to create it.  - Alan Kay
>>>>>>
>>>>>>Privacy matters!  We know from recent events that people are using
>>>>>> our
>>>>>>services to speak in defiance of unjust governments.   We treat
>>>>>>privacy and security as matters of life and death, because for some
>>>>>>users, they are.
>>>>>>
>>>>>>
>>>>>>On Mon, Nov 4, 2013 at 2:03 PM, Bob Briscoe <[e-mail]
>>>>>><mailto:[e-mail]>> wrote:
>>>>>>
>>>>>>     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
>>>>>>     [e-mail] <mailto:[e-mail]>
>>>>>>     https://www.ietf.org/mailman/listinfo/aqm
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>_______________________________________________
>>>>>>aqm mailing list
>>>>>>[e-mail]
>>>>>>https://www.ietf.org/mailman/listinfo/aqm
>>>>>
>>>>>--
>>>>>Prof. Dr. habil. Michael Menth
>>>>>University of Tuebingen
>>>>>Faculty of Science
>>>>>Department of Computer Science
>>>>>Chair of Communication Networks
>>>>>Sand 13, 72076 Tuebingen, Germany
>>>>>phone: [phone]
>>>>>fax: [phone]
>>>>>mailto:[e-mail]
>>>>>http://kn.inf.uni-tuebingen.de
>>>>>
>>>>>
>>>>>
>>>>>_______________________________________________
>>>>>aqm mailing list
>>>>>[e-mail]
>>>>>https://www.ietf.org/mailman/listinfo/aqm
>>>>_______________________________________________
>>>>aqm mailing list
>>>>[e-mail]
>>>>https://www.ietf.org/mailman/listinfo/aqm
>>>
>>>________________________________________________________________
>>>Bob Briscoe,                                                  BT
>>_______________________________________________
>>aqm mailing list
>>[e-mail]
>>https://www.ietf.org/mailman/listinfo/aqm
>
> ________________________________________________________________
> Bob Briscoe,                                                  BT
>
> _______________________________________________
> aqm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/aqm
>