[Dart] HTA's Last Call review - drart-dscp-rtp-02

[Harald Alvestrand <[e-mail]>]

*

Last Call review - drat-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”.


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….)


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


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.


Agree that the UDP stream is not unidirectional.


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.


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.


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.


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


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.


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.


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.


6. Guidelines


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


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.


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.



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

*





















*


-- 
Surveillance is pervasive. Go Dark.