Re: [AVT] I-D Action:draft-ietf-avt-ports-for-ucast-mcast-rtp-06.txt

[Colin Perkins <[e-mail]>]

Hi Ali,

On 10 Dec 2010, at 03:49, Ali C. Begen (abegen) wrote:
> Hi Colin,
> 
>> This update addresses most of my concerns with the -04 version of the draft. The remaining issues are:
>> 
>>> - 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?
>> 
>> The first half of this has been addressed, thanks. I didn't spot anything warning that the server port shouldn't be reused when
>> there are unexpired token outstanding: did I just miss it, or is this not important?
> 
> The unexpired (outstanding) tokens are not important for the server-side ports.
> 
>>> - 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.
>> 
>> While Section 3.2 has been split into two parts, I believe this is still an open issue. The new text at the start of Section 3.2.1 is
>> clear, but Section 3.2.2 still normatively refers to the example scenario. I think this port mapping scheme is more generally
>> useful than just in RAMS-like scenarios, so I'd encourage Section 3.2.2 to be updated to be much more generally applicable.
>> The basic normative description of the extensions is included on the last half of page 9 ("The following steps summarise the
>> Token-based solution:") and page 10; page 8 and the first half of page 9 focus on the RAMS example and, while they may be
>> normative for that use case, they aren't necessary for the protocol description.
> 
> OK, I will give another shot. Let me know if -07 version looks good (submitted soon).

That's a lot better. I would still clarify in the introduction to section 3.2.2 “are not specific to that particular example” -> “are not specific to that particular example, and can be applied to any scenario where analogous ports can be identified” or similar.

Colin




>>> - 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).
>> 
>> The text to address this, in Section 4, is good. One addition might be to mandate that the server MUST be prepared to handle
>> duplicate requests and MUST generate the same token in response to a duplicate request, and that the client MUST ignore
>> duplicate responses, to get consistency in how this is handled.
> 
> The server does not really keep any state about the earlier requests. Which means, when a client repeats the request (assuming it will use the same random number and its IP will not change), the server still may not produce the same token since the server could be advancing the expiration time based on the request's arrival time. I don't see a reason why this would be a problem. From operational viewpoint, both are valid tokens. If the client somehow gets two Token responses (which are probably different), it could discard the one expiring sooner, or the other. Does not matter IMO.
> 
>>> - 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)?
>> 
>> I still believe it would be appropriate to define new RTCP packet types to convey this information, rather than trying to
>> shoehorn these into transport layer feedback packets.
> 
> This is duly noted. However, I respectfully have to say that we did not do this for RAMS and making such a big change at this stage does not seem like a good idea to me. We are bending some rules but I think we are within a reasonable margin :)
> 
> Thanks.
> -acbegen
> 
>> Cheers,
>> Colin
>> 
>> 
>> --
>> Colin Perkins
>> http://csperkins.org/
>> 
>> 
> 
> _______________________________________________
> Audio/Video Transport Working Group
> [e-mail]
> https://www.ietf.org/mailman/listinfo/avt



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