Re: [AVT] Open issue in the RAMS draft

["Bill Ver Steeg (versteb)" <[e-mail]>]

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