Re: [AVT] Open issue in the RAMS draft

["Van Caenegem, Tom (Tom)" <[e-mail]>]

Ali,

It's OK for me. .. But ... I noticed that RECOMMENDED and SHOULD are considered equivalent as normative requirement RFC language. So, I would be surprised to learn that "SHOULD" requires a statement that explains why an exception can be made, and "RECOMMENDED" not.. Where is the logic here?

I guess Keith will answer that..
Tom

 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Ali C. Begen (abegen)
Sent: donderdag 17 juni 2010 23:54
To: Zeev Vax; Roni Even; Bill Ver Steeg (versteb); IETF AVT WG
Subject: Re: [AVT] Open issue in the RAMS draft

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

_______________________________________________
Audio/Video Transport Working Group
[e-mail]
https://www.ietf.org/mailman/listinfo/avt