Re: [AVT] Review of draft-ietf-avt-ports-for-ucast-mcast-rtp-08

[Magnus Westerlund <[e-mail]>]

Hi,

I haven't re-reveiew the latest version of document yet. But I do want
to respond to a few issues here. Or try to clarify what I meant.


Ali C. Begen (abegen) skrev 2010-12-14 15:32:
>> 1. Section 3.1: "By default, Tokens are server specific.  However, the
>> client
>>    can use the same Token to communicate with different servers if these
>>    servers are provided with the same secret key and algorithm used to
>>    generate the Token and are at least loosely clock-synchronized."
>>
>> How a client determine this is the case still doesn't appear to be defined.
> 
> The client does not need to know anything besides it is the same address (explicit or implicit from the c line) and the port.
> 
>> My suggestion is that a client determines if it has a valid token based
>> on the port and address of where to send the token request. But this
>> needs to be spelled out somewhere.
> 
> I think this is pretty obvious.

Well, it does affect client implementation and behavior for this. And I
think there is a point to make it clear what is expected to be done. So
that if we find a reason to need to make some adjustments around this,
we can be fairly certain about behavior.

> 
>> 2. Section 3.1:
>> "The
>>    Token becomes invalid if client's public IP address changes or when
>>    the server expires the Token.  In these cases, the client has to
>>    request a new Token."
>>
>> This might be misleading as the client in a number of cases can't
>> determine if an address change happens to them. Thus only determining
>> this when failure happens.
> 
> If you read carefully, the text does not imply that the client knows when its address changes. It simply says "when client's address changes".

Well, it is implied through "In these cases, the client has to request a
new Token." Instead of writing. "If this occurs, then the token will be
invalid and after receiving an error message on a request the client
needs to request a new token".

> 
>> 5. Section 3.2.1: "Ports *c0, *c1 and *c2 " bullet:
>>
>> There is no discussion of if C2 should be equal to C1 or not. I think
> 
> They could be the same as the text says.
> 
>> there might be actually considerations here. This have to do with the
>> binding of the RTCP reports to the unicast session transmission
>> happening P3 -> C1. If that isn't possible then the server doesn't know
> 
> C2 is the port client uses to send the RTCP reports for the unicast session. They go to port P4, which is different than P3. Since P4 cannot be the same as P3, it does not matter what you choose for c2.
> 
>> for which outgoing transmission the reports are for. I think also C3 has
>> to be equal to C2, or the server can't match on anything on transport
>> level. However, if the NAT is not address and port independent mapping
>> also that breaks down due the NAT properties.
> 
> We don’t have a c3 in the figure or text.

Sorry, C2 = C1, and C3 = C2. The issue as I say is that you can't bind
the "burst" or RTX transmission to the RTCP feedback message on those.


> 
>>
>> If one are going to enable to mapp on heuristics then I think the only
>> possibility for the server is to mapp on reported SSRC's and ensure to
>> use unique SSRC identifiers across all unicast RTP session going out
>> from P3.
>>
>> Or have I forgotten something here?
> 
> See my response above and let me know whether it addresses your concerns (which I probably did not get).

Yes, unless you have done something about this I think it something that
needs clarification.

> 
>> 6. Section 3.2.2:
>>
>> I am missing an RTP session definitions. I would like to have something
>> along the following lines included. This I think is the main part of how
>> a unicast session is established.
>>
>> Port mapping starts with a primary RTP session, where the server acting
>> on a port mapping request has an unidirectional flow of RTCP messages
>> from the client port (C1) to the server on a designated port (P3). There
>> MUST be no RTCP traffic related to the primary RTP session being sent
>> from P3 on the server to the client on port (C1).
> 
> This agrees with figure 2.
> 
>>
>> Upon a port mapping request RTCP message in the primary session from the
>> client on local port (C1) to the server port (P3) a new RTP point to
>> point unicast RTP session is created, unless active RTP session within
>> this context already exist. This new session consist of one leg of
>> multiplex RTP and RTCP messages from the Server (P3) to the client (C1).
> 
> Correct.
> 
>> The client to server leg in this unicast RTP session is going from
>> client local port (C2 perhaps C1 if mandated to be equal) to the Server
>> port (P4). The server port for the unicast needs to be signaled to the
>> client.
> 
> Correct.
> 
>>
>> The point I am trying to get across in the above is the need to make it
>> clear what flows of messages are considered to be different RTP sessions.
> 
> This is what we convey with Figure 2. If you look at it, the sessions are properly separated and each session has a number of flows with directions and port numbers clearly identified. It is concrete and clear.
> 
> If further text is needed, we can put additional wording.

Yes, the problem is that you don't spell out which legs are which RTP
sessions. As you do have two, and you don't have the regular symmetric
session. This is important when it comes to using other functionality on
these sessions.

> 
>> Another thing that I think is unclear is when an existing RTP session is
>> reused correctly. Like that a sequence of NACK messages for the same
>> primary RTP session shall of course continue to use the same RTP session.
> 
> Indeed, here we introduce nothing new. The regular RTP rules are still valid. If the session has timed out or was ended by a BYE, it ended. A subsequent NACK will open a new session. Ow, the existing session will continue.

This is far from obvious when you have this functionality. This is new
functionality not previously existing. Before a session was existing and
any request was within that sessions context. Or in certain cases where
multiple sessions exist, the relation between them is clearly stated.

> 
>> A third thing is the connection of the SSRC spaces that happens between
>> these two sessions. That as RTCP response to requests in the primary are
>> going into the unicast sessions packet flow.
>>
>> I have to say that this is starting more and more to trouble me as I
>> peel away the layers of implications. Can I please have a time machine
>> and go back 1.5 years and change things?
> 
> Probably you cannot. However, IMO, you are overthinking things in the sense some of the issues you raise above do not even belong to this spec. The SSRC behavior for example will be defined with the unicast application you are running. It could be RAMS, retransmission, multi-layer video, etc. They define their behavior individually.

Maybe you are correct that this is part of the RAMS, etc specification.
But is an question that needs to be considered. Getting all the quirks
of RTP is not easy, despite now having 10 years of experience with it.
Thus, you need to think through a lot of cases to be certain things
work. When doing that you should document how it is intended to work.
Otherwise we will have issues down the line. But you might be right that
this is an issue that belongs in RAMS and any other mechanism using this
mechanism. But this port mapping do mandate this relation, and thus
should point out this detail.

> 
>>
>> 7. Section 3.2.2, bullet 4:
>>
>> Until a unicast
>>        session is established, neither the server nor the client needs
>>        to send RTCP reports for the unicast session.
>>
>> Well, my question based on this, is when it is considered to not any
>> longer be established. I see two issues around that needs to be made clear.
> 
> Requesting and receiving Tokens does not create the unicast session. That is it.

Correct, but it is this spec that defines how the different legs of the
different RTP sessions exist.

> 
>> 1. How long are the client and server going to send RTCP receiver
>> reports related to the RTP transmissions happening in the session. Are
>> this 5 reporting interval since last RTP traffic in the session, or
>> something else?
> 
> Why define new rules here? This is just another RTP session and is supposed to follow the RTP rules.

Actually this is something new for RAMS/RTX with port mapping. We never
had RTP sessions that was dynamically created from one RTP session. We
always had external signalling that defined when an RTP session could
exist.

> 
>> 2. Secondly, what about RTCP BYE signaling? If either ends has sent
>> this, must the client select a new local port and never send any new
>> requests in the primary that ends up in this unicast session?
> 
> No, why would it mean that? BYE does not have such semantics.
> 

The issue is what is creating this session. It is the combination of a
request needing a unicast session, and the port mapping parts. But we
have completely failed to go into details when a session is terminated.

Yes, BYE's normal semantics is that this SSRC leaves the RTP session
now. So in a context where a request with a certain SSRC leaves a
session, does that imply that the created RTP session goes away?

It is a question, and as I see it a hole in the spec.

>>
>>
>> 8. Section 3.2.2: RTP session question.
>>
>> Are RTP packets in the direction C2->P4 forbidden? Currently there
>> doesn't appear to be any wording on this. Secondly, should it be
>> forbidden? Because I can see there is potential applications that needs
>> a client to server RTP stream, rather than the opposite. And as this is
>> a general RTP tool I think we need to work these questions out.
> 
> Yes, they are forbidden. This was the choice since the beginning. If you need a full bi-directional RTP session on the unicast side, you can do a full offer/answer exchange to set up that session. It does not fit into this context anyway.
> 
> To make this crystal clear, we can say that no rtp traffic must flow from client to server.

Hope this has made clear.

> 
>> 9. Section 4:
>> When a client sends a
>>    Port Mapping Request or Token Verification Request message but it
>>    does not receive a response back from the server (either a Port
>>    Mapping Response or Token Verification Failure message), it MAY
>>    resend its request by following the timer rules defined for RTCP
>>    feedback messages in Section 3.5 of [RFC4585] as a good practice.
>>
>> What are the criteria the client shall use to determine when a packet it
>> sent is lost?
> 
> Seriously? The client is ruled by the timer rules. It has a min waiting time. Then, it can resend or give up. What is there to define here?

Ok, this is serious nitpicking. And in most cases this isn't a problem
becuase the RTCP sending intervall allowed will be longer than the RTT.
But what happens if the one has "unlimited" RTCP bandwidth and can
always send immediately. You still need to wait to request until a time
that is long enough for the RTT + server response time.

> 
>> 15. Section 6:
>> A
>>    client that received a Token Verification Failure message can request
>>    a new Token from the server.
>>
>> I am missing discussion one when there is persistent errors. I think
>> there should be some recommendation about exponentially backing off ones
>> tries to retrieve a new token and then use it.
> 
> Would not 4585 scheduling algorithms take care of this? This is not different than sending broken NACKs for example.

Not really. The 4585 scheduling algorithm allows one to reschedule the
same NACK for every transmission and never give up. For knowing expected
behavior there is a point of making clear what the behavior here is.

> 
>> One may also need to consider if one after a period should try to
>> retrieve fresh declaration information for the service one tries to
>> access to see if the error is there?
> 
> If a server has given me a token valid for the next 12 hours, I can use it for the next 12 hours. If the service gets disabled in the mean time say after 6 hours, I will eventually get an error. So what? I can try to get a new token. Or, as you suggest I can be conservative and check with the server every hour to see whether I can get a valid token (because if the service got disabled, I won't get a valid token). This behavior is something up to the implementation. Either is fine and has pros/cons for different scenarios.
> 

That is not what I am saying. I asking for the service declartion, like
SDP or XML. Basically saying that is you have a persistent error at this
part, you better pop up to the application layer and have them check
their information.

> 
>> 15. Section 7.1:
>>
>> If used at a media level, the attribute MUST be used in a unicast
>>    media block.
>>
>> I think this sentence should go. Because this is in conflict with the
>> current semantics. I think it is better to include the a=portmapping-req
>> attribute at the places where one needs to send token verification
>> requests in RTCP. Rather than consider this to be derived implicitly.
> 
> It is already gone since we currently switched to media-level attributes only. And the text simply says "The 'portmapping-req' attribute SHALL be used as a media-level attribute."
> 
> 
>> This would make the SDP example in Figure 7 look like this:
>>
>>        v=0
>>         o=ali 1122334455 1122334466 IN IP4 nack.example.com
>>         s=Local Retransmissions
>>         t=0 0
>>         a=group:FID 1 2
>>         a=rtcp-unicast:rsi
>>         m=video 41000 RTP/AVPF 98
>>         i=Multicast Stream
>>         c=IN IP4 233.252.0.2/255
>>         a=source-filter:incl IN IP4 233.252.0.2 198.51.100.1   ; Note 1
>>         a=rtpmap:98 MP2T/90000
>>         a=multicast-rtcp:41500                                 ; Note 1
>>         a=rtcp:42000 IN IP4 192.0.2.1                          ; Note 2
>>         a=rtcp-fb:98 nack                                      ; Note 2
>>         a=portmapping-req:30000                                ; Note 6
> 
> As I explained a few times before, putting this attribute here is a mistake. It needs to be in the unicast session associated with the multicast session.
> 

I still strongly disagree on this.

>>         a=mid:1
>>         m=video 42000 RTP/AVPF 99                              ; Note 3
>>         i=Unicast Retransmission Stream
>>         c=IN IP4 192.0.2.1
>>         a=sendonly
>>         a=rtpmap:99 rtx/90000
>>         a=rtcp-mux                                             ; Note 4
>>         a=rtcp:42500                                           ; Note 5
>>         a=fmtp:99 apt=98; rtx-time=5000
>>         a=portmapping-req:30000                                ; Note 7
>>         a=mid:2
>>
>> The line with Note 7 would only be needed if we actually use RTCP bye in
>> the nack context to kill of the unicast session. Otherwise I don't think
>> it is needed here in Nack. But if the unicast session was for RAMS, then
>> it would be needed.
> 
> I respectfully disagree that the attribute will be repeated in the multicast block. It does not make sense.

No, I think it makes total sense to indicate the RTP sessions and there
corresponding RTCP flows where you will need a token for submitting some
requests. Rather than placing it in the m= for an RTP session where you
don't needed, only need a token to create this session.

I guess this is different views on how one should signal this. I will
review draft-11 now and see if you then made the definition distinct
enough that it is clear when the attribute should be used.

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