Re: [Dart] Commentary on draft-york-00

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

Harald,

Many thanks for the review and commentary, especially for the discussion
of real time traffic sensitivity to reordering.  This note is an attempt
to pick up non-editorial items that haven't been dealt with in other
messages on the list. I see four of them:

[1]
> 2.2 Diffserv PHBs
> 
> do you want to mention what the difference between the 4 AF classes is?
> Is it just isolation, or is there a ranking between them (in theory or
> in practice)?

Sure, there is a ranking between them.  In general, higher numbered
AF classes are expected to receive better forwarding behavior roughly akin
to higher numbered class selector codepoints being expected to receive
better forwarding behavior.

[2]
> 2.3 Diffserv and transport protocols
> 
> The last paragraph is true but irrelevant - we're not using UDP here,
> we're using other protocols carried inside UDP. And the stuff that's
> carried inside UDP may be sensitive to reordering or may be insensitive
> to reordering - we just can't tell purely from the fact that it's UDP.
> 
> Suggest deleting the paragraph.

I agree with the point, but rather than deleting the paragraph, I'd
suggest expanding it to include discussion of the use of UDP to
encapsulate protocols that are sensitive to reordering.  One of
the reasons for the existence of this paragraph is that it sets up
the allowance for use of multiple PHBs that may cause reordering
within a single UDP 5-tuple.

[3]
> IMPORTANT: There is a huge missing section here - which is about
> sensitivity of real time communications to packet reordering.

I agree, and thank you for the more detailed explanation that can be
used as a starting point to write this section.

[4]
> 2.4 DSCP remarking
> 
> The discussion of token-bucket-based remarkers leaves me a bit confused.
> To me, it's obvious (?) that token-bucket-based remarkers would operate
> in color-blind mode on a network boundary, and in color-sensitive mode
> only when they had assurance that incoming markings were already
> indicating color. Thus, flows from an end-user system should only hit
> color-blind remarkers; the real question is: will a color-blind remarker
> use the incoming DSCP codepoint to decide which of a group of remarking
> treatments it chooses for the packets?

I'm not sure about the "obvious" point - anyone care to comment on what's
actually deployed/configured in practice?

The answer to the final question about choice of remarking treatment is
"yes" although the PHBs in an AF class should receive the same treatment.
The fact that the question was asked suggests that the discussion of
traffic classifiers needs some additional clarity and explanation.

Thanks,
--David

> -----Original Message-----
> From: Dart [mailto:[e-mail]] On Behalf Of Harald Alvestrand
> Sent: Thursday, June 12, 2014 8:49 AM
> To: [e-mail]
> Subject: [Dart] Commentary on draft-york-00
> 
> This message contains running notes made during my initial review of
> draft-york-dart-dscp-rtp-00.
> Apologies for lack of organization; it seems better to get them out soon
> than to polish them.
> 
> 2 Background
> 
> "any one or more modalities" -> "one or more modalities" would read better.
> 
> "RTP defines the mechanism by which real-time data is transmitted" seems
> like an overreach. "RTP defines a common encapsulation format and
> handling rules for real-time data transmitted over the Internet" would
> be more appropriate.
> 
> "With most applications, a single..." - this is true for legacy. It
> seems likely not to remain true.
> 
> The definition of "media flow" needs to be in a "definitions" section.
> It's too important to be hiding in the "background" section - see much
> other mail.
> 
> "SCTP ... can be multiplexed with one or more RTP sessions". Actually we
> can only multiplex SCTP with a single RTP session. There have been
> proposals that would allow multiplexing of multiple RTP sessions (each
> containing multiple media flows) over a single 5-tuple, but these were
> not accepted.
> 
> The mention of MediaStream should be removed from bullet 1. It just
> confuses.
> 
> In bullet 2, only one RTP session can be multiplexed with another
> transport protocol (again).
> 
> The last paragraph is where distinguishing between <some kind of media
> related name> and <RTP packet flow> is very desirable. As it stands now,
> it seems simple, but when you start asking what all these flows "are",
> more precisely, it gets very confusing.
> 
> 2.1 DiffServ
> 
> bullet 1, first list: grammar nit - "classify traffic and setting bits"
> -> "classify traffic and set bits"
> 
> "In this context, "forwarding behavior" is a general - for example" ....
> is a general what, exactly?
> 
> "to allocates resources" -> "to allocate resources"
> 
> Nit: the all-zero DSCP seems to have only five zeroes.
> 
> 2.2 Diffserv PHBs
> 
> do you want to mention what the difference between the 4 AF classes is?
> Is it just isolation, or is there a ranking between them (in theory or
> in practice)?
> 
> 2.3 Diffserv and transport protocols
> 
> The last paragraph is true but irrelevant - we're not using UDP here,
> we're using other protocols carried inside UDP. And the stuff that's
> carried inside UDP may be sensitive to reordering or may be insensitive
> to reordering - we just can't tell purely from the fact that it's UDP.
> 
> Suggest deleting the paragraph.
> 
> IMPORTANT: There is a huge missing section here - which is about
> sensitivity of real time communications to packet reordering.
> 
> I'm not sure how much can be said here, but I think this is quite complex:
> 
> - Packet reordering may lead to spurious NACK generation and unneeded
> retransmission, just as for the data flow case. How sensitive it is to
> that depends on timers.
> 
> - Packet reordering that can be accomodated within an existing jitter
> buffer will not lead to any quality issues.
> 
> - Packet reordering that causes jitter buffers to extend is bad news for
> delay sensitive communication, such as interactive conversations.
> Interactive implementations may choose to discard late data - but this
> is a matter of meeting the deadline, not a matter of whether it's reordered.
> For replay of recorded media, it doesn't matter much.
> 
> - Packet loss is dealt with differently on interactive media than on
> reliable data delivery: Instead of retransmissing all lost data, one
> finds a reference point that new data can be based on, and continues to
> transmit media relative to that. One does not attempt to recover lost
> frames that are history.
> How that affects this discussion ... I'm not too sure.
> 
> 
> 2.4 DSCP remarking
> 
> The discussion of token-bucket-based remarkers leaves me a bit confused.
> To me, it's obvious (?) that token-bucket-based remarkers would operate
> in color-blind mode on a network boundary, and in color-sensitive mode
> only when they had assurance that incoming markings were already
> indicating color. Thus, flows from an end-user system should only hit
> color-blind remarkers; the real question is: will a color-blind remarker
> use the incoming DSCP codepoint to decide which of a group of remarking
> treatments it chooses for the packets?
> 
> It seems to me that the section should tell me, and it doesn't.
> 
> 3 RTP Multiplexing Background
> 
> Repeating the story about "only one RTP session per 5-tuple, please"....
> 
> 4 Recommendations
> 
> As discussed above, the first SHOULD NOT (reordering within a media
> flow) is not sufficiently founded in discussion of media properties.
> Reordering may be a problem, or it may not be a problem.
> 
> I don't see any issues with the other recommendations (the second seems
> like an obvious thing to say, for well documented reasons; the three
> others seem like no-ops from a practical standpoint).
> 
> Thanks for getting this out the door!
> 
> _______________________________________________
> Dart mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dart