Re: [AVT] Open issue in the RAMS draft

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

To start a discussion:

I think the TLV for the seqnum of the first burst packet must be included in every RAMS-I sent by the server (The overhead is small and it serves for an important goal). I am fine with the current "MUST" but we should make the sentence clear that it is a must for every RAMS-I message not only for the first one.

Regarding the timing of the first/initial RAMS-I message. It is correct that this message may get lost. So, even if we say the server must send it right before the burst, it may get dropped or re-ordered. The client MUST NOT break in such cases. However, we need to consider that RAMS may itself fail or may become even useless. E.g., if the client is missing one or more packets at the start of the burst and does not realize this for some time, by the time it asks for those missing packets and gets them, the resulting acquisition delay might be close to (or even longer than) the acquisition delay that would be achieved w/o RAMS. And the client will have wasted valuable resources of the server and network for no visible gain.

Our options here are:
- MUST: This makes the text clear and defines the server behavior normatively. However, what is the difference between the cases where the initial RAMS-I is dropped and where the server does not send it at the start of the burst? From client's viewpoint, these cases are equal. 
- SHOULD: Since we initially followed the logic above, we agreed on "SHOULD" (rather than a MUST) but now we are supposed to come up with a reason why the server will not need to follow this requirement. If you have suggestions, please speak up.
- MAY or any other non-normative language: IMO, it will be too soft to use "MAY" here as I think trying to get the burst description information to the client as quickly as possible is important for better performance. It increases the chances for RAMS success.

My personal choice is to stick with SHOULD. Or go for a MUST.

Please comment so that we can close this final issue.

-acbegen

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Ali C. Begen (abegen)
> Sent: Wednesday, June 16, 2010 1:00 PM
> To: IETF AVT WG
> Cc: Bill Ver Steeg (versteb)
> Subject: [AVT] Open issue in the RAMS draft
> 
> Hi everyone,
> 
> There will be a new revision to the RAMS draft to address the final remaining comments (mostly
> regarding the 2119 keyword usage in the draft). We currently agreed on all the earlier clarifications
> requested by Keith but one. Here is the remaining one and we would like to get input from the WG.
> 
> https://datatracker.ietf.org/doc/draft-ietf-avt-rapid-acquisition-for-rtp/
> 
> page 19, sub-bullet starting with "Accept Responses:"
> 
> Here is the current text:
> 
>         *  Accept Responses:  BRS MUST send a separate RAMS-I message
>            with the appropriate response code for each primary multicast
>            stream that has been requested by RTP_Rx and will be served
>            by BRS.  Such RAMS-I messages comprise fields that can be
>            used to describe the individual unicast burst streams.
> 
> -> So far, there are no issues.
> 
>            A particularly important field in the RAMS-I message carries
>            the RTP sequence number of the first packet transmitted in
>            the respective RTP stream to allow RTP_Rx to detect any
>            missing initial packet(s).  When BRS accepts the request,
> 
> -> No issues until this point, either.
> 
>            this field MUST be populated in the RAMS-I message and the
>                       ^^^^
>            initial RAMS-I message SHOULD precede the unicast burst or be
>                                   ^^^^^^
>            sent at the start of the burst so that RTP_Rx can quickly
>            detect any missing initial packet(s).
> 
> -> The discussion is about the MUST and SHOULD above. BTW, we will remove the part "precede the
> unicast burst" and keep only the "be sent at the start of the burst" part.
> 
>         Where possible, it is RECOMMENDED to include all RAMS-I messages
>         in the same compound RTCP packet.  However, it is possible that
>         the RAMS-I message for a primary multicast stream can get
>         delayed or lost, and RTP_Rx can start receiving RTP packets
>         before receiving a RAMS-I message.  RTP_Rx MUST NOT make
>         protocol dependencies on quickly receiving the initial RAMS-I
>         message.  For redundancy purposes, it is RECOMMENDED that BRS
>         repeats the RAMS-I messages multiple times as long as it follows
>         the RTCP timer rules defined in [RFC4585].
> 
> -> The paragraph above is also agreed. So, the client (RTP_Rx) MUST NOT make any assumptions about the
> order of the burst packets or the RAMS-I messages. In other words, the client implementation MUST NOT
> break when the arrival order is different than what it was expected. This is because even if the
> server sends them in the correct order (if we agree on one), packets may get re-ordered or lost.
> 
> On the other hand, everybody agrees that sending the seqnum of the first burst packet at an earlier
> stage is very useful to allow the client to detect whether it is missing any burst packets or not.
> Note that there is no other way that the client can detect this in the RTP plane.
> 
> But, the question is when this info should be sent. In particular:
> 
> 1- MUST the server include the TLV for the seqnum of the 1st burst packet in each RAMS-I message?
> Remember that RAMS-I messages can be repeated for redundancy. And if the server cannot tell the client
> when to join in the first RAMS-I message, a second RAMS-I message with the join-time information is
> required. The overhead of sending this particular TLV is not critical in practice.
> 
> 2- When should the server send the first (or initial) RAMS-I message? Right before (or at the start
> of) the burst or any time during the burst? And should we use "MUST, SHOULD, MAY" or something else
> here? If we wanna keep "SHOULD", we need to explain the circumstances when the server does not need to
> send a RAMS-I message at the start of the burst.
> 
> Note that this text explains the behavior of the server. No matter what the server does, the arrival
> order may still change at the client but the last paragraph above makes sure that the client
> implementation does not break in such cases.
> 
> Bill, Tom, Zeev, please add your comments if I missed something.
> 
> -acbegen
> 
> _______________________________________________
> Audio/Video Transport Working Group
> [e-mail]
> https://www.ietf.org/mailman/listinfo/avt