Re: [AVT] Open issue in the RAMS draft
Roni Even <Even.roni@huawei.com> Thu, 17 June 2010 20:38 UTC
Return-Path: <Even.roni@huawei.com>
X-Original-To: avt@core3.amsl.com
Delivered-To: avt@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2811D3A68CB for <avt@core3.amsl.com>; Thu, 17 Jun 2010 13:38:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.734
X-Spam-Level:
X-Spam-Status: No, score=0.734 tagged_above=-999 required=5 tests=[AWL=-0.260, BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sdq80ZBtXVjd for <avt@core3.amsl.com>; Thu, 17 Jun 2010 13:38:19 -0700 (PDT)
Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id A03DB3A6887 for <avt@ietf.org>; Thu, 17 Jun 2010 13:38:18 -0700 (PDT)
Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L4600LIQENPQC@szxga01-in.huawei.com> for avt@ietf.org; Fri, 18 Jun 2010 04:38:13 +0800 (CST)
Received: from huawei.com ([172.24.2.119]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L46003XWENP1G@szxga01-in.huawei.com> for avt@ietf.org; Fri, 18 Jun 2010 04:38:13 +0800 (CST)
Received: from windows8d787f9 (bzq-79-178-14-20.red.bezeqint.net [79.178.14.20]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L4600B5EENCJX@szxml01-in.huawei.com>; Fri, 18 Jun 2010 04:38:13 +0800 (CST)
Date: Thu, 17 Jun 2010 23:35:37 +0300
From: Roni Even <Even.roni@huawei.com>
In-reply-to: <EE933D92D054D14089A336CC71A5CCA6018E893F@XMB-RCD-213.cisco.com>
To: "'Bill Ver Steeg (versteb)'" <versteb@cisco.com>, "'Ali C. Begen (abegen)'" <abegen@cisco.com>, 'IETF AVT WG' <avt@ietf.org>
Message-id: <02ec01cb0e5c$aa334d20$fe99e760$%roni@huawei.com>
MIME-version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Content-type: text/plain; charset="us-ascii"
Content-language: en-us
Content-transfer-encoding: 7bit
Thread-index: AcsNdWo0kzTQmVdkRGOiUIkt8aNDfQAzelrAAAJNw4AAA+3QMA==
References: <04CAD96D4C5A3D48B1919248A8FE0D540C5EEA4A@xmb-sjc-215.amer.cisco.com> <04CAD96D4C5A3D48B1919248A8FE0D540C6A4214@xmb-sjc-215.amer.cisco.com> <EE933D92D054D14089A336CC71A5CCA6018E893F@XMB-RCD-213.cisco.com>
Subject: Re: [AVT] Open issue in the RAMS draft
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/avt>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Jun 2010 20:38:20 -0000
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: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] 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); > zeevvax@microsoft.com > 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: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] 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 > > avt@ietf.org > > https://www.ietf.org/mailman/listinfo/avt > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt
- [AVT] Open issue in the RAMS draft Ali C. Begen (abegen)
- Re: [AVT] Open issue in the RAMS draft Ali C. Begen (abegen)
- Re: [AVT] Open issue in the RAMS draft Roni Even
- Re: [AVT] Open issue in the RAMS draft Ali C. Begen (abegen)
- Re: [AVT] Open issue in the RAMS draft Bill Ver Steeg (versteb)
- Re: [AVT] Open issue in the RAMS draft Roni Even
- Re: [AVT] Open issue in the RAMS draft Zeev Vax
- Re: [AVT] Open issue in the RAMS draft Ali C. Begen (abegen)
- Re: [AVT] Open issue in the RAMS draft Van Caenegem, Tom (Tom)