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

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

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.

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
> >
>