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

["Ali C. Begen (abegen)" <[e-mail]>]

> -----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