Subject: [AVT] Open issue in the RAMS draft

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Wed, 16 Jun 2010 10:00:25 -0700

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

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 17 Jun 2010 10:53:45 -0700

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: [email-masked] [mailto:[email-masked]] 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.
> 
> -> 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.
> 
> -> 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.
> 
> 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.
> 
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

---

From: Roni Even <[email-masked]>
Date: Thu, 17 Jun 2010 21:18:54 +0300

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

> Sent: Thursday, June 17, 2010 8:54 PM
> To: IETF AVT WG
> 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.
>

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 17 Jun 2010 11:24:37 -0700

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

-acbegen

> From: Roni Even [mailto:[email-masked]]
> Sent: Thursday, June 17, 2010 2:19 PM
> To: Ali C. Begen (abegen); 'IETF AVT WG'
> Subject: RE: [AVT] Open issue in the RAMS draft
> 
> Hi,

---

From: "Bill Ver Steeg (versteb)" <[email-masked]>
Date: Thu, 17 Jun 2010 13:47:21 -0500

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);
[email-masked]

To start a discussion:

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.

-acbegen

> 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/

---

From: Roni Even <[email-masked]>
Date: Thu, 17 Jun 2010 23:35:37 +0300

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

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Bill Ver Steeg (versteb)
> Sent: Thursday, June 17, 2010 9:47 PM
> To: Ali C. Begen (abegen); IETF AVT WG
> may
> the
> better
> > regarding the 2119 keyword usage in the draft). We currently agreed
> on
> all the earlier clarifications
> > order of the burst packets or the RAMS-I messages. In other words,
> the
> client implementation MUST NOT
> > Note that there is no other way that the client can detect this in
> the
> RTP plane.
> >
> > when to join in the first RAMS-I message, a second RAMS-I message
> with
> the join-time information is

---

From: Zeev Vax <[email-masked]>
Date: Thu, 17 Jun 2010 21:02:51 +0000

I agree with Roni, we should change it to recommended as he suggested or to MAY.

Zeev  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 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,

> Ali C. Begen (abegen)

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 17 Jun 2010 14:54:00 -0700

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

> From: Zeev Vax [mailto:[email-masked]]
> Sent: Thursday, June 17, 2010 5:03 PM
> To: Roni Even; Bill Ver Steeg (versteb); Ali C. Begen (abegen); 'IETF AVT WG'

---

From: "Van Caenegem, Tom (Tom)" <[email-masked]>
Date: Fri, 18 Jun 2010 16:28:53 +0200

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: [email-masked] [mailto:[email-masked]] 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

<new text>

</new text>

-acbegen

> 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
> 
> > From: [email-masked] [mailto:[email-masked]] On Behalf 
> > Of Bill Ver Steeg (versteb)
> > 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.
> > 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
> >
> >
> >
> > 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
> > client will have wasted valuable resources of the server and network 
> > for no visible gain.
> >
> > Our options here are:
> > 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" (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 
> > > There will be a new revision to the RAMS draft to address the 
> > > final
> > remaining comments (mostly
> > https://datatracker.ietf.org/doc/draft-ietf-avt-rapid-acquisition-fo
> > r-
> > rt
> > p/
> > >
> > >            initial RAMS-I message SHOULD precede the unicast burst 
> > > or
> > be
> > >                                   ^^^^^^
> > > -> The paragraph above is also agreed. So, the client (RTP_Rx) 
> > > -> MUST
> > NOT make any assumptions about the
> > > server sends them in the correct order (if we agree on one), 
> > > packets
> > may get re-ordered or lost.
> > >
> > > Remember that RAMS-I messages can be repeated for redundancy. And 
> > > if
> > the server cannot tell the client
> > > required. The overhead of sending this particular TLV is not 
> > > critical
> > in practice.
> > >
> > > 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
> > > Audio/Video Transport Working Group [email-masked]