Re: [AVT] Open issue in the RAMS draft

[Zeev Vax <[e-mail]>]

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