Subject: Re: [AVT] comments on section 10 of draft-ietf-avt-rapid-acquisition-for-rtp-01

From: "VAN CAENEGEM Tom" <[email-masked]>
Date: Wed, 17 Jun 2009 10:17:26 +0200

Hi Roni,

I think your understanding was indeed different from the general
assumptions in this draft. Previously we agreed to only consider the
case where there is only one physical entity involved (called the
Retransmission Server in the draft), which allows us to NOT consider and
discuss cases where for instance the feedback target (which is defined
in the rtcpssm draft/RFC) is not in the same box as the retransmission
source or burst source, the entities sourcing retransmision/burst
packets. In that case we then would also need to describe how these
separate entities communicate.  
The fact that these different entities are now in the same box does not
necessarily mean that all interactions and data exchange with the RRs is
part of the same RTP session, which is in this case the SSM RTP session.
As Ali explained, the NACK and RAMS-R RTCP FB messages are directed to
the FB target, where we do not  defer from the rtcpssm draft. The RTP
retransmission/burst packets that are sent as a response to the NACK and
the RAMS-R can be either session multiplexed with respect to the
original SSM RTP session or SSRC muxed (same session), following RFC
4588. As the retransmission packets in this case are addressing the RR
in unicast, we obviously have a dedicated RTP session for the
retransmission/burst packets. We had some internal discussion on whether
considering the use case of having a separate session between RS and RR
for RTP retransmission packets triggered by an RTCP FB NACK and a
separate session for RTP burst packets triggered by an RTCP RAMS-R made
sense, but we ended up agreeing that allowing a single session was the
easiest way out, without imposing serious limitations to the general
architecture. 

This means that the ports used by the (single) RTP retransmission/burst
session are in principle decoupled from the primary SSM session. Hence
if an RR wants to receive the burst/retransmission packets and
associated RTCP messages on the same port the RR sent out the RTCP
RAMS-R/ NACK FB messages, this should either be signaled by the RR, OR
such port usage scheme is considered the "default" case -which also
means the RR supports RTP/RTCP port muxing for the retransmission/burst
session-, and then the RR needs to signal the ports for receiving the
RTP and RTCP packets in the retransmission session when it requires
dedicated ports.  

The RAMS-I (RS-> RR) and RAMS-T (RR-> RS) messages are only relevant to
a specific RR requesting the RTP burst stream and the RS, and carry
information/signaling related to the retransmission/burst session and
have nothing to do with the SSM session. Hence the FB target as logical
entity is not involved here. 

I hope this clarifies rather than it contributes to your confusion. But
we may need to rephrase the part you quoted, as your interpretation was
different from its intended meaning. We also tried to be more explicit
in which session which RAMS or other RTCP (e.g. Bye) messages needed to
be exchanged compared to a previous version of the draft, but we are
open of course to any other suggestions from your side if this is not
clear enough in your opinion.

Tom      

" A Retransmission Source may equally act as a Burst Source.  The
   Retransmission Source may also incorporate the Feedback Target
   ([I-D.ietf-avt-rtcpssm] permits the feedback target to be a
   retransmission server, since it is a logical function to which RRs
   send their unicast feedback), and we will use the term Retransmission
   Server (RS) in the remainder of the document to refer to a single
   physical entity comprising these three entities that share state.
   Note that the same method (with the identical message flows) would
   also apply in a scenario where rapid acquisition is performed by a
   feedback target co-located with the media source."

I assumed that we are only dealing with the case that the RS is a single
entity and not three different entities with different addresses

I also thought that this was agreed in previous discussions

If my understanding is not correct I will review the draft since the
current text is not explicit enough to specify which part is doing each
message. I saw that RAMS-R is going to feedback target but RAMS-T is
going to RS which is not specifying a specific address according to you.

Roni

-----Original Message-----
From: Ali C. Begen (abegen) [mailto:[email-masked]]
Sent: Tuesday, June 16, 2009 10:00 PM
To: Roni Even; [email-masked]
Subject: RE: [AVT] comments on section 10
ofdraft-ietf-avt-rapid-acquisition-for-rtp-01

Remember that the RAMS-R (RR->RS) message is NOT on the retransmission
(unicast) session, it's on the primary session since it is sent to the
feedback target of the primary SSM session. Thus, the source port RR
uses to send RAMS-R "cannot" be assumed to be the destination port it
wishes to receive the unicast burst on.

If you agree with this statement, it is clear why we need port
signaling.
Muxing will not help much here. It will just reduce the number of
signaled ports from 2 to 1.

-acbegen

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of 
> Roni
Even
> Sent: Tuesday, June 16, 2009 10:08 AM
> To: [email-masked]
> Subject: [AVT] comments on section 10
ofdraft-ietf-avt-rapid-acquisition-for-rtp-01
> 
> Hi,
> 
> I looked at section 10 and have some comments
> 
> 
> 
> 1.       If RTP/RTCP multiplexing is used, there is no need for any
specific operation
> from the RR side. The RR sends the RAMS-R message to the RS from the 
> port
it wants to
> receive the RAMS-I and RTP payload. The RS just sends the information 
> to
the port from
> which it received the RAMS-R and not to the one in the SDP
> 
> 2.       In the case where there is no RTP/RTCP multiplexing, the
RAMS-R
RTCP message will
> go to the RS and the RAMS-I will go to the port on the RR from where 
> the
RAMS-R was
> received. For the RTP, the RR does not know if it has a NAT on the way

> to
the RS and
> should try to get a routable address (using STUN for example) and
providing the port to
> the RS ( we still need to agree on how to do it)
> 
> 3.       If the above two points are correct than the RR receive port
in
the SDP is not
> really useful
> Roni Even

---

From: Roni Even <[email-masked]>
Date: Wed, 17 Jun 2009 14:23:37 +0300

Tom,
I understand the RAMS-R and RAMS-T, the text is not clear enough in section
6.2

It still leaves open the issue of the addresses for the RR in the case of
declarative SDP when there is no answer SDP from the RR.

About RTP/RTCP multiplexing, the declarative SDP can show that the RS
supports it and I still think that some information about the addressing
(like support for RTP/RTCP mux) should be supplied in the RAMS-R for the
declarative case.

Roni

> VAN CAENEGEM Tom
> Sent: Wednesday, June 17, 2009 11:17 AM
> To: [email-masked]
> Subject: Re: [AVT] comments on section 10 of draft-ietf-avt-rapid-
> acquisition-for-rtp-01
> 
> Hi Roni,
> 
> 4588. 
>As the retransmission packets in this case are addressing the RR
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

---

From: "VAN CAENEGEM Tom" <[email-masked]>
Date: Wed, 17 Jun 2009 14:23:08 +0200

Hi Roni,

Perhaps the start of section 6.2 can be rewritten as follows:

<START>

6.2.  Message Flows

   Figure 2 shows the main entities involved in rapid acquisition:

   o  Multicast Source

   o  Feedback Target (FT)

   o  Burst/ Retransmission Source

   o  RTP Receiver (RR)

(fig 2)

The feedback target (FT) is the entity as defined in [rtcpssm draft], to
which the RR sends its RTCP FB messages, indicating packet loss in the
ssm primary stream by means of a NACK or indicating the RR's desire to
have rapid acquisition of the ssm primary stream (by means of an RTCP FB
message as defined in this document). While the burst/retransmission
source is responsible for responding on these messages and, in the case
of rapid acquisition, further RTCP interaction with the RR during this
acquisition process, it is assumed in the remainder of the document that
these two logical entities (FT and burst/retransmission source) are
combined in a single physical entity and share state. In the remainder
of the text, the term retransmission server is used whenever
appropriate, to refer to the combined functionality of the FT and
retransmission/burst source. However, it must be noted that only the FT
is involved in the primary ssm RTP session, whereas the
burst/retransmission source transmits unicast RTP burst and RTP
retransmissions packets (both formatted  as RTP retransmission packets
[RFC4585]) in a single separate unicast RTP retransmission session to
each RR.

Note also that the same method (with the identical message flows) would
also apply in a scenario where rapid acquisition is performed by a
feedback target co-located with the media source.

(...)

<END>

Tom: As we mandate the retransmission source and burst source to be in
the same session, I think it is no longer required to split-up among
these two logical entities. I invite other people, including the
co-authors to comment on this new text proposal.

With respect to your comments on the RTP/RTCP port muxing support
indication by the RR inside the RAMS-R message. That would be needed,
but is not sufficient as, if only declarative SDP is used, and we want
to have the possibility that the RTP/RTCP packets in the retransmission
session can be received by the RR on the same port the RR issues the
RTCP RAMS-R, we need also a way by which the RR can signal this too. We
provided a possible solution in the draft, but I understood that you
think such a solution should be proposed in a separate draft proposal?
But I guess that would also apply then to the signaling of support for
RTP/RTCP port muxing by the RR?

Tom

-----Original Message-----
From: Roni Even [mailto:[email-masked]] 
Sent: woensdag 17 juni 2009 13:24
To: VAN CAENEGEM Tom; [email-masked]
Subject: RE: [AVT] comments on section 10

Tom,
I understand the RAMS-R and RAMS-T, the text is not clear enough in
section
6.2

It still leaves open the issue of the addresses for the RR in the case
of declarative SDP when there is no answer SDP from the RR.

Roni

>Retransmission Server in the draft), which allows us to NOT consider  
>and  discuss cases where for instance the feedback target (which is 
>defined  in the rtcpssm draft/RFC) is not in the same box as the 
>retransmission  source or burst source, the entities sourcing 
>retransmision/burst  packets. In that case we then would also need to 
>describe how these  separate entities communicate.
> The fact that these different entities are now in the same box does 
>not  necessarily mean that all interactions and data exchange with the 
>RRs  is  part of the same RTP session, which is in this case the SSM 
>RTP  session.

>retransmission/burst packets that are sent as a response to the NACK  
>and  the RAMS-R can be either session multiplexed with respect to the  
>As the retransmission packets in this case are addressing the RR  in 
>unicast, we obviously have a dedicated RTP session for the  
>retransmission/burst packets. We had some internal discussion on  
>whether  considering the use case of having a separate session between 
>RS and RR  for RTP retransmission packets triggered by an RTCP FB NACK 
>and a  separate session for RTP burst packets triggered by an RTCP 
>RAMS-R made  sense, but we ended up agreeing that allowing a single 
>session was the  easiest way out, without imposing serious limitations 
>to the general  architecture.
> 
> This means that the ports used by the (single) RTP 
> retransmission/burst session are in principle decoupled from the 
> primary SSM session. Hence if an RR wants to receive the 
> burst/retransmission packets and associated RTCP messages on the same 
> port the RR sent out the RTCP RAMS-R/ NACK FB messages, this should 
> either be signaled by the RR, OR such port usage scheme is considered 
> the "default" case -which also means the RR supports RTP/RTCP port 
> muxing for the retransmission/burst session-, and then the RR needs to

> signal the ports for receiving the RTP and RTCP packets in the 
> retransmission session when it requires dedicated ports.
> 
> The RAMS-I (RS-> RR) and RAMS-T (RR-> RS) messages are only relevant 
> to a specific RR requesting the RTP burst stream and the RS, and carry

> have nothing to do with the SSM session. Hence the FB target as 
> logical entity is not involved here.
> 
> I hope this clarifies rather than it contributes to your confusion. 
> But we may need to rephrase the part you quoted, as your 
> interpretation was different from its intended meaning. We also tried 
> to be more explicit in which session which RAMS or other RTCP (e.g. 
> Bye) messages needed to be exchanged compared to a previous version of

> the draft, but we are open of course to any other suggestions from 
> your side if this is not clear enough in your opinion.
> 
> Tom
> 
> 
> 
> 
> 
> 
> I assumed that we are only dealing with the case that the RS is a 
> single entity and not three different entities with different 
> addresses
> 
> current text is not explicit enough to specify which part is doing 
> each message. I saw that RAMS-R is going to feedback target but RAMS-T

> is going to RS which is not specifying a specific address according to

> you.

> > From: [email-masked] [mailto:[email-masked]] On Behalf 
> > Of Roni
> Even

> > port
> it wants to
> > receive the RAMS-I and RTP payload. The RS just sends the 
> > information to
> the port from

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Wed, 17 Jun 2009 07:15:27 -0700

The proposed text looks good to me. We should probably put the burst and retransmission sources in the same block in Figure 2 as well.

-acbegen

> From: [email-masked] [mailto:[email-masked]] On Behalf Of VAN CAENEGEM Tom
> Sent: Wednesday, June 17, 2009 5:23 AM
> Subject: Re: [AVT] comments on section 10ofdraft-ietf-avt-rapid-acquisition-for-rtp-01
> 
> 
>  Hi Roni,
>

---

From: "Bill Ver Steeg (versteb)" <[email-masked]>
Date: Wed, 17 Jun 2009 11:40:00 -0400

Tom-

These words looks good to me as well, with the following clarification. 

We do need to consider how we handle RTP/RTCP port muxing throughout the
document, and make the wording consistent wherever we reference the
ports in use. I am in favor of allowing (but not mandating) the RR to
signal RTP/RTCP port muxing. This would require the RS to support both
methods. This is just my opinion, and we need to come to consensus on
this matter.

Bill VerSteeg

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Ali C. Begen (abegen)
Sent: Wednesday, June 17, 2009 10:15 AM
To: VAN CAENEGEM Tom; Roni Even; [email-masked]
Subject: Re: [AVT] comments on
section10ofdraft-ietf-avt-rapid-acquisition-for-rtp-01

The proposed text looks good to me. We should probably put the burst and
retransmission sources in the same block in Figure 2 as well.

-acbegen

> Subject: Re: [AVT] comments on section 
> 10ofdraft-ietf-avt-rapid-acquisition-for-rtp-01
> 
> 
>  Hi Roni,
> 
> The feedback target (FT) is the entity as defined in [rtcpssm draft], 
> to which the RR sends its RTCP FB messages, indicating packet loss in 
> the ssm primary stream by means of a NACK or indicating the RR's 
> desire to have rapid acquisition of the ssm primary stream (by means 
> of an RTCP FB message as defined in this document). While the 
> burst/retransmission source is responsible for responding on these 
> messages and, in the case of rapid acquisition, further RTCP 
> interaction with the RR during this acquisition process, it is assumed

> in the remainder of the document that these two logical entities (FT 
> and burst/retransmission source) are combined in a single physical 
> entity and share state. In the remainder of the text, the term 
> retransmission server is used whenever appropriate, to refer to the 
> combined functionality of the FT and retransmission/burst source. 
> However, it must be noted that only the FT is involved in the primary 
> ssm RTP session, whereas the burst/retransmission source transmits 
> unicast RTP burst and RTP retransmissions packets (both formatted  as 
> RTP retransmission packets
> Note also that the same method (with the identical message flows) 
> would also apply in a scenario where rapid acquisition is performed by

> a feedback target co-located with the media source.
> 
> (...)
> 
> <END>
> 

> to have the possibility that the RTP/RTCP packets in the 
> retransmission session can be received by the RR on the same port the 
> RR issues the RTCP RAMS-R, we need also a way by which the RR can 
> signal this too. We provided a possible solution in the draft, but I 
> understood that you think such a solution should be proposed in a
separate draft proposal?

> supports it and I still think that some information about the 
> addressing (like support for RTP/RTCP mux) should be supplied in the 
> RAMS-R for the declarative case.
> 
> Roni
> 
> > Of VAN CAENEGEM Tom

> >not  necessarily mean that all interactions and data exchange with 
> >the RRs  is  part of the same RTP session, which is in this case the 
> >SSM RTP  session.

> >whether  considering the use case of having a separate session 
> >between RS and RR  for RTP retransmission packets triggered by an 
> >RTCP FB NACK and a  separate session for RTP burst packets triggered 
> >by an RTCP RAMS-R made  sense, but we ended up agreeing that allowing

> >a single session was the  easiest way out, without imposing serious 
> >limitations to the general  architecture.
> >
> > burst/retransmission packets and associated RTCP messages on the 
> > same port the RR sent out the RTCP RAMS-R/ NACK FB messages, this 
> > should either be signaled by the RR, OR such port usage scheme is 
> > considered the "default" case -which also means the RR supports 
> > RTP/RTCP port muxing for the retransmission/burst session-, and then

> > the RR needs to

> > information/signaling related to the retransmission/burst session 
> > and have nothing to do with the SSM session. Hence the FB target as 
> > interpretation was different from its intended meaning. We also 
> > tried to be more explicit in which session which RAMS or other RTCP
(e.g.

> > uses to send RAMS-R "cannot" be assumed to be the destination port 
> > it wishes to receive the unicast burst on.
> >

---

From: Zeev Vax <[email-masked]>
Date: Wed, 17 Jun 2009 16:44:52 +0000

The text proposal looks fine to me.
I don't think we should mandate support both, this would cause extra work in implementation of a solution, and I can't see any benefit. Giving that this is UDP traffic port muxing is a subset of separate ports, so we can mandate port muxing, and make optional the separate ports.

Zeev

-----Original Message-----
From: Bill Ver Steeg (versteb) [mailto:[email-masked]]
Sent: Wednesday, June 17, 2009 8:40 AM
To: Ali C. Begen (abegen); VAN CAENEGEM Tom; Roni Even; [email-masked]; Zeev Vax
Subject: RE: [AVT] comments on section10ofdraft-ietf-avt-rapid-acquisition-for-rtp-01

Tom-

Bill VerSteeg

-----Original Message-----

-acbegen

separate draft proposal?

(e.g.

---

From: Roni Even <[email-masked]>
Date: Thu, 18 Jun 2009 12:47:17 +0300

Hi Tom,
My comment about the text was more about the steps described later in
section 6.2

In step 2 the RS will send the RAMS-I from the RTCP port for the
burst/retransmission stream. This will help the RR to learn his address

In step 4 - update RAM-R, will it be sent to the FT target or to the
burst/retransmission.

In step 8 - specify where to send the RAMS-T not to the RS but to the
burst/retransmission address. 

As for the RTP/RTCP port multiplexing, I do not think that this is a
separate draft. We need to discuss the solution and decide where to it
should go. If the declarative SDP will include RTP/RTCP mux the RAM-R should
acknowledge that it is supported by the RR.

The need for a separate draft discussion is if the RR wants to offer
different ports for receiving the RTP and RTCP, and this needs to be
discussed. The major question is if we need a general mechanism which
requires a new RTCP message or is it just for this case and we can add the
information to the RAMS messages..

Roni

> From: VAN CAENEGEM Tom [mailto:[email-masked]]
> Sent: Wednesday, June 17, 2009 3:23 PM
> Subject: RE: [AVT] comments on section 10 ofdraft-ietf-avt-rapid-
> acquisition-for-rtp-01
> 
> 
>  Hi Roni,
> 
> addressing

---

From: Roni Even <[email-masked]>
Date: Thu, 18 Jun 2009 12:50:08 +0300

Zeev,
This is a question I had in the past. I think that it merits a separate
thread in order to get a consensus on the issue. Mandating RTP/RTCP
multiplexing for the unicast burst make it simpler and faster to start. 

Note the two ports may still be used for the retransmission case.

Roni

> From: Zeev Vax [mailto:[email-masked]]
> Sent: Wednesday, June 17, 2009 7:45 PM
> To: Bill Ver Steeg (versteb); Ali C. Begen (abegen); VAN CAENEGEM Tom;
> Roni Even; [email-masked]
> I don't think we should mandate support both, this would cause extra
> work in implementation of a solution, and I can't see any benefit.
> Giving that this is UDP traffic port muxing is a subset of separate
> ports, so we can mandate port muxing, and make optional the separate
> ports.
> 
> Zeev
> 
> 
> > > > received. For the RTP, the RR does not know if it has a NAT on
> the
> > > way
> > >
> > > > to
> > > the RS and

---

From: "VAN CAENEGEM Tom" <[email-masked]>
Date: Thu, 18 Jun 2009 13:45:13 +0200

Hi Roni,

I 100% agree with your remarks, and in fact I had proposed additional
text for step 2 and step 8 that clarified which message was sent in
which session and/or to/by whom, but now I notice these clarifying text
fragments seem to have been missed by the main editor in the last draft
release. Bill, can you add these phrases in a subsequent release?

Step 2: 

Add text: "Both the unicast burst and the RAMS-I message are transmitted
by the burst/retransmission source logical entity that is part of the
RS."

Step 8: 

Replace "Note that RR MUST send at least one RAMS-T message" by 

"Note that RR MUST send at least one RAMS-T message, and the RAMS-T
message MUST be addressed to the Burst source logical entity that is
part of the RS."  

On step 4, I took it kind of for granted that, as RAMS-R update messages
are the same as RAMS-R messages, the RAMS-R update message has to be
sent towards the FT... But you are right, that this should be explicitly
mentioned in the draft. One could even argue this message should be sent
to the Burst/Retransmission Source entity  as it services the purpose of
controling the RTP burst (similar as an RAMS-T message), but I would
suggest that this message is addressed to the FT, based on my previous
reasoning. 

So for Step 4,  I'd propose to change the current sentence  "RR MAY send
a new RAMS-R message with a different value for one or more fields of an
earlier RAMS-R message."  to  "RR MAY send a new RAMS-R message to the
FT entity of the RS, with a different value for one or more fields of an
earlier RAMS-R  message."

Tom

-----Original Message-----
From: Roni Even [mailto:[email-masked]] 
Sent: donderdag 18 juni 2009 11:47
To: VAN CAENEGEM Tom; [email-masked]
Subject: RE: [AVT] comments on section 10

Hi Tom,

As for the RTP/RTCP port multiplexing, I do not think that this is a
separate draft. We need to discuss the solution and decide where to it
should go. If the declarative SDP will include RTP/RTCP mux the RAM-R
should acknowledge that it is supported by the RR.

The need for a separate draft discussion is if the RR wants to offer
different ports for receiving the RTP and RTCP, and this needs to be
discussed. The major question is if we need a general mechanism which
requires a new RTCP message or is it just for this case and we can add
the information to the RAMS messages..

Roni

separate draft proposal?

> > the RR needs

(e.g.

> > each message. I saw that RAMS-R is going to feedback target but 
> > RAMS-
> T
>

---

From: "Bill Ver Steeg (versteb)" <[email-masked]>
Date: Thu, 18 Jun 2009 11:18:10 -0400

Tom/Roni-

We need to clarify the text to make the port relationships more clear.
We are still getting reader confusion when considering the relationship
between the ports associated with the primary multicast flow, the ports
associated with the RTCP feedback on the initial flow, and the ports
associated with the acceleration flow.

These proposed words are an improvement. I will start with your new
words and make further clarifications for consideration. I hope to have
some words tonight.

bvs

-----Original Message-----
Sent: Thursday, June 18, 2009 7:45 AM

Hi Roni,

Step 2: 

Step 8: 

Tom

-----Original Message-----
From: Roni Even [mailto:[email-masked]]
Sent: donderdag 18 juni 2009 11:47
To: VAN CAENEGEM Tom; [email-masked]
Subject: RE: [AVT] comments on section 10

Hi Tom,

Roni

separate draft proposal?

(e.g.

---

From: Zeev Vax <[email-masked]>
Date: Thu, 18 Jun 2009 21:26:57 +0000

Roni,

As I said I support mandating the multiplexing, but not the multiple ports. If there are no other opinions, we can add that to draft.

Zeev

-----Original Message-----
From: Roni Even [mailto:[email-masked]]
Sent: Thursday, June 18, 2009 2:50 AM
To: Zeev Vax; 'Bill Ver Steeg (versteb)'; 'Ali C. Begen (abegen)'; 'VAN CAENEGEM Tom'; [email-masked]
Subject: RE: [AVT] comments on section10ofdraft-ietf-avt-rapid-acquisition-for-rtp-01

Zeev,

Roni

> > > RAMS-T

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 18 Jun 2009 14:46:06 -0700

Zeev,

I agree that mandating both is not a good idea. But, you should note that muxing does not solve our issues. So, mandating it will not be the cure for everything. See my email from Tuesday.

-acbegen

> Sent: Thursday, June 18, 2009 2:27 PM
> To: Roni Even; Bill Ver Steeg (versteb); Ali C. Begen (abegen); 'VAN CAENEGEM Tom';
> [email-masked]
> As I said I support mandating the multiplexing, but not the multiple ports. If there are
> no other opinions, we can add that to draft.
> 
> Zeev
>

---

From: Zeev Vax <[email-masked]>
Date: Thu, 18 Jun 2009 21:58:09 +0000

If we assume all entities are one, why would you need to signal the retransmission port separately ?

Zeev

-----Original Message-----
From: Ali C. Begen (abegen) [mailto:[email-masked]]
Sent: Thursday, June 18, 2009 2:46 PM
To: Zeev Vax; Roni Even; Bill Ver Steeg (versteb); VAN CAENEGEM Tom; [email-masked]
Subject: RE: [AVT] comments on section10ofdraft-ietf-avt-rapid-acquisition-for-rtp-01

Zeev,

-acbegen

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 18 Jun 2009 15:06:45 -0700

I will copy/paste from my earlier email:

<quote>
Remember that the RAMS-R (RR->RS) message is NOT on the retransmission (unicast) session, it's on the primary session since it is sent to the feedback target of the primary SSM session. Thus, the source port RR uses to send RAMS-R "cannot" be assumed to be the destination port it wishes to receive the unicast burst on.
</quote>

So, even if muxing is enabled by RR meaning that it can receive RTP and RTCP on the same port, we still need to signal that single port somehow. One way of doing it is PubPorts message (which is by itself an RTCP message and can be appended to the RTCP packet that carries RAMS-R message). And frankly speaking, signaling two ports (RTP + RTCP) is not any more difficult than signaling a single (muxed) port. Thus, IMO we should not be mandating muxing.

-acbegen

> Sent: Thursday, June 18, 2009 2:58 PM
> To: Ali C. Begen (abegen); Roni Even; Bill Ver Steeg (versteb); VAN CAENEGEM Tom;
> [email-masked]
> I agree that mandating both is not a good idea. But, you should note that muxing does not
> solve our issues. So, mandating it will not be the cure for everything. See my email from
> Tuesday.
> 
> -acbegen
>

---

From: Zeev Vax <[email-masked]>
Date: Thu, 18 Jun 2009 22:47:53 +0000

Thanks I read your earlier message before, my point is that if you assume all entities are one, and assume muxing, you can assume the source port the RR use to send the RAMS-R is the same it wishes to receive the burst and control answers.
I.e. - I disagree with your conclusion below
<quote>
Thus, the source port RR uses to send RAMS-R "cannot" be assumed to be the destination port it wishes to receive the unicast burst on.
</quote>

Zeev
-----Original Message-----
From: Ali C. Begen (abegen) [mailto:[email-masked]]
Sent: Thursday, June 18, 2009 3:07 PM
To: Zeev Vax; Roni Even; Bill Ver Steeg (versteb); VAN CAENEGEM Tom; [email-masked]
Subject: RE: [AVT] comments on section10ofdraft-ietf-avt-rapid-acquisition-for-rtp-01

<quote>

-acbegen

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Fri, 19 Jun 2009 15:09:20 -0700

Roni, Tom,

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Roni Even
> Sent: Thursday, June 18, 2009 2:47 AM
> To: 'VAN CAENEGEM Tom'; [email-masked]
> Subject: Re: [AVT] comments on section 10 ofdraft-ietf-avt-rapid-acquisition-for-rtp-01
> 
> Hi Tom,

Does not RR already know the RTCP port and IP of the RS from the SDP? Are you considering a case where e.g., RS is behind a NAT?
 
> In step 4 - update RAM-R, will it be sent to the FT target or to the

Yes, this should be clarified. I agree with Tom that the updated RAMS-R should go to the FT as the first RAMS-R. We will add this to the next version.

> burst/retransmission address.

I would propose an alternative text to Tom's suggestion:

"Note that RR MUST send at least one RAMS-T message (if an RTCP BYE message has not been issued yet as described in step 9), and the RAMS-T message MUST be addressed to the RTCP port of the retransmission session."

In other words, if a BYE has already been issued, there is no need for RAMS-T. Agree with this?

-acbegen

---

From: "Bill Ver Steeg (versteb)" <[email-masked]>
Date: Wed, 24 Jun 2009 08:37:12 -0400

There has been some discussion around the requirement for a NAT section
in the latest RAMS draft. This note is an attempt to clarify the
requirement to signal RAMS port mappings. Once we come to a consensus as
to the desired behavior, we can update the draft.

This text refers to a ppt document that can be found at
ftp://ftpeng.cisco.com/abegen/PubPorts.pdf

When using RAMS to accelerate acquisition of a multicast flow, there are
two sessions - the primary multicast session and the acceleration
session. These sessions may have multiple socket contexts, depending on
the use of RTP/RTP port muxing. However, the primary multicast session
and the retransmission session are always distinct.

1- The primary multicast session - two logical flows defined by the
Source address, Destination Multicast Address, RTP port (P1) and RTCP
port(P2). This set of flows is shown in RED in the diagram.
2- The retransmission/acceleration session, shown in BLUE in the
diagram. In the most general non-port-muxed, non-NATed case, this stream
consists of 2 flows. The first (RTP) flow is defined by the 5-tuple of
UDP, IP address of the FT, RTP port configured by SDP (P3),  the IP
address of the client and the RTP port dynamically chosen by RR (c3).
The second (RTCP) flow is defined by the 5-tuple of UDP, FT address, the
RTCP port defined by SDP (P4), the IP address of the client and the RTCP
port dynamically chosen by RR (c4). When RTP/RTCP port muxing is used,
the retransmission session is collapsed onto a single 5-tuple.

Note that the feedback target for the primary session is P2 on FT/RS.
Note that the acceleration burst must flow from FT P3/P4 to C c3/c4. In
other words, the first desired data flow on the retransmission session
is "downstream". 

When we introduce NAT, we need to map c3 to c3' (and in the absence of
port muxing, also c4 to c4') through the NAT device. This diagram shows
the use of STUN in YELLOW to setup the port mappings, but other methods
could be used.

In summary, the ppt describes 4 options-

Drawing 1 - No muxing - Stun request, bind for two ports and send
PubPorts with RAMS-R to signal both, followed by the burst.
Drawing 2 - Muxing - Stun request, bind for one port and send PubPorts
with RAMS-R to signal a single port, followed by the burst.
Drawing 3 - Muxing - No explicit STUN request/bind. Send PubPorts with
RAMS-R to signal RS to use the src port of the incoming RTCP packet as
the destination for both RTP and RTCP in the ret session (We do this by
putting 0's in the pubports messages). Note that this does not work
through all NAT variants. The RAMS-R/PubPorts message is sent from c4 to
P2. The burst is sent from P4 to c4', and certain NATs will not pass
this traffic.
Drawing 4 - Muxing - No explicite STUN request/bind. Send PubPorts from
c4 to P4, initializing NAT bindings. Send RAMS-R, followed by the burst.
This works through all NAT types. There is concern about the decoupling
of the PubPorts from the RAMS-R, as dropped messages may cause problems.

Hopefully this note clarifies the need to signal the ports.

Inputs on ths problem are desired. We need to decide if the PubPorts is
the right way to go, and if the transaction is RAMS specific or is a
generic RTP/RTCP message. Once we make that determination, we need to
lay out the details of the message format. 

Based on the feedback - we will abandon the idea, keep it in the draft,
or write a separate draft for it.

Bill VerSteeg (with extensive input from Ali Begen and Dan Wing)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Zeev Vax
Sent: Thursday, June 18, 2009 5:58 PM
To: Ali C. Begen (abegen); Roni Even; Bill Ver Steeg (versteb);
VANCAENEGEM Tom; [email-masked]
Subject: Re: [AVT] comments on
section10ofdraft-ietf-avt-rapid-acquisition-for-rtp-01

If we assume all entities are one, why would you need to signal the
retransmission port separately ?

Zeev

---

From: "VAN CAENEGEM Tom" <[email-masked]>
Date: Thu, 25 Jun 2009 12:34:48 +0200

Bill,

Thanks for presenting so clearly the different options. A few opinions
here:

-For option 3 and 4, a STUN server is not involved, so perhaps the
associated slides should not mention a STUN server there.

-For option 3, the pub-port message is in fact not needed, not from the
NAPT point of view, and not from the RS point of view if we consider a
clause saying that the RR only needs to send a pub-port message to the
RS (Feedback Target) when it does NOT want to receive the RTP/RTCP
burst/retransmission packets on the same port as the source port on
which the RR sent out the RAMS-R or NACK RTCP message (hence no need to
define "zero" port values). Of course the RR can only do so, if it
supports RTP/RTCP muxing itself, and if it knows the RS supports
RTP/RTCP muxing too (as indicated in the declarative sdp received by the
RR) 

-Don't we also allow that for option 3, the port P2 actually equals port
P4? This is a kind of hybrid of session and SSRC multiplexing of the
primary multicast RTP stream and the retransmission/acceleration session
:  on the unidirectional RTP layer, the primary MC packets and the
unicast retransmission packets are clearly session muxed, but the RTCP
"return" channel for both streams have exactly the same transport
addresses, but are distinguished by means of a different SSRC.  In that
case, the NAPT will always work and there is (again) no need for a
pub-port message. The RTP receiver of course needs to know whether the
RS supports this port/multiplexing scheme and this could be solved  by
means of defining a new atribute in SDP, that is then included in the
declarative SDP. 

With this, I am not saying that I do not want to define the pub-port
message because RTP receivers that want to choose themselves which ports
are used for the acceleration session should rely on the pub-port
message to signal this to the RS (option 1 and 2) and to circumvent the
NAPT when using option 4.

For option 4, the pub-port message is used to make the NAPT binding. And
each time a RR asks for a retransmission , the RR may have to send a
pubreport message, because the NAPT bindings have a limited lifetime. It
is not clear to me whether for all options you considered, the
pub-report message is always sent whenever a  NACK is sent?  Or would
you recommend saying that it must be sent when a RAMS-R is sent
(obviously), and then during the acceleration/retransmission session it
is never sent anymore for option 1 and 2 (as the RS keeps state), and
for option 4 in your slides it is up to the RR to decide when to
transmit the pub-port, based on its knowledge of NAT binding lifetime?

In summary, my opinions are the following:

-the pub-port message is only used by the RR to signal a dedicated set
of ports to the RS on which it wants to receive the RTP/RTCP burst and
retransmission packets. This is option 1 and 2. For an acceleration
(+retransmission) session, the pub-port is sent once in a compound
together with RAMS-R, and for a retransmission-only session (no
RAMS/acceleration involved), it is sent in a compound together with the
1st issued NACK. For subsequent NACKs, there is no need to send the
pub-report along.
 
-when the declarative SDP indicates that the RS supports RTP/RTCP
muxing, and the RR does not use the pub-port message, the RR expects the
retransmission/burts packets on the same port on which it sent out the
RAMS-R or the NACK RTCP message.

-when additionally the declarative SDP indicates with a new attribute
that the RS is prepared to use as source port for the
burst/retransmission packets the ports used by the RR for the
burst/retransmission request, the RR expects the RS to use the same
ports (source and destination) for the retransmission/burts packets as
used by the receiver in the RAMS-R or the NACK RTCP message (but
reversed of course). The new SDP attribute could include a range of
ports out which the RTP receiver needs to select a value that it will
use as destination port for the RAMS-R or NACK.  

I would also be in favour that we mandate an RS to support RTP/RTCP
muxing, such that an RTP receiver can always make a choice which scheme
to follow.

I think it would make more sense to describe this whole solution with
the pub-port message definition and new SDP attribute as well as the
STUN message exchange in a separate draft as it is also applicable to
solutions making use of RTCP FB messages for retransmission only (RTCP
NACK), but with no need for rapid acquisition. 

Regards,
Tom 

-----Original Message-----
From: Bill Ver Steeg (versteb) [mailto:[email-masked]] 
Sent: woensdag 24 juni 2009 14:37
To: Zeev Vax; Ali C. Begen (abegen); Roni Even; VAN CAENEGEM Tom;
[email-masked]
Subject: Port mappings, NAT, and RAMS

-----Original Message-----

Zeev

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 25 Jun 2009 08:57:46 -0700

Hi Tom,

A few quick comments inline.

> Sent: Thursday, June 25, 2009 3:35 AM
> To: Bill Ver Steeg (versteb); Zeev Vax; Ali C. Begen (abegen); Roni Even; [email-masked]
> Subject: RE: Port mappings, NAT, and RAMS
> 
> Bill,
> 

Yup. It can be removed.

> define "zero" port values). Of course the RR can only do so, if it

The reason why we need pubports is that it indicates "explicitly" the port the client wants to use to receive the burst is the port it used to send the RAMS-R/pubports message. I believe we need this explicit indication, ow, we will be making an implicit assumption. Note that the rams-r/pubports is in the primary session and burst/ret packets are in the retransmission session, which is different than the primary.

As far as I can see, not everybody agrees on this point, but we need to make a decision here before we mandate anything.

> addresses, but are distinguished by means of a different SSRC.  In that

How? Since SSM and retransmission sessions are session muxed, they have the same SSRC. When a client is sending a receiver report, how do we identify which session it belongs to? So, I believe P2 should be different than P4.

> pub-report message is always sent whenever a  NACK is sent?  Or would

This is a very good point. If RS/FT address changes for each SSM session, then a new pubports is needed to bind the correct address/port on the NAT. And similar to RAMS-R, NACK would also require a pubports message whenever a binding is needed for regular retransmission. 

But, the main problem here is that we are separating the RAMS-R/NACK from the pubports message. Now, assume that we sent RAMS-R and pubports for session 1, and suppose pubports message made it but RAMS-R was lost. Then, we switched to session 2, sent a new RAMS-R and pubports. Then, we switched back to session 1, sending a new RAMS-R and pubports. Now, RS may get confused since it may not accurately match the outstanding RAMS-R and pubports messages. In the RAMS-R message, the parameters may have changed (such as burst bitrate). In the pubports, port mappings may have changed. As a result, RS may send the burst to the wrong port and/or the burst may be at a lower or higher bitrate than RR wants to have.

In other words, we are introducing new failure modes and this is a big concern for option 4, IMO.

> transmit the pub-port, based on its knowledge of NAT binding lifetime?

As long as the binding does not expire (meaning there is some transmission on that path), we should be fine. And I believe there are certain guidelines listed in the STUN spec.

-acbegen

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 25 Jun 2009 16:08:56 -0700

> Subject: Re: [AVT] Port mappings, NAT, and RAMS
> 
> Bill,
> 
> pubreport message, because the NAPT bindings have a limited 
> lifetime.

The RR can keep the NAT's binding alive by sending periodic STUN
indications (as described for RTP flows in Section 4.4 of 
draft-ietf-avt-app-rtp-keepalive), or maybe we could define a bogus
RTCP message if a STUN indication to keep the binding alive is
offensive.  draft-ietf-avt-app-rtp-keepalive mentions that RTCP
usually doesn't need keepalive traffic to keep a NAT binding alive
because RTCP is sent periodically.  In the situation with RAMS
RTCP messages, the RTCP requesting re-transmission is not sent 
periodicially.  

> It

It is difficult-to-impossible to determine the lifetime of a NAT's 
binding with much confidence.

-d

---

From: Roni Even <[email-masked]>
Date: Fri, 26 Jun 2009 11:31:03 +0300

Hi Bill,
I think I was the one who started this discussion but it looks to me like it
is going too far since some of this work are not in the AVT charter.

The RAMS solution is based on SSM and Retransmission and if there is a
problem with NATs in these drafts it should be discussed there. My concern
was different. The AVT solution is using SDP for specifying address
information. In the case of both SSM and retransmission, the server can
provide their address (which they may have obtained by using any method they
chose) in the SDP. This works both for offer/answer and declarative SDP. I
see no reason to address this topic in the RAMS draft

The RAMS draft need to provide other addresses which are the RR RTP and RTCP
receive addresses. In the case of offer answer this is clear by for
declarative SDP the RR does not sent an SDP so cannot provide receive
addresses.

In the case of RFC 4588 the retransmission can be based on session or SSRC
multiplexing and defines how to use SDP to provide the addresses. The
difference is that RFC 4588 do not address a unicast retransmission for a
multicast stream which is the special case described here.  In the current
case the SSRC multiplexing mode of RFC 4588 is not relevant so there MUST be
a way for the RR to provide its receiving addresses to the RS. 

Since this solution do not work in offer/answer but is based on declarative
SDP there need to be other way for the RR to provide the addressed

My view based on the text above about SSM and RFC 4588 is that this is a
special case and not a general case and this is why I suggested to add the
address information to the RAMS-R message.

Roni Even

> Sent: Wednesday, June 24, 2009 3:37 PM
> To: Zeev Vax; Ali C. Begen (abegen); Roni Even; VANCAENEGEM Tom;
> [email-masked]

---

From: "VAN CAENEGEM Tom" <[email-masked]>
Date: Fri, 26 Jun 2009 10:52:23 +0200

Hi Roni,

The problem I see here is that this is broader than RAMS: if an RTP
receiver in an SSM session does not make use of RAMS, but wants to
receive retransmissions, then integrating the "pub-port" functionality
in the RAMS-R will not help here. That is why it makes most sense to
define a dedicated RTCP "pub-port" message that can be combined with an
RAMS-R or with a NACK.. Or with any other future RTCP request message
that may be defined and relies on the same ssm with feedback target
architecture..
And I also think that we should consider a "default" case that when an
RTP receiver does not signal its ports, the retransmission server
understands the RTP receiver expects the retransmission/burst on the
port, that was used by the RTP receiver as source port to request the
retransmission and burst. But that should imply that the "pub-port" MUST
always be sent in a single compound together with the NACK and/or the
RAMS-R message (either of these) that triggers the retransmission
session.

Tom

-----Original Message-----
From: Roni Even [mailto:[email-masked]] 
Sent: vrijdag 26 juni 2009 10:31
To: 'Bill Ver Steeg (versteb)'; 'Zeev Vax'; 'Ali C. Begen (abegen)'; VAN
CAENEGEM Tom; [email-masked]
Subject: RE: Port mappings, NAT, and RAMS

Hi Bill,
I think I was the one who started this discussion but it looks to me
like it is going too far since some of this work are not in the AVT
charter.

The RAMS solution is based on SSM and Retransmission and if there is a
problem with NATs in these drafts it should be discussed there. My
concern was different. The AVT solution is using SDP for specifying
address information. In the case of both SSM and retransmission, the
server can provide their address (which they may have obtained by using
any method they
chose) in the SDP. This works both for offer/answer and declarative SDP.
I see no reason to address this topic in the RAMS draft

The RAMS draft need to provide other addresses which are the RR RTP and
RTCP receive addresses. In the case of offer answer this is clear by for
declarative SDP the RR does not sent an SDP so cannot provide receive
addresses.

In the case of RFC 4588 the retransmission can be based on session or
SSRC multiplexing and defines how to use SDP to provide the addresses.
The difference is that RFC 4588 do not address a unicast retransmission
for a multicast stream which is the special case described here.  In the
current case the SSRC multiplexing mode of RFC 4588 is not relevant so
there MUST be a way for the RR to provide its receiving addresses to the
RS. 

Since this solution do not work in offer/answer but is based on
declarative SDP there need to be other way for the RR to provide the
addressed

My view based on the text above about SSM and RFC 4588 is that this is a
special case and not a general case and this is why I suggested to add
the address information to the RAMS-R message.

Roni Even

> There has been some discussion around the requirement for a NAT 
> section in the latest RAMS draft. This note is an attempt to clarify 
> the requirement to signal RAMS port mappings. Once we come to a 
> consensus as to the desired behavior, we can update the draft.
> 
> When using RAMS to accelerate acquisition of a multicast flow, there 
> are two sessions - the primary multicast session and the acceleration 
> session. These sessions may have multiple socket contexts, depending 
> on the use of RTP/RTP port muxing. However, the primary multicast 
> session and the retransmission session are always distinct.
> 
> diagram. In the most general non-port-muxed, non-NATed case, this 
> stream consists of 2 flows. The first (RTP) flow is defined by the 
> 5-tuple of UDP, IP address of the FT, RTP port configured by SDP (P3),

> the IP address of the client and the RTP port dynamically chosen by RR

> (c3).
> The second (RTCP) flow is defined by the 5-tuple of UDP, FT address, 
> the RTCP port defined by SDP (P4), the IP address of the client and 
> the RTCP port dynamically chosen by RR (c4). When RTP/RTCP port muxing

> is used, the retransmission session is collapsed onto a single 
> 5-tuple.
> 
> Note that the acceleration burst must flow from FT P3/P4 to C c3/c4. 
> In other words, the first desired data flow on the retransmission 
> session is "downstream".
> 

> port muxing, also c4 to c4') through the NAT device. This diagram 
> shows the use of STUN in YELLOW to setup the port mappings, but other 
> methods could be used.
> 
> 
> 

> the destination for both RTP and RTCP in the ret session (We do this 
> by putting 0's in the pubports messages). Note that this does not work

> through all NAT variants. The RAMS-R/PubPorts message is sent from c4 
> to P2. The burst is sent from P4 to c4', and certain NATs will not 
> pass this traffic.
> This works through all NAT types. There is concern about the 
> decoupling of the PubPorts from the RAMS-R, as dropped messages may 
> cause problems.
> 
> Inputs on ths problem are desired. We need to decide if the PubPorts 
> is the right way to go, and if the transaction is RAMS specific or is 
> a generic RTP/RTCP message. Once we make that determination, we need 
> to lay out the details of the message format.
> 
> Based on the feedback - we will abandon the idea, keep it in the 
> draft, or write a separate draft for it.
>

---

From: "VAN CAENEGEM Tom" <[email-masked]>
Date: Fri, 26 Jun 2009 10:54:33 +0200

Ali, see inline 

-----Original Message-----
From: Ali C. Begen (abegen) [mailto:[email-masked]] 
Sent: donderdag 25 juni 2009 17:58
To: VAN CAENEGEM Tom; Bill Ver Steeg (versteb); Zeev Vax; Roni Even;
[email-masked]

Hi Tom,

Yup. It can be removed.

> -For option 3, the pub-port message is in fact not needed, not from 
> the NAPT point of view, and not from the RS point of view if we 
> consider a clause saying that the RR only needs to send a pub-port 
> message to the RS (Feedback Target) when it does NOT want to receive 
> the RTP/RTCP burst/retransmission packets on the same port as the 
> source port on which the RR sent out the RAMS-R or NACK RTCP message 
> (hence no need to define "zero" port values). Of course the RR can 
> only do so, if it

The reason why we need pubports is that it indicates "explicitly" the
port the client wants to use to receive the burst is the port it used to
send the RAMS-R/pubports message. I believe we need this explicit
indication, ow, we will be making an implicit assumption. Note that the
rams-r/pubports is in the primary session and burst/ret packets are in
the retransmission session, which is different than the primary.

As far as I can see, not everybody agrees on this point, but we need to
make a decision here before we mandate anything.

TOM: I agree with your last line, but I do not completely agree when you
mention "implicit" assumption, especially for option 3, where RAMS-R (or
NACK) and the Pub-port message are in the same compound message. If we
"define" that if no pub-report message is sent by the RR, the
information towards the Retransmission server is exactly the same as
when an RTP receiver sends an RTCP compound message made up of an RTCP
NACK/RAMS-R together with a pub-port message where the ports are "zero"
-as currently proposed in the RAMS draft now.  I agree that this is not
true for option 4, where pub-port and RAMS-R or NACK are separate
messages, but I do not favour the solution of option 4 for the same
reason you mention in your reply (a new failure mode). So, if option 4
is -for that reason- no longer considered, I do not see a problem with
defining this rule/clause as expressed above. In other words, there is
no need for a pub-report message in this scenario and this results NOT
in an "assumption" what-so-ever.   

> -Don't we also allow that for option 3, the port P2 actually equals 
> port P4? This is a kind of hybrid of session and SSRC multiplexing of 
> the primary multicast RTP stream and the retransmission/acceleration 
> session

> addresses, but are distinguished by means of a different SSRC.  In 

How? Since SSM and retransmission sessions are session muxed, they have
the same SSRC. When a client is sending a receiver report, how do we
identify which session it belongs to? So, I believe P2 should be
different than P4.

TOM: you are right. But notice this: RFC 4588 mandates that when session
muxing is used for retransmission, than the SSRC should be the same.
However the RFC 4588 does not give arguments why it needs to be like
that. So I ask you: what would or can happen if there is a different
SSRC used?  If there are no convincing arguments why we must stick to
the same SSRC, then, if we have a good use case to depart from that
"rule" -and the use case we are discussing here is IMO indeed a valid
use case- I do not see why we should be limited by such a "rule". The
"valid" use case is here that RAMS and Retransmission for SSM sessions
operates fine through any NAPT and without any dedicated RTCP message. 

> message because RTP receivers that want to choose themselves which 
> ports are used for the acceleration session should rely on the 
> pub-port message to signal this to the RS (option 1 and 2) and to 
> circumvent the NAPT when using option 4.
> 
> For option 4, the pub-port message is used to make the NAPT binding. 
> And each time a RR asks for a retransmission , the RR may have to send

> a pubreport message, because the NAPT bindings have a limited 
> lifetime. It is not clear to me whether for all options you 
> considered, the pub-report message is always sent whenever a  NACK is 
> sent?  Or would

This is a very good point. If RS/FT address changes for each SSM
session, then a new pubports is needed to bind the correct address/port
on the NAT. And similar to RAMS-R, NACK would also require a pubports
message whenever a binding is needed for regular retransmission. 

But, the main problem here is that we are separating the RAMS-R/NACK
from the pubports message. Now, assume that we sent RAMS-R and pubports
for session 1, and suppose pubports message made it but RAMS-R was lost.
Then, we switched to session 2, sent a new RAMS-R and pubports. Then, we
switched back to session 1, sending a new RAMS-R and pubports. Now, RS
may get confused since it may not accurately match the outstanding
RAMS-R and pubports messages. In the RAMS-R message, the parameters may
have changed (such as burst bitrate). In the pubports, port mappings may
have changed. As a result, RS may send the burst to the wrong port
and/or the burst may be at a lower or higher bitrate than RR wants to
have.

In other words, we are introducing new failure modes and this is a big
concern for option 4, IMO.

> (obviously), and then during the acceleration/retransmission session 
> it is never sent anymore for option 1 and 2 (as the RS keeps state), 
> and for option 4 in your slides it is up to the RR to decide when to 

As long as the binding does not expire (meaning there is some
transmission on that path), we should be fine. And I believe there are
certain guidelines listed in the STUN spec.

TOM: I agree.

-acbegen

> RAMS/acceleration involved), it is sent in a compound together with 
> the 1st issued NACK. For subsequent NACKs, there is no need to send 
> the pub-report along.
> 
> muxing, and the RR does not use the pub-port message, the RR expects 
> the retransmission/burts packets on the same port on which it sent out

> the RAMS-R or the NACK RTCP message.
> 

> muxing, such that an RTP receiver can always make a choice which 
> scheme to follow.
> 

(c3).

5-tuple.

cause problems.

---

From: Roni Even <[email-masked]>
Date: Fri, 26 Jun 2009 12:34:02 +0300

Tom,
What bothering me is that I do not want to make RTCP as a general mechanism
to provide addressing information. 

I still do not see this a a general problem. The case you described (SSM
with retransmission), except for the RAMS case there is no other application
that requires that, it requires co-location of the FT and retransmission
source, you send the retransmission request to the feedback target and not
to the retransmission server. 

If this was a general problem it should be addressed in the context of
retransmission or SSM.

Roni

> Sent: Friday, June 26, 2009 11:52 AM
> To: Roni Even; Bill Ver Steeg (versteb); Zeev Vax; Ali C. Begen
> (abegen); [email-masked]

---

From: "VAN CAENEGEM Tom" <[email-masked]>
Date: Fri, 26 Jun 2009 12:10:05 +0200

Roni,

See inline 

-----Original Message-----
From: Roni Even [mailto:[email-masked]] 
Sent: vrijdag 26 juni 2009 11:34
To: VAN CAENEGEM Tom; 'Bill Ver Steeg (versteb)'; 'Zeev Vax'; 'Ali C.
Begen (abegen)'; [email-masked]
Subject: RE: [AVT] Port mappings, NAT, and RAMS

Tom,
What bothering me is that I do not want to make RTCP as a general
mechanism to provide addressing information. 

TOM: I understand

I still do not see this a a general problem. The case you described (SSM
with retransmission), except for the RAMS case there is no other
application that requires that, it requires co-location of the FT and
retransmission source, you send the retransmission request to the
feedback target and not to the retransmission server. 

TOM: not sure I understand your exact point here. Do you agree that we
need a similar solution for SSM with retransmission (-only)  AND SSM
with RAMS (+ retransmission)?  In that case, it does not make sense to
specify ONLY a RAMS-R with the port information, you also need to do
that then for a NACK message. NACK is already defined, so that is why I
think that specifying a separate RTCP message is the way out here. But
because this is related to ssm and retransmission, it cannot be done in
this RAMS draft only. I do agree that such message can only be used in
the context of ssm with unicast feedback.

Roni

> define a dedicated RTCP "pub-port" message that can be combined with 
> an RAMS-R or with a NACK.. Or with any other future RTCP request 
> message that may be defined and relies on the same ssm with feedback 
> target architecture..

> To: 'Bill Ver Steeg (versteb)'; 'Zeev Vax'; 'Ali C. Begen (abegen)'; 
> VAN CAENEGEM Tom; [email-masked]

> server can provide their address (which they may have obtained by 
> using any method they
> The RAMS draft need to provide other addresses which are the RR RTP 
> and RTCP receive addresses. In the case of offer answer this is clear 
> by for declarative SDP the RR does not sent an SDP so cannot provide 
> receive addresses.
> 
> 
> The difference is that RFC 4588 do not address a unicast 
> retransmission for a multicast stream which is the special case 
> described here.  In the current case the SSRC multiplexing mode of RFC

> 4588 is not relevant so there MUST be a way for the RR to provide its 
> receiving addresses to the RS.
> 
> My view based on the text above about SSM and RFC 4588 is that this is

> a special case and not a general case and this is why I suggested to 
> add the address information to the RAMS-R message.
> 
> Roni Even
> 
> 

> > are two sessions - the primary multicast session and the 
> > acceleration session. These sessions may have multiple socket 
> > contexts, depending on the use of RTP/RTP port muxing. However, the 
> > primary multicast session and the retransmission session are always
distinct.
> > Source address, Destination Multicast Address, RTP port (P1) and 
> > RTCP port(P2). This set of flows is shown in RED in the diagram.

> > shows the use of STUN in YELLOW to setup the port mappings, but 
> > other methods could be used.
> >
> >
> >

> > through all NAT variants. The RAMS-R/PubPorts message is sent from 
> > c4 to P2. The burst is sent from P4 to c4', and certain NATs will 
> > not pass this traffic.

> > is the right way to go, and if the transaction is RAMS specific or 
> > is a generic RTP/RTCP message. Once we make that determination, we 
> > need to lay out the details of the message format.
> >
> > Of Zeev Vax

---

From: "Bill Ver Steeg (versteb)" <[email-masked]>
Date: Fri, 26 Jun 2009 10:35:03 -0400

Tom is on the right track here.

Let's try separate the technical issue from the logistical issues.

First - the technical issue- RAMS can be considered a special case of
RTCP/RTP repair. The existing RTCP NACK messages do not "self prime" a
NAT. If we can design a mechanism to make RTCP NACK self-configure a NAT
binding, we should be able to use it for RAMS-R. If we do not have a
mechanism for the baseline RTP repair method to make it NAT friendly, we
need to do something RAMS specific.
 
Second - the logistics issue - As Roni correctly points out, we do not
have a charter to address this in the more general case. The group needs
to decide if this is an RTP issue or a RAMS issue. Until we have
agreement on how to proceed, we should move this issue to a separate
(non-normative) document and remove it from the RAMS draft.

I (personally, not as a RAMS author) would like to see NAT addressed for
the baseline RTP/RTCP repair case. I feel that there is a need "in the
wild" for standard RTP/RTCP repair through NATs. We are getting ahead of
ourselves from a document structuring standpoint, though. 

Bill VerSteeg

-----Original Message-----
From: VAN CAENEGEM Tom [mailto:[email-masked]] 
Sent: Friday, June 26, 2009 6:10 AM
To: Roni Even; Bill Ver Steeg (versteb); Zeev Vax; Ali C. Begen
(abegen); [email-masked]

Roni,

See inline 

-----Original Message-----
From: Roni Even [mailto:[email-masked]]
Sent: vrijdag 26 juni 2009 11:34
To: VAN CAENEGEM Tom; 'Bill Ver Steeg (versteb)'; 'Zeev Vax'; 'Ali C.

Tom,

TOM: I understand

Roni

distinct.

---

From: Roni Even <[email-masked]>
Date: Fri, 26 Jun 2009 17:53:15 +0300

Tom,
I do not agree that we need a solution for SSM + retransmission not in the
architecture of RAMS. Can you show me such a use and why not use RAMS.
The assumption is that the first request for retransmission is going to the
FT. If the request goes to the retransmission server, you can use RTP/RTCP
multiplexing.
Roni 

> Sent: Friday, June 26, 2009 1:10 PM

---

From: "VAN CAENEGEM Tom" <[email-masked]>
Date: Fri, 26 Jun 2009 17:41:23 +0200

Hi Roni,

My perspective here is the one from real operator networks where
operators are providing IPTV services making use of RTP, including
multicast services. IPTV operators need to address packet loss, and one
way to address this is by making use of RTP retransmissions. I lead the
standardisation effort in DVB in 2007-2008, where we defined the RTP
retransmission solution referring to rtcp-ssm draft, RFC 4585 (defining
AVT-FB profile and RTCP FB message such as NACK) and RFC 4588
(Retransmission), and also the RTP mux draft. Hence this
architecture/solution is based on ssm, and the RTP receiver needs to
send all its RTCP messges , including the RTCP NACK FB, to the feedback
target. The feedback target is also here the same entity as the
retransmission server. DVB has its own way of signaling parameters, but
also here we were facing the fact that parameters are signaled to the
receivers. The receivers do not/cannot signal towards the FT/RET server
which ports they want. So we took a shortcut by allowing that the
destination port of the RTP packet could be defined by the system (so
quite exotic) OR when this port was not signaled, the RTP receiver knew
that the RTP retransmission packet port matches the source port it used
in the NACK messages. There have been some email exchanges from DVB with
AVT when this work was conducted, but there was not that much
interaction.

RAMS is a solution that addresses a different topic, that is: how to
shorten zapping response times. From a service need point of view,
packet loss repair and minimising zapping times are quite separate
topics: some operators may only be interested in achieving high image
quality (relying on retransmissions), others may (also) want to offer
smallest zapping response times without impact on quality (relying on
RAMS messaging). Note also that a "retransmission service" and  -what is
called in DVB-  "fast channel change service" impose quite different
loads onto the networks, especially when these servers are localised
deep in the network. So that may for instance be a reason why some IPTV
service providers do not want "fast channel change" service, but do need
retransmission service.  So, imposing to use "RAMS" for an IPTV service
that provides retransmission(-only) support -to allow a standards way by
which the receiver itself can select its ports- is quite absurd, and
will not work. 

In short: the architecture for retransmissions-only and for "fast
channel change" service are exactly the same, but RAMS as such has
nothing to do with retransmission service, still faces the same problem
of port signaling. 

Tom

-----Original Message-----
From: Roni Even [mailto:[email-masked]] 
Sent: vrijdag 26 juni 2009 16:53
To: VAN CAENEGEM Tom; 'Bill Ver Steeg (versteb)'; 'Zeev Vax'; 'Ali C.

Tom,
I do not agree that we need a solution for SSM + retransmission not in
the architecture of RAMS. Can you show me such a use and why not use
RAMS.
The assumption is that the first request for retransmission is going to
the FT. If the request goes to the retransmission server, you can use
RTP/RTCP multiplexing.
Roni 

> I still do not see this a a general problem. The case you described 
> (SSM with retransmission), except for the RAMS case there is no other 

> that then for a NACK message. NACK is already defined, so that is why 
> I think that specifying a separate RTCP message is the way out here. 
> But because this is related to ssm and retransmission, it cannot be 
> done in this RAMS draft only. I do agree that such message can only be

> used in the context of ssm with unicast feedback.
> 
> 

> > port, that was used by the RTP receiver as source port to request 
> > the retransmission and burst. But that should imply that the
"pub-port"
> > MUST
> > always be sent in a single compound together with the NACK and/or 
> > the RAMS-R message (either of these) that triggers the 
> > retransmission session.
> >
> > Tom
> >
> >

> > and RTCP receive addresses. In the case of offer answer this is 
> > clear by for declarative SDP the RR does not sent an SDP so cannot 
> > provide receive addresses.
> >
> >
> > In the case of RFC 4588 the retransmission can be based on session 
> > or SSRC multiplexing and defines how to use SDP to provide the
> addresses.
> > 4588 is not relevant so there MUST be a way for the RR to provide 
> > its receiving addresses to the RS.
> >

> > > contexts, depending on the use of RTP/RTP port muxing. However, 
> > > the primary multicast session and the retransmission session are 
> > > always
> distinct.
> > >
> > > 1- The primary multicast session - two logical flows defined by 
> > > the Source address, Destination Multicast Address, RTP port (P1) 
> > > and RTCP port(P2). This set of flows is shown in RED in the
diagram.

> > > the IP address of the client and the RTP port dynamically chosen 
> > > by
> > RR
> >
> > > (c3).
> > > the RTCP port defined by SDP (P4), the IP address of the client 
> > > and the RTCP port dynamically chosen by RR (c4). When RTP/RTCP 
> > > port
> > muxing
> >
> > > When we introduce NAT, we need to map c3 to c3' (and in the 
> > > absence
> > of
> >
> > > RAMS-R to signal RS to use the src port of the incoming RTCP 
> > > packet
> > as
> >
> > > Drawing 4 - Muxing - No explicite STUN request/bind. Send PubPorts

> > > from
> > > decoupling of the PubPorts from the RAMS-R, as dropped messages 
> > > may cause problems.
> > >

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Fri, 26 Jun 2009 08:41:12 -0700

Hi Tom,

[snip]
> NACK/RAMS-R together with a pub-port message where the ports are "zero"

We "may" be able to say it from RAMS-R but not for NACK since we are not defining it, we will be overloading its meaning, IMO. And as you/Bill pointed out in other emails, I also believe that this is more general problem than just RAMS. We need something like pubports for NACKs as well.

> SSRC used?  If there are no convincing arguments why we must stick to

Good question. If we don't use the same SSRC in session-muxed RTP sessions, it will introduce correlation problems. Receiver/XR reports coming from a larger number of receivers will be difficult to identify and match at the server side. There will be SSRC collisions, which will complicate things further.

-acbegen

---

From: Roni Even <[email-masked]>
Date: Fri, 26 Jun 2009 18:55:42 +0300

Tom,
So maybe, since it is the same architecture,  it is a good time to allow
RAMS-R to only signal retransmission.  

Roni

> Sent: Friday, June 26, 2009 6:41 PM
> > > The RAMS solution is based on SSM and Retransmission and if there
> is
> > a
> >

---

From: Zeev Vax <[email-masked]>
Date: Fri, 26 Jun 2009 17:26:55 +0000

I'm really straggling with why do we need to include port signaling as part of this draft. The port can be signal dynamically or sent to client at start up, and we can point out the different options to do so. Saying that, going to great level of details on this looks to me outside the scope of this draft.
The port muxing gives the means to connect this protocol to the retransmission one, and I think we should add that in order to clarify the usage of this protocol.

Zeev

-----Original Message-----
From: Roni Even [mailto:[email-masked]]
Sent: Friday, June 26, 2009 8:56 AM
To: 'VAN CAENEGEM Tom'; 'Bill Ver Steeg (versteb)'; Zeev Vax; 'Ali C. Begen (abegen)'; [email-masked]
Subject: RE: [AVT] Port mappings, NAT, and RAMS

Tom,

Roni

---

From: Roni Even <[email-masked]>
Date: Fri, 26 Jun 2009 20:58:48 +0300

Zeev,
I assume you mean RTp/RTCP muxing. I am afraid it will not solve the problem
since the RAM-R is going to the FT while the RTP is coming from the burst
server using a different port. This will fail a symmetric NAT since the RTP
is not coming from the same IP/port to where the RAMS-R was sent
Roni

> Sent: Friday, June 26, 2009 8:27 PM
> To: Roni Even; 'VAN CAENEGEM Tom'; 'Bill Ver Steeg (versteb)'; 'Ali C.
> I'm really straggling with why do we need to include port signaling as
> part of this draft. The port can be signal dynamically or sent to
> client at start up, and we can point out the different options to do
> so. Saying that, going to great level of details on this looks to me
> outside the scope of this draft.
> The port muxing gives the means to connect this protocol to the
> retransmission one, and I think we should add that in order to clarify
> the usage of this protocol.
> 
> Zeev
> 
> > > > And I also think that we should consider a "default" case that
> when
> > > an
> > >
> > > > chose) in the SDP. This works both for offer/answer and
> declarative
> > > > SDP.
> > > > described here.  In the current case the SSRC multiplexing mode
> of
> > > RFC
> > >
> > > > My view based on the text above about SSM and RFC 4588 is that
> this
> > > is
> > >
> > > > > 5-tuple of UDP, IP address of the FT, RTP port configured by
> SDP
> > > > (P3),
> > > >
> > > > > Drawing 3 - Muxing - No explicit STUN request/bind. Send
> PubPorts
> > > > with
> > > >
> > > > > by putting 0's in the pubports messages). Note that this does
> not
> > > > work
> > > >
> > > > > c4 to P4, initializing NAT bindings. Send RAMS-R, followed by
> the
> > > > > burst.

---

From: Zeev Vax <[email-masked]>
Date: Fri, 26 Jun 2009 18:51:22 +0000

my understanding is that port muxing can solve both problems, if we assume retransmission server and burst server are running on one physical server. For RTP RTCP muxing, the most logical is to use the RTCP port to send the RTP traffic, any other way looks to me like unnecessary overhead.

AT this point given the amount of emails we exchange on the subject, I suggest we set a conf call to discuss the issue.

Zeev

-----Original Message-----
From: Roni Even [mailto:[email-masked]]
Sent: Friday, June 26, 2009 10:59 AM
To: Zeev Vax; 'VAN CAENEGEM Tom'; 'Bill Ver Steeg (versteb)'; 'Ali C. Begen (abegen)'; [email-masked]
Subject: RE: [AVT] Port mappings, NAT, and RAMS

Zeev,

---

From: "VAN CAENEGEM Tom" <[email-masked]>
Date: Fri, 26 Jun 2009 20:30:15 +0200

Roni,

I am puzzled again. Are you suggesting that we use the RAMS-R message
also as a means to signal to the retransmission server that the RTP
receiver will only send NACKs? I do not get that way of thinking.
What the RAMS draft is about is defining the RAMS messages for rapid MC
acquisition. The architecture as such is not a new item. You can combine
rtcp-ssm and RFC 4585, RFC 4588, and there it is, the architecture.. In
the RAMS draft we only have imposed some constraints saying for instance
that the FT must be the same as the retransmission server (similar as in
DVB by the way). The additional port signaling we need that we are
discussing about now could be done by SDP negotiation or by means of
RTSP. But because of time constraints this is not a good solution,
regardless whether this is retransmission only, or retransmission and
rapid acquisition combined. 

I can only repeat myself: IF we define a port signaling means it must be
applicable both to retransmission-only (no RAMS messages are involved,
only NACKs) and to rapid acquisition (what the RAMS draft is about).
Hence, the RAMS-R message must be decoupled from the port signaling, and
even stronger:  the solution should be defined in a separate draft.

Tom 

-----Original Message-----
From: Roni Even [mailto:[email-masked]] 
Sent: vrijdag 26 juni 2009 17:56
To: VAN CAENEGEM Tom; 'Bill Ver Steeg (versteb)'; 'Zeev Vax'; 'Ali C.

Tom,

Roni

> multicast services. IPTV operators need to address packet loss, and 
> one way to address this is by making use of RTP retransmissions. I 
> lead the standardisation effort in DVB in 2007-2008, where we defined 
> the RTP retransmission solution referring to rtcp-ssm draft, RFC 4585 
> (defining AVT-FB profile and RTCP FB message such as NACK) and RFC 
> 4588 (Retransmission), and also the RTP mux draft. Hence this 
> send all its RTCP messges , including the RTCP NACK FB, to the 
> feedback target. The feedback target is also here the same entity as 
> the retransmission server. DVB has its own way of signaling 
> parameters, but also here we were facing the fact that parameters are 
> signaled to the receivers. The receivers do not/cannot signal towards 
> the FT/RET server which ports they want. So we took a shortcut by 
> allowing that the destination port of the RTP packet could be defined 
> by the system (so quite exotic) OR when this port was not signaled, 
> the RTP receiver knew that the RTP retransmission packet port matches 
> the source port it used in the NACK messages. There have been some 
> email exchanges from DVB with AVT when this work was conducted, but 
> there was not that much interaction.
> 
> RAMS messaging). Note also that a "retransmission service" and  -what 
> is called in DVB-  "fast channel change service" impose quite 
> different loads onto the networks, especially when these servers are 
> localised deep in the network. So that may for instance be a reason 
> why some IPTV service providers do not want "fast channel change" 
> service, but do need retransmission service.  So, imposing to use 
> "RAMS" for an IPTV service that provides retransmission(-only) support

> -to allow a standards way by which the receiver itself can select its 
> ports- is quite absurd, and will not work.
> 
> nothing to do with retransmission service, still faces the same 
> problem of port signaling.
> 
> Tom
> 
> 
> 
> 

> The assumption is that the first request for retransmission is going 
> to the FT. If the request goes to the retransmission server, you can 
> use RTP/RTCP multiplexing.
> Roni
> 
> > (SSM with retransmission), except for the RAMS case there is no 
> > other application that requires that, it requires co-location of the

> > FT and retransmission source, you send the retransmission request to

> > the feedback target and not to the retransmission server.
> >

> > that then for a NACK message. NACK is already defined, so that is 
> > why I think that specifying a separate RTCP message is the way out
here.

> > > The problem I see here is that this is broader than RAMS: if an 
> > > RTP receiver in an SSM session does not make use of RAMS, but 
> > > wants to receive retransmissions, then integrating the "pub-port"
> > functionality
> >
> > > like it is going too far since some of this work are not in the 
> > > AVT charter.
> > >

> > > concern was different. The AVT solution is using SDP for 
> > > specifying address information. In the case of both SSM and 
> > > retransmission,
> the
> 
> > > The RAMS draft need to provide other addresses which are the RR 
> > > RTP and RTCP receive addresses. In the case of offer answer this 
> > > is clear by for declarative SDP the RR does not sent an SDP so 
> > > cannot provide receive addresses.
> > >
> > >

> > > > diagram. In the most general non-port-muxed, non-NATed case, 
> > > > this stream consists of 2 flows. The first (RTP) flow is defined

> > > > In other words, the first desired data flow on the 
> > > > retransmission session is "downstream".
> > > >
> > > > port muxing, also c4 to c4') through the NAT device. This 
> > > > diagram shows the use of STUN in YELLOW to setup the port 
> > > > mappings, but other methods could be used.
> > > >
> > > >
> > > >
> > > > Drawing 1 - No muxing - Stun request, bind for two ports and 
> > > > send PubPorts with RAMS-R to signal both, followed by the burst.
> > > > c4 to P2. The burst is sent from P4 to c4', and certain NATs 
> > > > will not pass this traffic.
> > > > the burst.

> > > Audio/Video Transport Working Group [email-masked]

---

From: "VAN CAENEGEM Tom" <[email-masked]>
Date: Mon, 29 Jun 2009 18:17:29 +0200

Ali,

See some comments below (TOM).

-----Original Message-----
From: Ali C. Begen (abegen) [mailto:[email-masked]] 
Sent: vrijdag 26 juni 2009 17:41
To: VAN CAENEGEM Tom; Bill Ver Steeg (versteb); Zeev Vax; Roni Even;
[email-masked]

Hi Tom,

[snip]
> port the client wants to use to receive the burst is the port it used 
> to send the RAMS-R/pubports message. I believe we need this explicit 
> indication, ow, we will be making an implicit assumption. Note that 
> the rams-r/pubports is in the primary session and burst/ret packets 
> are in the retransmission session, which is different than the
primary.
> 
> As far as I can see, not everybody agrees on this point, but we need 
> to make a decision here before we mandate anything.
> 
> TOM: I agree with your last line, but I do not completely agree when 
> you mention "implicit" assumption, especially for option 3, where 
> RAMS-R (or

> NACK/RAMS-R together with a pub-port message where the ports are
"zero"

We "may" be able to say it from RAMS-R but not for NACK since we are not
defining it, we will be overloading its meaning, IMO. And as you/Bill
pointed out in other emails, I also believe that this is more general
problem than just RAMS. We need something like pubports for NACKs as
well.

TOM: indeed, that is why IMO we should define this problem and solution
in a separate draft which applies to any system architecture where a
unicast session from a FT is coupled to a ssm session with that same FT.

> -as currently proposed in the RAMS draft now.  I agree that this is 
> not true for option 4, where pub-port and RAMS-R or NACK are separate 

> > RTP/RTCP muxing too (as indicated in the declarative sdp received by

> > port P4? This is a kind of hybrid of session and SSRC multiplexing 
> > of the primary multicast RTP stream and the 
> > retransmission/acceleration session
> How? Since SSM and retransmission sessions are session muxed, they 
> have the same SSRC. When a client is sending a receiver report, how do

> we identify which session it belongs to? So, I believe P2 should be 
> different than P4.
> 
> TOM: you are right. But notice this: RFC 4588 mandates that when 
> session muxing is used for retransmission, than the SSRC should be the
same.
> SSRC used?  If there are no convincing arguments why we must stick to

Good question. If we don't use the same SSRC in session-muxed RTP
sessions, it will introduce correlation problems. Receiver/XR reports
coming from a larger number of receivers will be difficult to identify
and match at the server side. There will be SSRC collisions, which will
complicate things further.

TOM: the big difference with when the RFC 4588 was being discussed and
developed, is that now we are capable of advertising in SDP the SSRC of
the media server, that is in this case the retransmission server SSRC
used in the retransmission session. In fact for RAMS, we need to define
the SSRC of the ssm RTP session, so we can as well do it for the
retransmission session. Perhaps we should consider this different SSRC
possibility (hence violating RFC 4588) as part of a new draft, the one I
mentioned above.

-acbegen

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Tue, 30 Jun 2009 00:18:31 -0700

Hi Tom,

Let's get the input from the WG on these points. I believe going for a more general solution that will be applicable to both RAMS and NACK is more desirable.

BR,
-acbegen

> Sent: Monday, June 29, 2009 9:17 AM
> To: Ali C. Begen (abegen); Bill Ver Steeg (versteb); Zeev Vax; Roni Even; [email-masked]

---

From: Roni Even <[email-masked]>
Date: Tue, 30 Jun 2009 13:55:56 +0300

Hi guys,
My view is that this is not a general NACK problem but only for the case of
SSM and retransmission with similar box architecture to the RAMS solution.
If you have another case please explain
Roni

> Sent: Tuesday, June 30, 2009 10:19 AM
> Let's get the input from the WG on these points. I believe going for a
> more general solution that will be applicable to both RAMS and NACK is
> more desirable.
> 
> BR,
> -acbegen
> 
> 
> 
> > > > addresses, but are distinguished by means of a different SSRC.
> In
> > > > that
> > >

---

From: David R Oran <[email-masked]>
Date: Tue, 30 Jun 2009 09:10:26 -0400

> If you have another case please explain
I believe it is actually a MORE general problem than NACK or RAMS. I  
arises from mixing SSM sessions and unicast sessions for the same RTP- 
based application. That's because multicast enforces port symmetry  
among all the receivers while unicast needs per-receiver port selection.

So far we have two uses for mixing multicast and unicast:  
retransmission-based repair, and RAMS. I suspect more uses will arise  
in the future. I can think of a few off the top of my head:
- customized per-user overlays (e.g. to be alpha-blended with the  
video) or object-level replacement
- network-coded error recovery streams
- extra media info for re-integration when switching back from unicast  
to multicast in a fast-forward-to-realtime capability when doing  
"pause-live-content" style services
- adaptive switching between multicast and unicast based on number of  
simultaneous receivers.

I have a strong intuition that doing a generic mechanism to atomically  
signal ports for unicast sessions using the RTCP feedback machinery of  
the SSM session would be highly advisable.

So, I think:
a) we need to solve this problem
b) it exists even in the absence of NATs
c) we need a generic mechanism
d) it should be documented in a separate draft, and not part of RAMs  
or AVPF.

If we can agree to these points, then we can have a more detailed  
discussion of the appropriate machinery. I have opinions on that  
subject too.

DaveO.

---

From: Zeev Vax <[email-masked]>
Date: Tue, 30 Jun 2009 16:06:44 +0000

I agree this should be a separate draft and we should work on a more generic mechanism.
Two comments I have, first being a general problem it might have been solved already so I think we should research the area before investing in another draft. Second given such functionality is typically part of an application and not staying only in the lower network layers, the application can solve it as part of the startup sequence or other data delivery mechanism it has.

Zeev

-----Original Message-----
From: David R Oran [mailto:[email-masked]]
Sent: Tuesday, June 30, 2009 6:10 AM
To: Roni Even
Cc: 'Ali C. Begen (abegen)'; 'VAN CAENEGEM Tom'; 'Bill Ver Steeg (versteb)'; Zeev Vax; [email-masked]
Subject: Re: [AVT] Port mappings, NAT, and RAMS

So, I think:

DaveO.

---

From: Roni Even <[email-masked]>
Date: Tue, 30 Jun 2009 20:01:59 +0300

Zeev,
I think that this is not a general problem, I am not sure that RTCP should
enable a general way to convey transport addresses, we will need to open
this to discussion. 
Dave gave some probable cases but in my view the problem exists when there
are three important conditions:

1. No negotiation between both sides, no offer/answer like in declarative
SDP.  (prevent the receiver to offer a transport address)

2. The NACK /RAMS-R is going to one address while the response is coming
from a different address (like request to Feedback target in SSM and
response (may be RTP or RTCP) from retransmission server. This will prevent
using RTP/RTCP multiplexing

3. New one way communication (Like RTP from retransmission server and no RTP
from the receiver or previous unicast RTP to this receiver (multicast with
unicast retransmission). This prevent the receiver from opening a pinhole to
the source or from the retransmission server to do SSRC multiplexing like in
unicast retransmission. This is less limiting if you use RTP/RTCP
multiplexing based on resolving of condition 2 above in a way that will
enable RTP/RTCP multiplexing.

Roni Even

> Sent: Tuesday, June 30, 2009 7:07 PM
> To: David R Oran; Roni Even
> Cc: 'Ali C. Begen (abegen)'; 'VAN CAENEGEM Tom'; 'Bill Ver Steeg
> (versteb)'; [email-masked]
> Two comments I have, first being a general problem it might have been
> solved already so I think we should research the area before investing
> in another draft. Second given such functionality is typically part of
> an application and not staying only in the lower network layers, the
> application can solve it as part of the startup sequence or other data
> delivery mechanism it has.
> 
> Zeev
> 
> Of
> >>>> NACK) and the Pub-port message are in the same compound message.
> If
> >> we
> >>>
> >>> We "may" be able to say it from RAMS-R but not for NACK since we
> are
> >> not
> >>> unicast session from a FT is coupled to a ssm session with that
> same
> >> FT.
> >>>
> >>>
> >>>> defining this rule/clause as expressed above. In other words,
> there
> >> is
> >>>
> >>>> have the same SSRC. When a client is sending a receiver report,
> how
> >> do
> >>>
> >>> developed, is that now we are capable of advertising in SDP the
> SSRC
> >> of

---

From: "Bill Ver Steeg (versteb)" <[email-masked]>
Date: Tue, 30 Jun 2009 17:14:29 -0400

I agree that we should make a general solution for mapping unicast
sessions onto unicast sessions. 

We need to solve this problem using data flows that will work across
multiple vendors' solutions, and thus need to do it in a standards
forum. The IETF is the correct place to do this.

Bill VerSteeg 

-----Original Message-----
From: Zeev Vax [mailto:[email-masked]] 
Sent: Tuesday, June 30, 2009 9:07 AM
To: Dave Oran (oran); Roni Even
Cc: Ali C. Begen (abegen); 'VAN CAENEGEM Tom'; Bill Ver Steeg (versteb);
[email-masked]

I agree this should be a separate draft and we should work on a more
generic mechanism.

Zeev

-----Original Message-----
From: David R Oran [mailto:[email-masked]]
Sent: Tuesday, June 30, 2009 6:10 AM
To: Roni Even
Cc: 'Ali C. Begen (abegen)'; 'VAN CAENEGEM Tom'; 'Bill Ver Steeg
(versteb)'; Zeev Vax; [email-masked]
Subject: Re: [AVT] Port mappings, NAT, and RAMS

On Jun 30, 2009, at 6:55 AM, Roni Even wrote:

> Hi guys,
> My view is that this is not a general NACK problem but only for the 
> case of SSM and retransmission with similar box architecture to the 
> RAMS solution.
I believe it is actually a MORE general problem than NACK or RAMS. I
arises from mixing SSM sessions and unicast sessions for the same RTP-
based application. That's because multicast enforces port symmetry among
all the receivers while unicast needs per-receiver port selection.

retransmission-based repair, and RAMS. I suspect more uses will arise in
the future. I can think of a few off the top of my head:

So, I think:
a) we need to solve this problem
b) it exists even in the absence of NATs
c) we need a generic mechanism
d) it should be documented in a separate draft, and not part of RAMs or
AVPF.

If we can agree to these points, then we can have a more detailed
discussion of the appropriate machinery. I have opinions on that subject
too.

DaveO.

>> Let's get the input from the WG on these points. I believe going for 
>> a more general solution that will be applicable to both RAMS and NACK

>> is more desirable.

>>> defining it, we will be overloading its meaning, IMO. And as you/ 
>>> Bill pointed out in other emails, I also believe that this is more 
>>> general problem than just RAMS. We need something like pubports for 
>>> NACKs as well.
>>>
>>>

>>> sessions, it will introduce correlation problems. Receiver/XR 
>>> reports coming from a larger number of receivers will be difficult 
>>> to
>> identify
>>> the media server, that is in this case the retransmission server 
>>> SSRC used in the retransmission session. In fact for RAMS, we need 
>>> to
>> define

---

From: "Bill Ver Steeg (versteb)" <[email-masked]>
Date: Tue, 30 Jun 2009 17:14:36 -0400

Roni-

For the 2nd case, this problem also exists when the server's "request
port number" is different than the server's "response port number". This
is a very important case that breaks the port bindings in many NAT-ed
environments, and requires a standard solution. 

Bill VerSteeg

-----Original Message-----
From: Roni Even [mailto:[email-masked]] 
Sent: Tuesday, June 30, 2009 10:02 AM
To: 'Zeev Vax'; Dave Oran (oran)
Cc: Ali C. Begen (abegen); 'VAN CAENEGEM Tom'; Bill Ver Steeg (versteb);
[email-masked]

Zeev,
I think that this is not a general problem, I am not sure that RTCP
should enable a general way to convey transport addresses, we will need
to open this to discussion. 
Dave gave some probable cases but in my view the problem exists when
there are three important conditions:

1. No negotiation between both sides, no offer/answer like in
declarative SDP.  (prevent the receiver to offer a transport address)

2. The NACK /RAMS-R is going to one address while the response is coming
from a different address (like request to Feedback target in SSM and
response (may be RTP or RTCP) from retransmission server. This will
prevent using RTP/RTCP multiplexing

3. New one way communication (Like RTP from retransmission server and no
RTP from the receiver or previous unicast RTP to this receiver
(multicast with unicast retransmission). This prevent the receiver from
opening a pinhole to the source or from the retransmission server to do
SSRC multiplexing like in unicast retransmission. This is less limiting
if you use RTP/RTCP multiplexing based on resolving of condition 2 above
in a way that will enable RTP/RTCP multiplexing.

Roni Even

> >> To: VAN CAENEGEM Tom; Bill Ver Steeg (versteb); Zeev Vax; Roni 
> >> Even; [email-masked]
> >> Let's get the input from the WG on these points. I believe going 
> >> for a more general solution that will be applicable to both RAMS 
> >> and NACK is more desirable.
> >>
> >> BR,
> >> -acbegen
> >>
> >>
> >>
> >>> To: Ali C. Begen (abegen); Bill Ver Steeg (versteb); Zeev Vax; 
> >>> Roni
> >> Even; [email-masked]

> >>> general problem than just RAMS. We need something like pubports 
> >>> for NACKs
> as
> >>> well.
> >>>
> >>>
> >>>> no need for a pub-report message in this scenario and this 
> >>>> results
> >> NOT
> >>>

> >>>>> RTP/RTCP muxing too (as indicated in the declarative sdp 
> >>>>> received
> >> by
> >>>
> >>>>> the
> >>>>> RR)
> >>>>>
> >>>>> "return" channel for both streams have exactly the same 
> >>>>> transport addresses, but are distinguished by means of a
different SSRC.
> >> In
> >>>>> that
> >>>>
> >>>> How? Since SSM and retransmission sessions are session muxed, 
> >>>> they have the same SSRC. When a client is sending a receiver 
> >>>> report,
> how
> >> do
> >>>
> >>>> session muxing is used for retransmission, than the SSRC should 
> >>>> be
> >> the
> >>> same.
> >>>> SSRC used?  If there are no convincing arguments why we must 
> >>>> stick
> >> to
> >>>

---

From: Zeev Vax <[email-masked]>
Date: Wed, 1 Jul 2009 01:12:41 +0000

Roni,

My reference to general solution was beyond RTCP, any interactive two way application that have client in the cloud and not using HTTP over TCP, have the same issue. As Ethernet gaining more reliability UDP become a more valuable network solution, which will result in more application like that.

Zeev

-----Original Message-----
From: Bill Ver Steeg (versteb) [mailto:[email-masked]]
Sent: Tuesday, June 30, 2009 2:15 PM
To: Roni Even; Zeev Vax; Dave Oran (oran)
Cc: Ali C. Begen (abegen); VAN CAENEGEM Tom; [email-masked]
Subject: RE: [AVT] Port mappings, NAT, and RAMS

Roni-

Bill VerSteeg

-----Original Message-----
From: Roni Even [mailto:[email-masked]]
Sent: Tuesday, June 30, 2009 10:02 AM
To: 'Zeev Vax'; Dave Oran (oran)
Cc: Ali C. Begen (abegen); 'VAN CAENEGEM Tom'; Bill Ver Steeg (versteb);
[email-masked]

Zeev,

Roni Even

> Even;

different SSRC.

---

From: Zeev Vax <[email-masked]>
Date: Wed, 1 Jul 2009 01:12:42 +0000

I agree IETF is the right form, but I'm not sure the AVT WG is the right form as I think it is more general problem.

Zeev

-----Original Message-----
From: Bill Ver Steeg (versteb) [mailto:[email-masked]]
Sent: Tuesday, June 30, 2009 2:14 PM
To: Zeev Vax; Dave Oran (oran); Roni Even
Cc: Ali C. Begen (abegen); VAN CAENEGEM Tom; [email-masked]
Subject: RE: [AVT] Port mappings, NAT, and RAMS

Bill VerSteeg

-----Original Message-----
From: Zeev Vax [mailto:[email-masked]]
Sent: Tuesday, June 30, 2009 9:07 AM
To: Dave Oran (oran); Roni Even
Cc: Ali C. Begen (abegen); 'VAN CAENEGEM Tom'; Bill Ver Steeg (versteb);
[email-masked]

Zeev

-----Original Message-----
From: David R Oran [mailto:[email-masked]]
Sent: Tuesday, June 30, 2009 6:10 AM
To: Roni Even
Cc: 'Ali C. Begen (abegen)'; 'VAN CAENEGEM Tom'; 'Bill Ver Steeg

So, I think:

DaveO.

---

From: Roni Even <[email-masked]>
Date: Wed, 01 Jul 2009 07:58:51 +0300

Zeev,
You are right but I am trying to find the cases where for RTP/RTCP you
cannot address this on the application layer. For our work this means that
you cannot provide the information using SDP in offer/answer or declarative
way.
Roni

> Sent: Wednesday, July 01, 2009 4:13 AM
> To: Bill Ver Steeg (versteb); Roni Even; Dave Oran (oran)
> My reference to general solution was beyond RTCP, any interactive two
> way application that have client in the cloud and not using HTTP over
> TCP, have the same issue. As Ethernet gaining more reliability UDP
> become a more valuable network solution, which will result in more
> application like that.
> 
> Zeev
> 
> 
> 
> > >>>> The reason why we need pubports is that it indicates
> "explicitly"
> > >> the
> > >>>> information towards the Retransmission server is exactly the
> same
> > >> as
> > >>>> when an RTP receiver sends an RTCP compound message made up of
> an
> > >> RTCP
> > >>>
> > >>> in a separate draft which applies to any system architecture
> where
> > a
> > >>>> is -for that reason- no longer considered, I do not see a
> problem
> > >> with
> > >>>
> > >>> and match at the server side. There will be SSRC collisions,
> which
> > >> will
> > >>> TOM: the big difference with when the RFC 4588 was being
> discussed
> > >> and
> > >>> possibility (hence violating RFC 4588) as part of a new draft,
> the
> > >> one I
> > >>> mentioned above.
> > >>>
> > >>>
> > >>>> use case- I do not see why we should be limited by such a
> "rule".
> > >> The

---

From: Roni Even <[email-masked]>
Date: Wed, 01 Jul 2009 07:59:59 +0300

Bill,
If the server's sends the announcement using SDP this is not a problem
Roni

> Sent: Wednesday, July 01, 2009 12:15 AM

---

From: Roni Even <[email-masked]>
Date: Wed, 01 Jul 2009 08:01:50 +0300

Zeev,
The IETF has worked on it as part of BEHAVE WG and defined ICE for SDP based
systems
Roni

> To: Bill Ver Steeg (versteb); Dave Oran (oran); Roni Even
> Cc: VAN CAENEGEM Tom; [email-masked]
> I agree IETF is the right form, but I'm not sure the AVT WG is the
> right form as I think it is more general problem.
> 
> Zeev
> 
> among
> subject