Subject: [AVT] Open issues in the PortMapping draft

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

All,

Here is a list of open issues. We need your input to figure out the best way to address them. A revision is shortly coming up, and we will make frequent updates as necessary to make progress as fast as we can before the July meeting.

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

1- Message formats: There are a few reasons why the 4585 feedback message format is not particularly a good fit for requesting a PortMapping (PM) or responding to a PM request or including the Cookie in subsequent RTCP packets. One such reason is that the media sender SSRC field is not well defined in those messages.

We had similar concerns in the RAMS draft, yet we still used the 4585 format. Any objections if we do the same for this draft? If not, I suggest the client uses its own SSRC in both SSRC fields and the server does not change those values in its responses. That is, in both PM request and response messages, packet sender ssrc <- media sender ssrc <- client's SSRC.

2- Sub-message-type fields: Should we rather register one FMT value but multiple sub-FMT values for the PM request and response messages? Do you think we may need further message types in the future?

3- Client's CNAME/SSRC choices: The RTCP ports on the server (p3 and p4) MUST be different and the client MUST use the same SSRC and CNAME in the multicast and unicast sessions (to be consistent with session multiplexing as explained in the RAMS draft and 4588). This way, reports sent to ports p3 and p4 can be still linked together.

Any objections?

4- Keeping the NATs alive: Are RTCP receiver/extended reports enough to keep the bindings alive? Or, should we choose an option from I-D.ietf-avt-app-rtp-keepalive? Note that the client will have to keep the bindings open until a session is established and data flow starts. So, in addition to RTCP reports, we will most likely need something else as well.

5- Server's response to PM request messages: Does it have to be right away? If the request is rejected, could the server send a PM response message with an empty Cookie field?

Comments, thoughts are welcome.
-acbegen

---

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

Hi Ali,

Thank your summary, please see inline.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Ali C. Begen (abegen)
> Sent: Wednesday, May 19, 2010 5:27 AM
> To: IETF AVT WG
> Subject: [AVT] Open issues in the PortMapping draft
> 
> All,
> 
> Here is a list of open issues. We need your input to figure 
> out the best way to address them. A revision is shortly 
> coming up, and we will make frequent updates as necessary to 
> make progress as fast as we can before the July meeting.
> 
> 1- Message formats: There are a few reasons why the 4585 
> feedback message format is not particularly a good fit for 
> requesting a PortMapping (PM) or responding to a PM request 
> or including the Cookie in subsequent RTCP packets. One such 
> reason is that the media sender SSRC field is not well 
> defined in those messages.
> 
> We had similar concerns in the RAMS draft, yet we still used 
> the 4585 format. Any objections if we do the same for this 
> draft? If not, I suggest the client uses its own SSRC in both 
> SSRC fields and the server does not change those values in 
> its responses. That is, in both PM request and response 
> messages, packet sender ssrc <- media sender ssrc <- client's SSRC.

Agree~!

> 
> 2- Sub-message-type fields: Should we rather register one FMT 
> value but multiple sub-FMT values for the PM request and 
> response messages? 

That is better to create sub-FMT value for PM messages.

>Do you think we may need further message 
> types in the future?

> 
> 3- Client's CNAME/SSRC choices: The RTCP ports on the server 
> (p3 and p4) MUST be different and the client MUST use the 
> same SSRC and CNAME in the multicast and unicast sessions (to 
> be consistent with session multiplexing as explained in the 
> RAMS draft and 4588). This way, reports sent to ports p3 and 
> p4 can be still linked together.
> 
> Any objections?

It is OK for me.

> 
> 4- Keeping the NATs alive: Are RTCP receiver/extended reports 
> enough to keep the bindings alive? Or, should we choose an 
> option from I-D.ietf-avt-app-rtp-keepalive? Note that the 
> client will have to keep the bindings open until a session is 
> established and data flow starts. So, in addition to RTCP 
> reports, we will most likely need something else as well.
> 
> 5- Server's response to PM request messages: Does it have to 
> be right away? If the request is rejected, could the server 
> send a PM response message with an empty Cookie field?

If you adopt Sub-message-type in issue 2 and use FCI field to carry Cookie,
then a respond code is available to indicate success or failure. Defining a
specific failure type is expliciter than empty Cookie field to direct
client's next step action. 

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

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Wed, 19 May 2010 06:57:28 -0700

Here is the new version (addressing the earlier comments raised in the list):
https://datatracker.ietf.org/doc/draft-ietf-avt-ports-for-ucast-mcast-rtp

Diff:
http://tools.ietf.org/rfcdiff?url2=draft-ietf-avt-ports-for-ucast-mcast-rtp-02

-acbegen

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Ali C. Begen (abegen)
> Sent: Tuesday, May 18, 2010 5:27 PM
> To: IETF AVT WG
> Here is a list of open issues. We need your input to figure out the best way to address them. A
> revision is shortly coming up, and we will make frequent updates as necessary to make progress as fast
> as we can before the July meeting.
> 
> 1- Message formats: There are a few reasons why the 4585 feedback message format is not particularly a
> good fit for requesting a PortMapping (PM) or responding to a PM request or including the Cookie in
> subsequent RTCP packets. One such reason is that the media sender SSRC field is not well defined in
> those messages.
> 
> We had similar concerns in the RAMS draft, yet we still used the 4585 format. Any objections if we do
> the same for this draft? If not, I suggest the client uses its own SSRC in both SSRC fields and the
> server does not change those values in its responses. That is, in both PM request and response
> 2- Sub-message-type fields: Should we rather register one FMT value but multiple sub-FMT values for
> the PM request and response messages? Do you think we may need further message types in the future?
> 
> 3- Client's CNAME/SSRC choices: The RTCP ports on the server (p3 and p4) MUST be different and the
> client MUST use the same SSRC and CNAME in the multicast and unicast sessions (to be consistent with
> session multiplexing as explained in the RAMS draft and 4588). This way, reports sent to ports p3 and
> 4- Keeping the NATs alive: Are RTCP receiver/extended reports enough to keep the bindings alive? Or,
> should we choose an option from I-D.ietf-avt-app-rtp-keepalive? Note that the client will have to keep
> the bindings open until a session is established and data flow starts. So, in addition to RTCP
> 5- Server's response to PM request messages: Does it have to be right away? If the request is
> rejected, could the server send a PM response message with an empty Cookie field?
>

---

From: "Van Caenegem, Tom (Tom)" <[email-masked]>
Date: Fri, 21 May 2010 15:23:26 +0200

Hi Ali,

Some comments :
-related to your question 5: it makes more sense to include in the portmapping response message a response field that could be used to contain error codes similar as was defined for RAMS-I. I do not think you can impose timing requirements to an RS when responding to a port mapping response, other than the usual RTP AVPF timing rules.
-I would favour to keep "port mapping response" message as a name, whereas  a new message is defined, entitled e.g. "port mapping cookie" , to transfer the cookie along with a RAMS-R or NACK.  The only difference may be the response field presence, but it makes it easier to present this solution.
-If the port mapping request is sent several times by the RTP receiver (redundancy reasons), how should the RS react? You should also state that the random number inside the port mapping request must then be kept the same.
 
Then a comment with the risk of being criticised as counter-productive.;-)

I notice that you know stipulate that the SSRC name in SDES message accompanying RTCP messages in the primary RTP ssm session and accompanying the RTCP messages in the unicast RTP retransmission sessions must be used by the RS to associate them together. For this reason you also submitted the draft-begen-avt-rtp-cnames, an effort I applaude!

But... The reason why the simpler non-cookie solution I proposed  to enable the port mapping, was turned down in Anaheim was exactly because the association of the RTCP messages in the two sessions had to be done via C-NAME, but as it could not be guaranteed that C-NAMES were unique, the solution could not be guaranteed to work well in all cases.

Because the cookie-based solution clearly has some disadvantages compared to not using cookies (additional RTT impacting channel change time, server that needs to generate cookies, need for a keep-alive mechanism and additional security threats like stealing cookies etc ) I wonder what the remaining rationale is for not defining the non-cookie approach in IETF for RAMS and retransmissions.

Regards
Tom

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ali C. Begen (abegen)
Sent: woensdag 19 mei 2010 15:57
To: IETF AVT WG
Subject: Re: [AVT] Open issues in the PortMapping draft

Diff:

-acbegen

> Here is a list of open issues. We need your input to figure out the 
> best way to address them. A revision is shortly coming up, and we will 
> make frequent updates as necessary to make progress as fast as we can before the July meeting.
> 
> 1- Message formats: There are a few reasons why the 4585 feedback 
> message format is not particularly a good fit for requesting a 
> PortMapping (PM) or responding to a PM request or including the Cookie 
> in subsequent RTCP packets. One such reason is that the media sender SSRC field is not well defined in those messages.
> 
> We had similar concerns in the RAMS draft, yet we still used the 4585 
> format. Any objections if we do the same for this draft? If not, I 
> suggest the client uses its own SSRC in both SSRC fields and the 
> server does not change those values in its responses. That is, in both PM request and response messages, packet sender ssrc <- media sender ssrc <- client's SSRC.
> 
> 2- Sub-message-type fields: Should we rather register one FMT value 
> but multiple sub-FMT values for the PM request and response messages? Do you think we may need further message types in the future?
> 
> 3- Client's CNAME/SSRC choices: The RTCP ports on the server (p3 and 
> p4) MUST be different and the client MUST use the same SSRC and CNAME 
> in the multicast and unicast sessions (to be consistent with session 
> multiplexing as explained in the RAMS draft and 4588). This way, 
> reports sent to ports p3 and
> 4- Keeping the NATs alive: Are RTCP receiver/extended reports enough 
> to keep the bindings alive? Or, should we choose an option from 
> I-D.ietf-avt-app-rtp-keepalive? Note that the client will have to keep 
> the bindings open until a session is established and data flow starts. So, in addition to RTCP reports, we will most likely need something else as well.
> 
> 5- Server's response to PM request messages: Does it have to be right 
> away? If the request is rejected, could the server send a PM response message with an empty Cookie field?
>

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Fri, 21 May 2010 17:22:49 -0700

Hi Tom,

> From: Van Caenegem, Tom (Tom) [mailto:[email-masked]]
> Sent: Friday, May 21, 2010 9:23 AM
> To: Ali C. Begen (abegen); IETF AVT WG
> Subject: RE: [AVT] Open issues in the PortMapping draft
> 
> Hi Ali,
> 
> Some comments :
> -related to your question 5: it makes more sense to include in the portmapping response message a
> response field that could be used to contain error codes similar as was defined for RAMS-I. I do not
> think you can impose timing requirements to an RS when responding to a port mapping response, other
> than the usual RTP AVPF timing rules.
> -I would favour to keep "port mapping response" message as a name, whereas  a new message is defined,
> entitled e.g. "port mapping cookie" , to transfer the cookie along with a RAMS-R or NACK.  The only
> difference may be the response field presence, but it makes it easier to present this solution.

OK, any other opinions on this?

> -If the port mapping request is sent several times by the RTP receiver (redundancy reasons), how
> should the RS react? You should also state that the random number inside the port mapping request must
> then be kept the same.

Thinking more about this, I don’t think we need to have a random number and we can safely remove it from the cookie.
 
> I notice that you know stipulate that the SSRC name in SDES message accompanying RTCP messages in the
> primary RTP ssm session and accompanying the RTCP messages in the unicast RTP retransmission sessions
> must be used by the RS to associate them together. For this reason you also submitted the draft-begen-
> avt-rtp-cnames, an effort I applaude!

Thanks, that should resolve the CNAME issues. But on the cookie side, I don't think we need CNAMEs in the hashing, either.
 
> But... The reason why the simpler non-cookie solution I proposed  to enable the port mapping, was
> turned down in Anaheim was exactly because the association of the RTCP messages in the two sessions
> had to be done via C-NAME, but as it could not be guaranteed that C-NAMES were unique, the solution
> could not be guaranteed to work well in all cases.
> 
> Because the cookie-based solution clearly has some disadvantages compared to not using cookies
> (additional RTT impacting channel change time, server that needs to generate cookies, need for a keep-
> alive mechanism and additional security threats like stealing cookies etc ) I wonder what the
> remaining rationale is for not defining the non-cookie approach in IETF for RAMS and retransmissions.

I believe we can combine your http://www.ietf.org/proceedings/77/slides/avt-10.pdf idea with the cookie proposal.

This will avoid sending the keep-alives, while still getting the security benefit of the cookies proving return routability (which prevents the attack Magnus described in http://www.ietf.org/mail-archive/web/avt/current/msg12617.html). This way, the client needs only a single cookie (can obtain at boot time) regardless of how many different local ports it uses (in the current scheme we need one cookie per local port).

I'll email you offline to set up a time to talk.

-acbegen