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

[Magnus Westerlund <[e-mail]>]

Ali C. Begen (abegen) skrev 2010-12-02 16:24:
> Inline.
> 
>> -----Original Message-----
>> From: Magnus Westerlund [mailto:[e-mail]]
>> Sent: Thursday, December 02, 2010 8:59 AM
>> 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
> 
> This is not a problematic case.

No, I don't expect it to be, unless there is some strange interworking
between the different RTCP messages. But that would be present even
without the dynamically created unicast session.

> 
>> - Reusing a unicast session for different multimedia session, which I
>> think implies having them share the FTap.
> 
> This is not a problematic case, either.

I am not agreeing fully. There need to be some consideration here for
it. Because you need to know which session the incomming UDP data
relates to. For example if one has an ongoing RAMS burst for one channel
and then sends a NACK request or another RAMS request and request to use
the same unicast session it is not obvious that the data is
distinguishable from one channel to the other. Thus clearly
consideration should be done here. like alternating between two
different unicast sessions with RAMS requests to avoid overlap.

>> - Reuse over time of the port for different services. (which is the one
>> I think Colin was going after).
> 
> OK, this is interesting. Lets discuss it. Remember that the PT port (server side) is advertised in the SDP at media or session level.
> 
> If advertised at the media level, PT is the port where the clients (who plan to start that particular unicast session with the server) send their token request message. This is illustrated in the SDP example in the draft.
> 
> If advertised at the session level, PT will be the port for obtaining a Token for any unicast session that is run between the server(s) and clients. Recall that existence of the 'portmapping-req' attribute indicates that a Token is required for all unicast sessions. Note that different unicast session may have different server addresses, the attribute above only indicates the common port for them.
> 

Yes, I agree that all the tools are available for getting things to
work. However, there needs text to point out when a client should use
new local ports to create new unicast sessions to an server. This
becomes more or less important dependent on how much co-locating is
happening on the server side when it comes to the RTCP feedback port.
Preferably none.

I also feel that you are missing the issue with time. If a service exist
for 2 hours on friday between 18-20. Then another service is started at
21.00 on friday and happens to reuse the port numbers, but is actually
another service instance. Then the token from service one may or may not
still be valid depending if service 1 and 2 share token generator and
key or not.

In this case it would be best if the token generation for service one is
set so that the token will not last beyond the service it intends to
service.

There is also a security perspective, if one expect clients to be of a
non all ways on kind, then a particular IP address may first used by
host A and later by host B. Thus potentially allowing A to DoS host B
unless the token is short lived. But I think I brought this up otherwise.

Cheers

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