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

Harald,

Thank you for all the editorial nits and other readability suggestions.  I'll incorporate those as I make a readability pass through the document.  I agree that a paragraph around the impact of packet re-ordering on RTCWEB would be useful and I can work on something using your bullets as a base.

I will leave responses to your other points to members of the author team who are more knowledgable in those areas than I.

Thanks,
Dan

--
Dan York
Senior Content Strategist, Internet Society
york@isoc.org<mailto:york@isoc.org>   +1-802-735-1624
Jabber: york@jabber.isoc.org<mailto:york@jabber.isoc.org>
Skype: danyork   http://twitter.com/danyork

http://www.internetsociety.org/deploy360/

On Jun 12, 2014, at 8:49 AM, Harald Alvestrand <harald@alvestrand.no<mailto:harald@alvestrand.no>>
 wrote:

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
Dart@ietf.org<mailto:Dart@ietf.org>
https://www.ietf.org/mailman/listinfo/dart