Subject: [AVT] FW: New Version Notification for draft-ietf-avt-rapid-acquisition-for-rtp-12

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Wed, 25 Aug 2010 12:38:26 -0700

RAMS has been rev'ed to -12. For diff, refer to:
http://tools.ietf.org/rfcdiff?url1=draft-ietf-avt-rapid-acquisition-for-rtp-11&difftype=--html&submit=Go!&url2=draft-ietf-avt-rapid-acquisition-for-rtp-12

Let us know if there are any remaining comments.

-acbegen

-----Original Message-----
From: IETF I-D Submission Tool [mailto:[email-masked]] 
Sent: Wednesday, August 25, 2010 10:34 PM
To: Ali C. Begen (abegen)
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: New Version Notification for draft-ietf-avt-rapid-acquisition-for-rtp-12 

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

Filename:	 draft-ietf-avt-rapid-acquisition-for-rtp
Revision:	 12
Title:		 Unicast-Based Rapid Acquisition of Multicast RTP Sessions
Creation_date:	 2010-08-25
WG ID:		 avt
Number_of_pages: 52

Abstract:
When an RTP receiver joins a multicast session, it may need to
acquire and parse certain Reference Information before it can process
any data sent in the multicast session.  Depending on the join time,
length of the Reference Information repetition (or appearance)
interval, size of the Reference Information as well as the
application and transport properties, the time lag before an RTP
receiver can usefully consume the multicast data, which we refer to
as the Acquisition Delay, varies and can be large.  This is an
undesirable phenomenon for receivers that frequently switch among
different multicast sessions, such as video broadcasts.

In this document, we describe a method using the existing RTP and
RTCP protocol machinery that reduces the acquisition delay.  In this
method, an auxiliary unicast RTP session carrying the Reference
Information to the receiver precedes/accompanies the multicast
stream.  This unicast RTP flow can be transmitted at a faster than
natural bitrate to further accelerate the acquisition.  The
motivating use case for this capability is multicast applications
that carry real-time compressed audio and video.  However, the
proposed method can also be used in other types of multicast
applications where the acquisition delay is long enough to be a
problem.

The IETF Secretariat.

---

From: Robert Sparks <[email-masked]>
Date: Thu, 26 Aug 2010 14:33:40 -0500

Ali -

Thanks for the quick revision. What's the status on addressing my question about the definition of the error codes?

I found this version much easier to read.

RjS

On Aug 25, 2010, at 2:38 PM, Ali C. Begen (abegen) wrote:

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

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 26 Aug 2010 13:11:18 -0700

Hi Robert,

Sorry, apparently that new section was missing in yesterday's version. I just submitted a new version.
https://datatracker.ietf.org/doc/draft-ietf-avt-rapid-acquisition-for-rtp/

See section 11.6.1.

-acbegen

> From: Robert Sparks [mailto:[email-masked]]
> Sent: Thursday, August 26, 2010 10:34 PM
> Cc: [email-masked]
> Subject: Re: [AVT] FW: New Version Notification for draft-ietf-avt-rapid-acquisition-for-rtp-12
> 
> Ali -
>

---

From: Robert Sparks <[email-masked]>
Date: Thu, 26 Aug 2010 15:39:50 -0500

Thanks again!

The added section is just an expansion of the short phrase associated with the code.
Having this expansion helps clarify when one of these codes might get sent, but it doesn't help
answer how to interpret one when you get it.

Here are some questions that are still open for me (if they're answered in the draft already, I apologize,
please point me to the answer in the text):

1) I can infer from this list that a BRS might send both a 200 and a 201? Is there any guidance in the text
    about when its ok not to send one of them? Should an implementation receiving a 200 expect to see a
    201?

2) Some of these seem to indicate a recoverable condition - for instance if something receives a
     401, 402, 403, are you expecting a new RAMS-R to be emitted with values that aren't invalid?
     Where does the text define "valid"? 

3) Do you expect the recipient of a 501 to try to recover? If so, what's its recovery action, and what
     would it do differently if it got a 503? If not, why aren't you just sending a 500?

4) Do you expect something that receives a 500 to automatically retry? If so, when? What keeps a
     tight request->fail loop from happening?

5) Is 511 really a failure? I'm reading this to say that the BRS is answering the request and sending
    a burst, but only with preamble information even though the request might have asked for more.
   (Where is the text that says that?) 

RjS

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 26 Aug 2010 14:02:53 -0700

Hi Robert,

> Sent: Thursday, August 26, 2010 11:40 PM

When the request is accepted, BRS sends 200. Sending an additional RAMS-I with 201 is naturally optional since the client will know about the burst completion time through other means (RAMS-I).
 
>      401, 402, 403, are you expecting a new RAMS-R to be emitted with values that aren't invalid?

That is really up to the client. The server does not need to keep state about this. So if a new RAMS-R arrives with valid info, the server processes it as it is a new request. Note that client-side errors indicate a config or implementation problem on the client. So, I'd imagine that if a client causes a 400-level error in the first message, it won't be likely sending a correct RAMS-R in the second attempt.

>      Where does the text define "valid"?

We did not define it explicitly. However, I expect the natural rules will apply. For example, if the mcast stream is 10 Mbps but the client says its max receive bitrate is 5 Mbps, the server can easily see as an invalid value.
 
>      would it do differently if it got a 503? If not, why aren't you just sending a 500?

Recovery is totally up to the client implementation. E.g., simply joining the mcast session at that moment may be a better strategy. Or the client may re-try some time later. We have separate response codes (e.g., 501 vs 503) because the client can report them back to the provider using the XR report we have defined. Those specific error codes allow the provider to address them more appropriately. See:
https://datatracker.ietf.org/doc/draft-ietf-avt-multicast-acq-rtcp-xr/ 

>      tight request->fail loop from happening?

As I said above, this is implementation specific and scenario specific. In IPTV, it might be better to give up and do a simple join (e.g., when the BRS reports insufficient resources). In other apps, the client might still prefer to go with the RAMS option and in that case it can retry shortly.

OTOH, if the requested multicast stream is not available for the RAMS service, the client should naturally not try again.

> 5) Is 511 really a failure? I'm reading this to say that the BRS is answering the request and sending

As I recall we discussed this a bit earlier. We called it a failure case since the client is asking for something but the server is sending less.

>     a burst, but only with preamble information even though the request might have asked for more.

Yes, exactly. Note that the client may have requested only the preamble (tlv type 5) and in that case sending only the preamble is not a failure and the server sends a 200. 

>    (Where is the text that says that?)

The text in 11.6.1 is not sufficient?

-acbegen

---

From: Robert Sparks <[email-masked]>
Date: Thu, 26 Aug 2010 16:21:58 -0500

> When the request is accepted, BRS sends 200. Sending an additional RAMS-I with 201 is naturally optional since the client will know about the burst completion time through other means (RAMS-I).
Where in the text does it say either of those things? (In particular, I read what you write above to imply that a 200 is mandatory - where is that in the text?)

> That is really up to the client. The server does not need to keep state about this. So if a new RAMS-R arrives with valid info, the server processes it as it is a new request. Note that client-side…

So why do you have anything other than just 400?

> We did not define it explicitly. However, I expect the natural rules will apply. For example, if the mcast stream is 10 Mbps but the client says its max receive bitrate is 5 Mbps, the server can ea…

So, again, why do you have anything other than just 500? If the client isn't expected to recover, knowing which of the values was bad doesn't help it.
If it _is_ expected to recover, not having some common understanding of what "valid" reduces the semantics of the response to the bring-me-a-rock game.

> https://datatracker.ietf.org/doc/draft-ietf-avt-multicast-acq-rtcp-xr/ 

You should say this in the text.

> As I said above, this is implementation specific and scenario specific.
The text should say that.
> In IPTV, it might be better to give up and do a simple join (e.g., when the BRS reports insufficient resources). In other apps, the client might still prefer to go with the RAMS option and in that case it can retry shortly.
> 

You didn't answer what keeps a tight request->fail loop from happening? 

> The text in 11.6.1 is not sufficient?

I don't believe it is. Nothing in the current text captures the condition of sending this response only if the client asked for more than the preamble or that you would use a 200 if they didn't.

A lot of what seems "natural" to you is because you've been living this for years and you have an implementation. There is a lot you are assuming that isn't written down that looks like it
would effect interoperability. A new implementer is going to have to guess at what behavior is expected. For example, would you expect it to be acceptable to send a 200 and later send a 511? If not, what piece of text says you can't? Would you expect a 511 to be followed by a 201?

---

From: "Van Caenegem, Tom (Tom)" <[email-masked]>
Date: Fri, 27 Aug 2010 10:43:21 +0200

..some additional thoughts
Tom 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ali C. Begen (abegen)
Sent: donderdag 26 augustus 2010 23:03
To: Robert Sparks
Cc: [email-masked]
Subject: Re: [AVT] FW: New Version Notification for draft-ietf-avt-rapid-acquisition-for-rtp-12

Hi Robert,

> Subject: Re: [AVT] FW: New Version Notification for 
> draft-ietf-avt-rapid-acquisition-for-rtp-12
> 
> Thanks again!
> 
> Having this expansion helps clarify when one of these codes might get 
> sent, but it doesn't help answer how to interpret one when you get it.
> 
> Here are some questions that are still open for me (if they're 
> answered in the draft already, I apologize, please point me to the answer in the text):
> 

TOM: Ali added the phrase in section 6.2, step 3 (response): 

"Accept Responses:  The BRS MUST send at least one separate
           RAMS-I message with the appropriate response code (either
           zero indicating a private response or a 2xx-level response
           code indicating success as listed in Section 11.6) for each
           primary multicast stream that has been requested by the
           RTP_Rx and will be served by the BRS." 

Reading this again, we should replace in the text above 2xx with 200!

For the "reject responses" section, it may make sense to include in this text that a reject response code is either 4xx, 5xx or zero, with the exception of 502 (burst is terminated due to congestion) - as this response code assumes that the RAMS request has been previously accepted.

I found one additional item in this same paragraph that deserves some attention. It says: 

If the RTP_Rx has requested to acquire the whole primary
           multicast RTP session but the BRS cannot provide a rapid
           acquisition service for any of the primary multicast streams,
           the BRS MUST reject the request via a single RAMS-I message
           with a collective reject response code and whose media sender
           SSRC field is set to one of SSRCs served by this FT_Ap.  Upon
           receiving this RAMS-I message, the RTP_Rx abandons the rapid
           acquisition attempt and can immediately join the multicast
           session by sending an SFGMP Join message towards its upstream
           multicast router. In all other cases, the BRS MUST send a separate RAMS-I
           message with the appropriate response code for each primary
           multicast stream that has been requested by the RTP_Rx but
           cannot be served by the BRS.

My comment: in fact, a RTP Rx cannot distinguish between such a "collective reject response" and a "reject response" for a single SSRC, and hence will need to wait for any additional RAMS-I message that still may be sent. We can solve this by either mandating that the accept and reject RAMS-I messages must be sent in a single compound  (we have such statement for the "accept response" section following, but it only applies if the BRS can accept all SSRC burst requests) or we define a new separate (generic) collective reject response code.

TOM: 

-for the 400, we can stick to the word "invalid" (as this is about syntax).
-for the 403, I propose to redefine as  "This is used when the maximum receive bitrate value indicated in the RAMS-R message is insufficient"   ("Insufficient" iso "invalid")
-for the 401/402, I have no suggestion as I do not see a good use case behind the definition of these

TOM: 

I agree with this, but it brings up another issue: while we have a TLV for the RAMS-R that explicitly asks for a pre-amble only  (which we do not define in this draft.. And its definition is still quite unresolved as you know), we have no means for a RTP Rx to indicate it supports the pre-amble (or otherwise stated: the RTP Rx will be happy to receive the pre-amble if it cannot get the requested burst from the BRS). So, how can a BRS decide to send or not send the pre-amble, when it supports sending a preamble - only?  A way out here would be to define a new TLV for RAMS-R that says " RTP Rx supports pre-amble". The response from the BRS on a RAMS-R with such a TLV  could then be a reject response code 511 with the preamble sent.

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Fri, 27 Aug 2010 02:37:37 -0700

I chatted with Robert yesterday. A revision is due soon. Further inline.

> From: Van Caenegem, Tom (Tom) [mailto:[email-masked]]
> Sent: Friday, August 27, 2010 11:43 AM
> To: Ali C. Begen (abegen); Robert Sparks
> Cc: [email-masked]
> Subject: RE: [AVT] FW: New Version Notification fordraft-ietf-avt-rapid-acquisition-for-rtp-12
> 
> When the request is accepted, BRS sends 200. Sending an additional RAMS-I with 201 is naturally optional since the client will
> know about the burst completion time through other means (RAMS-I).
> 
> 
> 

We can but I did not want to remove the possibility a future 2xx level code overriding 200. But, if you think 200 is always the way to go, we can change it to 200.
 
> For the "reject responses" section, it may make sense to include in this text that a reject response code is either 4xx, 5xx or
> zero, with the exception of 502 (burst is terminated due to congestion) - as this response code assumes that the RAMS
> request has been previously accepted.
> 
> My comment: in fact, a RTP Rx cannot distinguish between such a "collective reject response" and a "reject response" for a
> single SSRC, and hence will need to wait for any additional RAMS-I message that still may be sent. We can solve this by either
> mandating that the accept and reject RAMS-I messages must be sent in a single compound  (we have such statement for the
> "accept response" section following, but it only applies if the BRS can accept all SSRC burst requests) or we define a new
> separate (generic) collective reject response code.

Is not 510 enough for this?
 
> We did not define it explicitly. However, I expect the natural rules will apply. For example, if the mcast stream is 10 Mbps
> but the client says its max receive bitrate is 5 Mbps, the server can easily see as an invalid value.
> 
> 
> TOM:
> 
> -for the 403, I propose to redefine as  "This is used when the maximum receive bitrate value indicated in the RAMS-R
> message is insufficient"   ("Insufficient" iso "invalid")

I am ok with these.
 
> Yes, exactly. Note that the client may have requested only the preamble (tlv type 5) and in that case sending only the
> preamble is not a failure and the server sends a 200.
> 
> I agree with this, but it brings up another issue: while we have a TLV for the RAMS-R that explicitly asks for a pre-amble only
> (which we do not define in this draft.. And its definition is still quite unresolved as you know), we have no means for a RTP Rx
> to indicate it supports the pre-amble (or otherwise stated: the RTP Rx will be happy to receive the pre-amble if it cannot get

There are two cases:
i) RTP_Rx explicitly asks for the preamble and it may get it from the server. This has no issues.
ii) RTP_Rx asks for a burst but the server responds with the preamble only. In this case, the RTP_Rx, if it does not understand it, discards the data. Still no failure.

> the requested burst from the BRS). So, how can a BRS decide to send or not send the pre-amble, when it supports sending a
> preamble - only?  A way out here would be to define a new TLV for RAMS-R that says " RTP Rx supports pre-amble". The
> response from the BRS on a RAMS-R with such a TLV  could then be a reject response code 511 with the preamble sent.

We thought about defining such a TLV but then the issue is which preamble format. What if there are alternative approaches. In that case using a private tlv makes more sense since things will not collide with each other. As I mentioned above, even if a non-preamble-capable client gets preamble data, it should not fail since it will silently discard the data (per RTP rules).

-acbegen

---

From: "Van Caenegem, Tom (Tom)" <[email-masked]>
Date: Fri, 27 Aug 2010 12:16:01 +0200

Ali,
See below.
Tom

TOM: let's make it 200.

> My comment: in fact, a RTP Rx cannot distinguish between such a 
> "collective reject response" and a "reject response" for a single 
> SSRC, and hence will need to wait for any additional RAMS-I message 
> that still may be sent. We can solve this by either mandating that the 
> accept and reject RAMS-I messages must be sent in a single compound  (we have such statement for the "accept response" section following, but it only applies if the BRS can accept all SSRC burst requests) or we define a new separate (generic) collective reject response code.

TOM: That response code is fine, but then we need to state this code explicitly in the text (iso having " the BRS MUST reject the request via a single RAMS-I message with a collective reject response code)

> I agree with this, but it brings up another issue: while we have a TLV 
> for the RAMS-R that explicitly asks for a pre-amble only (which we do 
> not define in this draft.. And its definition is still quite 
> unresolved as you know), we have no means for a RTP Rx to indicate it 
> supports the pre-amble (or otherwise stated: the RTP Rx will be happy 
> to receive the pre-amble if it cannot get

There are two cases:

> the requested burst from the BRS). So, how can a BRS decide to send or 
> not send the pre-amble, when it supports sending a preamble - only?  A 
> way out here would be to define a new TLV for RAMS-R that says " RTP Rx supports pre-amble". The response from the BRS on a RAMS-R with such a TLV  could then be a reject response code 511 with the preamble sent.

TOM: as the preamble is not defined yet, can we be sure it will have a different RTP payload type?
I also think that having a BRS sending data that a RTP receiver did not request neither recognises nor is interested in, is a good protocol design. In addition, sending the pre-amble -when not explicitly allowed for or requested by the receiver- may also cause interference with the IP Multicast acquisition following the failed RAMS-request. For instance, take the case where the RTP receiver only wanted a subset of the multicast RTP streams that make up the SSM (because the RTP receiver has not sufficient BW to allow bursting of the entire SSM), and the BRS rejects the request. If then the BRS starts sending the pre-amble-only, simultaneously with the receiver receiving the (unbursted) SSM,  this may cause packet loss. Especially for RAMS requests which have been rejected, the BRS should only send the pre-amble if the RTP receiver accepted to receive so.  I think this is a void in the current RAMS text, and we should add a explicit statement in the section "reject response" e.g.  "a BRS MUST not send any-premable (instead of the requested burst) unless explicitly allowed for by the RTP receiver via the TLV type 5 or a private extension in the RAMS-R message"

-acbegen

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Fri, 27 Aug 2010 04:32:06 -0700

Hi Tom,

> way to go, we can change it to 200.

OK, I changed it.
 
> > accept and reject RAMS-I messages must be sent in a single compound  (we have such statement for the "accept response"
> section following, but it only applies if the BRS can accept all SSRC burst requests) or we define a new separate (generic)
> collective reject response code.
> 
> TOM: That response code is fine, but then we need to state this code explicitly in the text (iso having " the BRS MUST reject
> the request via a single RAMS-I message with a collective reject response code)

Ok, done.
 
> > way out here would be to define a new TLV for RAMS-R that says " RTP Rx supports pre-amble". The response from the BRS
> on a RAMS-R with such a TLV  could then be a reject response code 511 with the preamble sent.
> 
> We thought about defining such a TLV but then the issue is which preamble format. What if there are alternative
> approaches. In that case using a private tlv makes more sense since things will not collide with each other. As I mentioned
> above, even if a non-preamble-capable client gets preamble data, it should not fail since it will silently discard the data (per
> RTP rules).
> 
> 

I guess you are specifically referring to MPEG2TS. And for that one, it has to be a different payload type as I mentioned before. 

However, independent from that, for other preambles that can use the same payload format (if such preamble exists), the support for it will be automatic since the client already supports the primary payload type which is identical to the preamble payload format.

> I also think that having a BRS sending data that a RTP receiver did not request neither recognises nor is interested in, is a
> good protocol design. In addition, sending the pre-amble -when not explicitly allowed for or requested by the receiver- may
> also cause interference with the IP Multicast acquisition following the failed RAMS-request. For instance, take the case

So, does this mean you are objecting to the use case for code 511? In other words, you don't want the server to send the preamble *only* unless it is explicitly asked for. Or you don’t want the server to send any preamble unless the client asked for it regardless of whether the burst will be provided or not. These are two different things.

> where the RTP receiver only wanted a subset of the multicast RTP streams that make up the SSM (because the RTP receiver
> has not sufficient BW to allow bursting of the entire SSM), and the BRS rejects the request. If then the BRS starts sending the
> pre-amble-only, simultaneously with the receiver receiving the (unbursted) SSM,  this may cause packet loss. Especially for

I don’t think it is a big concern. When we were discussing this, as I recall we thought it could be still advantageous to provide at least the preamble when the whole burst would not be provided. 

> RAMS requests which have been rejected, the BRS should only send the pre-amble if the RTP receiver accepted to receive so.
> I think this is a void in the current RAMS text, and we should add a explicit statement in the section "reject response" e.g.  "a
> BRS MUST not send any-premable (instead of the requested burst) unless explicitly allowed for by the RTP receiver via the
> TLV type 5 or a private extension in the RAMS-R message"

Type 5 is different. It says "send only the preamble" not "send also the preamble."

And as I said earlier signaling support a specific preamble format in a public TLV could be misleading due to the possibility of existence of more than one format on the server or in the SDP. If that were not the case, adding a new TLV for the RAMS-R (Support for Preamble) would be the ideal solution.

So, based on your suggestion, I propose the following:

1- We remove type 5
2- We remove code 511

One can still define a new public TLV for supporting a particular preamble format (i.e., in the preamble specification) or use a private TLV. This is something we don’t need to deal with in this draft.

3- Add text: "The BRS MUST NOT send preamble information in a particular format unless the RTP_Rx has signaled support for that format in the RAMS-R message through a public or private extension."

This requires explicit signaling from the client. However, it is somewhat different than what you said in the sense that the server can still respond to a RAMS-R with sending preamble only. I don't think we should forbid it.

Let me know if you are ok with this.

-acbegen

---

From: "Van Caenegem, Tom (Tom)" <[email-masked]>
Date: Fri, 27 Aug 2010 14:47:41 +0200

Ali,

Thanks for your FB. See further below..

> > I agree with this, but it brings up another issue: while we have a 
> > TLV for the RAMS-R that explicitly asks for a pre-amble only (which 
> > we do not define in this draft.. And its definition is still quite 
> > unresolved as you know), we have no means for a RTP Rx to indicate 
> > it supports the pre-amble (or otherwise stated: the RTP Rx will be 
> > happy to receive the pre-amble if it cannot get
> 
> There are two cases:
> ii) RTP_Rx asks for a burst but the server responds with the preamble 
> only. In this case, the RTP_Rx, if it does not understand it, discards the data. Still no failure.
> 
> > the requested burst from the BRS). So, how can a BRS decide to send 
> > or not send the pre-amble, when it supports sending a preamble - 
> > only?  A way out here would be to define a new TLV for RAMS-R that 
> > says " RTP Rx supports pre-amble". The response from the BRS
> We thought about defining such a TLV but then the issue is which 
> preamble format. What if there are alternative approaches. In that 
> case using a private tlv makes more sense since things will not 
> collide with each other. As I mentioned above, even if a non-preamble-capable client gets preamble data, it should not fail since it will silently discard the data (per RTP rules).
> 
> 

> I also think that having a BRS sending data that a RTP receiver did 
> not request neither recognises nor is interested in, is a good 
> protocol design. In addition, sending the pre-amble -when not 
> explicitly allowed for or requested by the receiver- may also cause 
> interference with the IP Multicast acquisition following the failed 
> RAMS-request. For instance, take the case

So, does this mean you are objecting to the use case for code 511? In other words, you don't want the server to send the preamble *only* unless it is explicitly asked for. Or you don't want the server to send any preamble unless the client asked for it regardless of whether the burst will be provided or not. These are two different things.

TOM: I am not objecting against 511 as such. See my example: I do not want that the BRS automatically sends the preamble iso a burst to a receiver, even though the receiver indicated support for the pre-amble. 

> where the RTP receiver only wanted a subset of the multicast RTP 
> streams that make up the SSM (because the RTP receiver has not 
> sufficient BW to allow bursting of the entire SSM), and the BRS 
> rejects the request. If then the BRS starts sending the 
> pre-amble-only, simultaneously with the receiver receiving the 
> (unbursted) SSM,  this may cause packet loss. Especially for

I don't think it is a big concern. When we were discussing this, as I recall we thought it could be still advantageous to provide at least the preamble when the whole burst would not be provided. 

> I think this is a void in the current RAMS text, and we should add a 
> explicit statement in the section "reject response" e.g.  "a BRS MUST 
> not send any-premable (instead of the requested burst) unless explicitly allowed for by the RTP receiver via the TLV type 5 or a private extension in the RAMS-R message"

1- We remove type 5
2- We remove code 511

One can still define a new public TLV for supporting a particular preamble format (i.e., in the preamble specification) or use a private TLV. This is something we don't need to deal with in this draft.

TOM:  

-If we add the text as you propose, then I do not see why you would want to get rid of code 511? Or do you propose that the response code must be 0 or a future defined value in the 5xx range, if the BRS does not send a burst and only a preamble. We cannot use the 200 code here, as then the RTP Rx will not know if the burst will still follow (and just sending the pre-amble is BTW not a success).

-What I still miss is the distinction between the RTP Rx allowing the BRS for sending a pre-amble when the BRS will not send the burst (a failure) and the RTP Rx allowing the BRS for sending a pre-amble together with a burst (success). 

As we may have several pre-amble payload formats, I agree it does in fact not make sense to define now a TLV      "request for pre-amble only", as a RS may in principle advertise support for multiple premable formats. What does make sense is to define the TLV option "Preamble-only allowed", which states that the RTP receiver is willing to receive only a preamble when it cannot get the RAMS burst(s).

In summary, 

1)I agree with removing type 5 TLV but replace it with a different one (which we could still call type 5) called something like "preamble-only allowed"
2)I do not see why we should get rid of response code 511
3)I propose to  extend your proposed phrase as follows :

"The BRS MUST NOT send preamble information in a particular format unless the RTP_Rx has signaled support for that format in the RAMS-R message through a public or private extension. Furthermore, within these constraints, the BRS MAY respond to a RAMS request with the response code of 511 in the RAMS-I message together with only the preamble (no burst), if the RTP-Rx included the "Preamble-only allowed" TLV in its RAMS-R message. 

I think this text then needs to fit in the step 4 (unicast burst) of section 6.2

Tom

-acbegen

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Fri, 27 Aug 2010 06:32:02 -0700

> One can still define a new public TLV for supporting a particular preamble format (i.e., in the preamble specification) or use
> a private TLV. This is something we don't need to deal with in this draft.
> 
> 3- Add text: "The BRS MUST NOT send preamble information in a particular format unless the RTP_Rx has signaled support
> for that format in the RAMS-R message through a public or private extension."
> 
> This requires explicit signaling from the client. However, it is somewhat different than what you said in the sense that the
> server can still respond to a RAMS-R with sending preamble only. I don't think we should forbid it.
> 
> -If we add the text as you propose, then I do not see why you would want to get rid of code 511? Or do you propose that the
> response code must be 0 or a future defined value in the 5xx range, if the BRS does not send a burst and only a preamble.
> We cannot use the 200 code here, as then the RTP Rx will not know if the burst will still follow (and just sending the pre-
> amble is BTW not a success).

Correct, cannot use 200 and that is not the intention. I thought we could leave that to those future specs (if they ever come out). But, if you are also ok with it, lets do the changes above but keep 511, though.

> 
> -What I still miss is the distinction between the RTP Rx allowing the BRS for sending a pre-amble when the BRS will not send
> the burst (a failure) and the RTP Rx allowing the BRS for sending a pre-amble together with a burst (success).

If the client signals support for preamble:
i) 200 will indicate that the burst will follow (most likely with preamble as well and the client is ready to get it)
ii) 511 will indicate only the preamble will follow
iii) another 5xx level code meaning nothing will be sent

Do you think we also need semantics for "send me preamble even if you don't send the burst"? Is not that an overkill? As I mentioned earlier, this is something we can easily defer to future specs since they will be defining the TLVs for signaling support for preamble.
 
> As we may have several pre-amble payload formats, I agree it does in fact not make sense to define now a TLV      "request
> for pre-amble only", as a RS may in principle advertise support for multiple premable formats. What does make sense is to
> define the TLV option "Preamble-only allowed", which states that the RTP receiver is willing to receive only a preamble when
> it cannot get the RAMS burst(s).

See my response above.
 
> 1)I agree with removing type 5 TLV but replace it with a different one (which we could still call type 5) called something like

So, the support for the particular preamble is signaled thru another TLV and this type-5 TLV is generic saying that "I am glad to receive only the preamble in the format I signaled above". We can do this but as I said this is not something we need to define here.

> 2)I do not see why we should get rid of response code 511

We are keeping it.

> "The BRS MUST NOT send preamble information in a particular format unless the RTP_Rx has signaled support for that
> format in the RAMS-R message through a public or private extension. Furthermore, within these constraints, the BRS MAY
> respond to a RAMS request with the response code of 511 in the RAMS-I message together with only the preamble (no burst),
> if the RTP-Rx included the "Preamble-only allowed" TLV in its RAMS-R message.

OK, I will go with this one.

-acbegen

---

From: Roni Even <[email-masked]>
Date: Sat, 28 Aug 2010 11:49:17 +0300

Hi guys,
I support the approach on preamble as suggested by Tom and the proposed text
from Tom - 
"The BRS MUST NOT send preamble information in a particular format unless
the RTP_Rx has signaled support for that
format in the RAMS-R message through a public or private extension.
Furthermore, within these constraints, the BRS MAY
respond to a RAMS request with the response code of 511 in the RAMS-I
message together with only the preamble (no burst),
if the RTP-Rx included the "Preamble-only allowed" TLV in its RAMS-R
message."

And I thought Ali agreed to add it. Will there be a 14 version of the draft?

Roni
As individual

> Sent: Friday, August 27, 2010 4:32 PM
> To: Van Caenegem, Tom (Tom); Robert Sparks
> Cc: [email-masked]
> Subject: Re: [AVT] FW: New Version Notification fordraft-ietf-avt-
> rapid-acquisition-for-rtp-12
> 
> > One can still define a new public TLV for supporting a particular
> preamble format (i.e., in the preamble specification) or use
> > 3- Add text: "The BRS MUST NOT send preamble information in a
> particular format unless the RTP_Rx has signaled support
> > This requires explicit signaling from the client. However, it is
> somewhat different than what you said in the sense that the
> > -If we add the text as you propose, then I do not see why you would
> want to get rid of code 511? Or do you propose that the
> > response code must be 0 or a future defined value in the 5xx range,
> if the BRS does not send a burst and only a preamble.
> > We cannot use the 200 code here, as then the RTP Rx will not know if
> the burst will still follow (and just sending the pre-
> Correct, cannot use 200 and that is not the intention. I thought we
> could leave that to those future specs (if they ever come out). But, if
> you are also ok with it, lets do the changes above but keep 511,
> though.
> 
> >
> > -What I still miss is the distinction between the RTP Rx allowing the
> BRS for sending a pre-amble when the BRS will not send
> > the burst (a failure) and the RTP Rx allowing the BRS for sending a
> pre-amble together with a burst (success).
> 
> i) 200 will indicate that the burst will follow (most likely with
> preamble as well and the client is ready to get it)
> Do you think we also need semantics for "send me preamble even if you
> don't send the burst"? Is not that an overkill? As I mentioned earlier,
> this is something we can easily defer to future specs since they will
> be defining the TLVs for signaling support for preamble.
> 
> > As we may have several pre-amble payload formats, I agree it does in
> fact not make sense to define now a TLV      "request
> > for pre-amble only", as a RS may in principle advertise support for
> multiple premable formats. What does make sense is to
> > define the TLV option "Preamble-only allowed", which states that the
> RTP receiver is willing to receive only a preamble when
> > 1)I agree with removing type 5 TLV but replace it with a different
> one (which we could still call type 5) called something like
> > "preamble-only allowed"
> 
> So, the support for the particular preamble is signaled thru another
> TLV and this type-5 TLV is generic saying that "I am glad to receive
> only the preamble in the format I signaled above". We can do this but
> as I said this is not something we need to define here.
> 
> > "The BRS MUST NOT send preamble information in a particular format
> unless the RTP_Rx has signaled support for that
> > format in the RAMS-R message through a public or private extension.
> Furthermore, within these constraints, the BRS MAY
> > respond to a RAMS request with the response code of 511 in the RAMS-I
> message together with only the preamble (no burst),

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Sat, 28 Aug 2010 02:14:18 -0700

Yes we already made the changes regarding the preamble. The new text looks much better. We will release v14 soon. We just need to address the remaining comments from Robert about the code usage. I am hoping to do it over the weekend.

-acbegen

> From: Roni Even [mailto:[email-masked]]
> Sent: Saturday, August 28, 2010 11:49 AM
> To: Ali C. Begen (abegen); 'Van Caenegem, Tom (Tom)'; 'Robert Sparks'
> Cc: [email-masked]
> Subject: RE: [AVT] FW: New Version Notificationfordraft-ietf-avt-rapid-acquisition-for-rtp-12
> 
> Hi guys,
> > message.