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

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

Gorry Fairhurst commented:

> (1) This statement appears at the end of section 2:
> 
>     "Multiplexing may reduce the complexity and resulting load on an
>     endpoint.  A single instance of STUN/ICE/TURN is simpler to execute
>     and manage than multiple instances STUN/ICE/TURN operations happening
>     in parallel, as the latter require synchronization and create more
>     complex failure situations that have to be cleaned up by additional
>     code."
> 
> 
> I suspect this is all true, but I'd like to ask that section 4 also
> makes a similar summary claim at the end - saying that using a single 5
> tuple and multiplexing multiple streams with *different* QoS expectation
> and therefore different DSCP markings can complicate the transport
> protocol design, by requiring a transport to disambiguate the congestion
> state for each network QoS category that is used. It will also result in
> increased complexity at the transport layer to validate path integrity,
> where a 5-tuple could result in a different routing/forwarding path in
> order to validate that the individual 5-tuples are reachable.  Of
> course, using DSCPs with an AF class can reduce some of the latter
> costs. etc. according to what the draft says.

The draft's been reorganized since the version that Gorry reviewed, so the
guidelines that were in Section 4 are now in Section 6.

This does feel like a good discussion to add, as it strengthens the rationale
for a single PHB/DSCP for a single TCP connection, SCTP association or DCCP
connection.  This discussion feels like it belongs in Section 5 somewhere,
and I would say the same for some of the rationale for that single PHB/DSCP
guideline, as it's not as clear as it could be about reordering (always a bad
idea) and different drop precedences (complexity, lack of operational
experience), and hence could use some elaboration.

I'd suggest a new Section 5.4 on "single PHB/DSCP for a single TCP connection,
SCTP association or DCCP connection" to expand that rationale and pick up
discussion of Gorry's item (1), as it applies (in different ways) to both
reordering and different drop precedences.  That would be accompanied by a
rewrite of the single PHB/DSCP guideline bullet. 

I'll try to work on some text offline w/Gorry with the goal of posting it
to the list sometime next week.

Thanks,
--David


> -----Original Message-----
> From: Dart [mailto:[e-mail]] On Behalf Of Gorry Fairhurst
> Sent: Wednesday, August 13, 2014 4:33 PM
> To: [e-mail]
> Subject: [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:
> 
> (1) This statement appears at the end of section 2:
> 
>     "Multiplexing may reduce the complexity and resulting load on an
>     endpoint.  A single instance of STUN/ICE/TURN is simpler to execute
>     and manage than multiple instances STUN/ICE/TURN operations happening
>     in parallel, as the latter require synchronization and create more
>     complex failure situations that have to be cleaned up by additional
>     code."
> 
> 
> I suspect this is all true, but I'd like to ask that section 4 also
> makes a similar summary claim at the end - saying that using a single 5
> tuple and multiplexing multiple streams with *different* QoS expectation
> and therefore different DSCP markings can complicate the transport
> protocol design, by requiring a transport to disambiguate the congestion
> state for each network QoS category that is used. It will also result in
> increased complexity at the transport layer to validate path integrity,
> where a 5-tuple could result in a different routing/forwarding path in
> order to validate that the individual 5-tuples are reachable.  Of
> course, using DSCPs with an AF class can reduce some of the latter
> costs. etc according to what the draft says.
> 
> I don't suggest that the extra complexity and additional algorithms are
> as big a problem as being unable to get through a NAPT/Firewall, but it
> seems that this nonetheless extra stuff that I don't recall having been
> worked upon before in the IETF - and a challenge I guess for the RMCAT WG.
> 
> (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