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

[[e-mail]]

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
>