[Rmt] WEBRC session description questions

<Rod.Walsh@nokia.com> Tue, 29 June 2010 08:21 UTC

Return-Path: <Rod.Walsh@nokia.com>
X-Original-To: rmt@core3.amsl.com
Delivered-To: rmt@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A8513A6971 for <rmt@core3.amsl.com>; Tue, 29 Jun 2010 01:21:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.592
X-Spam-Level:
X-Spam-Status: No, score=-4.592 tagged_above=-999 required=5 tests=[AWL=-0.594, BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 Clvyfd4NXKme for <rmt@core3.amsl.com>; Tue, 29 Jun 2010 01:21:50 -0700 (PDT)
Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id C92553A65A5 for <rmt@ietf.org>; Tue, 29 Jun 2010 01:21:49 -0700 (PDT)
Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o5T8LT0x006260; Tue, 29 Jun 2010 11:21:55 +0300
Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 29 Jun 2010 11:21:54 +0300
Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 29 Jun 2010 11:21:45 +0300
Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Tue, 29 Jun 2010 10:21:44 +0200
From: <Rod.Walsh@nokia.com>
To: <rmt@ietf.org>, <luby@qualcomm.com>, <v.goyal@ieee.org>
Date: Tue, 29 Jun 2010 10:21:34 +0200
Thread-Topic: WEBRC session description questions
Thread-Index: AcsXZBqcmUkAsUtFTNSGkq2FVx7Lzw==
Message-ID: <4C29AD0E.80501@nokia.com>
References: <4C22448F.3050704@tut.fi> <4C28C21C.9030209@nokia.com>
In-Reply-To: <4C28C21C.9030209@nokia.com>
Accept-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_4C29AD0E80501nokiacom_"
MIME-Version: 1.0
X-OriginalArrivalTime: 29 Jun 2010 08:21:45.0480 (UTC) FILETIME=[1CA2F080:01CB1764]
X-Nokia-AV: Clean
Subject: [Rmt] WEBRC session description questions
X-BeenThere: rmt@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Reliable Multicast Transport <rmt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/rmt>, <mailto:rmt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rmt>
List-Post: <mailto:rmt@ietf.org>
List-Help: <mailto:rmt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rmt>, <mailto:rmt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Jun 2010 08:21:54 -0000

Hi WEBRC folk

>From this text from the WEBRC RFC3738...

"Before joining a session the receiver MUST know the mapping between the
CNs and the channels. Upon joining the session or shortly thereafter, it
SHOULD have the values of LENP_B, BCR_P, TSD, P, N, L, Q and T. Some of
these values may be computed or measured once the receiver has joined
the session. For example, the receiver MAY obtain LENP_B and T from the
first packet received from the base channel, and the receiver MAY
measure BCR_P once it is joined to the base channel.  The values of P, Q
and TSD MAY be fixed to default values built into the receiver that do
not change from session to session, and the value of N MAY be computed
as T-Q.  The receiver SHOULD know whether the sender is employing a
technique to produce constant aggregate rate as described in [8]."

Does anyone have a perspective on how trivial/complex and rapid/stalling the in-band detection or calculation would be for:
1. LENP_B - calculated from from first packet. That's minimal effort - right?
2. T - calculated from from first packet. That's minimal effort - right?
3. BCR_P - measured after joining. What kind of delay and processing is introduced?
4. N - simple calculation, no problem.
5. TSD, P, Q - must be communicated out of band. Are these likely to be fixed for practically all cases?
6. L - must be communicated out of band - right?

We're thinking about a flag for "constant aggregate rate" - would the rate need communicating instead?

Also, we're figuring out the CN semantics and whether ordering (and not explicit labelling) is sufficient.

Cheers, Rod.