Re: [AVT] Open issue in the RAMS draft

[Roni Even <[e-mail]>]

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