Subject: [AVT] Comments/questions on port mapping proposal

From: "VAN CAENEGEM Tom" <[email-masked]>
Date: Mon, 5 Oct 2009 17:08:51 +0200

Hi Ali and Bill,

I would like to receive some more background/education on the proposal
on port mapping between unicast and multicast RTP sessions.
(http://tools.ietf.org/html/draft-begen-avt-ports-for-ucast-mcast-rtp-00
)
I listed some questions/comments:

1) What is the real benefit of working with cookies in this case? The
cookie basically informs the unicast server (or RS) to which destination
transport address  the RTP packets and RTCP packets in the
retransmission session should be sent, when the RR issues a NACK or
RAMS-R. Why can't this information be sent by the RR as the set of
RTP/RTCP port numbers, as described in one of your previous proposal ? 

2) The proposal defines that the RR is sending an RTCP message (port
mapping request) to the RTP port of the RS in the retransmission session
. Intrinsically RTP retransmission sessions/streams in combination with
ssm  - the way they are defined in RAMS- are unidirectional (recv-only
from RR point of view). So, this seems contradicting.

3) Does the cookie-lifetime span different RTP SSM sessions? The draft
says  : "Note that each distinct 5-tuple would have its own
       cookie, meaning that the client needs to repeat this process for
each RS, P3, P4, *c1 and *c2 combination."

So, in the case that only the SSRC of media sender changes, or P1 or P2
changes, when the RR joins a new ssm but  RS,P3,P4,c1 and c2 remain the
same, should a new cookie be requested/generated?

4) Specifically for RAMS use case, the first interactions in the
retransmission session for requesting and receiving the cookie, before
the RAMS-R can be sent, will impact the response time (time elapsed
before receiving the burst). From that point of view, sending  the port
mapping request  together with the RAMS-R or first NACK message (as
single compound RTCP message) in the primary multicast session to the
announced rtcp port (port P2 in the example) would be preferred. If a
cookie needs to be generated by the RS for the sake of further
interactions, this can be sent in a port-mapping response RTCP message
in the unicast (retransmission) session, e.g. along with the RTP
retransmission packet or burst, or along with another RTCP message like
RAMS-I.
IMO, the port mapping request and port mapping response messages can be
sent in the two different sessions especially for the considered use
cases .

5) If a cookie is to be requested/generated, IMO there should be a
single cookie instance, not one separate for RTP and one for RTCP ports,
which seems to be the case in the proposal. The RS than maps a received
cookie into the right port depending on whether an RTP packet or RTCP
message is transmitted to the RR in the retransmissions session. 

6) In the figure 3 there seem to be some mistakes: 
-I would expect the RTCP NACK to be sent to P2 instead of P3
-Not sure about the last cookie exchange.. Here the RTCP message (with
cookie) is exchanged in the retransmission session... So, the cookies
can be transmitted by the RR both in the ssm session (as with NACK) as
in the retransmission session?

Regards
Tom

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Tue, 13 Oct 2009 08:06:20 -0700

Hi Tom,

(I am bcc'ing mmusic as it is related).

Thanks for reviewing the spec. Sorry for the delay as we discussed a few things before we responded. You certainly asked the right questions and please see inline for the responses. Also, when reading the email, refer to the revised version. Hopefully, this revision will fix most of the issues.

http://tools.ietf.org/html/draft-begen-avt-ports-for-ucast-mcast-rtp-01

> 1) What is the real benefit of working with cookies in this case? The cookie basically
> informs the unicast server (or RS) to which destination transport address  the RTP packets
> and RTCP packets in the retransmission session should be sent, when the RR issues a NACK
> or RAMS-R. Why can't this information be sent by the RR as the set of RTP/RTCP port
> numbers, as described in one of your previous proposal ?

Good question, simple answer from AVT.

RTCP is not supposed to explicitly carry transport address information. By using cookies, we allow the server to convey IPV4/IPV6 addressing methods. An opaque cookie is used so that the client can't muddle with the data, and so that the intervening devices are not tempted to implement an ALG.

> 2) The proposal defines that the RR is sending an RTCP message (port mapping request) to
> the RTP port of the RS in the retransmission session . Intrinsically RTP retransmission
> sessions/streams in combination with ssm  - the way they are defined in RAMS- are
> unidirectional (recv-only from RR point of view). So, this seems contradicting.

The server needs to multiplex RTP and RTCP on the same port (P3 and P4). And client's sending an RTCP message to that port will be legal in that case.
 
> 3) Does the cookie-lifetime span different RTP SSM sessions? The draft says  : "Note that
> each distinct 5-tuple would have its own
>        cookie, meaning that the client needs to repeat this process for each RS, P3, P4,
> *c1 and *c2 combination."
> 
> So, in the case that only the SSRC of media sender changes, or P1 or P2 changes, when the
> RR joins a new ssm but  RS,P3,P4,c1 and c2 remain the same, should a new cookie be
> requested/generated?

It does not have to since p1/p2/ssrc don't impose anything on the cookie. If you need to have a new binding, you need a new cookie. If there is no need for a new binding, there is no need for a new cookie.

> 4) Specifically for RAMS use case, the first interactions in the retransmission session
> for requesting and receiving the cookie, before the RAMS-R can be sent, will impact the
> response time (time elapsed before receiving the burst). From that point of view, sending
> the port mapping request  together with the RAMS-R or first NACK message (as single
> compound RTCP message) in the primary multicast session to the announced rtcp port (port
> P2 in the example) would be preferred. If a cookie needs to be generated by the RS for the
> sake of further interactions, this can be sent in a port-mapping response RTCP message in
> the unicast (retransmission) session, e.g. along with the RTP retransmission packet or
> burst, or along with another RTCP message like RAMS-I.

RAMS-R/NACK (or any other feedback for the primary session) goes to port P2 on the server. But, the cookie request goes to port P3 on the server. Thus, they cannot be bundled in a compound packet.

Can we mux P2 and P3 on the server? I don't think we can. If we do that, the receiver reports for the SSM and unicast sessions will be mixed in the feedback target (since we are using session multiplexing).

There are two cases here, depending on whether the client muxes its RTP/RTCP on the same port or not.

If not muxing (c1 != c2): 

The client needs two cookies. Both cookie request messages go to port P3 on the server but one is sent from port c1 and the other one is sent from port c2. The server generates the cookies and sends the cookies back to the client. 

There are three new editor's notes about this step in the revision (section 4.2). Comments?

Assuming muxing is not available on the client (one can argue that not all clients are supporting muxing), both cookies need to be received by the client before an RAMS-R message can be sent to the server port P2 since RAMS-R message needs to include both cookies, one for the RTCP (e.g., RAMS-I) traffic and one for the RTP traffic (e.g., burst). Ow, the server would not know where to send the RTCP and RTP traffic. This means additional delay. In case of NACK, the cookie for the data port (c1) needs to be received before issuing any NACKs and must be included in the RTCP packet carrying the NACK message (see the diagram in the draft). But, unlike RAMS, the initial delay is not big concern here since the client can often get the cookie before needing to send the first NACK.

If muxing (c1=c2):

There is one cookie to be requested from the server. So, this is easier. But, the initial delay for getting the cookie is not eliminated. 

One potential solution to avoid the delay is when a single cookie is valid for all the multicast sessions the client is interested in. This means, the same server address/port is used for all those SSM sessions, and if the client sticks with the same receive ports (c1,c2), it can continue using the same cookie(s). This will eliminate the hassle for getting a new cookie for each new session.

However, one must be careful about this since it requires a strict SSRC management across multiple SSM sessions this server address/port is responsible for. In this case, the only unique identifier in the NACK and RAMS-R messages will be the media source SSRCs. So, one must make sure that each different SSM session does have a unique SSRC. Refer to draft-begen-avt-rams-scenarios-00 for details.

> IMO, the port mapping request and port mapping response messages can be sent in the two
> different sessions especially for the considered use cases .

Not sure what you mean here.
 
> 5) If a cookie is to be requested/generated, IMO there should be a single cookie instance,
> not one separate for RTP and one for RTCP ports, which seems to be the case in the
> proposal. The RS than maps a received cookie into the right port depending on whether an
> RTP packet or RTCP message is transmitted to the RR in the retransmissions session.

Cookie is a "passport" for the client to publish the ports it wants to use. So, it has to be per port. If the client implements muxing, then a single cookie is fine. 

> -I would expect the RTCP NACK to be sent to P2 instead of P3

Yes, NACK/RAMS-R goes to P2. Good catch. But, the cookie request still goes to P3.

> -Not sure about the last cookie exchange.. Here the RTCP message (with cookie) is
> exchanged in the retransmission session… So, the cookies can be transmitted by the RR both
> in the ssm session (as with NACK) as in the retransmission session?

I am not sure which one you are referring to. But, if you are referring to the bundled cookie when sending the RTCP (receiver) reports for the unicast session, yeah, I don't think we need to include the cookie. See the new revised figure.

For the sender reports in the unicast session (the last transaction in the figure), how should the server know if the client is using any custom port for rtcp? The figure correctly shows that these reports are sent to port c2, but this would require the server to "remember" this custom port for this client. Comments?

-acbegen