Re: [Dart] WGLC: draft-ietf-dart-dscp-rtp-02 - Gorry's item (2)

[Harald Alvestrand <[e-mail]>]

On 08/22/2014 09:33 PM, Black, David wrote:
> Good, I added a few words to be more explicit when I put the text into
> my working version of -03:
>
>    Guidance on transport protocol design and implementation to
>    provide support for use of multiple PHBs and DSCPs in a
>    transport protocol connection (e.g., DCCP) or transport protocol
>    association (e.g., SCTP) is out of scope for this document.

It would be nice to add "is a topic for future work", but
forward-looking statements should be avoided in RFCs. They turn out to
be embarassing down the road far too often....

(however, the WG could recommend to the ADs that this subject be pursued
by someone, somewhere, at some time....)

>
> Thanks,
> --David
>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]]
>> Sent: Friday, August 22, 2014 3:13 PM
>> To: Black, David
>> Cc: [e-mail]; [e-mail]; Black, David
>> Subject: RE: WGLC: draft-ietf-dart-dscp-rtp-02 - Gorry's item (2)
>>
>> I could live with that - it would be even nicer if we actually had a
>> document with set of recommendations to point to - but since we don't,
>> this seems an appropriate statement.
>>
>> Gorry
>>
>>
>>> Here's the next to last paragraph in Section 5.3:
>>>
>>>    SCTP [RFC4960] differs from TCP in a number of ways, including the
>>>    ability to deliver messages in an order that differs from the order
>>>    in which they were sent and support for unreliable streams.  However,
>>>    SCTP performs congestion control and retransmission across the entire
>>>    association, and not on a per-stream basis.  Although there may be
>>>    advantages to using multiple drop precedence across SCTP streams or
>>>    within an SCTP stream that does not use reliable ordered delivery,
>>>    there is no practical operational experience in doing so (e.g., the
>>>    SCTP sockets API [RFC6458] does not support use of more than one DSCP
>>>    for an SCTP association).  As a consequence, the impacts on SCTP
>>>    protocol and implementation behavior are unknown and difficult to
>>>    predict.  Hence a single PHB and DSCP should be used for all packets
>>>    in an SCTP association, independent of the number or nature of
>>>    streams in that association.  Similar reasoning applies to a DCCP
>>>    connection; a single PHB and DSCP should be used because the scope of
>>>    congestion control is the connection and there is no operational
>>>    experience with using more than one PHB or DSCP.
>>>
>>> I propose to add the following new sentence as its own paragraph:
>>>
>>>    Guidance on transport protocol design and implementation to provide
>>>    support for use of multiple PHBs and DSCPs in a transport connection
>>>    (e.g., DCCP) or association (e.g., SCTP) is out of scope for this
>>>    document.
>>>
>>> I could add examples of topics that could be addressed, but would prefer
>>> to leave that to the actual design activity.
>>>
>>> Thanks,
>>> --David
>>>
>>>
>>>> -----Original Message-----
>>>> From: Black, David
>>>> Sent: Thursday, August 14, 2014 9:16 AM
>>>> To: [e-mail]; [e-mail]
>>>> Cc: [e-mail]; Black, David
>>>> Subject: WGLC: draft-ietf-dart-dscp-rtp-02 - Gorry's item (2)
>>>>
>>>> Wearing none of my hats, I would prefer to put Gorry's item (2) into a
>>>> TSV
>>>> (Transport Area) draft somewhere, and hence prefer the suggestion to say
>>>> that this document does not provide that sort of guidance.
>>>>
>>>>>> (2) I don't know if the document's goal is also to make transport
>>>>>> recommendations for using multiple code points - i.e., things such
>>>> as must
>>>>>> be robust to the network changing a DSCP; needs to independently
>>>> verify
>>>>>> that a particular DCSP is not being black-holed, needs to not imply
>>>>>> relative precedence when interpreting loss or marking of packets for
>>>> a
>>>>>> flow using multiple DCSPs etc. ???
>>>>>>
>>>>>> If these are out of scope, then maybe the document should say that
>>>> this
>>>>>> particular document does not provide this sort of guidance.
>>>> Thanks,
>>>> --David
>>>>
>>>>> -----Original Message-----
>>>>> From: Dart [mailto:[e-mail]] On Behalf Of
>>>> [e-mail]
>>>>> Sent: Thursday, August 14, 2014 9:06 AM
>>>>> To: [e-mail]
>>>>> Cc: [e-mail]; [e-mail]
>>>>> Subject: Re: [Dart] WGLC: draft-ietf-dart-dscp-rtp-02
>>>>>
>>>>> Thanks
>>>>>
>>>>> When I said "transport" I was thinking of the algorithms to be used in
>>>> the
>>>>> end-host to figure out what was operational and where congestion and
>>>> delay
>>>>> were experienced. But what you say is all an import part. I expect
>>>> what
>>>>> you discuss, could go into the tsvwg intercom draft.
>>>>>
>>>>>
>>>>> Gorry
>>>>>> Hi Gorry,
>>>>>>
>>>>>> the following text will likely appear in the next version of my
>>>>>> diffserv-intercon draft. The more DSCPs appear in a flow which
>>>> aren't
>>>>>> deployed end-to-end for the corresponding PHB, the more often one of
>>>> the
>>>>>> scenarios will be encountered.
>>>>>>
>>>>>> The following scenarios start from a domain sending
>>>>>> IP traffic using a PHB and a corresponding DSCP to an interconnected
>>>>>> domain. The receiving domain may
>>>>>> -	Support the PHB and offer the same corresponding DSCP
>>>>>> -	Not support the PHB and use the DSCP for a different PHB
>>>>>> -	Not support the PHB and not use the DSCP
>>>>>> -	Support the PHB with a differing DSCP, and the DSCP of the
>>>>>>        sending domain is not used for another PHB
>>>>>> -	Support the PHB with a differing DSCP, and the DSCP of the
>>>>>>        sending domain is used for another PHB
>>>>>>
>>>>>> Another question to be answered then is how a network provider will
>>>> treat
>>>>>> unrecognized or unexpected DSCPs received at network boundaries.
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Ruediger
>>>>>>
>>>>>>
>>>>>> -----Ursprüngliche Nachricht-----
>>>>>> Von: Dart [mailto:[e-mail]] Im Auftrag von Gorry
>>>> Fairhurst
>>>>>> Gesendet: Mittwoch, 13. August 2014 22:33
>>>>>> An: [e-mail]
>>>>>> Betreff: [Dart] WGLC: draft-ietf-dart-dscp-rtp-02
>>>>>>
>>>>>>
>>>>>> I can see good points raised on the details, instead I have some
>>>> questions
>>>>>> about the overall document strcuture:
>>>>>>
>>>>>> [snip]
>>>>>>
>>>>>> (2) I don't know if the document's goal is also to make transport
>>>>>> recommendations for using multiple code points - i.e.things such as
>>>> must
>>>>>> be robust to the network changing a DSCP; needs to independently
>>>> verify
>>>>>> that a particular DCSP is not being black-holed, needs to not imply
>>>>>> relative precedence when interpreting loss or marking of packets for
>>>> a
>>>>>> flow using multiple DCSPs etc. ???
>>>>>>
>>>>>> If these are out of scope, then maybe the document should say that
>>>> this
>>>>>> particular document does not provide this sort of guidance.
>>>>>>
>>>>>> Gorry
>>>>>>
>>>>>> _______________________________________________
>>>>>> Dart mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/dart
>>>>>>
>>>>> _______________________________________________
>>>>> Dart mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/dart
> _______________________________________________
> Dart mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dart


-- 
Surveillance is pervasive. Go Dark.