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

[Joe Touch <[e-mail]>]

Hi, Bob,

IMO, the desciption of how IP header info (which is what I presume 
you're suggesting) to impact L2s (which include tunnels) belongs in a 
tunnel doc, which AFAICT belongs in INTAREA. The tunnel landscape is 
already quite complex.

I have no idea why TSV would be involved in this except if you're 
talking about TCP ECH markings, but IMO the relationship of the TCP mark 
to the IP mark might belong in TSV.

However, I do not think TSV should be promoting having signals "jump" 
layers, i.e., from TCP ECN to its impact on tunnels or L2.

Joe

On 11/6/2013 2:50 PM, Bob Briscoe wrote:
> 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