Subject: [AVT] Updated AD review: draft-ietf-avt-rapid-acquisition-for-rtp-14

From: Robert Sparks <[email-masked]>
Date: Thu, 2 Sep 2010 15:49:13 -0500

Summary: The majority of my concerns have been addressed. Two sticking points
         (the first two below) and a number of minor suggestions remain:

* I'm still confused about when a 511 will get used. I am guessing
  that the intent is that it will only get used if the request contained
  the new type-5 TLV value, and would get used _instead of_ a 200 if the
  server is only going to send preamble information. (That is, the server
  will not send a 200 and then later send a 511). If that's right, the
  semantics of using a "rejection" code to accept part of a request are
  likely to confuse new implementers. If you are partially accepting the
  request, consider using a new 2xx code. If that's not reasonable, then
  call attention to this oddness in the text on accepting requests:
           "The BRS MUST send at least one separate
           RAMS-I message with the appropriate response code (either
           zero indicating a private response or response code 200
           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." 
  by adding something like
           "Note that if the BRS is only sending preamble information,
            it will not accept the request, but will send a 511 rejection
            response instead."

* I am still concerned about the interoperability of a RAMS-I with a
  response code of zero. I'm finding this text particularly confusing:

    When the RTP_Rx receives an RAMS-I message with a private response 
    code that it does not understand, the RTP_Rx still needs to process  
    the TLV elements it understands.

  Should this have said "with a private TLV" instead of "with a private
  response code"?

  Based on the responses to my question on the list, I think the intent 
  is the following. If I have it right, the document should explicitly 
  call these things out:

   - Private TLVs can appear in any RAMS message (RAMS-R, RAMS-I, or RAMS-T)
   - An element receiving a private TLV that it does not understand ignores
     that TLV (regardless of the message type).

  And if the response code was zero, it is still not clear what an element
  is supposed to do with the message if it doesn't understand what the real 
  (private) response is. If I receive a response with a code of zero and
  I don't understand _any_ of the private TLVs (especially the one that
  tells me what the response actually means), do you still want me to try
  to take action on any TLVs with types 31-35 that might be in there? If so,
  am I supposed to treat the RAMS-I the way I would have treated a RAMS-I
  with a response code of 200, 100, or what? What am I supposed to do with
  the data these TLVs are giving me? It seems really dangerous for me to
  assume that this 0 with nothing in it I understand to tell me what the 0
  really means indicates that I'm actually going to get a burst just because
  there is a 34 block in it. And it's really unclear what I should do if one
  of these 0's follows a 200, and has different data in it than the 200 did
  (Nothing in the spec prevents that). I suggest that this attempt leads to 
  madness and propose that you add something like the following:

    The semantics of a RAMS-I message with a response code of 0 
    is determined by one or more private TLV blocks in the message. 
    If an element receives a RAMS-I message with a response code of 0,
    and it does not understand enough of the private TLV blocks to know
    what the private response code is, it MUST ignore the RAMS-I message.

* From my comments on -11
  - 6.2 step 9, last paragraph on page 21 : Is it possible that the
    BRS would already be past the point of sending the burst packet
    with an OSN matching the sequence number in the RAMS-T message
    when the RAMS-T message arrives and is processed?
  Ali's response was
  -  Could be. This is implementation specific. The BRS may prefer 
     to overlap or fill a gap (and fill the gap later via retransmissions).

  This response is confusing - there is text that constrains the BRS:
        Then, the BRS MUST
        terminate the respective burst after it sends the unicast burst
        packet whose Original Sequence Number (OSN) field in the RTP
        retransmission payload header matches this number minus one.

  The BRS's preference doesn't seem to come into play. Further, this
  text should be amended to deal with the case where the packet with
  that OSN match has already been sent, perhaps long ago. I suggest
  adding:
       If the BRS has already sent that unicast burst packet when the
       RAMS-T message arrives, the BRS MUST terminate the respective
       burst immediately.

* From my comments on -11
  - 6.5 fifth paragraph. The BRS _will_ (not _can_) continue sending
    burst packets in the case of a lost RAMS_T. There's no way for the
    RTP_Rx to know these messages were lost, so how would the RTP_Rx
    know it was "In such cases". Are you wanting the RTP_RX to _always_
    repeat the RAMS_T message or are you intending the
    recommended retransmission behavior to apply only if the RTP_Rx
    is still receiving burst packets after sinding a RAMS_T?
  Ali's response was
  - If the BRS is configured to stop the burst at a point (as a precaution), 
    it may stop the burst. RAMS-T can be repeated following the RTCP FB 
    rules. If the burst is still going on, that is a clear indication that 
    RAMS-T did not make it. I don't think we need to mandate repeated RAMS-T's.

  Given that, I suggest adjusting that paragraph to the following:

    In the case a RAMS-T message sent by the RTP_Rx does not reach its
    destination, the BRS might continue sending burst packets even though
    the RTP_Rx no longer needs them.  If an RTP_Rx is receiving burst packets
    it no longer needs after sending a RAMS-T message, it is RECOMMENDED
    that the RTP_Rx repeats the RAMS-T message multiple times based on
    the RTCP timer rules defined in [RFC4585].  The BRS MUST be
    provisioned to terminate the burst when it can no longer send the
    burst packets faster than it receives the primary multicast stream
    packets.
       
* 7.3 Definition of type 33
    There is a lowercase "should" in the third paragraph - should that
    have been SHOULD?

* 7.4 definition of type 34:
   Where you say "delta difference" you should say only "difference". The word
   delta in this context doesn't make sense.

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 2 Sep 2010 14:43:33 -0700

Hi Robert,

Thanks for the review. Let me try to address the remaining comments.

> -----Original Message-----
> From: Robert Sparks [mailto:[email-masked]]
> Sent: Thursday, September 02, 2010 11:49 PM
> To: [email-masked]
> Cc: Ali C. Begen (abegen)
> Subject: Updated AD review: draft-ietf-avt-rapid-acquisition-for-rtp-14
> 

Correct.

>   will not send a 200 and then later send a 511). If that's right, the

It will only send 511 (and the preamble).

>             it will not accept the request, but will send a 511 rejection

OK, this is a good idea.
 
>   Should this have said "with a private TLV" instead of "with a private

Private TLVs are not supposed to be understood by others anyway. Similarly, private response codes cannot be processed by others, either (this is what this text says). But, even if a RAMS-I has a private response code, there could be public TLVs that everybody can understand and act on. 

Make sense?
 
>    - Private TLVs can appear in any RAMS message (RAMS-R, RAMS-I, or RAMS-T)

Correct.

>      that TLV (regardless of the message type).

Correct.
 
>   to take action on any TLVs with types 31-35 that might be in there? If so,

(I ack that a server responding with a private code to a client that would not understand is not a likely case)

What is the alternative? Ignore everything?

I think such a client should take action on tlvs 31-35 since they could still mean something to the client. For example, join time (33) would be useful. 

>     what the private response code is, it MUST ignore the RAMS-I message.

OK, but what if the server keeps sending a burst?

Maybe, we should require the client to send RAMS-T right away? If it will not process the RAMS-I, it cannot use any burst anyway. And since it is required to send RAMS-T at some point, why not send it right away?

>        RAMS-T message arrives, the BRS MUST terminate the respective

Sure.
 
>     burst packets faster than it receives the primary multicast stream

Looks good to me.
 
>     There is a lowercase "should" in the third paragraph - should that

Fine with me. I believe my suggestion was a MUST, but SHOULD is good enough. 

>    delta in this context doesn't make sense.

Right, that should be removed.

Should we go ahead with one more revision?

Cheers, acbegen.

---

From: Robert Sparks <[email-masked]>
Date: Thu, 2 Sep 2010 16:51:27 -0500

>>     that TLV (regardless of the message type).

Ok - can you please make sure the document clearly says those things somewhere?

> Maybe, we should require the client to send RAMS-T right away? If it will not process the RAMS-I, it cannot use any burst anyway. And since it is required to send RAMS-T at some point, why not send…
That would address my concern.

> Should we go ahead with one more revision?

Please (assuming nobody objects quickly to the suggestion to send a RAMS-T above)

---

From: Roni Even <[email-masked]>
Date: Fri, 03 Sep 2010 01:56:21 +0300

Hi,
I want to address the private extensions and 0 response code. I think that a
similar problem may occur for vendor-neutral extension which are optional to
support and this will not be with 0 response code. 

Maybe the right approach is to allow the BRS to use only private extensions
or vendor-neutral extensions that the RTP_Rx signaled support for in the
RAMS-R. 
Another way is to divide the extensions to those that can be ignored with no
problem while only for those that cannot be ignored require that the RTP-Rx
will signal support in the RAMS-R.

I think that terminating the burst by the RTP_Rx when receiving an extension
(it can also be vendor-neutral one) that it does not understand in the
RAMS-I was not the intention, the intention was to ignore the extensions but
it looks like there may be issues with ignoring.

Roni Even
As individual

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Ali C. Begen (abegen)
> Sent: Friday, September 03, 2010 12:44 AM
> To: Robert Sparks; [email-masked]
> Subject: Re: [AVT] Updated AD review: draft-ietf-avt-rapid-acquisition-
> for-rtp-14
> 
> Hi Robert,
> 
> Private TLVs are not supposed to be understood by others anyway.
> Similarly, private response codes cannot be processed by others, either
> (this is what this text says). But, even if a RAMS-I has a private
> response code, there could be public TLVs that everybody can understand
> and act on.
> 
> Make sense?
> 
> (I ack that a server responding with a private code to a client that
> would not understand is not a likely case)
> 
> I think such a client should take action on tlvs 31-35 since they could
> still mean something to the client. For example, join time (33) would
> be useful.
> 
> Maybe, we should require the client to send RAMS-T right away? If it
> will not process the RAMS-I, it cannot use any burst anyway. And since
> it is required to send RAMS-T at some point, why not send it right
> away?
> 
> >
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

---

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

> From: Roni Even [mailto:[email-masked]]
> Sent: Friday, September 03, 2010 1:56 AM
> To: Ali C. Begen (abegen); 'Robert Sparks'; [email-masked]
> Subject: RE: [AVT] Updated AD review:draft-ietf-avt-rapid-acquisition-for-rtp-14
> 
> Hi,

Lets say a client receives a non-zero response code that it does not understand (e.g., it was registered recently and client's implementation is older). Then, I think the same rule would apply. If you don't understand the response code, send a RAMS-T.
 
> or vendor-neutral extensions that the RTP_Rx signaled support for in the

There is no efficient way for the client to indicate which private extensions as well as public extensions (beyond the mandatory ones) it supports.

> will signal support in the RAMS-R.

I think the current approach is satisfactory. We have defined the mandatory elements that everybody needs to support. Beyond that others are optional and can be safely ignored.
 
> it looks like there may be issues with ignoring.

Right, as Robert pointed out it may lead to some interesting scenarios. Normally, this is very unlikely to happen IMO but the document should cover it. And sending a RAMS-T is the best solution we can offer IMO.

Cheers, acbegen.

---

From: Roni Even <[email-masked]>
Date: Fri, 03 Sep 2010 12:49:09 +0300

Hi Ali,
I think I did not clarify my meaning, since I am not sure I understand what
is the proposal here.

The document allows private and vendor-neutral TLV extensions. As far as I
understand there can be a RAMS-I message with 200 response code that will
include vendor-neutral TLV extensions and not only RAMS-I with 0 response
code that includes private extensions, is this correct?

I noticed two recommendations from your response in this thread and I am not
sure I fully understand what is recommended.

1. I think the current approach is satisfactory. We have defined the
mandatory elements that everybody needs to support. Beyond that others are
optional and can be safely ignored.
Question: Does it mean that the only allowed TLV extensions are ones that
can be ignored. In which case why is the next recommendation?

2. Maybe, we should require the client to send RAMS-T right away? If it will
not process the RAMS-I, it cannot use any burst anyway. And since it is
required to send RAMS-T at some point, why not send it right away?

Question: if we take this approach it means that the server will not be able
to use TLV extensions (private or vendor neutral) in RAMS-I since he cannot
be sure if the RTP_Rx supports this extensions?

Thanks
Roni Even

> From: Ali C. Begen (abegen) [mailto:[email-masked]]
> Sent: Friday, September 03, 2010 4:57 AM
> To: Roni Even; Robert Sparks; [email-masked]
> Lets say a client receives a non-zero response code that it does not
> understand (e.g., it was registered recently and client's
> implementation is older). Then, I think the same rule would apply. If
> you don't understand the response code, send a RAMS-T.
> 
> There is no efficient way for the client to indicate which private
> extensions as well as public extensions (beyond the mandatory ones) it
> supports.
> 
> I think the current approach is satisfactory. We have defined the
> mandatory elements that everybody needs to support. Beyond that others
> are optional and can be safely ignored.
> 
> Right, as Robert pointed out it may lead to some interesting scenarios.
> Normally, this is very unlikely to happen IMO but the document should
> cover it. And sending a RAMS-T is the best solution we can offer IMO.
> 
> Cheers, acbegen.
> 
> > Roni Even
> > As individual
> >
> > > > Subject: Updated AD review: draft-ietf-avt-rapid-acquisition-for-
> rtp-
> > > 14
> > > >
> > > >   the new type-5 TLV value, and would get used _instead of_ a 200
> if
> > > the
> > > >   server is only going to send preamble information. (That is,
> the
> > > server
> > >
> > > Correct.
> > >
> > > >   will not send a 200 and then later send a 511). If that's
> right,
> > > the
> > >
> > > >   semantics of using a "rejection" code to accept part of a
> request
> > > are
> > > >   likely to confuse new implementers. If you are partially
> accepting
> > > the
> > > >   request, consider using a new 2xx code. If that's not
> reasonable,
> > > then
> > > >    - Private TLVs can appear in any RAMS message (RAMS-R, RAMS-I,
> or
> > > RAMS-T)
> > >
> > > Correct.
> > >
> > > >    - An element receiving a private TLV that it does not
> understand
> > > ignores
> > > >   And if the response code was zero, it is still not clear what
> an
> > > element
> > > >   is supposed to do with the message if it doesn't understand
> what
> > > the real
> > > >   (private) response is. If I receive a response with a code of
> zero
> > > and
> > > >   I don't understand _any_ of the private TLVs (especially the
> one
> > > that
> > > >   tells me what the response actually means), do you still want
> me to
> > > try
> > > >   to take action on any TLVs with types 31-35 that might be in
> there?
> > > If so,
> > >
> > > >   am I supposed to treat the RAMS-I the way I would have treated
> a
> > > RAMS-I
> > > >   with a response code of 200, 100, or what? What am I supposed
> to do
> > > with
> > > >   the data these TLVs are giving me? It seems really dangerous
> for me
> > > to
> > > >   assume that this 0 with nothing in it I understand to tell me
> what
> > > the 0
> > > >   really means indicates that I'm actually going to get a burst
> just
> > > because
> > > >   there is a 34 block in it. And it's really unclear what I
> should do
> > > if one
> > > >   of these 0's follows a 200, and has different data in it than
> the
> > > 200 did
> > > >   (Nothing in the spec prevents that). I suggest that this
> attempt
> > > leads to
> > > >     If an element receives a RAMS-I message with a response code
> of
> > > 0,
> > > >     and it does not understand enough of the private TLV blocks
> to
> > > know
> > > >     burst packets in the case of a lost RAMS_T. There's no way
> for
> > > the
> > > >     it may stop the burst. RAMS-T can be repeated following the
> RTCP
> > > FB
> > > >     rules. If the burst is still going on, that is a clear
> indication
> > > that
> > > >     RAMS-T did not make it. I don't think we need to mandate
> repeated
> > > RAMS-T's.
> > > >
> > > >     In the case a RAMS-T message sent by the RTP_Rx does not
> reach
> > > its
> > > >     destination, the BRS might continue sending burst packets
> even
> > > though
> > > >     the RTP_Rx no longer needs them.  If an RTP_Rx is receiving
> burst
> > > packets
> > > >     that the RTP_Rx repeats the RAMS-T message multiple times
> based
> > > on
> > > Fine with me. I believe my suggestion was a MUST, but SHOULD is
> good
> > > enough.
> > >
> > > >    Where you say "delta difference" you should say only
> "difference".
> > > The word

---

From: Robert Sparks <[email-masked]>
Date: Fri, 3 Sep 2010 10:12:37 -0500

Hi Ali -

I had a short voice conversation with Roni to make sure I  understood his point, and he
asked me to summarize what we talked about here.

The concern is that we are clear about the extensibility model in the draft. We want it
to be clear that private TLVs can appear in any message, and in almost all cases are
ignored if they are not understood. The one special case is for a RAMS-I with a response
code of zero, where the TLV that says what the semantics of this response are has to be
understood. It needs to be clear that 1) There has to be a private TLV that has that information
and 2) The recipient MUST understand it, or give up and send an immediate RAMS-T.

It would also help to note that if one of the IANA registered response codes has the right
semantics, the server should use it instead of making a private code with the same semantics.

Right now the protocol does not have a generic "requires" mechanism - something that
says "you must understand this TLV or you must reject (or perform some other special
treatment of) this message". There's no way to tell the recipient of some future IANA
registered TLV that it should do anything other than ignore it if it doesn't understand it.
That limitation should be clearly stated (assuming it's acceptable).

Similarly, there's no way to tell the recipient of some future vendor-neutral response code
that there are any special semantics associated with this code that it MUST understand
to be able to process the message. The document needs to be clear about what a
recipient of a RAMS-I with a response-code in the IANA registered range that it doesn't
know is supposed to do. (Is that there already?)

That doesn't mean that that some negotiation of future behavior isn't possible with
what's defined now. A future standardized set of TLV extensions could use a pattern
of allowing a new standard TLV block with a code of B to appear in a message
sent by a server only if the RAMS-R had a new standard TLV block with a code of A.
That is, clients could signal support for extensions, and would know whether servers
supported the extension only by whether it got used. This would not allow servers
to reject a message claiming "I don't support that extension". If anybody thinks that's
important, the protocol needs a mechanism it's currently missing.

RjS

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Sat, 4 Sep 2010 12:39:18 -0700

Hi Roni,

> Sent: Friday, September 03, 2010 12:49 PM

Correct. The difference is vendor-neutral (i.e., public) ones require IANA registration. But, still not everybody needs to support them. The current RAMS draft defines the mandatory TLV elements that any RAMS implementation must support. Naturally, a future spec may define new mandatory elements if need be.

> code that includes private extensions, is this correct?

Both a RAMS-I carrying 200 or 0 as the response code may carry both public and private TLVs. In other words, the code being public vs private does not limit what type of elements the server can include in the RAMS-I.
 
> optional and can be safely ignored.

Yup.

> can be ignored. In which case why is the next recommendation?

Does the text above adequately answer this question?
  
> be sure if the RTP_Rx supports this extensions?

The proposal is as follows. If the server sends a RAMS-I with a private response code that the client cannot process or a public response code that the client has not implemented, the client sends a RAMS-T right away to stop the burst.

If the server sticks with the current response codes, then there is no concern.

Hth,
-acbegen

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Sat, 4 Sep 2010 12:42:38 -0700

Hi All,

> Sent: Friday, September 03, 2010 6:13 PM
> To: Roni Even
> Cc: Ali C. Begen (abegen); [email-masked]
> Subject: Re: [AVT] Updated AD review:draft-ietf-avt-rapid-acquisition-for-rtp-14
> 
> Hi Ali -
> 

Correct. I thought the text was clear enough about this.

Correct.
 
> semantics, the server should use it instead of making a private code with the same semantics.

So, encourage the public codes over the private ones? Certainly.
 
> registered TLV that it should do anything other than ignore it if it doesn't understand it.

Right, the client will not understand some other vendor's private codes. It won't also understand the public codes it has not implemented. E.g., one can register 204 in a future spec. If the existing clients are not upgraded, they won't understand that one, either. So, they give up and send RAMS-T.

> know is supposed to do. (Is that there already?)

OK, I believe my text above makes my proposal clear.
 
> important, the protocol needs a mechanism it's currently missing.

As I recall, there was not any need mentioned for this before. This seems to be rather overkill to me, though. Instead, what I would suggest is that the client could put its "Enterprise Number" (that we use in the private TLVs) in a new TLV we can define in the RAMS-R message to let the server know what it would potentially support. For example, the client may list 3 vendors in that TLV and now the server at least has an idea that this client *may* (not necessarily will) support the private extensions from those 3 vendors. This way, the server has a better chance of sending a RAMS-I that the client can process fully.

What do you think?

-acbegen