Re: [AVT] Rapid Acquisition of Multicast Streams (RAMS) -multipleRAMS-R messages for the same unicast flow

To: "Bill Ver Steeg (versteb)" <versteb at cisco.com>, "Ye-Kui Wang" <yekuiwang at huawei.com>, "Zeev Vax" <zeevvax at microsoft.com>, <Tom.Van_Caenegem at alcatel-lucent.be>, "Ali C. Begen (abegen)" <abegen at cisco.com>

Subject: Re: [AVT] Rapid Acquisition of Multicast Streams (RAMS) -multipleRAMS-R messages for the same unicast flow

From: "Bill Ver Steeg (versteb)" <versteb at cisco.com>

Date: Wed, 1 Apr 2009 21:04:29 -0400

Authentication-results: rtp-dkim-2; header.From=versteb at cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; );

Cc: avt at ietf.org

Delivered-to: avt at core3.amsl.com

Dkim-signature: v=1; a=rsa-sha256; q=dns/txt; l=14477; t=1238634270; x=1239498270; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=versteb at cisco.com; z=From:=20=22Bill=20Ver=20Steeg=20(versteb)=22=20<versteb at ci sco.com> |Subject:=20RE=3A=20[AVT]=20Rapid=20Acquisition=20of=20Mult icast=20Streams=20(RAMS)=20-multipleRAMS-R=20messages=20for= 20the=20same=20unicast=20flow |Sender:=20 |To:=20=22Bill=20Ver=20Steeg=20(versteb)=22=20<versteb at cisc o.com>,=0A=20=20=20=20=20=20=20=20=22Ye-Kui=20Wang=22=20<yek uiwang at huawei.com>,=0A=20=20=20=20=20=20=20=20=22Zeev=20Vax= 22=20<zeevvax at microsoft.com>,=0A=20=20=20=20=20=20=20=20<Tom .Van_Caenegem at alcatel-lucent.be>,=0A=20=20=20=20=20=20=20=20 =22Ali=20C.=20Begen=20(abegen)=22=20<abegen at cisco.com>; bh=+1HHgaJv5XX63539D1vHSX/KgAmm02ICtwEKwW0HHV0=; b=P2nsBfGyKmtqWcWalyKhiiD+q7V0YRict5U1AwlNPX2GqZ7TyM9BiIlfkE 2upjMYiqsEPml6zFEctBPI7ouNp4p2c7Y8PkJimu7anJWwD5hLSOORXrQSRJ +/np9oEtXc;

In-reply-to: <81B9B88E2F9D574AA5328A85547CDE91EC1CDA at xmb-rtp-21d.amer.cisco.com>

List-archive: <http://www.ietf.org/mail-archive/web/avt>

List-help: <mailto:avt-request@ietf.org?subject=help>

List-id: Audio/Video Transport Working Group <avt.ietf.org>

List-post: <mailto:avt@ietf.org>

List-subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>

List-unsubscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>

References: <81B9B88E2F9D574AA5328A85547CDE91EC162E at xmb-rtp-21d.amer.cisco.com><5177B2A348E4B64EAD7D589A027892D96A29EAB21D at NA-EXMSG-C111.redmond.corp.microsoft.com><81B9B88E2F9D574AA5328A85547CDE91EC1C34 at xmb-rtp-21d.amer.cisco.com><81B9B88E2F9D574AA5328A85547CDE91EC1CAA at xmb-rtp-21d.amer.cisco.com><9FBAA863185D42098EB4FA0C7D117E25 at china.huawei.com> <81B9B88E2F9D574AA5328A85547CDE91EC1CDA at xmb-rtp-21d.amer.cisco.com>

Thread-index: AcmyMO1Vf+4hrMHmQjCLzeIX0fZkSAAt6jegAApONVAABEpf4AACVnxAAAB3z7AAACdp0A==

Thread-topic: [AVT] Rapid Acquisition of Multicast Streams (RAMS) -multipleRAMS-R messages for the same unicast flow

Based on further responses, the jury is still out.

I will mark this section of the text with an editor's note and we will continue the discussion.

bvs

From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org] On Behalf Of Bill Ver Steeg (versteb)
Sent: Wednesday, April 01, 2009 9:01 PM
To: Ye-Kui Wang; Zeev Vax; Tom.Van_Caenegem at alcatel-lucent.be; Ali C. Begen (abegen)
Cc: avt at ietf.org
Subject: Re: [AVT] Rapid Acquisition of Multicast Streams (RAMS) -multipleRAMS-R messages for the same unicast flow

Thanks YK-

This is also where I ended up. Simple is good.

I will be sure that the text is clear in this regard.

bvs

From: Ye-Kui Wang [mailto:yekuiwang at huawei.com]
Sent: Wednesday, April 01, 2009 8:53 PM
To: Bill Ver Steeg (versteb); 'Zeev Vax'; Tom.Van_Caenegem at alcatel-lucent.be; Ali C. Begen (abegen)
Cc: avt at ietf.org
Subject: RE: [AVT] Rapid Acquisition of Multicast Streams (RAMS) - multipleRAMS-R messages for the same unicast flow

Sending of subsequent RAMS-I messages by the RS is not trigged by reception of RAMS-R messages, but by that the server has decided to change information contained in RAMS-I messages, including burst bitrate. Only in the case when the RS decided to change the burst bitrate according to a subsequent RAMS-R message received, the subsequent RAMS-R message indirectly triggers a RAMS-I message. The process to me seems rather simple.

BR, YK

From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org] On Behalf Of Bill Ver Steeg (versteb)
Sent: Wednesday, April 01, 2009 7:52 PM
To: Bill Ver Steeg (versteb); Zeev Vax; Tom.Van_Caenegem at alcatel-lucent.be; Ali C. Begen (abegen)
Cc: avt at ietf.org
Subject: [AVT] Rapid Acquisition of Multicast Streams (RAMS) - multiple RAMS-R messages for the same unicast flow

When we added the ability to send more than one RAMS-R message, we opened up a few design points that we now need to consider.

We need to have some nomenclature for describing the "initial RMS-R" and "subsequent RMS-R", so I will start with using those words. Better words would be appreciated.

The first design point I would like to address is what the RS is required to do when it receives an RAMS-R for a burst that is already in flow (aka "subsequent RMS-R"). We stated that the least it could do was "ignore it". Does this imply that there is no requirement to send an RMS-I in response to RMS-R messages referencing an in-progress flow? If so, we should add clarifying text in the document that cautions the RR not to assume the RAMS-R was dropped. I briefly considered requiring the RS to send a RAMS-I for each received RAMS-R. Unfortunately, this then leads to another set of corner cases, and may result in a chatty exchange of messages.

We also need to consider how to deterministically differentiate between the initial RMS-R message and subsequent RMS-R messages, particularly in the event of packet loss or (unlikely) re-ordering. This probably leads us to including a monotonically increasing sequence number on the RMS-R. Dropped RMS-R messages should not be a protocol problem, as the first one received will trigger the burst. Subsequent RMS-R messages either change the burst shape or they do not, and they do not trigger additional messages. Similarly, if the initial RMS-I is dropped it will probably trigger an additional RMS-R message. Subsequent RMS-I messages will either be received by the RR or they will not, and they will not trigger additional messages.

So, has anybody considered these design points in detail? I have started to go down this path, but it gets complicated quickly.

In order to limit the complexity, I suggest that we state that the first received RMS-R triggers a RMS-I. Further RMS-R messages may flow. Further RMS-I messages may also flow, but there is no explicit requirement to send an RMS-I in response to a subsequent RMS-R.

Bill VerSteeg