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

["Black, David" <[e-mail]>]

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