Re: [AVT] draft-ietf-avt-ports-for-ucast-mcast-rtp-04: Review Comments [csp]

[Colin Perkins <[e-mail]>]

On 1 Dec 2010, at 14:46, DRAGE, Keith (Keith) wrote:
> (As WG chair)
...
> Members of the WG, please chime in - we'd like to get these closed and issue a new version of the draft by the 10th.


In general, I support this approach to port mapping, but there are a number of details that I believe need to be resolved in the draft.

- Introduction, 1st paragraph: suggest clarifying that the ports "are a shared resource that is defined declaratively"?

- Section 3.2, 1st paragraph, begins "We illustrate the second step with an example", but it's not clear what is "the second step" being referred to here.

- Section 3.2 is written as an example, but uses RFC 2119 language, and contains many normative requirements. I would suggest that Section 3 be split into two Sections: one giving the motivating example, and another giving normative requirements for use of the port mapping extensions to RTCP.

- Section 3.2, 1st bullet point on page 8 ("Port P3 denotes..."): the draft should clarify that the client may send any type of RTCP packet to the feedback target, any not just RTCP feedback messages, receiver, and extended reports. 

- Section 3.2, 3rd bullet on page 8, sub-point 1: it's not clear what is meant by "When the retransmission server sends unicast packets for a long period of time, this can exceed that timeout". Would it be clearer to say "when the gap between retransmission requests (or other traffic sent from client to server) is long, this can exceed that timeout"?

- Section 3.2, 4th bullet on page 8: the discussion of how the token may remain valid for multiple sessions is unclear. It may be clearer to say that the token is valid for that port on the server until its expiration time, irrespective of what that port is used for. Following on from this, would it be appropriate to add a warning that the server port SHOULD NOT be reused for other RTP sessions until the expiration time of the tokens issued?

- Section 3.2, step 4 on page 9: the draft needs to give a normative list of which RTCP packet types require an associated token.

- Section 3.2, step 1-5 on pages 9 and 10: these need to be moved out of the example, into a separate normative section.

- Section 5: The RTCP extensions defined here are exchanged in order to setup a unicast session, rather than to provide feedback on an existing session. Accordingly, it's not clear that they should be sent as RTCP Feedback messages. Would it be appropriate to define new RTCP packet types to convey this information, rather than trying to shoehorn this into transport layer feedback packets (this would also avoid the problem of how to set the SSRCs)?

- Section 5: Does the nonce have to be 64 bits? If a 56 bit nonce were sufficient, the feedback packets could be packed much more efficiently.

- Section 5.3 should give a normative list of which RTCP packet types require the token verification messages. Does the RTCP BYE packet need this?

- Section 5.4: it would be useful to include the nonce from the token that failed in the verification failure message, so the client can match up the failure to the token used.

- Section 5 should discuss timings and failure modes. RTCP is not a timely or reliable protocol. What is the expected behaviour if these messages are lost and/or delayed? (e.g., that's the retransmission behaviour).

- Section 6: is this section normative, or an example of how the server can generate a token? There seems little requirement for it to be normative.

- Section 6: why base-64 encode the output? RTCP is a binary protocol.

- Section 7: it would seem appropriate to always send the verification failure RTCP message, even if another error response has been delivered. 

Cheers,
Colin

-- 
Colin Perkins
http://csperkins.org/