Re: [AVT] Open issue in the RAMS draft

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

RECOMMEND (in place of SHOULD) is also fine for me. 

-acbegen

> -----Original Message-----
> From: Roni Even [mailto:[e-mail]]
> Sent: Thursday, June 17, 2010 2:19 PM
> To: Ali C. Begen (abegen); 'IETF AVT WG'
> Cc: Bill Ver Steeg (versteb)
> Subject: RE: [AVT] Open issue in the RAMS draft
> 
> Hi,
> I think that instead of SHOULD the draft can say RECOMMEND which has the
> same normative meaning but it sounds different. The major reason, like Ali
> stated, is that RTCP is not a reliable protocol and RAMS does not address
> reliability of messages. Clients should not break if a message is lost and
> section 5 explains that this is an optimization and the client can always
> use the multicast and wait for synchronization.
> Getting the information about the first packet in the burst or failing in
> the decoding due to packet lost MUST cause the same client behavior whether
> the RAMS-I with this information arrived or not. RAMS does not recommend any
> method in the case of burst packet loss so this is left to the
> implementation. For example, even if the RTP_Rx will get the RAMS-I with the
> first sequence number and will not receive this first packet, it can decide
> to take any action it wishes so by sending the information it does not cause
> a specific behavior.
> I think that by specifying all the information we can let the implementer
> decide when to send the RAMS-I
> 
> Roni Even
> As individual
> 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On Behalf Of
> > Ali C. Begen (abegen)
> > Sent: Thursday, June 17, 2010 8:54 PM
> > To: IETF AVT WG
> > Cc: Bill Ver Steeg (versteb)
> > 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-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
> > _______________________________________________
> > Audio/Video Transport Working Group
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/avt