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

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Tue, 18 May 2010 11:14:50 -0700

Sorry for the delay. We are revising the spec with the changes agreed on so far. But, majority of the open issues are still remaining. See inline.

> Hi Ali and Tom,
> 
> I agree the majority opinions from Tom.
> 
> a) each couple of PMReq and PMRes should be exchanged prior to RTCP message
> which solicits a forthcoming unicast RTP session on different destinatioin
> port, e.g., one PM round-trip plans to map on P3 for unicast retransmission,
> another PM round-trip plans tomap on P4 for unicast burst. If the third
> unicast session uses P5 by server and client (client can request multiple
> unicast bursts in session multiplexing case through different ports), you
> need to perform one more PM round-trip for P5. should we mention this?

Not really, the client may retrieve multiple cookies at the same time since they are on different ports. If they are not requested in parallel, of course the delay will add up.
 
> In PMReq, client can use its own SSRC in media sender field. Becasue it only
> aims to establish port mapping on NAT without any SSRC relevancy.  I perfer
> to reuse message format defined in RFC4585 rather than define new message
> format header for port mapping messages.

I tend to agree. The client uses its own SSRC in both the packet sender and media source fields in the PMReq message. I suggest the server does not change those fields in the PMRes message.

In other words, the Cookie is not tied to the media sender SSRC, could only be tied to the client's SSRC.

Is this proposal OK with everyone?

> 
> b) I also prefer use same format to carry cookie both on PMReq and PMRes. Is
> it fit to reuse NACK message to respond to PMRes? Or define a new PMNack

You mean if the server rejects the cookie request message? In that case, it can send PMRes with an empty Cookie field, I guess.

> message (FMT=9) just like PMReq and PMRes? Otherwise, what's the values
> setted in the PID and BLD field in NACK? Another point, sending NACK to P3
> seems to be illogical from whole round-trip integrality point of view.

Not sure what you mean here.
 
> c) I agree to use SSRC to indentify the client in order to link unicast
> session and SSM session.

I will put this down as an editor's note. I tend to agree that the client uses the same SSRC/CNAME in the unicast and multicast sessions so things are linked to each other.
 
> d) In security considerations, I don't understand how to use CNAME to aviod
> cookie stealing in non-compound RTCP message.

We hope to get a more mature text soon.

-acbegen
 
> BR
> Jinwei

---

From: Jinwei Xia <[email-masked]>
Date: Wed, 19 May 2010 09:30:52 +0800

Hi Ali,

Thank your response! Please see inline.

<snip>

> 
> In other words, the Cookie is not tied to the media sender 
> SSRC, could only be tied to the client's SSRC.
> 

It is fine for me.

> 
> > 
> > b) I also prefer use same format to carry cookie both on PMReq and 
> > PMRes. Is it fit to reuse NACK message to respond to PMRes? 
> Or define 
> > a new PMNack
> 
> You mean if the server rejects the cookie request message? In 
> that case, it can send PMRes with an empty Cookie field, I guess.

You partly solve my question, another question is we all know that NACK
message is used to indicate the loss of one or more RTP packets [RFC4585].
In Figure 3, do you reuse aforementioned NACK message  or define a new
format NACK message to respond PMRes?  If you use former, What's the values
in PID and BLD field in RTCP NACK? They make no sense to PM. 

> 
> > message (FMT=9) just like PMReq and PMRes? Otherwise, what's the 
> > values setted in the PID and BLD field in NACK? Another 
> point, sending 
> > NACK to P3 seems to be illogical from whole round-trip 
> integrality point of view.
> 

I would like to use P4 as destination port of RTCP NACK, I am not sure why
use P3 rather than P4.

Thank you

Jinwei

>  
> > c) I agree to use SSRC to indentify the client in order to link 
> > unicast session and SSM session.
> 
> I will put this down as an editor's note. I tend to agree 
> that the client uses the same SSRC/CNAME in the unicast and 
> multicast sessions so things are linked to each other.
>  
> > d) In security considerations, I don't understand how to 
> use CNAME to 
> > aviod cookie stealing in non-compound RTCP message.
>

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Tue, 18 May 2010 20:37:38 -0700

I sent out an email about the current open issues, please review that email as well. Inline. 

> -----Original Message-----
> From: Jinwei Xia [mailto:[email-masked]]
> Sent: Tuesday, May 18, 2010 9:31 PM
> To: Ali C. Begen (abegen); 'VAN CAENEGEM Tom'; Bill Ver Steeg (versteb); 'IETF AVT WG'
> Subject: RE: [AVT] New Version Notificationfordraft-ietf-avt-ports-for-ucast-mcast-rtp-01
> 
> 
> Hi Ali,
> 

The NACK is used as defined in 4585, no change at all. The Cookie included in a newly defined RTCP message and sent along with the NACK message in the same RTCP packet. 
 
> I would like to use P4 as destination port of RTCP NACK, I am not sure why

NACKs for the SSM packets go to the feedback target of the SSM session, which is P3. If the unicast session is the retransmission session for the SSM session, it is not allowed to use NACKs in that retransmission session per 4588. If the unicast session is not a retransmission session for the SSM session (e.g., it is used to send new unicast data), you can use NACKs in that unicast session if you need and in that case, P4 will be used for that purpose.

In our example, the unicast session is the retransmission session so NACKs must go to P3 not P4.

Cheers, acbegen

---

From: Jinwei Xia <[email-masked]>
Date: Wed, 19 May 2010 12:01:55 +0800

Hi Ali,

Thank your clarification, see inline.

<snip>

> > I would like to use P4 as destination port of RTCP NACK, I 
> am not sure 
> > why use P3 rather than P4.
> 
> NACKs for the SSM packets go to the feedback target of the 
> SSM session, which is P3. If the unicast session is the 
> retransmission session for the SSM session, it is not allowed 
> to use NACKs in that retransmission session per 4588. If the 
> unicast session is not a retransmission session for the SSM 
> session (e.g., it is used to send new unicast data), you can 
> use NACKs in that unicast session if you need and in that 
> case, P4 will be used for that purpose.
> 

It is more clear. Figure 3 is an PM example for retransmission session. But
in RAMS scenario, RAMS-R is used to establish the unicast session, do we
need NACK with Cookie field to respond PMRes? If need, it should be sent to
P3 or P4?

Thank you.

Jinwei

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Tue, 18 May 2010 21:36:16 -0700

Hi Jinwei

> Sent: Wednesday, May 19, 2010 12:02 AM

In that case, the RTCP packet carrying the RAMS-R message must carry the cookie as well. This message goes to P3.

> need NACK with Cookie field to respond PMRes? If need, it should be sent to

Again, NACKs are not modified at all. So, there is no Cookie field in the NACK messages. Cookie is included in a new message (which this draft should define - and I suppose we can use PMRes message for this) and this new message is sent along with the NACK or RAMS-R message depending on the scenario.

-acbegen

---

From: Jinwei Xia <[email-masked]>
Date: Wed, 19 May 2010 14:26:29 +0800

Hi Ali,

> > It is more clear. Figure 3 is an PM example for retransmission 
> > session. But in RAMS scenario, RAMS-R is used to establish 
> the unicast 
> > session, do we
> 
> In that case, the RTCP packet carrying the RAMS-R message 
> must carry the cookie as well. This message goes to P3.
> 
> Again, NACKs are not modified at all. So, there is no Cookie 
> field in the NACK messages. Cookie is included in a new 
> message (which this draft should define - and I suppose we 
> can use PMRes message for this) and this new message is sent 
> along with the NACK or RAMS-R message depending on the scenario.

Oops~ I misunderstand the NACK is the third step of PM setup just like TCP
three-way handshake. Because PM is fit to retransmission and RAMS, as well
as the title of Figure 3 is "Message flows for establishing a unicast
session", so I misunderstand the Figure3 is common example to all scenarios.

If we need a confirm message with Cookie field from client to server, I
prefer a new message to NACK or RAMS-R message. 

BR
Jinwei