[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.
- [Rmt] FLUTE SDP specification Jani Peltotalo
- Re: [Rmt] FLUTE SDP specification Luby, Michael
- Re: [Rmt] FLUTE SDP specification Rod.Walsh
- [Rmt] FLUTE SDP specification - open issues threa… Rod.Walsh
- [Rmt] FLUTE SDP specification - update status che… Rod.Walsh
- [Rmt] WEBRC session description questions Rod.Walsh
- Re: [Rmt] FLUTE SDP specification - update status… Jani Peltotalo
- Re: [Rmt] WEBRC session description questions Vincent Lucas
- [Rmt] FLUTE SDP specification Jani Peltotalo
- Re: [Rmt] FLUTE SDP specification brian.adamson