Harald,

Thank you for carefully reviewing this draft.  Comments/responses are inline at DLB>.

I’m about to post a -03 version which is not completely done.

Thanks,
--David

From: Dart [mailto:dart-bounces@ietf.org] On Behalf Of Harald Alvestrand
Sent: Friday, August 22, 2014 9:47 AM
To: dart@ietf.org
Subject: [Dart] HTA's Last Call review - drart-dscp-rtp-02


Last Call review - drat-ietf-dart-dscp-rtp-02

http://tools.ietf.org/html/draft-ietf-dart-dscp-rtp-02!<http://tools.ietf.org/html/draft-ietf-dart-dscp-rtp-02>

<http://tools.ietf.org/html/draft-ietf-dart-dscp-rtp-02>



Summary: This document is not ready for IETF Last Call, but close.

The recommendations are reasonable and reasonably argued, but the precision and specificity of the language needs to be tightened up before publication.



The below addresses some specific concerns.



Section 2



nit: “communication in real-time” -> “communication in real time”

nit: The complex example needs to mention that there may be non-media streams; suggest “there may be multiple media and non-media streams”.



DLB> Fixed both.



2.1



Reference to SSRC for reference clock is wrong - “an RTP stream may contain multiple source streams that use the same reference clock (SSRC)” - this should be “clock, identified by the same CNAME”. The SSRC has to be different for each RTP stream in an RTP session. (The naming choice here is confusing….)



DLB> The text refers to a single RTP stream that contains multiple source streams, but only one SSRC.

DLB> Are you sure that this needs to change to CNAME from SSRC?  I’d prefer not to introduce the CNAME

DLB> concept if it’s not necessary.



The section needs to mention that RTP can be carried over a non-datagram protocol such as TCP, but that this document does not say more about this - just to show that its omission is deliberate, not accidental.

(In fact 5.3 discusses TCP-encapsulated RTP. So it’s appropriate to mention it here.)



DLB> Done.



STUN is not an encapsulation protocol, so should be omitted from the “encapsulated via STUN” sentence. TURN is. STUN packets are, however, multiplexed with the RTP packets.



DLB> Agree, see text in separate message.



Agree that the UDP stream is not unidirectional.



DLB> Agree, and picked up Colin’s suggested change here.



2.2



STUN/TURN paragraph sits oddly here. It seems to belong outside the “reasons for multiplexing” flow. Perhaps move it to the beginning of the section?

Again, STUN description needs tuning; STUN is used also for enabling communication without a relay server, by exchanging publicly-visible IP addresses and ports.



DLB> Ok, I see “sits oddly”.  I’ve moved this text into Section 2.1 and adjusted it - see the -03 draft when it’s posted.



4.



“receiving the audio packets ahead of the video is not useful” -> “is not very useful” - the next sentence gives a reason why it is somewhat useful.



DLB> Changed to “significantly ahead” and changed next sentence to be about reliability instead of timing (early).



5.1 Diffserv, Reordering and Transport Protocols



The paragraph “Reordering also affects other forms of congestion control” is wrong. The content is OK, but the intro is not - it is the differential treatment (including drop probability) that creates problems for RMCAT, not (just) the reordering.



DLB> I don’t think so.  If RMCAT can’t cope with a video stream that uses multiple PHBs from an AF class, something is wrong.

DLB> I’ll tag this as an open issue in the draft - could you start a separate thread that includes the RMCAT WG to sort this

DLB> out?



DCCP is sensitive to differential treatment, since it does congestion control, so description of it as “problem free” is wrong.



DLB> Yup, serious thinko by yours truly, see other message on that specific topic for new text.



I think there are considerations coming from reordering (which affect protocols with immediate feedback, such as ACK-based protocols), and there are consdierations from diferential treatment (guessing wrong about what’s affected by a queue). The former applies to TCP; the latter applies to TCP, SCTP, DCCP, and (probably) whatever RMCAT comes to. These two should be separated.



DLB> I’m not sure that I understand what you’re asking for, and I’m not sure whether I agree.  I believe that SCTP is

DLB> TCP-like in being ACK-based, DCCP is covered by text in the other message on that topic, and “whatever RMCAT comes to”

DLB> is speculative (although the draft does have text on Michael Welzl’s concern about coupled congestion controllers that

DLB> don’t use measurements to detect bottlenecks).



DLB> Is there specific text on this topic that can be identified as wrong or misleading and proposed alternative text?



5.2 DiffServ, reordering and real time communication



The last paragraph of the section is somewhat misleading - network packet reordering done for *whatever* reason has no upper bound. If the authors think that packet reordering is more likely to be problematic with different DSCPs than with the same DSCP, that’s what they should say.



DLB> Ok, paragraph now reads:



   Network packet reordering has no effective upper bound, and can exceed the size of any reasonable

   jitter buffer. In practice, the size of jitter buffers for replay is limited by external factors

   such as the amount of time that a human is willing to wait for replay to start.  Use of different

   DSCPs that allow reordering is more likely to cause reordering problems than use of a single DSCP

   or set of DSCPs that does not allow reordering.



The reference to RTCP multi-stream optimization seems completely wrong. The grouping into RTCP reporting groups is about receiver SSRCs that see the same set of packets, not about grouping reports about different SSRC together. (unless I’ve misunderstood something). When not using multi-stream optimization, these SSRCs send duplicate reports.



DLB> The DART draft text does not mention SSRCs, and appears to be consistent with Section 3 and the first paragraph

DLB> of Section 3.1 of draft-ietf-avtcore-rtp-multi-stream-optimisation-03.  The point is that any use of different DSCPs

DLB> for different RTP streams breaks the (twice-stated) requirement in that AVTCORE draft for an identical view of the

DLB> network conditions” across the RTP streams involved, each of which has its own SSRC.



DLB> I don’t think the current DART draft text is actually wrong, but I’d welcome editing suggestions that improve clarity.



6. Guidelines



The word “requirements” seems at odds with the headline “guidelines”.



DLB> Fixed.



The word “session” is used several times without explanation - “RTCP session”, “reliable transport protoocol session”. From context, I guess “flow” or “connection” would be more appropriate.



DLB> RTCP text will be fixed when open issue is resolved on list.



I wonder if the first requirement can be phrased in the positive? For instance:



* Within a single RTP stream, should use a single PHB and DSCP, or a set of PHBs and DSCPs that do not allow reordering, for instance a single AF class.



DLB> Done, Ben also noticed this.



All in all, the document's recommendations are clear and reasonable, but the document can be improved.



DLB> Thank you.















































--

Surveillance is pervasive. Go Dark.