Subject: [AVT] draft-ietf-avt-rapid-acquisition-for-rtp-07: Binding the RAMS-I to the RAMS-R and how to know that RAMS-R are updates

From: Magnus Westerlund <[email-masked]>
Date: Wed, 03 Mar 2010 07:29:26 -0800

I am concerned about the lack of clear binding between requests, RAMS-R
and RAMS-T and the RAMS-I. So a initial RAMS-R creates a burst and
utilizes a establish unicast session context to the client. The port
mapping part is not yet 100% certain, but I get the impression that
would be done by including a cookie that identifies the unicast session
5-tuple.

However, the RAMS-R does not contain a sequence number, nor does it
contain any hint to the clients identity other than the 5-tuple on the
RTCP packet. However, that 5-tuple may change, due to NAT timeouts or
failures. That would not have been a serious issue if it wasn't for the
problem that the client can't terminate the burst if that happens. Due
to the amount of data RAMS can send a client really should be able to
say no there is something wrong. Please stop. However, this needs to be
done securely so that it is not a vulnerability that an attacker can use
to prevent the client from getting service.

The next issue is that there is very unclear on how a RS can determine
that a RAMS-R message is an update or a new request. This needs to be
specified. This has two angles, the first one is how you are certain
that a RAMS-R addresses an existing context, the second one is how the
RS knows that it is an updated request and not a duplication or a
retransmission from the client.

In addition I also find the lack of binding between the RAMS-R and
RAMS-I problematic. As RAMS-I can be sent asynchronous the client
currently can't separate a RAMS-I as a result of server decided change
or the result of a RAMS-R.

As I see it there needs to be clarification on how you identify the
context if any for RAMS-R messages, secondly clear specification on when
a RAMS-R is considered new, secondly I think a binding between the
RAMS-R and the RAMS-I would benefit the client and allow it to draw the
conclusion that the request has reached the server.

Cheers

Magnus Westerlund

IETF Transport Area Director
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Wed, 3 Mar 2010 13:51:13 -0800

Hi Magnus,

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Magnus Westerlund
> Sent: Wednesday, March 03, 2010 10:29 AM
> To: IETF AVT WG
> Subject: [AVT] draft-ietf-avt-rapid-acquisition-for-rtp-07: Binding the RAMS-I to the RAMS-R and how
> to know that RAMS-R are updates
> 

There are a few different problems here.

If the NAT fails and/or binding changes after the server received the request and started bursting, the client can only understand that something was wrong after it times out (e.g., it sent an RAMS-R but has not received anything yet or started receiving something but then the burst pre-maturely ended). In the mean time, nobody knows that the burst has failed.

Regardless of whether the burst was successful or not (as above), the client must always send a RAMS-T. If it is received by the server, it will terminate the burst.

But, if you tie the cookie to the 5-tuple, this would not work since the server will check the 5-tuple for that rams-t and it will have different values, and the server will discard it. 

That's why in our draft, we are currently going for 2-tuple. As long as the cookie is valid, the server will use it and by checking the SSRC and cname of the packet sender, it can tie the incoming RTCP message to an existing RTP session. You said that this would not work but I am still trying to understand why it would not.

> that a RAMS-R addresses an existing context, the second one is how the

See above.

> retransmission from the client.

I don't think this is much relevant once the server can determine whether the rams-r is tied to an existing unicast session or not. If there is no existing unicast session, it has to consider it as a new request. IF there is an existing session, it just updates the parameters it is using (if possible).
 
> or the result of a RAMS-R.

Does it matter? The important thing the server has updated something and used 100 as the response code to let the client know. 

Remember that we are not trying to run a fully reliable protocol here.

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

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 22 Mar 2010 10:30:48 -0700

> If the NAT fails and/or binding changes after the server received the request and started bursting, the client can only understand that something was wrong after it times out (e.g., it sent an RAMS…

Yes, that is clearly what will happen in this case.
> Regardless of whether the burst was successful or not (as above), the client must always send a RAMS-T. If it is received by the server, it will terminate the burst.

I don't understand how the server can terminate the burst if it receives
an RAMS-T that doesn't match an existing context. So my question is that
you please clarify how this context is identified?

> But, if you tie the cookie to the 5-tuple, this would not work since the server will check the 5-tuple for that rams-t and it will have different values, and the server will discard it. 

Well, I think if you are having request response cookie, then including
that in the next request might be a solution to bind things together.

> That's why in our draft, we are currently going for 2-tuple. As long as the cookie is valid, the server will use it and by checking the SSRC and cname of the packet sender, it can tie the incoming…

Ok, I don't know if that is clear in the document. SSRC + cname has the
potential for containing enough random information to provide good
statistical separation. However, that requires that the cname is set in
way that make the client's unique.

>> that a RAMS-R addresses an existing context, the second one is how the

No, I don't understand how you separate a new request or an update. The
cookie describes the unicast transport. The SSRC and CNAME will not
change either. So what in the RAMS-R separates an update or a new burst
request?

But I think the disconnect here is what we consider an update or a new
request. So you are saying that an update is any RAMS-R that comes in
after the first RAMS-R on that specific RS port as long as there are a
burst. So if you want a new request you must send a RAMS-T followed by a
RAMS-R?

> I don't think this is much relevant once the server can determine whether the rams-r is tied to an existing unicast session or not. If there is no existing unicast session, it has to consider it as…

Hmm, so you are saying that due to a retransmission will contain the
same parameter, there should be no change to the burst. So you think
checking the full set of parameters are easier than having a sequence
number?

> Remember that we are not trying to run a fully reliable protocol here.

Yes, I think it matters. Because even if you are not trying to run a
fully reliable protocol the client still want to know if the request
reached the server or not. Currently there are no clear indication what
the RAMS-I relate to.

Cheers

Magnus Westerlund

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Mon, 22 Mar 2010 14:33:58 -0700

Hi Magnus,

A few comments inline.

...
> > That's why in our draft, we are currently going for 2-tuple. As long as the cookie is valid, the
> server will use it and by checking the SSRC and cname of the packet sender, it can tie the incoming
> RTCP message to an existing RTP session. You said that this would not work but I am still trying to
> understand why it would not.
> 

I believe 3550 already tells a lot about cnames. 
 
> burst. So if you want a new request you must send a RAMS-T followed by a

It is simple. If there is already a burst planned for or going to that particular client for the particular requested stream, the newly arriving RAMS-R is an update. Ow, it is a new request.

> > I don't think this is much relevant once the server can determine whether the rams-r is tied to an
> existing unicast session or not. If there is no existing unicast session, it has to consider it as a
> new request. IF there is an existing session, it just updates the parameters it is using (if
> possible).
> 

Well, when you say "full set of parameters" it sounds like a big deal, whereas it actually is not. You gotta do some checks anyway to figure whether there is a burst going on or not. 
 
> reached the server or not. Currently there are no clear indication what

If the server sent a response code 100, that notifies the client. I don't think we need more than this. RAMS-I seqnums would not correlate to RAMS-R seqnums (had we used them) anyway, so we better not number the RAMS-R messages to avoid confusion.

-acbegen

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 23 Mar 2010 09:06:07 -0700

> I believe 3550 already tells a lot about cnames. 

Yes, but I don't think the latest version I read was clear on how to
ensure that the RS matched up requests. So making clear that you use
SSSRC + CNAME and informationally pointing at the need for high quality
CNAMES. I do have to say that producing good quality CNAME isn't the
simplest thing.

> It is simple. If there is already a burst planned for or going to that particular client for the particular requested stream, the newly arriving RAMS-R is an update. Ow, it is a new request.

Ok, then it should be possible to write a few word on that.

> Well, when you say "full set of parameters" it sounds like a big deal, whereas it actually is not. You gotta do some checks anyway to figure whether there is a burst going on or not. 

Ok, if you say so. I just find this to be sloppy protocol design that is
likely to cause problems down the road if one likes to do any extension.

> If the server sent a response code 100, that notifies the client. I don't think we need more than this. RAMS-I seqnums would not correlate to RAMS-R seqnums (had we used them) anyway, so we better…

You clearly need two different sequence number spaces, one for binding
the request and another for enumerating RAMS-I.

Well, I don't like it, but I will hold my nose on this. But I expect
issues when the first extensions starts showing up.

Cheers

Magnus Westerlund

---

From: Colin Perkins <[email-masked]>
Date: Thu, 25 Mar 2010 20:13:51 +0000

On 23 Mar 2010, at 16:06, Magnus Westerlund wrote:
>>>> That's why in our draft, we are currently going for 2-tuple. As  
>>>> long as the cookie is valid, the server will use it and by  
>>>> checking the SSRC and cname of the packet sender, it can tie the  
>>>> incoming RTCP message to an existing RTP session. You said that  
>>>> this would not work but I am still trying to understand why it  
>>>> would not.
>>>
>>> Ok, I don't know if that is clear in the document. SSRC + cname  
>>> has the potential for containing enough random information to  
>>> provide good statistical separation. However, that requires that  
>>> the cname is set in way that make the client's unique.
>>

And the guidelines for generating a CNAME in RFC 3550 are not  
necessarily appropriate for a world with widespread NAT, and may need  
updating if you rely on particular properties of the CNAME.

-- 
Colin Perkins
http://csperkins.org/