Re: [AVT] Open issue in the RAMS draft

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

Is the following text acceptable?

<new text>

        *  Accept Responses:  BRS MUST send at least one 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.
           When there is a RAMS-R request for multiple primary multicast
           streams, BRS MUST include all the individual RAMS-I messages
           corresponding to that RAMS-R request in the same compound
           RTCP packet if these messages fit in the same packet.

           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 a request for a primary multicast stream, this
           field MUST always be populated in the RAMS-I message(s) sent
           for this particular primary multicast stream.  It is
           RECOMMENDED that BRS sends a RAMS-I message at the start of
           the burst so that RTP_Rx can quickly detect any missing
           initial packet(s).

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

</new text>

Keith, could you confirm whether this text is OK in terms of 2119 language? If so, let's wrap it up and we will submit -11.

-acbegen


> -----Original Message-----
> From: Zeev Vax [mailto:[e-mail]]
> Sent: Thursday, June 17, 2010 5:03 PM
> To: Roni Even; Bill Ver Steeg (versteb); Ali C. Begen (abegen); 'IETF AVT WG'
> Subject: RE: [AVT] Open issue in the RAMS draft
> 
> I agree with Roni, we should change it to recommended as he suggested or to MAY.
> 
> Zeev
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Roni Even
> Sent: Thursday, June 17, 2010 1:36 PM
> To: 'Bill Ver Steeg (versteb)'; 'Ali C. Begen (abegen)'; 'IETF AVT WG'
> Subject: Re: [AVT] Open issue in the RAMS draft
> 
> Hi Bill,
> The discussion was if the server MUST send a RAMS-I in the start of the
> burst and I tried in my email to explain why it is not a MUST. It may be
> helpful but nothing will break if the server will not send it. This is based
> on section 5 that says that nothing should break since you can always go to
> the multicast.
> Roni
> 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On Behalf Of
> > Bill Ver Steeg (versteb)
> > Sent: Thursday, June 17, 2010 9:47 PM
> > To: Ali C. Begen (abegen); IETF AVT WG
> > Subject: Re: [AVT] Open issue in the RAMS draft
> >
> > Agreed on the first point. The (primary) intent of the multiple RAMS-I
> > messages is for message integrity, so the required fields should appear
> > in each RAMS-I. I realize that some RAMS-I messages convey "new"
> > information, but including all non-stale information in the new RAMS-I
> > is good practice from a message resiliency standpoint.
> >
> > On the second point, perhaps we can craft language that says
> > 1-the server MUST send a RAMS-I at the start of the burst, and the
> > initial RAMS-I MUST contain [an enumerated list of required fields] and
> > MAY contain the other fields.
> > 2- the server MUST send at least one RAMS-I that contains the join
> > time.
> > 3- the server MAY send additional RAMS-I messages, and these messages
> > MUST contain [an enumerated list of required fields] and May have
> > updated values for any of the fields.
> >
> > bvs
> >
> >
> >
> > -----Original Message-----
> > From: Ali C. Begen (abegen)
> > Sent: Thursday, June 17, 2010 1:54 PM
> > To: IETF AVT WG
> > Cc: Bill Ver Steeg (versteb); Van Caenegem, Tom (Tom);
> > [e-mail]
> > Subject: RE: [AVT] Open issue in the RAMS draft
> >
> > 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-
> > rt
> > p/
> > >
> > > 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
> > _______________________________________________
> > Audio/Video Transport Working Group
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/avt
> 
> _______________________________________________
> Audio/Video Transport Working Group
> [e-mail]
> https://www.ietf.org/mailman/listinfo/avt