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

[Robert Sparks <[e-mail]>]

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

On Sep 3, 2010, at 4:49 AM, Roni Even wrote:

> 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
> 
> 
> 
> 
> 
> 
> 
>> -----Original Message-----
>> From: Ali C. Begen (abegen) [mailto:[e-mail]]
>> Sent: Friday, September 03, 2010 4:57 AM
>> To: Roni Even; Robert Sparks; [e-mail]
>> Subject: RE: [AVT] Updated AD review:draft-ietf-avt-rapid-acquisition-
>> for-rtp-14
>> 
>> 
>> 
>>> -----Original Message-----
>>> From: Roni Even [mailto:[e-mail]]
>>> Sent: Friday, September 03, 2010 1:56 AM
>>> To: Ali C. Begen (abegen); 'Robert Sparks'; [e-mail]
>>> Subject: RE: [AVT] Updated AD review:draft-ietf-avt-rapid-
>> acquisition-for-rtp-14
>>> 
>>> 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.
>> 
>> 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.
>> 
>>> 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.
>> 
>> There is no efficient way for the client to indicate which private
>> extensions as well as public extensions (beyond the mandatory ones) it
>> supports.
>> 
>>> 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 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.
>> 
>>> 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.
>> 
>> 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
>>> 
>>>> -----Original Message-----
>>>> From: [e-mail] [mailto:[e-mail]] On Behalf
>> Of
>>>> Ali C. Begen (abegen)
>>>> Sent: Friday, September 03, 2010 12:44 AM
>>>> To: Robert Sparks; [e-mail]
>>>> Subject: Re: [AVT] Updated AD review: draft-ietf-avt-rapid-
>> acquisition-
>>>> for-rtp-14
>>>> 
>>>> Hi Robert,
>>>> 
>>>> Thanks for the review. Let me try to address the remaining
>> comments.
>>>> 
>>>>> -----Original Message-----
>>>>> From: Robert Sparks [mailto:[e-mail]]
>>>>> Sent: Thursday, September 02, 2010 11:49 PM
>>>>> To: [e-mail]
>>>>> Cc: Ali C. Begen (abegen)
>>>>> Subject: Updated AD review: draft-ietf-avt-rapid-acquisition-for-
>> rtp-
>>>> 14
>>>>> 
>>>>> 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
>>>> 
>>>> 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).
>>>> 
>>>>>  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."
>>>> 
>>>> OK, this is a good idea.
>>>> 
>>>>> * 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"?
>>>> 
>>>> 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?
>>>> 
>>>>>  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)
>>>> 
>>>> Correct.
>>>> 
>>>>>   - An element receiving a private TLV that it does not
>> understand
>>>> ignores
>>>>>     that TLV (regardless of the message type).
>>>> 
>>>> Correct.
>>>> 
>>>>>  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,
>>>> 
>>>> (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.
>>>> 
>>>>>  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.
>>>> 
>>>> 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?
>>>> 
>>>>> 
>>>>> * 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.
>>>> 
>>>> Sure.
>>>> 
>>>>> 
>>>>> * 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.
>>>> 
>>>> Looks good to me.
>>>> 
>>>>> * 7.3 Definition of type 33
>>>>>    There is a lowercase "should" in the third paragraph - should
>>>> that
>>>>>    have been SHOULD?
>>>> 
>>>> Fine with me. I believe my suggestion was a MUST, but SHOULD is
>> good
>>>> enough.
>>>> 
>>>>> * 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.
>>>> 
>>>> Right, that should be removed.
>>>> 
>>>> Should we go ahead with one more revision?
>>>> 
>>>> Cheers, acbegen.
>>>> _______________________________________________
>>>> Audio/Video Transport Working Group
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/avt
>