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

[Colin Perkins <[e-mail]>]

On 2 Dec 2010, at 15:40, Van Caenegem, Tom (Tom) wrote:
> Magnus, Colin,
> 
> -On using the RTCP FB message format, yes or no: 
> We do allow that for higher "security", the tokens may have to be requested/refreshed very often. Ultimately, that may come down to having the client requesting a new token with the portmapping request message prior to sending e.g. a RAMS-R (e.g. with every channel change). In that case, we do want the messages to be sent out as fast as possible, and hence RFC4585 seems appropriate (similar as we did for RAMS).

It's fine to use the RTP/AVPF timing rules, but the packet formats don't seem appropriate (similarly, they weren't the right choice for RAMS). We should really consider defining new packet formats here, rather than trying to kludge this into the feedback packet formats.

Colin



> -On which messages need tokens. 
> I have not a strong opinion here. I hinted Ali to use as selection criterium: any RTCP FB message that is issued by a receiver to a server, where the reception of that RTCP message is expected to result in unicast RTP packet(s) transmission from that server to that receiver 
> 
> Including the "bye" -for the unicats session- would let it go beyond RTCP FB messages, and would also include messages that stop the ongoing transmission of RTP packets. That is OK for me. But I am not sure on the "report" messages. Does this include RR?
> Related to this discussion, I think it would make sense that when the sender receives a RTCP message that requires a token verification company message, but which is missing, the server then responds with a port mapping response message indicating invalid/missing token.
> 
> Tom
> 
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Magnus Westerlund
> Sent: donderdag 2 december 2010 14:59
> To: Ali C. Begen (abegen)
> Cc: Colin Perkins; IETF AVT WG
> Subject: Re: [AVT] draft-ietf-avt-ports-for-ucast-mcast-rtp-04: Review Comments [csp]
> 
> Hi,
> 
> My views on some of these comments
> 
> Ali C. Begen (abegen) skrev 2010-12-02 02:56:
> 
>>> - 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
>> 
>> Yes, reworded as requested.
>> 
>>> 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?
>> 
>> Not sure why we would need this.
> 
> I think this is actually an interesting aspect of this. The draft seems to be missing text on the issues of re-using a unicast session for another usage. And here I think there are several aspects of this.
> - Reusing a unicast session for different type of RTCP requests (which may work
> - Reusing a unicast session for different multimedia session, which I think implies having them share the FTap.
> - Reuse over time of the port for different services. (which is the one I think Colin was going after).
> 
> 
>> 
>>> - 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)?
>> 
>> We did not do this for RAMS-R, either. I am not very keen on changing this at this stage. Does anybody feel strong about this?
>> 
> 
> I didn't want to change the messages to much, but I do agree that a new RTCP message type would likely be cleaner. Especially considering that none of the SSRC information in the feedback message seems to make sense in any of the case.
> 
>>> - 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.
>> 
>> Nope, it does not. Changed it to 56.
> 
> 
> 
>> 
>>> - 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?
>> 
>> I don't think BYE messages need a Token. NACKs, RAMS-R and RAMS-T require Tokens.
>> 
> 
> Ali, don't BYE also need it at least in the RAMS case? There a BYE message stops all bursts.
> 
> I would say anyone that has any type of control function.
> 
>> There could be some future packet formats or message types that might require a Token. How could we word this better? Any ideas?
> 
> I would divide them up into 3 categories:
> 
> 1. The ones that needs a special unicast session to work.
> - NACK
> - RAMS-R
> 
> 2. Control messages that could use the verification that they are comming from whom we previously has communicated with at this IP address.
> - CCM messages
> - RTCP Bye
> 
> 3. Reports etc that no direct impact, although secondary impact can be present.
> 
> I do note that stronger source authentication mechanisms should be considered in all these cases.
> 
> 
> -- 
> 
> Magnus Westerlund
> 
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB                | Phone  [phone]
> Färögatan 6                | Mobile [phone]
> SE-164 80 Stockholm, Sweden| mailto: [e-mail]
> ----------------------------------------------------------------------
> _______________________________________________
> Audio/Video Transport Working Group
> [e-mail]
> https://www.ietf.org/mailman/listinfo/avt
> _______________________________________________
> Audio/Video Transport Working Group
> [e-mail]
> https://www.ietf.org/mailman/listinfo/avt



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