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

[Magnus Westerlund <[e-mail]>]

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]
----------------------------------------------------------------------