Subject: [AVT] New Version Notification for draft-ietf-avt-ports-for-ucast-mcast-rtp-01

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Mon, 12 Apr 2010 17:17:42 -0700

The new version of the port mapping draft is available at:
http://www.ietf.org/id/draft-ietf-avt-ports-for-ucast-mcast-rtp-01.txt

This version discusses the solution we agreed on during the Anaheim breakout session. While the draft still has a few sections TBC/TBD, the main content is there and we would appreciate your comments on it.

A revision for the RAMS draft is in progress and it will include some editorial fixes and the revision required to fully support port mapping.

Thanks,
-acbegen

-----Original Message-----
From: IETF I-D Submission Tool [mailto:[email-masked]] 
Sent: Monday, April 12, 2010 8:14 PM
To: Ali C. Begen (abegen)
Cc: [email-masked]
Subject: New Version Notification for draft-ietf-avt-ports-for-ucast-mcast-rtp-01 

A new version of I-D, draft-ietf-avt-ports-for-ucast-mcast-rtp-01.txt has been successfully submitted by Ali Begen and posted to the IETF repository.

Filename:	 draft-ietf-avt-ports-for-ucast-mcast-rtp
Revision:	 01
Title:		 Port Mapping Between Unicast and Multicast RTP Sessions
Creation_date:	 2010-04-12
WG ID:		 avt
Number_of_pages: 21

Abstract:
This document presents a port mapping solution that allows RTP
receivers to choose their own receive ports for an auxiliary unicast
session in RTP applications using both unicast and multicast
services.  The solution requires multiplexing RTP and RTCP on a
single port on both endpoints in the unicast session.

The IETF Secretariat.

---

From: "VAN CAENEGEM Tom" <[email-masked]>
Date: Tue, 13 Apr 2010 14:23:20 +0200

Hi Ali, Bill,

I did a 1st read on the new draft. Some 1st comments:

a) The figure 3, which I believe is intended to be a general figure, may
be misleading in the RAMS case, as there will not be any SSM RTP packet
flow prior to the port mapping message exchange. So the possible absence
of the SSM prior to the port mapping messaging should be explicitly
mentioned IMO

If the SSM flow is not present yet, we will probably need to define a
rule on how the RTP receiver needs to fill out the "media sender SSRC"
field in the port mapping FB message (you ask this same question I
believe in the draft). This bears some similarities with what we did for
RAMS-R in the RAMS draft, but is still different. As the SSRC identifier
has no specific meaning here (it is not used or parsed in the port
mapping and cookie generation process), I think it is OK to say that the
RTP receiver puts its own SSRC in this field. This is aligned with what
was specified for RAMS-R.

In the figure 3, the session between burst/retransmission source entity
of the RS and the RTP receiver is established after the NACK (or RAMS-R,
or whatever future app message that will be defined), ....but is the
session not established when the port mapping request is sent out first?
It uses the same transport addresses.

b)You did not define how the cookie is transported from RTP receiver to
the RS (message format?)

c)The main reason why the alternative port mapping without cookie, as
presented in Anaheim, was no longer considered,  is because RTCP
messages sent out by an RTP receiver in the SSM session and RTCP
messages in the unicast RTP (retransmission) session cannot be linked
with one another, when there are multiple receivers behind a NAT. The
same issue is still present here. Solutions are:

-mandating that the "packet sender SSRC" of the RTP receiver is the SSM
session is the same as the "packet sender SSRC" used by the same RTP
receiver in the associated retransmission session. SSRC collisions for
those RTP receivers behind the same NAT can then be resolved with an
RTCP RSI message (to be transmitted by the DS!). BTW, this also causes
the non-cookie approach to work in all circumstances..

-having the cookie sent along with every RTCP message, sent either in
the SSM session (to the FT entity) or in the unicast session. This
actually augments the functionality of the cookie: it is also used as a
unique identifier (in other words it maps one-to-one with an RTP
receiver), and the information hashed in the cookie provides  to the RS
the transport address for the unicast (retransmission) session RTP/RTCP
packets, when the received RTCP message triggers the RS in sending
RTP/RTCP packets in this unicast session.

Editorial comments:

1) In the figure 2, it would be better to include the FT and
Burst/Retransmission Source sub-entities, as part of the Retransmission
server (RS). I understand the figure/example is about retransmissions,
but the RAMS is the more complex example, where for instance there are
also feedback rtcp reports sent to the Burst Source entity on port P4.
The figure only mentions feedback messages on port P3. This is indeed
true for retransmission, but making the more generic figure that
addresses RAMS as well, would be more informative IMO.

2) section 3:
"Port P3 denotes the RTCP port on the feedback target running on
      the retransmission server to collect the RTCP feedback messages,
      and RTP receiver and extended reports from the clients in the
      primary multicast session.  Port P3 is defined declaratively."

Typo: ... and RTCP receiver and extended reports..

3) section 3.1

"The client determines its receive port numbers (*c1 and *c2)."

Is the term "receive port" for c1 not strange and confusing as the RTP
receiver does not receive anything on this port, as it only transmits on
this port...

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Ali C. Begen (abegen)
Sent: dinsdag 13 april 2010 2:18
To: [email-masked]
Subject: [AVT] New Version Notification
fordraft-ietf-avt-ports-for-ucast-mcast-rtp-01

This version discusses the solution we agreed on during the Anaheim
breakout session. While the draft still has a few sections TBC/TBD, the
main content is there and we would appreciate your comments on it.

A revision for the RAMS draft is in progress and it will include some
editorial fixes and the revision required to fully support port mapping.

Thanks,
-acbegen

-----Original Message-----
From: IETF I-D Submission Tool [mailto:[email-masked]]
Sent: Monday, April 12, 2010 8:14 PM
To: Ali C. Begen (abegen)
Cc: [email-masked]
Subject: New Version Notification for
draft-ietf-avt-ports-for-ucast-mcast-rtp-01 

A new version of I-D, draft-ietf-avt-ports-for-ucast-mcast-rtp-01.txt
has been successfully submitted by Ali Begen and posted to the IETF
repository.

Abstract:

The IETF Secretariat.

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www.ietf.org/mailman/listinfo/avt

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Tue, 13 Apr 2010 06:27:55 -0700

Hi Tom,

Thanks for the quick review.

> of the SSM prior to the port mapping messaging should be explicitly

Good point. Maybe, we should provide two figures? Or just focus on the RAMS scenario since the retransmission is a subset?
 
> was specified for RAMS-R.

The assignment of media sender SSRC in the PM request message is a bit tricky as it was in the RAMS. If there are no objections, we can go with Tom's proposal but what about the retransmission case where the client would know the media sender SSRC before asking for the cookie. Should we still set the media sender SSRC field to client's SSRC?
 
> It uses the same transport addresses.

I believe the session is established upon receiving a nack, rams-r, etc. since the server will not allocate resources before it receives such messages. The previous one is just a cookie request. And at that time, it is not clear when the client will actually use it or not.
 
> b)You did not define how the cookie is transported from RTP receiver to

Yeah, looks like we missed it. Could we use the PMRes format for this? Or, should we define a separate format for this? 
 
> receiver in the associated retransmission session. SSRC collisions for

Actually, I don't see why the client would use different packet sender SSRCs when sending feedback/reports in the SSM session and in the unicast session. Since they are considered different sessions, I do not see a reason to use different values provided that the rtcp ports on the server for the SSM and unicast sessions (P3 and P4) are different.

> the non-cookie approach to work in all circumstances..

If two clients behind the same nat end up using the same SSRC, the CNAMEs can be used to separate the reports. At the end if all fail, the reported values might be wrong but port mapping will should work.
 
> the SSM session (to the FT entity) or in the unicast session. This

This will require every client to get a cookie whether or not they need a unicast session, right? Cookie should be used only if there is a need for a unicast session (meaning that all feedback messages establishing a unicast session (nack/rams-r) need the cookie).

> RTP/RTCP packets in this unicast session.

Using the cookie in RTCP reports might be overkill, don’t you think?

> addresses RAMS as well, would be more informative IMO.

OK.
 
> Typo: ... and RTCP receiver and extended reports..

Will fix.
 
> receiver does not receive anything on this port, as it only transmits on

Good catch, will fix this, too.

-acbegen

---

From: "VAN CAENEGEM Tom" <[email-masked]>
Date: Thu, 15 Apr 2010 14:12:16 +0200

Hi Ali, 

-----Original Message-----
From: Ali C. Begen (abegen) [mailto:[email-masked]] 
Sent: dinsdag 13 april 2010 15:28
To: VAN CAENEGEM Tom; Bill Ver Steeg (versteb); IETF AVT WG
Subject: RE: [AVT] New Version Notification

Hi Tom,

> a) The figure 3, which I believe is intended to be a general figure, 
> may be misleading in the RAMS case, as there will not be any SSM RTP 
> packet flow prior to the port mapping message exchange. So the 
> possible absence of the SSM prior to the port mapping messaging should

> be explicitly mentioned IMO

Good point. Maybe, we should provide two figures? Or just focus on the
RAMS scenario since the retransmission is a subset?

TOM: the figure should be made generic IMO, where you draw both the FT
entity and the Burst/Retransmission Source entity entity as two separate
disjoint vertical lines. Replace "retransmission" with "unicast session
RTP", NACK with FB, etc..

> believe in the draft). This bears some similarities with what we did 
> for RAMS-R in the RAMS draft, but is still different. As the SSRC 
> identifier has no specific meaning here (it is not used or parsed in 
> the port mapping and cookie generation process), I think it is OK to 
> say that the RTP receiver puts its own SSRC in this field. This is 
> aligned with what was specified for RAMS-R.

The assignment of media sender SSRC in the PM request message is a bit
tricky as it was in the RAMS. If there are no objections, we can go with
Tom's proposal but what about the retransmission case where the client
would know the media sender SSRC before asking for the cookie. Should we
still set the media sender SSRC field to client's SSRC?

TOM: we better have a clear single rule here. The SSRCs are not relevant
in the port mapping process (unless I overlook something?). We need to
be clear also on how the media sender SSRC and packet sender SSRC are
set in the port mapping response messages. As opposed to the RAMS-I in a
multi SSRC use case, we need only one port mapping response, but which
media/packet sender SSRC to use when there are multiple SSRCs in the
SSM? The feedback message is not the best format here. Perhaps you need
to define new message format header for port mapping messages, w/o SSRC
fields (but that can still be sent ASAP, as with AVPF profile)
 
> In the figure 3, the session between burst/retransmission source 
> entity of the RS and the RTP receiver is established after the NACK 
> (or RAMS-R, or whatever future app message that will be defined), 
> ....but is the session not established when the port mapping request
is sent out first?
> It uses the same transport addresses.

I believe the session is established upon receiving a nack, rams-r, etc.
since the server will not allocate resources before it receives such
messages. The previous one is just a cookie request. And at that time,
it is not clear when the client will actually use it or not.

TOM: if people agree on this, we need explicit text on this in the port
mapping draft, e.g. the unicast RTO session is establised when the RTP
receivers send the 1st RTCP message to the RS with the cookie . E.g. no
SR should be sent by the RS in the unicast session prior to reception of
this 1st RTCP message.
 
> b)You did not define how the cookie is transported from RTP receiver 
> to the RS (message format?)

Yeah, looks like we missed it. Could we use the PMRes format for this?
Or, should we define a separate format for this? 
 
TOM: one format that fits both PMReq and PMR as well as cookie is
possible IMO.

> -mandating that the "packet sender SSRC" of the RTP receiver is the 
> SSM session is the same as the "packet sender SSRC" used by the same 
> RTP receiver in the associated retransmission session. SSRC collisions

> for

Actually, I don't see why the client would use different packet sender
SSRCs when sending feedback/reports in the SSM session and in the
unicast session. Since they are considered different sessions, I do not
see a reason to use different values provided that the rtcp ports on the
server for the SSM and unicast sessions (P3 and P4) are different.

TOM: they are two different sessions, so an RTP end-point can (and
should) generate a random SSRC value in both sessions (RFC 3550). I
would propose that we mandate the two SSRC values to be the same for
those applications making use of portmapping. 
Q: do you allow P3 and P4 to be the same? This should not be made
possible as it does not allow the RS in a straightforward way to link
the incoming RTCP (RR) with the right session!

> the non-cookie approach to work in all circumstances..

If two clients behind the same nat end up using the same SSRC, the
CNAMEs can be used to separate the reports. At the end if all fail, the
reported values might be wrong but port mapping will should work.
 
> the SSM session (to the FT entity) or in the unicast session. This

This will require every client to get a cookie whether or not they need
a unicast session, right? Cookie should be used only if there is a need
for a unicast session (meaning that all feedback messages establishing a
unicast session (nack/rams-r) need the cookie).

> actually augments the functionality of the cookie: it is also used as 
> a unique identifier (in other words it maps one-to-one with an RTP 
> receiver), and the information hashed in the cookie provides  to the 
> RS the transport address for the unicast (retransmission) session 
> RTP/RTCP packets, when the received RTCP message triggers the RS in 
> sending RTP/RTCP packets in this unicast session.

Using the cookie in RTCP reports might be overkill, don't you think?

TOM: sure, it is not ideal, but you need a way to make sure that the
RTCP reports received in the two sessions can be linked to the same RTP
receiver by the RS. Having same SSRC is the better solution. Making
CNAMES really unique is also an option, but then the FB messages must be
sent as compound RTCP messages.

> Burst/Retransmission Source sub-entities, as part of the 
> Retransmission server (RS). I understand the figure/example is about 
> retransmissions, but the RAMS is the more complex example, where for 
> instance there are also feedback rtcp reports sent to the Burst Source
entity on port P4.

OK.

Will fix.

> receiver does not receive anything on this port, as it only transmits 
> on this port...

-acbegen