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

["Ali C. Begen (abegen)" <[e-mail]>]

As usual thanks for the detailed comments. I tried to give a good answer or response to each of the comments. However, I think some of the comments you made do not belong to this spec since they are related to behavior of general RTP and RTCP. See inline.

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Magnus Westerlund
> Sent: Tuesday, December 14, 2010 8:43 AM
> To: IETF AVT WG; [e-mail]
> Subject: [AVT] Review of draft-ietf-avt-ports-for-ucast-mcast-rtp-08
> 
> Hi,
> 
> I have re-read the whole of the draft and have the following question,
> comments or suggestions for improvements. I would say that we are fare
> from done. Having had the opportunity to think about this has raised a
> number of questions when considering this port mapping in the wider
> scope as a general RTP extension.
> 
> 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.
 
> 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". 
 
> 3. Structure of section 3.
> 
> I think some clean up of the structure is needed. The following
> structural issues I have detected.
> 
> - 3.2 Says Unicast Session Establishment, despite that 3.2.2 contains
> steps (see step 3) that matches 3.1, like step 3.

We can fix this.
 
> - 3.2.2 appears to missplace and would make more sense as 3.3. That way
> 3.2 could be more focused on the establishment of the unicast session.
> 
> - I also wonder if the example in 3.2.1 shouldn't be part of an
> introductory case.
> 
> - In general I think I would like to skip this description based on an
> example and more focus on the core pieces of the technology. Thus having
> a description of that rather than the example. I think it to a certain
> degree is taken up aspects that aren't needed.

We will check this part again, however, a number of people including myself find such introductory examples fairly useful to put everything into a context. 

It had some normative/informative parts mixed up (Colin's earlier comments) but the recent version does a decent job to explain the steps.
 
> 4. Figure 2: Can you please move up the NAT text so that it doesn't say
> "NA-T"

Done.

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

> 
> 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).
 
> 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.
 
> 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.
 
> 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.
 
> 
> 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.
 
> 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.
 
> 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.
 
> 
> 
> 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.

> 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?
 
> 10. Section 4: Why does the fields for the messages say that they are
> mandatory when none is optional to include?

We can delete the "mandatory" words.
 
> 11. Section 4.2:
>    o  Token Element (Variable size):  Mandatory element that is used to
>       carry the Token generated by the server.  This element is a
>       Length-Value element.  The Length field, which is 8 bits,
>       indicates the length (in octets) of the Value field that follows
>       the Length field.  The Value field carries the Token (or more
>       accurately, the output of the encoding process on the server).
> 
> I am missing a discussion about the 32-bit word aligment requirement
> that RTCP messages has. This needs to be ensured and currently it
> appears that the token is the only one that has variable length. Thus I
> think it needs a requirement on being 32-bit aligned.

Good point.
 
> 12. Section 4.2:
>    o  Token Element (Variable size):  Mandatory element that is used to
>       carry the Token generated by the server.  This element is a
>       Length-Value element.  The Length field, which is 8 bits,
>       indicates the length (in octets) of the Value field that follows
>       the Length field.  The Value field carries the Token (or more
>       accurately, the output of the encoding process on the server).
> 
> I don't think there is need for a length field in this field. One can
> use the RTCP message length field to derive the length of this field.

Since we plan to use padding, it is better to be explicit.
 
> 13. Section 4.3:
> 
> I think the below text should be its own subsection somewhere.
> 
> Currently, the following RTCP messages are REQUIRED to be accompanied
>    by a Token Verification Request message:
> 
>    o  Messages that trigger a new unicast session:
> 
>       *  NACK messages [RFC4585]
> 
>       *  RAMS-R messages [I-D.ietf-avt-rapid-acquisition-for-rtp]
> 
>    o  Messages that control an existing unicast session associated with
>       a multicast session:
> 
>       *  BYE messages [RFC3550]
> 
>       *  RAMS-T messages [I-D.ietf-avt-rapid-acquisition-for-rtp]
> 
>       *  CCM messages [RFC5104]
> 
>    Other RTCP messages defined in the future, which could be abused to
>    cause packet amplification attacks, SHOULD also be authenticated
>    using the mechanism described in this document.  The Token
>    Verification Request message might also be bundled with packets
>    carrying RTCP receiver or extended reports.  While such packets do
>    not have a strong security impact, a specific application might
>    desire to have a more controlled reporting scheme from the clients.

Ok.
 
> 14. Section 4.3:
> 
>    Other RTCP messages defined in the future, which could be abused to
>    cause packet amplification attacks *, SHOULD also be authenticated
>    using the mechanism described in this document.
> 
> at the * I think one should include "other types of denial of service
> attacks"

Sounds good.
 
> 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. 
 
> 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.

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

>         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.
 
> 16. RTCP bandwidth used for Token requests?
> 
> How does one signal the RTCP bandwidth used for controlling how often
> one is allowed to send the Token Requests?

See the text just before section 4.1. 
 
> 17. Section 8:
> 
> If you have an discussion of address pooling NATs I think the mentioning
> on the on-path attacks that is possible should also be mentioned.

Is this something different the ones already in section 9.1? I think the last sentence in the 1st paragraph is what you are looking for.
 
> 18. Section 9.1:
> 
> The Token, which is generated based on a client's IP address and
>    expiration date, provides protection against denial-of-service (DoS)
>    attacks.
> 
> To be correct I think one should add "off-path" before denial-of-service.

OK.
 
> 19.Section 10.3:
> 
> This registry
>    is to be managed by the IANA according to the Specification Required
>    policy of [RFC5226].
> 
> I wonder if this is the correct policy for this. I would like to have
> some sanity checking proposals in this area. I would either say:
> 
> Expert review with a restriction that any registration request must have
> a specification.
> 
> or
> 
> IETF Review

This is fine with me.
 
> 20. Section 10.3, the table seems to have spurious tab for 5-30.

Looks like IANA uses "Unassigned". I will change this accordingly.

-acbegen