From Majordomo@lbl.gov Fri Oct 19 09:51:35 2001
Date: Fri, 19 Oct 2001 06:45:37 -0700 (PDT)
From: Majordomo@lbl.gov
To: sweilnau@ietf.org
Subject: Majordomo file: list 'rmt' file 'archive'
--
>From se@tellique.de Sat Mar 20 07:42:05 1999
Received: from postal1.lbl.gov (localhost [127.0.0.1])
by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id HAA01641
for <rmt@listserv.lbl.gov>; Sat, 20 Mar 1999 07:42:04 -0800 (PST)
Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1])
by postal1.lbl.gov (8.9.0/8.9.0) with ESMTP id HAA17912
for <rmt@listserv.lbl.gov>; Sat, 20 Mar 1999 07:42:04 -0800 (PST)
Received: from mail.tellique.de (big-gw.tellique.de [195.126.133.179])
by SpamWall.lbl.gov (8.9.0/8.9.0) with ESMTP id HAA17907
for <rmt@lbl.gov>; Sat, 20 Mar 1999 07:42:02 -0800 (PST)
Received: from tellique.de (marc.tellique.de [62.144.106.59])
by mail.tellique.de (8.8.7/8.8.8) with ESMTP id QAA09255
for <rmt@lbl.gov>; Sat, 20 Mar 1999 16:41:54 +0100
Message-ID: <36F3C1A1.4693E0E3@tellique.de>
Date: Sat, 20 Mar 1999 16:41:21 +0100
From: Nils Seifert <se@tellique.de>
Organization: Tellique GmbH
X-Mailer: Mozilla 4.07 [en] (Win98; I)
MIME-Version: 1.0
To: rmt@lbl.gov
Subject: subcribe
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
--
Gruesse,
Nils Seifert
--
Nils Seifert / se@tellique.de
Tellique Kommunikationstechnik GmbH Berlin / http://www.tellique.de
Gustav-Meyer-Allee 25, D-13355 Berlin (Germany)
Tel. +49.30.463 07-551 /Fax. +49.30.463 07-579 /Funk: +49.172.8850112
>From luigi@labinfo.iet.unipi.it Thu Apr 1 09:36:15 1999
Received: from postal1.lbl.gov (localhost [127.0.0.1])
by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id JAA23546
for <rmt@listserv.lbl.gov>; Thu, 1 Apr 1999 09:36:14 -0800 (PST)
Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1])
by postal1.lbl.gov (8.9.0/8.9.0) with ESMTP id JAA16273
for <rmt@listserv.lbl.gov>; Thu, 1 Apr 1999 09:36:13 -0800 (PST)
Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5])
by SpamWall.lbl.gov (8.9.0/8.9.0) with SMTP id JAA16233
for <rmt@lbl.gov>; Thu, 1 Apr 1999 09:36:10 -0800 (PST)
Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id RAA16107; Thu, 1 Apr 1999 17:15:48 +0200
From: Luigi Rizzo <luigi@labinfo.iet.unipi.it>
Message-Id: <199904011515.RAA16107@labinfo.iet.unipi.it>
Subject: CfP: First Intl Workshop on Networked Group Communication
To: rmt@lbl.gov
Date: Thu, 1 Apr 1999 17:15:48 +0200 (MET DST)
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Dear RMT'ers,
Just a short note to announce the Call for Papers for an event
sponsored by COST264 and fully dedicated to Networked Group
Communicaton:
First International Workshop on
Networked Group Communication
Pisa, November 17-20, 1999
http://www.iet.unipi.it/~luigi/ngc99/
At the above URL you can get the complete CfP and related information.
A textual version is attached below.
Please disseminate this as you feel appropriate, and the usual
apologies for duplicates.
Cheers
Luigi
-----------------------------------+-------------------------------------
Luigi RIZZO .
EMAIL: luigi@iet.unipi.it . Dip. di Ing. dell'Informazione
HTTP://www.iet.unipi.it/~luigi/ . Universita` di Pisa
TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy)
-----------------------------------+-------------------------------------
FIRST INTERNATIONAL WORKSHOP ON NETWORKED GROUP COMMUNICATION
Sponsored by COST 264
Pisa, November 17-20, 1999
http://www.iet.unipi.it/~luigi/ngc99/
CALL FOR PAPERS
The aim of the Workshop is to allow researchers and practioners to
present the design and implementation techniques for networked
group communication. The focus of the workshop is strictly on
multicast and networked group communication, and this workshop is
the first and only internationational event in this area.
To be considered for acceptance, contribution should clearly
demonstrate the peculiarity of the solutions proposed in relation
to the presence of multiple communicating parties.
Original research papers are solicited for topics related to the
architecture and deployment of multicast services, including but
not limited to:
* multicast congestion control
* multicast routing, naming, address allocation
* scalability in multicast services
* reliable and semi-reliable multicast protocols
* novel multicast architectures
* multicast over heterogeneous media
* multipeer applications (distributed interactive applications,
games, DIS)
* QoS issues with multicast
* Pricing and economic model for multicast traffic
* group management techniques
* network engineering for multicast services
The Proceedings of the Workshop will be published by a major
publisher and will be available for participants at the Workshop.
The workshop will start with one day of tutorials on aspects of the IP
multicast architecture, held by key researchers in the area, followed
by two days presentations and invited talks, and a one-day COST264
Management Committee Meeting.
IMPORTANT DATES
Paper submission deadline: July 1st, 1999
Notification of acceptance: September 15, 1999
Camera Ready Due: September 30, 1999
Tutorials: November 17, 1999
Conference: November 18-19, 1999
SUBMISSION INFORMATION
Only full paper submissions will be accepted, not exceeding 20
pages double spaced. Overlenght papers will not be reviewed and
immediately returned to their authors. Papers must be submitted
by electronic means only, in Postscript or PDF format. Make sure
that your paper can be properly printed with Ghostscript.
The email address will be announced, and become active, one month
before the conference.
CONTACT ADDRESS
For more information on the Workshop, contact luigi@iet.unipi.it
PROGRAM CHAIRS
Luigi Rizzo luigi@iet.unipi.it
Serge Fdida sf@lip6.fr
PROGRAM COMMITTEE (preliminary)
Kevin C. Almeroth, USCB
Mostafa Ammar, GeorgiaTech
Ernst Biersack, EURECOM
Jon Crowcroft, University College London
Andre Danthine, U.Liege
Christophe Diot, SPRINT
Wolfgang Effelsberg, Uni.Mannheim
Serge Fdida, LIP6
Domenico Ferrari, CRATOS
JJ Garcia-Luna, UC Santa Cruz
Jim Gemmel, Microsoft
Mark Handley, ACIRI
Marcus Hofman, BELL LABS
David Hutchison, Lancaster University
Jim Kurose, UMass
Luciano Lenzini, Univ.Pisa
Helmut Leopold, Telekom AT
Allison Mankin, ISI
Jorg Nonnenmacher, Bell Labs
Radia Perlman, SUN
Jean-Jacques Quisquater, UCL (BE)
Luigi Rizzo, Univ. Pisa
Burkhard Stiller, ETH Zurich
Don Towsley, UMass
Giorgio Ventre, Univ.Napoli
Brian Whetten, Talarian Corporation
>From vern@daffy.ee.lbl.gov Tue Apr 13 20:32:31 1999
Received: from postal1.lbl.gov (localhost [127.0.0.1])
by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id UAA21672
for <rmt@listserv.lbl.gov>; Tue, 13 Apr 1999 20:32:30 -0700 (PDT)
Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1])
by postal1.lbl.gov (8.9.0/8.9.0) with ESMTP id UAA16172
for <rmt@listserv.lbl.gov>; Tue, 13 Apr 1999 20:32:30 -0700 (PDT)
Received: from daffy.ee.lbl.gov (daffy.ee.lbl.gov [131.243.1.31])
by SpamWall.lbl.gov (8.9.0/8.9.0) with ESMTP id UAA16168
for <rmt@lbl.gov>; Tue, 13 Apr 1999 20:32:29 -0700 (PDT)
Received: (from vern@localhost)
by daffy.ee.lbl.gov (8.9.2/8.9.2) id UAA10818;
Tue, 13 Apr 1999 20:32:29 -0700 (PDT)
Message-Id: <199904140332.UAA10818@daffy.ee.lbl.gov>
To: rmt@lbl.gov
Subject: Fwd: WG Review: Reliable Multicast Transport (rmt)
Date: Tue, 13 Apr 1999 20:32:29 PDT
From: Vern Paxson <vern@ee.lbl.gov>
------- Forwarded Message
Date: Mon, 12 Apr 1999 10:40:26 -0400
From: The IESG <iesg-secretary@ietf.org>
Subject: WG Review: Reliable Multicast Transport (rmt)
To: IETF-Announce: ;
Cc: new-work@ietf.org, maddogs@ietf.org
reply-to: iesg@ietf.org
Sender: scoya@ns.cnri.reston.va.us
Status: U
A new IETF working group has been proposed in the Transport Area.
The IESG has not made any determination as yet.
The following Description was submitted, and is provided for
informational purposes only:
Reliable Multicast Transport (rmt)
- ----------------------------------
Description of Working Group:
The purpose of this WG is to standardize reliable multicast transport.
Initial efforts will focus solely on the standardization of the
one-to-many transport of large amounts of data. Due to the large
number of applications that fall into this category, and the
sometimes orthogonal requirements these applications exhibit, it is
believed that a "one size fits all" protocol will be unable to meet
the requirements of all applications. In recognition of this
observation, this working group expects to standardize more than one
protocol.
The first work item for this working group will be to write a
rationale document that outlines the space in which the one-to-many
transport protocols will be developed. This document will explain
the requirements that lead to the development of different mechanisms
(even though these mechanisms may have broader applicability than
just addressing those requirements).
The second work item for this working group will be a functional
decomposition document that defines a set of easily-separable
coarse-grained functional blocks, and possibly some coarse-grained
protocol "cores". Both the functional blocks and cores will be
derived from the experience that has already gained with a number
of advanced existing proposed solutions.
Once these two drafts are completed, this working group will examine
the success of these efforts and develop a strategy for developing
particular protocols. Once a strategy is agreed upon, the working
group will recharter to continue the standardization of specific
functional blocks and protocol cores.
This working group will work closely with the Internet Research Task
Force (IRTF) groups on Reliable Multicast (RMRG) and Secure Multicast
(SMUG), especially for meeting the congestion control and security
requirements mandated by RFC 2357. This working group may standardize
reliable multicast for additional scenarios beyond the one-to-many
transport of bulk data once they are sufficiently well understood.
Goals and Milestones:
May 99 Working Group chartered
Jun 99 Submit Internet-Drafts on rationale and functional block
Jul 99 Meet at IETF in Oslo
Aug 99 Revise drafts for submission as Informational RFCs
Aug 99 Recharter Working Group in light of analysis of functional
decomposition.
------- End of Forwarded Message
>From floyd@elk.aciri.org Mon Apr 19 16:59:10 1999
Received: from postal1.lbl.gov (localhost [127.0.0.1])
by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id QAA17555
for <rmt@listserv.lbl.gov>; Mon, 19 Apr 1999 16:59:09 -0700 (PDT)
Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1])
by postal1.lbl.gov (8.9.0/8.9.0) with ESMTP id QAA00366
for <rmt@listserv.lbl.gov>; Mon, 19 Apr 1999 16:59:09 -0700 (PDT)
Received: from elk.aciri.org ([192.150.187.21])
by SpamWall.lbl.gov (8.9.0/8.9.0) with ESMTP id QAA00355
for <rmt@lbl.gov>; Mon, 19 Apr 1999 16:59:08 -0700 (PDT)
Received: from elk.aciri.org (localhost [127.0.0.1])
by elk.aciri.org (8.9.2/8.9.2) with ESMTP id QAA89860
for <rmt@lbl.gov>; Mon, 19 Apr 1999 16:58:45 -0700 (PDT)
(envelope-from floyd@elk.aciri.org)
Message-Id: <199904192358.QAA89860@elk.aciri.org>
To: rmt@lbl.gov
From: Sally Floyd <floyd@aciri.org>
Subject: first draft of notes from the Reliable Multicast Transport BOF
Date: Mon, 19 Apr 1999 16:58:45 -0700
Sender: floyd@elk.aciri.org
Here is the first draft of the notes from the
Reliable Multicast Transport BOF. (Yes, a little late...)
Corrections could be sent to me, or to the list.
- Sally
-----------------------------------------------------
Reliable Multicast Transport BOF, Monday March 15, Minneapolis IETF.
Notetaker: Sally Floyd
Intro: Vern Paxson
The goal of this meeting is not to standardize reliable multicast
in this meeting, but to discuss strategies for standardizing reliable
multicast.
The Area Directors are very much in favor of setting up one Working
Group for this.
This BOF will explore two fundamental strategies for standardizing
reliable multicast: One approach, the building-block approach, is
to standardize modules or building blocks. The other approach,
the whole-protocol approach, is to standardize whole protocols.
The other issue for this BOF to explore is what a charter for an
RMT working group would look like.
Agenda-bashing:
Standardizing Reliable Multicast: Mark Handley
Viewgraphs:
http://www.aciri.org/mjh/rmbof.ps
http://www.aciri.org/mjh/rmbof.mgp (Magicpoint source files)
The Building Block Approach to RM Standardization: Mark Handley
Viewgraphs:
http://www.aciri.org/mjh/bb.ps
http://www.aciri.org/mjh/bb.mgp (Magicpoint source files)
Discussion:
How is FEC with the layered approach different from FEC with the
other three approaches (tree/ack-based, nack-based, nack-based with
network support).
Past history in the IETF of standardizing building blocks?
MMusic, IP telephony both have done this.
How would the building-block approach work? What are the performance
costs of doing the building-block approach?
Building blocks for mostly-reliable protocols? Mark: I don't think
that they need to be a separate class. Ohta disagrees.
Ohta: We should not begin standardization until congestion control
is nailed down.
Michael Speer: RTP is a good example of the building block approach
successfully applied in the past.
A concern about permutations of building blocks.
What happens first, the building blocks are defined and protocols
are standardized on top, or protocols are standardized while
building blocks are being standardized in parallel? Mark: this
is a hard process to manage.
Tony S: Perhaps the right granularity for the building block approach
is at the functional level. Mark: Superficially it seems that
packet formats are not necessary to standardize, but when you look
at FEC, you see that it might be useful to standardized packet
formats also.
Allison: The people who develop the protocols perhaps should write
the building blocks that are useful to them.
The whole-propocol approach:
Starburst: Ken Miller absent, due to airport problems, so Brian
Whetten is presenting his slides.
Viewgraphs:
http://www.aciri.org/RMT/RM-Miller.pdf
http://www.aciri.org/RMT/RM-Miller.ps
RMTP-II: Brian Whetten
Viewgraphs:
http://www.talarian.com/rmtp-ii/IETF%20RM%20BOF%20-%20March%201999.ppt
RMTP-II: http://www.talarian.com/rmtp-ii/overview.htm
Vern: The argument for the building-block approach is not short-term
payoff but that of long-term payoff, so I don't understand why
you say that the building block approach will save time in the
short-term.
Abel: It is premature to say that we need to standardize
four separate protocols; that will confuse the market.
Vern: You don't buy Mark's argument that RM is fundamentally
different than TCP, and that one size doesn't fit all?
Roger: I believe that you can't have a one-size-fits-all protocol.
Multiple working groups for the different protocols will loose the
commonality.
TCP evolved from a field of many unicast reliable protocols.
People could call their current protocols version 1, and let the
building-block-based approach be version 2.
Mark: Only a few of the protocols can be deployed in the
big-I Internet today, and other protocols are the ones that are
most in demand in Intranets, where there is router or server support.
Jon C.: I see RMTP and SRM as fully-fledged protocols, but I see
PGM as a protocol piece with router support. One reason that TCP
worked was that we had at least three versions of source code.
?: There is customer demand for reliable multicast in the global
Internet now. Please do not slow down the development of RMTP-II
and PGM.
Dino: Is the new working group going to work on interworking
between the reliable multicast protocols?
PGM: Tony Speakman
Viewgraphs:
ftp://ftpeng.cisco.com/speakman/bof.slides.ps
Tony: To address the building-block vs. whole-protocol approach: There
could be functional building blocks, or at the other end of the
spectrum, specific mechanics of what to do in routers. I am a
fan of the building-block approach to protocols, but there is
a software engineering challenge that is nontrivial.
Tony: The activity of delivering and deploying these protocols in
constrained circumstances is essential in determining what
the building blocks should be. You certainly don't want to
create building blocks that are not useful.
Vern: Is sounds like you are saying that you like the building
block approach, but we don't know the right building blocks yet.
Tony: I think we need to start with per-protocol working groups.
If we can get an API right for applications, then applications at
least can go ahead.
Tony: We need to provide deployable instances of reliable multicast
to push things along (to enable applications, to enable multicast
routing, to enable more reliable multicast).
Tony: Yes, eventually we need to break out the building blocks.
?: Maybe we can have working groups directed at application-specific
spaces. Does it make sense to decouple congestion control from
reliability? If we agree on that, does that influence the way
that we want to structure the working group?
Tony: There are service models underlying ACK-based and NACK-based
approaches.
Jon C: The internet has a habit of being heterogeneous. Does this
work involve changes to IP Multicast? These long-term issues might
come out of the working groups.
Michael Speer: I am all for experience. We have to figure out how
to punch four protocols through a protocol.
Roger: I think that we really need to have this experience shared
in a single group.
Aaron: I am reminded by the discussion that we have been having
on the PILC list, of the siren call of the market trying to push
things through as quickly as possible. The methodology of building
blocks doesn't sound baked. My proposal is to come up with
classifications of topologies.
?: I don't know if we know enough yet to know exactly what the
building blocks are. If we get the source code for these
protocols, why do we need to formalize the building block approach.
Maybe you get the building blocks as you develop it.
?: Why are we restricing ourselves to one-to-many? Many-to-many
is still very important.
Scott B.: He wants to hear from people what they think the
importance is of the differences between Internets and Intranets.
Vern: We will summarize to the RM mailing list. We haven't decided
whether to establish a separate mailing list.
>From vern@daffy.ee.lbl.gov Wed Apr 28 23:22:17 1999
Received: from postal1.lbl.gov (localhost [127.0.0.1])
by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id XAA17054
for <rmt@listserv.lbl.gov>; Wed, 28 Apr 1999 23:22:17 -0700 (PDT)
Received: from daffy.ee.lbl.gov (daffy.ee.lbl.gov [131.243.1.31])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id XAA09683
for <rmt@lbl.gov>; Wed, 28 Apr 1999 23:22:16 -0700 (PDT)
Received: (from vern@localhost)
by daffy.ee.lbl.gov (8.9.2/8.9.2) id XAA07986;
Wed, 28 Apr 1999 23:22:16 -0700 (PDT)
Message-Id: <199904290622.XAA07986@daffy.ee.lbl.gov>
To: rmt@lbl.gov
Subject: Fwd: WG ACTION: Reliable Multicast Transport (rmt)
Date: Wed, 28 Apr 1999 23:22:16 PDT
From: Vern Paxson <vern@ee.lbl.gov>
------- Forwarded Message
Date: Wed, 28 Apr 1999 16:20:42 -0400
From: The IESG <iesg-secretary@ietf.org>
Subject: WG ACTION: Reliable Multicast Transport (rmt)
To: IETF-Announce: ;
Cc: new-work@ietf.org
Sender: scoya@ns.cnri.reston.va.us
Status: U
A new working group has been formed in the Transport Area of the
IETF. Please contact the chair or Area Directors for additional
information.
Reliable Multicast Transport (rmt)
- ----------------------------------
Current Status: Active Working Group
Chair(s):
Allison Mankin <mankin@east.isi.edu>
Roger Kermode <ark008@email.mot.com>
Lorenzo Vicisano <lorenzo@cisco.com>
Transport Area Director(s):
Scott Bradner <sob@harvard.edu>
Vern Paxson <vern@aciri.org>
Transport Area Advisor:
Vern Paxson <vern@aciri.org>
Mailing Lists:
General Discussion:rmt@lbl.gov
To Subscribe: rmt-request@lbl.gov
In Body: Subject
Archive: Send msg to rmt-request@lbl.gov w/Subject of Archive Help
Description of Working Group:
The purpose of this WG is to standardize reliable multicast transport.
Initial efforts will focus solely on the standardization of the
one-to-many transport of large amounts of data. Due to the large
number of applications that fall into this category, and the
sometimes orthogonal requirements these applications exhibit, it is
believed that a "one size fits all" protocol will be unable to meet
the requirements of all applications. In recognition of this
observation, this working group expects to standardize more than one
protocol.
The first work item for this working group will be to write a
rationale document that outlines the space in which the one-to-many
transport protocols will be developed. This document will explain
the requirements that lead to the development of different mechanisms
(even though these mechanisms may have broader applicability than
just addressing those requirements).
The second work item for this working group will be a functional
decomposition document that defines a set of easily-separable
coarse-grained functional blocks, and possibly some coarse-grained
protocol "cores". Both the functional blocks and cores will be
derived from the experience that has already gained with a number
of advanced existing proposed solutions.
Once these two drafts are completed, this working group will examine
the success of these efforts and develop a strategy for developing
particular protocols. Once a strategy is agreed upon, the working
group will recharter to continue the standardization of specific
functional blocks and protocol cores.
This working group will work closely with the Internet Research Task
Force (IRTF) groups on Reliable Multicast (RMRG) and Secure Multicast
(SMUG), especially for meeting the congestion control and security
requirements mandated by RFC 2357. This working group may standardize
reliable multicast for additional scenarios beyond the one-to-many
transport of bulk data once they are sufficiently well understood.
Goals and Milestones:
May 99 Working Group chartered
Jun 99 Submit Internet-Drafts on rationale and functional block
Jul 99 Meet at IETF in Oslo
Aug 99 Revise drafts for submission as Informational RFCs
Aug 99 Recharter Working Group in light of analysis of functional
decomposition.
------- End of Forwarded Message
>From chiu@bridge.East.Sun.COM Thu Apr 29 08:19:14 1999
Received: from postal1.lbl.gov (localhost [127.0.0.1])
by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id IAA18568
for <rmt@listserv.lbl.gov>; Thu, 29 Apr 1999 08:19:14 -0700 (PDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id IAA26883
for <rmt@lbl.gov>; Thu, 29 Apr 1999 08:19:13 -0700 (PDT)
Received: from East.Sun.COM ([129.148.1.241])
by mercury.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id IAA14181
for <rmt@lbl.gov>; Thu, 29 Apr 1999 08:19:10 -0700 (PDT)
Received: from bridge.East.Sun.COM by East.Sun.COM (SMI-8.6/SMI-5.3)
id LAA06288; Thu, 29 Apr 1999 11:19:03 -0400
Received: from bridge (bridge [129.148.75.125])
by bridge.East.Sun.COM (8.9.1b+Sun/8.9.1) with SMTP id LAA16925
for <rmt@lbl.gov>; Thu, 29 Apr 1999 11:18:59 -0400 (EDT)
Message-Id: <199904291518.LAA16925@bridge.East.Sun.COM>
Date: Thu, 29 Apr 1999 11:18:59 -0400 (EDT)
From: Dah Ming Chiu - Sun Microsystems <chiu@bridge.East.Sun.COM>
Reply-To: Dah Ming Chiu - Sun Microsystems <chiu@bridge.East.Sun.COM>
Subject: RE: Fwd: WG ACTION: Reliable Multicast Transport (rmt)
To: rmt@lbl.gov
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: o4LB+qnOS69peIqVLXmEdw==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc
testing the new distribution list...
>The first work item for this working group will be to write a
>rationale document that outlines the space in which the one-to-many
>transport protocols will be developed. This document will explain
>the requirements that lead to the development of different mechanisms
>(even though these mechanisms may have broader applicability than
>just addressing those requirements).
There are a couple of rather orthognal application requirements for a
"one-to-many transport of large amounts of data". I will call them
"file transfer" and "publish and subscribe" below.
1) File transfer
All data is available at the beginning of the session. The performance
metric is time to transfer the whole file to the whole multicast group
(however you care to define what the group is).
2) Publish and Subscribe
Data arrive bits and pieces during the session. The performance metric
is the time it takes to get each piece to the whole group. Each bit and
piece may not be very big.
The repair and flow/congestion control algorithms can be quite different
for the two cases. On the other hand, a single protocol can probably
be designed to handle both of these extremes reasonably well.
>From dykim@ccl.chungnam.ac.kr Wed May 12 18:19:48 1999
Received: from postal1.lbl.gov (localhost [127.0.0.1])
by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id SAA27417
for <rmt@listserv.lbl.gov>; Wed, 12 May 1999 18:19:47 -0700 (PDT)
Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id SAA29521
for <rmt@listserv.lbl.gov>; Wed, 12 May 1999 18:19:46 -0700 (PDT)
Received: from ccl.chungnam.ac.kr (ccl.chungnam.ac.kr [168.188.48.128])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id SAA29509
for <rmt@lbl.gov>; Wed, 12 May 1999 18:19:43 -0700 (PDT)
Received: from ccl.chungnam.ac.kr (ghil.chungnam.ac.kr [168.188.48.2])
by ccl.chungnam.ac.kr (8.9.0/8.9.0) with ESMTP id LAA15215;
Thu, 13 May 1999 11:17:21 +1000 (KDT)
Message-ID: <373A283B.BB789A41@ccl.chungnam.ac.kr>
Date: Thu, 13 May 1999 10:17:47 +0900
From: Dae Young KIM <dykim@ccl.chungnam.ac.kr>
Organization: Chungnam Nat'l Univ., InfoCom Eng. Dept.
X-Mailer: Mozilla 4.51 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: rmt <rmt@lbl.gov>, rm <rm@mash.CS.Berkeley.EDU>
Subject: taxonomy
Content-Type: text/plain; charset=EUC-KR
Content-Transfer-Encoding: 7bit
Dear all,
Obeserving the mails on rm/rmt, I find people would like to
differentiate among different topological multicast contexts by calling
them 'one-to-many' or 'many-to-many'.
One way of differentiating among these different multicast context would
be use terms like:
Simplex Multicast (SM)
Duplex Multicast (DM)
N-plex Multicast (NM)
Simplex Multicast is a one-to-many multicast wherein there are one
sender and many receivers; one send-only user with multiple receive-only
users.
Duplex Multicast is a one-with-many multicast wherein all are send and
receive members but whereas the data from the central (master) reach
every other member, data from each of the rest flow only to the master.
N-plex Multicast is the one wherein all are send- and receive-capable
and data from any member reach all the other members.
Here, only the main data flow is used as a criteria for classification.
For example, backward controls (e.g., ACKs) can be sent also in Simplex
Multicast.
If people would agree to do so, we can use these simpler wordings than
have to say every time 'one-to-many', 'many-to-many', ect.
--
Dae Young
http://ccl.chungnam.ac.kr/~dykim/
*** Come to ICT'99 ***
http://ict99.icu.ac.kr
>From luigi@labinfo.iet.unipi.it Tue May 18 10:38:39 1999
Received: from postal1.lbl.gov (localhost [127.0.0.1])
by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id KAA24736
for <rmt@listserv.lbl.gov>; Tue, 18 May 1999 10:38:39 -0700 (PDT)
Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id KAA13819
for <rmt@listserv.lbl.gov>; Tue, 18 May 1999 10:38:38 -0700 (PDT)
Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5])
by SpamWall.lbl.gov (8.9.3/8.9.3) with SMTP id KAA13808
for <rmt@lbl.gov>; Tue, 18 May 1999 10:38:35 -0700 (PDT)
Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id RAA01957; Tue, 18 May 1999 17:32:39 +0200
From: Luigi Rizzo <luigi@labinfo.iet.unipi.it>
Message-Id: <199905181532.RAA01957@labinfo.iet.unipi.it>
Subject: RMRG meeting info. (fwd)
To: rmt@lbl.gov
Date: Tue, 18 May 1999 17:32:38 +0200 (MET DST)
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
(sorry for the intrusion and the duplicate for those also subscribing
to the irtf rmrg list...)
Dear RM'ers,
as the date for the RMRG meeting (5&6 june, Pisa) is approaching,
i need to know how many people are coming in order to arrange things
properly. The page with program and travel info is at
http://www.iet.unipi.it/~luigi/rmrg/
There is no registration fee for the meeting, but if you are coming,
would you mind reply to this email with the following data (for
the name tags and participant list):
NAME:
EMAIL:
COMPANY
For those interested, I am organizing a dinner in Lucca on saturday
night, but i am afraid i could only reserve some 40 seats at the
restaurant (which could be enough, i just have no idea. If numbers
are significantly higher, i will try to arrange something). The
cost should be around 50.000 lire each. If you are interested,
please mention this in the email (don't worry, you will have time
to see Pisa as well; the town is small!)
thanks
luigi
-----------------------------------+-------------------------------------
Luigi RIZZO, luigi@iet.unipi.it . Dip. di Ing. dell'Informazione
http://www.iet.unipi.it/~luigi/ . Universita` di Pisa
TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy)
http://www.iet.unipi.it/~luigi/ngc99/
==== First International Workshop on Networked Group Communication ====
-----------------------------------+-------------------------------------
>From luigi@labinfo.iet.unipi.it Mon Jun 14 10:47:21 1999
Received: from postal1.lbl.gov (localhost [127.0.0.1])
by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id KAA10172
for <rmt@listserv.lbl.gov>; Mon, 14 Jun 1999 10:47:20 -0700 (PDT)
Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id KAA27511
for <rmt@listserv.lbl.gov>; Mon, 14 Jun 1999 10:47:19 -0700 (PDT)
Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5])
by SpamWall.lbl.gov (8.9.3/8.9.3) with SMTP id KAA27478
for <rmt@lbl.gov>; Mon, 14 Jun 1999 10:47:15 -0700 (PDT)
Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id RAA09910; Mon, 14 Jun 1999 17:18:06 +0200
From: Luigi Rizzo <luigi@labinfo.iet.unipi.it>
Message-Id: <199906141518.RAA09910@labinfo.iet.unipi.it>
Subject: CfP: First Intl. Workshop on Networked Group Communication
To: luigi@labinfo.iet.unipi.it (Luigi Rizzo)
Date: Mon, 14 Jun 1999 17:18:05 +0200 (MET DST)
In-Reply-To: <199904011510.RAA16046@labinfo.iet.unipi.it> from "Luigi Rizzo" at Apr 1, 99 05:09:56 pm
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Just a brief reminder -- the deadline (July 1st) for submissions to the
First International Workshop on Networked Group Communication (NGC99)
http://www.iet.unipi.it/~luigi/ngc99/
is approaching. Please note that in addition to regular contributions
we will also select a few "student contributions", authored by
students only.
See the online call for papers at the above URL for detailed info.
cheers
luigi
-----------------------------------+-------------------------------------
Luigi RIZZO, luigi@iet.unipi.it . Dip. di Ing. dell'Informazione
http://www.iet.unipi.it/~luigi/ . Universita` di Pisa
TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy)
http://www.iet.unipi.it/~luigi/ngc99/
==== First International Workshop on Networked Group Communication ====
-----------------------------------+-------------------------------------
>From ark008@email.mot.com Sun Jun 20 18:31:27 1999
Received: from postal1.lbl.gov (localhost [127.0.0.1])
by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id SAA02910
for <rmt@listserv.lbl.gov>; Sun, 20 Jun 1999 18:31:27 -0700 (PDT)
Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id SAA01718
for <rmt@listserv.lbl.gov>; Sun, 20 Jun 1999 18:31:26 -0700 (PDT)
Received: from motgate2.mot.com (motgate2.mot.com [129.188.136.102])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id SAA01714
for <rmt@lbl.gov>; Sun, 20 Jun 1999 18:31:25 -0700 (PDT)
Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate2.mot.com (MOT-motgate2 1.0) with ESMTP id UAA08202 for <rmt@lbl.gov>; Sun, 20 Jun 1999 20:32:34 -0500 (CDT)]
Received: [from superman.arc.corp.mot.com (superman.arc.corp.mot.com [217.1.10.18]) by pobox.mot.com (MOT-pobox 2.0) with SMTP id UAA05678 for <rmt@lbl.gov>; Sun, 20 Jun 1999 20:31:18 -0500 (CDT)]
Received: from email.mot.com ([217.1.10.230]) by superman.arc.corp.mot.com (8.6.12/8.6.12) with ESMTP id LAA05080 for <rmt@lbl.gov>; Mon, 21 Jun 1999 11:30:20 +1000
Message-ID: <376D95EF.31125AA3@email.mot.com>
Date: Mon, 21 Jun 1999 11:31:27 +1000
From: Roger Kermode <ark008@email.mot.com>
Organization: Motorola
X-Mailer: Mozilla 4.6 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: rmt@lbl.gov
Subject: RMT: Design Space and Building Blocks Internet Drafts now available
Content-Type: multipart/mixed;
boundary="------------7B71CA24ABEE300E086F0BEF"
This is a multi-part message in MIME format.
--------------7B71CA24ABEE300E086F0BEF
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Dear Everyone,
We'd like to announce the availability of the two internet-drafts on
the design-space and building-blocks for one-to-many bulk-data
transfer as per the RMT WG charter. They will shortly appear on the
ietf rfc-mirrors. Until then you can fetch them from
http://www.aciri.org/rmt/
cheers,
Allison, Roger, and Lorenzo
--------------7B71CA24ABEE300E086F0BEF
Content-Type: text/x-vcard; charset=us-ascii;
name="ark008.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Roger Kermode
Content-Disposition: attachment;
filename="ark008.vcf"
begin:vcard
n:Kermode;Roger
tel;fax:+61-2-9666-0501
tel;home:+61-2-9664-8335
tel;work:+61-2-9666-0558
x-mozilla-html:FALSE
url:www.mot.com.au
org:Motorola Australian Research Centre;Scalable Commodity Internet Lab
version:2.1
email;internet:ark008@email.mot.com
title:Principal Research Engineer
adr;quoted-printable:;;Level 3,=0D=0A12 Lord St.;Botany;NSW;2019;Australia
fn:Roger Kermode
end:vcard
--------------7B71CA24ABEE300E086F0BEF--
>From nsyracus@ns.cnri.reston.va.us Mon Jun 21 10:43:03 1999
Received: from postal1.lbl.gov (localhost [127.0.0.1])
by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id KAA04845
for <rmt@listserv.lbl.gov>; Mon, 21 Jun 1999 10:43:03 -0700 (PDT)
Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id KAA12968
for <rmt@listserv.lbl.gov>; Mon, 21 Jun 1999 10:43:02 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id KAA12962
for <rmt@lbl.gov>; Mon, 21 Jun 1999 10:43:00 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06590;
Mon, 21 Jun 1999 13:42:26 -0400 (EDT)
Message-Id: <199906211742.NAA06590@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: rmt@lbl.gov
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-rmt-buildingblocks-00.txt
Date: Mon, 21 Jun 1999 13:42:26 -0400
Sender: nsyracus@ns.cnri.reston.va.us
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Reliable Multicast
Transport Working Group of the IETF.
Title : Reliable Multicast Transport Building Blocks for
One-to-Many Bulk-Data Transfer
Author(s) : B. Whetten, L.Vicisano, R. Kermode, M. Handley,
S.Floyd
Filename : draft-ietf-rmt-buildingblocks-00.txt
Pages : 19
Date : 18-Jun-99
This document describes a framework for the standardization of bulk-data
reliable multicast transport. It builds upon the experience gained
during the deployment of several classes of contemporary reliable
multicast transport, and attempts to pull out the commonalties between
these classes of protocols into a number of building blocks. To that
end, this document recommends that certain components that are common to
multiple protocol classes be standardized as 'building blocks.' The
remaining parts of the protocols, consisting of highly protocol specific
tightly intertwined functions shall be designated as 'protocol cores.'
Thus, each protocol can then be constructed by merging a 'protocol core'
with a number of 'building blocks' which can be re-used across multiple
protocols.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rmt-buildingblocks-00.txt
Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-rmt-buildingblocks-00.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.
Send a message to:
mailserv@ietf.org.
In the body type:
"FILE /internet-drafts/draft-ietf-rmt-buildingblocks-00.txt".
NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv@ietf.org"
Content-Type: text/plain
Content-ID: <19990618093419.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-rmt-buildingblocks-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-rmt-buildingblocks-00.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19990618093419.I-D@ietf.org>
--OtherAccess--
--NextPart--
>From nsyracus@ns.cnri.reston.va.us Mon Jun 21 11:31:59 1999
Received: from postal1.lbl.gov (localhost [127.0.0.1])
by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id LAA05250
for <rmt@listserv.lbl.gov>; Mon, 21 Jun 1999 11:31:58 -0700 (PDT)
Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id LAA29498
for <rmt@listserv.lbl.gov>; Mon, 21 Jun 1999 11:31:57 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id LAA29483
for <rmt@lbl.gov>; Mon, 21 Jun 1999 11:31:56 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07374;
Mon, 21 Jun 1999 14:31:23 -0400 (EDT)
Message-Id: <199906211831.OAA07374@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: rmt@lbl.gov
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-rmt-design-space-00.txt
Date: Mon, 21 Jun 1999 14:31:23 -0400
Sender: nsyracus@ns.cnri.reston.va.us
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Reliable Multicast Transport Working Group of the IETF.
Title : The Reliable Multicast Design Space for Bulk Data Transfer
Author(s) : M. Handley, S. Floyd, B. Whetten, R. Kermode, L. Vicisano
Filename : draft-ietf-rmt-design-space-00.txt
Pages : 19
Date : 18-Jun-99
The design space for reliable multicast is rich, with many possible
solutions having been devised. However, application requirements serve
to constrain this design space to a relatively small solution space.
This document provides an overview of the design space and the ways in
which application constraints affect possible solutions.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rmt-design-space-00.txt
Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-rmt-design-space-00.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.
Send a message to:
mailserv@ietf.org.
In the body type:
"FILE /internet-drafts/draft-ietf-rmt-design-space-00.txt".
NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv@ietf.org"
Content-Type: text/plain
Content-ID: <19990618111448.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-rmt-design-space-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-rmt-design-space-00.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19990618111448.I-D@ietf.org>
--OtherAccess--
--NextPart--
>From hofmann@bell-labs.com Fri Jun 25 07:30:10 1999
Received: from postal1.lbl.gov (localhost [127.0.0.1])
by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id HAA25949
for <rmt@listserv.lbl.gov>; Fri, 25 Jun 1999 07:30:09 -0700 (PDT)
Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id HAA06753
for <rmt@listserv.lbl.gov>; Fri, 25 Jun 1999 07:30:08 -0700 (PDT)
Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6])
by SpamWall.lbl.gov (8.9.3/8.9.3) with SMTP id HAA06740
for <rmt@lbl.gov>; Fri, 25 Jun 1999 07:30:05 -0700 (PDT)
Received: from chair.dnrc.bell-labs.com ([135.180.161.201]) by dirty; Fri Jun 25 10:29:17 EDT 1999
Received: from bell-labs.com (apache [135.180.160.86])
by chair.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id KAA09206;
Fri, 25 Jun 1999 10:29:14 -0400 (EDT)
Message-ID: <37739232.32295F6C@bell-labs.com>
Date: Fri, 25 Jun 1999 10:29:06 -0400
From: Markus Hofmann <hofmann@bell-labs.com>
Organization: Bell Labs / Lucent, USA
X-Mailer: Mozilla 4.6 [en] (WinNT; U)
X-Accept-Language: en,de-DE
MIME-Version: 1.0
To: rmt@lbl.gov, rm@mash.cs.berkeley.edu
CC: Jonathan Rosenberg <jdrosen@dnrc.bell-labs.com>,
Jorg Nonnenmacher <nonnen@research.bell-labs.com>,
Markus Hofmann <hofmann@bell-labs.com>
Subject: new draft on feedback for multicast
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Folks,
we have put together an Internet draft that talks about the problem of
feedback for multicast. Its basically a taxonomy of the various
mechanisms that can be applied for sending feedback on multicast
reception. We believe this taxonomy is useful for both rmt (reliable
multicast transport) and avt. For rmt, it outlines the options for a
feedback building block, and for avt, options for an alternate profile
for RTCP (which was discussed at the last meeting).
The draft is an individual submission, and will appear in the archives
shortly. Until then, you can pick up a copy at:
http://www.cs.columbia.edu/~jdrosen/papers/draft-hnrs-rmt-avt-feedback-00.txt
Comments welcome.
Thanks,
Markus
>From luigi@labinfo.iet.unipi.it Tue Jun 29 04:17:12 1999
Received: from postal1.lbl.gov (localhost [127.0.0.1])
by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id EAA08273
for <rmt@listserv.lbl.gov>; Tue, 29 Jun 1999 04:17:11 -0700 (PDT)
Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id EAA07959
for <rmt@listserv.lbl.gov>; Tue, 29 Jun 1999 04:17:10 -0700 (PDT)
Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5])
by SpamWall.lbl.gov (8.9.3/8.9.3) with SMTP id EAA07955
for <rmt@lbl.gov>; Tue, 29 Jun 1999 04:17:08 -0700 (PDT)
Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id KAA03568; Tue, 29 Jun 1999 10:34:16 +0200
From: Luigi Rizzo <luigi@labinfo.iet.unipi.it>
Message-Id: <199906290834.KAA03568@labinfo.iet.unipi.it>
Subject: NGC99 Workshop -- New Submission Deadline 13 july 1999 !!!
To: luigi@labinfo.iet.unipi.it (Luigi Rizzo)
Date: Tue, 29 Jun 1999 10:34:15 +0200 (MET DST)
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
NGC99 Workshop -- New Submission Deadline 13 july 1999 !!!
Dear All,
as you all know the "Networking Paper Deadline Control Authority"
has announced potential congestion for deadlines around the first
week of july (read: INFOCOM2000 has moved its deadline to july 5th).
As this might have an impact on the schedule of potential authors,
and also in response to a huge number of requests for extensions,
we have decided to move the deadline for submissions to NGC99
Workshop.
>>> The NEW DEADLINE FOR SUBMISSIONS is 13 July 1999, 10am (GMT+2) <<<
We hope that this move will minimize deadline conflicts with other
multicast-related events and give authors the time they requested
to work on their papers.
Because we already had tight schedules for the review process, the
switch of deadlines was not an easy decision. Thus we encourage
potential authors to SUBMIT NOW a preliminary title+abstract for
their papers so we can start mapping papers to the reviewers.
cheers
luigi
-----------------------------------+-------------------------------------
Luigi RIZZO, luigi@iet.unipi.it . Dip. di Ing. dell'Informazione
http://www.iet.unipi.it/~luigi/ . Universita` di Pisa
TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy)
http://www.iet.unipi.it/~luigi/ngc99/
==== First International Workshop on Networked Group Communication ====
-----------------------------------+-------------------------------------
>From luby@dfountain.com Wed Jun 30 13:01:09 1999
Received: from postal1.lbl.gov (localhost [127.0.0.1])
by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id NAA17625
for <rmt@listserv.lbl.gov>; Wed, 30 Jun 1999 13:01:09 -0700 (PDT)
Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id NAA05435
for <rmt@listserv.lbl.gov>; Wed, 30 Jun 1999 13:01:08 -0700 (PDT)
Received: from monarch.dfountain.com ([207.90.190.130])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id NAA05429
for <rmt@lbl.gov>; Wed, 30 Jun 1999 13:01:07 -0700 (PDT)
Received: by PACIFIC with Internet Mail Service (5.5.2448.0)
id <MB17KWBT>; Wed, 30 Jun 1999 12:53:02 -0700
Message-ID: <619F2FB3840CD311AC2C0090273BF1AC017BC1@PACIFIC>
From: Mike Luby <luby@dfountain.com>
To: "'rmt@lbl.gov'" <rmt@lbl.gov>
Cc: Mike Luby <luby@dfountain.com>
Subject: Short version of comments on building blocks and design space dra
fts
Date: Wed, 30 Jun 1999 12:52:57 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="iso-8859-1"
RMT mailing list:
I have some proposals and comments on both the building blocks draft and the
design space draft that I am including in the next two emails. I include
below some preliminary motivation (the short version) for the primary
proposal. The detailed comments on the two drafts explore the ramifications
of this proposal and provide additional commentary as well.
Mike Luby
Digital Fountain and ICSI
A BRIEF MOTIVATION FOR MY COMMENTS:
One of the primary motivations for my writing the detailed comments on both
the building blocks draft and
the design space draft is to propose the separation of data reliability into
two logical components, which I
call the ensuring goodput component and the reporting reception component.
Ensuring goodput is the
component that makes sure enough information eventually gets to the
receivers so that they can reliably
recover the data, and reporting reception is the component that makes sure
the sender receives confirmation
that receivers have recovered the data. The argument for making this
separation is that for IP multicast
there are mechanisms that are excellent for ensuring goodput (using NACK
packets or FEC data packets)
that do not alone provide reporting reception, but overall are very
efficient at providing reliability when
augmented with mechanisms for providing reporting reception.
For TCP/IP, ACK packets are used to implement both components, and thus the
distinction between the
two components is blurred because of the use of the same mechanism. ACK
packets can also be used to
implement both components of reliability for IP multicast, but in addition
NACK packets and FEC data
packets have turned out to be very useful and, in some circumstances, more
efficient than ACK packets for
ensuring goodput. However, neither NACK packets nor FEC data packets alone
are enough to support the
reporting reception component of data reliability, and if this is needed
then other mechanisms should be
used. (NACK packets can provide a very limited amount of reception
reporting, but FEC data packets
provide none.) Yet, mechanisms have been proposed for the reporting
reception component of reliability
(e.g., ACK the entire application data unit) that when used in combination
with FEC data packets or NACK
packets for ensuring goodput provide overall reliability very efficiently.
Furthermore, there are multicast
applications where ensuring goodput is required, but not reporting
reception. Thus, it makes sense to
separate reliability into these two components in these two IP multicast
drafts.
>From luby@dfountain.com Wed Jun 30 13:02:40 1999
Received: from postal1.lbl.gov (localhost [127.0.0.1])
by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id NAA17651
for <rmt@listserv.lbl.gov>; Wed, 30 Jun 1999 13:02:40 -0700 (PDT)
Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id NAA05967
for <rmt@listserv.lbl.gov>; Wed, 30 Jun 1999 13:02:39 -0700 (PDT)
Received: from monarch.dfountain.com ([207.90.190.130])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id NAA05951
for <rmt@lbl.gov>; Wed, 30 Jun 1999 13:02:37 -0700 (PDT)
Received: by PACIFIC with Internet Mail Service (5.5.2448.0)
id <MB17KWB4>; Wed, 30 Jun 1999 12:54:33 -0700
Message-ID: <619F2FB3840CD311AC2C0090273BF1AC017BC2@PACIFIC>
From: Mike Luby <luby@dfountain.com>
To: "'rmt@lbl.gov'" <rmt@lbl.gov>
Cc: Mike Luby <luby@dfountain.com>
Subject: Comments on Building Blocks draft
Date: Wed, 30 Jun 1999 12:54:24 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="iso-8859-1"
Michael Luby, Digital Fountain and ICSI
Comments on:
Reliable Multicast Transport Building Blocks for One-to-Many
Bulk-Data Transfer
<draft-ietf-rmt-buildingblocks-00.txt>
General Comments
One key point that seems to be largely missing from the document <draft-
ietf-rmt-buildingblocks-00.txt> (hereafter referred to as the 'building
blocks
draft') in the definition of data reliability is a distinction between:
(a) Ensuring goodput: Protocols to ensure that a sender sends data
packets that are useful to receivers in recovering an application
data unit.
(b) Reporting reception: Protocols to ensure receivers report
reception status information of a given application data unit back
to a sender (or other management entity).
For different applications both can be important, and it would be
useful to develop the language in the building blocks draft so that
they are considered as separate components and so that the different
mechanisms for doing both can be described separately. Of course for
some overall protocols the mechanisms for implementing these two
components may be intertwined and thus there is little distinction
between these two components, but for many overall protocols this
distinction is useful and crucial. These two components together
loosely constitute the data reliability component in the current
building blocks draft.
The notion of application data unit depends on the application, and for
some applications it is not defined, although in most cases it can be
defined in a way that makes sense. For example, for file distribution
the application data unit is usually defined to be the entire file.
For a streaming video application, the application data unit may be a
single frame of the video, or it may be a group of pictures (several
frames that are encoded as a unit) in an MPEG transmission, or it may
be defined as 10 seconds of the video stream.
In the above description of ensuring goodput, the definition of
'useful' depends on the application. For example, for file
distribution it is 'useful' to a receiver to receive a set of packets
that allow the entire file to be recovered. For other applications,
such as MPEG streaming video, it may be 'useful' even if only a low
quality video can be played out from the received packets, and the
higher the quality of the playback from the received packets the more
'useful' those set of packets are.
In the above description of reporting reception, the definition of
'reception status information' also depends on the application. A
common requirement for reception status information for file
distribution is notification of completion by each receiver once it can
recover the file. A more stringent form might be that a receiver sends
status information to the sender each time another 10% of the download
has been completed. A less stringent requirement might be that no
reception status information is ever sent back to the sender. For a
video streaming application, reception status information may include
the quality of the video that is played out. Status information can be
useful for a variety of purposes, including confirmation of receipt of
an application data unit for both billing and tracking reasons.
The interaction between the various building block components can be
crucial, either as building blocks that work together to create higher
level functionality or in terms of implementations. As an example of
higher level functionality, ensuring goodput combined with reporting
reception provides what can be considered full data reliability, e.g.,
the file gets to the receivers as quickly as possible and the sender
knows when each receiver has fully recovered the file. As another
example, reporting reception can be very useful when combined with
group membership to decide when the sender stops transmitting packets
containing data about a given application data unit, e.g., stop
transmitting when all members in the group have reported that they have
completed the reception of the file. As an example of implementation
interaction, in some protocols there is an intimate connection between
the congestion control mechanisms used and the ensuring goodput
mechanisms.
A primary motivation for having ensuring goodput as a building block
component is that there may be packet loss that is varied both over
different receivers and over different time periods in a multicast
transmission. The basic mechanisms that have been proposed for
ensuring goodput can be partitioned into the following general
categories:
1) ACK based protocols: receivers send positive acknowledgements for
received packets, the sender resends packets that are not
acknowledged.
2) NACK based protocols: receivers send negative acknowledgements when
they perceive that they have missed packets that have been sent, the
sender resends packets that are acknowledged.
3) FEC based protocols: the sender uses some form of erasure codes (FEC
codes) to ensure that all packets are sent are useful to all
receivers.
Full descriptions of these types of protocols and their hybrids and
variants have all been described in the literature and in the building
blocks draft. It may be advantageous to consider defining building
blocks with respect to these three sub-components.
Primary motivations for reporting reception are network efficiency
(e.g., stop the transmission when all receivers are finished), billing
(e.g., a receiver can only be charged if it is confirmed that they
received the full file), and tracking (e.g., crucial for monitoring the
scalability and usefulness of the overall system). Examples of the
mechanisms for reporting reception include piggy-backing this
information in ACK-NACK packets, implicit usage of ACK-NACK packets,
sending unicast packets directly back to the sender, and sending
unicast packets to higher level management application tools.
The proposals made here are that:
i. The notion of an application data unit is useful and should be
defined explicitly and examples should be given. It may be for
some applications that an application data unit does not make
sense, but this is the exception rather than the rule.
ii. Components should be defined for both ensuring goodput and
reporting reception. One use of the combination of these two
components is to provide what is called data reliability in the
current building blocks draft. While it might be tempting to call
ensuring goodput by the name data reliability since ensuring
goodput is close in meaning to the definition of data reliability
in the current draft, this would be confusing. For example, it
seems that implicitly data reliability in the current draft
sometimes does and sometimes does not include some form of
reporting reception, depending on the mechanisms used to implement
it. (This explains in large part the differences between the
various types of delivery guarantees for different reliability
protocols in the current building blocks draft.) For example, ACKs
may be used for ensuring goodput as well as for reporting
reception. On the other hand, NACKs and FEC cannot be directly used
to implement reporting reception, and other mechanisms must be
employed. There is nothing wrong with combining the
implementations of one or more components. For example, ACKs could
be used simultaneously for verifying receipt of data packets so
that they are not retransmitted (part of ensuring goodput) and for
reporting reception of an entire file (as witnessed by all packets
constituting the file being ACKed). Nevertheless, it seems cleaner
to logically separate data reliability into ensuring goodput and
reporting reception as suggested in these comments, especially
since different approaches implement them differently.
iii. Consider decomposing ensuring goodput into 'ACK', 'NACK', and 'FEC'
building block mechanisms (and perhaps into some hybrids including
'HACK' and schemes that aggregate).
iv. Integrate these definitions into the other parts of the building
blocks draft, including descriptions as appropriate of how they may
interact functionally and how they may interact as mechanisms.
v. Consider the specific comments made in the following subsection in
conjunction with the four preceding proposals.
Specific Comments
The specific comments on the building blocks draft contained in this
section are written in a style that assumes the above proposals have
been accepted for incorporation into the building blocks draft. If a
full or partial incorporation of the proposals does not occur, then
these specific comments are still valid and can be considered
independently of the proposals on their own merits.
1. Page 4, Section 1.1: The title of this section and the lead in
paragraph are misleading. This section is all about ensuring
goodput, and how this impacts receiver scalability. The current
title suggests that the section is focused on complete protocol
families instead of just the ensuring goodput components of these
protocols. The title is more appropriately 'Ensuring goodput
Mechanisms'. The current lead in paragraph suggests the section is
about receiver scalability. The lead in paragraph would be better
suited to say that ensuring goodput is one of the crucial issues
that affects receiver scalability, and then talk about the
scalability of the ensuring goodput implementations used in several
protocols. There are other components that also affect receiver
scalability, including congestion control (already mentioned in the
section), group management, and reporting reception.
2. Page 4, Parts 1-4: The difference in the delivery guarantees between
the different protocols is a function of a combination of the
ensuring goodput component and the reporting reception component.
In some of the described protocols there is both an ensuring goodput
component and a reporting reception component, whereas for other
described protocols there is only an ensuring goodput component. It
is possible to supplement each protocol that is lacking reporting
reception with this component so that all protocols would have about
the same level of delivery guarantees.
3. Page 4, Part 3, Router assist: It seems clear that adding an
appropriate reporting reception component would provide message
stability.
4. Page 4, Part 4, Open-Loop delivery: The implication of how this is
written is that this mechanism provides a lower reliability
guarantee, and that FEC is the reason why. An FEC based ensuring
goodput implementation, when combined with an appropriate reporting
reception component, has the potential for providing the highest and
most efficient type of overall delivery reliability. For some types
of applications, it is true that one can afford a lower level of
overall delivery reliability, and thus one might consider a
deployment with no reporting reception component. However, with an
FEC based ensuring goodput component it is easy to add a low
bandwidth reporting reception component. Furthermore, the
combination of a FEC based ensuring goodput component and a
reporting reception component ensures the highest level of overall
reliability, is as efficient as possible, and because it is low
bandwidth it fits in very nicely with even highly-asymmetric
networks such as satellite.
5. Page 4, Section 2: It is stated that 'no single reliable multicast
protocol can meet the needs of all applications'. This is certainly
the case today, and all evidence points to this conclusion, but as
written this categorically concludes that there is no possibility in
the future of some overall protocol that can meet the needs of all
applications. Suggest rephrasing this so that it isn't embarrassing
sometime in the future (although given the six month lifetime of the
draft, maybe this is not an issue).
6. Page 6, Section 2.3, Building Block Requirements: The last sentence
of the 'Wide Applicability' section concludes that the fourth class
(with no back channel) is fundamentally different than the first
three and so may be less amenable to building blocks. One the
fourth class is defined properly (with the possibility of a
reporting reception component that would require a limited back
channel), I don't see any reason why it is any different than the
other three in terms of amenability to building blocks. Some
aspects of it are simpler, i.e., no back channel needed for ensuring
goodput, but we are trying to design overall protocols, not just the
ensuring goodput component, and thus just because one component is
implemented differently (in fact, it is pure 'FEC') doesn't put it
out of scope.
7. Page 7, Section 3, Protocol Components, last paragraph: There is a
conclusion there that the fourth class of protocols defined above
does not require many of these functions, including loss
notification, loss recovery, and group membership. When the FEC
portion of that protocol is redefined to be just the ensuring
goodput component of an overall protocol, a full version of the
fourth class definitely could benefit from some of these other
functions. Loss notification is not part of the overall protocol
for ensuring goodput, but it may be part of a congestion control
protocol, and it may be part of the reporting reception component.
Group membership combined with a reporting reception component may
be crucial for such an overall protocol to be efficient, e.g., stop
transmitting when all members of the group have reported completion.
8. Page 8, Section 3.1, Sub-Components Definition: Replace the data
reliability component with an ensuring goodput component and a
reporting reception component. The sub-parts of ensuring goodput
should be the same as for the current definition of data
reliability, except that the full definition should concentrate on
ensuring goodput aspects and not on reporting reception. The sub-
parts of the reporting reception component may include confirmation
that a particular receiver has completely received an application
data unit, or received enough to have 'useful' information about the
application data unit (e.g., video streaming examples described
above). This higher level information is useful for scheduling
multicast transmissions of different application data units (for
example, to make a decision for when to stop transmitting one group
of pictures in an MPEG transmission and start transmitting the
next), and potentially for tracking and billing purposes.
9. Page 10, Session Start/Stop: This is higher level functionality that
can be supported by a reporting reception component for the 'data
fountain' approach.
10. Page 13, Section 4.4, Generic Router Support: Packet filtering
for reducing the rate of flow to constrained bandwidth and/or
congested links is another function that could be mentioned here.
11. Page 15, Section 7, References: The following five references may
be appropriate:
The following paper describes how the basic protocol labeled as (4)
with layering for congestion control would work:
John Byers, Michael Luby, Michael Mitzenmacher, Ashu Rege, ''A
Digital Fountain Approach to Reliable Distribution of Bulk Data'',
ICSI technical report TR-98-005, February 1998, SIGCOMM '98,
September 1998.
The following paper describes how streaming video might be layered
and protected into application data units for transmission over the
Internet:
W.Tan and A.Zakhor, 'Real-time Internet Video Using Error Resilient
Scalable Compression and TCP-friendly Transport Protocol', IEEE
Trans. Multimedia, June 1999.
The following paper describes a Reed-Solomon implementation of FEC
that is available in software for transmission over the Internet
(used to protect MPEG streams in vic):
Johannes Bloemer, Malik Kalfane, Marek Karpinski,
Richard Karp, Michael Luby, David Zuckerman, ''An XOR-Based Erasure-
Resilient Coding Scheme'', ICSI Technical Report No. TR-95-048,
August 1995.
The following paper describes a new class of FEC codes that are
scalable to protect much larger application data units in a software
based implementation:
Michael Luby, Michael Mitzenmacher, Amin Shokrollahi,
Daniel Spielman, Volker Stemann, ''Practical Loss-Resilient Codes'',
29th Annual ACM Symposium on Theory of Computing, 1997.
>From luby@dfountain.com Wed Jun 30 13:03:30 1999
Received: from postal1.lbl.gov (localhost [127.0.0.1])
by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id NAA17677
for <rmt@listserv.lbl.gov>; Wed, 30 Jun 1999 13:03:29 -0700 (PDT)
Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id NAA06156
for <rmt@listserv.lbl.gov>; Wed, 30 Jun 1999 13:03:28 -0700 (PDT)
Received: from monarch.dfountain.com ([207.90.190.130])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id NAA06149
for <rmt@lbl.gov>; Wed, 30 Jun 1999 13:03:27 -0700 (PDT)
Received: by PACIFIC with Internet Mail Service (5.5.2448.0)
id <MB17KWBV>; Wed, 30 Jun 1999 12:55:23 -0700
Message-ID: <619F2FB3840CD311AC2C0090273BF1AC017BC3@PACIFIC>
From: Mike Luby <luby@dfountain.com>
To: "'rmt@lbl.gov'" <rmt@lbl.gov>
Cc: Mike Luby <luby@dfountain.com>
Subject: Comments on Design Space draft
Date: Wed, 30 Jun 1999 12:55:14 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="iso-8859-1"
Michael Luby, Digital Fountain and ICSI
Comments on:
The Reliable Multicast Design Space for Bulk Data Transfer
<draft-ietf-rmt-design-space-00>
General Comments
The following comments are written in response <draft-ietf-rmt-design-
space-00> (hereafter referred to as the 'design space draft'). These
comments were written after the comments I wrote on <draft-ietf-rmt-
buildingblocks-00.txt> (hereafter referred to as the 'building blocks
draft'). The specific comments on the design space draft contained
herein are written in a style that assumes the proposals made to the
building blocks draft have been accepted for incorporation into the
building blocks draft. If a full or partial incorporation of the
proposals does not occur, then these specific comments are still valid
and can be considered independently of the proposals on their own
merits.
Specific Comments
1. Page 3, Section 2.1, Did everyone receive the data?, third
paragraph: suggest changing 'If the application does need to know
that everyone got the data, then a positive acknowledgement must be
received ...' to 'If the application does need to know that everyone
got the data, then a reception report confirming receipt must be
received ...'. This assumes that the concept of an application data
unit has already been introduced. In the current design space
draft, this is defined just after this in the fourth paragraph.
Suggest moving the mention of application data unit be moved up and
expanded on a bit to include some possible examples as proposed in
my comments to the building blocks draft (e.g., for file transfer,
application data unit = file, for streaming MPEG video, application
data unit = group of pictures).
2. Page 4, Section 2.3, Receiver Set Scaling: The title of this section
is misleading given its content. A more appropriate title would be
'The Affect of Ensuring Goodput on Receiver Scaling'. There are
other components that also significantly affect receiver
scalability, including congestion control, group membership, and
reporting reception. It is the case that ensuring goodput is one of
the thornier issues with respect to receiver scalability, and thus
this section does make sense to include.
3. Page 4, Section 2.3, Receiver Set Scaling: In the fourth paragraph
there is mention that it is difficult to incorporate effective
congestion control into such protocols because of the sparseness of
feedback. The problem here is the mixing of the implementation of
two components - ensuring goodput and congestion control. It may
not be difficult to incorporate effective congestion control into
such schemes, it just may be difficult to piggy-pack the congestion
control onto the ensuring goodput ACK packets in this case because
of the sparseness of ACK packets. There are two points here: (a)
Sometimes it is advantageous to combine the implementations of
components together, e.g., piggy-backing the congestion control
signaling using the ACK packets that also are used for ensuring
goodput. This is similar to how TCP combines congestion control and
reliability in one overall protocol without separating them out. It
is cleaner to separate them out, but may be more efficient in some
cases to combine them. Nevertheless, there should be no inherent
reason why they can't be implemented separately and still be
efficient, and thus the conclusion that congestion control would
suffer if the ensuring goodput protocol uses sparse feedback seems
to be an inappropriate conclusion. The congestion control could use
a separate signaling mechanism and still be effective. (b) It is
important to consider the combined effects of one or more
components. For example, it is important to consider the aggregate
feedback traffic to the server, and not try to optimize the feedback
required for one component (say ensuring goodput) at the expense of
another (say congestion control). This does not seem to be the
point of this fourth paragraph however. The point of designing the
various components of the overall protocol so that it is overall
efficient is an important one though, and could be made somewhere.
4. Page 6, Section 3.1, Internet vs Intranet: The last sentence seems a
fairly strong conclusion that may change at some point in the
future. A proposed rewording is 'In the public Internet, it is less
likely that the additional expense required to support ...'.
5. Page 7, Section 4, The RM Solution Space: The title and introduction
don't accurately lead into this section. This section concentrates
on the ensuring goodput component of the overall protocol. A new
proposed title would be 'The ensuring goodput solution space'.
There should be a lead in sentence or two that makes it clear that
this section is addressing the issue of lost packets and thus is
discussing various ways to implement the ensuring goodput component.
Note that the sub-component decomposition here is roughly what I
proposed for adding to the building blocks draft for the ensuring
goodput component. (See proposal iii in my comments to the building
blocks draft).
6. Page 10, Section 4.3, Redundancy: The title of this section is
confusing, because FEC is often thought of in the context of
redundancy. Furthermore, what is described here is not so much
redundancy as a 'stateless streaming application'. This is an
application where the data can be thought of as a stateless stream
and whatever is sent in the future supercedes very quickly what was
sent in the past, and thus FEC techniques are inappropriate.
Perhaps 'Stateless streaming applications' could be the title? In
the second paragraph, the sentence 'The major advantage of
redundancy is that ...' could be changed to 'The major advantage of
a stateless streaming application is that ...'. Further on in the
same paragraph, 'redundant streams' could be changed to 'stateless
streams'.
7. Page 12, Section 4.4, paragraph 6: The paragraph starts off with the
sentence 'To apply reactive FEC, the sender must group data packets
into rounds, and the receivers ...'. It is unclear what the
definition of a 'round' is. One assumption could be that it is
somewhere between the size of an application data unit and a packet.
Perhaps the most compelling assumption is that it is the set of
packet associated with an application data unit. Then, reports
coming back on how many packets were missing could be considered as
reception reports. The decision on when to terminate sending
packets associated with one application data unit and move on to the
next is based on all receivers having confirmed receipt of the
entire application data unit using what logically would be
considered reporting receptions (implemented perhaps using ACKs or
NACKs as proposed).
8. Page 12, Section 4.4: No mention is made of applications where
proactive FEC might be useful. Examples that might be mentioned are
streaming video applications. One person who is doing work in this
area is Avideh Zakhor at UC Berkeley (a reference to one of her
relevant papers is given at the end). Another person is Philip Chou
of Microsoft (I don't have any references to his work). They use
some combination of proactive and reactive FEC. There are surely
others.
9. Page 12, Section 4.5, Layered FEC: The assumption with layered FEC
is made that packets are repeatedly transmitted. The relevant
sentence is 'The n encoded packets are then striped across multiple
multicast groups, and repeated (sic) transmitted'. That really
depends on the application and is not a requirement of the scheme.
For example, using a reporting reception component combined with
perhaps a group membership component, the transmission of packets
about the current application data unit can be terminated when all
(or enough) receivers have successfully recovered the application
data unit, and then transmission of the next application data unit
can proceed.
10. Page 12, Section 4.5, Layered FEC: The last phrase in last
sentence of last paragraph seems debatable. Doesn't Rizzo and
Vicisano propose a layered multicast scheme where 'tracer' packets
are sent out from the sender in each layer to coordinate joins and
leaves of receivers from the groups, and isn't their protocol
feedback free?
11. Page 14, Router-based congestion control: The paragraph that
starts 'For reliable multicast protocols, it is important to
consider congestion control at the same time as reliability is being
considered ...' This entire paragraph jumps to some conclusions
that have been recently challenged. For example, Lorenzo Vicisano,
Tony Speakman and I made a presentation at the RMG in PISA for
router supported congestion control that completely separated the
issue of congestion control from that of reliability. (I give the
reference at the end.) Probably worth considering rewriting this
paragraph and citing what the conclusions are based on, and
integrating it with the subsequent paragraph that starts 'In the
case of receiver-based congestion control ...'.
12. Page 15, Section 6, Security Concerns: Another form of denial-of-
service attack that is worth mentioning is in the layered approach a
non-cooperating receiver may subscribe to all layers behind a
bottleneck link and thus realize a denial-of-service attack to
receivers behind the bottleneck. In fact, this kind of attack is
even more perverse, as it also could overload the network and could
lead to possible collapse of the network. On the other hand, a
similar network collapse could also be induced by a TCP/IP receiver
sending fake acknowledgements at a fast rate.
13. Page 15, Section 7, References: The following references may be
appropriate:
The following paper describes how FEC and router supported packet
filtering might be combined to provide congestion control for
reliable multicast in a heterogeneous network:
Michael Luby, Lorenzo Vicisano, Tony Speakman, 'Heterogeneous
multicast congestion control based on router packet filtering',
presentation at RMG in PISA, June 1999, work in progress.
The following paper describes how the basic protocol labeled as (4)
with layering for congestion control would work:
John Byers, Michael Luby, Michael Mitzenmacher, Ashu Rege, ``A
Digital Fountain Approach to Reliable Distribution of Bulk Data'',
ICSI technical report TR-98-005, February 1998, SIGCOMM '98,
September 1998.
The following paper describes how streaming video might be layered
and protected into application data units for transmission over the
Internet:
W.Tan and A.Zakhor, "Real-time Internet Video Using Error Resilient
Scalable Compression and TCP-friendly Transport Protocol", IEEE
Trans. Multimedia, June 1999.
The following paper describes a Reed-Solomon implementation of FEC
that is available in software for transmission over the Internet
(used to protect MPEG streams in vic):
Johannes Bloemer, Malik Kalfane, Marek Karpinski,
Richard Karp, Michael Luby, David Zuckerman, ``An XOR-Based Erasure-
Resilient Coding Scheme'', ICSI Technical Report No. TR-95-048,
August 1995.
The following paper describes a new class of FEC codes that are
scalable to protect much larger application data units in a software
based implementation:
Michael Luby, Michael Mitzenmacher, Amin Shokrollahi,
Daniel Spielman, Volker Stemann, ``Practical Loss-Resilient Codes'',
29th Annual ACM Symposium on Theory of Computing, 1997.
>From chiu@bridge.East.Sun.COM Thu Jul 1 10:12:57 1999
Received: from postal1.lbl.gov (localhost [127.0.0.1])
by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id KAA22430
for <rmt@listserv.lbl.gov>; Thu, 1 Jul 1999 10:12:57 -0700 (PDT)
Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id KAA25629
for <rmt@listserv.lbl.gov>; Thu, 1 Jul 1999 10:12:56 -0700 (PDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id KAA25622
for <rmt@lbl.gov>; Thu, 1 Jul 1999 10:12:55 -0700 (PDT)
Received: from eastmail2.East.Sun.COM ([129.148.1.241])
by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA22747
for <rmt@lbl.gov>; Thu, 1 Jul 1999 10:12:53 -0700 (PDT)
Received: from bridge.East.Sun.COM (bridge.East.Sun.COM [129.148.75.125])
by eastmail2.East.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA12580
for <rmt@lbl.gov>; Thu, 1 Jul 1999 13:12:52 -0400 (EDT)
Received: from bridge (bridge [129.148.75.125])
by bridge.East.Sun.COM (8.9.1b+Sun/8.9.1) with SMTP id NAA19783
for <rmt@lbl.gov>; Thu, 1 Jul 1999 13:12:52 -0400 (EDT)
Message-Id: <199907011712.NAA19783@bridge.East.Sun.COM>
Date: Thu, 1 Jul 1999 13:12:52 -0400 (EDT)
From: Dah Ming Chiu - Sun Microsystems <chiu@bridge.East.Sun.COM>
Reply-To: Dah Ming Chiu - Sun Microsystems <chiu@bridge.East.Sun.COM>
Subject: Comments on building-block and design-space drafts
To: rmt@lbl.gov
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: 3JDLZJ8YRYi8c3i9nFHDyg==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc
Some thoughts after reading the building block draft:
1) My basic concern is whether this is too ambitious. How much success
have we had in standardizing APIs? It is perhaps feasible for
very well-defined and narrowly focused functions, such as FEC, encryption
and decryption, authentication, rate-based packet scheduling, or
rate calculation. For more abstract, complex, close-to-application
functions, it is very hard to get different people to agree.
2) I would like to see a more compeling argument for the building-block
effort, than the stated advantages which are mostly to ease software
development and maintanance. For example, we might want to make it
possible for (different) multicast receivers to receive from different
kinds of senders; or standardized router functions for different
end systems to use.
3) It might help to group the currently listed building blocks into two
categories - those that affect the main business of getting data from
sender to receivers (reliability, congestion control and security
mechanisms); and those that are session support functions (group,
session, tree config, notification).
4) The coverage of the different topics are quite uneven, and lacks focus.
For example, in the security section, it talks about the need to
authenticate control messages to deal with DoS. There are zillions of
other DoS attacks in multicast, how are we going to deal with the rest
of them?
Comment on the design space draft:
This document is quite well written. I have one comment regarding the
specific exclusion of "intermittent data flows". The cited reason is
"we do not yet have effective congestion control for such applications".
Well, TCP congestion control assumes continuous data transfer as well,
does that mean we should not use TCP for http type of request/response
short intermittent sessions? It seems to me that intermittent data
flows can use some very simple-minded congestion control to make sure
they are friendly with other flows. From my experience, intermittent
data model is a very important class of application for reliable multicast.
We mustn't drop it because it does not fit a particular congestion
control algorithm one try to standardize (at the moment).
>From ken_birman@email.msn.com Thu Jul 1 12:01:51 1999
Received: from postal1.lbl.gov (localhost [127.0.0.1])
by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id MAA23516
for <rmt@listserv.lbl.gov>; Thu, 1 Jul 1999 12:01:50 -0700 (PDT)
Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id MAA00132
for <rmt@listserv.lbl.gov>; Thu, 1 Jul 1999 12:01:49 -0700 (PDT)
Received: from secure.smtp.email.msn.com (secure.smtp.email.msn.com [207.46.181.28])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id MAA00125
for <rmt@lbl.gov>; Thu, 1 Jul 1999 12:01:48 -0700 (PDT)
Received: from adsl39 - 128.84.216.39 by email.msn.com with Microsoft SMTPSVC;
Thu, 1 Jul 1999 12:00:05 -0700
Message-ID: <002601bec3f3$edd6d020$27d85480@cit.cornell.edu>
From: "Kenneth P. Birman" <ken_birman@email.msn.com>
To: <rmt@lbl.gov>
References: <199907011712.NAA19783@bridge.East.Sun.COM>
Subject: Comments on building-block and design-space drafts
Date: Thu, 1 Jul 1999 14:59:12 -0400
Organization: Cornell University
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
I've also felt that the drafts leave open some issues. I wrote a detailed
comment to the authors, but since several people have posted comments, let
me share my own reaction very briefly.
First, I should stress that although my points are critical, I am actually
very impressed in a positive sense with the quality of these RFC's and view
them as very good first steps in a process. I don't think they are
finished -- my comments will all point to ways to revise and extend the
RFC's -- but I am not at all suggesting that they need to be tossed out and
rewritten, or anything of that sort.
Indeed, I think the multicast community owes its thanks to the authors, for
teaming up and producing a very convincing first cut.
But having said this, I do have some criticisms, which I intend in a
positive way:
1) I found the treatment of multi-sender groups inconsistent. On the one
hand, we are told that these drafts limit attention to single-sender
multicast scenarios, but on the other, there is some specific material in
the building-blocks RFT which states (incorrectly, in my opinion and
experience) that with multiple senders, there are no scalable flow control
and congestion control protocols. In fact, there have been many such
protocols. Some of them simply route the multicasts through a sequencer, as
in the work done by Kaashoek at MIT (but fault-tolerantly). Now, these
protocols look like they support multiple senders, and the messages get
through reliably. Is there a good reason to presume that multisender
protocols can't work? Perhaps certain styles of multi-sender protocols
don't scale, but even so, why does this rule out other styles of solution?
2) The drafts fail to cite a considerable body of work on the reliable
multicast problem itself, and on the problem of compositional design of
multicast systems -- van Renesse's work on Horus, Hayden's work on Ensemble,
and Rick Schlictings work on the multicast extensions to the x-Kernel
architecture at Arizona. These projects are important because they
demonstrate that one can build modular multicast architectures, and because
they attack the various overheads associated with layering in different and
important ways. My book, "Building Secure and Reliable Network
Applications" (Manning and Prentice Hall, 1997) discusses some of the issues
in a chapter on modular design of multicast protocols.
Reliable multicast dates back at least to 1985 -- the V system supported a
multicast and Willy and David talk about reliability in their papers on it,
and Isis came out around 1987. Isis was used in air traffic control
systems, it runs stock exchanges (the Swiss and New York systems are both
based on Isis -- a broader survey is coming out later this summer in
Software, Practice and Experience in the August 1999 issue). Wouldn't an
IETF standard be stronger by trying to encompass this prior work, rather
than simply overlooking it?
3) The drafts fail to cite much of the recent work on local repair protocols
and probabilistic scalable and reliable protocols. Obviously, I have my own
protocol in mind here -- Bimodal Multicast, subject of a paper in the May
issue of ACM Trans. on Computer Systems. But there are many. Instead, the
draft seems biased in favor of the tree-based hierarchical architectures
(such as SRM, RMTP), arguing that tree-based nack/resend schemes are
preferable to other options for acknowledgement or negative
acknowledgement. Not mentioned are the recent results showing that in
systems lacking membership data, such protocols can give very high rates of
overhead, for example in the presense of low systemwide loss rates. Again,
since I happen to believe strongly that randomized gossip protocols scale
better and represent a very interesting alternative (and one which can be
analyzed effectively), this option should at least be mentioned.
4) Some issues are not mentioned, but should be. For example, suppose I
want to know that my multicast protocol will survive any single link
failure, or any single router failure. The broad implications of such a
requirement are not mentioned here. Similarly for other aspects of the
reliability spectrum -- levels of consistency guarantee, strong membership
semantics (virtual synchrony), steady throughput guarantees (isochrony),
security (often seen by the user as an aspect of a single "secure and
reliable multicast problem"), real-time properties. Not all of these can
co-exist, so they all should be seen as possible dimensions of an
architecture.
That is, reliability is in the eye of the beholder. The job of the
standards developer is to accomodate many kinds of possible users, not to
pick a single scheme and stamp it as the winner...
5) All of this, it seems to me, argues that the architecture needs to be
separate from the protocols that populate it. For example, Horus has an
architecture supporting compositional protocol layering -- protocols built
as stacks of microprotocols. The actual protocol you run could be virtually
synchronous, probabilistic, secure, SRM-style, RMTP-style -- this depends on
the choice of components in the stack you use. So one can imagine
standardizing the stacking framework, inter-layer optimization methodology,
etc, and yet not having any real opinion on the relative merits of SRM,
RMTP, pbcast (bimodal multicast), vscast, the causal-delta protocols of
Raynal, or whatever. Indeed, such an architecture would support many
solutions which could live side by side. The RFC's, as written, promote a
choice in favor of tree based nack-only schemes using local repair. Is this
a wise decision? Such protocols, after all, are not amenable to providing
at least some of the properties listed above! Why not opt for diversity and
illustrate this by showing that a single architecture can elegantly
accomodate many of the important protocol options?
6) I question the decision to focus on 1-many bulk data transfer. In
particular, the RFC's lack any content specific to the bulk data aspects and
seem inconsistent about whether or not this is really even a 1-many
situation. Why not just accept that reliable multicast will often be used
in situations with many senders, and often used in situations where
membership awareness is important? Often -- not always -- but also, not
rarely or never...
Lest this all seem overly negative, please be aware that I find these RFC's
quite impressive as a first try. I don't think they are finished yet, but
I'm not advocating tossing them out either. I simply believe that they
could be made stronger and more broad with a little additional effort, and
that the result would be a more fitting IETF standard and more valuable to a
broader community.
Ken
>From J.Crowcroft@cs.ucl.ac.uk Fri Jul 2 00:43:01 1999
Received: from postal1.lbl.gov (localhost [127.0.0.1])
by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id AAA25615
for <rmt@listserv.lbl.gov>; Fri, 2 Jul 1999 00:43:00 -0700 (PDT)
Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id AAA04191
for <rmt@listserv.lbl.gov>; Fri, 2 Jul 1999 00:42:59 -0700 (PDT)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
by SpamWall.lbl.gov (8.9.3/8.9.3) with SMTP id AAA04187
for <rmt@lbl.gov>; Fri, 2 Jul 1999 00:42:58 -0700 (PDT)
Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP
id <g.03625-0@bells.cs.ucl.ac.uk>; Fri, 2 Jul 1999 08:42:52 +0100
To: "Kenneth P. Birman" <ken_birman@email.msn.com>
cc: rmt <rmt@lbl.gov>
Subject: Re: Comments on building-block and design-space drafts
In-reply-to: Your message of "Thu, 01 Jul 1999 14:59:12 EDT." <002601bec3f3$edd6d020$27d85480@cit.cornell.edu>
Date: Fri, 02 Jul 1999 08:42:50 +0100
Message-ID: <864.930901370@cs.ucl.ac.uk>
From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
In message <002601bec3f3$edd6d020$27d85480@cit.cornell.edu>, "Kenneth P. Birman
" typed:
>>1) I found the treatment of multi-sender groups inconsistent.
I think that there is a parallel point here. The proponents of
the view that we have to solve the single source problem first have, I
believe, a strong case: but BEWARE that we don't push the IP level
folks into optimising for single source - many ISPs would gladly adopt
an Express like model which would work fine for streaming RTP and for
single soruce RMT for software and web mirror data distribution
but would close the door pretty heavily against the sort of things
that multiple source enables (games etc etc)
>>hand, we are told that these drafts limit attention to single-sender
>>multicast scenarios, but on the other, there is some specific material in
>>the building-blocks RFT which states (incorrectly, in my opinion and
>>experience) that with multiple senders, there are no scalable flow control
>>and congestion control protocols. In fact, there have been many such
>>protocols. Some of them simply route the multicasts through a sequencer, as
>>in the work done by Kaashoek at MIT (but fault-tolerantly). Now, these
>>protocols look like they support multiple senders, and the messages get
>>through reliably. Is there a good reason to presume that multisender
>>protocols can't work? Perhaps certain styles of multi-sender protocols
>>don't scale, but even so, why does this rule out other styles of solution?
yes - i think the idea tho is to leave enough hooks in the current
work to allow us to edge towards including the full range of multiple
source protocols later......
>>2) The drafts fail to cite a considerable body of work on the reliable
>>multicast problem itself, and on the problem of compositional design of
>>multicast systems -- van Renesse's work on Horus, Hayden's work on Ensemble,
>>and Rick Schlictings work on the multicast extensions to the x-Kernel
>>architecture at Arizona. These projects are important because they
>>demonstrate that one can build modular multicast architectures, and because
>>they attack the various overheads associated with layering in different and
>>important ways. My book, "Building Secure and Reliable Network
>>Applications" (Manning and Prentice Hall, 1997) discusses some of the issues
>>in a chapter on modular design of multicast protocols.
good reference - thanks!
>>Reliable multicast dates back at least to 1985 -- the V system supported a
>>multicast and Willy and David talk about reliability in their papers on it,
>>and Isis came out around 1987. Isis was used in air traffic control
>>systems, it runs stock exchanges (the Swiss and New York systems are both
>>based on Isis -- a broader survey is coming out later this summer in
>>Software, Practice and Experience in the August 1999 issue). Wouldn't an
>>IETF standard be stronger by trying to encompass this prior work, rather
>>than simply overlooking it?
i guess the issue here was discussed at some of the RMRG and handover
meetings to RMT - yes, but later on - its not being excluded at all
but the priority was to deal with what was perceived as open
_internet_ customer requirements - there are, as ou say, a lot of
intranets running very succesful horus, tibnet, etc etc
systems......we need a good understanding of the impact of these in
the open internet, and at the RMRG in pisa, we outlined some of the
relevant things that nheed to emerge fro mthe research community over
the next year or two to allow us to think about engineering
open-internet-friendly multiple source protocols...
>>3) The drafts fail to cite much of the recent work on local repair protocols
>>and probabilistic scalable and reliable protocols. Obviously, I have my own
>>protocol in mind here -- Bimodal Multicast, subject of a paper in the May
>>issue of ACM Trans. on Computer Systems. But there are many. Instead, the
>>draft seems biased in favor of the tree-based hierarchical architectures
>>(such as SRM, RMTP), arguing that tree-based nack/resend schemes are
>>preferable to other options for acknowledgement or negative
>>acknowledgement. Not mentioned are the recent results showing that in
>>systems lacking membership data, such protocols can give very high rates of
>>overhead, for example in the presense of low systemwide loss rates. Again,
>>since I happen to believe strongly that randomized gossip protocols scale
>>better and represent a very interesting alternative (and one which can be
>>analyzed effectively), this option should at least be mentioned.
i guess we are not trying to write an academic paper here so
completeness of references to related work is not a critical issue
(how many ieee, itu or iso standards cite ANY work!), but useful
input again...thanks
>>4) Some issues are not mentioned, but should be. For example, suppose I
>>want to know that my multicast protocol will survive any single link
>>failure, or any single router failure. The broad implications of such a
>>requirement are not mentioned here. Similarly for other aspects of the
>>reliability spectrum -- levels of consistency guarantee, strong membership
>>semantics (virtual synchrony), steady throughput guarantees (isochrony),
>>security (often seen by the user as an aspect of a single "secure and
>>reliable multicast problem"), real-time properties. Not all of these can
>>co-exist, so they all should be seen as possible dimensions of an
>>architecture.
>>
>>That is, reliability is in the eye of the beholder. The job of the
>>standards developer is to accomodate many kinds of possible users, not to
>>pick a single scheme and stamp it as the winner...
>>5) All of this, it seems to me, argues that the architecture needs to be
>>separate from the protocols that populate it. For example, Horus has an
>>architecture supporting compositional protocol layering -- protocols built
>>as stacks of microprotocols. The actual protocol you run could be virtually
>>synchronous, probabilistic, secure, SRM-style, RMTP-style -- this depends on
>>the choice of components in the stack you use. So one can imagine
>>standardizing the stacking framework, inter-layer optimization methodology,
>>etc, and yet not having any real opinion on the relative merits of SRM,
>>RMTP, pbcast (bimodal multicast), vscast, the causal-delta protocols of
>>Raynal, or whatever. Indeed, such an architecture would support many
>>solutions which could live side by side. The RFC's, as written, promote a
>>choice in favor of tree based nack-only schemes using local repair. Is this
>>a wise decision? Such protocols, after all, are not amenable to providing
>>at least some of the properties listed above! Why not opt for diversity and
>>illustrate this by showing that a single architecture can elegantly
>>accomodate many of the important protocol options?
hmmmmmmmm....
>>6) I question the decision to focus on 1-many bulk data transfer. In
>>particular, the RFC's lack any content specific to the bulk data aspects and
>>seem inconsistent about whether or not this is really even a 1-many
>>situation. Why not just accept that reliable multicast will often be used
>>in situations with many senders, and often used in situations where
>>membership awareness is important? Often -- not always -- but also, not
>>rarely or never...
well, i guess one solution is to ask the proponents of commercial
1-many solutions to write a bit more about user requirements...
>>Lest this all seem overly negative, please be aware that I find these RFC's
>>quite impressive as a first try. I don't think they are finished yet, but
>>I'm not advocating tossing them out either. I simply believe that they
>>could be made stronger and more broad with a little additional effort, and
>>that the result would be a more fitting IETF standard and more valuable to a
>>broader community.
ace..
cheers
jon
>From whetten@talarian.com Sun Jul 4 20:47:43 1999
Received: from postal1.lbl.gov (localhost [127.0.0.1])
by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id UAA02303
for <rmt@listserv.lbl.gov>; Sun, 4 Jul 1999 20:47:39 -0700 (PDT)
Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id UAA05052
for <rmt@listserv.lbl.gov>; Sun, 4 Jul 1999 20:47:37 -0700 (PDT)
Received: from phobos.talarian.com (mailhost.talarian.com [207.5.32.17])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id UAA05048
for <rmt@lbl.gov>; Sun, 4 Jul 1999 20:47:37 -0700 (PDT)
Received: from tahoe (ta038.talarian.com [204.147.187.38] (may be forged)) by phobos.talarian.com (8.9.0/8.9.0) with SMTP id UAA02383; Sun, 4 Jul 1999 20:46:43 -0700 (PDT)
Message-Id: <4.1.19990702161157.023a9a30@pop3.concentric.net>
Message-Id: <4.1.19990702161157.023a9a30@pop3.concentric.net>
X-Sender: bwhetten@mailhost.talarian.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1
Date: Sun, 04 Jul 1999 14:31:44 -0700
To: Mike Luby <luby@dfountain.com>, "'rmt@lbl.gov'" <rmt@lbl.gov>
From: Brian Whetten <whetten@talarian.com>
Subject: Re: Short version of comments on building blocks and design
space drafts
Cc: Mike Luby <luby@dfountain.com>
In-Reply-To: <619F2FB3840CD311AC2C0090273BF1AC017BC1@PACIFIC>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Mike,
Thank you for the detailed feedback! I am on vacation at the moment, so
haven't yet had the time to read through all your detailed comments. Let
me give you my quick thoughts, however. I've been having problems reading
email, so others may have already responded to your email...I appologize
for any redundancy, if so.
In general, there are many different ways to "slice up" RM, and we will
probably never get complete consensus on all the questions involved. To be
fair, the first draft doesn't stress your class of "digital fountain"
algorithms as much as it does the NACK/ACK/Router Assist approaches. While
I'm sure part of that is because I am a little less familiar with this
newer class of protocols (which I appologize for), the biggest reason is
that we saw much less commonality between DF and the other three classes.
So we tried to focus on the area where we knew we could probably get the
most reuse and sharing--and which we thought would be the most controversial.
Your notion of reporting reception is very similar to the "message
stability" feature in RMTP-II and other HACK protocols. The primary
differences that I can see are:
1) Reception reporting is explicitly tied to ADU's, while message
stability is tied to a stream of transport level packets. The advantage of
the former is that it can provide slightly better fault tolerant semantics,
since the confirmation can include the application's flushing a file to
disk, for example. The potential tradeoff is that it makes the programming
API potentially more complex. This whole question of the advantages of ALF
is a religous debate, however, that has been going on for years.
2) For a streaming protocol, message stability can also provide flow
control and dramatically reduce the required buffers at the sender.
3) For a DF type protocol, reporting reception can also tell the sender
when to "turn off the fountain".
>From the perspective of getting consistent language, we have been
struggling with terminology for how to differentiate between protocols that
do and do not provide message stability. The fact that you raised this
means we obviously didn't do a good enough job. :) However, I'm not sure
how to reconcile the above two differences in a single term, and would
welcome suggestions on this.
>From the perspective of how to actually break the building blocks up, there
are three places that I see that reception reporting/message stability can
be done.
1) As part of the ACK/HACK mechanism, like in RMTP-II. In this case, the
message stability is inextricably tied to the rest of the protocol, and is
extremely difficult to separate out.
2) As part of an application specific protocol, like in MFTP. If you are
not using HACKs, it is much more difficult to scale reception reporting
(you have to use ACKs for this, by definition), and so this makes much more
sense for a file transfer application where your ADU is large enough to
prevent ACK implosion.
3) As part of a more generic session management protocol, which could also
provide total group membership, session advertisement, session start/stop,
etc. Note that when coupled with message stability, a session management
protocol can also provide scaleable real-time reception reporting, by
polling the DRs for the total group membership, and matching this up
against the count on # of receivers that comes from message stability
(although this has slightly different reliability semantics, since it is
transport reliability, not application reliability).
HACK protocols can work for both non-real time and real-time applications,
but typically need to build a hierarchy for real-time apps or very large
scale non-real time apps (>1000's nodes). For a HACK based protocol like
RMTP-II, the data reliability and recovery is intimately coupled with the
message stability, which is what allows it to support real-time apps. So
this is a tough one to break out.
In the RM BOF, I proposed that we have a File Transfer building block,
which would provide session management for a file transfer session, and
might also have an application level acknowledgement scheme built in. For
the building blocks draft, I was encouraged to take that out (at least for
now), because it was felt that this was an application level protocol, and
outside the scope of a transport working group. Perhaps that question is
one that we should open up for discussion.
In the draft, we briefly talked about the session management requirements,
but didn't put in any building blocks for those features, as I don't think
we felt there was consensus on how to best do that yet. It clearly is
important, particularly for the DF class of protocols, and I think your
feedback can help with this. Personally, this is where I had envisioned
the features you are talking about residing.
To complicate matters, a HACK protocol such as RMTP-II can work with other
standardized reliability mechanisms. With RMTP-II, you can tune the HACK
traffic down to the point where it is being primarily used just for
"reporting reception"/message stability. In fact, we already recommend
this for users which can turn on NACKs. If you run RMTP-II in a one-level
hierarchy, with the HACKs tuned down to just the level at which you would
do application level acknowledgements, then this is actually pretty similar
to what I think you are suggesting, except it isn't an application level
acknowledgement, and you don't have total group membership information
(just a count). So, RMTP-II's intricately coupled message stability can
work with the NACK and FEC building blocks, to provide much of "reporting
reception". It could also work with a generic router assist building block
to take advantage of PGM-style NACKs.
So, in conclusion, I think that while we might not have made it clear in
the draft, we are already thinking along somewhat similar lines, but the
necessity of supporting real-time applications and of concentrating on the
area with primary overlap, has caused us (or me, at least) to structure
things somewhat differently. I'd like us to be able to come up with
consensus for a consistent language on reliability semantics (which by
itself has generated a tremendous amount of research, much by Ken Birman
and his group). Then, perhaps we need to debate whether reception
reporting belongs in a file-transfer specific component, or as part of a
session management block. I do think that ADU semantics make more sense at
the session management / file transfer level, but less from a data naming
perspective than from an application level acknowledgement perspective.
Brian
>From whetten@talarian.com Sun Jul 4 20:47:50 1999
Received: from postal1.lbl.gov (localhost [127.0.0.1])
by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id UAA02318
for <rmt@listserv.lbl.gov>; Sun, 4 Jul 1999 20:47:49 -0700 (PDT)
Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id UAA05071
for <rmt@listserv.lbl.gov>; Sun, 4 Jul 1999 20:47:48 -0700 (PDT)
Received: from phobos.talarian.com (mailhost.talarian.com [207.5.32.17])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id UAA05061
for <rmt@lbl.gov>; Sun, 4 Jul 1999 20:47:47 -0700 (PDT)
Received: from tahoe (ta038.talarian.com [204.147.187.38] (may be forged)) by phobos.talarian.com (8.9.0/8.9.0) with SMTP id UAA02390; Sun, 4 Jul 1999 20:47:10 -0700 (PDT)
Message-Id: <4.1.19990704144448.00d82580@mailhost.talarian.com>
Message-Id: <4.1.19990704144448.00d82580@mailhost.talarian.com>
X-Sender: bwhetten@mailhost.talarian.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1
Date: Sun, 04 Jul 1999 16:11:08 -0700
To: "Kenneth P. Birman" <ken_birman@email.msn.com>, <rmt@lbl.gov>
From: Brian Whetten <whetten@talarian.com>
Subject: Re: Comments on building-block and design-space drafts
In-Reply-To: <002601bec3f3$edd6d020$27d85480@cit.cornell.edu>
References: <199907011712.NAA19783@bridge.East.Sun.COM>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Ahh..nothing like a vacation to give you the chance to catch up on emails. ;)
Ken,
Thanks for the positive nature of your comments. RM seems to be like
philosophy....six opinions for every five researchers....but if we all
follow the positive nature of your comments, hopefully we can continue to
work towards community consensus.
>1) I found the treatment of multi-sender groups inconsistent. On the one
>hand, we are told that these drafts limit attention to single-sender
>multicast scenarios, but on the other, there is some specific material in
>the building-blocks RFT which states (incorrectly, in my opinion and
>experience) that with multiple senders, there are no scalable flow control
>and congestion control protocols. In fact, there have been many such
>protocols. Some of them simply route the multicasts through a sequencer, as
>in the work done by Kaashoek at MIT (but fault-tolerantly). Now, these
>protocols look like they support multiple senders, and the messages get
>through reliably. Is there a good reason to presume that multisender
>protocols can't work? Perhaps certain styles of multi-sender protocols
>don't scale, but even so, why does this rule out other styles of solution?
This may not have been presented clearly, but this comment was supposed to
provide a partial rationale for why we were not looking at multiple sender
cases. I agree that there may be some solutions for multi-sender flow
control, but other than a centralized sequencer, I don't know of any
solutions for congestion control that I would consider provably safe and
fair with TCP. A centralized sequencer is a useful component for some
applications, and could be built on top of a 1-many RM protocol. For now,
I think this was considered out of the scope of this draft (we're trying to
start small, and then expand, as we already have too much on our collective
plates).
>2) The drafts fail to cite a considerable body of work on the reliable
>multicast problem itself, and on the problem of compositional design of
>multicast systems -- van Renesse's work on Horus, Hayden's work on Ensemble,
>and Rick Schlictings work on the multicast extensions to the x-Kernel
>architecture at Arizona. These projects are important because they
>demonstrate that one can build modular multicast architectures, and because
>they attack the various overheads associated with layering in different and
>important ways. My book, "Building Secure and Reliable Network
>Applications" (Manning and Prentice Hall, 1997) discusses some of the issues
>in a chapter on modular design of multicast protocols.
>
>Reliable multicast dates back at least to 1985 -- the V system supported a
>multicast and Willy and David talk about reliability in their papers on it,
>and Isis came out around 1987. Isis was used in air traffic control
>systems, it runs stock exchanges (the Swiss and New York systems are both
>based on Isis -- a broader survey is coming out later this summer in
>Software, Practice and Experience in the August 1999 issue). Wouldn't an
>IETF standard be stronger by trying to encompass this prior work, rather
>than simply overlooking it?
It is no one's intention to overlook this very influential prior work.
First off, my appology to you and to all the other researchers whose work
we did not cite. We got this draft out under severe time pressures, and so
fell back on the crutch of citing a couple prior survey papers, rather than
citing all the work individually. Speaking at least for myself, I am happy
to add additional references....although we risk doubling the size of the
draft. :)
The work on functional decomposition (as opposed to specific protocols) we
should have cited specifically, as it is directly relevant to the draft.
Again, my appologies. One difference between that approach and the
building blocks we conceive of is that a building block is defined
primarily as a "unit of work" that we think the community can come to
consensus on, rather than as a engineering component.
>3) The drafts fail to cite much of the recent work on local repair protocols
>and probabilistic scalable and reliable protocols. Obviously, I have my own
>protocol in mind here -- Bimodal Multicast, subject of a paper in the May
>issue of ACM Trans. on Computer Systems. But there are many. Instead, the
>draft seems biased in favor of the tree-based hierarchical architectures
>(such as SRM, RMTP), arguing that tree-based nack/resend schemes are
>preferable to other options for acknowledgement or negative
>acknowledgement. Not mentioned are the recent results showing that in
>systems lacking membership data, such protocols can give very high rates of
>overhead, for example in the presense of low systemwide loss rates. Again,
>since I happen to believe strongly that randomized gossip protocols scale
>better and represent a very interesting alternative (and one which can be
>analyzed effectively), this option should at least be mentioned.
Please see the response to #5, below.
>4) Some issues are not mentioned, but should be. For example, suppose I
>want to know that my multicast protocol will survive any single link
>failure, or any single router failure. The broad implications of such a
>requirement are not mentioned here. Similarly for other aspects of the
>reliability spectrum -- levels of consistency guarantee, strong membership
>semantics (virtual synchrony), steady throughput guarantees (isochrony),
>security (often seen by the user as an aspect of a single "secure and
>reliable multicast problem"), real-time properties. Not all of these can
>co-exist, so they all should be seen as possible dimensions of an
>architecture.
>
>That is, reliability is in the eye of the beholder. The job of the
>standards developer is to accomodate many kinds of possible users, not to
>pick a single scheme and stamp it as the winner...
Yes, reliability can become very subtle (and contentious) when you start
talking about fault tolerance guarantees, which is one of the primary
reasons why I think consensus has been reached that we should be targeting
1->many applications first, where ordering/virtual synchrony/etc. are less
important. Again, we're not saying that many-many distributed systems
protocols aren't important (remember, RMP is the only real protocol I can
truly claim initial authorship of), just that they are a more difficult
problem to achieve consensus on, and also of less immediate applicability
in the Big-I Internet. There is clearly a spot for many-many
standards...but a lot more consensus building needs to be done first, and
no clear leaders of this yet in the RMRG community. As one of the top
world experts in this area, would you like to help on this?
>5) All of this, it seems to me, argues that the architecture needs to be
>separate from the protocols that populate it. For example, Horus has an
>architecture supporting compositional protocol layering -- protocols built
>as stacks of microprotocols. The actual protocol you run could be virtually
>synchronous, probabilistic, secure, SRM-style, RMTP-style -- this depends on
>the choice of components in the stack you use. So one can imagine
>standardizing the stacking framework, inter-layer optimization methodology,
>etc, and yet not having any real opinion on the relative merits of SRM,
>RMTP, pbcast (bimodal multicast), vscast, the causal-delta protocols of
>Raynal, or whatever. Indeed, such an architecture would support many
>solutions which could live side by side. The RFC's, as written, promote a
>choice in favor of tree based nack-only schemes using local repair. Is this
>a wise decision? Such protocols, after all, are not amenable to providing
>at least some of the properties listed above! Why not opt for diversity and
>illustrate this by showing that a single architecture can elegantly
>accomodate many of the important protocol options?
First, there is a difference between engineering/implementation issues, and
standardization building blocks. As I mentioned above, a building block is
sort of a "political unit of work". A vendor that wishes to offer many
different protocols would be well advised to read through the very good
work that Horus and others have done on how to do micro-protocol
composition...but I think that micro protocols are too small of components
to achieve consensus on in a reasonable time frame. The question of how
many protocols to standardize is somewhat orthoganol, and obviously very
politically charged. A RM/distributed systems toolkit vendor could offer
many protocols, and high end developers (like many of the people who are
active in the IETF) could actually make intelligent decisions to best pick
the components they want. However, the vast majority of programmers--and
the OS vendors that offer protocols to them--do not want to support 20
protocols. I personally think that in the 1-many space, 4 will be more
than enough...and would actually like to see the router-assist broken in to
a separate component, rather than as a protocol core, so that we could
reduce this down to 3.
Now, as to _which_ protocols to standardize, this is even more contentious,
and is part of why I think the IETF initially chose to charter the RMRG
rather than a WG. This has provided a forum for researchers to reach a
partial consensus on many contentious topics, as we cross-educated each
other. Taking RMTP-II as an example (and the only one I can speak for),
while its name gives credit to Sanjoy's pioneering work, it is really a
product of the last two+ years of RMRG meetings and all the great research
that has been done on scaleable hierarchical protocols over the past 5 years.
I think Vern Paxson originally (and wisely) proposed this 4-fold taxonomy,
based on the type of network infrastructure support. I think bimodal
multicast was not mentioned because it hasn't yet been published. We
should mention it under the class of no-router support protocols. When I
read it, my initial impression was that as proposed, it was more of a
many-many distributed systems protocol, rather than a 1-many WAN protocol.
However, I personally think that the class of protocols that has no network
infrastructure support is much more difficult to solve than those that take
advantage of router or server assist....and so any new contributions to
that area, such as bimodal multicast, should be considered. Speaking for
myself, I would rather not see more than 1 protocol core come out of any of
the areas, and hope that a consensus can be reached among the researchers
in each area.
>6) I question the decision to focus on 1-many bulk data transfer. In
>particular, the RFC's lack any content specific to the bulk data aspects and
>seem inconsistent about whether or not this is really even a 1-many
>situation. Why not just accept that reliable multicast will often be used
>in situations with many senders, and often used in situations where
>membership awareness is important? Often -- not always -- but also, not
>rarely or never...
Again, let me reiterate that 1-many is the _initial_ focus, because it is a
well-bounded problem, which we have spent three years building consensus
on, for which we know of specific applications that need it in the Big-I
internet. Many-many apps and protocols make up a very real commercial
segment, but the requirements are sufficiently different that we feel that
they should be tackled separately. Hopefully, some of the building blocks
we are starting with can be used in many-many protocols (one of the
specific reasons why we chose to go with building blocks at all, over
strong objections from the whole-protocol camp).
Finally, group membership is definitely important...but more difficult to
do in a scaleable fashion...which is why a hierarchical solution is the
only one I think we have consensus on so far.
Brian
>From whetten@talarian.com Sun Jul 4 20:47:56 1999
Received: from postal1.lbl.gov (localhost [127.0.0.1])
by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id UAA02343
for <rmt@listserv.lbl.gov>; Sun, 4 Jul 1999 20:47:56 -0700 (PDT)
Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id UAA05105
for <rmt@listserv.lbl.gov>; Sun, 4 Jul 1999 20:47:55 -0700 (PDT)
Received: from phobos.talarian.com (mailhost.talarian.com [207.5.32.17])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id UAA05101
for <rmt@lbl.gov>; Sun, 4 Jul 1999 20:47:54 -0700 (PDT)
Received: from tahoe (ta038.talarian.com [204.147.187.38] (may be forged)) by phobos.talarian.com (8.9.0/8.9.0) with SMTP id UAA02386; Sun, 4 Jul 1999 20:47:02 -0700 (PDT)
Message-Id: <4.1.19990704143210.00dea680@mailhost.talarian.com>
Message-Id: <4.1.19990704143210.00dea680@mailhost.talarian.com>
X-Sender: bwhetten@mailhost.talarian.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1
Date: Sun, 04 Jul 1999 14:42:17 -0700
To: Dah Ming Chiu - Sun Microsystems <chiu@bridge.East.Sun.COM>, rmt@lbl.gov
From: Brian Whetten <whetten@talarian.com>
Subject: Re: Comments on building-block and design-space drafts
In-Reply-To: <199907011712.NAA19783@bridge.East.Sun.COM>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
>1) My basic concern is whether this is too ambitious. How much success
> have we had in standardizing APIs? It is perhaps feasible for
> very well-defined and narrowly focused functions, such as FEC, encryption
> and decryption, authentication, rate-based packet scheduling, or
> rate calculation. For more abstract, complex, close-to-application
> functions, it is very hard to get different people to agree.
A good concern. :) I don't think the building blocks we singled out are
overly ambitious, as they are all pretty cleanly defined, and I think we
can get consensus on most of them. The API's are not the primary thing
being standardized...the algorithms would be. However, building blocks
definitely carry risks with them, which we should constantly be cognizant
of. However, note that we didn't yet come to a consenus on session
management building blocks...which could prove contentious, although I hope
not.
>2) I would like to see a more compeling argument for the building-block
> effort, than the stated advantages which are mostly to ease software
> development and maintanance. For example, we might want to make it
> possible for (different) multicast receivers to receive from different
> kinds of senders; or standardized router functions for different
> end systems to use.
The first doesn't seem to have much value to me. The second one is there
as a building block (generic router assist), although perhaps not as an
argument....good comment.
>3) It might help to group the currently listed building blocks into two
> categories - those that affect the main business of getting data from
> sender to receivers (reliability, congestion control and security
> mechanisms); and those that are session support functions (group,
> session, tree config, notification).
Maybe.
>4) The coverage of the different topics are quite uneven, and lacks focus.
> For example, in the security section, it talks about the need to
> authenticate control messages to deal with DoS. There are zillions of
> other DoS attacks in multicast, how are we going to deal with the rest
> of them?
Are there other areas you felt were uneven? Security is something that I
feel will mostly be handled by SMUG, not by RMT (though others may
disagree). We are trying to show where it fits in the overall picture, but
not specify it...which means it will be necessity be treated more lightly.
>From Ken_Birman@email.msn.com Tue Jul 6 01:20:03 1999
Received: from postal1.lbl.gov (localhost [127.0.0.1])
by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id BAA05914
for <rmt@listserv.lbl.gov>; Tue, 6 Jul 1999 01:20:02 -0700 (PDT)
Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id BAA00501
for <rmt@listserv.lbl.gov>; Tue, 6 Jul 1999 01:20:01 -0700 (PDT)
Received: from secure.smtp.email.msn.com (secure.smtp.email.msn.com [207.46.181.28])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id BAA00484
for <rmt@lbl.gov>; Tue, 6 Jul 1999 01:20:00 -0700 (PDT)
Received: from adsl40 - 208.251.65.23 by email.msn.com with Microsoft SMTPSVC;
Tue, 6 Jul 1999 01:19:25 -0700
Message-ID: <001501bec788$41c10100$1741fbd0@cit.cornell.edu>
From: "Kenneth P. Birman" <Ken_Birman@email.msn.com>
To: <rmt@lbl.gov>, "Brian Whetten" <whetten@talarian.com>
References: <199907011712.NAA19783@bridge.East.Sun.COM> <4.1.19990704144448.00d82580@mailhost.talarian.com>
Subject: Re: Comments on building-block and design-space drafts
Date: Tue, 6 Jul 1999 04:19:09 -0400
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2014.211
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211
Hi Brian,
To avoid one of those exponential dialogs, I won't reply on a point by point
basis.
I think that IETF has good reasons for focusing on one thing at a time, and
if the focus is to be 1-many initially, this is fine. But again, one then
needs to use care to make sure the RFT actually reflects that decision. The
building blocks one seems to discuss many-many issues around the third page.
I suspect that this is a sign of the difficult reality of the thing -- the
issues don't split so easily, particularly if processes other than the
sender help with recovery.
Bimodal multicast: the protocol works the same way whether 1-many or
many-to-many. I don't think this makes it a many-to-many protocol,
though....
WIll I help on the extention to a more general solution? Sure. Actually,
the people to really focus on here are Robbert van Renesse and Farnam
Jahanian, who have a proposal for a standard in this area too, albeit less
elaborate and less formalized than yours. (They focus on what might be
called engineering building-block interfaces)
Finally: on the distinction between political and engineering building
blocks: I doubt that you would find an actual political consensus behind any
specific building block simply because none of the protocols you have in
mind has the market power to force a consensus. If I were Novell or Cisco I
wouldn't want to accidently anoint the wrong protocol as the designated
winner. So, it would be wise, politically, for IETF to adopt an engineering
building block approach instead. This is not likely to be political in the
unwinnable sense and hence has a good chance of success. The other kind of
politics can lead to standards -- the world has lots of them -- but not
actually to widespread adoption of the standard, it seems to me...
Ken
>From whetten@talarian.com Tue Jul 6 11:46:56 1999
Received: from postal1.lbl.gov (localhost [127.0.0.1])
by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id LAA09845
for <rmt@listserv.lbl.gov>; Tue, 6 Jul 1999 11:46:56 -0700 (PDT)
Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id LAA20270
for <rmt@listserv.lbl.gov>; Tue, 6 Jul 1999 11:46:55 -0700 (PDT)
Received: from phobos.talarian.com (mailhost.talarian.com [207.5.32.17])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id LAA20260
for <rmt@lbl.gov>; Tue, 6 Jul 1999 11:46:54 -0700 (PDT)
Received: from tahoe ([10.3.9.17]) by phobos.talarian.com (8.9.0/8.9.0) with SMTP id LAA03530; Tue, 6 Jul 1999 11:46:21 -0700 (PDT)
Message-Id: <4.1.19990706105632.01cd2ba0@mailhost.talarian.com>
X-Sender: bwhetten@mailhost.talarian.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1
Date: Tue, 06 Jul 1999 11:45:48 -0700
To: "Kenneth P. Birman" <Ken_Birman@email.msn.com>, <rmt@lbl.gov>
From: Brian Whetten <whetten@talarian.com>
Subject: Re: Comments on building-block and design-space drafts
In-Reply-To: <001501bec788$41c10100$1741fbd0@cit.cornell.edu>
References: <199907011712.NAA19783@bridge.East.Sun.COM>
<4.1.19990704144448.00d82580@mailhost.talarian.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
>I think that IETF has good reasons for focusing on one thing at a time, and
>if the focus is to be 1-many initially, this is fine. But again, one then
>needs to use care to make sure the RFT actually reflects that decision.
The charter for RMT states that: "Initial efforts will focus solely on the
standardization of the
one-to-many transport of large amounts of data." So we felt it came
implicitly out of the charter. The idea that we will then expand in to
many-many has also been reiterated at the BOF and each RMRG meeting. But
it never hurts to clarify...good point.
>Bimodal multicast: the protocol works the same way whether 1-many or
>many-to-many. I don't think this makes it a many-to-many protocol,
>though....
My reasons for thinking that bimodal multicast was primarily a many-many
LAN protocol were:
1) Unless I remember wrong, you stated in the paper that it was presently
only designed to work in a LAN/enterprise environment, although you had
promising avenues of exploration you were working on for WAN scalability.
2) One of the most exciting features of bimodal multicast, which you so
well analyze, is its ability to give very strong statistical guarantees on
atomicity of delivery, which makes it a potentially powerful building block
for high-end distributed systems applications like air traffic control. I
see that class of applications as fundamentally being many-many. Even if
there are apps in that space that don't need many-many, the fault
tolerance/atomicity/ordering guarantees needed by most of the apps in that
space, combined with the typically milder scalability requirements, seem to
me to justify treating that class as fundamentally different than the
1-many, non-ordered/atomic apps that the WG is initially focused on.
Potentially bi-modal could be used for both, but it seems that the work to
date has focused on distributed apps.
>Finally: on the distinction between political and engineering building
>blocks: I doubt that you would find an actual political consensus behind any
>specific building block simply because none of the protocols you have in
>mind has the market power to force a consensus. If I were Novell or Cisco I
>wouldn't want to accidently anoint the wrong protocol as the designated
>winner. So, it would be wise, politically, for IETF to adopt an engineering
>building block approach instead. This is not likely to be political in the
>unwinnable sense and hence has a good chance of success. The other kind of
>politics can lead to standards -- the world has lots of them -- but not
>actually to widespread adoption of the standard, it seems to me...
Well, on this point I strongly disagree, based on long discussions over the
past four years with both large OS vendors, router vendors, middleware
vendors, and application vendors. At GlobalCast, we started out trying to
sell RM in to both the many-many and 1-many markets. We quickly heard that
the many-many market was not compelling for now, because of the lower needs
for scalability. There was a lot of confusion at first about which 1-many
protocols were needed, and we offered both SRM, RMTP, PGM, RMP, and RMTP-II
to the market. What we heard from the market, after multiple years of
being protocol agnostic, was that almost all of the immediate application
needs could be met by RMTP-II. The interest breakdown was 70% RMTP-II, 20%
RMP, 10% PGM. Again....RMTP-II is not my protocol. The reason I'm been
trying to lead efforts (for 2+ years) to build a consensus around a
HACK/server based protocol is that it is precisely what I've heard the
market needs. Certainly not 100% of the market, and RMTP-II needs lots of
work still before it is ready for worldwide deployment...but certainly at
least 60% of the market.
Again, I think that there is a real market need for a many-many protocol
(as illustrated by the 20% interest in RMP), and hope that you, Robert, and
others can help start building a consensus in that area, not necessarily
for a framework of 100 different protocols, but towards the 1-2 concrete
and fully tested protocols that an OS vendor or middleware vendor would
want to support. A framework with lots of protocols makes lost of sense if
you are selling to very high end customers, and can offer lots of
consulting and support...the business model that ISIS successfully
followed. For other vendors, the support of such a thing is too burdensome.
Brian
>From kenm@starburstcom.com Tue Jul 6 13:16:12 1999
Received: from postal1.lbl.gov (localhost [127.0.0.1])
by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id NAA11184
for <rmt@listserv.lbl.gov>; Tue, 6 Jul 1999 13:16:11 -0700 (PDT)
Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id NAA16673
for <rmt@listserv.lbl.gov>; Tue, 6 Jul 1999 13:16:05 -0700 (PDT)
Received: from gummo.starburstcom.com (gummo.starburstsoftware.com [206.33.96.31])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id NAA16656
for <rmt@lbl.gov>; Tue, 6 Jul 1999 13:16:03 -0700 (PDT)
Received: from accord.starburstsoftware.com (accord.starburstcom.com [206.33.96.71])
by gummo.starburstcom.com (8.9.1/8.9.1) with SMTP id QAA08078;
Tue, 6 Jul 1999 16:07:49 -0400 (EDT)
Received: by accord.starburstsoftware.com with Microsoft Mail
id <01BEC7CA.DA53D180@accord.starburstsoftware.com>; Tue, 6 Jul 1999 16:16:07 -0400
Message-ID: <01BEC7CA.DA53D180@accord.starburstsoftware.com>
From: Ken Miller <kenm@starburstsoftware.com>
To: "'luby@dfountain.com'" <luby@dfountain.com>,
"'rmt@lbl.gov'"
<rmt@lbl.gov>
Subject: RE: Comments on Design Space draft
Date: Tue, 6 Jul 1999 16:16:05 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by listserv.lbl.gov id NAA11184
>>Reply to your message of 6/30/99 8:31 PM
>>Michael Luby, Digital Fountain and ICSI
>>
>>
>>
>>
>>Comments on:
>>The Reliable Multicast Design Space for Bulk Data Transfer
>> <draft-ietf-rmt-design-space-00>
>>
>>7. Page 12, Section 4.4, paragraph 6: The paragraph starts off with the
>>sentence 'To apply reactive FEC, the sender must group data packets
>>into rounds, and the receivers ...'. It is unclear what the
>>definition of a 'round' is. One assumption could be that it is
>>somewhere between the size of an application data unit and a packet.
>>Perhaps the most compelling assumption is that it is the set of
>>packet associated with an application data unit. Then, reports
>>coming back on how many packets were missing could be considered as
>>reception reports. The decision on when to terminate sending
>>packets associated with one application data unit and move on to the
>>next is based on all receivers having confirmed receipt of the
>>entire application data unit using what logically would be
>>considered reporting receptions (implemented perhaps using ACKs or
>>NACKs as proposed).
I believe a "round" is actually a parity group in which any packet or set of packets may be derived from the same number of parity packets from that group (or sometimes slightly more if the code is not perfect).
>>
>>8. Page 12, Section 4.4: No mention is made of applications where
>>proactive FEC might be useful. Examples that might be mentioned are
>>streaming video applications. One person who is doing work in this
>>area is Avideh Zakhor at UC Berkeley (a reference to one of her
>>relevant papers is given at the end). Another person is Philip Chou
>>of Microsoft (I don't have any references to his work). They use
>>some combination of proactive and reactive FEC. There are surely
>>others.
We have implemented both pro-active and reactive FEC in our MFTP based products since late last year. Our pro-active FEC is used in either one-way satellite environments with no back channel or in highly lossy radio environments with a back channel often encountered in tactical military radio environments.
>>
Ken Miller
-----------------------------------------------------------------------------------------------------
Ken Miller
Chairman & CTO
StarBurst Software Phone: (978) 287-5560 x223
150 Baker Avenue FAX: (978) 287-5561
Concord, MA 01742 Web: http://www.starburstsoftware.com
------------------------------------------------------------------------------------------------------
>From Ken_Birman@email.msn.com Sat Jul 10 00:44:39 1999
Received: from postal1.lbl.gov (localhost [127.0.0.1])
by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id AAA04553
for <rmt@listserv.lbl.gov>; Sat, 10 Jul 1999 00:44:39 -0700 (PDT)
Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id AAA14756
for <rmt@listserv.lbl.gov>; Sat, 10 Jul 1999 00:44:37 -0700 (PDT)
Received: from secure.smtp.email.msn.com (secure.smtp.email.msn.com [207.46.181.28])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id AAA14752
for <rmt@lbl.gov>; Sat, 10 Jul 1999 00:44:36 -0700 (PDT)
Received: from adsl40 - 208.251.65.5 by email.msn.com with Microsoft SMTPSVC;
Sat, 10 Jul 1999 00:44:04 -0700
Message-ID: <000201becaa7$fab270a0$0541fbd0@cit.cornell.edu>
From: "Kenneth P. Birman" <Ken_Birman@email.msn.com>
To: <rmt@lbl.gov>, "Brian Whetten" <whetten@talarian.com>
References: <199907011712.NAA19783@bridge.East.Sun.COM><4.1.19990704144448.00d82580@mailhost.talarian.com> <4.1.19990706105632.01cd2ba0@mailhost.talarian.com>
Subject: Re: Comments on building-block and design-space drafts
Date: Fri, 9 Jul 1999 13:19:13 -0400
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2014.211
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211
Hi Brian,
Your point seems to come down to a marketing position for your
company, GlobalCast: in your experience, GlobalCast only makes
money off of RMTP-II, so this should be the standard.
Fine... but in this case, why not just do an RMTP-II RFC, call
it that ("the RMTP design space" and "RMTP building blocks")
and promote truth in advertising? Based on GlobalCast's
marketing experiences and partners, this would presumably
draw at least the same degree of commercial interest as the
current reliable multicast labels do. And you wouldn't find your
group in the awkward position of seeming to create a reliable
multicast standard, but actually doing so primarily for the hack
based protocols of greatest interest to you as products, and
for which you presumably hold some pretty strong patents.
As it stands, you are putting forward a reliable multicast RFC
and yet replying to comments about it by saying, more or less,
RMTP-II doesn't do that, or doesn't need that, or that GlobalCast
isn't interested in that market... In effect, rewriting the group's
charter to narrow it around your product line.
Ken
>From whetten@talarian.com Mon Jul 12 02:55:16 1999
Received: from postal1.lbl.gov (localhost [127.0.0.1])
by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id CAA08153
for <rmt@listserv.lbl.gov>; Mon, 12 Jul 1999 02:55:16 -0700 (PDT)
Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id CAA16601
for <rmt@listserv.lbl.gov>; Mon, 12 Jul 1999 02:55:15 -0700 (PDT)
Received: from phobos.talarian.com (mailhost.talarian.com [207.5.32.17])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id CAA16597
for <rmt@lbl.gov>; Mon, 12 Jul 1999 02:55:14 -0700 (PDT)
Received: from tahoe (dhcp29182.ietf.uninett.no [128.39.29.182]) by phobos.talarian.com (8.9.0/8.9.0) with SMTP id CAA09001; Mon, 12 Jul 1999 02:54:41 -0700 (PDT)
Message-Id: <4.1.19990712024649.00a15f00@mailhost.talarian.com>
X-Sender: bwhetten@mailhost.talarian.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1
Date: Mon, 12 Jul 1999 02:48:50 -0700
To: "Kenneth P. Birman" <Ken_Birman@email.msn.com>, <rmt@lbl.gov>
From: Brian Whetten <whetten@talarian.com>
Subject: Re: Comments on building-block and design-space drafts
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Ken,
Perhaps I didn't do a good enough job of explaining my points. First, let
me see if I correctly understood the points you were making, and that I was
attempting to respond to. I understood you to be stating that:
1) You didn't think any of the major classes of protocols under discussion
(HACK based, NACK without server or router support, open-loop FEC only,
router supported) met a sufficient market demand to be turned into real
standards that would be deployed by major vendors.
2) Therefore we should instead by standardizing a framework (perhaps
similar to Horus) which would allow many protocols to be standardized and
deployed simultaneously.
My response was meant to convey two major points:
1) Yes, there are protocols that meet enough of the current market demand
to have the potential for widespread adoption. We know for sure that such
protocols need to evolve as we get additional real world experience with
them, which is part of why building blocks are so important, but we can
definitely get the process going now.
2) The major vendors you talk about are not, from my experience, very
interested in deploying more complex toolkits, which offer lots of
protocols, because they require dramatically more support and QA.
In order to lend weight to these opinions, I called on my experience as
part of one of the few companies which has offered multiple RM protocols to
the market.
Neither I, nor any of the other document editors, feel that a single
protocol (such as RMTP-II) can meet all the standards needs for RM, even in
the scope of the initial focus of 1-many distribution--and have no plans of
only standarizing a single protocol. We also know that we do not
understand every market requirement or every technical detail. Both of
these motivations are driving the goal of using building blocks in the
standards process. However, many concerns have been raised (by major
vendors) about the risks of "protocol explosion". As you so rightly point
out, it is very important for this body to take in to account market
requirements, if we hope to have these vendors pick up the standards and
promulgate them in to widespread use.
Again, I'd love to see you and/or one of your colleagues, as some of the
top experts in many-many multicast, pick up the ball in the RMRG for
many-many multicast, which we are now starting to work on there. The RMRG
could really use your help in the consensus building exercise that needs to
be done--similar to the processes we have been working on in one-many
multicast for the past years, and are continuing to work on as we finally
push these efforts in to the IETF.
Brian
At 01:19 PM 7/9/99 -0400, Kenneth P. Birman wrote:
>Hi Brian,
>
>Your point seems to come down to a marketing position for your
>company, GlobalCast: in your experience, GlobalCast only makes
>money off of RMTP-II, so this should be the standard.
>
>Fine... but in this case, why not just do an RMTP-II RFC, call
>it that ("the RMTP design space" and "RMTP building blocks")
>and promote truth in advertising? Based on GlobalCast's
>marketing experiences and partners, this would presumably
>draw at least the same degree of commercial interest as the
>current reliable multicast labels do. And you wouldn't find your
>group in the awkward position of seeming to create a reliable
>multicast standard, but actually doing so primarily for the hack
>based protocols of greatest interest to you as products, and
>for which you presumably hold some pretty strong patents.
>
>As it stands, you are putting forward a reliable multicast RFC
>and yet replying to comments about it by saying, more or less,
>RMTP-II doesn't do that, or doesn't need that, or that GlobalCast
>isn't interested in that market... In effect, rewriting the group's
>charter to narrow it around your product line.
>
>Ken
>
>
>
>
>From tmont@csee.wvu.edu Mon Jul 12 10:52:31 1999
Received: from postal1.lbl.gov (localhost [127.0.0.1])
by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id KAA10446
for <rmt@listserv.lbl.gov>; Mon, 12 Jul 1999 10:52:31 -0700 (PDT)
Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id KAA07364
for <rmt@listserv.lbl.gov>; Mon, 12 Jul 1999 10:52:30 -0700 (PDT)
Received: from Venus.ivv.nasa.gov (venus.ivv.nasa.gov [129.164.30.24])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id KAA07336
for <rmt@lbl.gov>; Mon, 12 Jul 1999 10:52:24 -0700 (PDT)
Received: from [129.164.10.55] by Venus.ivv.nasa.gov; Mon, 12 Jul 1999 13:54:07 -0400
Message-Id: <4.1.19990712131414.00ad3d10@naur.csee.wvu.edu>
X-Sender: (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1
Date: Mon, 12 Jul 1999 13:49:43 -0400
To: Brian Whetten <whetten@talarian.com>,
"Kenneth P. Birman" <Ken_Birman@email.msn.com>, <rmt@lbl.gov>
From: "Todd L. Montgomery" <tmont@csee.wvu.edu>
Subject: Re: Comments on building-block and design-space drafts
In-Reply-To: <4.1.19990712024649.00a15f00@mailhost.talarian.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
I wanted to make a few observations and comments on the drafts
being developed and on comments seen on the mailing list.
First off, I think the drafts are good first steps. Most of
the shortcomings have been mentioned and I am glad to see
things are progressing. However, the building block draft is
really vague..... I mean, really vague..... it really
does not describe a framework, it just lists what should be
in the framework with no technical details. It is necessary to
develop the building block draft as it stands, but it is definitely
not a document that I feel can go very far without a LOT more
detail. I think that the building block draft should be
retitled to "Building Block Design Space" and be its own
document. We need some initial design here. I think with the work done with
Horus, APPLCORE, and even the whole design pattern field,
we should be able to draw on a large body of work to aid us
in this. As a start, I would suggest basing things on
capabilities (like is used in IMAP, etc.). (If I was
not wearing 20 hats, I would take a stab at this....)
Secondly, I want to respond to Brian's comment on the
demand for different protocols (RMTP-II 70%, RMP 20%, PGM 10%).
I have to disagree.... first off, I am no longer with GlobalCast
so I am not qualified to talk about their specific market. However,
even when I was involved with GlobalCast, I wouldn't have agreed
with Brian's assessment. My point here is simple.... using
protocol market demand (as defined by one or two people) to drive feature
sets is not going to be productive. We should understand
the design space (like the building block draft spells out),
build an extensible framework (like used by a lot of other
protocols), and put the features in that we each need.
Basing importance of features on what one or even a few
say are important is not something I feel this working group
_needs_ to do. If we are building a framework that can support
a lot of varying protocols, then let's develop a simple
framework, and let each person carve out their own space in it.
We have all worked in this space for a while. We know a good
bit about what we need. At least as much as we need to know
to get something out that works and won't blow up the
Internet. :)
For most RM apps, I would choose PGM or SRM. They are light,
simple, and easy to use. The more advanced features that
RMTP-II and RMP offer can be run on top of them. This is
the lesson from Horus in my eyes. I also see a LOT of demand
for PGM... and we are going to be seeing a lot of implementations
of it over the next few months.
BTW: I WILL update the RM links page eventually. But I'm spread
a little thin right now to get to it. :)
-- Todd
>From kenm@starburstcom.com Mon Jul 12 14:26:10 1999
Received: from postal1.lbl.gov (localhost [127.0.0.1])
by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id OAA13523
for <rmt@listserv.lbl.gov>; Mon, 12 Jul 1999 14:26:06 -0700 (PDT)
Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id OAA17200
for <rmt@listserv.lbl.gov>; Mon, 12 Jul 1999 14:26:05 -0700 (PDT)
Received: from gummo.starburstcom.com (gummo.starburstsoftware.com [206.33.96.31])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id OAA17184
for <rmt@lbl.gov>; Mon, 12 Jul 1999 14:26:02 -0700 (PDT)
Received: from accord.starburstsoftware.com (accord.starburstcom.com [206.33.96.71])
by gummo.starburstcom.com (8.9.1/8.9.1) with SMTP id RAA11503;
Mon, 12 Jul 1999 17:15:00 -0400 (EDT)
Received: by accord.starburstsoftware.com with Microsoft Mail
id <01BECC8B.5A11F7C0@accord.starburstsoftware.com>; Mon, 12 Jul 1999 17:24:09 -0400
Message-ID: <01BECC8B.5A11F7C0@accord.starburstsoftware.com>
From: Ken Miller <kenm@starburstsoftware.com>
To: "'tmont@csee.wvu.edu'" <tmont@csee.wvu.edu>,
"'Brian Whetten'"
<whetten@concentric.net>,
"'Ken_Birman@email.msn.com'"
<Ken_Birman@email.msn.com>,
"'rmt@lbl.gov'" <rmt@lbl.gov>
Subject: RE: Comments on building-block and design-space drafts
Date: Mon, 12 Jul 1999 17:24:07 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by listserv.lbl.gov id OAA13523
I can also make the comment that 90+% of the current installations of reliable multicast based applications are actually MFTP, and it has gained the experience of 4 years in the commercial marketplace with production use.
Ken
>>Reply to your message of 7/12/99 1:46 PM
>>
>>I wanted to make a few observations and comments on the drafts
>>being developed and on comments seen on the mailing list.
>>
>>First off, I think the drafts are good first steps. Most of
>>the shortcomings have been mentioned and I am glad to see
>>things are progressing. However, the building block draft is
>>really vague..... I mean, really vague..... it really
>>does not describe a framework, it just lists what should be
>>in the framework with no technical details. It is necessary to
>>develop the building block draft as it stands, but it is definitely
>>not a document that I feel can go very far without a LOT more
>>detail. I think that the building block draft should be
>>retitled to "Building Block Design Space" and be its own
>>document. We need some initial design here. I think with the work done with
>>Horus, APPLCORE, and even the whole design pattern field,
>>we should be able to draw on a large body of work to aid us
>>in this. As a start, I would suggest basing things on
>>capabilities (like is used in IMAP, etc.). (If I was
>>not wearing 20 hats, I would take a stab at this....)
>>
>>Secondly, I want to respond to Brian's comment on the
>>demand for different protocols (RMTP-II 70%, RMP 20%, PGM 10%).
>>I have to disagree.... first off, I am no longer with GlobalCast
>>so I am not qualified to talk about their specific market. However,
>>even when I was involved with GlobalCast, I wouldn't have agreed
>>with Brian's assessment. My point here is simple.... using
>>protocol market demand (as defined by one or two people) to drive feature
>>sets is not going to be productive. We should understand
>>the design space (like the building block draft spells out),
>>build an extensible framework (like used by a lot of other
>>protocols), and put the features in that we each need.
>>Basing importance of features on what one or even a few
>>say are important is not something I feel this working group
>>_needs_ to do. If we are building a framework that can support
>>a lot of varying protocols, then let's develop a simple
>>framework, and let each person carve out their own space in it.
>>We have all worked in this space for a while. We know a good
>>bit about what we need. At least as much as we need to know
>>to get something out that works and won't blow up the
>>Internet. :)
>>
>>For most RM apps, I would choose PGM or SRM. They are light,
>>simple, and easy to use. The more advanced features that
>>RMTP-II and RMP offer can be run on top of them. This is
>>the lesson from Horus in my eyes. I also see a LOT of demand
>>for PGM... and we are going to be seeing a lot of implementations
>>of it over the next few months.
>>
>>BTW: I WILL update the RM links page eventually. But I'm spread
>>a little thin right now to get to it. :)
>>
>>-- Todd
>>
>>End of message
-----------------------------------------------------------------------------------------------------
Ken Miller
Chairman & CTO
StarBurst Software Phone: (978) 287-5560 x223
150 Baker Avenue FAX: (978) 287-5561
Concord, MA 01742 Web: http://www.starburstsoftware.com
------------------------------------------------------------------------------------------------------
>From whetten@talarian.com Tue Jul 13 06:57:58 1999
Received: from postal1.lbl.gov (localhost [127.0.0.1])
by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id GAA17600
for <rmt@listserv.lbl.gov>; Tue, 13 Jul 1999 06:57:57 -0700 (PDT)
Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id GAA21617
for <rmt@listserv.lbl.gov>; Tue, 13 Jul 1999 06:57:55 -0700 (PDT)
Received: from phobos.talarian.com (mailhost.talarian.com [207.5.32.17])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id GAA21613
for <rmt@lbl.gov>; Tue, 13 Jul 1999 06:57:54 -0700 (PDT)
Received: from tahoe (dhcp30238.ietf.uninett.no [128.39.30.238]) by phobos.talarian.com (8.9.0/8.9.0) with SMTP id GAA28205; Tue, 13 Jul 1999 06:55:24 -0700 (PDT)
Message-Id: <4.1.19990713010459.00d26f00@mailhost.talarian.com>
Message-Id: <4.1.19990713010459.00d26f00@mailhost.talarian.com>
X-Sender: whetten@pop3.concentric.net
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1
Date: Tue, 13 Jul 1999 01:10:29 -0700
To: Ken Miller <kenm@starburstsoftware.com>,
"'tmont@csee.wvu.edu'" <tmont@csee.wvu.edu>,
"'Brian Whetten'" <whetten@concentric.net>,
"'Ken_Birman@email.msn.com'" <Ken_Birman@email.msn.com>,
"'rmt@lbl.gov'" <rmt@lbl.gov>
From: Brian Whetten <whetten@talarian.com>
Subject: RE: Comments on building-block and design-space drafts
In-Reply-To: <01BECC8B.5A11F7C0@accord.starburstsoftware.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
My appologies, Ken. I should have also mentioned MFTP when discussing
market interest and uptake. Some may disagree, but I classify MFTP as a
one-layer HACK protocol (with, of course, NACK and FEC assist), at least at
the pure transport level. MFTP of course also includes higher level
file-transfer-specific session management, which we need to consider as we
define the higher level building blocks.
Brian
At 05:24 PM 7/12/99 -0400, Ken Miller wrote:
>I can also make the comment that 90+% of the current installations of
>reliable multicast based applications are actually MFTP, and it has gained
>the experience of 4 years in the commercial marketplace with production use.
>
>Ken
>
>>>Reply to your message of 7/12/99 1:46 PM
> >>
> >>I wanted to make a few observations and comments on the drafts
> >>being developed and on comments seen on the mailing list.
> >>
> >>First off, I think the drafts are good first steps. Most of
> >>the shortcomings have been mentioned and I am glad to see
> >>things are progressing. However, the building block draft is
> >>really vague..... I mean, really vague..... it really
> >>does not describe a framework, it just lists what should be
> >>in the framework with no technical details. It is necessary to
> >>develop the building block draft as it stands, but it is definitely
> >>not a document that I feel can go very far without a LOT more
> >>detail. I think that the building block draft should be
> >>retitled to "Building Block Design Space" and be its own
> >>document. We need some initial design here. I think with the work done with
> >>Horus, APPLCORE, and even the whole design pattern field,
> >>we should be able to draw on a large body of work to aid us
> >>in this. As a start, I would suggest basing things on
> >>capabilities (like is used in IMAP, etc.). (If I was
> >>not wearing 20 hats, I would take a stab at this....)
> >>
> >>Secondly, I want to respond to Brian's comment on the
> >>demand for different protocols (RMTP-II 70%, RMP 20%, PGM 10%).
> >>I have to disagree.... first off, I am no longer with GlobalCast
> >>so I am not qualified to talk about their specific market. However,
> >>even when I was involved with GlobalCast, I wouldn't have agreed
> >>with Brian's assessment. My point here is simple.... using
> >>protocol market demand (as defined by one or two people) to drive feature
> >>sets is not going to be productive. We should understand
> >>the design space (like the building block draft spells out),
> >>build an extensible framework (like used by a lot of other
> >>protocols), and put the features in that we each need.
> >>Basing importance of features on what one or even a few
> >>say are important is not something I feel this working group
> >>_needs_ to do. If we are building a framework that can support
> >>a lot of varying protocols, then let's develop a simple
> >>framework, and let each person carve out their own space in it.
> >>We have all worked in this space for a while. We know a good
> >>bit about what we need. At least as much as we need to know
> >>to get something out that works and won't blow up the
> >>Internet. :)
> >>
> >>For most RM apps, I would choose PGM or SRM. They are light,
> >>simple, and easy to use. The more advanced features that
> >>RMTP-II and RMP offer can be run on top of them. This is
> >>the lesson from Horus in my eyes. I also see a LOT of demand
> >>for PGM... and we are going to be seeing a lot of implementations
> >>of it over the next few months.
> >>
> >>BTW: I WILL update the RM links page eventually. But I'm spread
> >>a little thin right now to get to it. :)
> >>
> >>-- Todd
> >>
>>>End of message
>
>----------------------------------------------------------------------------
>-------------------------
>Ken Miller
>Chairman & CTO
>StarBurst Software Phone: (978) 287-5560 x223
>150 Baker Avenue FAX: (978) 287-5561
>Concord, MA 01742 Web: http://www.starburstsoftware.com
>----------------------------------------------------------------------------
>--------------------------
>
>From speakman@cisco.com Tue Jul 13 21:09:25 1999
Received: from postal1.lbl.gov (localhost [127.0.0.1])
by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id VAA20845
for <rmt@listserv.lbl.gov>; Tue, 13 Jul 1999 21:09:24 -0700 (PDT)
Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id VAA24454
for <rmt@listserv.lbl.gov>; Tue, 13 Jul 1999 21:09:24 -0700 (PDT)
Received: from zipper.cisco.com (zipper.cisco.com [171.69.63.31])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id VAA24450
for <rmt@lbl.gov>; Tue, 13 Jul 1999 21:09:23 -0700 (PDT)
Received: from localhost (speakman@localhost) by zipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id VAA25668 for <rmt@lbl.gov>; Tue, 13 Jul 1999 21:08:52 -0700 (PDT)
Message-Id: <199907140408.VAA25668@zipper.cisco.com>
To: rmt@lbl.gov
Subject: Scope of the bb spec
Date: Tue, 13 Jul 1999 21:08:52 -0700
From: Tony Speakman <speakman@cisco.com>
I have several more narrowly focussed comments on the bb draft,
but I'd like to address a few basic points ahead of the wg
meeting.
The most fundamental is that I think the list in section 3
contains 3 items that don't relate to the transport of data
in the network and don't require standardization. These are
group membership, session management, and tree configuration.
These three components add a conceivably large variety of
attributes to ways of operating a multicast transport protocol,
but they can be designed entirely in isolation from the TP
and, since they can have no dependencies on it, can evolve and
diverge in variety as higher layer models of multicast service
emerge. From the network perspective, there is no need to
mandate anything about these components. From a practical/
commercial/application/perspective, I'm sure the market
would like there to be a common implementation of these
components, but we should keep our hands off them and leave
creative application layer developers free to improvise
these components according to application feature requirements.
Since there's already an IRTF for security, that leaves us with
data reliability and congestion control, a much more focussed
mandate and one which is already aligned with the coverage we
have seen in the RM IRTF.
At a more specific level of detail, I'd like to clarify an
important distinction I see blurred in the statement just
ahead of section 4 that PGM contains an hierarchical element
and thus a tree building component. Clarifiying the notion
of tree building helps in understanding why I think it
can come off the list along with the other two.
One of the things SPMs do in PGM is carry explicit neighbour
information downstream on the distribution tree. This
function is entirely superfluous in a pure PGM topology,
so in it's current incarnation it is just establishing a
logical distribution tree that is used to return NAKs. That
tree is coincident with the data distribution tree and constists
of network elements. It is just reinforcing an hierarchical
relationship those network elements already have as a result
of multicast routing protocols.
By contrast, the arrangement of non-network elements into
a hierarchy relative to each other does require tree building
and that tree building may or may not relate to the distribution
tree. The tree building component should permit ACK aggregators
or retransmitters to be arranged in an arbitrary topology
optimized for any metric including a metric that allows that
hierarchy to be coincident with the distribution tree.
IMHO,
Tony S
>From mpullen@netlab.gmu.edu Thu Jul 15 08:07:48 1999
Received: from postal1.lbl.gov (localhost [127.0.0.1])
by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id IAA26139
for <rmt@listserv.lbl.gov>; Thu, 15 Jul 1999 08:07:47 -0700 (PDT)
Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id IAA05308
for <rmt@listserv.lbl.gov>; Thu, 15 Jul 1999 08:07:46 -0700 (PDT)
Received: from netlab.gmu.edu (netlab40.gmu.edu [129.174.40.125])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id IAA05298
for <rmt@lbl.gov>; Thu, 15 Jul 1999 08:07:45 -0700 (PDT)
Received: from localhost (mpullen@localhost)
by netlab.gmu.edu (8.8.5/8.8.5) with SMTP id LAA13210;
Thu, 15 Jul 1999 11:07:43 -0400 (EDT)
Date: Thu, 15 Jul 1999 11:07:43 -0400 (EDT)
From: Mark Pullen <mpullen@netlab.gmu.edu>
X-Sender: mpullen@netlab
To: rmt@lbl.gov
cc: Mark Pullen <mpullen@netlab.gmu.edu>
Subject: Re: I-D ACTION:draft-ietf-rmt-design-space-00.txt
In-Reply-To: <199906211831.OAA07374@ietf.org>
Message-ID: <Pine.SO4.4.02.9907151034070.10115-100000@netlab>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
RMT folks,
I am chagrined that I missed today's session, due to a
schedule error. Here are some points I had planned to make
regarding the Design Space draft. These are based on experience with
a hybrid RM protocol for distributed simulation. The points
admittedly are not specific to bulk data transfer, but then
a lot of this I-D seems to go beyond bulk data transfer. That is not
necessarily a bad thing, because this document is helping to build up a
common frame of reference for RM in general.
1. Introduction: 5th line "many" seems strong, perhaps it should
be "some"
2. Application Constraints: two constraint categories seem to
be missing:
o Does the application send a mix of reliable and best-effort
traffic? (it is possible to use the best-effort traffic to
inform receivers that a new reliable message has been sent;
they can NACK if they have not received)
o Does the application require intermediate values of transmitted
information, or only the last transmitted value? (if only the last
value there is a large reduction in state requirements for repairs,
somewhat related to the point on sender state reduction made in
section 4.2)
2.5 Time-bounded delivery: it might be good to refine the point
in the last sentence, which states "Time bounded delivery usually
also implies a semi-reliable protocol..." Given that this draft
envisions use of a shared network with only best-effort IP, one
can say that time-bounded delivery ALWAYS implies a semi-reliable
protocol, because there is no mechanism to ensure that other
users' transmissions will not congest the network.
3.3 Network Assistance: I'm not sure the taxonomy here covers
the cases completely. We have been working on a design for many-to-many
multicast where the transport layer in participating hosts can be
elected to answer with repairs (transparent to the application),
in order to localize repairs as much as possible. This might fit under
"Server-based approaches", but I would suggest a category "Peer-based
approaches" to cover the case where any multicast group member can provide
repairs, not just dedicated servers.
Mark
>From mjh@aciri.org Thu Jul 15 08:29:04 1999
Received: from postal1.lbl.gov (localhost [127.0.0.1])
by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id IAA26250
for <rmt@listserv.lbl.gov>; Thu, 15 Jul 1999 08:29:04 -0700 (PDT)
Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id IAA12003
for <rmt@listserv.lbl.gov>; Thu, 15 Jul 1999 08:29:03 -0700 (PDT)
Received: from aardvark.aciri.org (aardvark.aciri.org [192.150.187.20])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id IAA11984
for <rmt@lbl.gov>; Thu, 15 Jul 1999 08:29:01 -0700 (PDT)
Received: from aardvark.aciri.org (localhost [127.0.0.1])
by aardvark.aciri.org (8.9.2/8.9.2) with ESMTP id IAA82081;
Thu, 15 Jul 1999 08:28:42 -0700 (PDT)
(envelope-from mjh@aardvark.aciri.org)
From: Mark Handley <mjh@aciri.org>
X-Organisation: ACIRI
To: Mark Pullen <mpullen@netlab.gmu.edu>
cc: rmt@lbl.gov
Subject: Re: I-D ACTION:draft-ietf-rmt-design-space-00.txt
In-reply-to: Your message of "Thu, 15 Jul 1999 11:07:43 EDT."
<Pine.SO4.4.02.9907151034070.10115-100000@netlab>
Date: Thu, 15 Jul 1999 08:28:42 -0700
Message-ID: <82079.932052522@aardvark.aciri.org>
Sender: mjh@aciri.org
>RMT folks,
>
>I am chagrined that I missed today's session, due to a
>schedule error. Here are some points I had planned to make
>regarding the Design Space draft.
Thanks Mark - I mostly agree with your points, and will include them
in the next version. One exception:
>2. Application Constraints: two constraint categories seem to
>be missing:
>
>o Does the application send a mix of reliable and best-effort
> traffic? (it is possible to use the best-effort traffic to
> inform receivers that a new reliable message has been sent;
> they can NACK if they have not received)
What you describe is less a requirement than an implementation question.
This mechanism is normal for a many-to-many NACK-based protocol such
as SRM, where tail loss detection is critical. It's less clear to me
how important it is for bulk data transfer applications, which this
draft covers though. Tail loss detection is still required, but can
normally be dealt with though other means.
Cheers,
Mark
>From J.Crowcroft@cs.ucl.ac.uk Fri Jul 16 01:16:19 1999
Received: from postal1.lbl.gov (localhost [127.0.0.1])
by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id BAA00025
for <rmt@listserv.lbl.gov>; Fri, 16 Jul 1999 01:16:18 -0700 (PDT)
Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id BAA16013
for <rmt@listserv.lbl.gov>; Fri, 16 Jul 1999 01:16:17 -0700 (PDT)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
by SpamWall.lbl.gov (8.9.3/8.9.3) with SMTP id BAA16009
for <rmt@lbl.gov>; Fri, 16 Jul 1999 01:16:16 -0700 (PDT)
Received: from hocus.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP
id <g.07837-0@bells.cs.ucl.ac.uk>; Fri, 16 Jul 1999 09:16:13 +0100
To: rmt@lbl.gov
Subject: RM delivery semantics
Date: Fri, 16 Jul 1999 09:16:12 +0200
Message-ID: <384.932112972@cs.ucl.ac.uk>
From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
I guess it would be nice to really nail down what we meant by RM
delivery semantics
stable mesages refers to messages which the application has receiverd
acknowldged messaged refers to thanks the transport has receiverd
in the example i gave during RMT, NFS uses an RPC protocol -
A write message in NFS is supposed to have the semantics of unix
write, which is to write thru the caxce onto stable store...
If the RPC is carried over UDP, the RPC response from the application
happends when the message has been resceived and saved by the
application
If the RPC is carried over TCP, the RPC level dows the same thiing,
but, potentnailly, if the reciver is a bit slow in gettign the data to
disk, the TCP in the reciver will aclk the TCP data packet that
carried the ack and then the recvier rpc response will cause the
send of a data packet (with the same ack seq number of course)
the diffrence in the two TCP cases shows that while there are two
levels, that transport acknlowdgement of receipt, and the applicatio
acknowledgement of receipt, they are OFTEN piggybacks for lots of good
reasons.
THe point for RM protocls is that (of course,) the tight timeing
coupling required to get this piggybacking to work
is completely at odds with a lot of the feedback implosion control
strategies....i.e. it is probably anathema to scaling.
Also, we should note, this is ANOTHER reason to staty wih application
where the _eventual_ message stability is important (although sender
knowledge of all-receiver meassage stability may not be) bcecause we
are not doing transacations or RPC like applications, but ratehr,
long-lived ftp like applications......
my two NOKs
jon
>From redmonst@cisco.com Mon Jul 19 03:10:09 1999
Received: from postal1.lbl.gov (localhost [127.0.0.1])
by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id DAA08181
for <rmt@listserv.lbl.gov>; Mon, 19 Jul 1999 03:10:09 -0700 (PDT)
Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id DAA01175
for <rmt@listserv.lbl.gov>; Mon, 19 Jul 1999 03:10:08 -0700 (PDT)
Received: from jindo.cisco.com (jindo.cisco.com [171.69.43.22])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id DAA01171
for <rmt@lbl.gov>; Mon, 19 Jul 1999 03:10:07 -0700 (PDT)
Received: from jaws.cisco.com (jaws.cisco.com [198.135.1.36])
by jindo.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with SMTP id DAA27233
for <rmt@lbl.gov>; Mon, 19 Jul 1999 03:09:34 -0700 (PDT)
Date: Mon, 19 Jul 1999 11:09:32 +0100 (BST)
From: Richard Edmonstone <redmonst@cisco.com>
To: rmt@lbl.gov
Subject: commets on drafts
Message-ID: <Pine.GSO.3.96.990719110623.29923A-100000@jaws.cisco.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Hi,
Here are some specific comments on the two RMT drafts.
Cheers,
Richard.
--
Comments for buildingblocks-00.txt
----------------------------------
a1.) Page 3, para 2; is 1000 - 10000 a large enough target for number of
receivers ? For an internet multicast protocol should our aim be
higher ?
a2.) Page 4, section 1.1. The wording implies that the 4 "families" of protocol
are mutually exclusive. For example, a reader new to the problem space
would think from reading this section that FEC was unreliable and mutually
exclusive of the others. IMHO, text could be added after points 1-4 along
the lines of:
"Note that these families are not exclusive. For example, some protcols
may combine FEC and an ACK or NAK mechanism to increase overall
reliability."
a3.) Page 4, section 1.1, point 2. The server assist point misses out the
notion of local retransmitters that can be useful in certain network
scenarios; eg. asymmetric networks or at key points in the internet. This
notion should not be lost and could either be added to this section or
somewhere else.
a4.) Page 4, section 1.1, point 3. An important point of router assist can be
the strengthening of NAKs; the routers maintain state and retransmit NAKs
in a hop by hop basis. This could be mentioned so as not to misrepresent
PGM.
a5.) Page 7, section 3. Are we missing a section for the obvious protocol
component of data delivery ? Should this or the data reliability section
mention a "Data Ordering" sub component ?
a6.) Page 8, section 3. Session management section. There was some debate
at the IETF RMT meeting about ACKs and whether an ACK based protocol
gives better "message stability" than a NAK based protocol. It was
suggested that "receipt confirmation" is appropriate and could be
viwed as separate from the transport level ACK mechanism.
Do we want to put the function of receipt confirmation into a building
block ?
a7.) Page 9, section 3.1. After the IETF meeting, we are in a position to
clarify that only denial of service style attacks are within the scope of
the RMT protocols and that the other security issues will be dealt with
by SMuG. The text could be changed to reflect this. This comment applies
to section 4.6 aswell.
a8.) Reference FLST98; one author is S.Lin not A.Lin.
Comments for design-space-00.txt
----------------------------------
b1.) Page 3, section 2. A missing application constraint is :
"Does the application need ordered data ?".
b2.) Page 3, section 2.1. Relates to comment a6 above. I think we need to
decouple the transport layer packet by packet ACK/NAK mechanism from
the notion of receipt confirmation. Here's a good place to do it.
ADU acknowledgement still implies (to me) smallish data chunks of a form.
I'd like to see an session ack component based around acking "large"
self-describing objects. This component would sit on "top" of the data
delivery / reliability component, regardless of this component's
reliability mechanism (ACK, NAK, FEC or whatever).
b3.) Page 4, section 2.3. Section should state that the different solutions
can be combined into hybrids. See comment a2 above.
b4.) Maybe I'm biased, but I don't hold with the statements in section 3.1
as regards the cost of extra state required for router assist. I'd like to
see these statements removed and replaced with a statement that "it may
take several years to deploy router assist in the internet, due to the
release / quality cycle associated with service providers upgrading to new
router software."
b5.) page 5, section 3.2, paragraph 1. Limits on the number of S,G states
that internet routers can deal with definately limit the use of
multicast for NAK suppression. Local wire multicasts could be used for
some local suppression. The notion of NAK elimination on the return path
could be brought in here aswell.
b6.) page 10, section 4.2. NAK elimination needs mentioned aswell as the
already mentioned suppression. Probably a small subsection 4.2.2 could
be added for this.
b7.) page 10, section 4.2.1, point 4. PGM is mis-represented here. PGM
uses several mechanisms to suppress NAKs. It uses random timers on
the receivers that will adjust their random period dynamically to local
group size. It uses feedback from the 1st hop PGM capable router to the
receivers to suppress NAKs. In addition, it optionally uses a local scope
multicast from a NAKing receiver to other receivers.
b8.) page 10, section 4.2.1, last paragraph. For my education, what is a
"sender triggered NACK mechanism" ?
b9.) Reference FLST98; one author is S.Lin not A.Lin.
>From whetten@talarian.com Tue Jul 20 14:45:42 1999
Received: from postal1.lbl.gov (localhost [127.0.0.1])
by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id OAA17902
for <rmt@listserv.lbl.gov>; Tue, 20 Jul 1999 14:45:41 -0700 (PDT)
Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id OAA11937
for <rmt@listserv.lbl.gov>; Tue, 20 Jul 1999 14:45:40 -0700 (PDT)
Received: from phobos.talarian.com (mailhost.talarian.com [207.5.32.17])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id OAA11925
for <rmt@lbl.gov>; Tue, 20 Jul 1999 14:45:39 -0700 (PDT)
Received: from tahoe (ta035.talarian.com [204.147.187.35] (may be forged)) by phobos.talarian.com (8.9.0/8.9.0) with SMTP id OAA15225; Tue, 20 Jul 1999 14:45:01 -0700 (PDT)
Message-Id: <4.1.19990720100536.024ce9f0@mailhost.talarian.com>
Message-Id: <4.1.19990720100536.024ce9f0@mailhost.talarian.com>
X-Sender: bwhetten@mailhost.talarian.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1
Date: Tue, 20 Jul 1999 10:32:42 -0700
To: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>, rmt@lbl.gov
From: Brian Whetten <whetten@talarian.com>
Subject: Re: RM delivery semantics
In-Reply-To: <384.932112972@cs.ucl.ac.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Hi Jon,
I think this debate simply comes down to the question of whether or not
message stability requires getting acknowledgements from the transport, or
from the application. From a semantics/taxonomy perspective, I would
suggest/agree that we have a major division between "statistical
reliability/goodput ensurance" and "message stability", and then an
additional minor division within message stability, as to whether the
acknowledgement is from the transport or the application. i.e.
Reliability Semantics
- Statistical Reliability (anyone have a better name yet?)
- Message Stability
- Optimistic Stability (transport layer)
- Pessimistic Stability (transport layer)
- Application level stability
>From a building blocks/implementation perspective, unless we are doing
high-end (ISIS/Horus/RMP/etc.) fault tolerant applications (which we're
not, for now), the primary reason I see to care about getting an
application level acknowledgement is if the application is going to do
something persistent with the data, either writing it to disk or to a
database--which may happen relatively quickly (<50ms), or could take up to
seconds to complete. I could see some other cases which would have much
longer time scales for application acks, but I think those are outside our
primary scope.
>From a layering semantics perspective, I feel that a transport protocol
should provide transport layer semantics as the default. We need to
remember that our principal audience is the same community that uses
sockets, not the high-end research-aware developers that participate in the
IETF.
>From an implementation/performance perspective, having an implementation
that offers high end developers the option to piggy-back application level
acknowledgements on top of a TRACK (previously named HACK) infrastructure
seems useful, and I don't think it will impact performance that much.
Taking RMTP-II as an example, message stability is reported in a different
field than those used for requests for retransmission and measurements of
loss. Therefore, it would not directly impact the performance of the TRACK
generation, retransmission algorithms, or of congestion control. It would
simply delay the stability at the sender, and require additional message
buffering throughout the protocol.
Again taking RMTP-II as an example, it already offers two levels of message
stability -- optimistic and pessimistic. Application message stability
semantics are a simple extension to pessimistic aggregation (they make no
sense with optimistic aggregation), so you can just have a third option,
for application stability.
Again, I'd recommend that from a usability perspective we don't focus on
application stability except as a special option...but its pretty trivial
to standardize/implement.
Brian
At 09:16 AM 7/16/99 +0200, Jon Crowcroft wrote:
>
>I guess it would be nice to really nail down what we meant by RM
>delivery semantics
>
>stable mesages refers to messages which the application has receiverd
>acknowldged messaged refers to thanks the transport has receiverd
>
>in the example i gave during RMT, NFS uses an RPC protocol -
>A write message in NFS is supposed to have the semantics of unix
>write, which is to write thru the caxce onto stable store...
>
>If the RPC is carried over UDP, the RPC response from the application
>happends when the message has been resceived and saved by the
>application
>
>If the RPC is carried over TCP, the RPC level dows the same thiing,
>but, potentnailly, if the reciver is a bit slow in gettign the data to
>disk, the TCP in the reciver will aclk the TCP data packet that
>carried the ack and then the recvier rpc response will cause the
>send of a data packet (with the same ack seq number of course)
>
>the diffrence in the two TCP cases shows that while there are two
>levels, that transport acknlowdgement of receipt, and the applicatio
>acknowledgement of receipt, they are OFTEN piggybacks for lots of good
>reasons.
>
>THe point for RM protocls is that (of course,) the tight timeing
>coupling required to get this piggybacking to work
>is completely at odds with a lot of the feedback implosion control
>strategies....i.e. it is probably anathema to scaling.
>
>Also, we should note, this is ANOTHER reason to staty wih application
>where the _eventual_ message stability is important (although sender
>knowledge of all-receiver meassage stability may not be) bcecause we
>are not doing transacations or RPC like applications, but ratehr,
>long-lived ftp like applications......
>
>my two NOKs
>
>
>jon
>
>From vogels@cs.cornell.edu Wed Jul 21 07:21:10 1999
Received: from postal1.lbl.gov (localhost [127.0.0.1])
by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id HAA20673
for <rmt@listserv.lbl.gov>; Wed, 21 Jul 1999 07:21:09 -0700 (PDT)
Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id HAA09305
for <rmt@listserv.lbl.gov>; Wed, 21 Jul 1999 07:21:09 -0700 (PDT)
Received: from opus.cs.cornell.edu (EXCHANGE.CS.CORNELL.EDU [128.84.248.73])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id HAA09301
for <rmt@lbl.gov>; Wed, 21 Jul 1999 07:21:08 -0700 (PDT)
Received: by EXCHANGE.CS.CORNELL.EDU with Internet Mail Service (5.5.2448.0)
id <311Q4CJK>; Wed, 21 Jul 1999 10:20:36 -0400
Message-ID: <AFF14EF52432D2118C0B00A0C9558F2C3D3066@EXCHANGE.CS.CORNELL.EDU>
From: Werner Vogels <vogels@cs.cornell.edu>
To: rmt@lbl.gov
Subject: RE: RM delivery semantics
Date: Wed, 21 Jul 1999 10:20:36 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="windows-1252"
A "short" reply, I feel a more extensive discussion belongs in RMRG not rmt.
The way I read Jon's message, and the way it is important for the RMT
building block design space, is that: if the application or protocols above
the immediate transport wants to piggyback some additional data on transport
information flowing back to the sender (xxACK's in general), how can we
support this.
- I don't think it would be difficult to get consensus on whether the
piggybacking is a "good thing": it is only the transport layer that has
access to a preferred path back to the sender. It does not seem a good idea
if the application would also start sending UDP packets back to the sender
with stability style information, where they are likely to travel
side-by-side xxACK messages triggered by the same data.
- In contrast to Brian I do not feel it is simple to implement. The biggest
problem I see, is that it is almost impossible to do with the transport
being a black box. In the ideal case if the receiver transport periodically
sends back reports to the sender, it could upcall to an upper module to
request whether it has data to piggyback. At the sender, at the receipt of
this report, it indicates this data to the upper sender module. Perfect,
optimal resource usage. The problem starts if the "report back to the
sender" is not that simple: if we use a tree structure, or use gossip
techniques for the reports, intermediate nodes that are able to collapse
multiple reports into a single message, would also need a condensation
function for the data that the upper modules at receivers have generated. If
the data is simple: a single sequence number identical to the message seq#,
it could be done. If the data is more extensive it becomes almost impossible
to have this knowledge in all the intermediate nodes. The second problem
here is what the sender can do with the data reported to it: if he receives
a condensed report, does he know to which receivers it applies without
having a view of the transport topology? Which means that more of the
transport information needs to be exposed to support this. So I feel it can
be done, but not by using strict layering or black box transports.
- some additional experiences: it is a misconception that application
stability information is only useful for fancy fault-tolerance style
applications. It is dangerous to split the world into two parts "networking"
on one side and "distributed systems" on the other. You will miss out on a
lot of good stuff if you draw a strict line at the transport level, and
ignore the rest as "research". For example if there is a simple way to
disseminate stability info, a number of the web object caching protocols can
be made a lot simpler. While currently many of your customers may be still
stuck at socket level (Brian's words, not mine ...), eventually they are all
solving problems in the application that are distributed in nature and thus
will be doing things that are beyond simple transport message exchange. But
they are far from fault-tolerance style apps. Our experience is that
customers are looking hard at the reliable-multicast space to solve a number
of their scalability problems, restructuring systems such that they can
exploit rm to make their apps scalable, and the results are complex systems
that need all the help they can get from us.
2cnts,
--
Werner
-----Original Message-----
From: Brian Whetten [mailto:whetten@talarian.com]
Sent: Tuesday, July 20, 1999 1:33 PM
To: Jon Crowcroft; rmt@lbl.gov
Subject: Re: RM delivery semantics
Hi Jon,
I think this debate simply comes down to the question of whether or not
message stability requires getting acknowledgements from the transport, or
from the application. From a semantics/taxonomy perspective, I would
suggest/agree that we have a major division between "statistical
reliability/goodput ensurance" and "message stability", and then an
additional minor division within message stability, as to whether the
acknowledgement is from the transport or the application. i.e.
Reliability Semantics
- Statistical Reliability (anyone have a better name yet?)
- Message Stability
- Optimistic Stability (transport layer)
- Pessimistic Stability (transport layer)
- Application level stability
>From a building blocks/implementation perspective, unless we are doing
high-end (ISIS/Horus/RMP/etc.) fault tolerant applications (which we're
not, for now), the primary reason I see to care about getting an
application level acknowledgement is if the application is going to do
something persistent with the data, either writing it to disk or to a
database--which may happen relatively quickly (<50ms), or could take up to
seconds to complete. I could see some other cases which would have much
longer time scales for application acks, but I think those are outside our
primary scope.
>From a layering semantics perspective, I feel that a transport protocol
should provide transport layer semantics as the default. We need to
remember that our principal audience is the same community that uses
sockets, not the high-end research-aware developers that participate in the
IETF.
>From an implementation/performance perspective, having an implementation
that offers high end developers the option to piggy-back application level
acknowledgements on top of a TRACK (previously named HACK) infrastructure
seems useful, and I don't think it will impact performance that much.
Taking RMTP-II as an example, message stability is reported in a different
field than those used for requests for retransmission and measurements of
loss. Therefore, it would not directly impact the performance of the TRACK
generation, retransmission algorithms, or of congestion control. It would
simply delay the stability at the sender, and require additional message
buffering throughout the protocol.
Again taking RMTP-II as an example, it already offers two levels of message
stability -- optimistic and pessimistic. Application message stability
semantics are a simple extension to pessimistic aggregation (they make no
sense with optimistic aggregation), so you can just have a third option,
for application stability.
Again, I'd recommend that from a usability perspective we don't focus on
application stability except as a special option...but its pretty trivial
to standardize/implement.
Brian
At 09:16 AM 7/16/99 +0200, Jon Crowcroft wrote:
>
>I guess it would be nice to really nail down what we meant by RM
>delivery semantics
>
>stable mesages refers to messages which the application has receiverd
>acknowldged messaged refers to thanks the transport has receiverd
>
>in the example i gave during RMT, NFS uses an RPC protocol -
>A write message in NFS is supposed to have the semantics of unix
>write, which is to write thru the caxce onto stable store...
>
>If the RPC is carried over UDP, the RPC response from the application
>happends when the message has been resceived and saved by the
>application
>
>If the RPC is carried over TCP, the RPC level dows the same thiing,
>but, potentnailly, if the reciver is a bit slow in gettign the data to
>disk, the TCP in the reciver will aclk the TCP data packet that
>carried the ack and then the recvier rpc response will cause the
>send of a data packet (with the same ack seq number of course)
>
>the diffrence in the two TCP cases shows that while there are two
>levels, that transport acknlowdgement of receipt, and the applicatio
>acknowledgement of receipt, they are OFTEN piggybacks for lots of good
>reasons.
>
>THe point for RM protocls is that (of course,) the tight timeing
>coupling required to get this piggybacking to work
>is completely at odds with a lot of the feedback implosion control
>strategies....i.e. it is probably anathema to scaling.
>
>Also, we should note, this is ANOTHER reason to staty wih application
>where the _eventual_ message stability is important (although sender
>knowledge of all-receiver meassage stability may not be) bcecause we
>are not doing transacations or RPC like applications, but ratehr,
>long-lived ftp like applications......
>
>my two NOKs
>
>
>jon
>
>From owner-rmt@listserv.lbl.gov Fri Jul 30 08:02:45 1999
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.0/8.9.0) id IAA03280;
Fri, 30 Jul 1999 08:01:04 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from labinfo.iet.unipi.it (localhost [127.0.0.1])
by listserv.lbl.gov (8.9.0/8.9.0) with SMTP id IAA03276
for <rmt@listserv.lbl.gov>; Fri, 30 Jul 1999 08:00:59 -0700 (PDT)
Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id OAA09854; Fri, 30 Jul 1999 14:25:51 +0200
From: Luigi Rizzo <luigi@labinfo.iet.unipi.it>
Message-Id: <199907301225.OAA09854@labinfo.iet.unipi.it>
Subject: Finally! PGM source code for FreeBSD available!
To: rm@mash.cs.berkeley.edu
Date: Fri, 30 Jul 1999 14:25:51 +0200 (MET DST)
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-rmt@listserv.lbl.gov
Precedence: bulk
[apologies for the duplicates to rmt and rm list members, the feedback
is directed to rm only]
After way too much delay I am glad to announce the availability of the
first snapshot of my PGM Host implementation for FreeBSD.
For the full details (kernel code, sample code, notes...) see
http://www.iet.unipi.it/~luigi/pgm.html
feedback appreciated, support for developing this also appreciated...
The code is rapidly evolving, so make sure to get the latest version
when you decice to try it!
enjoy
luigi
-----------------------------------+-------------------------------------
Luigi RIZZO, luigi@iet.unipi.it . Dip. di Ing. dell'Informazione
http://www.iet.unipi.it/~luigi/ . Universita` di Pisa
TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy)
http://www.iet.unipi.it/~luigi/ngc99/
==== First International Workshop on Networked Group Communication ====
-----------------------------------+-------------------------------------
>From owner-rmt@listserv.lbl.gov Sat Jul 31 01:46:48 1999
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.0/8.9.0) id BAA06094;
Sat, 31 Jul 1999 01:44:24 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (localhost [127.0.0.1])
by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id BAA06090
for <rmt@listserv.lbl.gov>; Sat, 31 Jul 1999 01:44:22 -0700 (PDT)
Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id BAA11631
for <rmt@listserv.lbl.gov>; Sat, 31 Jul 1999 01:44:21 -0700 (PDT)
Received: from daffy.ee.lbl.gov (daffy.ee.lbl.gov [131.243.1.31])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id BAA11624
for <rmt@lbl.gov>; Sat, 31 Jul 1999 01:44:20 -0700 (PDT)
Received: (from vern@localhost)
by daffy.ee.lbl.gov (8.9.2/8.9.2) id BAA07453;
Sat, 31 Jul 1999 01:44:20 -0700 (PDT)
Message-Id: <199907310844.BAA07453@daffy.ee.lbl.gov>
To: rmt@lbl.gov
Subject: Administrative: rmt@lbl.gov now managed by majordomo
In-reply-to: Your message of Sat, 31 Jul 1999 01:27:02 PDT.
Date: Sat, 31 Jul 1999 01:44:19 PDT
From: Vern Paxson <vern@ee.lbl.gov>
Sender: owner-rmt@listserv.lbl.gov
Precedence: bulk
The mailing list management of rmt@lbl.gov has been changed to be via email
to majordomo@listserv.lbl.gov. Let me know if you encounter any problems.
Vern
>From owner-rmt@listserv.lbl.gov Mon Aug 2 08:25:13 1999
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.0/8.9.0) id IAA23461;
Mon, 2 Aug 1999 08:20:39 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (localhost [127.0.0.1])
by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id IAA23457
for <rmt@listserv.lbl.gov>; Mon, 2 Aug 1999 08:20:37 -0700 (PDT)
Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id IAA20916
for <rmt@listserv.lbl.gov>; Mon, 2 Aug 1999 08:20:36 -0700 (PDT)
Received: from hubbub.cisco.com (hubbub.cisco.com [171.69.11.2])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id IAA20903
for <rmt@lbl.gov>; Mon, 2 Aug 1999 08:20:34 -0700 (PDT)
Received: from OranLT ([171.69.210.9]) by hubbub.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/CISCO.GATE.1.1) with SMTP id IAA04139; Mon, 2 Aug 1999 08:18:09 -0700 (PDT)
From: "David Oran" <oran@cisco.com>
To: <maddogs@ietf.org>, <idmr@cs.ucl.ac.uk>, <idr@merit.edu>,
<msdp@network-services.uoregon.edu>, <pim@catarina.usc.edu>,
<mboned@network-services.uoregon.edu>, <malloc@catarina.usc.edu>,
<rmt@lbl.gov>
Subject: Maestro BoF Results
Date: Mon, 2 Aug 1999 11:17:41 -0400
Message-ID: <NBBBIFCAKKOPNMMKHHEFGEBGFFAA.oran@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-rmt@listserv.lbl.gov
Precedence: bulk
The Routing Area held a BoF at the Oslo IETF whose purpose was to discuss
potential refinements to the IP multicast model in two areas:
1) Enhanced two-part multicast addressing to ease scalability and
deployment
headaches,
2) Optimizations to exploit the single-sender case
The BoF announcement, along with its scope and agenda, may be found at:
http://www.ietf.org/ietf/99jul/maestro-agenda-99jul.txt.
I am sending this message to who I think are all the relevant WG mailing
lists, and it will also be sent out via IETF-announce, so please let me know
directly if I've missed a relevant group rather than risk clogging peoples'
mailboxes with multiple forwards.
The minutes of BoF are attached below. One of the conclusions from the BoF
was to continue discussions on these subjects to ascertain if there is a
critical mass of support to charter one or more Working Groups to pursue
IETF standards (or other outputs) in these areas. We are therefore
resurrecting a moribund Routing Area mailing list for this purpose:
routing-discussion@ietf.org
Subscription is via majordomo@ietf.org
Thanks to all who participated in the BoF and in advance for useful
low-flamability discussion on the mailing list.
Regards, Dave Oran (routing co-area director)
MAESTRO BOF, Dave Oran
----------------------
AGENDA
History - modify multicast model, do we need a working group
on this?
A number of people think if we simplify the multicast model
there are significant benefits in reducing complexity.
changes: addressing model, assume single sender.
We want to look at the problems today and see how proposed
simplications might help.
Ground rules: talk about problems and how they map to the
proposed simplifications. from two perspectives, isp's
and architectural view.
Bryan Lyles, Sprint Deployment Strategy
---------------------------------------
Today, multicast enabled, working with vendors and customers to make
it work. built on PIM-SM, MSDP, MBGP, IGMPV2, GLOP.
Short Term - push current protocols, work in ietf to enhance base.
Certain kinds of applications want single server (radio station,
politician giving speech, dont want opposition heckling him)
Hugh Holbrook, Stanford/Cisco
-----------------------------
Some multicast applications work well with unicast
others its impossible, high data rates, many receivers
questions to isp's - how do you bill for it. make billing reflect
cost. so charge by size of group.
dmm - if i am a source, receivers on same isp are onnet,
other receivers are offnet. want to billed for offnet folks.
brad cain - bill by bandwidth, can isp's break even on multicast.
Queries flow down tree, counts flow back up, somehow gather data
to bill src. access control for large groups, restrict senders
in advance (pirates on tv station), important for commercial
applications too.
kevin almeroth - why does it work with radia, lawyers are
the answers, no one owns a multicast address, if they did
you could sue someone for using yours without permission.
security - source provides passwd to receivers
www.dsg.stanford.edu/hollbrook/express
Jeremy Hall, uunet
------------------
Problems - scalability, single source model ok, hard to implement.
you are trying to restrict something that is not restrictable.
lots of protocols running as ships in the night, ok when it works,
never know which one is not working correctly. way too much ad hoc
stuff going on. which protocol is broken. nice to be able to trace
a problem from the sender, to the receiver. receiver says i'm not
receiving this content. have to figure out from that info, where
the source is and what the problem is.
Some applications hide the group, so you cant figure out where
to troubleshoot. people dont understand how it works, so they
cant help you debug. need education.
Billing problems, counting receivers might be nice but is hard
as groups get big. onnet vs offnet. tried to employ things
that are parallel to unicast. unicast routing tries to dump traffic
asap, mulitcast wants to keep as long as possible. current model
doesnt scale. anyone can source to any group and thats a security
problem. there are a lot of security issues with multicast.
Mark Handley, ACIRI
-------------------
Internet Standard Multicast, where it came from and why it had
nice properties. direct extension of the unicast model, host
sends packets to destination address, it gets there. nice
architecure, senders dont need to know about receivers.
recievers dont need to know who senders are. distributed binding
is useful resource. senders and receivers dont need to know about
topology, robust, route around failures etc. hosts dont need to
knows about routing protocool. need distinction between service
model and its implementation in the network. separates what
the application wants and how the network achieves it. clean
separation of routing and transport/application layer.
What can we do with it:
Regular one to many applications - video distribution, data distribution
many to many applications - conferening, games, dont know members in
advance, distributed binding is very robust, changes the way you design
applications (eg wb)
Many to few applications - server discovery
Scoping, used to have ttl scoping, poor for traffic engineering,
great for self organizing applications, expanding ring search,
we lost the ttl in pim, admin scoping getting it back, mzap
Security - can only restrict traffic safely with encryption.
content providers want authentication, have the mechanisms already.
problems:
forwarding table size, aggregation helps some;
how can isp's make money;
lack of scalable routing protocol, bgmp, hierarchical pim,
bi-direction pim with grib, bgmp will probably work,
hierarchical pim too;
lack or good network management and diagnostic tools.
serious growing pains, transition from dvmrp painful
distributed binding a key - wb, sdr, mimaze applications
important to avoid constraining network mechanisms to support only one
to many applications
Bryan - lots of differences of opionion in the community.
Hugh - avoid overly commplicating things for futures applications
when we have existing applications that need support now.
jon crowcroft, ucl, www.cs.ucl.ac.uk/research/rama
--------------------------------------------------
Enhancing deering multicast, enhancing the addressing scheme.
class D address is a channel, not really an ip address.
Anonymously names a group of receivers, allows anyone to send to it.
alternatives, allow end systems to be explicit
DCM/connectionless multicast - add list of addresses,
transparency and fault tolerance
David Oran - Final Questions
----------------------------
we have 5 minutes, where should we go with this?
Brian Whetten - wishes had heard more from isps about problems.
TODO - decide which problems are of deployment and which are based
on what we are deploying.
Scott Petrak - 3 things: think about low bandwidth hosts at the end,
like wireless; thing 2 i missed; small number of senders a worthy
optimization.
Dorian Kim - deployment problems have been maturity of implementation issues
and how to make all the hacks play together. havent tried running native
multicast at scales we want. will find more answers as we deploy and ramp
up, at this point probably not worth limiting model.
Hum votes
create a mailing list 2/3 hum
no mailing list 1/3 hum
>From owner-rmt@listserv.lbl.gov Mon Aug 2 09:00:09 1999
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.0/8.9.0) id IAA23516;
Mon, 2 Aug 1999 08:59:46 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (localhost [127.0.0.1])
by listserv.lbl.gov (8.9.0/8.9.0) with ESMTP id IAA23512
for <rmt@listserv.lbl.gov>; Mon, 2 Aug 1999 08:59:43 -0700 (PDT)
Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id IAA01973
for <rmt@listserv.lbl.gov>; Mon, 2 Aug 1999 08:59:43 -0700 (PDT)
Received: from mailman.sprintlabs.com (mx.sprintlabs.com [208.30.174.2])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id IAA01965
for <rmt@lbl.gov>; Mon, 2 Aug 1999 08:59:41 -0700 (PDT)
Received: from sprintlabs.com (ip199-2-54-117.sprintlabs.com [199.2.54.117]) by mailman.sprintlabs.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0)
id P60ZAK1M; Mon, 2 Aug 1999 08:59:40 -0700
Message-ID: <37A5C07E.9482F819@sprintlabs.com>
Date: Mon, 02 Aug 1999 08:59:58 -0700
From: christophe diot <cdiot@sprintlabs.com>
Organization: SPRINT ATL
X-Mailer: Mozilla 4.05 [en] (Win95; I)
MIME-Version: 1.0
To: David Oran <oran@cisco.com>
CC: maddogs@ietf.org, idmr@cs.ucl.ac.uk, idr@merit.edu,
msdp@network-services.uoregon.edu, pim@catarina.usc.edu,
mboned@network-services.uoregon.edu, malloc@catarina.usc.edu,
rmt@lbl.gov
Subject: Re: Maestro BoF Results
References: <NBBBIFCAKKOPNMMKHHEFGEBGFFAA.oran@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-rmt@listserv.lbl.gov
Precedence: bulk
David Oran wrote:
>
> The Routing Area held a BoF at the Oslo IETF whose purpose was to discuss
> potential refinements to the IP multicast model in two areas:
> 1) Enhanced two-part multicast addressing to ease scalability and
> deployment
> headaches,
> 2) Optimizations to exploit the single-sender case
>
> The BoF announcement, along with its scope and agenda, may be found at:
> http://www.ietf.org/ietf/99jul/maestro-agenda-99jul.txt.
>
> I am sending this message to who I think are all the relevant WG mailing
> lists, and it will also be sent out via IETF-announce, so please let me know
> directly if I've missed a relevant group rather than risk clogging peoples'
> mailboxes with multiple forwards.
>
> The minutes of BoF are attached below. One of the conclusions from the BoF
> was to continue discussions on these subjects to ascertain if there is a
> critical mass of support to charter one or more Working Groups to pursue
> IETF standards (or other outputs) in these areas. We are therefore
> resurrecting a moribund Routing Area mailing list for this purpose:
> routing-discussion@ietf.org
> Subscription is via majordomo@ietf.org
>
> Thanks to all who participated in the BoF and in advance for useful
> low-flamability discussion on the mailing list.
>
> Regards, Dave Oran (routing co-area director)
>
> MAESTRO BOF, Dave Oran
> ----------------------
>
> AGENDA
>
> History - modify multicast model, do we need a working group
> on this?
>
> A number of people think if we simplify the multicast model
> there are significant benefits in reducing complexity.
> changes: addressing model, assume single sender.
>
> We want to look at the problems today and see how proposed
> simplications might help.
>
> Ground rules: talk about problems and how they map to the
> proposed simplifications. from two perspectives, isp's
> and architectural view.
>
> Bryan Lyles, Sprint Deployment Strategy
> ---------------------------------------
> Today, multicast enabled, working with vendors and customers to make
> it work. built on PIM-SM, MSDP, MBGP, IGMPV2, GLOP.
>
> Short Term - push current protocols, work in ietf to enhance base.
>
> Certain kinds of applications want single server (radio station,
> politician giving speech, dont want opposition heckling him)
If I remember well, this is not exactly what we said ...
What we "also" sayed is that we
encouter problems with providing stable and robust multicast service,
and that we are not really satisfied with the current protocol
architecture
and with its implementation (difficult to know if the architecture or
the implementation is broken).
The conslusion of the talk was that Sprint would like IETF to consider
a protocol architecture that would be stable, more simple, and more
scalable.
> Hugh Holbrook, Stanford/Cisco
> -----------------------------
> Some multicast applications work well with unicast
> others its impossible, high data rates, many receivers
> questions to isp's - how do you bill for it. make billing reflect
> cost. so charge by size of group.
>
> dmm - if i am a source, receivers on same isp are onnet,
> other receivers are offnet. want to billed for offnet folks.
>
> brad cain - bill by bandwidth, can isp's break even on multicast.
>
> Queries flow down tree, counts flow back up, somehow gather data
> to bill src. access control for large groups, restrict senders
> in advance (pirates on tv station), important for commercial
> applications too.
>
> kevin almeroth - why does it work with radia, lawyers are
> the answers, no one owns a multicast address, if they did
> you could sue someone for using yours without permission.
>
> security - source provides passwd to receivers
>
> www.dsg.stanford.edu/hollbrook/express
>
> Jeremy Hall, uunet
> ------------------
> Problems - scalability, single source model ok, hard to implement.
> you are trying to restrict something that is not restrictable.
> lots of protocols running as ships in the night, ok when it works,
> never know which one is not working correctly. way too much ad hoc
> stuff going on. which protocol is broken. nice to be able to trace
> a problem from the sender, to the receiver. receiver says i'm not
> receiving this content. have to figure out from that info, where
> the source is and what the problem is.
>
> Some applications hide the group, so you cant figure out where
> to troubleshoot. people dont understand how it works, so they
> cant help you debug. need education.
>
> Billing problems, counting receivers might be nice but is hard
> as groups get big. onnet vs offnet. tried to employ things
> that are parallel to unicast. unicast routing tries to dump traffic
> asap, mulitcast wants to keep as long as possible. current model
> doesnt scale. anyone can source to any group and thats a security
> problem. there are a lot of security issues with multicast.
>
> Mark Handley, ACIRI
> -------------------
> Internet Standard Multicast, where it came from and why it had
> nice properties. direct extension of the unicast model, host
> sends packets to destination address, it gets there. nice
> architecure, senders dont need to know about receivers.
> recievers dont need to know who senders are. distributed binding
> is useful resource. senders and receivers dont need to know about
> topology, robust, route around failures etc. hosts dont need to
> knows about routing protocool. need distinction between service
> model and its implementation in the network. separates what
> the application wants and how the network achieves it. clean
> separation of routing and transport/application layer.
>
> What can we do with it:
>
> Regular one to many applications - video distribution, data distribution
> many to many applications - conferening, games, dont know members in
> advance, distributed binding is very robust, changes the way you design
> applications (eg wb)
>
> Many to few applications - server discovery
>
> Scoping, used to have ttl scoping, poor for traffic engineering,
> great for self organizing applications, expanding ring search,
> we lost the ttl in pim, admin scoping getting it back, mzap
>
> Security - can only restrict traffic safely with encryption.
> content providers want authentication, have the mechanisms already.
>
> problems:
>
> forwarding table size, aggregation helps some;
> how can isp's make money;
> lack of scalable routing protocol, bgmp, hierarchical pim,
> bi-direction pim with grib, bgmp will probably work,
> hierarchical pim too;
> lack or good network management and diagnostic tools.
>
> serious growing pains, transition from dvmrp painful
>
> distributed binding a key - wb, sdr, mimaze applications
>
> important to avoid constraining network mechanisms to support only one
> to many applications
>
> Bryan - lots of differences of opionion in the community.
> Hugh - avoid overly commplicating things for futures applications
> when we have existing applications that need support now.
>
> jon crowcroft, ucl, www.cs.ucl.ac.uk/research/rama
> --------------------------------------------------
> Enhancing deering multicast, enhancing the addressing scheme.
> class D address is a channel, not really an ip address.
> Anonymously names a group of receivers, allows anyone to send to it.
> alternatives, allow end systems to be explicit
> DCM/connectionless multicast - add list of addresses,
> transparency and fault tolerance
>
> David Oran - Final Questions
> ----------------------------
> we have 5 minutes, where should we go with this?
>
> Brian Whetten - wishes had heard more from isps about problems.
>
> TODO - decide which problems are of deployment and which are based
> on what we are deploying.
>
> Scott Petrak - 3 things: think about low bandwidth hosts at the end,
> like wireless; thing 2 i missed; small number of senders a worthy
> optimization.
>
> Dorian Kim - deployment problems have been maturity of implementation issues
> and how to make all the hacks play together. havent tried running native
> multicast at scales we want. will find more answers as we deploy and ramp
> up, at this point probably not worth limiting model.
>
> Hum votes
> create a mailing list 2/3 hum
> no mailing list 1/3 hum
--
=======================================================
christophe Diot | tel: 1(650)375.4539
Sprint ATL | fax: 1(650)375.4490
1 Adrian Court | cdiot@sprintlabs.com
Burlingame CA 94010 | www.sprintlabs.com
USA |
>From owner-rmt@listserv.lbl.gov Mon Aug 16 05:20:44 1999
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id FAA24038;
Mon, 16 Aug 1999 05:18:34 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (root@postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id FAA24034
for <rmt@listserv.lbl.gov>; Mon, 16 Aug 1999 05:18:32 -0700 (PDT)
Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id FAA07377
for <rmt@listserv.lbl.gov>; Mon, 16 Aug 1999 05:18:32 -0700 (PDT)
Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5])
by SpamWall.lbl.gov (8.9.3/8.9.3) with SMTP id FAA07365
for <rmt@lbl.gov>; Mon, 16 Aug 1999 05:18:29 -0700 (PDT)
Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id LAA25813; Mon, 16 Aug 1999 11:39:43 +0200
From: Luigi Rizzo <luigi@labinfo.iet.unipi.it>
Message-Id: <199908160939.LAA25813@labinfo.iet.unipi.it>
Subject: New version of pgm source for FreeBSD
To: luigi@labinfo.iet.unipi.it (Luigi Rizzo)
Date: Mon, 16 Aug 1999 11:39:43 +0200 (MET DST)
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-rmt@lbl.gov
Precedence: bulk
[Bcc to rm, rmt and another pgm-related list to avoid spam as a result
of replies.]
As the subject says, there is a newer snapshot of my PGM code for
FreeBSD available from the usual URL
http://www.iet.unipi.it/~luigi/pgm.html
This one is much more complete and robust than the previous one, and
works on FreeBSD 3.x and 2.2.x .
cheers
luigi
-----------------------------------+-------------------------------------
Luigi RIZZO, luigi@iet.unipi.it . Dip. di Ing. dell'Informazione
http://www.iet.unipi.it/~luigi/ . Universita` di Pisa
TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy)
http://www.iet.unipi.it/~luigi/ngc99/
==== First International Workshop on Networked Group Communication ====
-----------------------------------+-------------------------------------
>From owner-rmt@listserv.lbl.gov Mon Sep 6 06:17:14 1999
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id GAA14077;
Mon, 6 Sep 1999 06:14:25 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (root@postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id GAA14073
for <rmt@listserv.lbl.gov>; Mon, 6 Sep 1999 06:14:23 -0700 (PDT)
Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id GAA17307
for <rmt@listserv.lbl.gov>; Mon, 6 Sep 1999 06:14:22 -0700 (PDT)
Received: from ccl.chungnam.ac.kr (ccl.chungnam.ac.kr [168.188.48.128])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id GAA17303
for <rmt@lbl.gov>; Mon, 6 Sep 1999 06:14:21 -0700 (PDT)
Received: from ccl.chungnam.ac.kr (ghil.chungnam.ac.kr [168.188.48.2])
by ccl.chungnam.ac.kr (8.9.0/8.9.0) with ESMTP id WAA00288
for <rmt@lbl.gov>; Mon, 6 Sep 1999 22:11:01 +1000 (KDT)
Message-ID: <37D3BE06.90C4179B@ccl.chungnam.ac.kr>
Date: Mon, 06 Sep 1999 22:13:42 +0900
From: Dae Young KIM <dykim@ccl.chungnam.ac.kr>
Organization: Chungnam Nat'l Univ., InfoCom Eng. Dept.
X-Mailer: Mozilla 4.61 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: rmt <rmt@lbl.gov>
Subject: Test
Content-Type: text/plain; charset=EUC-KR
Content-Transfer-Encoding: 7bit
Sender: owner-rmt@lbl.gov
Precedence: bulk
Sorry for this test mail. Just wanted to know why this mailing list
apparently seems to be dormant.
--
Dae Young
http://ccl.chungnam.ac.kr/~dykim/
>From owner-rmt@listserv.lbl.gov Wed Sep 8 21:53:28 1999
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id VAA22191;
Wed, 8 Sep 1999 21:49:41 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (root@postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id VAA22187
for <rmt@listserv.lbl.gov>; Wed, 8 Sep 1999 21:49:39 -0700 (PDT)
Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id VAA18950
for <rmt@listserv.lbl.gov>; Wed, 8 Sep 1999 21:49:38 -0700 (PDT)
Received: from fastmail.vertical.net (fastmail.vertical.net [146.145.74.44])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id VAA18946
for <rmt@LBL.GOV>; Wed, 8 Sep 1999 21:49:37 -0700 (PDT)
Date: Wed, 8 Sep 1999 21:49:37 -0700 (PDT)
Message-Id: <199909090449.VAA18946@SpamWall.lbl.gov>
Received: from fastmail (172.16.0.44) by fastmail.vertical.net (LSMTP for Windows NT v1.1b) with SMTP id <9.0002A90A@fastmail.vertical.net>; Thu, 9 Sep 1999 0:37:12 -0400
From: Computer OEM Online <newsletter@VERTICAL.NET>
Subject: Computer OEM Online Newsletter
To: rmt@lbl.gov
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"
Sender: owner-rmt@lbl.gov
Precedence: bulk
============================================================
Computer OEM Online Newsletter
Volume 2 Issue 46
Wednesday, September 08, 1999
============================================================
Computer OEM Online's System Strategy case study series continues. Frank Carau,
R&D Lab Manager at Hewlett-Packard's Portable Capture and Communications
facility, describes how code coverage and regression test analyses tools helped
his team speed a 500-000-gate ASIC to successful first-pass completion. Read
about it at http://www2.computeroemonline.com/read/nl19990907/10080.
******** NATIONAL SPONSOR ********
The 9.99% fixed Bank One Platinum Business Card Visa. No annual fee and up
to $25,000 line of credit. Track expenses, simplify tax reporting, and
streamline your finances. Apply online by visiting:
http://app1.firstusa.com/card.cfm/XPL6UBC13/6B3Z
******** Computer OEM Online^Òs Weekly Selection: ********
Advanced Routing of Electronic Modules A vision of the future in advanced
electronics by Michael Pecht, Yeun Tsun G.Wong
The rapid growth of the electronic products market has created an increasing
need for affordable, reliable, high-speed and high-density multi-layer printed
circuit boards (PCBs).
Our Price: $95.00! To read more and purchase this book, visit:
http://www2.computeroemonline.com/read/nl19990907/10138
****** FEATURED ARTICLES selected by Alex Mendelsohn ******
1) Digital Car Stereo DSP Chip Samples
2) Multiple Instruction-Set Technology Takes A Bow
3) Analog Devices Implements Intel Mobile Power Management
------------------------------------------------------------
1) Digital Car Stereo DSP Chip Samples
IC house STMicroelectronics starts sampling a 3 V mixed-signal DSP-based
baseband processor chip for all-digital car stereos. ST's programmable approach
lets you add features simply by changing firmware. Try that with your
conventional analog car stereo!
http://www2.computeroemonline.com/read/nl19990907/10003
2) Multiple Instruction-Set Technology Takes A Bow
As part of the Navy's Dual Use Science & Technology program sponsored by the
Office of Naval Research, CPU Technology, Inc. is developing a core processing
architecture it says will make possible upgraded high-end embedded systems. CPU
Tech will supply a system-on-a-chip that will work/run both legacy processors
and software without changes, and new higher-order languages and commercial off-
the-shelf software tools.
http://www2.computeroemonline.com/read/nl19990907/10004
3) Analog Devices Implements Intel Mobile Power Management
Chip makers Analog Devices releases the industry's first DC-to-DC converter to
incorporate Intel's Mobile Voltage Positioning technology.
http://www2.computeroemonline.com/read/nl19990907/10005
******** EDITOR'S CHOICE PRODUCTS ********
1) ZIF BGA Sockets
2) Display Driver ICs
3) LVT Logic
------------------------------------------------------------
1) ZIF BGA Sockets
Zero insertion force BGA sockets permit repeated tool-free removal and
insertion of ball-grid-array-packaged microprocessors.
http://www2.computeroemonline.com/read/nl19990907/10007
2) Display Driver ICs
Type CS1084, '85, and '86 driver ICs contain the circuitry needed to interface
between a system microprocessor and automotive Vacuum Fluorescent Display
instrumentation.
http://www2.computeroemonline.com/read/nl19990907/10008
3) LVT Logic
Designed for 3.3 V applications, logic line includes the 74LVTH273 octal D-type
flip-flop with Clear, the 74LVT373/74LVTH373 octal transparent latch with three-
state outputs, and the 74LVT374/74LVTH374 octal D-type with three-state
outputs. Available with and without Bus-hold, the high speed (less than 4.5
nanosecond) ICs can be used for off-board driving applications such as
backplanes, memory arrays, telecom switches, and in networking applications.
Bus-hold maintains a valid logic state on an unloaded input, eliminating the
need for external pull-up or pull-down resistors to prevent floating inputs.
http://www2.computeroemonline.com/read/nl19990907/10009
******** ADVERTISEMENT ********
The award winning My Lycos is the fast and easy-to-use start page -
providing you with personalized news, weather, stock quotes, horoscopes,
weather, sports scores and more. Try it now - http://my.lycos.com.
***** FEATURED COMPANIES (information from sponsors): ******
Visit the companies below for more industry news and product information:
Adapter Technologies Inc. was established in 1994 to provide interconnect
solutions to OEMs that required application specific products to produce their
end products. Working with fortune 100, 500 and 1000 companies world wide,
their products consist from small run to large run production quantities,
research and development products and high end electronic assemblies
encompassing surface mount technologies and thru hole technologies.
Visit Adapter Technologies Inc. at:
http://www2.computeroemonline.com/storefronts/adaptertech.html
NKK Switches provides comprehensive manufacturing, warehousing, and other sales
services from its USA headquarters in Scottsdale, Arizona. An extensive staff
of knowledgeable marketing and sales personnel is on call to provide technical
information as well as pricing and delivery schedules.
Visit NKK Switches at:
http://www2.computeroemonline.com/storefronts/nkk.html
Ziatech Corporation is a leading supplier of rugged CompactPCI® and STD 32®
industrial computers. They manufacture board-level, system-level, and fully
integrated microcomputer products for OEMs and end users seeking to automate
their applications quickly and cost effectively.
Visit Ziatech Corporation at:
http://www2.computeroemonline.com/storefronts/ziatech.html
Thanks for subscribing to Computer OEM Online's weekly newsletter. Tell your
friends and associates about it. Have questions, or suggestions? Call Managing
Editor Alex Mendelsohn at (207) 967-8812.
-------------------------------------------------------------------
If you enjoy reading Computer OEM Online's Newsletter, please tell a
friend or colleague about it. Anyone can sign up for a free
subscription on our Web site at http://www.computeroemonline.com
--------------------------------------------------------------------
If your company wishes to sponsor this newsletter, please
contact Sherylen Yoak at mailto:syoak@verticalnet.com to learn more.
==========================================================
If you wish to unsubscribe, please go to the following web page:
http://www2.computeroemonline.com/content/newsletter/unsubscribe.asp
==========================================================
The Computer OEM Online Homepage: http://www.computeroemonline.com
(c) Copyright 1999 VerticalNet, Inc. All rights reserved. All
product names contained herein are the trademarks of their
respective holders.
>From owner-rmt@listserv.lbl.gov Thu Sep 9 22:41:59 1999
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id WAA25300;
Thu, 9 Sep 1999 22:40:39 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (root@postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id WAA25296
for <rmt@listserv.lbl.gov>; Thu, 9 Sep 1999 22:40:37 -0700 (PDT)
Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id WAA20547
for <rmt@listserv.lbl.gov>; Thu, 9 Sep 1999 22:40:36 -0700 (PDT)
Received: from fastmail.vertical.net (fastmail.vertical.net [146.145.74.44])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id WAA20543
for <rmt@LBL.GOV>; Thu, 9 Sep 1999 22:40:35 -0700 (PDT)
Date: Thu, 9 Sep 1999 22:40:35 -0700 (PDT)
Message-Id: <199909100540.WAA20543@SpamWall.lbl.gov>
Received: from fastmail (172.16.0.44) by fastmail.vertical.net (LSMTP for Windows NT v1.1b) with SMTP id <6.00031636@fastmail.vertical.net>; Fri, 10 Sep 1999 1:28:06 -0400
From: Embedded Technology <newsletter@VERTICAL.NET>
Subject: Embedded Technology Newsletter
To: rmt@lbl.gov
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"
Sender: owner-rmt@lbl.gov
Precedence: bulk
============================================================
Embedded Technology.com Newsletter
Volume 1 Issue 18
Thursday, September 09, 1999
============================================================
******** NATIONAL SPONSOR ********
The 9.99% fixed Bank One Platinum Business Card Visa. No annual fee and up
to $25,000 line of credit. Track expenses, simplify tax reporting, and
streamline your finances. Apply online by visiting:
http://app1.firstusa.com/card.cfm/XPL6UBC13/6B3Z
******** Embedded Technology.com^Òs Weekly Selection: *******
A Practitioner's Guide to RISC Microprocessor Architecture by Patrick H. Stakem
An introduction to Reduced Instruction Set Microprocessors which is a subfield
of RISC.
Retail Price: $82.95 Our Price: $70.99! You Save: $11.96 (14%)
To read more and purchase this book, visit:
http://www2.embeddedtechnology.com/read/nl19990907/10141
****** FEATURED ARTICLES selected by Bruce Bennett *****
1) Uniform Device Driver Spec Ready for Implementation
2) SBS Develops K2 CPCI Board Targeting Telecom Applications
3) Fujitsu Mikrolektronik Restructures
------------------------------------------------------------
1) Uniform Device Driver Spec Ready for Implementation
Members of Project UDI today announced the release of the UDI (Uniform Driver
Interface) 1.0 Specification. This Specification is the culmination of a multi-
company development effort designed to provide device driver portability for
existing and future system configurations.
http://www2.embeddedtechnology.com/read/nl19990907/10054
2) SBS Develops K2 CPCI Board Targeting Telecom Applications
SBS Technologies, Inc. has announced the availability of K2, a 6U cPCI board
targeting high performance telecommunications applications requiring hot-swap,
system/non-system slot functionality, and versatile I/O with dual PMC slots.
http://www2.embeddedtechnology.com/read/nl19990907/10056
3) Fujitsu Mikrolektronik Restructures
Fujitsu Mikroelektronik GmbH in Dreieich-Buchschlag, Frankfurt, Germany has
announced that as part of a restructuring of its European operations, it will
now function as the European headquarters of Fujitsu Microelectronics Europe
GmbH. Known as Fujitsu Microelectronics Europe (FME), the company will combine
the activities of Marketing, Design Centres and Sales Offices in the UK,
Germany, France, Italy, Sweden.
http://www2.embeddedtechnology.com/read/nl19990907/10059
******** EDITOR'S CHOICE PRODUCTS ********
1) Multimedia PC
2) Emulator
3) I/O Solutions Guide
------------------------------------------------------------
1) Multimedia PC
The SBC-Media GX is an EBX-compliant board based on the MMX-enhanced 233-MHz
MediaGX processor. -- Arcom Control Systems, Kansas City, MO.
http://www2.embeddedtechnology.com/read/nl19990907/8882
2) Emulator
The USP-51A emulator with a POD32X2-60 fully emulates the TS80C32X2 device in
targets at the maximum clock speed of 64 MHz. -- Signum Systems, Moorpark, CA.
http://www2.embeddedtechnology.com/read/nl19990907/8884
3) I/O Solutions Guide
The company^Òs catalog features a range of VMEbus boards, PC cards and
IndustryPack mezzanine modules. The boards perform analog I/O, digital I/O and
serial communication functions. -- Acromag, Wixom, MI.
http://www2.embeddedtechnology.com/read/nl19990907/10050
******** ADVERTISEMENT ********
The award winning My Lycos is the fast and easy-to-use start page -
providing you with personalized news, weather, stock quotes, horoscopes,
weather, sports scores and more. Try it now - http://my.lycos.com.
****** FEATURED COMPANY (information from sponsors): ******
Visit the company below for more industry news and product information:
The Embedded Initiative is a partner program, created by Annasoft Systems in
1997, focused on providing ready-to-run Windows CE platform solutions. These
solutions consist of embedded PC hardware combined with Annasoft software that
enable OEM manufacturers of embedded and dedicated systems to run Windows CE
off-the-shelf, without adaptation or driver development, on a wide range of
commercially available single board computers and modules.
Visit Annasoft Systems at:
http://www2.embeddedtechnology.com/storefronts/embeddedinitiative.html
The Embedded Systems Conference in San Jose, CA is just two weeks away (Sept.
27 to Sept. 30). Be sure to watch for our extensive coverage of the event on
Embedded Technology.com.
-------------------------------------------------------------------
If you enjoy reading Embedded Technology's Newsletter, please tell a
friend or colleague about it. Anyone can sign up for a free
subscription on our Web site at http://www.embeddedtechnology.com
--------------------------------------------------------------------
If you're a company that wishes to sponsor this newsletter, please
contact Sherylen Yoak at mailto:syoak@verticalnet.com to learn more.
==========================================================
If you wish to unsubscribe, please go to the following web page:
http://www2.embeddedtechnology.com/content/newsletter/unsubscribe.asp
==========================================================
The Embedded Technology Homepage: http://www.embeddedtechnology.com
(c) Copyright 1999 VerticalNet, Inc. All rights reserved. All
product names contained herein are the trademarks of their
respective holders.
>From owner-rmt@listserv.lbl.gov Fri Sep 10 00:57:54 1999
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id AAA25385;
Fri, 10 Sep 1999 00:57:36 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (root@postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id AAA25381
for <rmt@listserv.lbl.gov>; Fri, 10 Sep 1999 00:57:34 -0700 (PDT)
Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id AAA02296
for <rmt@listserv.lbl.gov>; Fri, 10 Sep 1999 00:57:33 -0700 (PDT)
Received: from s2.smtp.oleane.net (s2.smtp.oleane.net [195.25.12.6])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id AAA02292
for <rmt@lbl.gov>; Fri, 10 Sep 1999 00:57:31 -0700 (PDT)
Received: from nec.oleane.com (dyn-1-1-253.Cor.dialup.oleane.fr [62.161.8.253]) by s2.smtp.oleane.net with SMTP id JAA36430 for <rmt@lbl.gov>; Fri, 10 Sep 1999 09:57:29 +0200 (CEST)
Message-ID: <00ad01befb62$49a269a0$0201a8c0@nec.oleane.com>
From: "Peter lewis" <peter.lewis@upperside.fr>
To: <rmt@lbl.gov>
Subject: QoS Summit
Date: Fri, 10 Sep 1999 09:58:36 +0200
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: owner-rmt@lbl.gov
Precedence: bulk
QoS Summit: key requirements for advanced applications running on future
networks. Technologies (MPLS, ATM, IntSev/DiffServ, Frame Relay).
Managing, policing, billing, charging QoS. The annual rendez-vous with
top senior specialists.
Paris, France, 16-19 November 1999
Please see details at the following web address:
http://www.upperside.fr/baqos.htm
Sorry to post this message on the list.
Thanks
>From owner-rmt@listserv.lbl.gov Tue Sep 14 09:53:32 1999
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id JAA06852;
Tue, 14 Sep 1999 09:51:43 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (root@postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id JAA06848
for <rmt@listserv.lbl.gov>; Tue, 14 Sep 1999 09:51:42 -0700 (PDT)
Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id JAA21255
for <rmt@listserv.lbl.gov>; Tue, 14 Sep 1999 09:51:36 -0700 (PDT)
Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5])
by SpamWall.lbl.gov (8.9.3/8.9.3) with SMTP id JAA21220
for <rmt@lbl.gov>; Tue, 14 Sep 1999 09:51:34 -0700 (PDT)
Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id QAA00911; Tue, 14 Sep 1999 16:02:30 +0200
From: Luigi Rizzo <luigi@labinfo.iet.unipi.it>
Message-Id: <199909141402.QAA00911@labinfo.iet.unipi.it>
Subject: NGC99 - Call for Posters and Participation
To: luigi@labinfo.iet.unipi.it (Luigi Rizzo)
Date: Tue, 14 Sep 1999 16:02:30 +0200 (MET DST)
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-rmt@lbl.gov
Precedence: bulk
[usual apologies for duplicates]
Just a reminder of upcoming deadlines for NGC99:
First International Workshop on Networked Group Communication
Pisa, 17-19 november 1999
http://www.iet.unipi.it/~luigi/ngc99/
Registrations are now open, as well as poster submissions:
Early registrations 5 october
Poster submissions 5 november
Tutorials and workshop 17-19 november
The Workshop, sponsored by Cisco, Microsoft Research and Motorola,
features:
* tutorials by Mostafa Ammar and Don Towsley, Mark Handley, Radia
Perlman;
* invited talks by Ken Birman, Bob Briscoe, Steve Deering, Christophe
Diot, Radia Perlman, Tony Speakman;
* 18 technical papers, and poster sessions;
all of this near the beautiful monuments and landscape of Tuscany.
Check the workshop's web pages http://www.iet.unipi.it/~luigi/ngc99/
for detailed info.
cheers
luigi rizzo
P.S. This msg is sent using Bcc to avoid spam on mailing lists
by people replying to the msg. To see where you got this msg from,
check the headers.
-----------------------------------+-------------------------------------
Luigi RIZZO, luigi@iet.unipi.it . Dip. di Ing. dell'Informazione
http://www.iet.unipi.it/~luigi/ . Universita` di Pisa
TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy)
http://www.iet.unipi.it/~luigi/ngc99/
==== First International Workshop on Networked Group Communication ====
-----------------------------------+-------------------------------------
>From owner-rmt@listserv.lbl.gov Mon Sep 20 09:36:18 1999
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id JAA27396;
Mon, 20 Sep 1999 09:34:56 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (root@postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id JAA27392
for <rmt@listserv.lbl.gov>; Mon, 20 Sep 1999 09:34:54 -0700 (PDT)
Received: from SpamWall.lbl.gov (root@localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id JAA05724
for <rmt@listserv.lbl.gov>; Mon, 20 Sep 1999 09:34:53 -0700 (PDT)
Received: from s2.smtp.oleane.net (s2.smtp.oleane.net [195.25.12.6])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id JAA05676
for <rmt@lbl.gov>; Mon, 20 Sep 1999 09:34:36 -0700 (PDT)
Received: from Dell (dyn-1-1-230.Cor.dialup.oleane.fr [62.161.8.230]) by s2.smtp.oleane.net with SMTP id SAA31040; Mon, 20 Sep 1999 18:11:58 +0200 (CEST)
Message-ID: <003701bf0382$f3a87ac0$0701a8c0@oleane.com>
From: "Peter Lewis" <peter.lewis@upperside.fr>
To: <Undisclosed-Recipient:@s2.smtp.oleane.net;>
Subject: Media Gateway Control 99 : Call for paper
Date: Mon, 20 Sep 1999 18:06:56 +0200
Organization: Upperside
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_002A_01BF0392.ECF8CC60"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-rmt@lbl.gov
Precedence: bulk
This is a multi-part message in MIME format.
------=_NextPart_000_002A_01BF0392.ECF8CC60
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Paris, France, 15-17 December 1999
Media Gateway Control 99 Conference.
MGCP, Megaco, H.248. How to assure convergence between IP and PSTN =
networks.
Technical challenges, trials, interoperability tests, normalization =
work.
Call for papers: www.upperside.fr/bamgc.htm
Thanks
------=_NextPart_000_002A_01BF0392.ECF8CC60
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2>Paris, France, 15-17 December 1999<BR><BR>Media =
Gateway=20
Control 99 Conference.<BR><BR>MGCP, Megaco, H.248. How to assure =
convergence=20
between IP and PSTN networks.<BR>Technical challenges, trials, =
interoperability=20
tests, normalization work.<BR><BR>Call for papers: <A=20
href=3D"http://www.upperside.fr/bamgc.htm">www.upperside.fr/bamgc.htm</A>=
<BR><BR>Thanks<BR></FONT></DIV>
<DIV> </DIV></BODY></HTML>
------=_NextPart_000_002A_01BF0392.ECF8CC60--
>From owner-rmt@listserv.lbl.gov Thu Sep 23 14:26:02 1999
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id OAA09543;
Thu, 23 Sep 1999 14:24:12 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id OAA09539
for <rmt@listserv.lbl.gov>; Thu, 23 Sep 1999 14:24:11 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id OAA02404
for <rmt@listserv.lbl.gov>; Thu, 23 Sep 1999 14:24:10 -0700 (PDT)
Received: from motgate2.mot.com (motgate2.mot.com [129.188.136.102])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id OAA02371
for <rmt@lbl.gov>; Thu, 23 Sep 1999 14:24:04 -0700 (PDT)
Received: [from pobox2.mot.com (pobox2.mot.com [129.188.137.195]) by motgate2.mot.com (MOT-motgate2 1.0) with ESMTP id QAA21715 for <rmt@lbl.gov>; Thu, 23 Sep 1999 16:23:52 -0500 (CDT)]
Received: [from superman.arc.corp.mot.com (superman.arc.corp.mot.com [217.1.10.18]) by pobox2.mot.com (MOT-pobox2 2.0) with SMTP id QAA25216 for <rmt@lbl.gov>; Thu, 23 Sep 1999 16:23:50 -0500 (CDT)]
Received: from arc.corp.mot.com (t_il01_d_slip13.corp.mot.com [199.2.172.91]) by superman.arc.corp.mot.com (8.6.12/8.6.12) with ESMTP id HAA01847 for <rmt@lbl.gov>; Fri, 24 Sep 1999 07:22:27 +1000
Message-ID: <37EA9ABB.BCC80FAE@arc.corp.mot.com>
Date: Fri, 24 Sep 1999 07:25:15 +1000
From: Roger Kermode <rkermode@arc.corp.mot.com>
Organization: Motorola Austrlian Research Centre
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: rmt-list <rmt@lbl.gov>
Subject: IETF/RMT call for action....
Content-Type: multipart/mixed;
boundary="------------7BA37A493A5E6C6957F17D22"
Sender: owner-rmt@lbl.gov
Precedence: bulk
This is a multi-part message in MIME format.
--------------7BA37A493A5E6C6957F17D22
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Dear RMT'ers,
the next IETF is nearly upon us we'd like to fill you in what's been
going on and also to ask for your participation.
1) We'd like to invite parties who are interested in writing internet
drafts on the building blocks, protocol instantiations, and Abstract
APIs identified in the building-blocks draft to contact the working
group co-chairs ASAP. N.B. the cutoff for drafts is Oct 22 so
be don't wait to respond to this message.
2) We're nearly done with revisions on the building blocks and
design space draft, expect to see new versions before the meeting.
3) The working group chairs have been working on a new charter which
we will send to this email list within the next week or so for comment.
We'd like to incorporate any feedback pretty quickly so we can have
the rechartering done before the next IETF meeting.
4) We have also identified the need for an additional draft that will
outline a series of guidelines for writing internet drafts on building
blocks, protocol instantiations (how to glue building blocks together
with additional functionality to create a implementable protocol),
and abstract APIs (how to map a specific API onto a protocol
instantiation)
Cheers,
Roger Kermode
Allison Mankin
Lorenzo Vicisano
--------------7BA37A493A5E6C6957F17D22
Content-Type: text/x-vcard; charset=us-ascii;
name="rkermode.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Roger Kermode
Content-Disposition: attachment;
filename="rkermode.vcf"
begin:vcard
n:Kermode;Roger
tel;cell:+61-408-212-284
tel;fax:+61-2-9666-0501
tel;work:+61-2-9666-0558
x-mozilla-html:FALSE
url:http://www.arc.corp.mot.com
org:Motorola Australian Research Centre;Scalable Commodity Internet Lab
version:2.1
email;internet:ark008@email.mot.com
title:Principal Research Engineer, Lab Manager
adr;quoted-printable:;;12 Lord St. Level 3=0D=0A=0D=0A;Botany;NSW;2019;Australia
x-mozilla-cpt:;-15680
fn:Roger Kermode
end:vcard
--------------7BA37A493A5E6C6957F17D22--
>From owner-rmt@listserv.lbl.gov Thu Sep 23 14:46:50 1999
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id OAA09556;
Thu, 23 Sep 1999 14:46:47 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id OAA09552
for <rmt@listserv.lbl.gov>; Thu, 23 Sep 1999 14:46:46 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id OAA09023
for <rmt@listserv.lbl.gov>; Thu, 23 Sep 1999 14:46:45 -0700 (PDT)
Received: from motgate.mot.com (motgate.mot.com [129.188.136.100])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id OAA08998
for <rmt@lbl.gov>; Thu, 23 Sep 1999 14:46:43 -0700 (PDT)
Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (MOT-motgate 1.0) with ESMTP id QAA09736 for <rmt@lbl.gov>; Thu, 23 Sep 1999 16:46:38 -0500 (CDT)]
Received: [from superman.arc.corp.mot.com (superman.arc.corp.mot.com [217.1.10.18]) by mothost.mot.com (MOT-mothost 2.0) with SMTP id QAA17362 for <rmt@lbl.gov>; Thu, 23 Sep 1999 16:46:35 -0500 (CDT)]
Received: from arc.corp.mot.com (t_il01_d_slip13.corp.mot.com [199.2.172.91]) by superman.arc.corp.mot.com (8.6.12/8.6.12) with ESMTP id HAA02118 for <rmt@lbl.gov>; Fri, 24 Sep 1999 07:45:14 +1000
Message-ID: <37EAA012.E3066662@arc.corp.mot.com>
Date: Fri, 24 Sep 1999 07:48:02 +1000
From: Roger Kermode <rkermode@arc.corp.mot.com>
Organization: Motorola Austrlian Research Centre
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: rmt-list <rmt@lbl.gov>
Subject: IETF RMT: Progress Update/Call for I-D authors...
Content-Type: multipart/mixed;
boundary="------------863D2EC52BC16F93483C5312"
Sender: owner-rmt@lbl.gov
Precedence: bulk
This is a multi-part message in MIME format.
--------------863D2EC52BC16F93483C5312
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Dear RMT'ers,
the next IETF is nearly upon us we'd like to fill you in what's been
going on and also to ask for your participation.
1) We'd like to invite parties who are interested in writing internet
drafts on the building blocks, protocol instantiations, and Abstract
APIs identified in the building-blocks draft to contact the working
group co-chairs ASAP. N.B. the cutoff for drafts is Oct 22 so
don't wait to respond to this message.
2) We're nearly done with revisions on the building blocks and
design space draft, expect to see new versions before the meeting.
3) The working group chairs have been working on a new charter which
we will send to this email list within the next week or so for comment.
We'd like to incorporate any feedback pretty quickly so we can have
the rechartering done before the next IETF meeting.
4) We have also identified the need for an additional draft that will
outline a series of guidelines for writing internet drafts on building
blocks, protocol instantiations (how to glue building blocks together
with additional functionality to create a implementable protocol),
and abstract APIs (how to map a specific API onto a protocol
instantiation)
Cheers,
Roger Kermode
Allison Mankin
Lorenzo Vicisano
--------------863D2EC52BC16F93483C5312
Content-Type: text/x-vcard; charset=us-ascii;
name="rkermode.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Roger Kermode
Content-Disposition: attachment;
filename="rkermode.vcf"
begin:vcard
n:Kermode;Roger
tel;cell:+61-408-212-284
tel;fax:+61-2-9666-0501
tel;work:+61-2-9666-0558
x-mozilla-html:FALSE
url:http://www.arc.corp.mot.com
org:Motorola Australian Research Centre;Scalable Commodity Internet Lab
version:2.1
email;internet:ark008@email.mot.com
title:Principal Research Engineer, Lab Manager
adr;quoted-printable:;;12 Lord St. Level 3=0D=0A=0D=0A;Botany;NSW;2019;Australia
x-mozilla-cpt:;-15680
fn:Roger Kermode
end:vcard
--------------863D2EC52BC16F93483C5312--
>From owner-rmt@listserv.lbl.gov Mon Oct 4 03:56:01 1999
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id DAA26064;
Mon, 4 Oct 1999 03:53:48 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id DAA26060
for <rmt@listserv.lbl.gov>; Mon, 4 Oct 1999 03:53:46 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id DAA28581
for <rmt@listserv.lbl.gov>; Mon, 4 Oct 1999 03:53:45 -0700 (PDT)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
by SpamWall.lbl.gov (8.9.3/8.9.3) with SMTP id DAA28578
for <rmt@lbl.gov>; Mon, 4 Oct 1999 03:53:44 -0700 (PDT)
Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP
id <g.19069-0@bells.cs.ucl.ac.uk>; Mon, 4 Oct 1999 11:53:16 +0100
To: David Oran <oran@cisco.com>
cc: maddogs <maddogs@ietf.org>, idmr <idmr@cs.ucl.ac.uk>, idr <idr@merit.edu>,
msdp <msdp@network-services.uoregon.edu>, pim <pim@catarina.usc.edu>,
mboned <mboned@network-services.uoregon.edu>,
malloc <malloc@catarina.usc.edu>, rmt <rmt@lbl.gov>
Subject: Re: Maestro BoF Results
In-reply-to: Your message of "Mon, 02 Aug 1999 11:17:41 EDT." <NBBBIFCAKKOPNMMKHHEFGEBGFFAA.oran@cisco.com>
Date: Mon, 04 Oct 1999 11:53:15 +0100
Message-ID: <11012.939034395@cs.ucl.ac.uk>
From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
Sender: owner-rmt@lbl.gov
Precedence: bulk
...
..."One of the conclusions from the BoF
was to continue discussions on these subjects to ascertain if there is a
critical mass of support to charter one or more Working Groups to pursue
IETF standards (or other outputs) in these areas. We are therefore
resurrecting a moribund Routing Area mailing list for this purpose:
routing-discussion@ietf.org"
so whats the conclusion vis-a-vis multicast discussion
(considering imminance of next/DC) ietf?
cheers
jon
(apols for multi-list hit, but some folks might have had a peripheral
but strong enough interest to want to know the outcome without seeing
the process)
>From owner-rmt@listserv.lbl.gov Sat Oct 9 04:39:38 1999
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id EAA21087;
Sat, 9 Oct 1999 04:38:03 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id EAA21083
for <rmt@listserv.lbl.gov>; Sat, 9 Oct 1999 04:38:01 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id EAA08757
for <rmt@listserv.lbl.gov>; Sat, 9 Oct 1999 04:37:59 -0700 (PDT)
Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5])
by SpamWall.lbl.gov (8.9.3/8.9.3) with SMTP id EAA08754
for <rmt@lbl.gov>; Sat, 9 Oct 1999 04:37:57 -0700 (PDT)
Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id NAA20491; Sat, 9 Oct 1999 13:41:53 +0100
From: Luigi Rizzo <luigi@labinfo.iet.unipi.it>
Message-Id: <199910091241.NAA20491@labinfo.iet.unipi.it>
Subject: Updated PGM source code (FreeBSD)
To: luigi@iet.unipi.it
Date: Sat, 9 Oct 1999 13:41:52 +0100 (MET)
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-rmt@lbl.gov
Precedence: bulk
[sent to a few lists/individuals with Bcc to avoid spam on return]
Dear all,
an updated version of our FreeBSD pgm code is available for download
at the usual place
http://www.iet.unipi.it/~luigi/pgm.html
this include several bug fixes to out mid-august version, and now
implements PGM options. A sample application (pgmtftp) also included.
The usual disclaimer and guarantees (none!) apply.
Successful usage or bug reports are solicited and welcome.
cheers
luigi
-----------------------------------+-------------------------------------
Luigi RIZZO, luigi@iet.unipi.it . Dip. di Ing. dell'Informazione
http://www.iet.unipi.it/~luigi/ . Universita` di Pisa
TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy)
http://www.iet.unipi.it/~luigi/ngc99/
==== First International Workshop on Networked Group Communication ====
-----------------------------------+-------------------------------------
>From owner-rmt@listserv.lbl.gov Fri Oct 15 05:37:23 1999
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id FAA20577;
Fri, 15 Oct 1999 05:35:34 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id FAA20573
for <rmt@listserv.lbl.gov>; Fri, 15 Oct 1999 05:35:32 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id FAA02009
for <rmt@listserv.lbl.gov>; Fri, 15 Oct 1999 05:35:31 -0700 (PDT)
Received: from s2.smtp.oleane.net (s2.smtp.oleane.net [195.25.12.6])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id FAA02000
for <rmt@lbl.gov>; Fri, 15 Oct 1999 05:35:29 -0700 (PDT)
Received: from Dell (dyn-1-1-255.Cor.dialup.oleane.fr [62.161.8.255]) by s2.smtp.oleane.net with SMTP id OAA95005; Fri, 15 Oct 1999 14:35:02 +0200 (CEST)
Message-ID: <009c01bf1709$a9d953c0$0701a8c0@oleane.com>
From: "Peter Lewis" <peter.lewis@upperside.fr>
To: <Undisclosed-Recipient:@s2.smtp.oleane.net;>
Subject: Media Gateway Control Conference
Date: Fri, 15 Oct 1999 14:34:42 +0200
Organization: Upperside
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_0099_01BF171A.6B522F80"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-rmt@lbl.gov
Precedence: bulk
This is a multi-part message in MIME format.
------=_NextPart_000_0099_01BF171A.6B522F80
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MGCP, Megaco, H.248: performing seamless interoperation between IP and =
PSTN
networks. The international rendez-vous in Paris, 15-17 December 1999.
More infos:=20
http://www.upperside.fr/bamgc.htm
------=_NextPart_000_0099_01BF171A.6B522F80
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>
<DIV><FONT size=3D3>MGCP, Megaco, H.248: performing seamless =
interoperation=20
between IP and PSTN<BR>networks. The international rendez-vous in Paris, =
15-17=20
December 1999.<BR><BR>More infos: </FONT></DIV>
<DIV><FONT color=3D#800080 size=3D3><A=20
href=3D"http://www.upperside.fr/bamgc.htm">http://www.upperside.fr/bamgc.=
htm</A></FONT></DIV></DIV>
<DIV> </DIV></BODY></HTML>
------=_NextPart_000_0099_01BF171A.6B522F80--
>From owner-rmt@listserv.lbl.gov Mon Oct 18 14:26:10 1999
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id OAA29062;
Mon, 18 Oct 1999 14:24:20 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id OAA29058
for <rmt@listserv.lbl.gov>; Mon, 18 Oct 1999 14:24:18 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id OAA23867
for <rmt@listserv.lbl.gov>; Mon, 18 Oct 1999 14:24:17 -0700 (PDT)
Received: from baynet.baynetworks.com (ns1.BayNetworks.COM [134.177.3.20])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id OAA23842
for <rmt@lbl.gov>; Mon, 18 Oct 1999 14:24:06 -0700 (PDT)
Received: from mailhost.BayNetworks.COM (h016b.s86b1.BayNetworks.COM [134.177.1.107])
by baynet.baynetworks.com (8.9.1/8.9.1) with ESMTP id OAA27686
for <rmt@lbl.gov>; Mon, 18 Oct 1999 14:21:19 -0700 (PDT)
Received: from mailhost.corpeast.BayNetworks.COM (ns3.corpeast.baynetworks.com [132.245.135.91])
by mailhost.BayNetworks.COM (8.9.1/8.8.8) with ESMTP id OAA18228
for <rmt@lbl.gov>; Mon, 18 Oct 1999 14:20:45 -0700 (PDT)
Received: from bl-mail1.corpeast.BayNetworks.com (bl-mail1-hme0.corpeast.baynetworks.com [132.245.135.82])
by mailhost.corpeast.BayNetworks.COM (SMI-8.6/BNET-97/05/05-S) with SMTP
id RAA17098; Mon, 18 Oct 1999 17:21:53 -0400
for <rmt@lbl.gov>
Received: from thardjon ([47.72.241.57])
by bl-mail1.corpeast.BayNetworks.com (Post.Office MTA v3.5.1
release 219 ID# 0-51848U14000L14000S0V35) with SMTP id com
for <rmt@lbl.gov>; Mon, 18 Oct 1999 17:19:59 -0400
Message-Id: <3.0.32.19991018171506.0127d62c@ZBL6C002.corpeast.baynetworks.com>
X-Sender: thardjon@ZBL6C002.corpeast.baynetworks.com
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Mon, 18 Oct 1999 17:15:12 -0400
To: rmt@lbl.gov
From: Internet-Drafts@ietf.org (by way of Thomas Hardjono <thardjon@nortelnetworks.com>)
Subject: I-D ACTION:draft-irtf-smug-framework-00.txt
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-rmt@lbl.gov
Precedence: bulk
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Secure IP Multicast: Problem areas, Framework, and
Building Blocks
Author(s) : T. Hardjono, R. Canetti, M. Baugher, P. Dinsmore
Filename : draft-irtf-smug-framework-00.txt
Pages : 21
Date : 15-Oct-99
This document provides a foundation for the research work done as the
Secure Multicast Group (SMuG)of the IRTF. The document begins by
introducing a Reference Framework and problem areas, and proceeds to
identify functional building blocks for a secure multicast solution.
The identified building blocks, their definition and realization
will be the subject of future work of SmuG.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-irtf-smug-framework-00.txt
Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-irtf-smug-framework-00.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.
Send a message to:
mailserv@ietf.org.
In the body type:
"FILE /internet-drafts/draft-irtf-smug-framework-00.txt".
NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
<ftp://ftp.ietf.org/internet-drafts/draft-irtf-smug-framework-00.txt>
>From owner-rmt@listserv.lbl.gov Wed Oct 20 10:29:56 1999
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id KAA04712;
Wed, 20 Oct 1999 10:28:06 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id KAA04708
for <rmt@listserv.lbl.gov>; Wed, 20 Oct 1999 10:27:59 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id KAA29829
for <rmt@listserv.lbl.gov>; Wed, 20 Oct 1999 10:27:58 -0700 (PDT)
Received: from naur.csee.wvu.edu (naur.csee.wvu.edu [157.182.194.28])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id KAA29821
for <rmt@lbl.gov>; Wed, 20 Oct 1999 10:27:57 -0700 (PDT)
Received: from naur.csee.wvu.edu (naur.csee.wvu.edu [157.182.194.28])
by naur.csee.wvu.edu (8.9.0/8.9.0) with ESMTP id NAA01577;
Wed, 20 Oct 1999 13:25:54 -0400 (EDT)
Date: Wed, 20 Oct 1999 13:25:54 -0400 (EDT)
From: "Todd L. Montgomery" <todd@whitebarn.com>
X-Sender: tmont@naur.csee.wvu.edu
To: rm@mash.CS.Berkeley.EDU, rmt@lbl.gov
Subject: WhiteBarn PGM source code available
In-Reply-To: <380DED01.E83A19B5@whitebarn.com>
Message-ID: <Pine.GSO.4.10.9910201322040.18567-100000@naur.csee.wvu.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-rmt@lbl.gov
Precedence: bulk
I apologize to those on both the RMRG and RMT mailing lists.
You will get two copies of this.... I wanted to make sure
this made it to those on the research and commercial side.
(I should note that WRMF is suitable for any protocol, but
we have done PGM right now.)
WhiteBarn, Inc. (http://www.whitebarn.com) is pleased to announce the
availability of the WhiteBarn Reliable Multicast Framework (WRMF) as
well as it's implementation of the Cisco PGM reliable multicast
protocol in source code form.
WhiteBarn is releasing this source under a community license, a free
for non-commercial use license, designed to spur the deployment and
expand the acceptance of reliable multicast applications and PGM.
WRMF-PGM currently supports several platforms:
- Windows 95 with Winsock 2
- Windows 98
- SCO UnixWare
- Linux 2.x.x (Red Hat, Debian, Slackware, Mandrake, etc.)
- Solaris 2.5+
- FreeBSD 3.x
WRMF-PGM is designed as a stand alone daemon that acts as a proxy
between a TCP stream and a PGM session. This allows developers to use
a stream abstraction for communication with the group and makes
porting existing TCP applications to PGM very simple. The design also
helps to isolate the elevated permissions that PGM must use to send
raw IP packets to just the daemon and not the whole application.
If you think WRMF-PGM might be something you can use, but are not
sure, feel free to send us email and we will be glad to answer any
questions.
The press release:
http://www.whitebarn.com/links/october20_99.html
WRMF-PGM source code:
http://www.whitebarn.com follow the 'Download PGM' link
Questions?
send email to pgm@whitebarn.com
Todd L. Montgomery
Whitebarn, Inc.
304-291-5972
todd@whitebarn.com
>From owner-rmt@listserv.lbl.gov Tue Oct 26 04:48:57 1999
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id EAA25737;
Tue, 26 Oct 1999 04:46:43 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id EAA25733
for <rmt@listserv.lbl.gov>; Tue, 26 Oct 1999 04:46:41 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id EAA18391
for <rmt@listserv.lbl.gov>; Tue, 26 Oct 1999 04:46:41 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id EAA18388
for <rmt@lbl.gov>; Tue, 26 Oct 1999 04:46:40 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02599;
Tue, 26 Oct 1999 07:46:36 -0400 (EDT)
Message-Id: <199910261146.HAA02599@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: rmt@lbl.gov
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-rmt-buildingblocks-01.txt
Date: Tue, 26 Oct 1999 07:46:36 -0400
Sender: owner-rmt@lbl.gov
Precedence: bulk
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Reliable Multicast Transport Working Group of the IETF.
Title : Reliable Multicast Transport Building Blocks for
One-to-Many Bulk-Data Transfer
Author(s) : B. Whetten, L. Vicisano, R. Kermode, M. Handley,
S. Floyd, M. Luby
Filename : draft-ietf-rmt-buildingblocks-01.txt
Pages : 21
Date : 25-Oct-99
This document describes a framework for the standardization of bulk-data
reliable multicast transport. It builds upon the experience gained
during the deployment of several classes of contemporary reliable
multicast transport, and attempts to pull out the commonalities between
these classes of protocols into a number of building blocks. To that
end, this document recommends that certain components that are common to
multiple protocol classes be standardized as 'building blocks.' The
remaining parts of the protocols, consisting of highly protocol
specific, tightly intertwined functions, shall be designated as
'protocol cores.' Thus, each protocol can then be constructed by
merging a 'protocol core' with a number of 'building blocks' which can
be re-used across multiple protocols.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rmt-buildingblocks-01.txt
Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-rmt-buildingblocks-01.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.
Send a message to:
mailserv@ietf.org.
In the body type:
"FILE /internet-drafts/draft-ietf-rmt-buildingblocks-01.txt".
NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv@ietf.org"
Content-Type: text/plain
Content-ID: <19991025151222.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-rmt-buildingblocks-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-rmt-buildingblocks-01.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19991025151222.I-D@ietf.org>
--OtherAccess--
--NextPart--
>From owner-rmt@listserv.lbl.gov Thu Oct 28 00:35:11 1999
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id AAA05038;
Thu, 28 Oct 1999 00:32:23 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from info.iet.unipi.it (info.iet.unipi.it [131.114.9.184])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id AAA05034
for <rmt@listserv.lbl.gov>; Thu, 28 Oct 1999 00:32:19 -0700 (PDT)
Received: (from luigi@localhost)
by info.iet.unipi.it (8.9.2/8.9.2) id JAA10201;
Thu, 28 Oct 1999 09:31:26 +0200 (CEST)
(envelope-from luigi)
From: Luigi Rizzo <luigi@info.iet.unipi.it>
Message-Id: <199910280731.JAA10201@info.iet.unipi.it>
Subject: NGC'99 Reminder
To: luigi@info.iet.unipi.it (Luigi Rizzo)
Date: Thu, 28 Oct 1999 09:31:26 +0200 (CEST)
X-Mailer: ELM [version 2.4ME+ PL43 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-rmt@lbl.gov
Precedence: bulk
[usual apologies for duplicates -- mailing lists are in Bcc to avoid
spam on reply - please pass this reminder to interested parties/lists]
A reminder that Nov. 5th (i.e. next week) is the deadline for poster
submissions for NGC'99,
First International Workshop on Networked Group Communication
Pisa, 17-20 november 1999
http://www.iet.unipi.it/~luigi/ngc99/
The workshop features 17 referred contributions and 2 poster
sessions. Leading experts in networking and group communications
will also contribute to the workshop with 4 invited talks, 2
keynotes, and 3 tutorials.
More info and details on the workshop are on the web page above.
IMPORTANT NOTE: attendance is exceeding our expectations, and
we might be forced to close registrations once we reach max capacity.
So if you intend to participate REGISTER SOON, and if you need to
register on-site PLEASE SEND A NOTE INFORMING OF YOUR INTENTIONS
to luigi@iet.unipi.it so we can tell you if room will still be
available.
cheers
luigi
-----------------------------------+-------------------------------------
Luigi RIZZO, luigi@iet.unipi.it . Dip. di Ing. dell'Informazione
http://www.iet.unipi.it/~luigi/ . Universita` di Pisa
TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy)
http://www.iet.unipi.it/~luigi/ngc99/
==== First International Workshop on Networked Group Communication ====
-----------------------------------+-------------------------------------
>From owner-rmt@listserv.lbl.gov Fri Oct 29 05:55:33 1999
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id FAA10985;
Fri, 29 Oct 1999 05:53:01 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id FAA10981
for <rmt@listserv.lbl.gov>; Fri, 29 Oct 1999 05:52:59 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id FAA29236
for <rmt@listserv.lbl.gov>; Fri, 29 Oct 1999 05:52:59 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id FAA29233
for <rmt@lbl.gov>; Fri, 29 Oct 1999 05:52:58 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22123;
Fri, 29 Oct 1999 08:52:55 -0400 (EDT)
Message-Id: <199910291252.IAA22123@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: rmt@lbl.gov
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-rmt-gra-arch-00.txt
Date: Fri, 29 Oct 1999 08:52:55 -0400
Sender: owner-rmt@lbl.gov
Precedence: bulk
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Reliable Multicast Transport Working Group of the IETF.
Title : Generic Router Assist (GRA) Building Block
Motivation and Architecture
Author(s) : B. Cain, T. Speakman, D. Towsley
Filename : draft-ietf-rmt-gra-arch-00.txt
Pages : 19
Date : 28-Oct-99
Generic Router Assist (GRA) is a network-based service that enables
end-to-end multicast transport protocols to take advantage of infor-
mation distributed across the network elements in a given multicast
distribution tree. The service consists of a canonical set of simple
functions which network elements may apply to selected packets in the
transport session as they traverse the distribution tree. The choice
of function and the packet parameters to which it is applied can be
defined and customized for a given transport session in a highly con-
trolled fashion that still permits enough flexibility for GRA to be
used to address a wide range of multicast transport problems not
amenable to end-to-end solution. This document provides the motiva-
tion and an architecture for GRA.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rmt-gra-arch-00.txt
Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-rmt-gra-arch-00.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.
Send a message to:
mailserv@ietf.org.
In the body type:
"FILE /internet-drafts/draft-ietf-rmt-gra-arch-00.txt".
NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv@ietf.org"
Content-Type: text/plain
Content-ID: <19991028142330.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-rmt-gra-arch-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-rmt-gra-arch-00.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <19991028142330.I-D@ietf.org>
--OtherAccess--
--NextPart--
>From owner-rmt@listserv.lbl.gov Sun Nov 7 11:24:20 1999
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id LAA26049;
Sun, 7 Nov 1999 11:21:05 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id LAA26045
for <rmt@listserv.lbl.gov>; Sun, 7 Nov 1999 11:21:02 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id LAA09002
for <rmt@listserv.lbl.gov>; Sun, 7 Nov 1999 11:21:01 -0800 (PST)
Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id LAA08994
for <rmt@lbl.gov>; Sun, 7 Nov 1999 11:21:01 -0800 (PST)
Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate2.mot.com (MOT-motgate2 1.0) with ESMTP id NAA04917 for <rmt@lbl.gov>; Sun, 7 Nov 1999 13:21:00 -0600 (CST)]
Received: [from homer.arc.corp.mot.com ([217.1.10.38]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id NAA09835 for <rmt@lbl.gov>; Sun, 7 Nov 1999 13:20:57 -0600 (CST)]
Received: from arc.corp.mot.com (t_il06_k_slip3.corp.mot.com [129.188.171.205])
by homer.arc.corp.mot.com (8.9.3/8.9.3) with ESMTP id GAA24068
for <rmt@lbl.gov>; Mon, 8 Nov 1999 06:20:12 +1100 (EST)
Message-ID: <3825D21F.EC144775@arc.corp.mot.com>
Date: Mon, 08 Nov 1999 06:25:19 +1100
From: Roger Kermode <rkermode@arc.corp.mot.com>
Reply-To: Roger.Kermode@motorola.com
Organization: Motorola
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: rmt-list <rmt@lbl.gov>
Subject: RMT Agenda, 46th IETF Washington
Content-Type: multipart/mixed;
boundary="------------D7E96917F903C1983F487296"
Sender: owner-rmt@lbl.gov
Precedence: bulk
This is a multi-part message in MIME format.
--------------D7E96917F903C1983F487296
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Dear RMT'ers,
Please accept our apologies for the tardiness of this
message. Below is the preliminary Agenda for the RMT
meeting on Thursday.
Please be prompt, note that as the Agenda is *very*
tight, we will be taking steps to ensure that we run
to time :)
Cheers,
Roger, Lorenzo, and Allison
RMT Agenda
Thursday, Novemeber 11 at 1300-1500
===================================
CHAIRS: Allison Mankin <mankin@isi.edu>
Roger Kermode <Roger.Kermode@motorola.com>
Lorenzo Vicisano <lorenzo@cisco.com>
Agenda Bashing: Roger Kermode [ 4 mins]
BB & DS Drafts Update: Roger Kermode [ 1 mins]
Guidelines Draft (NEW): Allison Mankin [15 mins]
Congestion Control Update: Mark Handley [ 5 mins]
Security Requirements: Thomas Hardjono [10 mins]
Generic Router Assist: Tony Speakman/Brad Cain [20 mins]
Leg Stretch, Brain Cramp Removal, Carpal Tunnel Break [ 5 mins]
Protocol 1 - NACK: Joe Macker [20 mins]
Protocol 2 - TRACK: Brian Whetten [15 Mins]
Protocol 3 - Open Loop: Mike Luby [10 mins]
Recharter/Discussion/Next Steps: Roger Kermode [15 mins]
--------------D7E96917F903C1983F487296
Content-Type: text/x-vcard; charset=us-ascii;
name="rkermode.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Roger Kermode
Content-Disposition: attachment;
filename="rkermode.vcf"
begin:vcard
n:Kermode;Roger
tel;fax:+61-2-9666-0501
tel;home:+61-2-9664-8335
tel;work:+61-2-9666-0558
x-mozilla-html:FALSE
url:www.mot.com.au
org:Motorola Australian Research Centre;Scalable Commodity Internet Lab
version:2.1
email;internet:Roger.Kermode@motorola.com
title:Principal Research Engineer
adr;quoted-printable:;;Level 3,=0D=0A12 Lord St.;Botany;NSW;2019;Australia
x-mozilla-cpt:;-1
fn:Roger Kermode
end:vcard
--------------D7E96917F903C1983F487296--
>From owner-rmt@listserv.lbl.gov Mon Nov 22 02:40:05 1999
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id CAA13115;
Mon, 22 Nov 1999 02:37:55 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id CAA13111
for <rmt@listserv.lbl.gov>; Mon, 22 Nov 1999 02:37:54 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id CAA16569
for <rmt@listserv.lbl.gov>; Mon, 22 Nov 1999 02:37:53 -0800 (PST)
Received: from post.netchina.com.cn ([202.94.1.48])
by SpamWall.lbl.gov (8.9.3/8.9.3) with SMTP id CAA16566
for <rmt@lbl.gov>; Mon, 22 Nov 1999 02:37:50 -0800 (PST)
Received: (qmail 21905 invoked from network); 22 Nov 1999 10:31:55 -0000
Received: from ppp227.netchina.com.cn (HELO netchina.com.cn) (202.94.2.227)
by 202.94.1.48 with SMTP; 22 Nov 1999 10:31:55 -0000
Message-ID: <38391AC8.2CD00EB9@netchina.com.cn>
Date: Mon, 22 Nov 1999 18:28:26 +0800
From: Robert Tan <tjsh@netchina.com.cn>
Reply-To: tjsh@netchina.com.cn
Organization: Tan Junsheng
X-Mailer: Mozilla 4.7 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: rmt@lbl.gov
Subject: The title: Flash Bandwidth 1KHz to 100MHz
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-rmt@lbl.gov
Precedence: bulk
The title: Flash Bandwidth 1KHz to 100MHz
Digital Controlled Broadband
Anti-alias & Reconstruction Filter
Dear Sir: This is my discussion article.
The details:
http://www.cnindex.net/~tjsh/Base_of_Broadband_Access.html
http://www.cnindex.net/~tjsh/Base_of_Broadband_Access.doc
Sincerely,
Robert Tan
11.22
Flash Bandwidth 1KHz to 100MHz
Digital Controlled Broadband
Anti-alias & Reconstruction Filter
The Next Era Web of Multimedia Data-stream
Transmission Solution of the Internet!
By Robert Tan
Update: 1999. 11. 22
For the many more format and definite of standard of digital film and
video, digital audio
and the other multimedia data stream of tomorrow, the existing network
technology including
the modern internet webs will be fabulous and difficult to transmit it
for us. The Endpoint
Congestion almost resistant our viewer area full of the entire world, We
would need the
straightway link of the multi-media data-stream in real-time for us.
Would you like to get a lower cost & more effective digital signal
channel in a wide-bandwidth
or broadband hybrid coax cable system? For the FTTX, HFC networks,
especially in the HFC
networks with the 256QAM or 64VSB digital modulation technology systems,
the SSB-ASK or the
VSB-ASK technology transmission systems would be used normally. The
Flash Bandwidth 1KHZ to
100MHz digital control a variable frequency bandwidth, it is
high-performance anti-alias &
reconstruction (FBW) filter, it will be able to provide a variable
multiplex sub-frequency
band in any broadband HFC system. With the FDM assistant digital carry
system and SSB or VSB
signal channel, a group of FBW filters will provide separate
multi-frequency bands in spectrum
without any cross talking and distortion by a large frequency range in a
high-speed high-
effective transmission system. In a FTTX or HFC web, this digital
controlled signal channel
would have a very large frequency spectrum changed dynamic range. For a
large client group,
such as the Broadband Cable Internet Access or HFC users, one of them
would like to get a
variable data speed according to the applications of his needed. It will
provide a lot of
digital control frequency bandwidth which is separated one another in
HFC transmission system,
and it will more effective for the "hot clients", such as the VOD video
clients or the other
high-code rate users and high-speed data stream user's applications. The
FBW will improve the
speed of the data stream, diminish the amount of the spare resource
seizing of "Cool Clients",
reduce the calculations of the DSP processor of the center web main
switching system and the
branch switching system. Reduce the CPU utilities of the applications in
all of client
communication adapter and its cost of produce is very important. The
"Cool Clients" mains
the IP telephone users or the other lower speed code rate audio
applications. Anyway, the
speed of the up-stream data and down-stream data speed could be changed
to any value you
needed, and the changing degree will be very smoothly and very simply in
writing one or
two bytes in the command system of communication web switcher. By the
high-speed frequency
variable characteristic, if the FBW filter were used in your FTTX or HFC
switching system,
the upward and downward data stream speed could be managed and attempted
by your command
system. So that, the transmission bandwidth will be able to adjusted to
your needed in any
time within one millionth second. The real-time will be very more
improved and more effective
on the communication main roads such as FTTX and HFC system,
transmission controlling system
will completely control the data stream in real-time.
Dear Technology Research and Development Administrator:
I am an electronic engineer in the field of Analog and Digital
filters researching and
designing. I had been a DSP engineer for ten years. My development field
is electronic circuits
-- digital and analog hardware designing and researching in applications
of Digital Signal
Processing. My works contains the frequency spectrum analysis, digital
audio and digital video
systems, noise spectrum controlling and processing, and the other
military applications. I have
researched and designed several kind of analog and digital anti-alias &
reconstruction filters.
A few years before, in my R&D works, I find the special frequency of the
filters is usually
fixed, it could be very difficult to change the cutoff frequency of the
low-pass anti-alias
& reconstruction filter. But the fixed filter could not suit the target
of my technical
applications. If we want to get several special frequency of the
filters, we must to use
several different fixed filters or instead of fixed filter with
switching capacity filter
or digital filter, such as IIR or FIR filter, and their frequency must
be variable in order
to change the analysis frequency. It is very important for the spectrum
analysis system and
the digital random real time vibrated controlling system. But, in this
way, we must pay for
digital IIR or FIR filter, it is very expensive in the price, take a
large space for the DSP
chips and its outside memory banks to install it. So, we would get into
much troubles and
complex questions from a simple problem.
However, we have the switching capacity technologies, and the product of
up to 8th order
filters is a very normally used. But the switching capacity filter will
have a high noise
and low frequency range, and it has a non-exactly special frequency,
generally. The special
frequency of most of the switching capacity filters is from 1/95 to
1/105 times of its main
switching clock and it is difficult to improve its accuracy. Actually,
the switching capacity
filter circuit is very difficult to adjust and use in applications.
Anywise, its order is
normally below 8th order, and the special frequency and bandwidth of the
switching capacity
filters is below to 50KHz, and the amplitude response is not exactly
yet, the dynamic range
of the amplitude is very low, normally, it is below the 48dB. Except of
frequency range from
0 to 50Hz, in this field, its dynamic range is lower than 30 dB and not
usefully, it is
normally being used in the speech processing circuit and the other lower
frequency band
processing systems. Attention, all of this analysis is not including the
phase noise of the
main switching clock and the noise of clock feed through yet. The
others, it is difficult to
get much more analysis frequency bands or special frequency points for
the switching capacity
filters, it is especially for the higher frequency band which is
approached to the top
frequency point. All of these characteristics of the switching capacity
filters will restrict
its applications in the area of modern digital communications.
The others method of the filters designing is the contact-time analog
filter .I have found
some method. It could make many transfer functions. Such as the
elliptical function,
Chebyshev function and Butterworth function, but there is some
interesting things here,
it is that the same circuit frame could be built into many transfer
functions, and it
would have programmable (digital controlled) special frequency. Changing
special frequency
on line is available. It could get the very wide frequency range, very
quickly to change
the used band, and the digital controlled circuit is very directly and
simply, the special
frequency step is very smoothly (because the Frequency is controlled by
long bit Digital
multiplier). In that points, integrate the FBW filter circuit technology
is very useful
for the digital controlling and processing systems. Because of the
Digital Controlling
Flash Bandwidth Filer (FBW) is depend on a few chips of high quality 8
or 12 bits long
Digital Multiplier and a few chips of high-speed amplifiers. The other,
this filter
technology is used with a few exactitude resistors and exactitude
capacitors also. For
example, an 8th order elliptical filter need 8chips of dual Digital
Multiplier and several
chips high bandwidth amplifiers, 8chips exactitude capacitors and
several chips exactitude
resisters. If it is possible, integrating all the Digital Multiplier and
amplifiers into
one chip or one plastic package (mixed circuit), place all the
exactitude resistors and
capacitors out of the package. It will be finest filter and very easy to
used and could
be re-designed agilely by the customers and the OEMs. The parameter of
the filters is
depending on the value of the resistors and the capacitors. Its value
could be designed
by the customs freely and calculated by constant functions directly, and
that is very
simply.
And then, the FBW filters would be very usefully in the FTTX or HFC
networks. For working
with the 256QAM or 64VSB modulation technology and any narrow-band
transmission technology
systems, such as the Broadband Cable Internet Access webs, HDTV or SDTV
and VOD systems, it
would compress the used frequency bandwidth in mostly extent. Because of
the WAN systems in
any nations will be depending on the "Tree structures" as the main road
in the webs in the
future. The frequency source is very expensive in this web, It would be
welcomed in the
Internet web digital information transmission, exchanging and switching
technology area,
DSP area and digital communications area, such as MAN and WAN coax cable
webs or the FTTX
system applications. Any way, the most of modern networking transmission
mode is TDM. It
is very suitable for the text material or media, because of it is a
fixed media in size,
and it is the fixed continue time in length and generation procedure.
But the most of
multimedia is not to be suitable with that. The data stream of voice and
video will have
no constant size to be forecasted has no constant procedure time. It is
only have a constant
and fixed bandwidth of media data stream. Because of your interesting
points is onto the
generations and the procedures of the video or audio information of thus
material or the
news, such as the high quality digital cinema, digital musicale and so
on. Certainly, you
could take the any multimedia information and any moving picture on you
desktop through the
Internet Web. It will be appeared the true alive world with you in any
site you can go! So
that, the only one of best way of the media data streams transmission
and exchanging is the
FDM mode with the SSB-ASK or VSB-ASK technology, it should be working
with the QAM or
VSB- ASK digital modulation technology in the future Internet webs.
FBW filter would be used in most of switchers and routers, which is
depending on the FDM
technologies. For the cable TV systems STB (set top box), video & audio
servers in Broadband
Cable Internet Access, cable modems or the client-end adapters in the
most of family users
and the most of business cable users in the world will need a very great
deal of broadband
web transmission bandwidth. Because of that, in any modern
home-electronic equipment, such
as the Internet officers, shopping's and the VOD or the other broadband
information
electronics, its using method would be depending on the FDM switching
technologies. So that,
the "Online Home-Electronics" or the other Internet accessing products
which is used in
people's homes would be simply to operate and easy to use. And it must
be depend on the
simply low-layer hardware equipment and protocols of the webs, such as
the VOD systems
and the STB terminals in the Broadband Cable Internet Access or HFC
networks. The FBW
technology would provide us more applicable and useable method in the
physics layer of
the public HFC networks, its FDM applications in a broadband web get us
in a lower building
price, more effective than the other technology. Such as the Broadband
Cable Internet Access
webs, HFC networks, FTTX networks, and the other and the other WAN
public broadband networks
would have a very great applications of the FBW filters.
The others, using a Flash-Band-width filter will help you get in to a
fully data stream
bandwidth management of any expensive data-link channels and the very
expensive communication
data stream bandwidth, such as the communication data-link of the
satellite communication
systems, and the ocean bottom communication systems. FBW filter will
control the any leased
data-stream bandwidth in dynamic mode within a very large frequency
range, a large range of
signal frequency bandwidth and data-stream speed in any time for a
communication administration
and operation system. It will change the bandwidth with you leased data
stream very imminently
within several microsecond, improve your expensive bandwidth of
data-stream transmission channel,
save your leased payment and money cost for any customers of digital
communications and any
Tele-communication operating and service company. It will hold any
important transmission of
data-stream in smoothly and take it freely. So, in this system, any
interrupt of your
communication data stream will be never.
The Digital Control Flash Bandwidth Filter specifications:
(1) General details:
Frequency range: 0.1Hz--100MHz
Useable frequency range: 0.1Hz--100MHz(at least)
Special frequency step: 0.001Hz-1000KHz
Transfer functions: Elliptical, Butterworth, Chebyshev, and Bassel
function.
And the others contacted-time filters.
Available filter type: Low-pass filter, High-pass filter, Notch filter,
Band-pass filter and All-pass filter.
Noise Level: -160dB(max) (Only depend on the number of the used
amplifiers.)
Order range: 2nd--12th(Depend on the sensitivity of the transfer
functions.)
Filter switching time: Less than 300nS (Filter Setting time is 200nS)
Useful Range: Anti-alias filters, Reconstruction filters.
(2) Pass Band Specifications:
Frequency selectable range: 100Hz--100MHz
(Depend on the performance of the selected amplifiers)
Special Frequency steps: 1Hz-1000KHz
Pass band Dynamic range: 90dB (Depend on the amplifiers and the order of
the filter.)
Ripple: 0.01--1.0dB (Only depend on the filter function and the
passband ripple designed.)
(3) Pass to Stop Band:
Drop speed of Interim-band Cut-off:
180db/oct (8th order elliptical function with 0.05dB pass-band ripple)
(4) Stop Band:
Amplitude min drop: 120db(8th elliptical filter for example)
Frequency range: 0.1Hz--100MHz
(Depend on the amplifiers and the Digital Multiplier specifications)
(5) Digital Control specifications:
Digital component is used (8 bit, 10bit, 12bit, and 16bit is available).
The special frequency is (N1/N2) * Frequency (ref).
(The N1, N2 is the Digital component input byte, from 8bit to 16 bit.)
The Frequency (ref) is form 10Hz to 10MHz.
(This parameter is depends on one RC time constant.)
High speed and voltage feedback high-bandwidth operation amplifiers are
required.
(6) Requirement: (The filter section of 8th order)
Digital component: 8 chips (Selections depend on the frequency range)
High-performance Amplifiers: 12 to 24 chips (Selections depend on the
frequency)
Capacitors or inductors: 8 chips (exactitude degree value is 1% to
0.1%)
Resistors: 16-36 chips (exactitude degree value is 1% to 0.1%)
(7) Group delay: Depend on the function of the filter
designed, filter
phase response designed, and the filter
order.
(8) Filter switching time: Less than 300nS (Filter Setting time is
200nS)
The Comparisons of the 4 kinds active Filters
For example:
8th order filter
Switching Capacity Filter
Digital Filter
(FIR or IIR Filter)
Traditional
Fixed Analog Frequency Filter
Digital controlling FBW filter
Noise Level or (THD+N) Value:
Highest
-48db
Lower
-70db
Very Low
-160db
Very Low
-120db
Filter Dynamic Range
The Value:
Little
50db
Middle
70db
Very Large
160db
Large
100db
Real-time active frequency
The range of the value:
Narrow
200Hz to 300KHz
Wide
0.001Hz to 50KHz
Very Wide
0.1Hz to 1MHz
Very wide
0.001Hz to 100MHz
The Outside in advance Anti-alias & Reconstruction assistant filter
requirement
The degree of assistant filter Quality
Required
2nd to 4th order anti-alias & reconstruction assistant outside filter
Required
4th to 6th order anti-alias & reconstruction assistant outside filter
Not required.
----------
Not required
----------
The Precision of the special frequency:
The ability of on-line changing the filter special frequency
&Method
Low.
+/-3%
Very easy
(Changing the switching clock)
High
+/-3%
Very difficult
(Change a new programs and
parameters )
Very high
0.1%
Very difficult.
(Changing the system time
constant)
Very high
0.1%
Easy(Writing digital word to the filter control port)
The complex degree of the filter system designing
&The used space
Simple
Small
Very complex
Very large
Simple
Middle
Middle
Middle
The price for produce a filter
&The difficult degree of the applications
Very low
$10~50
Easy
Very high
$300~600
Difficult
Low
$30~90
Easy
Middle
$50~100
Middle
Anti-alias & Reconstruction filter Performance: (1)Pass Band
Ripple &Dynamic Range:
(2)Stop Band
Rejection
(3)Interim Band Dropping Slope:
Low Quality & Low Price.
+/-0.2db
50db
55db
50db/oct
Normal or High Quality & High price
+/-0.01db
70db
70db
130db/oct
Normal Quality & Low Price
+/-0.01db
120db
120db
180db/oct
High Quality & & Middle Price.
+/-0.01db
110db
120db
180db/oct
Online/offline Changing of highest/lowest special frequency rate &
Range:
&changing time:
All available
1000 times
300Hz to 300KHz
10mS(Time of PLL tracking & locked)
Offline available
Not available
Not available
Not available
(Reboot DSP & A/D system)
Offline available
1000 times
Not available
Not available
All available
100000 times
1KHz to 100MHz
160nS (TTL 2 bytes writing time)
Filter online reconstruction setting time (The total time of
filter frequency switched)
10mS
Not available
Not available
300nS
Group delay and the phase response:
Producer design only.
Linear or Producer design only.
Producer design only.
Producer & User design is available.
Equality data stream speed or comported speed of its TxDAC :
&Butterworth 8th filter
(Broadband channel HFC usable signal dynamic range is about 50dB):
4.8Kbps to 4.8Mbps
(600SPS to 600KSPS)
8bit TxDAC
Constant 400Kbps
(50KSPS)
8bit TxDAC
Constant 800Mbps
(100MSPS)
8bit TxDAC
16Kbps to 1600Mbps
(2KSPS to 200MSPS)
8bit TxDAC
Suitable with the 8bit TxDAC and used 256QAM (or 64VSB) in SSB/VSB mode
of technology
(Data speed of Base Band):
Carrier signal RF full-band tie up:
Difficult to be used with the 256QAM and 64VSB.
(High Level Phase Noise)
4.8Kbps(Min)
4.8Mbps(Max)
384Hz to 384KHz
Difficult to be used in variable data-speed transmission or receiving
system
Difficult to be used in variable data-speed transmission or receiving
system
With 256QAM:
8Kbps(Min)
800Mbps
(Max)
With 64VSB:
12Kbps(Min)
1200Mbps (Max).
1.28KHz to 128MHz
For the HFC Specialty signal TV Channel:
40dB Eb/N
6MHz Full-band 64VSB model
@1KHz-6MHz
Data-rate:
With 64VSB:
9.375Kbps
(Min)
56.25Mbps
(Max)
Contact Address:
No.2 Buliding Room1007,
Mudanyuan Beili, Haidian District
Beijing P. R. China,
Post Code: 100083
Name: Tan Junsheng (Robert Tan)
Tele: 8610-82076834, 86-13701070213(Mobile)
E-mail: Tjsh@netchina.com.cn or tanjun@hotmail.com
Homepage: http://www.cnindex.net/~tjsh
Details Remind:
http://www.cnindex.net/~tjsh/Base_of_Broadband_Access.html
>From owner-rmt@listserv.lbl.gov Mon Dec 6 02:13:09 1999
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id CAA06580;
Mon, 6 Dec 1999 02:08:05 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id CAA06576
for <rmt@listserv.lbl.gov>; Mon, 6 Dec 1999 02:08:04 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id CAA11687
for <rmt@listserv.lbl.gov>; Mon, 6 Dec 1999 02:08:03 -0800 (PST)
Received: from motgate.mot.com (motgate.mot.com [129.188.136.100])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id CAA11684
for <rmt@lbl.gov>; Mon, 6 Dec 1999 02:08:02 -0800 (PST)
Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate.mot.com (MOT-motgate 1.0) with ESMTP id DAA07766 for <rmt@lbl.gov>; Mon, 6 Dec 1999 03:07:58 -0700 (MST)]
Received: [from homer.arc.corp.mot.com ([217.1.10.38]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id DAA10814 for <rmt@lbl.gov>; Mon, 6 Dec 1999 03:07:56 -0700 (MST)]
Received: from arc.corp.mot.com (IDENT:rkermode@[217.1.71.205])
by homer.arc.corp.mot.com (8.9.3/8.9.3) with ESMTP id VAA09163
for <rmt@lbl.gov>; Mon, 6 Dec 1999 21:07:06 +1100 (EST)
Message-ID: <384B8B59.E3B1C1AB@arc.corp.mot.com>
Date: Mon, 06 Dec 1999 21:09:29 +1100
From: Roger Kermode <rkermode@arc.corp.mot.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.13 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: rmt@lbl.gov
Subject: RMT Future Progress.....
Content-Type: multipart/alternative;
boundary="------------E8E3F1738F8E4F1EA0F97937"
Sender: owner-rmt@lbl.gov
Precedence: bulk
--------------E8E3F1738F8E4F1EA0F97937
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Dear Everyone,
Thanks for your efforts so far. In discussions between the RMT chairs
and the Transport ADs after the RMT slot in Washington D.C., it was
decided that we need to accelerate our progress. To that we'd like
to propose two things:
1) Hold an all-day interim meeting in mid-february at least one month
before the Adelaide IETF.
It has been suggested that the west-coast of the US would be a good
place to hold the meeting. Possible venues could be Berkeley or
San Diego, what do people think?
2) Formation of teams to work on Building Block and Protocol
Instanitaions Drafts:
Below is a list of people (alphabetic order) who have expressed an
interest in working on the various drafts. We'd like to see the team
for each draft to solidify and for work to start in earnest for
presentation at the interim meeting.
ACTION: Let's use the list to start some discussion about
1) forming the teams to do the drafts and
2) whether people can attend the interim meeting in mid-feb
cheers,
Roger Kermode,
Allison Mankin,
Lorenzo Vicisano
Guidelines Draft
----------------
Roger Kermode
Allison Mankin
Lorenzo Vicisano
Building Blocks teams
---------------------
## Congestion Control (with RMRG)
Sally Flloyd
Mark Handley
## Generic Router Assist
Brad Cain,
Tony Speakman,
Don Towsley
## NACK
Brian Adamson
Joe Macker
## FEC
Jon Crowcroft?
Jim Gemmel
Mike Luby
Luigi Rizzo
Lorenzo Vicisano?
## Tree Building (with RMRG)
Dah Ming Chu
Roger Kermode
Brian Levine
Dave Thaler
Brian Whetten
Transport Protection
??
Protocol Instantiaions
----------------------
## NACK
Joe Macker
Brian Adamson
## TRACK
Brian Whetten
Dah Ming Chiu
## Open Loop FEC
Mike Luby
--------------E8E3F1738F8E4F1EA0F97937
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<tt>Dear Everyone,</tt><tt></tt>
<p><tt>Thanks for your efforts so far. In discussions between the RMT chairs</tt>
<br><tt>and the Transport ADs after the RMT slot in Washington D.C., it
was</tt>
<br><tt>decided that we need to accelerate our progress. To that we'd like</tt>
<br><tt>to propose two things:</tt>
<br><tt></tt> <tt></tt>
<p><tt>1) Hold an all-day interim meeting in mid-february at least one
month</tt>
<br><tt> before the Adelaide IETF.</tt><tt></tt>
<p><tt> It has been suggested that the west-coast of the US
would be a good</tt>
<br><tt> place to hold the meeting. Possible venues could be
Berkeley or</tt>
<br><tt> San Diego, what do people think?</tt><tt></tt>
<p><tt>2) Formation of teams to work on Building Block and Protocol</tt>
<br><tt> Instanitaions Drafts:</tt><tt></tt>
<p><tt> Below is a list of people (alphabetic order) who have
expressed an</tt>
<br><tt> interest in working on the various drafts. We'd like
to see the team</tt>
<br><tt> for each draft to solidify and for work to start in
earnest for</tt>
<br><tt> presentation at the interim meeting.</tt><tt></tt>
<p><tt>ACTION: Let's use the list to start some discussion about</tt>
<br><tt> 1) forming the teams to do the drafts and</tt>
<br><tt> 2) whether people can attend the interim meeting in mid-feb</tt><tt></tt>
<p><tt>cheers,</tt><tt></tt>
<p><tt>Roger Kermode,</tt>
<br><tt>Allison Mankin,</tt>
<br><tt>Lorenzo Vicisano</tt>
<br><tt></tt> <tt></tt>
<p><tt>Guidelines Draft</tt>
<br><tt>----------------</tt>
<br><tt>Roger Kermode</tt>
<br><tt>Allison Mankin</tt>
<br><tt>Lorenzo Vicisano</tt><tt></tt>
<p><tt>Building Blocks teams</tt>
<br><tt>---------------------</tt><tt></tt>
<p><tt>## Congestion Control (with RMRG)</tt>
<br><tt>Sally Flloyd</tt>
<br><tt>Mark Handley</tt><tt></tt>
<p><tt>## Generic Router Assist</tt>
<br><tt>Brad Cain,</tt>
<br><tt>Tony Speakman,</tt>
<br><tt>Don Towsley</tt><tt></tt>
<p><tt>## NACK</tt>
<br><tt>Brian Adamson</tt>
<br><tt>Joe Macker</tt><tt></tt>
<p><tt>## FEC</tt>
<br><tt>Jon Crowcroft?</tt>
<br><tt>Jim Gemmel</tt>
<br><tt>Mike Luby</tt>
<br><tt>Luigi Rizzo</tt>
<br><tt>Lorenzo Vicisano?</tt><tt></tt>
<p><tt>## Tree Building (with RMRG)</tt>
<br><tt>Dah Ming Chu</tt>
<br><tt>Roger Kermode</tt>
<br><tt>Brian Levine</tt>
<br><tt>Dave Thaler</tt>
<br><tt>Brian Whetten</tt><tt></tt>
<p><tt>Transport Protection</tt>
<br><tt>??</tt><tt></tt>
<p><tt>Protocol Instantiaions</tt>
<br><tt>----------------------</tt>
<br><tt>## NACK</tt>
<br><tt>Joe Macker</tt>
<br><tt>Brian Adamson</tt><tt></tt>
<p><tt>## TRACK</tt>
<br><tt>Brian Whetten</tt>
<br><tt>Dah Ming Chiu</tt><tt></tt>
<p><tt>## Open Loop FEC</tt>
<br><tt>Mike Luby</tt></html>
--------------E8E3F1738F8E4F1EA0F97937--
>From owner-rmt@listserv.lbl.gov Mon Dec 6 12:08:25 1999
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id MAA09564;
Mon, 6 Dec 1999 12:07:39 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id MAA09560
for <rmt@listserv.lbl.gov>; Mon, 6 Dec 1999 12:07:38 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id MAA06942
for <rmt@listserv.lbl.gov>; Mon, 6 Dec 1999 12:07:37 -0800 (PST)
Received: from phobos.talarian.com (mailhost.talarian.com [207.5.32.17])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id MAA06934
for <rmt@lbl.gov>; Mon, 6 Dec 1999 12:07:35 -0800 (PST)
Received: from tahoe ([10.3.9.43]) by phobos.talarian.com (8.9.0/8.9.0) with SMTP id MAA21305; Mon, 6 Dec 1999 12:07:06 -0800 (PST)
Message-Id: <4.1.19991206120017.01f08b90@mailhost.talarian.com>
X-Sender: whetten@pop3.concentric.net
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1
Date: Mon, 06 Dec 1999 12:07:54 -0800
To: Roger Kermode <rkermode@arc.corp.mot.com>, rmt@lbl.gov
From: Brian Whetten <whetten@talarian.com>
Subject: Re: RMT Future Progress.....
In-Reply-To: <384B8B59.E3B1C1AB@arc.corp.mot.com>
Mime-Version: 1.0
Content-Type: multipart/alternative;
boundary="=====================_4158739==_.ALT"
Sender: owner-rmt@lbl.gov
Precedence: bulk
--=====================_4158739==_.ALT
Content-Type: text/plain; charset="us-ascii"
Great to see the pointy stick out again. :)
I would also be happy to/like to participate in the congestion control BB. For
transport layer protection, I think Thomas Hardjorno has some interest in
helping with this, and he can probably point you to some others from the SMUG
community who have interest in helping on this as well.
Can I please make just one strong request for the February meeting, which is
that we schedule it in the next 2-3 weeksW. February 7-9 is the IP Multicast
Summit, here in the bay, so scheduling it for the 10th might work well for
people.
Brian
At 09:09 PM 12/6/1999 +1100, Roger Kermode wrote:
>
> Dear Everyone,
>
> Thanks for your efforts so far. In discussions between the RMT chairs
> and the Transport ADs after the RMT slot in Washington D.C., it was
> decided that we need to accelerate our progress. To that we'd like
> to propose two things:
>
>
> 1) Hold an all-day interim meeting in mid-february at least one month
> before the Adelaide IETF.
>
> It has been suggested that the west-coast of the US would be a good
> place to hold the meeting. Possible venues could be Berkeley or
> San Diego, what do people think?
>
> 2) Formation of teams to work on Building Block and Protocol
> Instanitaions Drafts:
>
> Below is a list of people (alphabetic order) who have expressed an
> interest in working on the various drafts. We'd like to see the team
> for each draft to solidify and for work to start in earnest for
> presentation at the interim meeting.
>
> ACTION: Let's use the list to start some discussion about
> 1) forming the teams to do the drafts and
> 2) whether people can attend the interim meeting in mid-feb
>
> cheers,
>
> Roger Kermode,
> Allison Mankin,
> Lorenzo Vicisano
>
>
> Guidelines Draft
> ----------------
> Roger Kermode
> Allison Mankin
> Lorenzo Vicisano
>
> Building Blocks teams
> ---------------------
>
> ## Congestion Control (with RMRG)
> Sally Flloyd
> Mark Handley
>
> ## Generic Router Assist
> Brad Cain,
> Tony Speakman,
> Don Towsley
>
> ## NACK
> Brian Adamson
> Joe Macker
>
> ## FEC
> Jon Crowcroft?
> Jim Gemmel
> Mike Luby
> Luigi Rizzo
> Lorenzo Vicisano?
>
> ## Tree Building (with RMRG)
> Dah Ming Chu
> Roger Kermode
> Brian Levine
> Dave Thaler
> Brian Whetten
>
> Transport Protection
> ??
>
> Protocol Instantiaions
> ----------------------
> ## NACK
> Joe Macker
> Brian Adamson
>
> ## TRACK
> Brian Whetten
> Dah Ming Chiu
>
> ## Open Loop FEC
> Mike Luby
--=====================_4158739==_.ALT
Content-Type: text/html; charset="us-ascii"
<html>
Great to see the pointy stick out again. :)<br>
<br>
I would also be happy to/like to participate in the congestion control
BB. For transport layer protection, I think Thomas Hardjorno has
some interest in helping with this, and he can probably point you to some
others from the SMUG community who have interest in helping on this as
well.<br>
<br>
Can I please make just one strong request for the February meeting, which
is that we schedule it in the next 2-3 weeksW. February 7-9 is the
IP Multicast Summit, here in the bay, so scheduling it for the 10th might
work well for people.<br>
<br>
Brian<br>
<br>
At 09:09 PM 12/6/1999 +1100, Roger Kermode wrote: <br>
<blockquote type=cite cite>Dear Everyone, <br>
<br>
Thanks for your efforts so far. In discussions between the RMT chairs
<br>
and the Transport ADs after the RMT slot in Washington D.C., it was
<br>
decided that we need to accelerate our progress. To that we'd like <br>
to propose two things: <br>
<br>
<br>
1) Hold an all-day interim meeting in mid-february at least one month
<br>
before the Adelaide IETF. <br>
<br>
It has been suggested that the west-coast of the US would be
a good <br>
place to hold the meeting. Possible venues could be Berkeley
or <br>
San Diego, what do people think? <br>
<br>
2) Formation of teams to work on Building Block and Protocol <br>
Instanitaions Drafts: <br>
<br>
Below is a list of people (alphabetic order) who have
expressed an <br>
interest in working on the various drafts. We'd like to see
the team <br>
for each draft to solidify and for work to start in earnest
for <br>
presentation at the interim meeting. <br>
<br>
ACTION: Let's use the list to start some discussion about <br>
1) forming the teams to do the drafts and <br>
2) whether people can attend the interim meeting in mid-feb <br>
<br>
cheers, <br>
<br>
Roger Kermode, <br>
Allison Mankin, <br>
Lorenzo Vicisano <br>
<br>
<br>
Guidelines Draft <br>
---------------- <br>
Roger Kermode <br>
Allison Mankin <br>
Lorenzo Vicisano <br>
<br>
Building Blocks teams <br>
--------------------- <br>
<br>
## Congestion Control (with RMRG) <br>
Sally Flloyd <br>
Mark Handley <br>
<br>
## Generic Router Assist <br>
Brad Cain, <br>
Tony Speakman, <br>
Don Towsley <br>
<br>
## NACK <br>
Brian Adamson <br>
Joe Macker <br>
<br>
## FEC <br>
Jon Crowcroft? <br>
Jim Gemmel <br>
Mike Luby <br>
Luigi Rizzo <br>
Lorenzo Vicisano? <br>
<br>
## Tree Building (with RMRG) <br>
Dah Ming Chu <br>
Roger Kermode <br>
Brian Levine <br>
Dave Thaler <br>
Brian Whetten <br>
<br>
Transport Protection <br>
?? <br>
<br>
Protocol Instantiaions <br>
---------------------- <br>
## NACK <br>
Joe Macker <br>
Brian Adamson <br>
<br>
## TRACK <br>
Brian Whetten <br>
Dah Ming Chiu <br>
<br>
## Open Loop FEC <br>
Mike Luby</blockquote><br>
<br>
</html>
--=====================_4158739==_.ALT--
>From owner-rmt@listserv.lbl.gov Mon Dec 6 13:20:00 1999
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id NAA09830;
Mon, 6 Dec 1999 13:19:25 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id NAA09826
for <rmt@listserv.lbl.gov>; Mon, 6 Dec 1999 13:19:24 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id NAA29819
for <rmt@listserv.lbl.gov>; Mon, 6 Dec 1999 13:19:23 -0800 (PST)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id NAA29779
for <rmt@lbl.gov>; Mon, 6 Dec 1999 13:19:17 -0800 (PST)
Received: from eastmail2.East.Sun.COM ([129.148.1.241])
by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA14636
for <rmt@lbl.gov>; Mon, 6 Dec 1999 13:19:16 -0800 (PST)
Received: from bcn.East.Sun.COM (bcn.East.Sun.COM [129.148.75.4])
by eastmail2.East.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id QAA12653
for <rmt@lbl.gov>; Mon, 6 Dec 1999 16:19:14 -0500 (EST)
Received: from bridge (bridge [129.148.75.125])
by bcn.East.Sun.COM (8.9.1b+Sun/8.9.1) with SMTP id QAA10750
for <rmt@lbl.gov>; Mon, 6 Dec 1999 16:19:15 -0500 (EST)
Message-Id: <199912062119.QAA10750@bcn.East.Sun.COM>
Date: Mon, 6 Dec 1999 16:19:13 -0500 (EST)
From: Dah Ming Chiu - Sun Microsystems <Dahming.Chiu@east.sun.com>
Reply-To: Dah Ming Chiu - Sun Microsystems <Dahming.Chiu@east.sun.com>
Subject: Re: RMT Future Progress.....
To: rmt@lbl.gov
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: mMfyCyd3/fBAzHZorxGgug==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc
Sender: owner-rmt@lbl.gov
Precedence: bulk
I also like the idea of holding it in the Bay area, near IP Multicast Summit.
Regards
Dah Ming Chiu
>From owner-rmt@listserv.lbl.gov Tue Dec 7 14:19:37 1999
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id OAA21613;
Tue, 7 Dec 1999 14:18:22 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id OAA21604
for <rmt@listserv.lbl.gov>; Tue, 7 Dec 1999 14:18:20 -0800 (PST)
From: rhee@eos.ncsu.edu
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id OAA28438
for <rmt@listserv.lbl.gov>; Tue, 7 Dec 1999 14:18:19 -0800 (PST)
Received: from rolex.csc.ncsu.edu (rolex.csc.ncsu.edu [152.1.213.197])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id OAA28433
for <rmt@lbl.gov>; Tue, 7 Dec 1999 14:18:18 -0800 (PST)
Received: (from rhee@localhost)
by rolex.csc.ncsu.edu (8.8.4/UC02Jan97)
id RAA03393; Tue, 7 Dec 1999 17:18:16 -0500 (EST)
Date: Tue, 7 Dec 1999 17:18:16 -0500 (EST)
Message-Id: <199912072218.RAA03393@rolex.csc.ncsu.edu>
To: rkermode@arc.corp.mot.com, rmt@lbl.gov
Subject: re: RMT Future Progress.....
Sender: owner-rmt@lbl.gov
Precedence: bulk
Hi Roger,
I would like to participate in the internet-drafting process.
In particular, I am interested in congestion control and FEC.
Is it possible to have me in these teams?
Injong
>From owner-rmt@listserv.lbl.gov Thu Dec 9 13:34:40 1999
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id NAA02820;
Thu, 9 Dec 1999 13:31:53 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id NAA02816
for <rmt@listserv.lbl.gov>; Thu, 9 Dec 1999 13:31:51 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id NAA21648
for <rmt@listserv.lbl.gov>; Thu, 9 Dec 1999 13:31:50 -0800 (PST)
Received: from hercules.cs.ucsb.edu (hercules.cs.ucsb.edu [128.111.41.30])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id NAA21643
for <rmt@lbl.gov>; Thu, 9 Dec 1999 13:31:50 -0800 (PST)
Received: from jackson.cs.ucsb.edu (jackson [128.111.52.10])
by hercules.cs.ucsb.edu (8.8.6/8.8.6) with ESMTP id NAA15497;
Thu, 9 Dec 1999 13:31:38 -0800 (PST)
Received: by jackson.cs.ucsb.edu (8.9.3+Sun/SMI-SVR4)
id NAA28580 for ; Thu, 9 Dec 1999 13:31:33 -0800 (PST)
Date: Thu, 9 Dec 1999 13:31:33 -0800 (PST)
From: almeroth@cs.ucsb.edu (Kevin C. Almeroth)
Message-Id: <199912092131.NAA28580@jackson.cs.ucsb.edu>
To: almeroth@cs.ucsb.edu, nonnen@research.bell-labs.com
Subject: CFP: Integrating Multicast into the Internet (Special Issue of Computer Communications)
Sender: owner-rmt@lbl.gov
Precedence: bulk
CALL FOR PAPERS:
Special Issue of Computer Communications on
Integrating Multicast into the Internet
CFP URL: http://www.cs.ucsb.edu/~almeroth/COMCOM:cfp.html
Journal URL: http://www.elsevier.com/inca/publications/store/5/2/5/4/4/0/
TOPICS:
The amount of bandwidth available in the Internet is increasing
dramatically, both in the backbone networks, as well as in the last mile
(broadband access). One consequence is that the delivery of high-quality
multimedia data will become feasible, and multimedia data, including audio
and video, will become the dominant traffic. As more users gain access to
broadband services, new applications and services will become possible. The
result will be a growing demand for large-scale multimedia applications and
services.
Multicasting as a pure networking solution to the transport of media is
recognized as offering economies-of-scale for large-scale applications.
Multicast is also believed to enable applications which provide service to
thousands, even millions of customers. While there has been significant
research work on multicast, efforts to successfully deploy a production
service have lagged. Reasons range from frequently changing protocols,
management and engineering problems, legacy hardware limitations, traffic
conflicts with unicast, etc.. This special issue focuses on research issues
dealing with the challenges of deploying multicast in the network. Specific
topics include, but are not limited to:
* Multicast Congestion Control
* Multicast Overlay Networks
* Next-Generation Multicast Routing Algorithms
* Multicast Media Transport
* Security for Multicast-Based Services
* Multicast Traffic Engineering and Management
* Multicast Pricing and Quality of Service
GUEST EDITORS:
Kevin Almeroth Jorg Nonnenmacher
Department of Computer Science Network Research Dept, Lucent Technologies
University of California 600-700 Mountain Avenue
Santa Barbara, CA 93106-5110 Murray Hill, NJ 07974-0636
Phone: +1(805) 893-2777 Phone: +1(908) 582-1707
Fax: +1(805) 893-8553 Fax: +1(908) 582-6632
Email: almeroth@cs.ucsb.edu Email: nonnen@research.bell-labs.com
IMPORTANT DATES:
Paper Submission Deadline: February 1, 2000
Feedback to Authors: May 1, 2000
Final Manuscripts Due: June 1, 2000
Publication Date: Fall 2000
SUBMISSION INSTRUCTIONS:
Authors are requested to send e-mail to one or both of the Guest Editors
(almeroth@cs.ucsb.edu, nonnen@research.bell-labs.com) giving a URL from
where a postscript or PDF file can be downloaded. Successfully received
papers will be acknowledged.
AUTHOR INFORMATION:
Submissions made to the special issue should not have appeared in, or been
submitted to other archival publications. All papers will be subjected to
the journal's usual refereeing process.
>From owner-rmt@listserv.lbl.gov Thu Dec 9 15:07:51 1999
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id PAA03178;
Thu, 9 Dec 1999 15:07:30 -0800 (PST)
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id PAA03174
for <rmt@listserv.lbl.gov>; Thu, 9 Dec 1999 15:07:28 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id PAA19652
for <rmt@listserv.lbl.gov>; Thu, 9 Dec 1999 15:07:28 -0800 (PST)
Received: from sj-mailhub-2.cisco.com (sj-mailhub-2.cisco.com [171.69.43.88])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id PAA19648
for <rmt@lbl.gov>; Thu, 9 Dec 1999 15:07:27 -0800 (PST)
Received: from kouvelas-u10.cisco.com (kouvelas-u10.cisco.com [171.69.65.54])
by sj-mailhub-2.cisco.com (8.9.1a/8.9.1) with ESMTP id PAA18195
for <rmt@lbl.gov>; Thu, 9 Dec 1999 15:07:27 -0800 (PST)
Received: from localhost (lorenzo@localhost) by kouvelas-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id PAA10767 for <rmt@lbl.gov>; Thu, 9 Dec 1999 15:06:23 -0800 (PST)
Message-Id: <199912092306.PAA10767@kouvelas-u10.cisco.com>
X-Authentication-Warning: kouvelas-u10.cisco.com: lorenzo owned process doing -bs
X-Mailer: exmh version 2.0.2 2/24/98
To: rmt@lbl.gov
Subject: Draft meeting minutes
Mime-Version: 1.0
Content-Type: text/plain
Date: Thu, 09 Dec 1999 15:06:23 -0800
From: Lorenzo Vicisano <lorenzo@cisco.com>
Sender: owner-rmt@lbl.gov
Precedence: bulk
Hi,
Please find enclosed the draft version of the Washington IETF meeting
minutes. If you have comments please let us know by tomorrow Dec 10th
3pm PST. Apologize for the short notice.
Cheers,
The WG Chairs
Content-Type: multipart/mixed ;
boundary="==_Exmh_-5897494130"
This is a multipart MIME message.
--==_Exmh_-5897494130
--==_Exmh_-5897494130
Content-Type: text/plain ; name="rmt2-minutes"; charset=us-ascii
Content-Description: rmt2-minutes
Content-Disposition: attachment; filename="rmt2-minutes"
Thursday, November 11 at 1300-1500
===================================
CHAIRS: Allison Mankin <mankin@isi.edu>
Roger Kermode <Roger.Kermode@motorola.com>
Lorenzo Vicisano <lorenzo@cisco.com>
Notes taken by Sally Floyd and Alliso Mankin.
Minutes reported by the WG chairs.
Meeting Agenda
==============
Agenda Bashing: Roger Kermode
BB & DS Drafts Update: Roger Kermode
Guidelines Draft (NEW): Allison Mankin
Congestion Control Update: Mark Handley
Generic Router Assist: Tony Speakman
Protocol 1 - NACK: Joe Macker
Protocol 2 - TRACK: Brian Whetten
Protocol 3 - Open Loop: Mike Luby
Security Requirements: Thomas Hardjono
Recharter/Discussion/Next Steps: Roger Kermode
General Remarks
================
- Volunteers to work on any/all drafts are sought. The WG chairs
are compiling a list of people interested that will be circulated
in the WG mailing list.
- As a result of the WG meeting discussion, a revision to the list
of building block is needed (probably need extension). This issue
will be discussed in a meeting to be held in between this and next
IETF.
Meeting Minutes
===============
The content of the viewgraphs presented is not fully reported in this
notes. Please refer to the presentation material for this.
+ Guidelines Draft
------------------
This draft is being put together by the Working Group co-chairs.
Besides the issues established initially, this draft should also
discuss requirement/applicability statement for Protocol Instantiation.
Protocol instantiation drafts should explicitly state how the
protocol being specified meets the guidelines requirements.
+ Congestion Control Update
---------------------------
No viewgraphs available.
The IRTF RMRG has a good handle on equation-based congestion control
for unicast. The multicast variant has not been developed as far as
expected. A guess on time-scales are that a draft on sender-based
multicast
congestion control will be moved from RMRG to RMT in about six months.
The above applies to sender-based congestion control with single
data rate.
Sender-based and receiver-based congestion control will be covered in
separate drafts.
+ Generic Router Assist
------------------------
This constitutes one of the building blocks. The architectural design
draft is available: draft-ieft-rmt-gra-arch-00.txt .
The router task is to assist in functions that can also be accomplished
without their presence (albeit less efficiently). It is lightweighted
and
it is not active networking.
Open issues are: mechanism for splicing GRA signals into transport
protocols (cannot go in network layer but should be
transport-independent).
The authors of the draft solicit input from protocol designers to
select the "support functions" implemented in routers. Operators
that manipulate packets will be limited in number (~ 10) and not
combinable.
+ Building Blocks for NACK-Only RM (NORM)
-----------------------------------------
This presentation is intended to stimulate a discussion on building
blocks for NACK-bases protocols by presenting a prototyped instantiation
of NACK-based protocol (MDP).
Assumption:
- do not assume GRA, but be able to use it, if it is present.
- support loosely controlled groups
- Request for retransmission (NACK) should be based on the
type/content
of the transfer. (e.g. discrete objects vs. continuous stream).
- NACK suppression and other needed functionalities should not make
assumptions on the underling multicast network service. These
should be able to work in presence of asymmetry introduced by
the current variety of routing protocol (source-based tree, shred
tree,
bidirectional tree, single source model). They should also work
without multicast back-channel.
>From the discussion after the presentation it appears that there
are more 'small' building blocks that can be extracted from the
NACK protocol instantiation than the ones initially foreseen (e.g.
source/session identification).
+ TRACK protocol instantiation
------------------------------
Brian Whetten solicited people interested in working on TRACK to
help. The most important open issues seem to be: tree building and
scalability of server-based support (e.g. in the middle of the
network). Other issues belong to building blocks (e.g. congestion
control and security).
The presentation was based on the assumption that most of the
protocol functionalities were provided by the protocol instantiation
an not by building blocks. These included ACK and NACK machinery,
tree building/maintenance and session management. In the following
discussion it was raised the issue on why these cannot be provided
by building blocks (the same used for the NACK protocol). It seem
that efforts should be made to use building blocks as far as possible.
+ Open Loop Protocol
--------------------
The presentation was opened with the issue of agreeing on a new name
for this class of protocol. Mike Luby proposed ALC (Asynchronous
Layered Coding).
Two main open issues were raised for this class of protocol:
specification
of the session parameters (mainly FEC encoding) and congestion control.
As for the former, a possible approach is using out-of-band information
that apply to the session (need in-band session identification, common
with the other classes). The congestion control issue will be approached
along the line of RLC (layered CC by Vicisano, Rizzo, Crowcroft) after
addressing the issues that are left open in this proposal.
+ Security Requirement
----------------------
This point needs to be addressed in a more coordinated way at the
next meeting (or at the pre-IETF meeting). In particular it should
be made a clear distinction between the two issues:
a) Security requirement for RM protocols
b) Security building blocks
Where the first is a pre-requisite for RM protocols, aimed at
protecting the network from malicious attack through security holes
opened by the presence of RM protocols. The second is a optional
component of RM protocols that provide additional service to the
application (Data protection, authentication ...).
>From the meeting discussion it seems that addressing a) with the
available security techniques can pose unacceptable scalability
limitation on RM protocols. Alternatively this issues could be
addressed in the context of congestion control (e.g. by making sure
that all the multicast traffic is accounted in the share assigned
to the session by its congestion control component).
+ Next Meeting
--------------
It is likely that an interim meeting will be held in mid-Februrary
on the west-coast of the USA. One possible date would be February 10th
immediately after the IP Multicast Summit.
--==_Exmh_-5897494130--
>From owner-rmt@listserv.lbl.gov Fri Dec 10 17:56:39 1999
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id RAA09066;
Fri, 10 Dec 1999 17:55:29 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id RAA09062
for <rmt@listserv.lbl.gov>; Fri, 10 Dec 1999 17:55:28 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id RAA26623
for <rmt@listserv.lbl.gov>; Fri, 10 Dec 1999 17:55:27 -0800 (PST)
Received: from pacific.intranet (226.webfountain.com [208.48.102.226])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id RAA26619
for <rmt@lbl.gov>; Fri, 10 Dec 1999 17:55:26 -0800 (PST)
Received: by pacific.intranet with Internet Mail Service (5.5.2448.0)
id <WHC4A05V>; Fri, 10 Dec 1999 17:54:39 -0800
Message-ID: <619F2FB3840CD311AC2C0090273BF1AC151F43@pacific.intranet>
From: Mike Luby <luby@dfountain.com>
To: "'Lorenzo Vicisano'" <lorenzo@cisco.com>, "'rmt@lbl.gov'" <rmt@lbl.gov>
Subject: RE: Draft meeting minutes
Date: Fri, 10 Dec 1999 17:54:34 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="iso-8859-1"
Sender: owner-rmt@lbl.gov
Precedence: bulk
Lorenzo and All,
Please change all references to "open loop" in this document and subsequent
documents to "ALC", which stands for "Asynchronous Layered Coding".
Thanks, Mike
-----Original Message-----
From: owner-rmt@lbl.gov [mailto:owner-rmt@lbl.gov]On Behalf Of Lorenzo
Vicisano
Sent: Thursday, December 09, 1999 3:06 PM
To: rmt@lbl.gov
Subject: Draft meeting minutes
Hi,
Please find enclosed the draft version of the Washington IETF meeting
minutes. If you have comments please let us know by tomorrow Dec 10th
3pm PST. Apologize for the short notice.
Cheers,
The WG Chairs
Content-Type: multipart/mixed ;
boundary="==_Exmh_-5897494130"
This is a multipart MIME message.
--==_Exmh_-5897494130
--==_Exmh_-5897494130
Content-Type: text/plain ; name="rmt2-minutes"; charset=us-ascii
Content-Description: rmt2-minutes
Content-Disposition: attachment; filename="rmt2-minutes"
Thursday, November 11 at 1300-1500
===================================
CHAIRS: Allison Mankin <mankin@isi.edu>
Roger Kermode <Roger.Kermode@motorola.com>
Lorenzo Vicisano <lorenzo@cisco.com>
Notes taken by Sally Floyd and Alliso Mankin.
Minutes reported by the WG chairs.
Meeting Agenda
==============
Agenda Bashing: Roger Kermode
BB & DS Drafts Update: Roger Kermode
Guidelines Draft (NEW): Allison Mankin
Congestion Control Update: Mark Handley
Generic Router Assist: Tony Speakman
Protocol 1 - NACK: Joe Macker
Protocol 2 - TRACK: Brian Whetten
Protocol 3 - Open Loop: Mike Luby
Security Requirements: Thomas Hardjono
Recharter/Discussion/Next Steps: Roger Kermode
General Remarks
================
- Volunteers to work on any/all drafts are sought. The WG chairs
are compiling a list of people interested that will be circulated
in the WG mailing list.
- As a result of the WG meeting discussion, a revision to the list
of building block is needed (probably need extension). This issue
will be discussed in a meeting to be held in between this and next
IETF.
Meeting Minutes
===============
The content of the viewgraphs presented is not fully reported in this
notes. Please refer to the presentation material for this.
+ Guidelines Draft
------------------
This draft is being put together by the Working Group co-chairs.
Besides the issues established initially, this draft should also
discuss requirement/applicability statement for Protocol Instantiation.
Protocol instantiation drafts should explicitly state how the
protocol being specified meets the guidelines requirements.
+ Congestion Control Update
---------------------------
No viewgraphs available.
The IRTF RMRG has a good handle on equation-based congestion control
for unicast. The multicast variant has not been developed as far as
expected. A guess on time-scales are that a draft on sender-based
multicast
congestion control will be moved from RMRG to RMT in about six months.
The above applies to sender-based congestion control with single
data rate.
Sender-based and receiver-based congestion control will be covered in
separate drafts.
+ Generic Router Assist
------------------------
This constitutes one of the building blocks. The architectural design
draft is available: draft-ieft-rmt-gra-arch-00.txt .
The router task is to assist in functions that can also be accomplished
without their presence (albeit less efficiently). It is lightweighted
and
it is not active networking.
Open issues are: mechanism for splicing GRA signals into transport
protocols (cannot go in network layer but should be
transport-independent).
The authors of the draft solicit input from protocol designers to
select the "support functions" implemented in routers. Operators
that manipulate packets will be limited in number (~ 10) and not
combinable.
+ Building Blocks for NACK-Only RM (NORM)
-----------------------------------------
This presentation is intended to stimulate a discussion on building
blocks for NACK-bases protocols by presenting a prototyped instantiation
of NACK-based protocol (MDP).
Assumption:
- do not assume GRA, but be able to use it, if it is present.
- support loosely controlled groups
- Request for retransmission (NACK) should be based on the
type/content
of the transfer. (e.g. discrete objects vs. continuous stream).
- NACK suppression and other needed functionalities should not make
assumptions on the underling multicast network service. These
should be able to work in presence of asymmetry introduced by
the current variety of routing protocol (source-based tree, shred
tree,
bidirectional tree, single source model). They should also work
without multicast back-channel.
>From the discussion after the presentation it appears that there
are more 'small' building blocks that can be extracted from the
NACK protocol instantiation than the ones initially foreseen (e.g.
source/session identification).
+ TRACK protocol instantiation
------------------------------
Brian Whetten solicited people interested in working on TRACK to
help. The most important open issues seem to be: tree building and
scalability of server-based support (e.g. in the middle of the
network). Other issues belong to building blocks (e.g. congestion
control and security).
The presentation was based on the assumption that most of the
protocol functionalities were provided by the protocol instantiation
an not by building blocks. These included ACK and NACK machinery,
tree building/maintenance and session management. In the following
discussion it was raised the issue on why these cannot be provided
by building blocks (the same used for the NACK protocol). It seem
that efforts should be made to use building blocks as far as possible.
+ Open Loop Protocol
--------------------
The presentation was opened with the issue of agreeing on a new name
for this class of protocol. Mike Luby proposed ALC (Asynchronous
Layered Coding).
Two main open issues were raised for this class of protocol:
specification
of the session parameters (mainly FEC encoding) and congestion control.
As for the former, a possible approach is using out-of-band information
that apply to the session (need in-band session identification, common
with the other classes). The congestion control issue will be approached
along the line of RLC (layered CC by Vicisano, Rizzo, Crowcroft) after
addressing the issues that are left open in this proposal.
+ Security Requirement
----------------------
This point needs to be addressed in a more coordinated way at the
next meeting (or at the pre-IETF meeting). In particular it should
be made a clear distinction between the two issues:
a) Security requirement for RM protocols
b) Security building blocks
Where the first is a pre-requisite for RM protocols, aimed at
protecting the network from malicious attack through security holes
opened by the presence of RM protocols. The second is a optional
component of RM protocols that provide additional service to the
application (Data protection, authentication ...).
>From the meeting discussion it seems that addressing a) with the
available security techniques can pose unacceptable scalability
limitation on RM protocols. Alternatively this issues could be
addressed in the context of congestion control (e.g. by making sure
that all the multicast traffic is accounted in the share assigned
to the session by its congestion control component).
+ Next Meeting
--------------
It is likely that an interim meeting will be held in mid-Februrary
on the west-coast of the USA. One possible date would be February 10th
immediately after the IP Multicast Summit.
--==_Exmh_-5897494130--
>From owner-rmt@listserv.lbl.gov Fri Dec 10 18:05:28 1999
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id SAA09104;
Fri, 10 Dec 1999 18:05:26 -0800 (PST)
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id SAA09100
for <rmt@listserv.lbl.gov>; Fri, 10 Dec 1999 18:05:24 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id SAA28019
for <rmt@listserv.lbl.gov>; Fri, 10 Dec 1999 18:05:23 -0800 (PST)
Received: from kickme.cisco.com (kickme.cisco.com [198.92.30.42])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id SAA28006
for <rmt@lbl.gov>; Fri, 10 Dec 1999 18:05:18 -0800 (PST)
Received: from kouvelas-u10.cisco.com (kouvelas-u10.cisco.com [171.69.65.54])
by kickme.cisco.com (8.9.1a/8.9.1) with ESMTP id SAA11689;
Fri, 10 Dec 1999 18:00:54 -0800 (PST)
Received: from localhost (lorenzo@localhost) by kouvelas-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id SAA12758; Fri, 10 Dec 1999 18:04:40 -0800 (PST)
Message-Id: <199912110204.SAA12758@kouvelas-u10.cisco.com>
X-Authentication-Warning: kouvelas-u10.cisco.com: lorenzo owned process doing -bs
X-Mailer: exmh version 2.0.2 2/24/98
To: Mike Luby <luby@dfountain.com>
cc: "'rmt@lbl.gov'" <rmt@lbl.gov>
Subject: Re: Draft meeting minutes
In-reply-to: Your message of "Fri, 10 Dec 1999 17:54:34 PST."
<619F2FB3840CD311AC2C0090273BF1AC151F43@pacific.intranet>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 10 Dec 1999 18:04:40 -0800
From: Lorenzo Vicisano <lorenzo@cisco.com>
Sender: owner-rmt@lbl.gov
Precedence: bulk
Mike,
> Please change all references to "open loop" in this document and subsequent
> documents to "ALC", which stands for "Asynchronous Layered Coding".
Too late: I've already sent the minutes. Will do next time.
Please note however the we mentioned ALC in the notes.
cheers,
Lorenzo
>From owner-rmt@listserv.lbl.gov Fri Dec 10 20:16:35 1999
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id UAA09435;
Fri, 10 Dec 1999 20:16:19 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id UAA09431
for <rmt@listserv.lbl.gov>; Fri, 10 Dec 1999 20:16:17 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id UAA07978
for <rmt@listserv.lbl.gov>; Fri, 10 Dec 1999 20:16:16 -0800 (PST)
Received: from virtualworkshop.com (IDENT:root@dino.virtualworkshop.com [208.14.33.1])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id UAA07975
for <rmt@lbl.gov>; Fri, 10 Dec 1999 20:16:15 -0800 (PST)
Received: from virtualworkshop.com (barney.virtualworkshop.com [208.14.33.4])
by virtualworkshop.com (8.9.1/8.8.7) with ESMTP id XAA12521;
Fri, 10 Dec 1999 23:16:06 -0500
Message-ID: <3851D005.9B750D41@virtualworkshop.com>
Date: Fri, 10 Dec 1999 23:16:05 -0500
From: "Michael D. Myjak" <mmyjak@virtualworkshop.com>
Reply-To: mmyjak@virtualworkshop.com
Organization: The Virtual Workshop, Inc.
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Lorenzo Vicisano <lorenzo@cisco.com>
CC: RMT <rmt@lbl.gov>
Subject: Re: Draft meeting minutes
References: <199912110204.SAA12758@kouvelas-u10.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-rmt@lbl.gov
Precedence: bulk
Lorenzo Vicisano wrote:
> Mike,
>
> > Please change all references to "open loop" in this document and subsequent
> > documents to "ALC", which stands for "Asynchronous Layered Coding".
>
> Too late: I've already sent the minutes. Will do next time.
> Please note however the we mentioned ALC in the notes.
>
> cheers,
> Lorenzo
Lorenzo,
Its not uncommon to circulate the minutes, make a correction or two, and
recirculate a final draft.
--
All the best -
_
___|0|_|___ Michael D. Myjak, Vice President R&D and CTO
| N & W | The Virtual Workshop, Inc.
= oo---oo = P.O. Box 98 Titusville Fl 32781
email: <mmyjak@virtualworkshop.com> voice&fax: 407.264.0440
>From owner-rmt@listserv.lbl.gov Fri Dec 10 20:50:54 1999
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id UAA09504;
Fri, 10 Dec 1999 20:50:45 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id UAA09500
for <rmt@listserv.lbl.gov>; Fri, 10 Dec 1999 20:50:43 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id UAA09547
for <rmt@listserv.lbl.gov>; Fri, 10 Dec 1999 20:50:43 -0800 (PST)
Received: from daffy.ee.lbl.gov (daffy.ee.lbl.gov [131.243.1.31])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id UAA09544
for <rmt@lbl.gov>; Fri, 10 Dec 1999 20:50:42 -0800 (PST)
Received: (from vern@localhost)
by daffy.ee.lbl.gov (8.9.2/8.9.2) id UAA06351;
Fri, 10 Dec 1999 20:50:40 -0800 (PST)
Message-Id: <199912110450.UAA06351@daffy.ee.lbl.gov>
To: mmyjak@virtualworkshop.com
Cc: Lorenzo Vicisano <lorenzo@cisco.com>, RMT <rmt@lbl.gov>
Subject: Re: Draft meeting minutes
In-reply-to: Your message of Fri, 10 Dec 1999 23:16:05 PST.
Date: Fri, 10 Dec 1999 20:50:39 PST
From: Vern Paxson <vern@ee.lbl.gov>
Sender: owner-rmt@lbl.gov
Precedence: bulk
> Its not uncommon to circulate the minutes, make a correction or two, and
> recirculate a final draft.
I have a hard time seeing changing minutes that discuss a proposal to change
the term "Open Loop" to "ALC", so that they don't mention the term "Open Loop"
and just use "ALC". I think the minutes should stand as they are.
In addition, the meeting summary that the chairs sent to the area directors
said of the proposed name change that there "was little time for discussion
of this suggestion". So I think the name change should first be open for
discussion on the mailing list (personally, I think it's a good idea).
Vern
>From owner-rmt@listserv.lbl.gov Sat Dec 11 18:24:07 1999
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id SAA11597;
Sat, 11 Dec 1999 18:22:38 -0800 (PST)
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id SAA11593
for <rmt@listserv.lbl.gov>; Sat, 11 Dec 1999 18:22:32 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id SAA04902
for <rmt@listserv.lbl.gov>; Sat, 11 Dec 1999 18:22:31 -0800 (PST)
Received: from kickme.cisco.com (kickme.cisco.com [198.92.30.42])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id SAA04892
for <rmt@lbl.gov>; Sat, 11 Dec 1999 18:22:26 -0800 (PST)
Received: from kouvelas-u10.cisco.com (kouvelas-u10.cisco.com [171.69.65.54])
by kickme.cisco.com (8.9.1a/8.9.1) with ESMTP id SAA10543;
Sat, 11 Dec 1999 18:17:48 -0800 (PST)
Received: from localhost (lorenzo@localhost) by kouvelas-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id SAA14121; Sat, 11 Dec 1999 18:21:39 -0800 (PST)
Message-Id: <199912120221.SAA14121@kouvelas-u10.cisco.com>
X-Authentication-Warning: kouvelas-u10.cisco.com: lorenzo owned process doing -bs
X-Mailer: exmh version 2.0.2 2/24/98
To: mmyjak@virtualworkshop.com
cc: RMT <rmt@lbl.gov>
Subject: Re: Draft meeting minutes
In-reply-to: Your message of "Fri, 10 Dec 1999 23:16:05 EST."
<3851D005.9B750D41@virtualworkshop.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sat, 11 Dec 1999 18:21:39 -0800
From: Lorenzo Vicisano <lorenzo@cisco.com>
Sender: owner-rmt@lbl.gov
Precedence: bulk
> Its not uncommon to circulate the minutes, make a correction or two, and
> recirculate a final draft.
Michael,
Mike's request arrived after the deadline we had set, that was
dictated by the IETF deadline. We do apologize, however,
for having sent out the minutes only one day in advance.
cheers,
Lorenzo
>From owner-rmt@listserv.lbl.gov Thu Dec 16 21:32:05 1999
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id VAA14385;
Thu, 16 Dec 1999 21:30:17 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id VAA14381
for <rmt@listserv.lbl.gov>; Thu, 16 Dec 1999 21:30:15 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id VAA11441
for <rmt@listserv.lbl.gov>; Thu, 16 Dec 1999 21:30:14 -0800 (PST)
Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id VAA11438
for <rmt@lbl.gov>; Thu, 16 Dec 1999 21:30:13 -0800 (PST)
Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate2.mot.com (MOT-motgate2 1.0) with ESMTP id WAA21197 for <rmt@lbl.gov>; Thu, 16 Dec 1999 22:30:13 -0700 (MST)]
Received: [from homer.arc.corp.mot.com ([217.1.10.38]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id WAA19310 for <rmt@lbl.gov>; Thu, 16 Dec 1999 22:30:11 -0700 (MST)]
Received: from arc.corp.mot.com (t-il06-y-port8.corp.mot.com [129.188.170.138])
by homer.arc.corp.mot.com (8.9.3/8.9.3) with ESMTP id QAA23178
for <rmt@lbl.gov>; Fri, 17 Dec 1999 16:28:30 +1100 (EST)
Message-ID: <3859CBA1.7F682961@arc.corp.mot.com>
Date: Fri, 17 Dec 1999 16:35:29 +1100
From: Roger Kermode <rkermode@arc.corp.mot.com>
Reply-To: Roger.Kermode@motorola.com
Organization: Motorola
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: rmt-list <rmt@lbl.gov>
Subject: RMT Team Formation, draft editor election...
Content-Type: multipart/mixed;
boundary="------------00253F7E6647C5CCE17686FA"
Sender: owner-rmt@lbl.gov
Precedence: bulk
This is a multi-part message in MIME format.
--------------00253F7E6647C5CCE17686FA
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Dear RMTers,
I've done my best to add names and email addresses to the list
of actively interested people for each of the RMT drafts that
have currently been scheduled. I'd like each you involved in a
teams to contact the other members of your team and to elect
a document editor for that team. This person will be responsible
for merging the inputs of other team members and ensuring the
timely progress of the draft.
Given that the holidays are nearly upon us it would be nice to
have this sorted out in the next week or so,
cheers,
Roger
Guidelines Draft
----------------
Roger Kermode <Roger.Kermode@motorola.com>
Allison Mankin <mankin@isi.edu>
Lorenzo Vicisano <lorenzo@cisco.com>
Building Blocks teams
---------------------
## Congestion Control (with RMRG)
Sally Flloyd <flloyd@aciri.org>
Mark Handley <mjh@aciri.org>
Shivkumar Kalyanaraman <shivkuma@ecse.rpi.edu>
Injong Rhee <rhee@eos.ncsu.edu>
## Generic Router Assist
Brad Cain <bcain@nortelnetworks.com>
Tony Speakman, <speakman@cisco.com>
Don Towsley
## NACK
Brian Adamson <adamson@itd.nrl.navy.mil>
Joe Macker <macker@itd.nrl.navy.mil>
Carsten Borman <cabo@Informatik.Uni-Bremen.DE>
## Asynchronous Layered Coding
Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
Jim Gemmel <jgemmel@microsoft.com>
Mike Luby <luby@dfountain.com>
Luigi Rizzo <luigi@labinfo.iet.unipi.it>
Lorenzo Vicisano <lorenzo@cisco.com>
Bruce Lueckenhoff <brucelu@cadence.com>
Vincent ROCA <vincent.roca@lip6.fr>
## Tree Building (with RMRG)
Dah Ming Chu <Dahming.Chiu@east.sun.com>
Roger Kermode <Roger.Kermode@motorola.com>
Brian Levine <brian@cs.umass.edu>
Dave Thaler <dthaler@Exchange.Microsoft.com>
Brian Whetten <whetten@talarian.com>
Transport Protection
??
Protocol Instantiaions
----------------------
## NACK
Brian Adamson <adamson@itd.nrl.navy.mil>
Joe Macker <macker@itd.nrl.navy.mil>
Richard Edmonstone <redmonst@cisco.com>
## TRACK
Brian Whetten <whetten@talarian.com>
Dah Ming Chiu <Dahming.Chiu@east.sun.com>
## Asynchronous Layered Coding
Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
Jim Gemmel <jgemmel@microsoft.com>
Mike Luby <luby@dfountain.com>
Luigi Rizzo <luigi@labinfo.iet.unipi.it>
Lorenzo Vicisano <lorenzo@cisco.com>
Bruce Lueckenhoff <brucelu@cadence.com>
--------------00253F7E6647C5CCE17686FA
Content-Type: text/x-vcard; charset=us-ascii;
name="rkermode.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Roger Kermode
Content-Disposition: attachment;
filename="rkermode.vcf"
begin:vcard
n:Kermode;Roger
tel;fax:+61-2-9666-0501
tel;home:+61-2-9664-8335
tel;work:+61-2-9666-0558
x-mozilla-html:FALSE
url:www.mot.com.au
org:Motorola Australian Research Centre;Scalable Commodity Internet Lab
version:2.1
email;internet:Roger.Kermode@motorola.com
title:Principal Research Engineer
SNAIL MAIL: Locked Bag 5028, Botany NSW, 1455=0D=0A;Botany;NSW;2019;Australia
adr;quoted-printable:;;PHYSICAL: Level 3, 12 Lord St., Botany, NSW=0D=0A=
x-mozilla-cpt:;-1
fn:Roger Kermode
end:vcard
--------------00253F7E6647C5CCE17686FA--
>From owner-rmt@listserv.lbl.gov Fri Dec 17 11:08:59 1999
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id LAA16603;
Fri, 17 Dec 1999 11:07:52 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id LAA16599
for <rmt@listserv.lbl.gov>; Fri, 17 Dec 1999 11:07:50 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id LAA25002
for <rmt@listserv.lbl.gov>; Fri, 17 Dec 1999 11:07:49 -0800 (PST)
Received: from phobos.talarian.com (mailhost.talarian.com [207.5.32.17])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id LAA24995
for <rmt@lbl.gov>; Fri, 17 Dec 1999 11:07:48 -0800 (PST)
Received: from tahoe ([10.3.9.20]) by phobos.talarian.com (8.9.0/8.9.0) with SMTP id LAA18239; Fri, 17 Dec 1999 11:07:25 -0800 (PST)
Message-Id: <4.1.19991217110709.01f59df0@mailhost.talarian.com>
X-Sender: bwhetten@mailhost.talarian.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1
Date: Fri, 17 Dec 1999 11:07:32 -0800
To: Roger.Kermode@motorola.com, rmt-list <rmt@lbl.gov>
From: Brian Whetten <whetten@talarian.com>
Subject: Re: RMT Team Formation, draft editor election...
In-Reply-To: <3859CBA1.7F682961@arc.corp.mot.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-rmt@lbl.gov
Precedence: bulk
Roger,
I would also like to continue contributing to the TFMCC (congestion
control) work.
Brian
At 04:35 PM 12/17/1999 +1100, Roger Kermode wrote:
>Dear RMTers,
>
>I've done my best to add names and email addresses to the list
>of actively interested people for each of the RMT drafts that
>have currently been scheduled. I'd like each you involved in a
>teams to contact the other members of your team and to elect
>a document editor for that team. This person will be responsible
>for merging the inputs of other team members and ensuring the
>timely progress of the draft.
>
>Given that the holidays are nearly upon us it would be nice to
>have this sorted out in the next week or so,
>
>cheers,
>
>Roger
>
>
>Guidelines Draft
>----------------
>Roger Kermode <Roger.Kermode@motorola.com>
>Allison Mankin <mankin@isi.edu>
>Lorenzo Vicisano <lorenzo@cisco.com>
>
>Building Blocks teams
>---------------------
>
>## Congestion Control (with RMRG)
>Sally Flloyd <flloyd@aciri.org>
>Mark Handley <mjh@aciri.org>
>Shivkumar Kalyanaraman <shivkuma@ecse.rpi.edu>
>Injong Rhee <rhee@eos.ncsu.edu>
>
>## Generic Router Assist
>Brad Cain <bcain@nortelnetworks.com>
>Tony Speakman, <speakman@cisco.com>
>Don Towsley
>
>## NACK
>Brian Adamson <adamson@itd.nrl.navy.mil>
>Joe Macker <macker@itd.nrl.navy.mil>
>Carsten Borman <cabo@Informatik.Uni-Bremen.DE>
>
>## Asynchronous Layered Coding
>Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
>Jim Gemmel <jgemmel@microsoft.com>
>Mike Luby <luby@dfountain.com>
>Luigi Rizzo <luigi@labinfo.iet.unipi.it>
>Lorenzo Vicisano <lorenzo@cisco.com>
>Bruce Lueckenhoff <brucelu@cadence.com>
>Vincent ROCA <vincent.roca@lip6.fr>
>
>## Tree Building (with RMRG)
>Dah Ming Chu <Dahming.Chiu@east.sun.com>
>Roger Kermode <Roger.Kermode@motorola.com>
>Brian Levine <brian@cs.umass.edu>
>Dave Thaler <dthaler@Exchange.Microsoft.com>
>Brian Whetten <whetten@talarian.com>
>
>Transport Protection
>??
>
>Protocol Instantiaions
>----------------------
>## NACK
>Brian Adamson <adamson@itd.nrl.navy.mil>
>Joe Macker <macker@itd.nrl.navy.mil>
>Richard Edmonstone <redmonst@cisco.com>
>
>## TRACK
>Brian Whetten <whetten@talarian.com>
>Dah Ming Chiu <Dahming.Chiu@east.sun.com>
>
>## Asynchronous Layered Coding
>Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
>Jim Gemmel <jgemmel@microsoft.com>
>Mike Luby <luby@dfountain.com>
>Luigi Rizzo <luigi@labinfo.iet.unipi.it>
>Lorenzo Vicisano <lorenzo@cisco.com>
>Bruce Lueckenhoff <brucelu@cadence.com>
>From owner-rmt@listserv.lbl.gov Tue Dec 21 04:26:58 1999
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id EAA28239;
Tue, 21 Dec 1999 04:24:57 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id EAA28235
for <rmt@listserv.lbl.gov>; Tue, 21 Dec 1999 04:24:54 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id EAA24454
for <rmt@listserv.lbl.gov>; Tue, 21 Dec 1999 04:24:54 -0800 (PST)
Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id EAA24451
for <rmt@lbl.gov>; Tue, 21 Dec 1999 04:24:53 -0800 (PST)
Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate2.mot.com (MOT-motgate2 1.0) with ESMTP id FAA00029 for <rmt@lbl.gov>; Tue, 21 Dec 1999 05:24:52 -0700 (MST)]
Received: [from homer.arc.corp.mot.com ([217.1.10.38]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id FAA19643 for <rmt@lbl.gov>; Tue, 21 Dec 1999 05:24:51 -0700 (MST)]
Received: from arc.corp.mot.com ([217.1.71.213])
by homer.arc.corp.mot.com (8.9.3/8.9.3) with ESMTP id XAA29215
for <rmt@lbl.gov>; Tue, 21 Dec 1999 23:22:47 +1100 (EST)
Message-ID: <385F72CC.8D514497@arc.corp.mot.com>
Date: Tue, 21 Dec 1999 23:30:04 +1100
From: Roger Kermode <rkermode@arc.corp.mot.com>
Reply-To: Roger.Kermode@motorola.com
Organization: Motorola
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: rmt-list <rmt@lbl.gov>
Subject: Interim RMT Meeting Feb 10th at ACIRI (Berkeley)
Content-Type: multipart/mixed;
boundary="------------433F66D633774ED0FB7B2AB6"
Sender: owner-rmt@lbl.gov
Precedence: bulk
This is a multi-part message in MIME format.
--------------433F66D633774ED0FB7B2AB6
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
There will be an interim meeting of the IETF RMT WG on
February 10th, 2000 at ACIRI near U.C. Berkeley.
Mark Handley has kindly arranged for a room that can
hold 40 people. At this stage we'd like to gauge
attendance numbers to determine if we need to find a
larger venue.
If you plan to attend please RSVP ASAP.
cheers,
Roger Kermode
Allison Mankin
Lorenzo Vicisano
--------------433F66D633774ED0FB7B2AB6
Content-Type: text/x-vcard; charset=us-ascii;
name="rkermode.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Roger Kermode
Content-Disposition: attachment;
filename="rkermode.vcf"
begin:vcard
n:Kermode;Roger
tel;fax:+61-2-9666-0501
tel;home:+61-2-9664-8335
tel;work:+61-2-9666-0558
x-mozilla-html:FALSE
url:www.mot.com.au
org:Motorola Australian Research Centre;Scalable Commodity Internet Lab
version:2.1
email;internet:Roger.Kermode@motorola.com
title:Principal Research Engineer
SNAIL MAIL: Locked Bag 5028, Botany NSW, 1455=0D=0A;Botany;NSW;2019;Australia
adr;quoted-printable:;;PHYSICAL: Level 3, 12 Lord St., Botany, NSW=0D=0A=
x-mozilla-cpt:;-1
fn:Roger Kermode
end:vcard
--------------433F66D633774ED0FB7B2AB6--
>From owner-rmt@listserv.lbl.gov Mon Jan 3 07:33:15 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id HAA11398;
Mon, 3 Jan 2000 07:30:44 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id HAA11394
for <rmt@listserv.lbl.gov>; Mon, 3 Jan 2000 07:30:42 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id HAA20534
for <rmt@listserv.lbl.gov>; Mon, 3 Jan 2000 07:30:42 -0800 (PST)
Received: from smtp2.cluster.oleane.net (smtp2.cluster.oleane.net [195.25.12.17])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id HAA20523
for <rmt@lbl.gov>; Mon, 3 Jan 2000 07:30:36 -0800 (PST)
Received: from oleane (dyn-1-1-234.Vin.dialup.oleane.fr [195.25.4.234]) by smtp2.cluster.oleane.net with SMTP id QAA75711; Mon, 3 Jan 2000 16:29:34 +0100 (CET)
Message-ID: <005601bf55ff$04f74a80$0401a8c0@oleane.com>
From: "Peter Lewis" <peter.lewis@upperside.fr>
To: <Undisclosed-Recipient:@smtp2.cluster.oleane.net;>
Subject: VoDSL 2000 Conference
Date: Mon, 3 Jan 2000 16:27:10 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_0053_01BF5607.6292A240"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-rmt@lbl.gov
Precedence: bulk
This is a multi-part message in MIME format.
------=_NextPart_000_0053_01BF5607.6292A240
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
=20
Hello,
=20
The VoDSL 2000 Conference will stand in Paris next 28-31 March. Key =
speakers, case studies: take a look at: =
http://www.upperside.fr/bavodsl.htm
=20
Regards
------=_NextPart_000_0053_01BF5607.6292A240
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>
<DIV><FONT face=3DArial size=3D2> =20
<DIV><FONT face=3DArial size=3D2>
<DIV><FONT color=3D#000000 size=3D2>Hello,</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
<DIV><FONT color=3D#000000 size=3D2>The VoDSL 2000 Conference will stand =
in Paris=20
next 28-31 March. Key speakers, case studies: take a look at: <A=20
href=3D"http://www.upperside.fr/bavodsl.htm">http://www.upperside.fr/bavo=
dsl.htm</A></FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
<DIV><FONT color=3D#000000=20
size=3D2>Regards</FONT></FONT></FONT></DIV></DIV></DIV></FONT></DIV>
<DIV> </DIV></BODY></HTML>
------=_NextPart_000_0053_01BF5607.6292A240--
>From owner-rmt@listserv.lbl.gov Tue Jan 11 02:51:29 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id CAA03600;
Tue, 11 Jan 2000 02:46:28 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id CAA03596
for <rmt@listserv.lbl.gov>; Tue, 11 Jan 2000 02:46:26 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id CAA03060
for <rmt@listserv.lbl.gov>; Tue, 11 Jan 2000 02:46:25 -0800 (PST)
Received: from smtp1.cluster.oleane.net (smtp1.cluster.oleane.net [195.25.12.16])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id CAA03028
for <rmt@lbl.gov>; Tue, 11 Jan 2000 02:45:51 -0800 (PST)
Received: from oleane (dyn-1-1-186.Vin.dialup.oleane.fr [195.25.4.186]) by smtp1.cluster.oleane.net with SMTP id LAA20336; Tue, 11 Jan 2000 11:43:57 +0100 (CET)
Message-ID: <008501bf5c20$6b51e020$0401a8c0@oleane.com>
From: "Peter Lewis" <peter.lewis@upperside.fr>
To: <Undisclosed-Recipient:@smtp1.cluster.oleane.net;>
Subject: SIP 2000 Call for Paper
Date: Tue, 11 Jan 2000 11:41:20 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_0082_01BF5C28.C79F0D00"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-rmt@lbl.gov
Precedence: bulk
This is a multi-part message in MIME format.
------=_NextPart_000_0082_01BF5C28.C79F0D00
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
SIP 2000: beyond H.323?=20
Discussing and debating in Paris May 10-12.
A CFP is online at:
http://www.upperside.fr/basip.htm
=20
------=_NextPart_000_0082_01BF5C28.C79F0D00
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>
<DIV><FONT color=3D#000000 size=3D2>SIP 2000: beyond H.323? =
</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2>Discussing and debating in Paris May =
10-12.</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2>A CFP is online at:</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2><A=20
href=3D"http://www.upperside.fr/basip.htm">http://www.upperside.fr/basip.=
htm</A></FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT> </DIV></FONT></DIV>
<DIV> </DIV></BODY></HTML>
------=_NextPart_000_0082_01BF5C28.C79F0D00--
>From owner-rmt@listserv.lbl.gov Wed Jan 12 09:34:25 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id JAA10716;
Wed, 12 Jan 2000 09:32:10 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id JAA10712
for <rmt@listserv.lbl.gov>; Wed, 12 Jan 2000 09:32:07 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id JAA00494
for <rmt@listserv.lbl.gov>; Wed, 12 Jan 2000 09:32:05 -0800 (PST)
Received: from mailgate.Cadence.COM (mailgate.Cadence.COM [158.140.2.1])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id JAA00485
for <rmt@lbl.gov>; Wed, 12 Jan 2000 09:32:04 -0800 (PST)
Received: from sbult1e.Cadence.COM (sbult1e.Cadence.COM [139.99.82.8])
by mailgate.Cadence.COM (8.9.3/8.9.3) with ESMTP id JAA26641;
Wed, 12 Jan 2000 09:30:49 -0800 (PST)
Received: (from brucelu@localhost)
by sbult1e.Cadence.COM (8.8.5/8.8.5) id JAA21661;
Wed, 12 Jan 2000 09:30:43 -0800 (PST)
From: Bruce Lueckenhoff <brucelu@cadence.com>
Message-Id: <200001121730.JAA21661@sbult1e.Cadence.COM>
Subject: Re: RMT Team Formation
To: rmt@lbl.gov
Date: Wed, 12 Jan 100 09:30:43 -0800 (PST)
Cc: J.Crowcroft@cs.ucl.ac.uk, jgemmel@microsoft.com, luby@dfountain.com,
luigi@info.iet.unipi.it, lorenzo@cisco.com, vincent.roca@lip6.fr
In-Reply-To: <Pine.LNX.3.95.991223161540.1829D-100000@pegase.ipv6.lip6.fr> from "Vincent Roca" at Dec 23, 99 04:19:49 pm
Organization: Cadence Design Systems, Inc.
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text
X-Received: By mailgate.Cadence.COM as JAA26641 at Wed Jan 12 09:30:49 2000
Sender: owner-rmt@lbl.gov
Precedence: bulk
Greetings,
Mr. Roca raises a valid point. Layering should be considered
separately, at least from the building block point of view. Certainly
layering could be part of an ALC protocol instantiation, though.
Am I missing any compelling reasons why layering ought to be bundled
into the ALC building block?
on December 23, 1999, Vincent Roca wrote:
> ...
> I see that he inserted me in the ALC list... I read the meeting
> minutes and saw that it is more dedicated to FEC/CC than on
> layered packet organization schemes
> ...
Bruce
--
Bruce Lueckenhoff mailto:brucelu@cadence.com
Cadence Design Systems 805-571-1246 FAX:805-571-1300
>From owner-rmt@listserv.lbl.gov Wed Jan 12 12:52:21 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id MAA11329;
Wed, 12 Jan 2000 12:51:09 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id MAA11325
for <rmt@listserv.lbl.gov>; Wed, 12 Jan 2000 12:51:02 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id MAA07058
for <rmt@listserv.lbl.gov>; Wed, 12 Jan 2000 12:51:02 -0800 (PST)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id MAA06846
for <rmt@lbl.gov>; Wed, 12 Jan 2000 12:50:11 -0800 (PST)
Received: from eastmail2.East.Sun.COM ([129.148.1.241])
by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA17523
for <rmt@lbl.gov>; Wed, 12 Jan 2000 12:50:00 -0800 (PST)
Received: from bcn.East.Sun.COM (bcn.East.Sun.COM [129.148.75.4])
by eastmail2.East.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id PAA22102
for <rmt@lbl.gov>; Wed, 12 Jan 2000 15:49:58 -0500 (EST)
Received: from bridge (bridge [129.148.75.125])
by bcn.East.Sun.COM (8.9.1b+Sun/8.9.1) with SMTP id PAA25668
for <rmt@lbl.gov>; Wed, 12 Jan 2000 15:49:58 -0500 (EST)
Message-Id: <200001122049.PAA25668@bcn.East.Sun.COM>
Date: Wed, 12 Jan 2000 15:49:57 -0500 (EST)
From: Dah Ming Chiu - Sun Microsystems <Dahming.Chiu@east.sun.com>
Reply-To: Dah Ming Chiu - Sun Microsystems <Dahming.Chiu@east.sun.com>
Subject: ACK Building Block
To: rmt@lbl.gov
MIME-Version: 1.0
Content-Type: MULTIPART/mixed; BOUNDARY=Ambush_of_Tigers_512_000
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc
Sender: owner-rmt@lbl.gov
Precedence: bulk
--Ambush_of_Tigers_512_000
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: YoliUetor4PDRyrANjucVA==
Over a month ago, I wrote a short proposal to develop an ACK building
block, and circulated it to a small set of people in RMT for comment.
So far, only Brian Whetten and I have been discussing it; and we have
some different opinions. Since there may be others on the RMT list who
are interested in the (Tree-based) ACK approach, I would like to move
the discussion here.
Attached is a sketch of an ACK BB (Building Block). I have not updated
it since I wrote it a month ago. It describes the relationship
between a receiver and its repair head (repair node), and some basic
session management functions of the sender, all in terms of an abstract
API. I have also sketched out some algorithms that need to be specified
(such as deciding when to ack and request ack), and some hooks to other
BB's (e.g. congestion control, tree-building). Most importantly, this
is all quite simple.
I hope this is useful for helping us build the TRACK protocol standards
as we move ahead. Comments are welcome.
Dah Ming Chiu
--Ambush_of_Tigers_512_000
Content-Type: TEXT/plain; name="ACKBB.txt"; charset=us-ascii; x-unix-mode=0600
Content-Description: ACKBB.txt
Content-MD5: hZzSk05DmgQ2NOxJNZXvPA==
ACK-based reliable multicast service building block (ACK BB)
------------------------------------------------------------
The ACK-based reliable multicast building block abstracts out the basic
interface and algorithms used by an ACK-based reliable multicast transport,
and described how it interacts with other building blocks such as the
use (and building) of a repair tree, congestion/flow control, security
and group management.
The following is a rough sketch of the ACK BB, including definitions of
an abstract API, a number of algorithms, and descriptions of "hooks" used
for integrating with other building blocks.
1) Abstract API
1.1) Definition of some primitive datatypes used to describe the abstract API.
session:
This is possibly identified by the following -
session id
multicast address
[sender address]
member:
This identifies a receiver using its address and port
head:
This identifies a repair head using its address and port
1.2) APIs for member to repair head interaction:
BindToRepairHead(session, head, scope, [role], [subtree])
This function is used by a member to request repair service from a
repair head. The parameter scope includes ttl and/or administrative
scoping information, used by a repair head to perform localized repair.
The optional parameters [role] and [subtree] provide other information
about the receiver. Role says if the receiver can or cannot become
head; subtree indicates if the receiver is itself a repair head,
and information about its dependents.
Ack(session, head, ack_info)
This function is used to send an acknowledgement to a repair head.
The parameter ack_info is a suitable data structure - for example
can contain an ascending list of sequence numbers; the first
element of the list signifying the highest sequence number of
consecutively received packets, etc.
Unbind(session, head, reason)
This function is used to tell the current repair head that its services
are no longer needed.
1.3) APIs for repair head to member interaction:
AcceptMember(session, member, available_packets, [repair_addr], [level])
This function is used to respond to a BindToRepairHead request.
The parameter available_packets a suitable data structure for example
containing a descending list of sequence numbers; the first element of
the list signifying the beginning of a consecutive packet stream this
repair head is prepared to repair. Optionally, a separate multicast
address can be suggested for members to listen for (multicast) repairs.
The optional parameter [level] is used (when there is a repair tree) to
indicate the number of other repair heads this repair head depends on.
RejectMember(session, member, reason)
This function is used to reject a membership request via
BindToRepairHead.
RequestAck(session, memberlist, seqno)
This function is used to request the members in memberlist to ack.
The parameter seqno contains the newest sequence number the repair
head has seen.
RequestFinalAck(session, memberlist, seqno)
This function is used to request the members in memberlist to ack
the receipt of all packets up to seqno (inclusive), which is the
last packet of the session. The repair head cannot exit until it
has fulfilled it obligation to see all members have received the last
packet of the session.
SendRepair(session, [member], seqno)
This function is used to send a repair message. If a member parameter
is included, then the repair head sends a unicast repair message (seqno)
to this member; else the repair message (seqno) is sent to all members
served by this repair head.
Terminate(session, member, reason)
This function is used by the head to terminate a member. Reasons
for termination could be the member is not able to following the
minimum data rate configured for the session, and/or causing the
repair head to fill up its cache.
Resign(session, reason)
This function is used by the head to resign. It provides a way
for its members to gracefully find other repair heads more
quickly (than if the repair head crashed).
1.4) APIs for sender to group interaction:
SessionStart(session)
This function is used by the sender to send a multicast message to the
whole group to indicate a multicast session is about to begin.
SenderStatus(session, status)
This function is used by the sender to tell the whole multicast group
that it is still alive and optionally the sequence number of messages
it has sent thus far. This is typically done when there is a (time)
gap in the data packet stream.
SessionEnd(session, seqno)
This function is used by the sender to tell the whole multicast group
that it has sent out the last packet (seqno). This is an optimization
to help the whole group to recognize the end of the session.
2) Algorithms
The following algorithms describe when the above functions are used (only
the cases where it is s not obvious). In the process, we discuss a
number of (configurable) parameters and some internal states of the receiver
and repair heads.
2.1) When to ack
Three events may trigger a receiver to send an ack:
ack window
ack timer
probe
The normal event is the ack window. Ack window is a configured parameter.
(Note, in some implementations, this may be a dynamic parameter tied to
the congestion window). For example, a receiver may be configured to send
an ack once every 32 packets. If the packet stream is continuous and under
normal operation conditions, this may be the only mechanism used to
schedule sending of acks.
The ack timer is also a configured parameter. (Note again, in some
implementations this may be a dynamically adjusted parameter based on
prediction of expected inter-packet arrival times). This mechanism is
typically triggered when losses occur, or when application data has a
(time) gap in it.
The receiver also sends an ack in response to various probes from the repair
head or the sender. For example, the RequestAck, RequestFinalAck,
SessionEnd and RTT computation functions may all trigger a receiver to
send an ack.
2.2) When to request ack
When a repair head detects that a member has not sent an ack for some
interval of time, it requests those members to respond with an ack. This
time is similar to the ack timer discussed above. Request for ack can be
a unicast message (when only one member is being polled) or a multicast
message when multiple members are being polled. The addresses of the
multiple members can be listed in the request message. This enables the
repair heads to disown unresponsive members and reclaim buffers.
Request for ack can also be used to compute RTT between a repair head
and its member.
2.3) Cache management
Depends on the type of late join support and the type of reliability
being supported.
2.4) Repair algorithm
When some member indicates missing packets, the repair head calls the
SendRepair function to queue repairs to the retransmission queue. It is
often the case that multiple members request the same repair. The
implementation of SendRepair must carefully avoid queueing a repair packet
that is already in the queue, or sending a repair that has very recently
been sent.
The repair head also decides when to send an ack via unicast and when
to use multicast to minimize bandwidth usage.
2.5) Session close
The algorithm to close the session is for the sender to call sessionEnd().
This results in a multicast message being transmitted to the whole group
indicating end of session. Each repair head, separately requests all
members in its repair group to send an ack of the final packet. In
case the session end message from the sender is not received by a
repair head, it may be sent multiple times. Failing that, the session
end signal still would propagate down the tree via each repair head
requesting the final ack.
3) Other Hooks
The hooks describe additional ways (other than the abstract API) this
building block interacts with other building blocks and a protocol
instantiation.
3.1) Hooks exported
3.1.1) Missing packet info
Other BB's may need to query this BB for the total number of lost packet
seen and repaired up to now. This information may prove useful for
congestion control, for example in calculating the suitable rate for
transmission; or in determining which member is keeping the group
transmission rate below the minimum data rate.
Similarly, there should be a hook for zeroing the above states to
accommodate the need to restart certain calculations (for example -
when the sender resumes data transmission after a pause).
3.1.2) Cache info
Other BB may be interested in the cache occupancy, or available packets
in the cache.
3.1.3) ackWindow
3.2) Hooks expected from other BB's
3.2.1) Current Data rate
This information probably comes from the congestion control BB. It
may be useful for dynamically setting some timers used to send (or
request) acks.
3.2.2) Keep alive function
The repair head and its member need a keep-alive function which runs in the
absence of repairs. If this is covered in the tree-building BB, then the
hooks are needed by this BB to access it.
3.2.3) Repair scope
The TREE BB may provide a repair scope for controlling the locality of
repairs. The repair scope infomation is needed by this BB too.
3.2.4) Security hook
Security hooks are needed to perform signature/authentication operations
on all BB(protocol) control messages.
4) Issues
Some functions in this BB overlap with functions in the tree configuration
BB. For example, the Bind/Unbind, Accept/Reject would be used during tree
building as well. On the other hand, a receiver and head need some
keep-alive function that we did not specify here now (perhaps we should
have), and expected it be part of the tree maintenance function in the
tree BB.
--Ambush_of_Tigers_512_000--
>From owner-rmt@listserv.lbl.gov Mon Jan 17 12:39:43 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id MAA28297;
Mon, 17 Jan 2000 12:36:17 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id MAA28293
for <rmt@listserv.lbl.gov>; Mon, 17 Jan 2000 12:36:15 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id MAA16294
for <rmt@listserv.lbl.gov>; Mon, 17 Jan 2000 12:36:14 -0800 (PST)
Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id MAA16291
for <rmt@lbl.gov>; Mon, 17 Jan 2000 12:36:13 -0800 (PST)
Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate2.mot.com (VWALL-IN-motgate2 2.0) with ESMTP id NAA12832 for <rmt@lbl.gov>; Mon, 17 Jan 2000 13:36:12 -0700 (MST)]
Received: [from homer.arc.corp.mot.com ([217.1.10.38]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id NAA07552 for <rmt@lbl.gov>; Mon, 17 Jan 2000 13:36:11 -0700 (MST)]
Received: from arc.corp.mot.com ([144.187.5.100])
by homer.arc.corp.mot.com (8.9.3/8.9.3) with ESMTP id HAA03586
for <rmt@lbl.gov>; Tue, 18 Jan 2000 07:31:43 +1100 (EST)
Message-ID: <38837C33.D4D0D71D@arc.corp.mot.com>
Date: Tue, 18 Jan 2000 07:31:47 +1100
From: Roger Kermode <rkermode@arc.corp.mot.com>
Reply-To: Roger.Kermode@motorola.com
Organization: Motorola
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: rmt-list <rmt@lbl.gov>
Subject: RMT: Call For Feb 10 Agenda Items
Content-Type: multipart/mixed;
boundary="------------CA450681D05075CD7872F10A"
Sender: owner-rmt@lbl.gov
Precedence: bulk
This is a multi-part message in MIME format.
--------------CA450681D05075CD7872F10A
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Februrary 10th is rapidly approaching and the next meeting is looming
up quickly.
If everyone could please coordinate with the other people working
on your respecitve building block drafts, and send potential
agenda items to me as you can I would be most grateful.
Thanks!
Roger
--------------CA450681D05075CD7872F10A
Content-Type: text/x-vcard; charset=us-ascii;
name="rkermode.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Roger Kermode
Content-Disposition: attachment;
filename="rkermode.vcf"
begin:vcard
n:Kermode;Roger
tel;fax:+61-2-9666-0501
tel;home:+61-2-9664-8335
tel;work:+61-2-9666-0558
x-mozilla-html:FALSE
url:www.mot.com.au
org:Motorola Australian Research Centre;Scalable Commodity Internet Lab
version:2.1
email;internet:Roger.Kermode@motorola.com
title:Principal Research Engineer
SNAIL MAIL: Locked Bag 5028, Botany NSW, 1455=0D=0A;Botany;NSW;2019;Australia
adr;quoted-printable:;;PHYSICAL: Level 3, 12 Lord St., Botany, NSW=0D=0A=
x-mozilla-cpt:;-1
fn:Roger Kermode
end:vcard
--------------CA450681D05075CD7872F10A--
>From owner-rmt@listserv.lbl.gov Tue Jan 18 04:23:16 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id EAA29267;
Tue, 18 Jan 2000 04:22:47 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id EAA29263
for <rmt@listserv.lbl.gov>; Tue, 18 Jan 2000 04:22:45 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id EAA28101
for <rmt@listserv.lbl.gov>; Tue, 18 Jan 2000 04:22:44 -0800 (PST)
Received: from bettina.informatik.uni-bremen.de (root@bettina.informatik.uni-bremen.de [134.102.224.3])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id EAA28097
for <rmt@lbl.gov>; Tue, 18 Jan 2000 04:22:43 -0800 (PST)
Received: from cabo2 (dienstmann.informatik.uni-bremen.de [134.102.224.51])
by bettina.informatik.uni-bremen.de (8.8.7/8.8.7) with SMTP id NAA04911;
Tue, 18 Jan 2000 13:22:15 +0100 (MET)
From: "Dr. Carsten Bormann" <cabo@tzi.org>
To: <Roger.Kermode@motorola.com>, "rmt-list" <rmt@lbl.gov>
Subject: RE: Call For Feb 10 Agenda Items
Date: Tue, 18 Jan 2000 13:22:12 +0100
Message-ID: <NDBBLDHFKCPEPDKNKJBKGEMCCOAA.cabo@tzi.org>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
In-Reply-To: <38837C33.D4D0D71D@arc.corp.mot.com>
Sender: owner-rmt@lbl.gov
Precedence: bulk
Are we going to run the meeting as an RMT "plenary" or are we going to split
up into BB/PI subgroups?
I sure have ideas for agenda items for the latter case (which should spawn
some plenary items, too).
Gruesse, Carsten
>From owner-rmt@listserv.lbl.gov Thu Jan 20 15:56:24 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id PAA16368;
Thu, 20 Jan 2000 15:55:40 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id PAA16364
for <rmt@listserv.lbl.gov>; Thu, 20 Jan 2000 15:55:37 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id PAA14413
for <rmt@listserv.lbl.gov>; Thu, 20 Jan 2000 15:55:37 -0800 (PST)
Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id PAA14402
for <rmt@lbl.gov>; Thu, 20 Jan 2000 15:55:36 -0800 (PST)
Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (VWALL-IN-ftpbox 2.0) with ESMTP id QAA07328 for <rmt@lbl.gov>; Thu, 20 Jan 2000 16:55:35 -0700 (MST)]
Received: [from homer.arc.corp.mot.com ([217.1.10.38]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id QAA13142 for <rmt@lbl.gov>; Thu, 20 Jan 2000 16:55:32 -0700 (MST)]
Received: from arc.corp.mot.com (everest.arc.corp.mot.com [217.1.10.204])
by homer.arc.corp.mot.com (8.9.3/8.9.3) with ESMTP id KAA08242
for <rmt@lbl.gov>; Fri, 21 Jan 2000 10:50:52 +1100 (EST)
Message-ID: <38879F5D.C578D26D@arc.corp.mot.com>
Date: Fri, 21 Jan 2000 10:50:53 +1100
From: Roger Kermode <rkermode@arc.corp.mot.com>
Reply-To: Roger.Kermode@motorola.com
Organization: Motorola
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: rmt-list <rmt@lbl.gov>
Subject: [Fwd: RMT meeting Feb 10 at Aciri]
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-rmt@lbl.gov
Precedence: bulk
Ahhh the hazards of copying email...
ACIRI's address is 1947 Center St.
cheers,
Roger
-------- Original Message --------
Subject: RMT meeting Feb 10 at Aciri
Date: Fri, 21 Jan 2000 10:49:36 +1100
From: Roger Kermode <rkermode@arc.corp.mot.com>
Reply-To: Roger.Kermode@motorola.com
Organization: Motorola
To: rmt-list <rmt@lbl.gov>
Just a reminder. The next RMT meeting is as follows:
Date: Thursday, Feb 10, 2000
Venue: ACIRI, Berkeley, CA
Address: 947 Center st., Berkeley, CA
Time: 9:00am - 5:00pm
Hotels: try Shattuck Hotel (510-845-7300) 5 min from ACIRI
So far I have not had an overwhelming response from potential
participants. If we want to keep moving people will need to
step up an work together on defining the various building blocks
and protocol instantiations. Please try to contact the other
people in the various sub-groups and make some progress.
Please contact me ASAP if you wish to present and discuss a draft
Roger
>From owner-rmt@listserv.lbl.gov Thu Jan 20 15:56:24 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id PAA16362;
Thu, 20 Jan 2000 15:54:25 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id PAA16358
for <rmt@listserv.lbl.gov>; Thu, 20 Jan 2000 15:54:23 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id PAA14005
for <rmt@listserv.lbl.gov>; Thu, 20 Jan 2000 15:54:22 -0800 (PST)
Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id PAA13994
for <rmt@lbl.gov>; Thu, 20 Jan 2000 15:54:21 -0800 (PST)
Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by ftpbox.mot.com (VWALL-IN-ftpbox 2.0) with ESMTP id QAA06504 for <rmt@lbl.gov>; Thu, 20 Jan 2000 16:54:20 -0700 (MST)]
Received: [from homer.arc.corp.mot.com ([217.1.10.38]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id QAA24652 for <rmt@lbl.gov>; Thu, 20 Jan 2000 16:54:17 -0700 (MST)]
Received: from arc.corp.mot.com (everest.arc.corp.mot.com [217.1.10.204])
by homer.arc.corp.mot.com (8.9.3/8.9.3) with ESMTP id KAA08206
for <rmt@lbl.gov>; Fri, 21 Jan 2000 10:49:34 +1100 (EST)
Message-ID: <38879F10.81A21BA3@arc.corp.mot.com>
Date: Fri, 21 Jan 2000 10:49:36 +1100
From: Roger Kermode <rkermode@arc.corp.mot.com>
Reply-To: Roger.Kermode@motorola.com
Organization: Motorola
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: rmt-list <rmt@lbl.gov>
Subject: RMT meeting Feb 10 at Aciri
Content-Type: multipart/mixed;
boundary="------------EF676A36CF60A9D1D1456D53"
Sender: owner-rmt@lbl.gov
Precedence: bulk
This is a multi-part message in MIME format.
--------------EF676A36CF60A9D1D1456D53
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Just a reminder. The next RMT meeting is as follows:
Date: Thursday, Feb 10, 2000
Venue: ACIRI, Berkeley, CA
Address: 947 Center st., Berkeley, CA
Time: 9:00am - 5:00pm
Hotels: try Shattuck Hotel (510-845-7300) 5 min from ACIRI
So far I have not had an overwhelming response from potential
participants. If we want to keep moving people will need to
step up an work together on defining the various building blocks
and protocol instantiations. Please try to contact the other
people in the various sub-groups and make some progress.
Please contact me ASAP if you wish to present and discuss a draft
Roger
--------------EF676A36CF60A9D1D1456D53
Content-Type: text/x-vcard; charset=us-ascii;
name="rkermode.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Roger Kermode
Content-Disposition: attachment;
filename="rkermode.vcf"
begin:vcard
n:Kermode;Roger
tel;fax:+61-2-9666-0501
tel;home:+61-2-9664-8335
tel;work:+61-2-9666-0558
x-mozilla-html:FALSE
url:www.mot.com.au
org:Motorola Australian Research Centre;Scalable Commodity Internet Lab
version:2.1
email;internet:Roger.Kermode@motorola.com
title:Principal Research Engineer
SNAIL MAIL: Locked Bag 5028, Botany NSW, 1455=0D=0A;Botany;NSW;2019;Australia
adr;quoted-printable:;;PHYSICAL: Level 3, 12 Lord St., Botany, NSW=0D=0A=
x-mozilla-cpt:;-1
fn:Roger Kermode
end:vcard
--------------EF676A36CF60A9D1D1456D53--
>From owner-rmt@listserv.lbl.gov Fri Jan 21 01:39:04 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id BAA17369;
Fri, 21 Jan 2000 01:38:14 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id BAA17365
for <rmt@listserv.lbl.gov>; Fri, 21 Jan 2000 01:38:12 -0800 (PST)
From: myzhai@990.net
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id BAA21761
for <rmt@listserv.lbl.gov>; Fri, 21 Jan 2000 01:38:11 -0800 (PST)
Received: from 990.net ([202.102.13.155])
by SpamWall.lbl.gov (8.9.3/8.9.3) with SMTP id BAA21758
for <rmt@lbl.gov>; Fri, 21 Jan 2000 01:38:08 -0800 (PST)
Received: (fmail 29235 invoked by uid 1300); 21 Jan 2000 09:31:11 -0000
Date: 21 Jan 2000 09:31:11 -0000
Message-ID: <20000121093111.29234.fmail@990.net>
Reply-To: myzhai@990.net
To: rmt@lbl.gov
Cc: luby@dfountain.com
Subject: about "ALC"
Content-Transfer-Encoding: 8bit
Sender: owner-rmt@lbl.gov
Precedence: bulk
Hello,everyone,
I am interested in topics about "ALC(Asynchronous Layered Coding)",
where can I find more infomation about it?
Thx
Zjai
__________________________________________________
»¶ÓʹÓýðÁêÈÈÏßÃâ·Ñµç×ÓÓʼþϵͳhttp://www.990.net
>From owner-rmt@listserv.lbl.gov Wed Jan 26 04:15:39 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id EAA12463;
Wed, 26 Jan 2000 04:13:52 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id EAA12459
for <rmt@listserv.lbl.gov>; Wed, 26 Jan 2000 04:13:50 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id EAA22993
for <rmt@listserv.lbl.gov>; Wed, 26 Jan 2000 04:13:49 -0800 (PST)
Received: from smtp1.cluster.oleane.net (smtp1.cluster.oleane.net [195.25.12.16])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id EAA22988
for <rmt@lbl.gov>; Wed, 26 Jan 2000 04:13:48 -0800 (PST)
Received: from oleane (dyn-1-1-009.Vin.dialup.oleane.fr [195.25.4.9]) by smtp1.cluster.oleane.net with SMTP id NAA52637; Wed, 26 Jan 2000 13:12:44 +0100 (CET)
Message-ID: <008c01bf67f6$3f458680$0401a8c0@oleane.com>
From: "Peter Lewis" <peter.lewis@upperside.fr>
To: <Undisclosed-Recipient:@smtp1.cluster.oleane.net;>
Subject: SIP 2000 Call for Papaer
Date: Wed, 26 Jan 2000 13:09:46 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_0089_01BF67FE.9E62EA60"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-rmt@lbl.gov
Precedence: bulk
This is a multi-part message in MIME format.
------=_NextPart_000_0089_01BF67FE.9E62EA60
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
SIP 2000: Beyond H.323? A scientific committe composed of the most =
eminent experts in this technology will review the abstracts submitted =
from the Call For Papers:
http://www.upperside.fr/basip.htm
Take a look at the exhibition list.
------=_NextPart_000_0089_01BF67FE.9E62EA60
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>
<DIV><FONT face=3DArial size=3D2>
<DIV><FONT color=3D#000000 size=3D2>SIP 2000: Beyond H.323? A scientific =
committe=20
composed of the most eminent experts in this technology will review the=20
abstracts submitted from the Call For Papers:</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2><A=20
href=3D"http://www.upperside.fr/basip.htm">http://www.upperside.fr/basip.=
htm</A></FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2>Take a look at the exhibition=20
list.</FONT></FONT></DIV></DIV></FONT></DIV>
<DIV> </DIV></BODY></HTML>
------=_NextPart_000_0089_01BF67FE.9E62EA60--
>From owner-rmt@listserv.lbl.gov Thu Jan 27 09:57:08 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id JAA23890;
Thu, 27 Jan 2000 09:55:01 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id JAA23886
for <rmt@listserv.lbl.gov>; Thu, 27 Jan 2000 09:54:59 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id JAA22036
for <rmt@listserv.lbl.gov>; Thu, 27 Jan 2000 09:54:58 -0800 (PST)
Received: from hercules.cs.ucsb.edu (hercules.cs.ucsb.edu [128.111.41.30])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id JAA22033
for <rmt@lbl.gov>; Thu, 27 Jan 2000 09:54:57 -0800 (PST)
Received: from jackson.cs.ucsb.edu (jackson [128.111.52.10])
by hercules.cs.ucsb.edu (8.8.6/8.8.6) with ESMTP id JAA22607;
Thu, 27 Jan 2000 09:54:40 -0800 (PST)
Received: by jackson.cs.ucsb.edu (8.9.3+Sun/SMI-SVR4)
id JAA25324 for ; Thu, 27 Jan 2000 09:54:36 -0800 (PST)
Date: Thu, 27 Jan 2000 09:54:36 -0800 (PST)
From: almeroth@cs.ucsb.edu (Kevin C. Almeroth)
Message-Id: <200001271754.JAA25324@jackson.cs.ucsb.edu>
To: almeroth@cs.ucsb.edu
Cc: nonnen@eurecom.fr
Subject: Reminder, CFP: Integrating Multicast into the Internet
Sender: owner-rmt@lbl.gov
Precedence: bulk
Reminder, DEADLINE February 1, 2000
CALL FOR PAPERS:
Special Issue of Computer Communications on
Integrating Multicast into the Internet
CFP URL: http://www.cs.ucsb.edu/~almeroth/COMCOM:cfp.html
Journal URL: http://www.elsevier.com/inca/publications/store/5/2/5/4/4/0/
TOPICS:
The amount of bandwidth available in the Internet is increasing
dramatically, both in the backbone networks, as well as in the last mile
(broadband access). One consequence is that the delivery of high-quality
multimedia data will become feasible, and multimedia data, including audio
and video, will become the dominant traffic. As more users gain access to
broadband services, new applications and services will become possible. The
result will be a growing demand for large-scale multimedia applications and
services.
Multicasting as a pure networking solution to the transport of media is
recognized as offering economies-of-scale for large-scale applications.
Multicast is also believed to enable applications which provide service to
thousands, even millions of customers. While there has been significant
research work on multicast, efforts to successfully deploy a production
service have lagged. Reasons range from frequently changing protocols,
management and engineering problems, legacy hardware limitations, traffic
conflicts with unicast, etc.. This special issue focuses on research issues
dealing with the challenges of deploying multicast in the network. Specific
topics include, but are not limited to:
* Multicast Congestion Control
* Multicast Overlay Networks
* Next-Generation Multicast Routing Algorithms
* Multicast Media Transport
* Security for Multicast-Based Services
* Multicast Traffic Engineering and Management
* Multicast Pricing and Quality of Service
GUEST EDITORS:
Kevin Almeroth Jorg Nonnenmacher
Department of Computer Science Network Research Dept, Lucent Technologies
University of California 600-700 Mountain Avenue
Santa Barbara, CA 93106-5110 Murray Hill, NJ 07974-0636
Phone: +1(805) 893-2777 Phone: +1(908) 582-1707
Fax: +1(805) 893-8553 Fax: +1(908) 582-6632
Email: almeroth@cs.ucsb.edu Email: nonnen@eurecom.fr
IMPORTANT DATES:
Paper Submission Deadline: February 1, 2000
Feedback to Authors: May 1, 2000
Final Manuscripts Due: June 1, 2000
Publication Date: Fall 2000
SUBMISSION INSTRUCTIONS:
Papers should be double spaced, 11pt font, and standard margins. Length
should be 20 pages maximum not including figures, tables, and references.
Maximum total length is 30 pages. Authors are requested to send e-mail
to one or both of the Guest Editors (almeroth@cs.ucsb.edu, nonnen@eurecom.fr)
giving a URL from where a postscript or PDF file can be downloaded (papers
can also be emailed though this is not the preferred format). Successfully
received papers will be acknowledged.
AUTHOR INFORMATION:
Submissions made to the special issue should not have appeared in, or been
submitted to other archival publications. All papers will be subjected to
the journal's usual refereeing process.
>From owner-rmt@listserv.lbl.gov Fri Jan 28 00:50:53 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id AAA25740;
Fri, 28 Jan 2000 00:49:56 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id AAA25736
for <rmt@listserv.lbl.gov>; Fri, 28 Jan 2000 00:49:54 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id AAA29782
for <rmt@listserv.lbl.gov>; Fri, 28 Jan 2000 00:49:53 -0800 (PST)
Received: from pec.etri.re.kr (pec.etri.re.kr [129.254.164.217])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id AAA29779
for <rmt@lbl.gov>; Fri, 28 Jan 2000 00:49:47 -0800 (PST)
Received: from sjkoh (sjkoh.etri.re.kr [129.254.164.46])
by pec.etri.re.kr (8.9.1/8.9.1) with SMTP id RAA27055;
Fri, 28 Jan 2000 17:43:55 +0900 (KST)
Message-ID: <004c01bf696c$845969e0$2ea4fe81@etri.re.kr>
From: "Seok J. Koh" <sjkoh@pec.etri.re.kr>
To: "Dah Ming Chiu - Sun Microsystems" <Dahming.Chiu@east.sun.com>,
<rmt@lbl.gov>
References: <200001122049.PAA25668@bcn.East.Sun.COM>
Subject: Re: ACK Building Block
Date: Fri, 28 Jan 2000 17:48:57 +0900
Organization: ETRI/PEC
MIME-Version: 1.0
Content-Type: text/plain;
charset="Windows-1252"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6600
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by SpamWall.lbl.gov id AAA25737
Sender: owner-rmt@lbl.gov
Precedence: bulk
Hi, there,
The proposal seems to be one of reasonable inputs for initial draft of ACK building block,
even though some addings or modifications are required.
For examples, the scope of ACK building block can be explictly described, and
some assumptions, including that the tree is given by automatic configurations
or can be obtained from external software, may be made.
Anyway, I cannot find the item of ACK building block as the drafting work,
in the plan of this Mid-Feb RMT meeting.
I would like to know why the drafting work of ACK building block has not
been inlcuded as a drafting item at the meeting,
in spite that NACK and GRA BBs were included.
Is that item pre-mature yet ?
or overlapped by the other BBs such as tree building or TRACK ?
cheers,
Seok-Joo, Koh
----- Original Message -----
> Over a month ago, I wrote a short proposal to develop an ACK building
> block, and circulated it to a small set of people in RMT for comment.
> So far, only Brian Whetten and I have been discussing it; and we have
> some different opinions. Since there may be others on the RMT list who
> are interested in the (Tree-based) ACK approach, I would like to move
> the discussion here.
>
> Attached is a sketch of an ACK BB (Building Block). I have not updated
> it since I wrote it a month ago. It describes the relationship
> between a receiver and its repair head (repair node), and some basic
> session management functions of the sender, all in terms of an abstract
> API. I have also sketched out some algorithms that need to be specified
> (such as deciding when to ack and request ack), and some hooks to other
> BB's (e.g. congestion control, tree-building). Most importantly, this
> is all quite simple.
>
> I hope this is useful for helping us build the TRACK protocol standards
> as we move ahead. Comments are welcome.
>
> Dah Ming Chiu
>From owner-rmt@listserv.lbl.gov Mon Jan 31 05:44:57 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id FAA03747;
Mon, 31 Jan 2000 05:43:00 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id FAA03743
for <rmt@listserv.lbl.gov>; Mon, 31 Jan 2000 05:42:57 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id FAA28677
for <rmt@listserv.lbl.gov>; Mon, 31 Jan 2000 05:42:56 -0800 (PST)
Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id FAA28671
for <rmt@lbl.gov>; Mon, 31 Jan 2000 05:42:55 -0800 (PST)
Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate2.mot.com (VWALL-IN-motgate2 2.0) with ESMTP id GAA16741 for <rmt@lbl.gov>; Mon, 31 Jan 2000 06:42:55 -0700 (MST)]
Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [217.1.10.38]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id GAA21000 for <rmt@lbl.gov>; Mon, 31 Jan 2000 06:42:53 -0700 (MST)]
Received: from arc.corp.mot.com ([144.187.5.100])
by homer.arc.corp.mot.com (8.9.3/8.9.3) with ESMTP id AAA20062
for <rmt@lbl.gov>; Tue, 1 Feb 2000 00:42:48 +1100 (EST)
Message-ID: <38959155.B284985C@arc.corp.mot.com>
Date: Tue, 01 Feb 2000 00:42:45 +1100
From: Roger Kermode <rkermode@arc.corp.mot.com>
Reply-To: Roger.Kermode@motorola.com
Organization: Motorola
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: rmt-list <rmt@lbl.gov>
Subject: RMT Agenda Update for Feb 10th
Content-Type: multipart/mixed;
boundary="------------AA49F7503878746450EC11B0"
Sender: owner-rmt@lbl.gov
Precedence: bulk
This is a multi-part message in MIME format.
--------------AA49F7503878746450EC11B0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Dear RMT'ers,
A quick note to let you know that we haven't forgotten about the
agenda for Feb 10th. We're currently, trying to piece together
an order for the presentation requests we have received (speak
up if you haven't already!) We're particularly keen to take
advantage of having an entire day to *REAL* work. To that end
we're looking at an agenda that will *minimize* presentation time
and involve us breaking up into focus groups to work on individual
drafts. Please put your thinking caps on be prepared for detailed
discussions!!!!
An agenda will appear early next week.
The details of the meeting one more time....
Date: Thursday, Feb 10, 2000
Host: ACIRI
Venue: ICSI Building, 6th Floor
Address: 1947 Center st., Berkeley, CA
Time: 9:30am - 5:00pm
Hotels: try Shattuck Hotel (510-845-7300) 5 min from ACIRI
cheers,
Roger
Allison
Lorenzo
--------------AA49F7503878746450EC11B0
Content-Type: text/x-vcard; charset=us-ascii;
name="rkermode.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Roger Kermode
Content-Disposition: attachment;
filename="rkermode.vcf"
begin:vcard
n:Kermode;Roger
tel;cell:+61-408-212-284
tel;fax:+61-2-9666-0501
tel;home:+61-2-9664-8335
tel;work:+61-2-9666-0558
x-mozilla-html:FALSE
-mozilla-cpt:;-1;;;
url:www.mot.com.au
org:Motorola Australian Research Centre;Scalable Commodity Internet Lab
version:2.1
email;internet:Roger.Kermode@motorola.com
title:Australia
adr;quoted-printable:;;PHYSICAL: Level 3, 12 Lord St., Botany, NSW=0D=0A=
x-mozilla-cpt:;0
fn:Roger Kermode
end:vcard
--------------AA49F7503878746450EC11B0--
>From owner-rmt@listserv.lbl.gov Mon Jan 31 09:56:03 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id JAA04951;
Mon, 31 Jan 2000 09:54:55 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id JAA04947
for <rmt@listserv.lbl.gov>; Mon, 31 Jan 2000 09:54:53 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id JAA24748
for <rmt@listserv.lbl.gov>; Mon, 31 Jan 2000 09:54:53 -0800 (PST)
Received: from phobos.talarian.com (mailhost.talarian.com [207.5.32.17])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id JAA24743
for <rmt@lbl.gov>; Mon, 31 Jan 2000 09:54:51 -0800 (PST)
Received: from tahoe (ta036.talarian.com [204.147.187.36] (may be forged)) by phobos.talarian.com (8.9.0/8.9.0) with SMTP id JAA02374; Mon, 31 Jan 2000 09:54:31 -0800 (PST)
Message-Id: <4.1.20000131092342.0223a6b0@mailhost.talarian.com>
X-Sender: bwhetten@mailhost.talarian.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1
Date: Mon, 31 Jan 2000 09:35:19 -0800
To: Roger.Kermode@motorola.com, rmt-list <rmt@lbl.gov>
From: Brian Whetten <whetten@talarian.com>
Subject: Re: RMT Agenda Update for Feb 10th
In-Reply-To: <38959155.B284985C@arc.corp.mot.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-rmt@lbl.gov
Precedence: bulk
Hi all,
I'm looking at the amount of work to do, and am beginning to feel that one
day won't be nearly enough. Is there any way that we can extend this to
Friday as well? It seems like we really need to lock everyone in a room
for about a week...but that is obviously not going to happen given all our
frightening schedules.
As a second possibility, which I'll just throw out as an open invitation, I
have access to a couple free condos in South Lake Tahoe, 5 minutes from
Heavenly (some of the best terrain in the country, although our snow isn't
quite as good as Utah or Colorado). Would people be tempted (especially
the non-west coasters?) in to a combined work/play weekend? I can't think
of a better place I'd rather work on writing billions of pages of
documents. ;)
Brian
At 12:42 AM 2/1/2000 +1100, Roger Kermode wrote:
>Dear RMT'ers,
>
>A quick note to let you know that we haven't forgotten about the
>agenda for Feb 10th. We're currently, trying to piece together
>an order for the presentation requests we have received (speak
>up if you haven't already!) We're particularly keen to take
>advantage of having an entire day to *REAL* work. To that end
>we're looking at an agenda that will *minimize* presentation time
>and involve us breaking up into focus groups to work on individual
>drafts. Please put your thinking caps on be prepared for detailed
>discussions!!!!
>
>An agenda will appear early next week.
>
>
>The details of the meeting one more time....
>
> Date: Thursday, Feb 10, 2000
> Host: ACIRI
> Venue: ICSI Building, 6th Floor
> Address: 1947 Center st., Berkeley, CA
> Time: 9:30am - 5:00pm
> Hotels: try Shattuck Hotel (510-845-7300) 5 min from ACIRI
>
>cheers,
>
>Roger
>Allison
>Lorenzo
>From owner-rmt@listserv.lbl.gov Mon Jan 31 10:20:52 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id KAA05223;
Mon, 31 Jan 2000 10:20:34 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id KAA05209
for <rmt@listserv.lbl.gov>; Mon, 31 Jan 2000 10:20:29 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id KAA04400
for <rmt@listserv.lbl.gov>; Mon, 31 Jan 2000 10:20:28 -0800 (PST)
Received: from aardvark.aciri.org (aardvark.aciri.org [192.150.187.20])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id KAA04395
for <rmt@lbl.gov>; Mon, 31 Jan 2000 10:20:28 -0800 (PST)
Received: from aardvark.aciri.org (localhost [127.0.0.1])
by aardvark.aciri.org (8.9.3/8.9.2) with ESMTP id KAA50247;
Mon, 31 Jan 2000 10:17:43 -0800 (PST)
(envelope-from mjh@aardvark.aciri.org)
From: Mark Handley <mjh@aciri.org>
X-Organisation: ACIRI
To: Brian Whetten <whetten@talarian.com>
cc: Roger.Kermode@motorola.com, rmt-list <rmt@lbl.gov>
Subject: Re: RMT Agenda Update for Feb 10th
In-reply-to: Your message of "Mon, 31 Jan 2000 09:35:19 PST."
<4.1.20000131092342.0223a6b0@mailhost.talarian.com>
Date: Mon, 31 Jan 2000 10:17:43 -0800
Message-ID: <50245.949342663@aardvark.aciri.org>
Sender: owner-rmt@lbl.gov
Precedence: bulk
>I'm looking at the amount of work to do, and am beginning to feel that one
>day won't be nearly enough. Is there any way that we can extend this to
>Friday as well? It seems like we really need to lock everyone in a room
>for about a week...but that is obviously not going to happen given all our
>frightening schedules.
We're hosting the SMuG RG meeting on Friday 11th, so the lecture room
here won't be available, which is the only room that can host 40+
people. We also have a few smaller conference rooms and a number of
offices people can use, so it would be possible to continue into
Friday. However, I suspect that this is best done only by individual
sub-groups that wish to continue working on a specific topic.
So, sub-groups: let me know if you want to continue on the Friday
(preferably in advance, but we can usually be fairly flexible even
without notice) and let me know how many people you expect to be.
I'll then try and sort out appropriate rooms.
Cheers,
Mark
BTW, some SMuG people had trouble booking the suggested hotel.
There's also a list of hotels at
http://www.lbl.gov/Workplace/near-our-shuttle.html
All the starred ones are reasonably close to ICSI.
>From owner-rmt@listserv.lbl.gov Mon Feb 7 21:12:46 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id VAA18917;
Mon, 7 Feb 2000 21:09:36 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id VAA18913
for <rmt@listserv.lbl.gov>; Mon, 7 Feb 2000 21:09:34 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id VAA22212
for <rmt@listserv.lbl.gov>; Mon, 7 Feb 2000 21:09:33 -0800 (PST)
Received: from motgate.mot.com (motgate.mot.com [129.188.136.100])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id VAA22203
for <rmt@lbl.gov>; Mon, 7 Feb 2000 21:09:32 -0800 (PST)
Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate.mot.com (VWALL-IN-motgate 2.0) with ESMTP id WAA14006 for <rmt@lbl.gov>; Mon, 7 Feb 2000 22:09:31 -0700 (MST)]
Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [217.1.10.38]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id WAA27013 for <rmt@lbl.gov>; Mon, 7 Feb 2000 22:09:26 -0700 (MST)]
Received: from arc.corp.mot.com (t-il06-w-port2.corp.mot.com [129.188.170.92])
by homer.arc.corp.mot.com (8.9.3/8.9.3) with ESMTP id QAA09496
for <rmt@lbl.gov>; Tue, 8 Feb 2000 16:08:32 +1100 (EST)
Message-ID: <389FA4D0.5F79900D@arc.corp.mot.com>
Date: Tue, 08 Feb 2000 16:08:32 +1100
From: Roger Kermode <rkermode@arc.corp.mot.com>
Reply-To: Roger.Kermode@motorola.com
Organization: Motorola
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: rmt-list <rmt@lbl.gov>
Subject: RMT Meeting Agenda, Feb 10
Content-Type: multipart/mixed;
boundary="------------F79A41C7056DC60F7258F12F"
Sender: owner-rmt@lbl.gov
Precedence: bulk
This is a multi-part message in MIME format.
--------------F79A41C7056DC60F7258F12F
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Dear RMT'ers,
A tentative agenda for the feb 10 meeting is attached below.
Note that we have deliverately kept the presentations short,
as we'd like to maximize the time for discussions. Those of you
of have replied and have recevied slots should keep your
presentations to roughly 5 slides in bullet form and hit the
major points you want to bring up for discussion. If you need to
convey additional information please do so by posting it to the
list prior to the meeting. However, keep in mind that people are
unlikely to read long papers before the meeting.
See you on Thursday,
cheers,
Roger
Allison
Lorenzo
-----------------------------------------------------------------
RMT Interim Meeting
Thursday Febraruy 10th, ACIRI
1947 Center st., Berkeley, CA
Directions to ICSI are at
http://www.icsi.berkeley.edu/where.html
Tentative Agenda
---------------------------------
09:00 - 09:10 10 mins Agenda Bashing
[Roger]
09:10 - 09:10 10 mins WG status update
bb + ds drafts
Recharter
09:10 - 09:20 10 mins Call to arms/editorship selection update
[Roger]
09:20 - 09:40 40 mins Guidelines Draft Update/Discussion
[Roger/Lorenzo/Allison]
10 mins draft outline
30 mins discussion
10:00 - 11:20 1hr20mins Congestion Control: [Handley/Flloyd?]
10 mins TFMCC update [Handley/Flloyd]
10 mins ALC implications for CC [Luby]
10 mins TEAR implications for CC [Rhee]
10 mins Generic source-based multicast CC
[Kalyanaraman]
40 mins discussion
11:20 - 12:20 1hr NACK: [Bormann & Adamson?]
10 mins BB Update [Borman]
20 mins BB Discussion
10 mins PI Update [Adamson]
20 mins PI Discusion
12:20 - 13:00 1hr Lunch
13:00 - 14:00 1hr Asynchronous Layered Coding: [Luby]
10 mins BB update
10 mins Gemmell?
40 mins discussion
14:00 - 14:30 1hr Tree-Building: [??]
10 mins table of contents update [Chiu]
20 mins discussion
14:30 - 16:00 1hr TRACK progress [Whetten/Chiu]
10 mins [Whetten]
10 mins [Chiu]
40 mins Discussion
16:00 - 16:45 45 mins VACANT
16:45 - 17:00 15 mins Agenda bashing for Adelaide
--------------F79A41C7056DC60F7258F12F
Content-Type: text/x-vcard; charset=us-ascii;
name="rkermode.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Roger Kermode
Content-Disposition: attachment;
filename="rkermode.vcf"
begin:vcard
n:Kermode;Roger
tel;cell:+61-408-212-284
tel;fax:+61-2-9666-0501
tel;home:+61-2-9664-8335
tel;work:+61-2-9666-0558
x-mozilla-html:FALSE
-mozilla-cpt:;0;;;
url:www.mot.com.au
org:Motorola Australian Research Centre;Scalable Commodity Internet Lab
version:2.1
email;internet:Roger.Kermode@motorola.com
title:Principal Research Engineer
adr;quoted-printable:;;PHYSICAL: Level 3, 12 Lord St., Botany, NSW=0D=0A=
x-mozilla-cpt:;0
fn:Roger Kermode
end:vcard
--------------F79A41C7056DC60F7258F12F--
>From owner-rmt@listserv.lbl.gov Tue Feb 8 22:03:00 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id WAA21640;
Tue, 8 Feb 2000 22:00:34 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id WAA21636
for <rmt@listserv.lbl.gov>; Tue, 8 Feb 2000 22:00:32 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id WAA14062
for <rmt@listserv.lbl.gov>; Tue, 8 Feb 2000 22:00:23 -0800 (PST)
Received: from phobos.talarian.com (mailhost.talarian.com [207.5.32.17])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id WAA14059
for <rmt@lbl.gov>; Tue, 8 Feb 2000 22:00:22 -0800 (PST)
Received: from tahoe ([207.5.32.66]) by phobos.talarian.com (8.9.0/8.9.0) with SMTP id VAA23403; Tue, 8 Feb 2000 21:58:21 -0800 (PST)
Message-Id: <4.1.20000208161711.01d31880@mailhost.talarian.com>
X-Sender: bwhetten@mailhost.talarian.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1
Date: Tue, 08 Feb 2000 16:24:25 -0800
To: smug@baynetworks.com, rmt@lbl.gov
From: Brian Whetten <whetten@talarian.com>
Subject: Security Considerations for TRACK Protocols
Mime-Version: 1.0
Content-Type: multipart/mixed;
boundary="=====================_246435064==_"
Sender: owner-rmt@lbl.gov
Precedence: bulk
--=====================_246435064==_
Content-Type: text/plain; charset="us-ascii"
Hello all,
Sorry for those who get duplicates of this. Please find attached a draft
Thomas Hardjorno and I did to analyze the security considerations for TRACK
protocols. This is still rough, isn't formatted correctly, and isn't an
official IETF draft yet. We will be discussing this at the SMUG meeting on
Friday.
Brian
--=====================_246435064==_
Content-Type: text/plain; name="draft-ietf-rmt-track-security-xx.txt";
x-mac-type="54455854"; x-mac-creator="74747874"
Content-Transfer-Encoding: x-uuencode
Content-Disposition: attachment; filename="draft-ietf-rmt-track-security-xx.txt"
begin 600 draft-ietf-rmt-track-security-xx.txt
M#0I);G1E<FYE="!%;F=I;F5E<FEN9R!487-K($9O<F-E("`@("`@("`@("`@
M("`@("`@("`@("`@("`@("!4+B!(87)D:F]N;PT*24Y415).150M1%)!1E0@
M("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("!.;W)T
M96P@3F5T=V]R:W,-"F1R869T+6EE=&8M<FUT+71R86-K+7-E8W5R:71Y+7AX
M+G1X="`@("`@("`@("`@("`@("`@("`@("`@("!"+B!7:&5T=&5N#0I*86YU
M87)Y(#$R+"`R,#`P("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@
M("`@("`@("`@("`@("!486QA<FEA;@T*#0H-"@T*#0H@("`@("`@("`@("`@
M4V5C=7)I='D@4F5Q=6ER96UE;G1S($9O<B!44D%#2R!0<F]T;V-O;',-"@T*
M("`@("`@("`@("`@("`\9')A9G0M:65T9BUR;70M=')A8VLM<V5C=7)I='DM
M>'@N='AT/@T*#0H-"E-T871U<R!O9B!T:&ES($UE;6\-"@T*("`@5&AI<R!D
M;V-U;65N="!I<R!A;B!);G1E<FYE="U$<F%F="!A;F0@:7,@:6X@9G5L;"!C
M;VYF;W)M86YC90T*("`@=VET:"!A;&P@<')O=FES:6]N<R!O9B!396-T:6]N
M(#$P(&]F(%)&0S(P,C8N#0H-"B`@($EN=&5R;F5T+41R869T<R!A<F4@=V]R
M:VEN9R!D;V-U;65N=',@;V8@=&AE($EN=&5R;F5T($5N9VEN965R:6YG#0H@
M("!487-K($9O<F-E("A)151&*2P@:71S(&%R96%S+"!A;F0@:71S('=O<FMI
M;F<@9W)O=7!S+B`@3F]T92!T:&%T#0H@("!O=&AE<B!G<F]U<',@;6%Y(&%L
M<V\@9&ES=')I8G5T92!W;W)K:6YG(&1O8W5M96YT<R!A<PT*("`@26YT97)N
M970M1')A9G1S+@T*#0H@("!);G1E<FYE="U$<F%F=',@87)E(&1R869T(&1O
M8W5M96YT<R!V86QI9"!F;W(@82!M87AI;75M(&]F('-I>`T*("`@;6]N=&AS
M(&%N9"!M87D@8F4@=7!D871E9"P@<F5P;&%C960L(&]R(&]B<V]L971E9"!B
M>2!O=&AE<@T*("`@9&]C=6UE;G1S(&%T(&%N>2!T:6UE+B`@270@:7,@:6YA
M<'!R;W!R:6%T92!T;R!U<V4@26YT97)N970M#0H@("!$<F%F=',@87,@<F5F
M97)E;F-E(&UA=&5R:6%L(&]R('1O(&-I=&4@=&AE;2!O=&AE<B!T:&%N(&%S
M#0H@("`B=V]R:R!I;B!P<F]G<F5S<RXB#0H-"B`@(%1H92!L:7-T(&]F(&-U
M<G)E;G0@26YT97)N970M1')A9G1S(&-A;B!B92!A8V-E<W-E9"!A=`T*("`@
M:'1T<#HO+W=W=RYI971F+F]R9R]I971F+S%I9"UA8G-T<F%C=',N='AT#0H@
M("!4:&4@;&ES="!O9B!);G1E<FYE="U$<F%F="!3:&%D;W<@1&ER96-T;W)I
M97,@8V%N(&)E(&%C8V5S<V5D(&%T#0H@("!H='1P.B\O=W=W+FEE=&8N;W)G
M+W-H861O=RYH=&UL+@T*#0H-"D%B<W1R86-T#0H-"E1H:7,@9&]C=6UE;G0@
M9&ES8W5S<V5S('1H92!S96-U<FET>2!I<W-U97,@=VET:&EN(%12964M8F%S
M960@#0I!0TMN;W=L961G96UE;G0@*%1204-+*2!R96QI86)L92!M=6QT:6-A
M<W0@<')O=&]C;VQS+"!A;F0@:61E;G1I9FEE<R`-"G-O;64@8V]N<W1R86EN
M=',@86YD(')E<75I<F5M96YT<R!F;W(@<V5C=7)I='D@<')O=FES:6]N<R!F
M;W(@=&AE<V4@#0IP<F]T;V-O;',N("!"87-E9"!O;B!T:&4@8V]N<W1R86EN
M=',@86YD(')E<75I<F5M96YT<RP@=&AE(&1O8W5M96YT(`T*<')O<&]S97,@
M82!S97!A<F%T:6]N(&]F(&1A=&$@<&%C:V5T(&-O;F9I9&5N=&EA;&ET>2!A
M;F0@875T:&5N=&EC871I;VXL(`T*9G)O;2!T<F%N<W!O<G0@;&%Y97(@<')O
M=&5C=&EO;BX@($ET('!R;W!O<V5S('1H870@5%)!0TL@<')O=&]C;VQS(&)E
M(`T*<')I;6%R:6QY(&-O;F-E<FYE9"!W:71H(&=R;W5P(&%U=&AE;G1I8V%T
M:6]N(&]F(&-O;G1R;VP@86YD(&1A=&$@#0IP86-K971S+"!T;R!P<F]T96-T
M(&%G86EN<W0@871T86-K<R!O;B!T:&4@=')A;G-P;W)T(&EN9G)A<W1R=6-T
M=7)E+B`@270@#0IP<F]P;W-E<R!T:&%T(&1A=&$@8V]N9FED96YT:6%L:71Y
M(&%N9"!S;W5R8V4@875T:&5N=&EC871I;VX@8F4@<')O=FED960@#0IS97!A
M<F%T96QY(&9R;VT@=&AI<R!L;W<@;&5V96P@9W)O=7`@875T:&5N=&EC871I
M;VXL(&ED96%L;'D@870@=&AE(`T*87!P;&EC871I;VX@;&5V96PN("!792!S
M:&]W('1H870@=&AI<R!I<R!P87)T:6-U;&%R;'D@:6UP;W)T86YT(&9O<B`-
M"E1204-+('!R;W1O8V]L<RP@8F5C875S92!O9B!T:&4@<F5Q=6ER96UE;G0@
M=&AA="!T:&4@:6YT97)I;W(@8V]N=')O;"`-"FYO9&5S(&]N;'D@;W!T:6]N
M86QL>2!H879E(&%C8V5S<R!T;R!T:&4@9&%T82!P86-K970@<&%Y;&]A9"X-
M"@T*4W!E8VEF:6-A;&QY+"!T:&4@8W5R<F5N="!W;W)K('!R;W!O<V5S('1H
M870@9&%T82!A;F0@8V]N=')O;"!P86-K970@#0IA=71H96YT:6-A=&EO;B!B
M92!P<F]V:61E9"!U<VEN9R!)4'-E8RUB87-E9"!A=71H96YT:6-A=&EO;B!A
M="!T:&4@#0IN971W;W)K(&QA>65R+B`@5&AI<R!A<'!R;V%C:"!A;&QO=W,@
M86X@:6YT97)I;W(@8V]N=')O;"!N;V1E('1O(`T*875T:&5N=&EC86QL>2!R
M971R86YS;6ET(&$@;&]S="!D871A('!A8VME="`H=VAI8V@@<F5M86EN<R!E
M;F-R>7!T960@#0IU;F1E<B!T:&4@<V5P87)A=&4@9&%T82UE;F-R>7!T:6]N
M(&ME>2D@=&\@:71S(&]W;B!C:&EL9')E;B`H82!S970@;V8@#0I296-E:79E
M<G,I+"!W:&EL92!M86MI;F<@=7-E(&]F('1H92!)4'-E8R!F96%T=7)E<RP@
M<W5C:"!A<R!P<F]T96-T:6]N(`T*86=A:6YS="!R97!L87D@871T86-K<RX@
M(`T*#0I4:&ES(&1O8W5M96YT('1H96X@<')O=FED97,@82!S<&5C:69I8R!P
M<F]P;W-A;"!F;W(@:&]W(&=R;W5P(&ME>7,@#0IS:&]U;&0@8F4@9&EV:61E
M9"!U<"!A;6]N9R!G<F]U<"!M96UB97)S+"!F;W(@8V]N=')O;"!A;F0@9&%T
M82!P86-K970@#0IA=71H96YT:6-A=&EO;BX@(%=H:6QE('!R;W9I9&EN9R!S
M;VUE(')A=&EO;F%L92!F;W(@9&EV;W)C:6YG('1H:7,@#0IP<F]P;W-A;"!F
M<F]M('1H870@;V8@<V]U<F-E(&%U=&AE;G1I8V%T:6]N(&%N9"!D871A(&-O
M;F9I9&5N=&EA;&ET>2P@:70@#0ID;V5S(&YO="!P<F]V:61E(&$@<W!E8VEF
M:6,@<')O<&]S86P@9F]R('1H;W-E('!I96-E<RX-"@T*#0HQ+B!"86-K9W)O
M=6YD.B!4:&4@375L=&EC87-T(%-E8W5R:71Y(%!R;V)L96T-"@T*5&AE('!R
M;V)L96T@;V8@;75L=&EC87-T('-E8W5R:71Y(&-A;B!B92!D:79I9&5D(&EN
M=&\@=&AR964@9V5N97)A;"`-"F%R96%S(&]F(&-O;F-E<FXZ#0HM($1A=&$@
M16YC<GEP=&EO;B!A;F0@4V]U<F-E($%U=&AE;G1I8V%T:6]N+B`@5&AE(&UE
M=&AO9"!U<V5D('1O(`T*96YC:7!H97(@;W(@<V-R86UB;&4@=&AE(&UU;'1I
M8V%S="!D871A+"!A;F0@=F5R:69Y('1H92!I9&5N=&ET>2!O9B`-"G1H92!S
M96YD97(@;V8@=&AI<R!D871A+@T*+2!+97D@1&ES=')I8G5T:6]N+B`@5&AE
M(&UE=&AO9"!U<V5D('1O('-E8W5R96QY(&1I<W1R:6)U=&4@9W)O=7`@#0IK
M97ES(&%N9"!K97EI;F<@;6%T97)I86P@=&\@=&AE(&UE;6)E<G,@;V8@82!G
M<F]U<"P@9F]R('5S92!I;B`-"F1E8W)Y<'1I;F<@;W(@875T:&5N=&EC871I
M;F<@=&AE(&1A=&$@;W(@8V]N=')O;"!P86-K971S+@T*+2!);F9R87-T<G5C
M='5R92!P<F]T96-T:6]N+B`@365C:&%N:7-M<R!U<V5D('1O('!R;W1E8W0@
M=&AE(`T*;75L=&EC87-T(&EN9G)A<W1R=6-T=7)E(&ET<V5L9BP@86YD('1O
M(&UI;FEM:7IE('1H92!A8FEL:71Y(&]F(&%N(`T*:6YT<G5D97(@=&\@9&5N
M>2!S97)V:6-E('1O(&QE9VET:6UA=&4@=7-E<G,N#0H-"E1H92!S96-U<FET
M>2!O9B!R96QI86)L92!M=6QT:6-A<W0@<')O=&]C;VQS(&9A;&QS('!R:6UA
M<FEL>2!I;G1O('1H92`-"G1H:7)D(&-A=&5G;W)Y(&]F('!R;V)L96US+B`@
M0V]M<&QE=&4@9&5N:6%L(&]F('-E<G9I8V4@<')O=&5C=&EO;B!M=7-T(`T*
M<W1A<G0@870@=&AE(&YE='=O<FL@;&5V96P@*&DN92X@25`@375L=&EC87-T
M*2P@=VET:"!C;VYT<F]L<R!P;&%C960@;VX@#0IS96YD97)S(&9R;VT@;W9E
M<FQO861I;F<@=&AE(&YE='=O<FL@=VET:"!B<G5T92!F;W)C92"3<W!A;6UI
M;F>4+"!A<R`-"G=E;&P@87,@=VET:"!A=71H96YT:6-A=&EO;B!O9B!C;VYT
M<F]L('!A8VME=',L('1O(&ME97`@=7-E<G,@9G)O;2`-"F-O<G)U<'1I;F<@
M=&AE('-T871E(&]F('1H92!)4"!-=6QT:6-A<W0@<')O=&]C;VQS+B`@02!T
M<F%N<W!O<G0@#0IP<F]T;V-O;"!N965D<R!T;R!A9&1R97-S('1H92!S86UE
M(&ES<W5E<RP@8VAE8VMI;F<@=&\@;6%K92!S=7)E('1H870@#0IS96YD97)S
M(&%R92!N;W0@<V5N9&EN9R!M;W)E(&1A=&$@=&AA;B!T:&5Y(&%R92!A;&QO
M=V5D("AS=6-H(&%S('=I=&@@#0IE;F9O<F-E86)L92!C;VYG97-T:6]N(&-O
M;G1R;VPI+"!A;F0@875T:&5N=&EC871I;F<@8V]N=')O;"!P86-K971S+"!T
M;R`-"G!R;W1E8W0@=&AE('!R;W1O8V]L('-T871E+B`@0V]N=')O;"!P86-K
M970@875T:&5N=&EC871I;VX@:7,@#0IP87)T:6-U;&%R;'D@:6UP;W)T86YT
M(&EN(%1204-+('!R;W1O8V]L<RP@8F5C875S92!O9B!T:&5I<B!U<V4@;V8@
M#0II;G1E<FEO<B!C;VYT<F]L(&YO9&5S("AF;W(@97AA;7!L92P@:6X@4DU4
M4"U)22P@1%)S(&%N9"!43G,I('1O(`T*:6YC<F5A<V4@<V-A;&%B:6QI='DN
M#0H-"D%N(&]P=&EO;F%L(&5X=&5N<VEO;B!T;R!T:&4@<F5Q=6ER96UE;G0@
M;V8@:6YF<F%S=')U8W1U<F4@<')O=&5C=&EO;B!I<R`-"G1H870@;V8@:6YF
M<F%S=')U8W1U<F4@<')I=F%C>2X@(%-O;64@87!P;&EC871I;VYS(')E<75I
M<F4@=&AA="!T:&4@#0IH96%D97)S(&]F('1H92!N971W;W)K('!A8VME=',@
M8F4@96YC<GEP=&5D+"!T;R!P<F]V:61E('!R;W1E8W1I;VX@9G)O;2`-"FYE
M='=O<FL@86YA;'ES:7,@871T86-K<RX-"@T*#0HR+B!);F1E<&5N9&5N8V4@
M;V8@4DT@4V5C=7)I='D-"@T*5&AE('-E8W5R:71Y(&]F(')E;&EA8FQE(&UU
M;'1I8V%S="`H4DTI('!R;W1O8V]L<R!I<R!P87)T(&]F('1H92!L87)G97(@
M#0IP<F]B;&5M(&]F('1H92!S96-U<FET>2!O9B!T:&4@;75L=&EC87-T(&EN
M9G)A<W1R=6-T=7)E+"!W:&EC:"!A;'-O(`T*8V]N<VES=',@;V8@=&AE('-E
M8W5R:71Y(&]F('1H92!M=6QT:6-A<W0@<F]U=&EN9R!P<F]T;V-O;',N#0H-
M"E-I;F-E(%)-('!R;W1O8V]L<R!A;F0@;75L=&EC87-T(')O=71I;F<@<')O
M=&]C;VQS(&5X:7-T(&%T(&1I9F9E<F5N="`-"FQA>65R<R!I;B!T:&4@<')O
M=&]C;VP@<W1A8VLL(&%N9"!S:6YC92!D:69F97)E;G0@4DT@<')O=&]C;VQS
M(&UA>2!B92`-"F5M<&QO>65D('=I=&@@9&EF9F5R96YT(&UU;'1I8V%S="!R
M;W5T:6YG('!R;W1O8V]L<RP@:70@:7,@=7-E9G5L(&9R;VT@82`-"G-E8W5R
M:71Y('!E<G-P96-T:79E('1O('1R96%T('1H97-E('1W;R!S96-U<FET>2!P
M<F]B;&5M<R!S97!A<F%T96QY+B`@#0I);B!A9&1I=&EO;BP@86QT:&]U9V@@
M:6X@;6%N>2!I;G-T86YC97,@=&AE('1O<&]L;V=Y(&]F(%)-(`T*:6YF<F%S
M=')U8W1U<F4@;6%Y(&-O:6YC:61E('=I=&@@=&AA="!O9B!T:&4@;75L=&EC
M87-T(')O=71I;F<@<')O=&]C;VPL(`T*<W5C:"!S>6UM971R>2!C86YN;W0@
M8F4@87-S=6UE9"!F;W(@86QL(&-A<V5S+@T*#0I3:6UI;&%R;'DL(&9R;VT@
M82!D97-I9VX@<&5R<W!E8W1I=F4L('1H92!P<F]B;&5M(&]F('-E8W5R:6YG
M('1H92!D871A(`T*<W1R96%M("AE+F<N('1H<F]U9V@@8V]N=&5N="!E;F-R
M>7!T:6]N*2!S:&]U;&0@8F4@<V5P87)A=&5D(&9R;VT@=&AE(`T*:7-S=64@
M;V8@<V5C=7)I;F<@<F5L:6%B;&4@;75L=&EC87-T('!R;W1O8V]L<RX-"@T*
M06QT:&]U9V@@=V4@=')E870@4DTM<V5C=7)I='D@87,@86X@:6YD97!E;F1E
M;G0@<')O8FQE;2!F<F]M(&]T:&5R(`T*;75L=&EC87-T('-E8W5R:71Y('!R
M;V)L96US+"!T:&ES(&1O97,@;F]T('!R96-L=61E('5S:6YG('1H92!S;VQU
M=&EO;G,@#0II;B!O=&AE<B!A<F5A<R!I;B!O<F1E<B!T;R!S;VQV92!T:&4@
M<V5C=7)I='D@;F5E9',@;V8@4DTN($9O<B!E>&%M<&QE+"`-"G1H92!U<V4@
M;V8@25!S96,@=&5C:&YO;&]G>2!A="!T:&4@25`@;&%Y97(@=&\@875T:&5N
M=&EC871E(&UU;'1I8V%S="`-"G)O=71I;F<@<')O=&]C;VP@8V]N=')O;"UP
M86-K971S(&-A;B!A;'-O(&)E('5S960@=&\@875T:&5N=&EC871E(%)-(`T*
M8V]N=')O;"UM97-S86=E<RX@($AO=V5V97(L('1H92!I;G-T86YC92!O9B!D
M97!L;WEI;F<@25!S96,@:6X@8F]T:"`-"F-A<V5S(&UU<W0@8F4@9&ES=&EN
M9W5I<VAE9"!A;F0@=')E871E9"!S97!A<F%T96QY+@T*#0H-"C,N(%)-5%`M
M24D@3W9E<G9I97<-"@T*5VAI;&4@;F]T(&YE8V5S<V%R:6QY('1Y<&EC86P@
M;V8@86QL(%1204-+('!R;W1O8V]L<R`H<W5C:"!A<R!44D%-(`T*6TM#5U`P
M,%TI+"!W92!U<V4@=&AE(%)-5%`M24D@<')O=&]C;VP@87,@86X@97AA;7!L
M92!F;W(@86YA;'ES:7,@86YD(`T*9&ES8W5S<VEO;BX@(%1H92!23510+4E)
M('!R;W1O8V]L(&9E871U<F5S(&$@;G5M8F5R(&]F(&5N=&ET:65S('=H:6-H
M(`T*<&%R=&EC:7!A=&4@:6X@82!L;V=I8V%L('1R964@;W(@:&EE<F%R8VAY
M(&%N9"!W:&EC:"!E>&-H86YG92!C;VYT<F]L+0T*;65S<V%G97,@=VET:"!E
M86-H(&]T:&5R+B`@5&AE(&5N=&ET:65S(&%R92!T:&4@5&]P($YO9&4@*%1.
M*2P@=&AE(`T*4V5N9&5R($YO9&5S("A31"DL('1H92!$97-I9VYA=&5D(%)E
M8V5I=F5R($YO9&5S("A$4BD@86YD('1H92!296-E:79E<B`-"DYO9&5S("A2
M3BDN("`-"@T*4DU44"U)22!P;&%C97,@<F5C96EV97)S(&EN=&\@;&]C86P@
M<F5G:6]N<RP@=VAE<F4@96%C:"!R96=I;VX@:7,@#0IA<W-I9VYE9"!T;R!A
M($12+B`@5&AE<V4@9W)O=7!S(&%R92!A<G)A;F=E9"!H:65R87)C:&EC86QL
M>2!A<R!A('1R964@#0IR;V]T960@870@=&AE(%1.+"!W:71H('1H92!$4G,@
M<F5P<F5S96YT:6YG('1H92!N;V1E<R!O9B!T:&4@=')E92P@86YD(`T*=&AE
M(')E8V5I=F5R<R!A<R!T:&4@;&5A=F5S+B`@5&AE('-E;F1E<G,@8V]N;F5C
M="!D:7)E8W1L>2!T;R!T:&4@=&]P(`T*;F]D92P@870@=&AE('1O<"!L87EE
M<B!O9B!T:&4@:&EE<F%R8VAY+B`@5&AE(')E8V5I=F5R<R!S96YD('1H96ER
M(`T*8V]N=')O;"UM97-S86=E<R`H04-+<RP@3D%#2W,L(&5T8RXI('1O('1H
M92!$4B!O9B!T:&5I<B!R96=I;VXN("`-"E)E=')A;G-M:7-S:6]N(&]F(&QO
M<W0@<&%C:V5T<R!M87D@8F4@9&]N92!L;V-A;&QY(&)Y('1H92!$4B!O9B!A
M(`T*9&]M86EN+"!O<B!G;&]B86QL>2!F<F]M('1H92!S96YD97(N("!%86-H
M($12('-E;F1S('1H96ER(&-O;G1R;VP@#0IM97-S86=E<R!T;R!T:&4@1%(@
M870@=&AE(&YE>'0@;&5V96P@=7`@=&AE(&AI97)A<F-H>2X@(%1H:7,@<')O
M8V5S<R!I<R`-"G)E<&5A=&5D('5N=&EL('1H92!43BP@=VAO('1H96X@9F]R
M=V%R9',@=&AE(&-O;G1R;VP@;65S<V%G97,@=&\@=&AE(`T*87!P<F]P<FEA
M=&4@<V5N9&5R+B`@5&AE($12<R!A;F0@5$X@86=G<F5G871E('1H92!P;W-I
M=&EV92`-"F%C:VYO=VQE9&=E;65N=',@9G)O;2!T:&4@<F5C96EV97)S+"!A
M;F0@<W5P<')E<W,@=&AE(')E9'5N9&%N="!N96=A=&EV92`-"F%C:VYO=VQE
M9&=E;65N=',L(&EN(&]R9&5R('1O('-O;'9E('1H92!!0TLO3D%#2R!I;7!L
M;W-I;VX@<')O8FQE;2X-"@T*02!$4B!M86EN=&%I;G,@82!L;V-A;"!M=6QT
M:6-A<W0@9W)O=7`@=&\@:G5S="!I=',@8VAI;&1R96XL(&%N9"`-"G-U8G-C
M<FEB97,@=&\@=&AE(&QO8V%L(&UU;'1I8V%S="!G<F]U<"!O9B!I=',@<&%R
M96YT+B`@02!$4B!U<V5S('1H:7,@#0IL;V-A;"!M=6QT:6-A<W0@9W)O=7`@
M9F]R(')E=')A;G-M:7-S:6]N<R!T;R!I=',@8VAI;&1R96XN("!7:&EL92!2
M3510+0T*24D@=7-E<R!M=6QT:6-A<W0@9F]R(')E=')A;G-M:7-S:6]N(&9R
M;VT@82!$4BP@;W1H97(@5%)!0TL@<')O=&]C;VQS(`T*;6%Y(&-H;V]S92!T
M;R!O<'1I;VYA;&QY('5S92!U;FEC87-T+@T*#0I23510+4E)(&1I<W1I;F=U
M:7-H97,@8F5T=V5E;B!A(&1A=&$@8VAA;FYE;"!A;F0@82!C;VYT<F]L(&-H
M86YN96PN("!!(`T*9&%T82!C:&%N;F5L(&ES(&$@9VQO8F%L(&UU;'1I8V%S
M="!G<F]U<"!C<F5A=&5D('5S:6YG('1H92!U;F1E<FQY:6YG(`T*;75L=&EC
M87-T(')O=71I;F<@<')O=&]C;VPN("!!(&-O;G1R;VP@8VAA;FYE;"!I<R!T
M:&4@:6YT97)C;VYN96-T960@#0IT;W!O;&]G>2!O9B!C;VYT<F]L(&YO9&5S
M+"!F;W(@:&%N9&QI;F<@97)R;W(@<F5C;W9E<GD@86YD('!O<VET:79E(`T*
M<&%C:V5T(&%C:VYO=VQE9&=E;65N=',N#0H-"DEN(&]R9&5R('1O(&]B=&%I
M;B!D871A('!A8VME=',@9G)O;2!T:&4@4V5N9&5R+"!A(%)E8V5I=F5R(&EN
M(&$@9VEV96X@#0I23510+4E)(')E9VEO;B!M=7-T(&IO:6X@=&AE(&UU;'1I
M8V%S="!G<F]U<"`H:2YE+B!T:&4@9&%T82!C:&%N;F5L*2X@(`T*5&AE($12
M(&]F('1H870@<F5G:6]N(&UU<W0@:F]I;B!E=F5R>2!M=6QT:6-A<W0@9W)O
M=7`@=&AA="!I=',@#0ID97-C96YD86YT<R!H879E(&IO:6YE9"X@($YO=&4@
M=&AA="!T:&4@1%)S(&%R92!N;W0@<F5S<&]N<VEB;&4@9F]R(`T*9F]R=V%R
M9&EN9R!T:&4@9&%T82!P86-K971S(&UU;'1I8V%S="!B>2!T:&4@4V5N9&5R
M+"!S:6YC92!T:&%T(&1A=&$@#0IS=')E86T@:7,@<')O<&%G871E9"!B>2!T
M:&4@=6YD97)L>6EN9R!M=6QT:6-A<W0@<F]U=&EN9R!P<F]T;V-O;"X-"@T*
M5&AE(&9I9W5R92!B96QO=R!I;&QU<W1R871E<R!A;B!23510+4E)('1R964@
M=VET:"!M=6QT:7!L92!C;VYT<F]L(`T*;F]D97,N#0H-"B`@("`@("`@("`@
M("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@($A!0TMS#0H@("`@("`@
M("`@("`@("TM+2TM+2TM+2TM/B`H5&]P($YO9&4I+2TM+2TM+2TM+2TM+2TM
M+2T^*%-E;F1E<B!N;V1E*0T*("`@("`@("`@("`@(%X@("`@("`@("`@("`@
M("`@7EY>("`@("`@("`@("`@("`@("`@("`@("`@("`@("!\#0H@("`@("`@
M("`@("`@?"`@("`@("`@("`@("`@+R`@?"`@7"`@("`@("`@("`@("`@("`@
M("`@("`@("`@('P-"B`@("`@("!(04-+<R!\("`@("`@("`@("`@+R`@("!\
M("`@(%P@("`@("`@("`@("`@("`@("`@("`@("`@?`T*("`@("`@("`@("`@
M('P@("`@("`@("`@+R`@("`@('P@("`@("!<("`@("`@("`@("`@("`@("`@
M("`@("!\#0H@("`@("`@("`@("`@?"`@("`@("`@+R`@("`@("`@?"`@("`@
M("`@7"`@("`@*$1E<VEG;F%T960@("`@('P-"B`@("`@("`@("`@("`@("`@
M("`@+R`@("`@("`@("!\("`@("`@("`@(%P@("`@4F5C96EV97(@("`@("`@
M?`T*("`@("`@("`@("`@("`@("`@+R`@("`@("`@("`@('P@("`@("`@("`@
M("!<("`@;F]D92D@("`@("`@("!V#0H@("`@("!#;VYT<F]L("`@1"!2("`@
M("`@("`@("!$(%(@("`@("`@("`@($0@4B`@/"TM+2TM+2TM+2TM+7P-"B`@
M("`@($-H86YN96P@("!>7B`@("`@("`@("`@(%Y>7B`@("`@("`@("`@(%Y>
M("`@("`@("`@("`@("`@?"!$871A#0H@("`@("`@("`@("`@("`O('P@("`@
M("`@("`@("\@?"!<("`@("`@("`@("!\(%P@("`@("`@("`@("`@('P@0VAA
M;FYE;`T*("`@("`@("`@("`@("`O("!\("`@("`@("`@("\@('P@(%P@("`@
M("`@("`@?"`@7"`@("`@("`@("`@("!\#0H@("`@("`@("`@("`@+R`@('P@
M("`@("`@("`O("`@?"`@(%P@("`@("`@("!\("`@7"`@("`@("`@("`@('8-
M"B`@("`@("`@("`@4DX@("!23B`@("`@("!23B`@(%).("`@4DX@("`@("`@
M(%).("`@4DX@("`\+2TM+2TM#0H@("`@("`@("`@("`@("`@("`@("`@("A2
M96-E:79E<B!.;V1E<RD-"@T*#0H-"C0N(%1204-+(%!R;W1O8V]L(%-E8W5R
M:71Y($ES<W5E<R!A;F0@4F5Q=6ER96UE;G1S#0H-"E1H:7,@<V5C=&EO;B!D
M971A:6QS('1H92!S96-U<FET>2!R97%U:7)E;65N=',@9F]R(%1204-+('!R
M;W1O8V]L<R!W:&EC:"`-"F%R92!S:6UI;&%R('1O(%)-5%`M24DN("!4:&5S
M92!R97%U:7)E;65N=',@:6YC;'5D92!G96YE<F%L(&UU;'1I8V%S="`-"G1R
M86YS<&]R="!R97%U:7)E;65N=',L(&%S('=E;&P@87,@<V]M92!R97%U:7)E
M;65N=',@<W!E8VEF:6,@=&\@5%)!0TL@#0IP<F]T;V-O;',N#0H-"C0N,2!"
M86-K9W)O=6YD#0H-"DEN(&%D9')E<W-I;F<@=&AE('-E8W5R:71Y(&ES<W5E
M<R!S<&5C:69I8R!T;R!44D%#2R!P<F]T;V-O;',L(&ET(&ES(`T*=7-E9G5L
M('1O(&-O;G-I9&5R('1H92!G96YE<F%L(&%S<&5C=',@;V8@<V5C=7)I='D@
M<F5L871I;F<@=&\@<F5L:6%B;&4@#0IM=6QT:6-A<W0N#0H-"B`M($QA>65R
M(&EN('=H:6-H('-E8W5R:71Y(&ES(&%P<&QI960Z#0I4:&4@='=O(&QA>65R
M<R!I;B!W:&EC:"!S96-U<FET>2!M96-H86YI<VUS(&%R92!D97!L;WEE9"!A
M<F4@#0IT>7!I8V%L;'D@=&AE(&YE='=O<FL@;&%Y97(@86YD('1H92!A<'!L
M:6-A=&EO;B!L87EE<BX@($EN('1H92`-"FYE='=O<FL@;&%Y97(@=&AE('!R
M;W1O8V]L('1H870@:7,@=&AE(&UO<W0@8V]M;6]N;'D@=7-E9"!I<R!T:&4@
M#0I)4'-E8R!P<F]T;V-O;"P@=VAI8V@@<')O=FED97,@875T:&5N=&EC871I
M;VX@86YD+V]R(&5N8W)Y<'1I;VXN("!);B`-"F5I=&AE<B!C87-E+"!W:71H
M($E0<V5C('1H92!T<F%N<W!O<G0@:&5A9&5R<R`H86YD($E0(&AE861E<G,I
M(&%R92`-"G!R;W1E8W1E9"X@(%=H96X@875T:&5N=&EC871I;VX@86YD+V]R
M(&5N8W)Y<'1I;VX@:7,@87!P;&EE9"!A="!T:&4@#0IA<'!L:6-A=&EO;B!L
M87EE<BP@;F5I=&AE<B!T:&4@=')A;G-P;W)T(&AE861E<G,@;F]R('1H92!)
M4"!H96%D97)S(`T*87)E('!R;W1E8W1E9"X-"@T*("T@5'EP97,@;V8@875T
M:&5N=&EC871I;VXZ#0H@("T@4V]U<F-E+6%U=&AE;G1I8V%T:6]N.B!)9B!P
M=6)L:6,@:V5Y("AA<WEM;65T<FEC*2!C<GEP=&]G<F%P:'D@:7,@#0ID97!L
M;WEE9"P@=VAE<F4@;VYL>2!T:&4@<V5N9&5R(&MN;W=S('1H92!S96-R970M
M:&%L9B!O9B!T:&4@#0IP=6)L:6,@:V5Y('!A:7(L('1H96X@=6YI<75E(")S
M;W5R8V4M875T:&5N=&EC871I;VXB(&-A;B!B92`-"F5S=&%B;&ES:&5D+@T*
M("`M($=R;W5P+6%U=&AE;G1I8V%T:6]N.B!)9B!S:&%R960@:V5Y("AS>6UM
M971R:6,I(&-R>7!T;V=R87!H>2!I<R`-"F1E<&QO>65D(&%N9"!T:&4@:V5Y
M(&ES('-H87)E9"!B>2!M;W)E('1H86X@='=O('!A<G1I97,L('1H96X@#0IO
M;FQY(")G<F]U<"UA=71H96YT:6-A=&EO;B(@8V%N(&)E(&5S=&%B;&ES:&5D
M+B!4:&ES(&UE86YS('1H870@82`-"G)E8V5I=F5R(&EN(&$@9W)O=7`@:7,@
M;VYL>2!C97)T86EN('1H870@=&AE(&5N=&ET>2!T:&%T('-E;G0@=&AE(`T*
M;65S<V%G92!I<R!I;B!P;W-S97-S:6]N(&]F('1H92!S>6UM971R:6,M:V5Y
M+"!A;F0@:7,@=&AU<R`-"F%S<W5M960@=&\@8F4@82!M96UB97(@;V8@=&AE
M(&=R;W5P('-H87)I;F<@=&AE(&ME>2X-"@T*26X@=&AE(&9O;&QO=VEN9RP@
M=&AE(%1204-+('-P96-I9FEC(')E<75I<F5M96YT<R!A<F4@9G5R=&AE<B`-
M"F5L86)O<F%T960N#0H-"@T*-"XR($%U=&AE;G1I8V%T:6]N(&]F($-O;G1R
M;VPM365S<V%G97,-"@T*07,@<W1A=&5D(&%B;W9E+"!T:&4@9&ER96-T;'D@
M<F5L979A;G0@<V5C=7)I='D@8V]N8V5R;B!F;W(@5%)!0TL@#0IP<F]T;V-O
M;',@:7,@<')O=&5C=&EO;B!O9B!T:&4@;75L=&EC87-T(&EN9G)A<W1R=6-T
M=7)E+"!P87)T:6-U;&%R;'D@;V8@#0IT:&4@8V]N=')O;"!T<F5E+"!I;B!O
M<F1E<B!T;R!P<F]V:61E('!R;W1E8W1I;VX@86=A:6YS="!R97!L87D@;W(@
M;W1H97(@#0IA='1A8VMS('=H:6-H('-E96L@=&\@8V]R<G5P="!T:&4@<W1A
M=&4@;V8@=&AE('1R86YS<&]R="!P<F]T;V-O;"X@(%1H92`-"F%U=&AE;G1I
M8V%T:6]N(&]F(&-O;G1R;VP@;65S<V%G97,@97AC:&%N9V5D(&%M;VYG(%12
M04-+('!R;W1O8V]L(`T*96YT:71I97,@<F5P<F5S96YT<R!T:&4@;6EN:6UA
M;"!S96-U<FET>2!M96-H86YI<VUS(&YE8V5S<V%R>2!T;R!D;R!S;RX-"@T*
M5'=O('1Y<&5S(&]F(&%U=&AE;G1I8V%T:6]N(&UE8VAA;FES;7,@8V%N(&)E
M(&%D;W!T960L(&-O<G)E<W!O;F1I;F<@=&\@#0IT:&4@='=O(&)A<VEC('1Y
M<&5S(&]F(&-R>7!T;W-Y<W1E;7,N("!);B!T:&4@8V]N=&5X="!O9B!R96QI
M86)L92`-"FUU;'1I8V%S="P@=&AR;W5G:'!U="!A;F0@;&%T96YC>2!I<R!T
M>7!I8V%L;'D@;V8@:&EG:"!I;7!O<G1A;F-E+"!A;F0@#0IG<F]U<"UA=71H
M96YT:6-A=&EO;B!B87-E9"!O;B!S>6UM971R:6,@8W)Y<'1O9W)A<&AY(&%P
M<&5A<G,@=&\@8F4@#0IP<F5F97)A8FQE+B`@#0H-"D=I=F5N('1H:7,L('1H
M92!E9F9I8VEE;F-I97,@;V8@<WEM;65T<FEC(&ME>2!B87-E9"!A=71H96YT
M:6-A=&EO;B`-"F%P<&5A<B!T;R!O=71W96EG:"!T:&4@8F5N969I=',@;V8@
M<'5B;&EC(&ME>2!B87-E9"!A=71H96YT:6-A=&EO;BX@#0I4:&5R92!A<F4@
M<&]T96YT:6%L;'D@8W)Y<'1O9W)A<&AI8R!S8VAE;65S('1H870@8V%N('!R
M;W9I9&4@=&AE('5N:7%U92`-"G-O=7)C92UA=71H96YT:6-A=&EO;B!O9B!P
M=6)L:6,@:V5Y(&-R>7!T;V=R87!H>2!W:&EL92!P<F]V:61I;F<@=&AE(`T*
M<&5R9F]R;6%N8V4@8VAA<F%C=&5R:7-T:6-S(&]F('-Y;6UE=')I8R!K97D@
M8F%S960@875T:&5N=&EC871I;VX@*&4N9RX@#0IE9F9I8VEE;G0@9&EG:71A
M;"!S:6=N:6YG(&]F('1H92!H87-H+79A;'5E(&]F('-E=F5R86P@9&%T82!P
M86-K971S*2X@(`T*2&]W979E<BP@870@=&AE('!R97-E;G0@=&EM92P@9F]R
M('1H92!G96YE<F%L(&-A<V4@;V8@:6YF<F%S=')U8W1U<F4@#0IP<F]T96-T
M:6]N+"!T:&4@8V]M<&QE>&ET:65S(&]F('1H97-E(&]P=&EO;G,@87!P96%R
M('1O(&]U='=E:6=H('1H92`-"F)E;F5F:71S+@T*#0I4:'5S+"!I;B!S=6UM
M87)Y+"!F;W(@5%)!0TL@<')O=&]C;VP@8V]N=')O;"UM97-S86=E<RP@97AP
M;&EC:70@9W)O=7`M#0IA=71H96YT:6-A=&EO;B!A="!T:&4@25`@;&%Y97(@
M<VAO=6QD(&)E(&1E<&QO>65D('5S:6YG('-Y;6UE=')I8R`-"F-R>7!T;V=R
M87!H>2X@($%L=&AO=6=H(&$@;G5M8F5R(&]F('1E8VAN;VQO9VEE<R!A<F4@
M879A:6QA8FQE+"!W92`-"G!R;W!O<V4@<W!E8VEF:6-A;&QY($E0<V5C+6)A
M<V5D(&%U=&AE;G1I8V%T:6]N('5S:6YG(&$@:V5Y960M:&%S:"`-"F9U;F-T
M:6]N(%M+03DX8BQ-1SDX82Q-1SDX8ET@9'5E('1O(&ET<R!G<F]W:6YG('5S
M92!A;F0@879A:6QA8FEL:71Y+@T*#0I792!D96YO=&4@=&AE('-Y;6UE=')I
M8R!K97D@=7-E9"!F;W(@8V]N=')O;"!M97-S86=E(&%U=&AE;G1I8V%T:6]N
M(&%S(`T*=&AE($EN=&5R:6]R3F]D94ME>2X@5&AE($EN=&5R:6]R3F]D94ME
M>2!I<R!A('-Y;6UE=')I8R!K97D@<VAA<F5D(&)Y(`T*86QL($12<R!A;F0@
M=&AE(%1.('=I=&AI;B!A(&=I=F5N(%)-5%`M24D@;W(@5%)!0TL@:&EE<F%R
M8VAY+B`@5&AE(&ME>2`-"FES(&EN9&5P96YD96YT(&]F(&%N>2!D871A('-T
M<F5A;2P@86YD(&ES('5S960@=&\@875T:&5N=&EC871E(&-O;G1R;VP@#0IP
M86-K971S(&5X8VAA;F=E9"!A;6]N9R!T:&4@1%)S+U1.+B`@#0H-"@T*-"XS
M($YO;BU$96-I<&AE<F%B:6QI='D@;V8@1&%T82!086-K971S(&)Y($12<PT*
M#0I23510+4E)(')E<75I<F5S('1H870@82!$97-I9VYA=&5D(%)E8V5I=F5R
M($YO9&4@*$12*2!J;VEN(&%L;"!O9B!T:&4@#0IM=6QT:6-A<W0@9W)O=7!S
M('1H870@:71S(&1E<V-E;F1A;G1S(&AA=F4@:F]I;F5D+B`@5&AI<R!I<R!A
M;'-O('1R=64@;V8@#0IT:&4@5&]P($YO9&4@*%1.*2X-"@T*1F]R(%1204-+
M('!R;W1O8V]L<R!I="!I<R!P<F5F97)A8FQE('1H870@875T:&5N=&EC871I
M;VX@;65T:&]D<R!B87-E9"`-"F]N(&$@<WEM;65T<FEC(&ME>2!B92!D97!L
M;WEE9"!D=64@=&\@<&5R9F]R;6%N8V4@<F5A<V]N<RX@(%1H:7,@;6%Y(&)E
M(`T*86-H:65V960@97AP;&EC:71L>2P@<W5C:"!A<R!B>2!U<VEN9R!A(&ME
M>65D(&AA<V@@9G5N8W1I;VXL(&]R(`T*:6UP;&EC:71L>2!U<VEN9R!E;F-R
M>7!T:6]N("AW:&5R92!A('-U8V-E<W-F=6P@9&5C<GEP=&EO;B!I;7!L:65S
M('1H92`-"F-I<&AE<G1E>'0@:7,@8F]T:"!U;FUO9&EF:65D(&EN('1R86YS
M:70@86YD('=A<R!G96YE<F%T960@8GD@82!H;VQD97(@#0IO9B!T:&4@<WEM
M;65T<FEC(&ME>2DN#0H-"DAO=V5V97(L(%1204-+('!R;W1O8V]L<R!H879E
M(&$@9G5R=&AE<B!R97%U:7)E;65N="P@;F%M96QY('1H870@=&AE:7(@#0IR
M97!A:7(@;F]D97,@*&DN92X@1%(@86YD(%1.*2!B92`H;W!T:6]N86QL>2D@
M<')E=F5N=&5D(&9R;VT@<F5A9&EN9R!T:&4@#0IM=6QT:6-A<W0@9&%T82X@
M36]R92!S<&5C:69I8V%L;'DL('=E('!E<F-E:79E('1H870@1%)S(&UA>2!B
M92`-"F%D;6EN:7-T97)E9"!A<R!P87)T(&]F(&$@<F5L:6%B:6QI='D@<V5R
M=FEC92!O9F9E<F5D(&)Y('1H:7)D('!A<G1I97,@#0IS=6-H(&%S($E34',N
M("!4:&5S92!T:&ER9"!P87)T:65S(&UA>2!R969U<V4@=&AE(&%B:6QI='D@
M=&\@9&5C:7!H97(@#0ID871A('!A8VME=',@:6X@;W)D97(@=&\@879O:60@
M=&AE(&QE9V%L(')A;6EF:6-A=&EO;G,@;V8@:&%V:6YG(&%C8V5S<R`-"G1O
M('1H92!D871A(&-O;G1E;G1S+B`@5&AU<RP@9G)O;2!T:&4@25-0('!E<G-P
M96-T:79E+"!44D%#2R!P<F]T;V-O;',@#0IM=7-T(&%L;&]W('1H96T@=&\@
M<')O=F4@=&\@=&AE(&-O;G1E;G0M;W=N97(@=&AA="!T:&5Y(&1O(&YO="!P
M;W-S97,@#0IT:&4@;65A;G,@=&\@86QT97(@=&AE(&-O;G1E;G1S('1R86YS
M;6ET=&5D('1H<F]U9V@@=&AE(&UU;'1I8V%S="`-"F=R;W5P<RX-"@T*1VEV
M96X@=&AE(&%B;W9E(')E<75I<F5M96YT(&]F('1H92!$4G,O5$X@86YD('1H
M92!N965D(&9O<B!F87-T(`T*875T:&5N=&EC871I;VXL('=E('!R;W!O<V4Z
M#0H-"BT@=&AE('-E<&%R871I;VX@;V8@9&%T82!S=')E86T@8V]N9FED96YT
M:6%L:71Y('5S:6YG(&5I=&AE<B!A('-Y;6UE=')I8R`-"F]R(&%S>6UM971R
M:6,@:V5Y(&9R;VT@9&%T82!A=71H96YT:6-A=&EO;B!U<VEN9R!A('-Y;6UE
M=')I8R!K97D@*&DN92X@#0IE>'!L:6-I="!G<F]U<"UA=71H96YT:6-A=&EO
M;BDN#0H-"BT@9&%T82!S=')E86T@8V]N9FED96YT:6%L:71Y('=I;&P@8F4@
M8V]N9'5C=&5D(&%T('1H92!A<'!L:6-A=&EO;B`-"FQA>65R+"!W:&EL92!D
M871A(&%U=&AE;G1I8V%T:6]N('5S:6YG(&$@<WEM;65T<FEC(&ME>2!W:6QL
M(&)E(`T*8V]N9'5C=&5D(&%T('1H92!N971W;W)K(&QA>65R+@T*#0HM('-I
M;F-E('1H92!$4G,O5$X@;6%Y(&)E("AO<'1I;VYA;&QY*2!P<F5V96YT960@
M9G)O;2!R96%D:6YG('1H92`-"FUU;'1I8V%S="!D871A+"!T=V\@*#(I(&1I
M9F9E<F5N="!K97ES(&UU<W0@8F4@9&5P;&]Y960@8V]R<F5S<&]N9&EN9R`-
M"G1O('1H92!N965D<R!O9B!D871A('-T<F5A;2!C;VYF:61E;G1I86QI='D@
M86YD(&1A=&$@9W)O=7`M#0IA=71H96YT:6-A=&EO;BX-"@T*#0HT+C0@075T
M:&5N=&EC871I;VX@;V8@1&%T82!2971R86YS;6ES<VEO;G,-"@T*26X@5%)!
M0TL@<')O=&]C;VQS+"!R971R86YS;6ES<VEO;G,@;V8@9&%T82!P86-K971S
M(&UA>2!C;VUE(&9R;VT@=&AE(`T*;W)I9VEN86P@<V]U<F-E+"!O<B!F<F]M
M(&$@9&EF9F5R96YT("A$4BD@;F]D92X@(%1H:7,@;&]C86P@<F5C;W9E<GD@
M:7,@#0IA;B!I;7!O<G1A;G0@=&]O;"!F;W(@:6YC<F5A<VEN9R!T:&4@<V-A
M;&%B:6QI='D@86YD(&QA=&5N8WD@;V8@82`-"G!R;W1O8V]L+B`@26X@=&AE
M(&-O;G1E>'0@;V8@<V5C=7)I='DL(&ET(')A:7-E<R!T:&4@<75E<W1I;VX@
M87,@=&\@=VAA="`-"F%U=&AE;G1I8V%T:6]N(&UE=&AO9',@<VAO=6QD(&)E
M('5S960@;VX@=&AE<V4@<&%C:V5T<RX-"@T**&$I($EF('-O=7)C92!A=71H
M96YT:6-A=&EO;B`H=7-I;F<@<'5B;&EC(&ME>2!C<GEP=&]G<F%P:'DI(&%N
M9"!D871A(`T*8V]N9FED96YT:6%L:71Y("AI;F-L=61I;F<@:6UP;&EC:70@
M9W)O=7`@875T:&5N=&EC871I;VXI(&ES(`T*87!P;&EE9"!A="!T:&4@87!P
M;&EC871I;VX@;&%Y97(L('1H92!$4B!C86X@<VEM<&QY(')E<&QA>2!T:&4@
M9&%T82`-"BAI+F4N('!A>6QO860I('5N;6]D:69I960@=&\@=&AE('%U97)Y
M:6YG(')E8V5I=F5R<RP@96ET:&5R('9I82`-"G5N:6-A<W0@;W(@;&]C86P@
M;75L=&EC87-T+@T*#0HH8BD@268L(&AO=V5V97(L(&5X<&QI8VET(&=R;W5P
M(&%U=&AE;G1I8V%T:6]N("AU<VEN9R!A('-Y;6UE=')I8R!K97DI(`T*=V%S
M(&%P<&QI960@870@=&AE(&YE='=O<FL@;&%Y97(@*&4N9RX@=7-I;F<@25!S
M96,I+"!T:&5N('1H92!$4B`-"F-A;FYO="!S:6UP;'D@<F5P;&%Y('1H92!P
M86-K970@9'5E('1O(')E<W1R:6-T:6]N<R!A="!T:&4@25`@#0IL87EE<BX@
M(%1H=7,L(&EN('1H:7,@8V%S92!T:&4@1%(@;75S="!R92UA<'!L>2!T:&4@
M9W)O=7`M#0IA=71H96YT:6-A=&EO;BX-"@T*5&%K:6YG(&-A<V4@*&(I(&9U
M<G1H97(L('1H97)E(&%R92!T=V\@;W!T:6]N<R!C;W)R97-P;VYD:6YG('1O
M(`T*=VAE=&AE<B!R971R86YS;6ES<VEO;B!B>2!T:&4@1%(@:7,@<&5R9F]R
M;65D('9I82!U;FEC87-T('1O(&$@#0IR96-E:79E<B!O<B!V:6$@;75L=&EC
M87-T+@T*#0HH:2D@268@=&AE(')E=')A;G-M:7-S:6]N(&ES('5N:6-A<W0@
M=&\@82!G:79E;B!R96-E:79E<BP@=&AE;B!I="`-"FES('!R969E<G)E9"!I
M9B!T:&4@1%(@86YD('1H92!R96-E:79E<B!S:&%R92!A('-E<&%R871E(`T*
M<WEM;65T<FEC(&ME>2!F;W(@=&AI<R!P=7)P;W-E+@T*#0HH:6DI($EF('1H
M92!R971R86YS;6ES<VEO;B!I<R!V:6$@;75L=&EC87-T('1O(&$@<W5B9W)O
M=7`@*&%S(&ES(`T*=&AE(&-A<V4@:6X@4DU44"U)22DL('1H96X@=&AE($12
M(&-A;B!E:71H97(@=7-E('1H92!E>&ES=&EN9R`-"F=R;W5P+7-H87)E9"!S
M>6UM971R:6,@:V5Y(&]R('5S92!A('-E<&%R871E('-Y;6UE=')I8R!K97D@
M;VYL>2`-"F9O<B!T:&4@<W5B9W)O=7`@=6YD97(@=&AE($12+B`@5V4@<')O
M<&]S92!T;R!U<V4@=&AE(&QA=&5R(`T*87!P<F]A8V@L('=H:6-H(&UE86YS
M('1H870@82!$4B!A;F0@:71S(&-H:6QD<F5N("AR96-E:79E<G,I(`T*;75S
M="!S:&%R92!A('-E<&%R871E('-Y;6UE=')I8R!K97D@9F]R(&5X<&QI8VET
M(&=R;W5P(`T*875T:&5N=&EC871I;VX@870@=&AE($E0(&QA>65R+@T*#0H-
M"C0N-2!+97ES(&9O<B!$871A($-O;F9I9&5N=&EA;&ET>2!A;F0@9F]R($%U
M=&AE;G1I8V%T:6]N#0H-"D%S(&UE;G1I;VYE9"!A8F]V92P@=V4@<')O<&]S
M92!T:&4@<V5P87)A=&EO;B!O9B!D871A('-T<F5A;2`-"F-O;F9I9&5N=&EA
M;&ET>2!U<VEN9R!A('-Y;6UE=')I8R!K97D@96YC<GEP=&EO;B`H969F96-T
M:6YG(&%N(&EM<&QI8VET(`T*9W)O=7`M875T:&5N=&EC871I;VXI(&9R;VT@
M9&%T82!A=71H96YT:6-A=&EO;B!U<VEN9R!A('-Y;6UE=')I8R!K97D@86YD
M(`T*82!K97EE9"!H87-H(&9U;F-T:6]N("AI+F4N(&5X<&QI8VET(&=R;W5P
M+6%U=&AE;G1I8V%T:6]N*2X-"@T*5V4@;F]W(&1E;F]T92!T:&4@<WEM;65T
M<FEC(&ME>2!F;W(@9&%T82!S=')E86T@8V]N9FED96YT:6%L:71Y(&%T('1H
M92`-"F%P<&QI8V%T:6]N(&QA>65R(&%S('1H92!'<F]U<$1A=&%+97DN($]N
M;'D@=&AE('-O=7)C92!A;F0@=F%L:60@#0IR96-E:79E<G,@=VEL;"!H879E
M(&$@8V]P>2!O9B!T:&4@1W)O=7!$871A2V5Y+"!W:&EC:"!I<R!D96QI=F5R
M960@=&\@#0IT:&5M('1H<F]U9V@@=&AE(&%P<')O<')I871E($=R;W5P($ME
M>2!-86YA9V5M96YT("A'2TTI('!R;W1O8V]L('1H870@#0II9&5N=&EF:65S
M(&%N9"!V97)I9FEE<R!T:&4@;65M8F5R<R!I;F1I=FED=6%L;'DN("!);B!T
M:&4@8V%S92!W:&5R92!T:&4@#0I$4G,@86YD('1H92!43B!A<F4@;F]T('!E
M<FUI='1E9"!T;R!R96%D('1H92!M=6QT:6-A<W0@9&%T82P@=&AE>2!M=7-T
M(`T*8F4@<')E=F5N=&5D(&)Y('1H92!'2TT@<')O=&]C;VP@9G)O;2!O8G1A
M:6YI;F<@=&AE($=R;W5P1&%T84ME>2X-"@T*5V4@9&5N;W1E('1H92!S>6UM
M971R:6,@:V5Y(&9O<B!E>'!L:6-I="!G<F]U<"UA=71H96YT:6-A=&EO;B!A
M="!T:&4@#0IN971W;W)K(&QA>65R(&%S('1H92!'<F]U<$%U=&A+97DN(%1H
M92!'<F]U<$%U=&A+97D@:7,@9&ES=&EN8W0@9G)O;2!T:&4@#0I'<F]U<$1A
M=&%+97DN($9O<B!44D%#2R!P<F]T;V-O;',L('=E('!R;W!O<V4@=&AE('5S
M92!O9B!)4'-E8R!W:71H(`T*:V5Y960@:&%S:&EN9R!A="!T:&4@;F5T=V]R
M:R!L87EE<B!T;R!P<F]V:61E(&5X<&QI8VET(&=R;W5P+0T*875T:&5N=&EC
M871I;VX@=7-I;F<@=&AE($=R;W5P075T:$ME>2X@(%5N;&EK92!T:&4@1W)O
M=7!$871A2V5Y+"!T:&4@#0I'<F]U<$%U=&A+97D@:7,@:VYO=VX@8GD@86QL
M(&5N=&ET:65S(&EN=F]L=F5D(&EN('1H92!M=6QT:6-A<W0N("!4:&ES(`T*
M:6YC;'5D97,@86QL(&EN=&5R:6]R(&YO9&4@96YT:71I97,@*&4N9RX@5$XL
M($12*2P@=&AE(%-E;F1E<B]3;W5R8V4@86YD(`T*=&AE(%)E8V5I=F5R<RX-
M"@T*#0HT+C8@075T:&5N=&EC:71Y(&]F($Y!0TL@86YD(&]T:&5R($-O;G1R
M;VP@4&%C:V5T<PT*#0I);B!44D%#2R!P<F]T;V-O;',L(&$@1%(@<F5S<&]N
M9',@=&\@82!.04-+(&9R;VT@;VYE(&ET<R!C:&EL9')E;B`-"BAT>7!I8V%L
M;'D@82!R96-E:79E<BD@8GD@<F4M=')A;G-M:71T:6YG('1H92!L;W-T('!A
M8VME="!V:6$@;&]C86P@#0IM=6QT:6-A<W0N("!4:&ES(&)A<VEC(&)E:&%V
M:6]R(&-A;B!B92!O<&5N('1O(&%B=7-E(&)Y(&%N(&%T=&%C:V5R('=H;R`-
M"FEN:F5C=',@<W!U<FEO=7,@3D%#2R!M97-S86=E<R!T;W=A<F1S('1H92!$
M4BP@969F96-T:6YG(&$@;&]C86P@#0IM=6QT:6-A<W0@=&\@86QL(&-H:6QD
M<F5N(&]F('1H92!$4BX@($EN(&ET<V5L9B!T:&ES(&ES(&$@=V%S=&4@;V8@
M#0IB86YD=VED=&@@86YD(&UA>2!R97-U;'0@:6X@82!D96YI86P@;V8@<F5S
M;W5R8V4@=&\@=&AE(&=R;W5P(&UE;6)E<G,N("`-"D]T:&5R(&-O;G1R;VP@
M<&%C:V5T<R!D:7)E8W1L>2!I;7!A8W0@=&AE('-T871E(&]F('1H92!G<F]U
M<"P@<W5C:"!A<R`-"G1H92!G<F]U<"!M96UB97)S:&EP+"!A;F0@8V]U;&0@
M86QS;R!B92!U<V5D(&EN(&1E;FEA;"!O9B!S97)V:6-E(`T*871T86-K<RX-
M"@T*5&\@8V]U;G1E<B!T:&5S92!T>7!E<R!O9B!A='1A8VLL('1H92!C;VYT
M<F]L(&UE<W-A9V5S('1H96US96QV97,@;75S="`-"F)E(&%U=&AE;G1I8V%T
M960@8GD@=&AE($12+B`@1&EG:71A;"!S:6=N871U<F5S('5S:6YG('!U8FQI
M8R!K97D@#0IC<GEP=&]G<F%P:'D@8V]U;&0@8F4@87!P;&EE9"!T;R!T:&4@
M8V]N=')O;"!M97-S86=E<RX@($AO=V5V97(L('1H:7,@#0IA<'!R;V%C:"!W
M;W5L9"!B92!I;F5F9FEC:65N="!D=64@=&\@=&AE(&AI9V@@0U!5(&-O<W0@
M;V8@<'5B;&EC(&ME>2`-"F5N8W)Y<'1I;VXN("!!;'-O+"!I="!W;W5L9"!R
M97%U:7)E(&-R96%T:6YG(&$@<V5P87)A=&4@<V5C=7)I='D@#0IA<W-O8VEA
M=&EO;B!W:71H(&5A8V@@8VAI;&0@;V8@=&AE($12+@T*#0I);G-T96%D+"!W
M92!P<F]P;W-E('1H870@3D%#2R!A;F0@;W1H97(@8V]N=')O;"!M97-S86=E
M<R!F<F]M(&$@8VAI;&0@#0HH<F5C96EV97(I('1O(&ET<R!$4B!B92!P<F]T
M96-T960@=7-I;F<@<WEM;65T<FEC($E0<V5C(&)A<V5D(`T*875T:&5N=&EC
M871I;VXN("!4:&ES(')E<75I<F5S('1H92!T=V\@<&%R=&EE<R!T;R!F:7)S
M="!E<W1A8FQI<V@@82`-"E-E8W5R:71Y($%S<V]C:6%T:6]N("A302D@86YD
M(&$@<VAA<F5D('-Y;6UE=')I8R!K97DN("!4:&4@<WEM;65T<FEC(&ME>2`-
M"F-A;B!B92!U;FEQ=64@<&5R(&-H:6QD+"!O<B!B92!U;FEF;W)M(&]V97(@
M82!S=6)G<F]U<"!O9B!R96-E:79E<G,@#0HH:2YE+B!T:&]S92!U;F1E<B!T
M:&4@1%(I+@T*#0H-"C0N-R!&875L="!296-O=F5R>0T*#0I);B!23510+4E)
M+"!I9B!A(&-H:6QDDG,@8V]N;F5C=&EO;B!T;R!A($12(&]R(%1.(&9A:6QS
M+"!23510+4E)(`T*<')O=FED97,@875T;VUA=&EC(&UE8VAA;FES;7,@9F]R
M(&9A:6QI;F<M;W9E<B!T;R!A;F]T:&5R($12(&]R(&)A8VMU<"`-"E1.+B`@
M5&AI<R!R96-O;FYE8W1I;VX@;F5E9',@=&\@:&%P<&5N('%U:6-K;'DL('-O
M('1H870@=&AE(&-H:6QD(&-A;B`-"G)E:F]I;B!T:&4@9&%T82!S=')E86T@
M8F5F;W)E('1O;R!M=6-H(&1A=&$@:&%S(&)E96X@;6ES<V5D('1O(')E8V]V
M97(@#0IF<F]M+B`@268@82!C:&EL9"!N965D<R!T;R!G970@82!N97<@:V5Y
M(&9O<B!T:&%T($12+U1.+"!T:&ES(&-A;B!B92!A(`T*8F]T=&QE;F5C:RX@
M($=I=F5N('1H870@=&AE(&ME>2!D:7-T<FEB=71I;VX@:6YF<F%S=')U8W1U
M<F4@;6%Y(&)E(`T*8V5N=')A;&EZ960L(&%N9"!A(&UA:F]R:71Y(&]F(')E
M8V5I=F5R<R!M87D@;F5E9"!T;R!F86EL(&]V97(@870@=&AE(`T*<V%M92!T
M:6UE+"!T:&ES('!R97-E;G1S(&$@;6%J;W(@;W!P;W)T=6YI='D@9F]R(&YE
M='=O<FL@8V]N9V5S=&EO;BX-"@T*5&AE(%)-5%`M24D@96YT:71I97,@87)E
M(&=I=F5N('1H92!A9&1R97-S(&]F('1H96ER(&)A8VMU<"!C;VYT<F]L(&YO
M9&4@#0IA="!S=&%R='5P('1I;64N("!7:&EL92!T:&5S92!A9&1R97-S97,@
M8V%N(&-H86YG92P@=&AE>2!A<F4@97AP96-T960@=&\@#0IA;'=A>7,@:&%V
M92!T:&4@861D<F5S<V5S(&]F(&]N92!O<B!M;W)E(&)A8VMU<"!N;V1E<RX@
M(%=H96X@#0II;7!L96UE;G1I;F<@<V5C=7)I='D@9F5A='5R97,L(&5A8V@@
M8VAI;&0@<VAO=6QD(&)E(')E<75I<F5D('1O(&ME97`@#0IT:&4@:V5Y(&9O
M<B!I=',@<')I;6%R>2!B86-K=7`@1%(O5$XN("!/<'1I;VYA;&QY+"!I="!M
M87D@;F5E9"!T;R!K965P(`T*=&AE(&ME>7,@9F]R(&5A8V@@;V8@=&AE(&)A
M8VMU<"!C;VYT<F]L(&YO9&5S(&ET(&ES('5S:6YG+@T*#0H-"C0N."!);7!L
M96UE;G1A=&EO;B!W:71H($1I9F9E<F5N="!,979E;',@;V8@3U,@4')O=&5C
M=&EO;@T*#0I!(%1204-+('!R;W1O8V]L(&-A;B!B92!I;7!L96UE;G1E9"!I
M;B`H870@;&5A<W0I(&]N92!O9B!T:')E92!W87ES+@T*+2!!<'!L:6-A=&EO
M;B!L979E;"X@($UO<W0@:6UP;&5M96YT871I;VYS(&]F(%1204-+('!R;W1O
M8V]L<R!F;W(@=&AE(`T*;F5A<B!F=71U<F4@87)E(&5X<&5C=&5D('1O(&]P
M97)A=&4@:6X@=&AE(&%P<&QI8V%T:6]N(&QE=F5L(&]F('1H92`-"D]3+"!R
M=6YN:6YG(&]N('1O<"!O9B!51%`N(`T*+2!+97)N96PN("!!<R!44D%#2R!P
M<F]T;V-O;',@8F5C;VUE(&)U;F1L960@=VET:"!S=&%N9&%R9"!O<&5R871I
M;F<@#0IS>7-T96US+"!I="!I<R!E>'!E8W1E9"!T;R!B96-O;64@82!K97)N
M96P@;6]D=6QE+"!A;F0@<G5N(&1I<F5C=&QY(`T*;W9E<B!)4"X-"BT@5FER
M='5A;"!M86-H:6YE+B`@4V]M92!44D%#2R!E;G1I=&EE<R`H<&%R=&EC=6QA
M<FQY('-E;F1E<G,@86YD(`T*<F5C96EV97)S*2!W:6QL(&)E(')U;B!I;B!V
M:7)T=6%L(&UA8VAI;F5S+"!S=6-H(&%S('=H96X@:6UP;&5M96YT960@#0IA
M<R!A($IA=F$@87!P;&5T+@T*#0I44D%#2R!P<F]T;V-O;"!S96-U<FET>2!M
M=7-T(&%C8V]M;6]D871E(&%L;"!T:')E92!O9B!T:&5S92!O<'1I;VYS+B`@
M#0I4:&ES(')A:7-E<R!T:&4@9F]L;&]W:6YG(&ES<W5E<RX-"BT@07!P;&EC
M871I;VX@3&5V96PN("!/;F4@861V86YT86=E(&]F(&%P<&QI8V%T:6]N(&QE
M=F5L(`T*:6UP;&5M96YT871I;VYS(&ES('1H96ER(&9L97AI8FEL:71Y+B`@
M5&AE<V4@:6UP;&5M96YT871I;VYS(&-O=6QD(`T*=7-E(&5I=&AE<B!)4'-E
M8R!R;W5T:6YE<RP@=&AE(&%P<&QI8V%T:6]N(&QA>65R('-E8W5R:71Y(&9U
M;F-T:6]N<RP@#0IO<B!B;W1H+@T*+2!6:7)T=6%L($UA8VAI;F5S+B`@5&AE
M<F4@87)E(&ES<W5E<R!T<GEI;F<@=&\@=7-E($E0<V5C('=I=&@@#0IV:7)T
M=6%L(&UA8VAI;F5S('-U8V@@87,@2F%V82P@=VAI8V@@:&%V92!T;R!D871E
M(&AI;F1E<F5D('1H92`-"G-U<'!O<G0@;V8@25!S96,@=&AR;W5G:"!N871I
M=F4@2F%V82!A<'!L971S+B`@5&AI<R!M86ME<R!I="`-"FEM<&]R=&%N="!F
M;W(@82!44D%#2R!P<F]T;V-O;"!T;R!O<'1I;VYA;&QY(&)E(&%B;&4@=&\@
M=7-E(&]N;'D@#0IA<'!L:6-A=&EO;B!L979E;"!S96-U<FET>2X-"BT@2V5R
M;F5L($EM<&QE;65N=&%T:6]N<RX@($%S(&$@5%)!0TL@<')O=&]C;VP@8F5C
M;VUE<R!B=6YD;&5D('=I=&@@#0IO<&5R871I;F<@<WES=&5M<RP@:70@:7,@
M97AP96-T960@=&AA="!)4'-E8R!W:6QL(&%L<V\@8F5C;VUE(&)U;F1L960@
M#0IW:71H('1H92!/4RX@(%1O(&%V;VED(&AA=FEN9R!T;R!U<V4@;&5S<R!T
M<G5S=&5D('-O9G1W87)E(&EN('1H92`-"F%P<&QI8V%T:6]N(&QE=F5L+"!T
M:&4@5%)!0TL@<')O=&]C;VP@=VEL;"!H879E('1O(&)E(&%B;&4@=&\@=7-E
M(&$@#0IK97)N96P@;&5V96P@<V5C=7)I='D@<WES=&5M("AS=6-H(&%S($E0
M<V5C*2!F;W(@:71S('1R86YS<&]R="!L979E;"`-"G-E8W5R:71Y(&YE961S
M+@T*#0H-"C0N.2!397!A<F%T92!296=I;VYA;"!0<F]T96-T:6]N#0H-"E12
M04-+('!R;W1O8V]L<R!A<F4@97AP96-T960@=&\@8F4@=7-E9"!F;W(@8V]N
M=&5N="!D:7-T<FEB=71I;VX@9G)O;2!A(`T*9F5W('-E;F1E<G,@=&\@;6%N
M>2!R96-E:79E<G,N("!);B!T:&4@8V%S92!O9B!A<'!L:6-A=&EO;G,@=&AA
M="`-"F1I<W1R:6)U=&4@8W)I=&EC86P@9&%T82!T;R!M86YY(&1I9F9E<F5N
M="!O<F=A;FEZ871I;VYS+"!I="!I<R!N;W0@#0IE;F]U9V@@=&\@=')U<W0@
M86QL(')E8V5I=F5R<RX@($9O<B!E>&%M<&QE+"!A(&UA<FME="!D871A(&9E
M960@<')O=FED97(@#0IC;W5L9"!B92!U<VEN9R!A(%1204-+('!R;W1O8V]L
M('1O(&1I<W1R:6)U=&4@;&EV92!M87)K970@9&%T82!F965D<R!T;R`-"F-O
M;7!E=&EN9R!F:6YA;F-I86P@:6YS=&ET=71I;VYS+B`@26X@=&AI<R!S:71U
M871I;VXL('1H92!D871A(&9E960@#0IP<F]V:61E<B!N965D<R!T;R!B92!A
M8FQE('1O('!R;W1E8W0@:6YD:79I9'5A;"!C;VUP86YI97,@9G)O;2!C;W)R
M=7!T960@#0IC;VYT<F]L('!A8VME=',@9G)O;2!O=&AE<B!C=7-T;VUE<G,@
M*'=H:6-H(&-O=6QD(&)E(&=E;F5R871E9"!E:71H97(@#0II;G1E;G1I;VYA
M;&QY+"!O<B!M;W)E(&QI:V5L>2P@=6YI;G1E;G1I;VYA;&QY*2!W:&EC:"!W
M;W5L9"!C875S92!D96YI86P@#0IO9B!S97)V:6-E+@T*#0I!<R!W92!P<F]P
M;W-E(&EN('1H92!N97AT('-E8W1I;VXL(&$@5%)!0TL@<')O=&]C;VP@;75S
M="!P<F]V:61E(`T*<V5P87)A=&4@<F5G:6]N86P@:V5Y<R!F;W(@=&AE(&=R
M;W5P+6%U=&AE;G1I8V%T:6]N(&]F(&-O;G1R;VP@<&%C:V5T<R`-"G-E;G0@
M9G)O;2!T:&4@<F5C96EV97)S(&]F(&1I9F9E<F5N="!$4G,N("!4:&ES(&%L
M;&]W<R!T:&4@#0IA=71H96YT:6-A=&EO;B!O9B!C;VYT<F]L+6UE<W-A9V5S
M(&9O<B!E86-H('-E="!O9B!R96-E:79E<G,@*'!A<G0@;V8@#0IO;F4@8W5S
M=&]M97(I('1O(&)E(&1O;F4@<V5P87)A=&5L>2`H9G)O;2!A;F]T:&5R('-E
M="!O9B!R96-E:79E<G,L(&%S(`T*<&%R="!O9B!D:69F97)E;G0@8W5S=&]M
M97(I+B!3:6YC92!F;W(@96%C:"!S970@;V8@<F5C96EV97)S(&$@9&EF9F5R
M96YT(`T*:V5Y(&ES('5S960L('1H:7,@;&EM:71S('1H92!A8FEL:71Y(&]F
M(&$@8W5S=&]M97(@=&\@<&5R<&5T<F%T92!D96YI86P@#0IO9B!S97)V:6-E
M(&%T=&%C:W,@86=A:6YS="!O=&AE<B!C=7-T;VUE<G,N(`T*#0H-"C0N,3`@
M4&ER86-Y(&]F(%!A>2U097(M57-E($1A=&$-"@T*02!C;VUM;VX@<V-E;F%R
M:6\@9F]R(%1204-+('!R;W1O8V]L<R!I;G9O;'9E<R!P87DM<&5R+75S92!D
M871A(`T*9&ES=')I8G5T:6]N+"!S=6-H(&%S(&QI=F4@;6%R:V5T(&1A=&$L
M('!A>2UP97(M=FEE=R!V:61E;R!S:6=N86QS+"!O<B`-"G!A:60@<W5B<V-R
M:7!T:6]N<R!T;R!S;V9T=V%R92!U<&1A=&5S+B`@26X@=&AI<R!S8V5N87)I
M;RP@82!R96-E:79E<B`-"F-A;FYO="!B92!T<G5S=&5D('1O(&YO="!G:79E
M(&ET<R!G<F]U<"!K97ES('1O(&]U='-I9&4@96YT:71I97,L('=H;R`-"F%R
M92!T<GEI;F<@=&\@9V5T(&9R964@<V5R=FEC92X@(%=E(&UE;G1I;VX@=&AI
M<R!R97%U:7)E;65N="!S:6YC92!I="!I<R`-"F1I9F9E<F5N="!T:&%N('!O
M:6YT+71O+7!O:6YT('-E8W5R:71Y+B`@2&]W979E<BP@=&AI<R!R97%U:7)E
M;65N="!I<R`-"G1H92!R97-P;VYS:6)I;&ET>2!O9B!T:&4@87!P;&EC871I
M;VX@;&5V96P@<V5C=7)I='DN#0H-"@T*#0HU+B!!<F-H:71E8W1U<F4@4F5C
M;VUM96YD871I;VYS#0H-"E1H92!P<F5V:6]U<R!S96-T:6]N(&1E=&%I;&5D
M('-O;64@;V8@=&AE('-P96-I9FEC(')E<75I<F5M96YT<R!A;F0@#0II<W-U
M97,@9F]R(%1204-+('!R;W1O8V]L('-E8W5R:71Y+"!A;&]N9R!W:71H('-O
M;64@:6YD:79I9'5A;"`-"G)E8V]M;65N9&%T:6]N(&]N(&AA;F1L:6YG(&5A
M8V@@;VYE+B`@1VEV96X@=&AO<V4@<F5Q=6ER96UE;G1S+"!W92`-"G!R;W!O
M<V4@=&AE(&9O;&QO=VEN9R!A<F-H:71E8W1U<F4@<F5C;VUM96YD871I;VYS
M(&9O<B!I;7!L96UE;G1I;F<@#0IS96-U<FET>2!W:71H(%1204-+('!R;W1O
M8V]L<RX@(`T*#0H-"C4N,2!397!A<F%T:6]N(&]F(%-E8W5R:71Y(%)E<W!O
M;G-I8FEL:71I97,-"@T*07,@9&5T86EL960@86)O=F4L(%1204-+('!R;W1O
M8V]L<R!A<F4@<')I;6%R:6QY(&-O;F-E<FYE9"!W:71H(`T*<')O=&5C=&EO
M;B!O9B!T:&4@;F5T=V]R:R!I;F9R87-T<G5C='5R92P@<F%T:&5R('1H86X@
M=VET:"!I<W-U97,@<W5C:"`-"F%S(&1A=&$@8V]N9FED96YT:6%L:71Y(&%N
M9"!S;W5R8V4M875T:&5N=&EC871I;VXN("!4:&5R969O<F4L('=E(`T*<F5C
M;VUM96YD('1H870@5%)!0TL@<')O=&]C;VQS(%-(3U5,1"!P<F]V:61E.@T*
M("`@*&$I(&=R;W5P(&%U=&AE;G1I8V%T:6]N(&]F(&-O;G1R;VP@<&%C:V5T
M<RP@86YD#0H@("`H8BD@;W!T:6]N86P@9W)O=7`@875T:&5N=&EC871I;VX@
M;V8@9&%T82!P86-K971S#0I/<'1I;VYA;&QY+"!44D%#2R!P<F]T;V-O;',@
M34%9(&-H;V]S92!T;R!P<F]V:61E.@T*("`@*&,I(&]P=&EO;F%L('!R:79A
M8WD@;V8@9&%T82!A;F0@;V8@8V]N=')O;"!P86-K970@:&5A9&5R<RX@(`T*
M5&\@86-C;VUP;&ES:"!T:&ES+"!W92!R96-O;6UE;F0@=&AA="!44D%#2R!P
M<F]T;V-O;',@=7-E($E0<V5C(`T*=&5C:&YO;&]G>2!A="!T:&4@;F5T=V]R
M:R!L87EE<BP@=VAI;&4@;&5T=&EN9R!A<'!L:6-A=&EO;B!L979E;"`-"G-E
M8W5R:71Y('!E<F9O<FT@861D:71I;VYA;"!F=6YC=&EO;G,@87,@;F5E9&5D
M+B`@1F]R(&EM<&QE;65N=&%T:6]N<R`-"G1H870@9&\@;F]T(&AA=F4@86-C
M97-S('1O($E0<V5C+"!A;F0@87)E(&YO="!I;7!L96UE;G1E9"!A<R!P87)T
M(&]F('1H92`-"D]3+"!A<'!L:6-A=&EO;B!L979E;"!S96-U<FET>2!C86X@
M8F4@=7-E9"!I;G-T96%D+2UA;'1H;W5G:"!T:&ES(&]F(`T*8V]U<G-E(')I
M<VMS(&EN8V]M<&%T:6)I;&ET>2!W:71H(&]T:&5R(&EM<&QE;65N=&%T:6]N
M<RX-"@T*5&AE('-E<&%R871I;VX@;V8@9W)O=7`M875T:&5N=&EC871I;VX@
M;V8@9&%T82!F<F]M(&)O=&@@9&%T82!S;W5R8V4M#0IA=71H96YT:6-A=&EO
M;B!A;F0@9&%T82UC;VYF:61E;G1I86QI='D@:7,@=&EG:'1L>2!C;W5P;&5D
M('1O('1H92!C:&]I8V4@#0IO9B!R96-O;6UE;F1I;F<@25!S96,@9F]R('1H
M92!G<F]U<"!A=71H96YT:6-A=&EO;BX@(%1H97-E('1W;R!C:&]I8V5S(`T*
M87)E(&UO=&EV871E9"!B>2!T:&4@9F]L;&]W:6YG.@T*#0HH82D@3F]N+41E
M8VEP:&5R86)I;&ET>2!O9B!D871A(&)Y(&EN=&5R:6]R(&-O;G1R;VP@;F]D
M97,Z(&ET(&ES(&$@#0IR97%U:7)E;65N="!O9B!44D%#2R!P<F]T;V-O;',@
M=&AA="!I;B!S;VUE(&1E<&QO>6UE;G1S+"!I=',@8V]N=')O;"`-"F5N=&ET
M:65S("AE+F<N(%1.+"!$4BD@8F4@=6YA8FQE('1O(&1E8VEP:&5R('1H92!D
M871A('!A8VME="X@(%1H=7,L(`T*=&AE($=R;W5P1&%T84ME>2!F;W(@9&%T
M82!E;F-R>7!T:6]N(&%N9"!'<F]U<$%U=&A+97D@9F]R(&=R;W5P+0T*875T
M:&5N=&EC871I;VX@;75S="!B92!D:7-T:6YC="X@($ET(&ES(&YO="!S=69F
M:6-I96YT('1O('-I;7!L>2!U<V4@#0IA;B!I9&5N=&EC86P@:V5Y("AF;W(@
M=&AE($=R;W5P1&%T84ME>2!A;F0@1W)O=7!!=71H2V5Y*2!A;F0@=&\@#0II
M;G-T<G5C="!T:&4@5%)!0TL@<')O=&]C;VP@96YT:71I97,@=&\@879O:60@
M9&5C:7!H97)I;F<@=&AE(&1A=&$@#0IP86-K971S+B`@270@;75S="!B92!P
M<F]V86)L>2!S:&]W;B!T:&%T('1H92!I;G1E<FEO<B!C;VYT<F]L(&YO9&5S
M(`T*9&\@;F]T(&AA=F4@=&AE(&%B:6QI='D@=&\@9&5C:7!H97(@=&AE(&1A
M=&$@<&%C:V5T<R`H979E;B!I9B!T:&5Y(`T*=VES:"!T;R!D;R!S;RDN#0H-
M"BAB*2!5<V4@;V8@25!S96,@=&5C:&YO;&]G:65S.B!C;VYS:61E<F%B;&4@
M969F;W)T(&AA<R!B965N(&EN=F5S=&5D(&EN(`T*9&5V96QO<&EN9R!T:&4@
M25!S96,@87)C:&ET96-T=7)E(&%N9"!P<F]T;V-O;',@6TM!.3AA+"!+03DX
M8ETL(&%N9"`-"F$@9W)O=VEN9R!N=6UB97(@;V8@=F5N9&]R<R!A<F4@<W5P
M<&]R=&EN9R!)4'-E8RX@(%1H92!)4'-E8R!S=6ET92`-"F]F9F5R<R!A(&YU
M;6)E<B!O9B!F96%T=7)E<RP@:6YC;'5D:6YG('-O;64@<')O=&5C=&EO;B!A
M9V%I;G-T(`T*<F5P;&%Y(&%T=&%C:W,N#0H-"BAC*2!-=6QT:6-A<W0@25!S
M96,Z('1H92!)4'-E8R!A<F-H:71E8W1U<F4@:&%S(&EN=&5N=&EO;F%L;'D@
M86QL;W=E9"`-"G1H92!U<V4@;V8@25!S96,@9F]R($E0(&UU;'1I8V%S="!W
M:71H;W5T(&-H86YG97,@=&\@=&AE(&)A<VEC(`T*8V]N<W1R=6-T<R!W:71H
M:6X@=&AE($E0<V5C('-U:71E+B`@0W5R<F5N=&QY+"!W;W)K(&ES('!R;V-E
M961I;F<@#0IT;W=A<F1S('1H92!E<W1A8FQI<VAM96YT(&]F(&$@<W1A;F1A
M<F0@;65C:&%N:7-M('1O('-E;&5C="!T:&4@#0I'<F]U<"!396-U<FET>2!!
M<W-O8VEA=&EO;B`H1W)O=7`@4T$@;W(@1U-!*2!F;W(@;75L=&EC87-T(&%N
M9"!A(`T*;65T:&]D('1O(&1I<W-E;6EN871E('1H92!'4T$@=&\@=&AE('9A
M;&ED(&UE;6)E<G,@;V8@=&AE(&=R;W5P(`T*6TA#33DX+$A(.3EA72X-"@T*
M*&0I($%P<')O<')I871E($QE=F5L.B`@<VEN8V4@=&AE('!R:6UA<GD@<'5R
M<&]S92!O9B!T<F%N<W!O<G0@;&5V96P@#0IS96-U<FET>2!I<R!T;R!S96-U
M<F4@=&AE(&EN9G)A<W1R=6-T=7)E(&%T(&$@=')A;G-P;W)T(&QE=F5L+"!U
M<VEN9R`-"F$@;F5T=V]R:R!O<B!T<F%N<W!O<G0@;&5V96P@<V5C=7)I='D@
M<')O=&]C;VP@86QL;W=S(&5A8V@@=&\@8F4@#0II;7!L96UE;G1E9"!T;V=E
M=&AE<BTM96ET:&5R(&EN('1H92!/4RP@;W(@:6X@=&AE(&%P<&QI8V%T:6]N
M(&QA>65R+@T*#0H-"C4N,B!$:79I<VEO;B!O9B!297-P;VYS:6)I;&ET:65S
M#0H-"D=I=F5N('1H:7,@9G5N9&%M96YT86P@9&EV:7-I;VX@8F5T=V5E;B!A
M<'!L:6-A=&EO;B!A;F0@=')A;G-P;W)T(`T*<F5S<&]N<VEB:6QI=&EE<RP@
M=V4@9&EV:61E('1H92!S96-U<FET>2!R97-P;VYS:6)I;&ET:65S(&EN('1O
M(&9O=7(@#0IP87)T<RX-"@T*3F5T=V]R:R!297-P;VYS:6)I;&ET:65S("A)
M4"!A;F0@25`@375L=&EC87-T*0T*+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM
M+2TM+2TM+2TM+2TM+2TM+2TM+2TM+0T*#0HM($%D;6ES<VEO;B!C;VYT<F]L
M<R!O;B!S96YD97)S+2UT;R!P<F]T96-T(&%G86EN<W0@DV)R=71E(`T*("!F
M;W)C990@<W!A;6UI;F<@871T86-K<RX-"BT@075T:&5N=&EC871I;VX@;V8@
M<F]U=&EN9R!C;VYT<F]L('!A8VME=',M+71O('!R;W1E8W0@#0H@('1H92!R
M;W5T:6YG(&EN9G)A<W1R=6-T=7)E(&9R;VT@9&5N:6%L(&]F('-E<G9I8V4@
M871T86-K<RX-"@T*5')A;G-P;W)T(%)E<W!O;G-I8FEL:71I97,@*%1204-+
M(%!R;W1O8V]L<RD-"BTM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM
M+2TM+0T*+2!0<F]T96-T:6]N(&]F('1H92!C;VYT<F]L(&UE<W-A9V5S(&9R
M;VT@<F5P;&%Y(&%T=&%C:W,-"B`@86YD(&]T:&5R(&1E;FEA;"UO9BUS97)V
M:6-E(&%T=&%C:W,N#0HM($]P=&EO;F%L.B!P<F]T96-T:6]N(&]F(&1A=&$@
M<&%C:V5T<R!F<F]M(')E<&QA>2!A='1A8VMS+@T*+2!/<'1I;VYA;#H@96YC
M<GEP=&EO;B!O9B!C;VYT<F]L(&UE<W-A9V5S('1O(&UI;FEM:7IE#0H@(&YE
M='=O<FL@86YA;'ES:7,@8GD@871T86-K97)S+@T*#0I%;F0@=&\@16YD(%)E
M<W!O;G-I8FEL:71I97,@*$%P<&QI8V%T:6]N*0T*+2TM+2TM+2TM+2TM+2TM
M+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2T-"BT@4V]U<F-E(&%U=&AE;G1I
M8V%T:6]N+2UT;R!V97)I9GD@=&AE(&%U=&AE;G1I8VET>2!O9B!D871A+`T*
M("!A;F0@<')O=FED92!O<'1I;VYA;"!N;VXM<F5P=61I871I;VX@;V8@9&%T
M82X-"BT@1&%T82!E;F-R>7!T:6]N+2UT;R!P<F]V:61E(&1A=&$@8V]N9FED
M96YT:6%L:71Y+@T*#0I+97D@36%N86=E;65N="!);F9R87-T<G5C='5R90T*
M+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+0T*+2!$:7-T<FEB=71I
M;VX@;V8@=')A;G-P;W)T(&%N9"!N971W;W)K(&QA>65R(&ME>7,Z(&%U=&AE
M;G1I8V%T:6]N#0H@(&]F(&EN9&EV:61U86P@:&]S=',L(&%N9"!D:7-T<FEB
M=71I;VX@;V8@:V5Y<R!T;R!T:&]S92!H;W-T<PT*+2!!<'!L:6-A=&EO;B!L
M979E;"!K97D@9&ES=')I8G5T:6]N.B!A=71H96YT:6-A=&EO;B!O9@T*("!I
M;F1I=FED=6%L('!R;V-E<W-E<RP@86YD(&1I<W1R:6)U=&EO;B!O9B!K97ES
M('1O('1H;W-E('!R;V-E<W-E<PT*+2!/<'1I;VYA;#H@<&5R:6]D:6,@<F5K
M97EI;F<M+6=R;W5P(&ME>7,@<&5R:6]D:6-A;&QY(&YE960-"B`@=&\@8F4@
M8VAA;F=E9"P@8F]T:"!A9G1E<B!A(&-E<G1A:6X@=&EM92!L:6UI="!H87,@
M97AP:7)E9"P-"B`@86YD+V]R(&%F=&5R('1H92!G<F]U<"!M96UB97)S:&EP
M(&-H86YG97,N#0H-"E1H92!F:6=U<F4@8F5L;W<@<VAO=W,@:&]W('1H97-E
M(&-O;7!O;F5N=',@<F5L871E('1O(&5A8V@@;W1H97(N("!44D%#2R`-"G!R
M;W1O8V]L<R!C86X@8F4@=7-E9"!W:71H;W5T(&%N>2!A9&1I=&EO;F%L('-E
M8W5R:71Y(&%T('1H92!)4"])4"`-"DUU;'1I8V%S="!L979E;"P@86QT:&]U
M9V@@=&AI<R!W:6QL(&YO="!P<F]V:61E(&9U;&P@<')O=&5C=&EO;B!F<F]M
M(`T*9&5N:6%L(&]F('-E<G9I8V4@871T86-K<RX@(%1204-+('!R;W1O8V]L
M<R!W:6QL(&)E(&%B;&4@=&\@8F4@=7-E9"!O;B`-"G1O<"!O9B!51%`@;W(@
M<F%W($E0+TE0($UU;'1I8V%S="X@($$@5%)!0TL@<')O=&]C;VP@8V%N('5S
M92!E:71H97(@#0I)4'-E8R!O<B!A<'!L:6-A=&EO;B!L979E;"!S96-U<FET
M>2!F;W(@:71S(&YE='=O<FL@<V5C=7)I='D@#0IR97%U:7)E;65N=',L(&%L
M=&AO=6=H('=E(')E8V]M;65N9"!U<VEN9R!)4'-E8R!W:&5R979E<B!P;W-S
M:6)L92X-"B`@("`@("`@("`@("`@("`@("`@("`@*RTM+2TM+2TM+2TM+2TM
M+2TM+2TM*R`@("`@("`K+2TM+2TM+2TM+2L-"BLM+2TM+2TM+2TM+2TM+2L\
M+2TM+2T^?"`@("!!<'!L:6-A=&EO;B`@("`@?#PM+2TM+3Y\("!!<'`@4V5C
M('P-"GP@("`@("`@("`@("`@('P@("`@("`@*RTM+2TM+2TM+2TM+2TM+2TM
M+2TM*R`@('P]/3Y\("`@("`@("`@('P-"GP@("`@("`@("`@("`@('P@("`@
M("`@?"`@("`@("!44D%#2R`@("`@("`@?#PM+7P@("`K+2TM+2TM+2TM+2L-
M"GP@("`@($ME>2`@("`@('P\+2TM+2T^*R`@("`@("`@("`K+2TM+2TM+2TM
M*R`@('PM+3Y\("`@("`@("`@('P-"GP@($UA;F%G96UE;G0@('P@("`@("`@
M?"`@("`@("`@("!\("`@5410("`@?"`@("`@("!\("`@25!S96,@('P-"GP@
M("`@("`@("`@("`@('P@("`@("`@*RTM+2TM+2TM+2TM+2TM+2TM+2TM*R`@
M("`@("!\("`@("`@("`@('P-"GP@("`@("`@("`@("`@('P\/3T]/3T^?"`@
M25`L($E0($UU;'1I8V%S="`@?#P]/3T]/3Y\("`@("`@("`@('P-"BLM+2TM
M+2TM+2TM+2TM+2L@("`@("`@*RTM+2TM+2TM+2TM+2TM+2TM+2TM*R`@("`@
M("`K+2TM+2TM+2TM+7P-"@T*("`\/3T]/B!/<'1I;VYA;`T*#0H-"E=H96X@
M82!D871A('!A8VME="!I<R!T;R!B92!S96YT('1O('1H92!M=6QT:6-A<W0@
M9W)O=7`L('1H92`-"E-E;F1E<B]3;W5R8V4@9FER<W0@*&]P=&EO;F%L;'DI
M(&5N8VEP:&5R<R!T:&4@9&%T82!P86-K970@=7-I;F<@=&AE(`T*1W)O=7!$
M871A2V5Y(&%B;W9E('1H92!232]T<F%N<W!O<G0@;&%Y97(N("!)="!I<R!T
M:&5N('!A<W-E9"!T;R!T:&4@#0I232]T<F%N<W!O<G0@;&%Y97(L('=H:6-H
M(&%T=&%C:&5S('1H92!N96-E<W-A<GD@4DT@:&5A9&5R<RX@(%1H92!R97-U
M;'0@#0II<R!T:&5N('!A<W-E9"!D;W=N('1O('1H92!)4"!L87EE<B!W:&5R
M92!)4'-E8R!A=71H96YT:6-A=&EO;B!I<R`-"F5S=&%B;&ES:&5D("AU<VEN
M9R!T:&4@1W)O=7!!=71H2V5Y*2X-"@T*02!296-E:79E<B!I;B!T:&4@;75L
M=&EC87-T(&=R;W5P('=O=6QD(&)E(&EN('!O<W-E<W-I;VX@;V8@8F]T:"!T
M:&4@#0I'<F]U<$1A=&%+97D@86YD('1H92!'<F]U<$%U=&A+97DL(&%N9"!T
M:'5S('=I;&P@8F4@86)L92!T;R!F:7)S="`-"F%U=&AE;G1I8V%T92!T:&4@
M9&%T82!P86-K970@=7-I;F<@=&AE($=R;W5P075T:$ME>2P@86YD('1H96X@
M8V]N=&EN=64@#0IT;R!D96-I<&AE<B!T:&4@9&%T82!P86-K970@=7-I;F<@
M=&AE($=R;W5P1&%T84ME>2X-"@T*02!$97-I9VYA=&5D(%)E8V5I=F5R($YO
M9&4@*$12*2!W:6QL('!O<W-E<W,@=&AE($=R;W5P075T:$ME>2`H8G5T(&YO
M="`-"G1H92!'<F]U<$1A=&%+97DI+"!A;F0@=&AU<R!W:6QL(&]N;'D@8F4@
M86)L92!T;R!A=71H96YT:6-A=&4@=&AE('!A8VME="`-"G5S:6YG('1H92!'
M<F]U<$%U=&A+97D@=7-I;F<@25!S96,N("!!9G1E<B!V97)I9GEI;F<@=&AE
M(&%U=&AE;G1I8VET>2!O9B`-"F$@<F5C96EV960@9&%T82!P86-K970L(&$@
M1%(@=VEL;"!B92!A8FQE('1O(')E=')A;G-M:70@=&AE("AE;F-I<&AE<F5D
M*2`-"F1A=&$@<&%C:V5T('1O(&ET<R!C:&EL9')E;BP@96ET:&5R('9I82!U
M;FEC87-T(&]R(')E9VEO;BUB87-E9"!L;V-A;"`-"FUU;'1I8V%S="X@($$@
M<F5T<F%N<VUI<W-I;VX@;V8@82!L;W-T(&1A=&$@<&%C:V5T(&9R;VT@82!$
M4B!W:6QL(&)E(`T*875T:&5N=&EC871E9"!U<VEN9R!A(%-U8F=R;W5P075T
M:$ME>2`H<V5E(&)E;&]W*2!W:&EC:"!I<R!A('-Y;6UE=')I8R`-"FME>2!S
M:&%R960@8GD@82!$4B!A;F0@86QL(&ET<R!C:&EL9')E;B!296-E:79E<G,@
M;VYL>2X-"@T*06=A:6XL(&%L=&AO=6=H('1H92!C=7)R96YT('=O<FL@<')O
M<&]S97,@=&AE('5S92!O9B!U;FEC87-T($E0<V5C(&%N9"`-"FUU;'1I8V%S
M="!)4'-E8R!A="!T:&4@;F5T=V]R:R!L87EE<BP@:70@9&]E<R!N;W0@<')E
M8VQU9&4@=&AE('5S92!O9B`-"F]T:&5R(&%U=&AE;G1I8V%T:6]N('1E8VAN
M;VQO9VEE<R!A="!T:&4@;F5T=V]R:R!L87EE<B!O<B!A="!T:&4@#0I232]T
M<F%N<W!O<G0@;&%Y97(N("!3=6-H('1E8VAN;VQO9VEE<RP@:&]W979E<BP@
M=VEL;"!H879E('1O(&%D9')E<W,@#0IM=6-H(&]F('1H92!S86UE(&ES<W5E
M<R!F86-E9"!B>2!)4'-E8RP@:6YC;'5D:6YG('!R979E;G1I;VX@;V8@<F5P
M;&%Y<RP@#0IT:&4@8W)E871I;VX@86YD(&UA:6YT96YA;F-E(&]F('-T871E
M("AI+F4N()-396-U<FET>2!!<W-O8VEA=&EO;G.4*2`-"F%S<V]C:6%T960@
M=VET:"!T:&4@1W)O=7!!=71H2V5Y+"!T:&4@4V5N9&5R(&%N9"!296-E:79E
M<BAS*2P@86YD(&]T:&5R(`T*9F5A='5R97,@86YD('-U<'!O<G1I;F<@;65C
M:&%N:7-M<RX@($ET(&ES('!R96-I<V5L>2!T:&4@9W)O=VEN9R`-"F%V86EL
M86)I;&ET>2!O9B!)4'-E8R!T:&%T(&UO=&EV871E<R!T:&4@8W5R<F5N="!W
M;W)K('1O(&-H;V]S92!)4'-E8R`-"F9O<B!N971W;W)K(&QA>65R(&%U=&AE
M;G1I8V%T:6]N(&9O<B!B;W1H(&1A=&$@86YD(&-O;G1R;VP@<&%C:V5T<RX-
M"@T*#0HU+C,@5%)!0TL@2V5Y<PT*#0I);B!G96YE<F%L+"!E86-H(&YO9&4@
M:6X@=&AE(&AI97)A<F-H>2!M=7-T(&)E(&%B;&4@=&\@875T:&5N=&EC871E
M(`T*:71S96QF('1O('1H92!K97D@;6%N86=E;65N="!E;G1I='DO<V5R=F5R
M+"!B969O<F4@:70@=VEL;"!B92!A;&QO=V5D('1O(`T*<F5C96EV92!A;GD@
M;V8@=&AE(&)E;&]W(&ME>7,N("!792!A<W-U;64@=&AE(&EM<&QE;65N=&%T
M:6]N(&]F(&$@:V5Y(`T*;6%N86=E;65N="!I;F9R87-T<G5C='5R92P@=VAI
M8V@@:6YT97)F86-E<R!W:71H('1H92!$4G,@86YD(%1.<RP@87,@#0IW96QL
M(&%S('1H92!S96YD97)S(&%N9"!R96-E:79E<G,N("`-"@T*5V4@<')O<&]S
M92!T:&%T('1H:7,@:V5Y(&UA;F%G96UE;G0@<WES=&5M(&)E(')E<W!O;G-I
M8FQE(&9O<B`-"F1I<W1R:6)U=&EN9R!T:&4@9F]L;&]W:6YG(%1204-+('!R
M;W1O8V]L(&ME>7,Z#0H-"B`M("!'<F]U<$1A=&%+97DZ(`T*5&AE($=R;W5P
M1&%T84ME>2!I<R!T:&4@=6YI<75E('-Y;6UE=')I8R!K97D@9F]R(&1A=&$@
M96YC<GEP=&EO;B`-"G-H87)E9"!B>2!A;&P@;65M8F5R<R!O9B!A(&UU;'1I
M8V%S="!G<F]U<"P@97AC;'5D:6YG('1H92!I;G1E<FEO<B`-"G1R964@96YT
M:71I97,N("!4>7!I8V%L;'DL(&]N92!'<F]U<$1A=&%+97D@:7,@87-S;V-I
M871E9"!W:71H(&]N92`-"FUU;'1I8V%S="!G<F]U<"X@(%1H92!'<F]U<$1A
M=&%+97D@:7,@=7-E9"!T;R!P<F]V:61E(&%C8V5S<R!C;VYT<F]L(`T*=&\@
M=&AE(&1A=&$@<&%C:V5T(&)Y('=A>2!O9B!T:&4@4V5N9&5R+U-O=7)C92!E
M;F-I<&AE<FEN9R!T:&4@9&%T82`-"G!A8VME="X@(%-I;F-E(&]N;'D@=&AE
M(%)E8V5I=F5R<R!H;VQD('1H92!C;W!Y(&]F('1H92!'<F]U<$1A=&%+97DL
M(`T*;VYL>2!T:&4@4F5C96EV97)S('=I;&P@8F4@86)L92!T;R!D96-I<&AE
M<B!T:&4@9&%T82!P86-K971S+B`@5&AI<R`-"FES(&%N(&]P=&EO;F%L(&ME
M>2P@=VAI8V@@9&]E<R!N;W0@9&ER96-T;'D@8V]N8V5R;B!T:&4@5%)!0TL@
M#0IT<F%N<W!O<G0N#0H-"B`M("!'<F]U<$%U=&A+97DZ(`T*5&AE($=R;W5P
M075T:$ME>2!I<R!T:&4@=6YI<75E('-Y;6UE=')I8R!K97D@<VAA<F5D(&)Y
M(&%L;"!M96UB97)S(`T*;V8@82!M=6QT:6-A<W0@9W)O=7`L(&EN8VQU9&EN
M9R!T:&4@:6YT97)I;W(@8V]N=')O;"!N;V1E<RX@($]N92`-"D=R;W5P075T
M:$ME>2!I<R!A<W-O8VEA=&5D('=I=&@@;VYE(&UU;'1I8V%S="!G<F]U<"X@
M(%1H92!P=7)P;W-E(&]F(`T*=&AE($=R;W5P075T:$ME>2!I<R!T;R!P<F]V
M:61E(&%U=&AE;G1I8V%T:6]N(&]F('1H92`H<&]S<VEB;'D@#0IE;F-I<&AE
M<F5D*2!D871A('!A8VME=',N("!);B!T:&4@8V]N=&5X="!O9B!)4'-E8R!A
M=71H96YT:6-A=&EO;BP@#0IT:&ES(&-A;B!B92!A8VAI979E9"!U<VEN9R!A
M(&ME>65D(&AA<V@@9G5N8W1I;VXL('-U8V@@87,@2$U!0RU-1#4M#0HY-B!;
M34<Y.&%=(&%N9"!(34%#+5-(02TQ+3DV(%M-1SDX8ETN#0H-"B`M("!3=6)G
M<F]U<$%U=&A+97DZ(`T*5&AE(%-U8F=R;W5P075T:$ME>2!I<R!T:&4@=6YI
M<75E('-Y;6UE=')I8R!K97D@<VAA<F5D(&]N;'D@8GD@#0IE;G1I=&EE<R!W
M:71H:6X@82!G:79E;B!L;V-A;"!R96=I;VXL(&-O;G-I<W1I;F<@;V8@82!$
M4B!A;F0@:71S(`T*8VAI;&1R96X@*&-O;G-I<W1I;F<@;V8@;VYE(&]R(&UO
M<F4@4F5C96EV97)S+"!A;F0@<&]S<VEB;'D@;VYE(`T*8VAI;&0@1%(I+B!4
M:&4@4W5B9W)O=7!!=71H2V5Y(&ES('5S960@8GD@=&AE('!A<F5N="!I;B!A
M(&QO8V%L(`T*<F5G:6]N('1O('!R;W9I9&4@9W)O=7`M875T:&5N=&EC871I
M;VX@9F]R('1H92`H;&]S="D@9&%T82!P86-K971S(`T**'-T:6QL(&5N8VEP
M:&5R960@=6YD97(@=&AE($=R;W5P1&%T84ME>2D@=VAI8V@@87)E(')E=')A
M;G-M:71T960@=&\@#0IT:&4@4F5C96EV97)S(&EN('1H92!R96=I;VXL(&5I
M=&AE<B!V:6$@=6YI8V%S="!O<B!V:6$@<W5B=')E92T-"FUU;'1I8V%S="X@
M(%1H92!3=6)G<F]U<$%U=&A+97D@:7,@86QS;R!U<V5D(&)Y('1H92!E;G1I
M=&EE<R!I;B!A(`T*<F5G:6]N('1O(&=R;W5P+6%U=&AE;G1I8V%T92!C;VYT
M<F]L(&UE<W-A9V5S('1H870@87)E(&5X8VAA;F=E9"`-"G=I=&@@96%C:"!O
M=&AE<BX@4VEM:6QA<B!T;R!T:&4@1W)O=7!!=71H2V5Y+"!W92!P<F]P;W-E
M('1H92!U<V4@;V8@#0I)4'-E8R!B87-E9"!A=71H96YT:6-A=&EO;B!V:6$@
M:V5Y960@:&%S:"!F=6YC=&EO;BX-"@T*3F]T92!T:&%T(&9O<B!R96=I;VXM
M8F%S960@<F5T<F%N<VUI<W-I;VX@;V8@;&]S="!P86-K971S(&%N9"!F;W(@
M#0IC;VYT<F]L+7!A8VME="!A=71H96YT:6-A=&EO;BP@=&AE(%-U8F=R;W5P
M075T:$ME>2!I<R!U<V5D(&EN<W1E860@#0IO9B!T:&4@1W)O=7!!=71H2V5Y
M("AN;W0@8F]T:"DN#0H-"DYO=&4@=&AA="!I9B!A($12(&AA<'!E;G,@=&\@
M8F4@82!C:&EL9"!W:71H:6X@82!R96=I;VX@86YD(&%T('1H92`-"G-A;64@
M=&EM92!A('!A<F5N="!W:71H:6X@:71S(&]W;B!R96=I;VXL('1H96X@=&AA
M="!$4B!W:6QL(&AO;&0@='=O(`T*9&ES=&EN8W0@4W5B9W)O=7!!=71H2V5Y
M<R!C;W)R97-P;VYD:6YG('1O('1H92!T=V\@<F5G:6]N<RX-"@T*26X@=&AE
M(&9U='5R92P@4DU44"U)22!H;W!E<R!T;R!T86ME(&%D=F%N=&%G92!O9B!S
M=6)T<F5E+6UU;'1I8V%S="P@#0IW:&5R92!A('!A8VME="!C86X@8F4@<V5N
M="!T;R!A(&-O;G-T<F%I;F5D('!I96-E(&]F('1H92!M=6QT:6-A<W0@#0IT
M<F5E+B`@261E86QL>2P@82!S=6)T<F5E+6UU;'1I8V%S="!O;FQY(&=O97,@
M=&\@=&AE('!I96-E<R!O9B!T:&4@#0IT<F5E('1H870@:&%V92!L;W-T(&$@
M<&%C:V5T+B`@26X@=&AI<R!C87-E+"!A9&1I=&EO;F%L(')E9VEO;B!K97ES
M(`T*=V]U;&0@:&%V92!T;R!B92!D:7-T<FEB=71E9"P@=&AA="!S<&%N;F5D
M(&UU;'1I<&QE(&QE=F5L<R!O9B!T:&4@#0IH:65R87)C:'DN("!792!W:6QL
M(&QE879E('1H:7,@8V]N<VED97)A=&EO;B!F;W(@82!F=71U<F4@=&EM92P@
M#0IH;W=E=F5R+"!S:6YC92!S=6)T<F5E+6UU;'1I8V%S="!D;V5S(&YO="!Y
M970@97AI<W0@:6X@82!D97!L;WEA8FQE(`T*9F]R;2X-"@T*("T@($EN=&5R
M:6]R3F]D94ME>3H@#0I4:&4@26YT97)I;W).;V1E2V5Y(&ES(&$@<WEM;65T
M<FEC(&ME>2!S:&%R960@8GD@86QL(&EN=&5R:6]R(`T*8V]N=')O;"!N;V1E
M<R!W:71H:6X@82!G:79E;B!44D%#2R!H:65R87)C:'DN("!4:&4@:V5Y(&ES
M(`T*:6YD97!E;F1E;G0@;V8@86YY(&1A=&$@<W1R96%M+"!A;F0@:7,@=7-E
M9"!T;R!A=71H96YT:6-A=&4@8V]N=')O;"`-"G!A8VME=',@97AC:&%N9V5D
M(&%M;VYG('1H92!$4G,O5$XN("!3:&]U;&0@82!C:&EL9"U$4B!R97%U97-T
M(&$@#0IR971R86YS;6ES<VEO;B!O9B!A(&QO<W0@9&%T82!P86-K970@9G)O
M;2!I=',@<&%R96YT+412+"!T:&5N('1H92`-"G!A<F5N="U$4B!W:6QL(&1E
M;&EV97(@=&AE("AE;F-R>7!T960I(&QO<W0@<&%C:V5T('1O('1H92!C:&EL
M9"U$4BP@#0IA=71H96YT:6-A=&5D('5S:6YG('1H92!);G1E<FEO<DYO9&5+
M97DN#0H-"D)E9F]R92!T:&4@8VAI;&0M1%(@<F5T<F%N<VUI=',@=&AI<R!L
M;W-T(&1A=&$@<&%C:V5T('1O(&ET<R!O=VX@#0IR96=I;VXL(&ET(&UU<W0@
M9FER<W0@875T:&5N=&EC871E('1H92!P86-K970@9G)O;2!T:&4@<&%R96YT
M+412(`T*=7-I;F<@=&AE($EN=&5R:6]R3F]D94ME>2X@($ET(&UU<W0@=&AE
M;B!U<V4@:71S(&]W;B!3=6)G<F]U<$%U=&A+97D@#0IO9B!T:&4@<F5G:6]N
M(&AE861E9"]P87)E;G1E9"!B>2!T:&%T(&-H:6QD+412('1O('!R;W9I9&4@
M#0IA=71H96YT:6-A=&EO;B!F;W(@=&AE(')E=')A;G-M:71T960@9&%T82!P
M86-K970N("`-"@T*#0HV+B!,:6UI=&%T:6]N<PT*#0I4:&4@<')O<&]S960@
M<V5C=7)I='D@87)C:&ET96-T=7)E(&AA<R!C97)T86EN(&QI;6ET871I;VYS
M+B`@5&AE<V4@#0II;F-L=61E.@T*#0HH82D@0G)U=&4@1F]R8V4@071T86-K
M<RX@($%T('1H92!T<F%N<W!O<G0@;&5V96PL(&YO(&%D;6ES<VEO;B!C;VYT
M<F]L<R`-"F-A;B!B92!P=70@:6X@<&QA8V4@=&\@=&AR;W1T;&4@82!S96YD
M97(@=VAI8V@@:7,@9V5N97)A=&EN9R!L;W1S(&]F(`T*<W!U<FEO=7,@<&%C
M:V5T<R!T;R!A(&UU;'1I8V%S="!A9&1R97-S+B`@5&AI<R!I<R!T:&4@<F5Q
M=6ER96UE;G0@;V8@#0IT:&4@;F5T=V]R:R!L979E;"X@($%T('1H92!P<F5S
M96YT('1I;64L(&YO(&%C8V5P=&5D('-T86YD87)D(&5X:7-T<R`-"F9O<B!D
M;VEN9R!S;R!A="!T:&4@25`@375L=&EC87-T(&QE=F5L+@T*#0HH8BD@2V5Y
M($-O<G)U<'1I;VXN("!4:&4@<F5C;VUM96YD960@9W)O=7`@:V5Y(&%R8VAI
M=&5C='5R92!M86ME<R!A(`T*8V%R969U;"!T<F%D96]F9B!B971W965N('1H
M92!N965D('1O(&1I<W1R:6)U=&4@;6%N>2!K97ES+"!A;F0@=&AE(`T*;F5E
M9"!T;R!L;V-A;&EZ92!T:&4@969F96-T<R!O9B!A(&YO9&4@=VAI8V@@:7,@
M8V]M<')O;6ES960N(%1H:7,@#0IP<F]P;W-A;"!A;&QO=W,@82!L;V-A;"!R
M96-E:79E<B!T;R!P97)P971R871E(&1E;FEA;"!O9B!S97)V:6-E(`T*871T
M86-K<R!T;R!I=',@;&]C86P@1%(L(&%N9"!T:&4@<F5C96EV97)S('-E<G9E
M9"!B>2!T:&%T($12+@T*#0HH8RD@4')I=F%C>2X@($EN(&]R9&5R('1O('!R
M979E;G0@;F5T=V]R:R!T<F%F9FEC(&%N86QY<VES(&%T=&%C:W,L('1H92`-
M"F=R;W5P(&ME>7,@8V%N(&)E('5S960@=VET:"!)4'-E8R!T;R!E;F-R>7!T
M('1H92!P86-K971S('-E;G0@=&\@=&AE(`T*9W)O=7`L(&EN(&%D9&ET:6]N
M('1O(&1O:6YG('!A8VME="!A=71H96YT:6-A=&EO;BX@($AO=V5V97(L(&ET
M(&UU<W0@#0IB92!R96-O9VYI>F5D('1H870@=&AI<R!I<R!N;W0@82!G96YE
M<F%L('-O;'5T:6]N(&9O<B!D871A('!R:79A8WDN("`-"DEN('!A<G1I8W5L
M87(L('1H92!G<F]U<"!K97ES(&-A;B!E87-I;'D@8F4@<&%S<V5D(&9R;VT@
M82!V86QI9"`-"G)E8V5I=F5R('1O(&%N('5N875T:&]R:7IE9"!R96-E:79E
M<BP@=&\@96YA8FQE('!I<F%C>2!O9B!P87DM<&5R+0T*=7-E('-E<G9I8V5S
M+B`@5&AI<R!I<R!R96%S;VYA8FQE+"!A<R!D871A('!R:79A8WD@:7,@;F]T
M(&-O;G-I9&5R960@#0IP87)T(&]F('1H92!S8V]P92!O9B!44D%#2R!P<F]T
M;V-O;',N#0H-"BAD*2!-=6QT:6-A<W0@25!S96,N("!!;'1H;W5G:"!C=7)R
M96YT;'D@25!S96,@:7,@9V5N97)A;&QY(&EM<&QE;65N=&5D(`T*9F]R('!A
M:7(M=VES92`H;VYE+71O+6]N92D@8V]M;75N:6-A=&EO;G,@8F5T=V5E;B!O
M;F4@<V5N9&5R(&%N9"!O;F4@#0IR96-E:79E<BP@=&AE(&1E<VEG;B!O9B!)
M4'-E8R!I='-E;&8@86QL;W=S(&9O<B!U<V%G92!I;B!)4"`-"FUU;'1I8V%S
M="X@($-U<G)E;G1L>2!T:&4@4V5C=7)I='D@07-S;V-I871I;VX@*%-!*2!D
M969I;FET:6]N(`T*<F5Q=6ER97,@=&AE(%-E8W5R:71Y(%!A<F%M971E<B!)
M;F1E>"`H4U!)*2!T;R!B92!S96QE8W1E9"!B>2!T:&4@#0IR96-E:79E<B!;
M2T$Y.&%=+B`@2&]W979E<BP@<VEN8V4@:6X@25`@;75L=&EC87-T(&$@9W)O
M=7`@861D<F5S<R`-"FUA>2!B92!A<W-O8VEA=&5D('=I=&@@;75L=&EP;&4@
M<F5C96EV97)S+"!T:&4@97AI<W1I;F<@;65T:&]D(&]F(`T*<V5L96-T:6YG
M('1H92!34$D@;75S="!B92!R92UI;G1E<G!R971E9"X@($AE;F-E+"!I;B!T
M:&4@8V]N=&5X="!O9B`-"I--=6QT:6-A<W0@25!S96.4+"!A('!R92UD969I
M;F5D(&5N=&ET>2`H92YG+B!T:&4@<V]U<F-E+"!O<B!T:&4@:V5Y(`T*<V5R
M=F5R+VUA;F%G97(I(&UU<W0@9FER<W0@8W)E871E('1H92!'<F]U<"U302`H
M:6YC;'5D:6YG('-E;&5C=&EN9R`-"G1H92!34$DI(&%N9"!D96QI=F5R('1H
M92!'<F]U<"U302!T;R!A;&P@=&AE(&UE;6)E<G,@;V8@=&AE(&=R;W5P(`T*
M*&)Y(&5I=&AE<B!T:&4@(G!U<V@B(&]R(")P=6QL(B!P87)A9&EG;2DN("!4
M:'5S(')A=&AE<B!T:&%N(&)E:6YG(&$@#0IM;V1I9FEC871I;VX@=&\@=&AE
M($E0<V5C('-P96-I9FEC871I;VXL('1H:7,@<F5Q=6ER96UE;G0@<VEM<&QY
M(`T*;65A;G,@=&AA="!A9&1I=&EO;F%L('!R;W1O8V]L<R!A<F4@;F5E9&5D
M('1O(&5S=&%B;&ES:"!A('-H87)E9"`-"D=R;W5P+5-!+B`@3VYE('!O<W-I
M8FQE(&%P<')O86-H(&9O<B!T:&4@1W)O=7`@2V5Y($UA;F%G96UE;G0@*$=+
M32D@#0IP<F]T;V-O;"!I<R!T;R!A;'-O(&1E;&EV97(@=&AE($=R;W5P+5-!
M("AA;F0@;W1H97(@:V5Y:6YG(&UA=&5R:6%L*2`-"G1O('1H92!R96-E:79E
M<B!A="!T:&4@<V%M92!T:6UE(&ET(&1E;&EV97)S('1H92!'<F]U<$1A=&%+
M97D@#0I;2$--.3A=+@T*#0H-"C<N(%-U;6UA<GD-"@T*26X@<W5M;6%R>2P@
M:6X@=&AE(&-U<G)E;G0@=V]R:R!W92!H879E('!R;W!O<V5D(&9O<B!44D%#
M2R!P<F]T;V-O;',@=&AE(`T*<V5P87)A=&EO;B!O9B!D871A('-T<F5A;2!C
M;VYF:61E;G1I86QI='D@=7-I;F<@82!S>6UM971R:6,@:V5Y("AI+F4N(`T*
M:6UP;&EC:70@9W)O=7`M875T:&5N=&EC871I;VXI(&9R;VT@9&%T82!A=71H
M96YT:6-A=&EO;B!U<VEN9R!A(`T*<WEM;65T<FEC(&ME>2`H:2YE+B!E>'!L
M:6-I="!G<F]U<"UA=71H96YT:6-A=&EO;BDN($1A=&$@<W1R96%M(`T*8V]N
M9FED96YT:6%L:71Y('5S:6YG(&$@<WEM;65T<FEC(&ME>2!W:6QL(&)E(&-O
M;F1U8W1E9"!A="!T:&4@#0IA<'!L:6-A=&EO;B!L87EE<BP@=VAI;&4@9&%T
M82!A=71H96YT:6-A=&EO;B!U<VEN9R!A('-Y;6UE=')I8R!K97D@=VEL;"`-
M"F)E(&-O;F1U8W1E9"!A="!T:&4@;F5T=V]R:R!L87EE<BX@(%-I;F-E('1H
M92!$4G,O5$X@;6%Y(&)E("AO<'1I;VYA;&QY*2`-"G!R979E;G1E9"!F<F]M
M(')E861I;F<@=&AE(&UU;'1I8V%S="!D871A+"!T=V\@*#(I(&1I9F9E<F5N
M="!S>6UM971R:6,@#0IK97ES(&UU<W0@8F4@9&5P;&]Y960@8V]R<F5S<&]N
M9&EN9R!T;R!T:&4@;F5E9',@;V8@9&%T82!S=')E86T@#0IC;VYF:61E;G1I
M86QI='D@86YD(&1A=&$@9W)O=7`M875T:&5N=&EC871I;VXN#0H-"E1H:7,@
M<')O<&]S86P@9F]L;&]W<R!A(&YU;6)E<B!O9B!R97%U:7)E;65N=',L('-O
M;64@;V8@=VAI8V@@87)E(`T*<W!E8VEF:6,@=&\@5%)!0TL@<')O=&]C;VQS
M+B`@5&AE('5S92!O9B!G<F]U<"UA=71H96YT:6-A=&EO;B!A="!T:&4@#0IN
M971W;W)K(&QA>65R(&ES.@T*("`@+2!F;W(@<')O=&5C=&EO;B!O9B!T:&4@
M=')A;G-P;W)T(&%N9"!)4"!H96%D97)S+@T*("`@+2!T;R!A;&QO=R!A($12
M('1O(&%U=&AE;G1I8V%L;'D@<F5T<F%N<VUI="!L;W-T('!A8VME=',@=&\@
M#0H@("`@(&$@9&5S=&EN871I;VX@861D<F5S<R`H=6YI8V%S="!O<B!L;V-A
M;"!M=6QT:6-A<W0I(&1I9F9E<F5N="`-"B`@("`@9G)O;2!T:&4@;W)I9VEN
M86P@;75L=&EC87-T(&=R;W5P(&%D9')E<W,N#0H@("`M('1O(&%L;&]W(&$@
M<V5P87)A=&4@<WEM;65T<FEC(&ME>2!E;F-R>7!T:6]N('1O(&)E(&%P<&QI
M960@#0H@("`@("AA="!T:&4@87!P;&EC871I;VX@;&%Y97(I(&EN(&]R9&5R
M('!R979E;G0@=&AE($12<R]43B!F<F]M#0H@("`@(')E861I;F<@=&AE(&1A
M=&$N#0H-"E=E(&%S<W5M92!E;F-R>7!T:6]N(&9O<B!C;VYF:61E;G1I86QI
M='D@*'5S:6YG('1H92!'<F]U<$1A=&%+97DI(&AA<R`-"F)E96X@87!P;&EE
M9"!A8F]V92!T:&4@=')A;G-P;W)T(&QA>65R(&)Y('1H92!S96YD97(O<V]U
M<F-E+"!I;B!O<F1E<B!T;R`-"G!R979E;G0@82!$4B]43B!F<F]M(&1E8W)Y
M<'1I;F<@=&AE(&1A=&$N("!4:&4@1W)O=7!$871A2V5Y(&ES(&]N;'D@#0IA
M=F%I;&%B;&4@=&\@=&AE(&=R;W5P(&UE;6)E<G,L(&5X8VQU9&EN9R!T:&4@
M:6YT97)I;W(@8V]N=')O;"!N;V1E<RX-"@T*5V4@<')O<&]S92!T:&4@=7-E
M(&]F(&%N;W1H97(@:V5Y("A'<F]U<$%U=&A+97DI('1O('!R;W9I9&4@9W)O
M=7`M#0IA=71H96YT:6-A=&EO;B!F<F]M('1H92!S;W5R8V4O<V5N9&5R(&%T
M('1H92!N971W;W)K(&QA>65R('5S:6YG(`T*<WEM;65T<FEC(&ME>2!C<GEP
M=&]G<F%P:'DN("!4:&4@1W)O=7!!=71H2V5Y(&ES(&MN;W=N(&)Y('1H92!M
M96UB97)S(&]F(`T*=&AE(&=R;W5P+"!A<R!W96QL(&%S('1H92!I;G1E<FEO
M<B!C;VYT<F]L(&YO9&5S+@T*#0I&;W(@=&AE(')E=')A;G-M:7-S:6]N(&]F
M(&QO<W0@<&%C:V5T<R!T;R!R96=I;VYS('=I=&AI;B!A(&=R;W5P+"!E:71H
M97(@#0IV:6$@=6YI8V%S="!O<B!L;V-A;"!M=6QT:6-A<W0L('=E('!R;W!O
M<V4@=&AE('5S92!O9B!A(%-U8F=R;W5P075T:$ME>2`-"BAI;G-T96%D(&]F
M('1H92!'<F]U<$%U=&A+97DI('=H:6-H(&ES(&MN;W=N(&]N;'D@=&\@96YT
M:71I97,@=VET:&EN(&$@#0IR96=I;VX@*$12(&%N9"!I=',@8VAI;&1R96XI
M+B!4:&4@4W5B9W)O=7!!=71H2V5Y(&ES(&%L<V\@=7-E9"!B>2!T:&4@#0IE
M;G1I=&EE<R!I;B!A(')E9VEO;B!T;R!G<F]U<"UA=71H96YT:6-A=&4@8V]N
M=')O;"!M97-S86=E<R!T:&%T(&%R92`-"F5X8VAA;F=E9"!W:71H(&5A8V@@
M;W1H97(N(`T*#0H-"C@N(%)E9F5R96YC97,-"@T*6TA#33DX72!4+B!(87)D
M:F]N;RP@0BX@0V%I;B!A;F0@22X@36]N9V$L()-);G1R82U$;VUA:6X@1W)O
M=7`@2V5Y(`T*36%N86=E;65N="!0<F]T;V-O;)0L('=O<FL@:6X@<')O9W)E
M<W,L(&1R869T+6EE=&8M:7!S96,M:6YT<F%G:VTM#0HP,"YT>'0L($YO=B`Q
M.3DX+@T*#0I;2$@Y.6%=($@N($AA<FYE>2!A;F0@12X@2&%R9&5R+"`B1W)O
M=7`@4V5C=7)I='D@07-S;V-I871I;VX@2V5Y(`T*36%N86=E;65N="!0<F]T
M;V-O;"(L('=O<FL@:6X@<')O9W)E<W,L(&1R869T+6AA<FYE>2US<&%R=&$M
M9W-A:VUP+7-E8RT-"C`P+G1X="P@36%Y(#$Y.3DN#0H-"EM+0U=0,#!=($TN
M($MA9&%N<VMY+"!$+B!#:&EU+"!*+B!797-L97DL($HN(%!R;W9I;F\N(""3
M5')E92UB87-E9"`-"E)E;&EA8FQE($UU;'1I8V%S="`H5%)!32F4+"!W;W)K
M(&EN('!R;V=R97-S+"!D<F%F="UK861A;G-K>2UT<F%M+0T*,#(N='AT+"!*
M86YU87)Y(#(P,#`N#0H-"EM+03DX85T@4RX@2V5N="!A;F0@4BX@071K:6YS
M;VXL()-396-U<FET>2!!<F-H:71E8W1U<F4@9F]R('1H92!);G1E<FYE="`-
M"E!R;W1O8V]LE"P@24541BP@4D9#(#$X,C4L(#$Y.3@N#0H-"EM+03DX8ET@
M4RX@2V5N="!A;F0@4BX@071K:6YS;VXL()-)4"!!=71H96YT:6-A=&EO;B!(
M96%D97*4+"!W;W)K(&EN(`T*<')O9W)E<W,L($EN=&5R;F5T($1R869T+"!*
M=6QY(#$Y.3@N#0H-"EM-1SDX85T@0RX@36%D<V]N+"!2+B!';&5N;BP@(E1H
M92!5<V4@;V8@2$U!0RU-1#4M.38@=VET:&EN($534"!A;F0@04@B+"`-"G=O
M<FL@:6X@<')O9W)E<W,L(&1R869T+6EE=&8M:7!S96,M875T:"UH;6%C+6UD
M-2TY-BTP,RYT>'0L($9E8B`Q.3DX#0H-"EM-1SDX8ET@0RX@36%D<V]N+"!2
M($=L96YN+"!4:&4@57-E(&]F($A-04,M4TA!+3$M.38@=VET:&EN($534"!A
M;F0@04@B+"`-"G=O<FL@:6X@<')O9W)E<W,L(")D<F%F="UI971F+6EP<V5C
M+6%U=&@M:&UA8RUS:&$Q+3DV+3`S+G1X="P@1F5B+"`Q.3DX+@T*#0I;4CDR
M72!2+B!2:79E<W0L(")-1#4@1&EG97-T($%L9V]R:71H;2(L(%)&0S$S,C$L
M($%P<FEL(#$Y.3(N#0H-"EM24T$Y,UT@(%)302!,86)O<F%T;W)I97,L(")0
M2T-3(S$Z(%)302!%;F-R>7!T:6]N(%-T86YD87)D(BP@5F]L=6UE,2XU+"`-
M"DYO+B`Q.3DS+@T*#0I;5T)033DX72!"+B!7:&5T=&5N+"!-+B!"87-A=F%I
M86@L(%,N(%!A=6PL(%0N($UO;G1G;VUE<GDL()-23510+4E)(`T*4W!E8VEF
M:6-A=&EO;I0N("!7;W)K(&EN('!R;V=R97-S+"!D<F%F="UW:&5T=&5N+7)M
B='`M:6DM,#`N='AT+"!!<')I;"`-"C@L(#$Y.3@N#0H-"@``
`
end
--=====================_246435064==_
Content-Type: text/plain; charset="us-ascii"
--=====================_246435064==_--
>From owner-rmt@listserv.lbl.gov Wed Feb 9 09:03:11 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id JAA23285;
Wed, 9 Feb 2000 09:02:05 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id JAA23281
for <rmt@listserv.lbl.gov>; Wed, 9 Feb 2000 09:02:02 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id JAA20566
for <rmt@listserv.lbl.gov>; Wed, 9 Feb 2000 09:02:01 -0800 (PST)
Received: from phobos.talarian.com (mailhost.talarian.com [207.5.32.17])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id JAA20546
for <rmt@lbl.gov>; Wed, 9 Feb 2000 09:01:59 -0800 (PST)
Received: from tahoe ([207.5.32.66]) by phobos.talarian.com (8.9.0/8.9.0) with SMTP id JAA06011; Wed, 9 Feb 2000 09:01:07 -0800 (PST)
Message-Id: <4.1.20000209085625.01c8b640@mailhost.talarian.com>
X-Sender: bwhetten@mailhost.talarian.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1
Date: Wed, 09 Feb 2000 08:58:01 -0800
To: smug@baynetworks.com, rmt@lbl.gov
From: Brian Whetten <whetten@talarian.com>
Subject: Security Considerations for TRACK Protocols
Mime-Version: 1.0
Content-Type: multipart/alternative;
boundary="=====================_286204430==_.ALT"
Sender: owner-rmt@lbl.gov
Precedence: bulk
--=====================_286204430==_.ALT
Content-Type: text/plain; charset="us-ascii"
Someone reported that the file was corrupted, so it is attached below.
Sorry to add to everyone's mailbox!
Brian
Internet Engineering Task Force T. Hardjono
INTERNET-DRAFT Nortel Networks
draft-ietf-rmt-track-security-00.txt B. Whetten
January 12, 2000 Talarian
Security Requirements For TRACK Protocols
<draft-ietf-rmt-track-security-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as
"work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document discusses the security issues within TRee-based
ACKnowledgement (TRACK) reliable multicast protocols, and identifies
some constraints and requirements for security provisions for these
protocols. Based on the constraints and requirements, the document
proposes a separation of data packet confidentiality and authentication,
from transport layer protection. It proposes that TRACK protocols be
primarily concerned with group authentication of control and data
packets, to protect against attacks on the transport infrastructure. It
proposes that data confidentiality and source authentication be provided
separately from this low level group authentication, ideally at the
application level. We show that this is particularly important for
TRACK protocols, because of the requirement that the interior control
nodes only optionally have access to the data packet payload.
Specifically, the current work proposes that data and control packet
authentication be provided using IPsec-based authentication at the
network layer. This approach allows an interior control node to
authentically retransmit a lost data packet (which remains encrypted
under the separate data-encryption key) to its own children (a set of
Receivers), while making use of the IPsec features, such as protection
against replay attacks.
This document then provides a specific proposal for how group keys
should be divided up among group members, for control and data packet
authentication. While providing some rationale for divorcing this
proposal from that of source authentication and data confidentiality, it
does not provide a specific proposal for those pieces.
1. Background: The Multicast Security Problem
The problem of multicast security can be divided into three general
areas of concern:
- Data Encryption and Source Authentication. The method used to
encipher or scramble the multicast data, and verify the identity of
the sender of this data.
- Key Distribution. The method used to securely distribute group
keys and keying material to the members of a group, for use in
decrypting or authenticating the data or control packets.
- Infrastructure protection. Mechanisms used to protect the
multicast infrastructure itself, and to minimize the ability of an
intruder to deny service to legitimate users.
The security of reliable multicast protocols falls primarily into the
third category of problems. Complete denial of service protection must
start at the network level (i.e. IP Multicast), with controls placed on
senders from overloading the network with brute force "spamming", as
well as with authentication of control packets, to keep users from
corrupting the state of the IP Multicast protocols. A transport
protocol needs to address the same issues, checking to make sure that
senders are not sending more data than they are allowed (such as with
enforceable congestion control), and authenticating control packets, to
protect the protocol state. Control packet authentication is
particularly important in TRACK protocols, because of their use of
interior control nodes (for example, in RMTP-II, DRs and TNs) to
increase scalability.
An optional extension to the requirement of infrastructure protection is
that of infrastructure privacy. Some applications require that the
headers of the network packets be encrypted, to provide protection from
network analysis attacks.
2. Independence of RM Security
The security of reliable multicast (RM) protocols is part of the larger
problem of the security of the multicast infrastructure, which also
consists of the security of the multicast routing protocols.
Since RM protocols and multicast routing protocols exist at different
layers in the protocol stack, and since different RM protocols may be
employed with different multicast routing protocols, it is useful from a
security perspective to treat these two security problems separately.
In addition, although in many instances the topology of RM
infrastructure may coincide with that of the multicast routing protocol,
such symmetry cannot be assumed for all cases.
Similarly, from a design perspective, the problem of securing the data
stream (e.g. through content encryption) should be separated from the
issue of securing reliable multicast protocols.
Although we treat RM-security as an independent problem from other
multicast security problems, this does not preclude using the solutions
in other areas in order to solve the security needs of RM. For example,
the use of IPsec technology at the IP layer to authenticate multicast
routing protocol control-packets can also be used to authenticate RM
control-messages. However, the instance of deploying IPsec in both
cases must be distinguished and treated separately.
3. RMTP-II Overview
While not necessarily typical of all TRACK protocols (such as TRAM
[KCWP00]), we use the RMTP-II protocol as an example for analysis and
discussion. The RMTP-II protocol features a number of entities which
participate in a logical tree or hierarchy and which exchange control-
messages with each other. The entities are the Top Node (TN), the
Sender Nodes (SD), the Designated Receiver Nodes (DR) and the Receiver
Nodes (RN).
RMTP-II places receivers into local regions, where each region is
assigned to a DR. These groups are arranged hierarchically as a tree
rooted at the TN, with the DRs representing the nodes of the tree, and
the receivers as the leaves. The senders connect directly to the top
node, at the top layer of the hierarchy. The receivers send their
control-messages (ACKs, NACKs, etc.) to the DR of their region.
Retransmission of lost packets may be done locally by the DR of a
domain, or globally from the sender. Each DR sends their control
messages to the DR at the next level up the hierarchy. This process is
repeated until the TN, who then forwards the control messages to the
appropriate sender. The DRs and TN aggregate the positive
acknowledgements from the receivers, and suppress the redundant negative
acknowledgements, in order to solve the ACK/NACK implosion problem.
A DR maintains a local multicast group to just its children, and
subscribes to the local multicast group of its parent. A DR uses this
local multicast group for retransmissions to its children. While RMTP-
II uses multicast for retransmission from a DR, other TRACK protocols
may choose to optionally use unicast.
RMTP-II distinguishes between a data channel and a control channel. A
data channel is a global multicast group created using the underlying
multicast routing protocol. A control channel is the interconnected
topology of control nodes, for handling error recovery and positive
packet acknowledgements.
In order to obtain data packets from the Sender, a Receiver in a given
RMTP-II region must join the multicast group (i.e. the data channel).
The DR of that region must join every multicast group that its
descendants have joined. Note that the DRs are not responsible for
forwarding the data packets multicast by the Sender, since that data
stream is propagated by the underlying multicast routing protocol.
The figure below illustrates an RMTP-II tree with multiple control
nodes.
HACKs
-----------> (Top Node)----------------->(Sender node)
^ ^^^ |
| / | \ |
HACKs | / | \ |
| / | \ |
| / | \ (Designated |
/ | \ Receiver |
/ | \ node) v
Control D R D R D R <------------|
Channel ^^ ^^^ ^^ | Data
/ | / | \ | \ | Channel
/ | / | \ | \ |
/ | / | \ | \ v
RN RN RN RN RN RN RN <------
(Receiver Nodes)
4. TRACK Protocol Security Issues and Requirements
This section details the security requirements for TRACK protocols which
are similar to RMTP-II. These requirements include general multicast
transport requirements, as well as some requirements specific to TRACK
protocols.
4.1 Background
In addressing the security issues specific to TRACK protocols, it is
useful to consider the general aspects of security relating to reliable
multicast.
- Layer in which security is applied:
The two layers in which security mechanisms are deployed are
typically the network layer and the application layer. In the
network layer the protocol that is the most commonly used is the
IPsec protocol, which provides authentication and/or encryption. In
either case, with IPsec the transport headers (and IP headers) are
protected. When authentication and/or encryption is applied at the
application layer, neither the transport headers nor the IP headers
are protected.
- Types of authentication:
- Source-authentication: If public key (asymmetric) cryptography is
deployed, where only the sender knows the secret-half of the
public key pair, then unique "source-authentication" can be
established.
- Group-authentication: If shared key (symmetric) cryptography is
deployed and the key is shared by more than two parties, then
only "group-authentication" can be established. This means that a
receiver in a group is only certain that the entity that sent the
message is in possession of the symmetric-key, and is thus
assumed to be a member of the group sharing the key.
In the following, the TRACK specific requirements are further
elaborated.
4.2 Authentication of Control-Messages
As stated above, the directly relevant security concern for TRACK
protocols is protection of the multicast infrastructure, particularly of
the control tree, in order to provide protection against replay or other
attacks which seek to corrupt the state of the transport protocol. The
authentication of control messages exchanged among TRACK protocol
entities represents the minimal security mechanisms necessary to do so.
Two types of authentication mechanisms can be adopted, corresponding to
the two basic types of cryptosystems. In the context of reliable
multicast, throughput and latency is typically of high importance, and
group-authentication based on symmetric cryptography appears to be
preferable.
Given this, the efficiencies of symmetric key based authentication
appear to outweigh the benefits of public key based authentication.
There are potentially cryptographic schemes that can provide the unique
source-authentication of public key cryptography while providing the
performance characteristics of symmetric key based authentication (e.g.
efficient digital signing of the hash-value of several data packets).
However, at the present time, for the general case of infrastructure
protection, the complexities of these options appear to outweigh the
benefits.
Thus, in summary, for TRACK protocol control-messages, explicit group-
authentication at the IP layer should be deployed using symmetric
cryptography. Although a number of technologies are available, we
propose specifically IPsec-based authentication using a keyed-hash
function [KA98b,MG98a,MG98b] due to its growing use and availability.
We denote the symmetric key used for control message authentication as
the InteriorNodeKey. The InteriorNodeKey is a symmetric key shared by
all DRs and the TN within a given RMTP-II or TRACK hierarchy. The key
is independent of any data stream, and is used to authenticate control
packets exchanged among the DRs/TN.
4.3 Non-Decipherability of Data Packets by DRs
RMTP-II requires that a Designated Receiver Node (DR) join all of the
multicast groups that its descendants have joined. This is also true of
the Top Node (TN).
For TRACK protocols it is preferable that authentication methods based
on a symmetric key be deployed due to performance reasons. This may be
achieved explicitly, such as by using a keyed hash function, or
implicitly using encryption (where a successful decryption implies the
ciphertext is both unmodified in transit and was generated by a holder
of the symmetric key).
However, TRACK protocols have a further requirement, namely that their
repair nodes (i.e. DR and TN) be (optionally) prevented from reading the
multicast data. More specifically, we perceive that DRs may be
administered as part of a reliability service offered by third parties
such as ISPs. These third parties may refuse the ability to decipher
data packets in order to avoid the legal ramifications of having access
to the data contents. Thus, from the ISP perspective, TRACK protocols
must allow them to prove to the content-owner that they do not posses
the means to alter the contents transmitted through the multicast
groups.
Given the above requirement of the DRs/TN and the need for fast
authentication, we propose:
- the separation of data stream confidentiality using either a symmetric
or asymmetric key from data authentication using a symmetric key (i.e.
explicit group-authentication).
- data stream confidentiality will be conducted at the application
layer, while data authentication using a symmetric key will be
conducted at the network layer.
- since the DRs/TN may be (optionally) prevented from reading the
multicast data, two (2) different keys must be deployed corresponding
to the needs of data stream confidentiality and data group-
authentication.
4.4 Authentication of Data Retransmissions
In TRACK protocols, retransmissions of data packets may come from the
original source, or from a different (DR) node. This local recovery is
an important tool for increasing the scalability and latency of a
protocol. In the context of security, it raises the question as to what
authentication methods should be used on these packets.
(a) If source authentication (using public key cryptography) and data
confidentiality (including implicit group authentication) is
applied at the application layer, the DR can simply replay the data
(i.e. payload) unmodified to the querying receivers, either via
unicast or local multicast.
(b) If, however, explicit group authentication (using a symmetric key)
was applied at the network layer (e.g. using IPsec), then the DR
cannot simply replay the packet due to restrictions at the IP
layer. Thus, in this case the DR must re-apply the group-
authentication.
Taking case (b) further, there are two options corresponding to
whether retransmission by the DR is performed via unicast to a
receiver or via multicast.
(i) If the retransmission is unicast to a given receiver, then it
is preferred if the DR and the receiver share a separate
symmetric key for this purpose.
(ii) If the retransmission is via multicast to a subgroup (as is
the case in RMTP-II), then the DR can either use the existing
group-shared symmetric key or use a separate symmetric key only
for the subgroup under the DR. We propose to use the later
approach, which means that a DR and its children (receivers)
must share a separate symmetric key for explicit group
authentication at the IP layer.
4.5 Keys for Data Confidentiality and for Authentication
As mentioned above, we propose the separation of data stream
confidentiality using a symmetric key encryption (effecting an implicit
group-authentication) from data authentication using a symmetric key and
a keyed hash function (i.e. explicit group-authentication).
We now denote the symmetric key for data stream confidentiality at the
application layer as the GroupDataKey. Only the source and valid
receivers will have a copy of the GroupDataKey, which is delivered to
them through the appropriate Group Key Management (GKM) protocol that
identifies and verifies the members individually. In the case where the
DRs and the TN are not permitted to read the multicast data, they must
be prevented by the GKM protocol from obtaining the GroupDataKey.
We denote the symmetric key for explicit group-authentication at the
network layer as the GroupAuthKey. The GroupAuthKey is distinct from the
GroupDataKey. For TRACK protocols, we propose the use of IPsec with
keyed hashing at the network layer to provide explicit group-
authentication using the GroupAuthKey. Unlike the GroupDataKey, the
GroupAuthKey is known by all entities involved in the multicast. This
includes all interior node entities (e.g. TN, DR), the Sender/Source and
the Receivers.
4.6 Authenticity of NACK and other Control Packets
In TRACK protocols, a DR responds to a NACK from one its children
(typically a receiver) by re-transmitting the lost packet via local
multicast. This basic behavior can be open to abuse by an attacker who
injects spurious NACK messages towards the DR, effecting a local
multicast to all children of the DR. In itself this is a waste of
bandwidth and may result in a denial of resource to the group members.
Other control packets directly impact the state of the group, such as
the group membership, and could also be used in denial of service
attacks.
To counter these types of attack, the control messages themselves must
be authenticated by the DR. Digital signatures using public key
cryptography could be applied to the control messages. However, this
approach would be inefficient due to the high CPU cost of public key
encryption. Also, it would require creating a separate security
association with each child of the DR.
Instead, we propose that NACK and other control messages from a child
(receiver) to its DR be protected using symmetric IPsec based
authentication. This requires the two parties to first establish a
Security Association (SA) and a shared symmetric key. The symmetric key
can be unique per child, or be uniform over a subgroup of receivers
(i.e. those under the DR).
4.7 Fault Recovery
In RMTP-II, if a child's connection to a DR or TN fails, RMTP-II
provides automatic mechanisms for failing-over to another DR or backup
TN. This reconnection needs to happen quickly, so that the child can
rejoin the data stream before too much data has been missed to recover
from. If a child needs to get a new key for that DR/TN, this can be a
bottleneck. Given that the key distribution infrastructure may be
centralized, and a majority of receivers may need to fail over at the
same time, this presents a major opportunity for network congestion.
The RMTP-II entities are given the address of their backup control node
at startup time. While these addresses can change, they are expected to
always have the addresses of one or more backup nodes. When
implementing security features, each child should be required to keep
the key for its primary backup DR/TN. Optionally, it may need to keep
the keys for each of the backup control nodes it is using.
4.8 Implementation with Different Levels of OS Protection
A TRACK protocol can be implemented in (at least) one of three ways.
- Application level. Most implementations of TRACK protocols for the
near future are expected to operate in the application level of the
OS, running on top of UDP.
- Kernel. As TRACK protocols become bundled with standard operating
systems, it is expected to become a kernel module, and run directly
over IP.
- Virtual machine. Some TRACK entities (particularly senders and
receivers) will be run in virtual machines, such as when implemented
as a Java applet.
TRACK protocol security must accommodate all three of these options.
This raises the following issues.
- Application Level. One advantage of application level
implementations is their flexibility. These implementations could
use either IPsec routines, the application layer security functions,
or both.
- Virtual Machines. There are issues trying to use IPsec with
virtual machines such as Java, which have to date hindered the
support of IPsec through native Java applets. This makes it
important for a TRACK protocol to optionally be able to use only
application level security.
- Kernel Implementations. As a TRACK protocol becomes bundled with
operating systems, it is expected that IPsec will also become bundled
with the OS. To avoid having to use less trusted software in the
application level, the TRACK protocol will have to be able to use a
kernel level security system (such as IPsec) for its transport level
security needs.
4.9 Separate Regional Protection
TRACK protocols are expected to be used for content distribution from a
few senders to many receivers. In the case of applications that
distribute critical data to many different organizations, it is not
enough to trust all receivers. For example, a market data feed provider
could be using a TRACK protocol to distribute live market data feeds to
competing financial institutions. In this situation, the data feed
provider needs to be able to protect individual companies from corrupted
control packets from other customers (which could be generated either
intentionally, or more likely, unintentionally) which would cause denial
of service.
As we propose in the next section, a TRACK protocol must provide
separate regional keys for the group-authentication of control packets
sent from the receivers of different DRs. This allows the
authentication of control-messages for each set of receivers (part of
one customer) to be done separately (from another set of receivers, as
part of different customer). Since for each set of receivers a different
key is used, this limits the ability of a customer to perpetrate denial
of service attacks against other customers.
4.10 Piracy of Pay-Per-Use Data
A common scenario for TRACK protocols involves pay-per-use data
distribution, such as live market data, pay-per-view video signals, or
paid subscriptions to software updates. In this scenario, a receiver
cannot be trusted to not give its group keys to outside entities, who
are trying to get free service. We mention this requirement since it is
different than point-to-point security. However, this requirement is
the responsibility of the application level security.
5. Architecture Recommendations
The previous section detailed some of the specific requirements and
issues for TRACK protocol security, along with some individual
recommendation on handling each one. Given those requirements, we
propose the following architecture recommendations for implementing
security with TRACK protocols.
5.1 Separation of Security Responsibilities
As detailed above, TRACK protocols are primarily concerned with
protection of the network infrastructure, rather than with issues such
as data confidentiality and source-authentication. Therefore, we
recommend that TRACK protocols SHOULD provide:
(a) group authentication of control packets, and
(b) optional group authentication of data packets
Optionally, TRACK protocols MAY choose to provide:
(c) optional privacy of data and of control packet headers.
To accomplish this, we recommend that TRACK protocols use IPsec
technology at the network layer, while letting application level
security perform additional functions as needed. For implementations
that do not have access to IPsec, and are not implemented as part of the
OS, application level security can be used instead--although this of
course risks incompatibility with other implementations.
The separation of group-authentication of data from both data source-
authentication and data-confidentiality is tightly coupled to the choice
of recommending IPsec for the group authentication. These two choices
are motivated by the following:
(a) Non-Decipherability of data by interior control nodes: it is a
requirement of TRACK protocols that in some deployments, its control
entities (e.g. TN, DR) be unable to decipher the data packet. Thus,
the GroupDataKey for data encryption and GroupAuthKey for group-
authentication must be distinct. It is not sufficient to simply use
an identical key (for the GroupDataKey and GroupAuthKey) and to
instruct the TRACK protocol entities to avoid deciphering the data
packets. It must be provably shown that the interior control nodes
do not have the ability to decipher the data packets (even if they
wish to do so).
(b) Use of IPsec technologies: considerable effort has been invested in
developing the IPsec architecture and protocols [KA98a, KA98b], and
a growing number of vendors are supporting IPsec. The IPsec suite
offers a number of features, including some protection against
replay attacks.
(c) Multicast IPsec: the IPsec architecture has intentionally allowed
the use of IPsec for IP multicast without changes to the basic
constructs within the IPsec suite. Currently, work is proceeding
towards the establishment of a standard mechanism to select the
Group Security Association (Group SA or GSA) for multicast and a
method to disseminate the GSA to the valid members of the group
[HCM98,HH99a].
(d) Appropriate Level: since the primary purpose of transport level
security is to secure the infrastructure at a transport level, using
a network or transport level security protocol allows each to be
implemented together--either in the OS, or in the application layer.
5.2 Division of Responsibilities
Given this fundamental division between application and transport
responsibilities, we divide the security responsibilities in to four
parts.
Network Responsibilities (IP and IP Multicast)
----------------------------------------------
- Admission controls on senders--to protect against "brute
force" spamming attacks.
- Authentication of routing control packets--to protect
the routing infrastructure from denial of service attacks.
Transport Responsibilities (TRACK Protocols)
------------------------------------
- Protection of the control messages from replay attacks
and other denial-of-service attacks.
- Optional: protection of data packets from replay attacks.
- Optional: encryption of control messages to minimize
network analysis by attackers.
End to End Responsibilities (Application)
-----------------------------------------
- Source authentication--to verify the authenticity of data,
and provide optional non-repudiation of data.
- Data encryption--to provide data confidentiality.
Key Management Infrastructure
-------------------------------
- Distribution of transport and network layer keys: authentication
of individual hosts, and distribution of keys to those hosts
- Application level key distribution: authentication of
individual processes, and distribution of keys to those processes
- Optional: periodic rekeying--group keys periodically need
to be changed, both after a certain time limit has expired,
and/or after the group membership changes.
The figure below shows how these components relate to each other. TRACK
protocols can be used without any additional security at the IP/IP
Multicast level, although this will not provide full protection from
denial of service attacks. TRACK protocols will be able to be used on
top of UDP or raw IP/IP Multicast. A TRACK protocol can use either
IPsec or application level security for its network security
requirements, although we recommend using IPsec wherever possible.
+--------------------+ +----------+
+--------------+<----->| Application |<----->| App Sec |
| | +--------------------+ |==>| |
| | | TRACK |<--| +----------+
| Key |<----->+ +---------+ |-->| |
| Management | | | UDP | | IPsec |
| | +--------------------+ | |
| |<=====>| IP, IP Multicast |<=====>| |
+--------------+ +--------------------+ +----------|
<===> Optional
When a data packet is to be sent to the multicast group, the
Sender/Source first (optionally) enciphers the data packet using the
GroupDataKey above the RM/transport layer. It is then passed to the
RM/transport layer, which attaches the necessary RM headers. The result
is then passed down to the IP layer where IPsec authentication is
established (using the GroupAuthKey).
A Receiver in the multicast group would be in possession of both the
GroupDataKey and the GroupAuthKey, and thus will be able to first
authenticate the data packet using the GroupAuthKey, and then continue
to decipher the data packet using the GroupDataKey.
A Designated Receiver Node (DR) will possess the GroupAuthKey (but not
the GroupDataKey), and thus will only be able to authenticate the packet
using the GroupAuthKey using IPsec. After verifying the authenticity of
a received data packet, a DR will be able to retransmit the (enciphered)
data packet to its children, either via unicast or region-based local
multicast. A retransmission of a lost data packet from a DR will be
authenticated using a SubgroupAuthKey (see below) which is a symmetric
key shared by a DR and all its children Receivers only.
Again, although the current work proposes the use of unicast IPsec and
multicast IPsec at the network layer, it does not preclude the use of
other authentication technologies at the network layer or at the
RM/transport layer. Such technologies, however, will have to address
much of the same issues faced by IPsec, including prevention of replays,
the creation and maintenance of state (i.e. "Security Associations")
associated with the GroupAuthKey, the Sender and Receiver(s), and other
features and supporting mechanisms. It is precisely the growing
availability of IPsec that motivates the current work to choose IPsec
for network layer authentication for both data and control packets.
5.3 TRACK Keys
In general, each node in the hierarchy must be able to authenticate
itself to the key management entity/server, before it will be allowed to
receive any of the below keys. We assume the implementation of a key
management infrastructure, which interfaces with the DRs and TNs, as
well as the senders and receivers.
We propose that this key management system be responsible for
distributing the following TRACK protocol keys:
- GroupDataKey:
The GroupDataKey is the unique symmetric key for data encryption
shared by all members of a multicast group, excluding the interior
tree entities. Typically, one GroupDataKey is associated with one
multicast group. The GroupDataKey is used to provide access control
to the data packet by way of the Sender/Source enciphering the data
packet. Since only the Receivers hold the copy of the GroupDataKey,
only the Receivers will be able to decipher the data packets. This
is an optional key, which does not directly concern the TRACK
transport.
- GroupAuthKey:
The GroupAuthKey is the unique symmetric key shared by all members
of a multicast group, including the interior control nodes. One
GroupAuthKey is associated with one multicast group. The purpose of
the GroupAuthKey is to provide authentication of the (possibly
enciphered) data packets. In the context of IPsec authentication,
this can be achieved using a keyed hash function, such as HMAC-MD5-
96 [MG98a] and HMAC-SHA-1-96 [MG98b].
- SubgroupAuthKey:
The SubgroupAuthKey is the unique symmetric key shared only by
entities within a given local region, consisting of a DR and its
children (consisting of one or more Receivers, and possibly one
child DR). The SubgroupAuthKey is used by the parent in a local
region to provide group-authentication for the (lost) data packets
(still enciphered under the GroupDataKey) which are retransmitted to
the Receivers in the region, either via unicast or via subtree-
multicast. The SubgroupAuthKey is also used by the entities in a
region to group-authenticate control messages that are exchanged
with each other. Similar to the GroupAuthKey, we propose the use of
IPsec based authentication via keyed hash function.
Note that for region-based retransmission of lost packets and for
control-packet authentication, the SubgroupAuthKey is used instead
of the GroupAuthKey (not both).
Note that if a DR happens to be a child within a region and at the
same time a parent within its own region, then that DR will hold two
distinct SubgroupAuthKeys corresponding to the two regions.
In the future, RMTP-II hopes to take advantage of subtree-multicast,
where a packet can be sent to a constrained piece of the multicast
tree. Ideally, a subtree-multicast only goes to the pieces of the
tree that have lost a packet. In this case, additional region keys
would have to be distributed, that spanned multiple levels of the
hierarchy. We will leave this consideration for a future time,
however, since subtree-multicast does not yet exist in a deployable
form.
- InteriorNodeKey:
The InteriorNodeKey is a symmetric key shared by all interior
control nodes within a given TRACK hierarchy. The key is
independent of any data stream, and is used to authenticate control
packets exchanged among the DRs/TN. Should a child-DR request a
retransmission of a lost data packet from its parent-DR, then the
parent-DR will deliver the (encrypted) lost packet to the child-DR,
authenticated using the InteriorNodeKey.
Before the child-DR retransmits this lost data packet to its own
region, it must first authenticate the packet from the parent-DR
using the InteriorNodeKey. It must then use its own SubgroupAuthKey
of the region headed/parented by that child-DR to provide
authentication for the retransmitted data packet.
6. Limitations
The proposed security architecture has certain limitations. These
include:
(a) Brute Force Attacks. At the transport level, no admission controls
can be put in place to throttle a sender which is generating lots of
spurious packets to a multicast address. This is the requirement of
the network level. At the present time, no accepted standard exists
for doing so at the IP Multicast level.
(b) Key Corruption. The recommended group key architecture makes a
careful tradeoff between the need to distribute many keys, and the
need to localize the effects of a node which is compromised. This
proposal allows a local receiver to perpetrate denial of service
attacks to its local DR, and the receivers served by that DR.
(c) Privacy. In order to prevent network traffic analysis attacks, the
group keys can be used with IPsec to encrypt the packets sent to the
group, in addition to doing packet authentication. However, it must
be recognized that this is not a general solution for data privacy.
In particular, the group keys can easily be passed from a valid
receiver to an unauthorized receiver, to enable piracy of pay-per-
use services. This is reasonable, as data privacy is not considered
part of the scope of TRACK protocols.
(d) Multicast IPsec. Although currently IPsec is generally implemented
for pair-wise (one-to-one) communications between one sender and one
receiver, the design of IPsec itself allows for usage in IP
multicast. Currently the Security Association (SA) definition
requires the Security Parameter Index (SPI) to be selected by the
receiver [KA98a]. However, since in IP multicast a group address
may be associated with multiple receivers, the existing method of
selecting the SPI must be re-interpreted. Hence, in the context of
"Multicast IPsec", a pre-defined entity (e.g. the source, or the key
server/manager) must first create the Group-SA (including selecting
the SPI) and deliver the Group-SA to all the members of the group
(by either the "push" or "pull" paradigm). Thus rather than being a
modification to the IPsec specification, this requirement simply
means that additional protocols are needed to establish a shared
Group-SA. One possible approach for the Group Key Management (GKM)
protocol is to also deliver the Group-SA (and other keying material)
to the receiver at the same time it delivers the GroupDataKey
[HCM98].
7. Summary
In summary, in the current work we have proposed for TRACK protocols the
separation of data stream confidentiality using a symmetric key (i.e.
implicit group-authentication) from data authentication using a
symmetric key (i.e. explicit group-authentication). Data stream
confidentiality using a symmetric key will be conducted at the
application layer, while data authentication using a symmetric key will
be conducted at the network layer. Since the DRs/TN may be (optionally)
prevented from reading the multicast data, two (2) different symmetric
keys must be deployed corresponding to the needs of data stream
confidentiality and data group-authentication.
This proposal follows a number of requirements, some of which are
specific to TRACK protocols. The use of group-authentication at the
network layer is:
- for protection of the transport and IP headers.
- to allow a DR to authentically retransmit lost packets to
a destination address (unicast or local multicast) different
from the original multicast group address.
- to allow a separate symmetric key encryption to be applied
(at the application layer) in order prevent the DRs/TN from
reading the data.
We assume encryption for confidentiality (using the GroupDataKey) has
been applied above the transport layer by the sender/source, in order to
prevent a DR/TN from decrypting the data. The GroupDataKey is only
available to the group members, excluding the interior control nodes.
We propose the use of another key (GroupAuthKey) to provide group-
authentication from the source/sender at the network layer using
symmetric key cryptography. The GroupAuthKey is known by the members of
the group, as well as the interior control nodes.
For the retransmission of lost packets to regions within a group, either
via unicast or local multicast, we propose the use of a SubgroupAuthKey
(instead of the GroupAuthKey) which is known only to entities within a
region (DR and its children). The SubgroupAuthKey is also used by the
entities in a region to group-authenticate control messages that are
exchanged with each other.
8. References
[HCM98] T. Hardjono, B. Cain and I. Monga, "Intra-Domain Group Key
Management Protocol", work in progress, draft-ietf-ipsec-intragkm-
00.txt, Nov 1998.
[HH99a] H. Harney and E. Harder, "Group Security Association Key
Management Protocol", work in progress, draft-harney-sparta-gsakmp-sec-
00.txt, May 1999.
[KCWP00] M. Kadansky, D. Chiu, J. Wesley, J. Provino. "Tree-based
Reliable Multicast (TRAM)", work in progress, draft-kadansky-tram-
02.txt, January 2000.
[KA98a] S. Kent and R. Atkinson, "Security Architecture for the Internet
Protocol", IETF, RFC 1825, 1998.
[KA98b] S. Kent and R. Atkinson, "IP Authentication Header", work in
progress, Internet Draft, July 1998.
[MG98a] C. Madson, R. Glenn, "The Use of HMAC-MD5-96 within ESP and AH",
work in progress, draft-ietf-ipsec-auth-hmac-md5-96-03.txt, Feb 1998
[MG98b] C. Madson, R Glenn, The Use of HMAC-SHA-1-96 within ESP and AH",
work in progress, "draft-ietf-ipsec-auth-hmac-sha1-96-03.txt, Feb, 1998.
[R92] R. Rivest, "MD5 Digest Algorithm", RFC1321, April 1992.
[RSA93] RSA Laboratories, "PKCS#1: RSA Encryption Standard", Volume1.5,
No. 1993.
[WBPM98] B. Whetten, M. Basavaiah, S. Paul, T. Montgomery, "RMTP-II
Specification". Work in progress, draft-whetten-rmtp-ii-00.txt, April
8, 1998.
--=====================_286204430==_.ALT
Content-Type: text/html; charset="us-ascii"
<html>
Someone reported that the file was corrupted, so it is attached
below.<br>
Sorry to add to everyone's mailbox!<br>
Brian<br>
<br>
<br>
<font face="Courier New, Courier">Internet Engineering Task
Force
T. Hardjono<br>
INTERNET-DRAFT
Nortel Networks<br>
draft-ietf-rmt-track-security-00.txt
B. Whetten<br>
January 12,
2000
Talarian<br>
<br>
<br>
<br>
<br>
Security Requirements For TRACK Protocols<br>
<br>
<draft-ietf-rmt-track-security-00.txt><br>
<br>
<br>
Status of this Memo<br>
<br>
This document is an Internet-Draft and is in full
conformance<br>
with all provisions of Section 10 of RFC2026.<br>
<br>
Internet-Drafts are working documents of the Internet
Engineering<br>
Task Force (IETF), its areas, and its working groups.
Note that<br>
other groups may also distribute working documents as<br>
Internet-Drafts.<br>
<br>
Internet-Drafts are draft documents valid for a maximum of
six<br>
months and may be updated, replaced, or obsoleted by
other<br>
documents at any time. It is inappropriate to use
Internet-<br>
Drafts as reference material or to cite them other than
as<br>
"work in progress."<br>
<br>
The list of current Internet-Drafts can be accessed at<br>
<a href="http://www.ietf.org/ietf/1id-abstracts.txt" eudora="autourl">http://www.ietf.org/ietf/1id-abstracts.txt</a><br>
The list of Internet-Draft Shadow Directories can be
accessed at<br>
<a href="http://www.ietf.org/shadow.html" eudora="autourl">http://www.ietf.org/shadow.html</a>.<br>
<br>
<br>
Abstract<br>
<br>
This document discusses the security issues within TRee-based <br>
ACKnowledgement (TRACK) reliable multicast protocols, and identifies
<br>
some constraints and requirements for security provisions for these
<br>
protocols. Based on the constraints and requirements, the document
<br>
proposes a separation of data packet confidentiality and authentication,
<br>
from transport layer protection. It proposes that TRACK protocols
be <br>
primarily concerned with group authentication of control and data <br>
packets, to protect against attacks on the transport
infrastructure. It <br>
proposes that data confidentiality and source authentication be provided
<br>
separately from this low level group authentication, ideally at the
<br>
application level. We show that this is particularly important for
<br>
TRACK protocols, because of the requirement that the interior control
<br>
nodes only optionally have access to the data packet payload.<br>
<br>
Specifically, the current work proposes that data and control packet
<br>
authentication be provided using IPsec-based authentication at the <br>
network layer. This approach allows an interior control node to
<br>
authentically retransmit a lost data packet (which remains encrypted
<br>
under the separate data-encryption key) to its own children (a set of
<br>
Receivers), while making use of the IPsec features, such as protection
<br>
against replay attacks. <br>
<br>
This document then provides a specific proposal for how group keys <br>
should be divided up among group members, for control and data packet
<br>
authentication. While providing some rationale for divorcing this
<br>
proposal from that of source authentication and data confidentiality, it
<br>
does not provide a specific proposal for those pieces.<br>
<br>
<br>
1. Background: The Multicast Security Problem<br>
<br>
The problem of multicast security can be divided into three general
<br>
areas of concern:<br>
- Data Encryption and Source Authentication. The method used to
<br>
encipher or scramble the multicast data, and verify the identity of
<br>
the sender of this data.<br>
- Key Distribution. The method used to securely distribute group
<br>
keys and keying material to the members of a group, for use in <br>
decrypting or authenticating the data or control packets.<br>
- Infrastructure protection. Mechanisms used to protect the <br>
multicast infrastructure itself, and to minimize the ability of an <br>
intruder to deny service to legitimate users.<br>
<br>
The security of reliable multicast protocols falls primarily into the
<br>
third category of problems. Complete denial of service protection
must <br>
start at the network level (i.e. IP Multicast), with controls placed on
<br>
senders from overloading the network with brute force
"spamming", as <br>
well as with authentication of control packets, to keep users from <br>
corrupting the state of the IP Multicast protocols. A transport
<br>
protocol needs to address the same issues, checking to make sure that
<br>
senders are not sending more data than they are allowed (such as with
<br>
enforceable congestion control), and authenticating control packets, to
<br>
protect the protocol state. Control packet authentication is <br>
particularly important in TRACK protocols, because of their use of <br>
interior control nodes (for example, in RMTP-II, DRs and TNs) to <br>
increase scalability.<br>
<br>
An optional extension to the requirement of infrastructure protection is
<br>
that of infrastructure privacy. Some applications require that the
<br>
headers of the network packets be encrypted, to provide protection from
<br>
network analysis attacks.<br>
<br>
<br>
2. Independence of RM Security<br>
<br>
The security of reliable multicast (RM) protocols is part of the larger
<br>
problem of the security of the multicast infrastructure, which also
<br>
consists of the security of the multicast routing protocols.<br>
<br>
Since RM protocols and multicast routing protocols exist at different
<br>
layers in the protocol stack, and since different RM protocols may be
<br>
employed with different multicast routing protocols, it is useful from a
<br>
security perspective to treat these two security problems
separately. <br>
In addition, although in many instances the topology of RM <br>
infrastructure may coincide with that of the multicast routing protocol,
<br>
such symmetry cannot be assumed for all cases.<br>
<br>
Similarly, from a design perspective, the problem of securing the data
<br>
stream (e.g. through content encryption) should be separated from the
<br>
issue of securing reliable multicast protocols.<br>
<br>
Although we treat RM-security as an independent problem from other <br>
multicast security problems, this does not preclude using the solutions
<br>
in other areas in order to solve the security needs of RM. For example,
<br>
the use of IPsec technology at the IP layer to authenticate multicast
<br>
routing protocol control-packets can also be used to authenticate RM
<br>
control-messages. However, the instance of deploying IPsec in both
<br>
cases must be distinguished and treated separately.<br>
<br>
<br>
3. RMTP-II Overview<br>
<br>
While not necessarily typical of all TRACK protocols (such as TRAM <br>
[KCWP00]), we use the RMTP-II protocol as an example for analysis and
<br>
discussion. The RMTP-II protocol features a number of entities
which <br>
participate in a logical tree or hierarchy and which exchange
control-<br>
messages with each other. The entities are the Top Node (TN), the
<br>
Sender Nodes (SD), the Designated Receiver Nodes (DR) and the Receiver
<br>
Nodes (RN). <br>
<br>
RMTP-II places receivers into local regions, where each region is <br>
assigned to a DR. These groups are arranged hierarchically as a
tree <br>
rooted at the TN, with the DRs representing the nodes of the tree, and
<br>
the receivers as the leaves. The senders connect directly to the
top <br>
node, at the top layer of the hierarchy. The receivers send their
<br>
control-messages (ACKs, NACKs, etc.) to the DR of their region.
<br>
Retransmission of lost packets may be done locally by the DR of a <br>
domain, or globally from the sender. Each DR sends their control
<br>
messages to the DR at the next level up the hierarchy. This process
is <br>
repeated until the TN, who then forwards the control messages to the
<br>
appropriate sender. The DRs and TN aggregate the positive <br>
acknowledgements from the receivers, and suppress the redundant negative
<br>
acknowledgements, in order to solve the ACK/NACK implosion problem.<br>
<br>
A DR maintains a local multicast group to just its children, and <br>
subscribes to the local multicast group of its parent. A DR uses
this <br>
local multicast group for retransmissions to its children. While
RMTP-<br>
II uses multicast for retransmission from a DR, other TRACK protocols
<br>
may choose to optionally use unicast.<br>
<br>
RMTP-II distinguishes between a data channel and a control channel.
A <br>
data channel is a global multicast group created using the underlying
<br>
multicast routing protocol. A control channel is the interconnected
<br>
topology of control nodes, for handling error recovery and positive
<br>
packet acknowledgements.<br>
<br>
In order to obtain data packets from the Sender, a Receiver in a given
<br>
RMTP-II region must join the multicast group (i.e. the data
channel). <br>
The DR of that region must join every multicast group that its <br>
descendants have joined. Note that the DRs are not responsible for
<br>
forwarding the data packets multicast by the Sender, since that data
<br>
stream is propagated by the underlying multicast routing protocol.<br>
<br>
The figure below illustrates an RMTP-II tree with multiple control <br>
nodes.<br>
<br>
HACKs<br>
-----------> (Top Node)----------------->(Sender node)<br>
^
^^^
|<br>
|
/ |
\
|<br>
HACKs
|
/ |
\
|<br>
|
/ |
\
|<br>
|
/
| \
(Designated |<br>
/
|
\ Receiver |<br>
/
|
\ node)
v<br>
Control D
R D
R D R
<------------|<br>
Channel
^^
^^^
^^
| Data<br>
/ | / |
\ |
\
| Channel<br>
/ | /
| \ |
\
|<br>
/ |
/ |
\ |
\
v<br>
RN RN RN
RN RN
RN RN <------<br>
(Receiver Nodes)<br>
<br>
<br>
<br>
4. TRACK Protocol Security Issues and Requirements<br>
<br>
This section details the security requirements for TRACK protocols which
<br>
are similar to RMTP-II. These requirements include general
multicast <br>
transport requirements, as well as some requirements specific to TRACK
<br>
protocols.<br>
<br>
4.1 Background<br>
<br>
In addressing the security issues specific to TRACK protocols, it is
<br>
useful to consider the general aspects of security relating to reliable
<br>
multicast.<br>
<br>
- Layer in which security is applied:<br>
The two layers in which security mechanisms are deployed are <br>
typically the network layer and the application layer. In the
<br>
network layer the protocol that is the most commonly used is the <br>
IPsec protocol, which provides authentication and/or encryption. In
<br>
either case, with IPsec the transport headers (and IP headers) are <br>
protected. When authentication and/or encryption is applied at the
<br>
application layer, neither the transport headers nor the IP headers
<br>
are protected.<br>
<br>
- Types of authentication:<br>
- Source-authentication: If public key (asymmetric) cryptography
is <br>
deployed, where only the sender knows the secret-half of the <br>
public key pair, then unique "source-authentication" can be
<br>
established.<br>
- Group-authentication: If shared key (symmetric) cryptography is
<br>
deployed and the key is shared by more than two parties, then <br>
only "group-authentication" can be established. This means that
a <br>
receiver in a group is only certain that the entity that sent the <br>
message is in possession of the symmetric-key, and is thus <br>
assumed to be a member of the group sharing the key.<br>
<br>
In the following, the TRACK specific requirements are further <br>
elaborated.<br>
<br>
<br>
4.2 Authentication of Control-Messages<br>
<br>
As stated above, the directly relevant security concern for TRACK <br>
protocols is protection of the multicast infrastructure, particularly of
<br>
the control tree, in order to provide protection against replay or other
<br>
attacks which seek to corrupt the state of the transport protocol.
The <br>
authentication of control messages exchanged among TRACK protocol <br>
entities represents the minimal security mechanisms necessary to do
so.<br>
<br>
Two types of authentication mechanisms can be adopted, corresponding to
<br>
the two basic types of cryptosystems. In the context of reliable
<br>
multicast, throughput and latency is typically of high importance, and
<br>
group-authentication based on symmetric cryptography appears to be <br>
preferable. <br>
<br>
Given this, the efficiencies of symmetric key based authentication <br>
appear to outweigh the benefits of public key based authentication.
<br>
There are potentially cryptographic schemes that can provide the unique
<br>
source-authentication of public key cryptography while providing the
<br>
performance characteristics of symmetric key based authentication (e.g.
<br>
efficient digital signing of the hash-value of several data
packets). <br>
However, at the present time, for the general case of infrastructure
<br>
protection, the complexities of these options appear to outweigh the
<br>
benefits.<br>
<br>
Thus, in summary, for TRACK protocol control-messages, explicit
group-<br>
authentication at the IP layer should be deployed using symmetric <br>
cryptography. Although a number of technologies are available, we
<br>
propose specifically IPsec-based authentication using a keyed-hash <br>
function [KA98b,MG98a,MG98b] due to its growing use and
availability.<br>
<br>
We denote the symmetric key used for control message authentication as
<br>
the InteriorNodeKey. The InteriorNodeKey is a symmetric key shared by
<br>
all DRs and the TN within a given RMTP-II or TRACK hierarchy. The
key <br>
is independent of any data stream, and is used to authenticate control
<br>
packets exchanged among the DRs/TN. <br>
<br>
<br>
4.3 Non-Decipherability of Data Packets by DRs<br>
<br>
RMTP-II requires that a Designated Receiver Node (DR) join all of the
<br>
multicast groups that its descendants have joined. This is also
true of <br>
the Top Node (TN).<br>
<br>
For TRACK protocols it is preferable that authentication methods based
<br>
on a symmetric key be deployed due to performance reasons. This may
be <br>
achieved explicitly, such as by using a keyed hash function, or <br>
implicitly using encryption (where a successful decryption implies the
<br>
ciphertext is both unmodified in transit and was generated by a holder
<br>
of the symmetric key).<br>
<br>
However, TRACK protocols have a further requirement, namely that their
<br>
repair nodes (i.e. DR and TN) be (optionally) prevented from reading the
<br>
multicast data. More specifically, we perceive that DRs may be <br>
administered as part of a reliability service offered by third parties
<br>
such as ISPs. These third parties may refuse the ability to
decipher <br>
data packets in order to avoid the legal ramifications of having access
<br>
to the data contents. Thus, from the ISP perspective, TRACK
protocols <br>
must allow them to prove to the content-owner that they do not posses
<br>
the means to alter the contents transmitted through the multicast <br>
groups.<br>
<br>
Given the above requirement of the DRs/TN and the need for fast <br>
authentication, we propose:<br>
<br>
- the separation of data stream confidentiality using either a symmetric
<br>
or asymmetric key from data authentication using a symmetric key (i.e.
<br>
explicit group-authentication).<br>
<br>
- data stream confidentiality will be conducted at the application <br>
layer, while data authentication using a symmetric key will be <br>
conducted at the network layer.<br>
<br>
- since the DRs/TN may be (optionally) prevented from reading the <br>
multicast data, two (2) different keys must be deployed corresponding
<br>
to the needs of data stream confidentiality and data group-<br>
authentication.<br>
<br>
<br>
4.4 Authentication of Data Retransmissions<br>
<br>
In TRACK protocols, retransmissions of data packets may come from the
<br>
original source, or from a different (DR) node. This local recovery
is <br>
an important tool for increasing the scalability and latency of a <br>
protocol. In the context of security, it raises the question as to
what <br>
authentication methods should be used on these packets.<br>
<br>
(a) If source authentication (using public key cryptography) and data
<br>
confidentiality (including implicit group authentication) is <br>
applied at the application layer, the DR can simply replay the data
<br>
(i.e. payload) unmodified to the querying receivers, either via <br>
unicast or local multicast.<br>
<br>
(b) If, however, explicit group authentication (using a symmetric key)
<br>
was applied at the network layer (e.g. using IPsec), then the DR <br>
cannot simply replay the packet due to restrictions at the IP <br>
layer. Thus, in this case the DR must re-apply the group-<br>
authentication.<br>
<br>
Taking case (b) further, there are two options corresponding to <br>
whether retransmission by the DR is performed via unicast to a <br>
receiver or via multicast.<br>
<br>
(i) If the retransmission is unicast to a given receiver, then it <br>
is preferred if the DR and the receiver share a separate <br>
symmetric key for this purpose.<br>
<br>
(ii) If the retransmission is via multicast to a subgroup (as is <br>
the case in RMTP-II), then the DR can either use the existing <br>
group-shared symmetric key or use a separate symmetric key only <br>
for the subgroup under the DR. We propose to use the later <br>
approach, which means that a DR and its children (receivers) <br>
must share a separate symmetric key for explicit group <br>
authentication at the IP layer.<br>
<br>
<br>
4.5 Keys for Data Confidentiality and for Authentication<br>
<br>
As mentioned above, we propose the separation of data stream <br>
confidentiality using a symmetric key encryption (effecting an implicit
<br>
group-authentication) from data authentication using a symmetric key and
<br>
a keyed hash function (i.e. explicit group-authentication).<br>
<br>
We now denote the symmetric key for data stream confidentiality at the
<br>
application layer as the GroupDataKey. Only the source and valid <br>
receivers will have a copy of the GroupDataKey, which is delivered to
<br>
them through the appropriate Group Key Management (GKM) protocol that
<br>
identifies and verifies the members individually. In the case where
the <br>
DRs and the TN are not permitted to read the multicast data, they must
<br>
be prevented by the GKM protocol from obtaining the GroupDataKey.<br>
<br>
We denote the symmetric key for explicit group-authentication at the
<br>
network layer as the GroupAuthKey. The GroupAuthKey is distinct from the
<br>
GroupDataKey. For TRACK protocols, we propose the use of IPsec with
<br>
keyed hashing at the network layer to provide explicit group-<br>
authentication using the GroupAuthKey. Unlike the GroupDataKey, the
<br>
GroupAuthKey is known by all entities involved in the multicast.
This <br>
includes all interior node entities (e.g. TN, DR), the Sender/Source and
<br>
the Receivers.<br>
<br>
<br>
4.6 Authenticity of NACK and other Control Packets<br>
<br>
In TRACK protocols, a DR responds to a NACK from one its children <br>
(typically a receiver) by re-transmitting the lost packet via local
<br>
multicast. This basic behavior can be open to abuse by an attacker
who <br>
injects spurious NACK messages towards the DR, effecting a local <br>
multicast to all children of the DR. In itself this is a waste of
<br>
bandwidth and may result in a denial of resource to the group
members. <br>
Other control packets directly impact the state of the group, such as
<br>
the group membership, and could also be used in denial of service <br>
attacks.<br>
<br>
To counter these types of attack, the control messages themselves must
<br>
be authenticated by the DR. Digital signatures using public key
<br>
cryptography could be applied to the control messages. However,
this <br>
approach would be inefficient due to the high CPU cost of public key
<br>
encryption. Also, it would require creating a separate security
<br>
association with each child of the DR.<br>
<br>
Instead, we propose that NACK and other control messages from a child
<br>
(receiver) to its DR be protected using symmetric IPsec based <br>
authentication. This requires the two parties to first establish a
<br>
Security Association (SA) and a shared symmetric key. The symmetric
key <br>
can be unique per child, or be uniform over a subgroup of receivers
<br>
(i.e. those under the DR).<br>
<br>
<br>
4.7 Fault Recovery<br>
<br>
In RMTP-II, if a child's connection to a DR or TN fails, RMTP-II <br>
provides automatic mechanisms for failing-over to another DR or backup
<br>
TN. This reconnection needs to happen quickly, so that the child
can <br>
rejoin the data stream before too much data has been missed to recover
<br>
from. If a child needs to get a new key for that DR/TN, this can be
a <br>
bottleneck. Given that the key distribution infrastructure may be
<br>
centralized, and a majority of receivers may need to fail over at the
<br>
same time, this presents a major opportunity for network
congestion.<br>
<br>
The RMTP-II entities are given the address of their backup control node
<br>
at startup time. While these addresses can change, they are
expected to <br>
always have the addresses of one or more backup nodes. When <br>
implementing security features, each child should be required to keep
<br>
the key for its primary backup DR/TN. Optionally, it may need to
keep <br>
the keys for each of the backup control nodes it is using.<br>
<br>
<br>
4.8 Implementation with Different Levels of OS Protection<br>
<br>
A TRACK protocol can be implemented in (at least) one of three
ways.<br>
- Application level. Most implementations of TRACK protocols for
the <br>
near future are expected to operate in the application level of the
<br>
OS, running on top of UDP. <br>
- Kernel. As TRACK protocols become bundled with standard operating
<br>
systems, it is expected to become a kernel module, and run directly
<br>
over IP.<br>
- Virtual machine. Some TRACK entities (particularly senders and
<br>
receivers) will be run in virtual machines, such as when implemented
<br>
as a Java applet.<br>
<br>
TRACK protocol security must accommodate all three of these
options. <br>
This raises the following issues.<br>
- Application Level. One advantage of application level <br>
implementations is their flexibility. These implementations could
<br>
use either IPsec routines, the application layer security functions,
<br>
or both.<br>
- Virtual Machines. There are issues trying to use IPsec with
<br>
virtual machines such as Java, which have to date hindered the <br>
support of IPsec through native Java applets. This makes it <br>
important for a TRACK protocol to optionally be able to use only <br>
application level security.<br>
- Kernel Implementations. As a TRACK protocol becomes bundled with
<br>
operating systems, it is expected that IPsec will also become bundled
<br>
with the OS. To avoid having to use less trusted software in the
<br>
application level, the TRACK protocol will have to be able to use a
<br>
kernel level security system (such as IPsec) for its transport level
<br>
security needs.<br>
<br>
<br>
4.9 Separate Regional Protection<br>
<br>
TRACK protocols are expected to be used for content distribution from a
<br>
few senders to many receivers. In the case of applications that
<br>
distribute critical data to many different organizations, it is not
<br>
enough to trust all receivers. For example, a market data feed
provider <br>
could be using a TRACK protocol to distribute live market data feeds to
<br>
competing financial institutions. In this situation, the data feed
<br>
provider needs to be able to protect individual companies from corrupted
<br>
control packets from other customers (which could be generated either
<br>
intentionally, or more likely, unintentionally) which would cause denial
<br>
of service.<br>
<br>
As we propose in the next section, a TRACK protocol must provide <br>
separate regional keys for the group-authentication of control packets
<br>
sent from the receivers of different DRs. This allows the <br>
authentication of control-messages for each set of receivers (part of
<br>
one customer) to be done separately (from another set of receivers, as
<br>
part of different customer). Since for each set of receivers a different
<br>
key is used, this limits the ability of a customer to perpetrate denial
<br>
of service attacks against other customers. <br>
<br>
<br>
4.10 Piracy of Pay-Per-Use Data<br>
<br>
A common scenario for TRACK protocols involves pay-per-use data <br>
distribution, such as live market data, pay-per-view video signals, or
<br>
paid subscriptions to software updates. In this scenario, a
receiver <br>
cannot be trusted to not give its group keys to outside entities, who
<br>
are trying to get free service. We mention this requirement since
it is <br>
different than point-to-point security. However, this requirement
is <br>
the responsibility of the application level security.<br>
<br>
<br>
<br>
5. Architecture Recommendations<br>
<br>
The previous section detailed some of the specific requirements and
<br>
issues for TRACK protocol security, along with some individual <br>
recommendation on handling each one. Given those requirements, we
<br>
propose the following architecture recommendations for implementing
<br>
security with TRACK protocols. <br>
<br>
<br>
5.1 Separation of Security Responsibilities<br>
<br>
As detailed above, TRACK protocols are primarily concerned with <br>
protection of the network infrastructure, rather than with issues such
<br>
as data confidentiality and source-authentication. Therefore, we
<br>
recommend that TRACK protocols SHOULD provide:<br>
(a) group authentication of control packets, and<br>
(b) optional group authentication of data packets<br>
Optionally, TRACK protocols MAY choose to provide:<br>
(c) optional privacy of data and of control packet
headers. <br>
To accomplish this, we recommend that TRACK protocols use IPsec <br>
technology at the network layer, while letting application level <br>
security perform additional functions as needed. For
implementations <br>
that do not have access to IPsec, and are not implemented as part of the
<br>
OS, application level security can be used instead--although this of
<br>
course risks incompatibility with other implementations.<br>
<br>
The separation of group-authentication of data from both data
source-<br>
authentication and data-confidentiality is tightly coupled to the choice
<br>
of recommending IPsec for the group authentication. These two
choices <br>
are motivated by the following:<br>
<br>
(a) Non-Decipherability of data by interior control nodes: it is a <br>
requirement of TRACK protocols that in some deployments, its control
<br>
entities (e.g. TN, DR) be unable to decipher the data packet. Thus,
<br>
the GroupDataKey for data encryption and GroupAuthKey for group-<br>
authentication must be distinct. It is not sufficient to simply use
<br>
an identical key (for the GroupDataKey and GroupAuthKey) and to <br>
instruct the TRACK protocol entities to avoid deciphering the data <br>
packets. It must be provably shown that the interior control nodes
<br>
do not have the ability to decipher the data packets (even if they <br>
wish to do so).<br>
<br>
(b) Use of IPsec technologies: considerable effort has been invested in
<br>
developing the IPsec architecture and protocols [KA98a, KA98b], and
<br>
a growing number of vendors are supporting IPsec. The IPsec suite
<br>
offers a number of features, including some protection against <br>
replay attacks.<br>
<br>
(c) Multicast IPsec: the IPsec architecture has intentionally allowed
<br>
the use of IPsec for IP multicast without changes to the basic <br>
constructs within the IPsec suite. Currently, work is proceeding
<br>
towards the establishment of a standard mechanism to select the <br>
Group Security Association (Group SA or GSA) for multicast and a <br>
method to disseminate the GSA to the valid members of the group <br>
[HCM98,HH99a].<br>
<br>
(d) Appropriate Level: since the primary purpose of transport level
<br>
security is to secure the infrastructure at a transport level, using
<br>
a network or transport level security protocol allows each to be <br>
implemented together--either in the OS, or in the application
layer.<br>
<br>
<br>
5.2 Division of Responsibilities<br>
<br>
Given this fundamental division between application and transport <br>
responsibilities, we divide the security responsibilities in to four
<br>
parts.<br>
<br>
Network Responsibilities (IP and IP Multicast)<br>
----------------------------------------------<br>
<br>
- Admission controls on senders--to protect against "brute <br>
force" spamming attacks.<br>
- Authentication of routing control packets--to protect <br>
the routing infrastructure from denial of service attacks.<br>
<br>
Transport Responsibilities (TRACK Protocols)<br>
------------------------------------<br>
- Protection of the control messages from replay attacks<br>
and other denial-of-service attacks.<br>
- Optional: protection of data packets from replay attacks.<br>
- Optional: encryption of control messages to minimize<br>
network analysis by attackers.<br>
<br>
End to End Responsibilities (Application)<br>
-----------------------------------------<br>
- Source authentication--to verify the authenticity of data,<br>
and provide optional non-repudiation of data.<br>
- Data encryption--to provide data confidentiality.<br>
<br>
Key Management Infrastructure<br>
-------------------------------<br>
- Distribution of transport and network layer keys: authentication<br>
of individual hosts, and distribution of keys to those hosts<br>
- Application level key distribution: authentication of<br>
individual processes, and distribution of keys to those
processes<br>
- Optional: periodic rekeying--group keys periodically need<br>
to be changed, both after a certain time limit has expired,<br>
and/or after the group membership changes.<br>
<br>
The figure below shows how these components relate to each other.
TRACK <br>
protocols can be used without any additional security at the IP/IP <br>
Multicast level, although this will not provide full protection from
<br>
denial of service attacks. TRACK protocols will be able to be used
on <br>
top of UDP or raw IP/IP Multicast. A TRACK protocol can use either
<br>
IPsec or application level security for its network security <br>
requirements, although we recommend using IPsec wherever possible.<br>
+--------------------+
+----------+<br>
+--------------+<----->|
Application |<----->| App Sec |<br>
|
| +--------------------+
|==>| |<br>
|
|
|
TRACK |<--|
+----------+<br>
| Key
|<----->+
+---------+
|-->| |<br>
| Management |
| |
UDP | |
IPsec |<br>
|
|
+--------------------+
| |<br>
|
|<=====>| IP, IP Multicast
|<=====>|
|<br>
+--------------+
+--------------------+
+----------|<br>
<br>
<===> Optional<br>
<br>
<br>
When a data packet is to be sent to the multicast group, the <br>
Sender/Source first (optionally) enciphers the data packet using the
<br>
GroupDataKey above the RM/transport layer. It is then passed to the
<br>
RM/transport layer, which attaches the necessary RM headers. The
result <br>
is then passed down to the IP layer where IPsec authentication is <br>
established (using the GroupAuthKey).<br>
<br>
A Receiver in the multicast group would be in possession of both the
<br>
GroupDataKey and the GroupAuthKey, and thus will be able to first <br>
authenticate the data packet using the GroupAuthKey, and then continue
<br>
to decipher the data packet using the GroupDataKey.<br>
<br>
A Designated Receiver Node (DR) will possess the GroupAuthKey (but not
<br>
the GroupDataKey), and thus will only be able to authenticate the packet
<br>
using the GroupAuthKey using IPsec. After verifying the
authenticity of <br>
a received data packet, a DR will be able to retransmit the (enciphered)
<br>
data packet to its children, either via unicast or region-based local
<br>
multicast. A retransmission of a lost data packet from a DR will be
<br>
authenticated using a SubgroupAuthKey (see below) which is a symmetric
<br>
key shared by a DR and all its children Receivers only.<br>
<br>
Again, although the current work proposes the use of unicast IPsec and
<br>
multicast IPsec at the network layer, it does not preclude the use of
<br>
other authentication technologies at the network layer or at the <br>
RM/transport layer. Such technologies, however, will have to
address <br>
much of the same issues faced by IPsec, including prevention of replays,
<br>
the creation and maintenance of state (i.e. "Security
Associations") <br>
associated with the GroupAuthKey, the Sender and Receiver(s), and other
<br>
features and supporting mechanisms. It is precisely the growing
<br>
availability of IPsec that motivates the current work to choose IPsec
<br>
for network layer authentication for both data and control packets.<br>
<br>
<br>
5.3 TRACK Keys<br>
<br>
In general, each node in the hierarchy must be able to authenticate
<br>
itself to the key management entity/server, before it will be allowed to
<br>
receive any of the below keys. We assume the implementation of a
key <br>
management infrastructure, which interfaces with the DRs and TNs, as
<br>
well as the senders and receivers. <br>
<br>
We propose that this key management system be responsible for <br>
distributing the following TRACK protocol keys:<br>
<br>
- GroupDataKey: <br>
The GroupDataKey is the unique symmetric key for data encryption <br>
shared by all members of a multicast group, excluding the interior <br>
tree entities. Typically, one GroupDataKey is associated with one
<br>
multicast group. The GroupDataKey is used to provide access control
<br>
to the data packet by way of the Sender/Source enciphering the data
<br>
packet. Since only the Receivers hold the copy of the GroupDataKey,
<br>
only the Receivers will be able to decipher the data packets. This
<br>
is an optional key, which does not directly concern the TRACK <br>
transport.<br>
<br>
- GroupAuthKey: <br>
The GroupAuthKey is the unique symmetric key shared by all members <br>
of a multicast group, including the interior control nodes. One
<br>
GroupAuthKey is associated with one multicast group. The purpose of
<br>
the GroupAuthKey is to provide authentication of the (possibly <br>
enciphered) data packets. In the context of IPsec authentication,
<br>
this can be achieved using a keyed hash function, such as HMAC-MD5-<br>
96 [MG98a] and HMAC-SHA-1-96 [MG98b].<br>
<br>
- SubgroupAuthKey: <br>
The SubgroupAuthKey is the unique symmetric key shared only by <br>
entities within a given local region, consisting of a DR and its <br>
children (consisting of one or more Receivers, and possibly one <br>
child DR). The SubgroupAuthKey is used by the parent in a local <br>
region to provide group-authentication for the (lost) data packets <br>
(still enciphered under the GroupDataKey) which are retransmitted to
<br>
the Receivers in the region, either via unicast or via subtree-<br>
multicast. The SubgroupAuthKey is also used by the entities in a
<br>
region to group-authenticate control messages that are exchanged <br>
with each other. Similar to the GroupAuthKey, we propose the use of
<br>
IPsec based authentication via keyed hash function.<br>
<br>
Note that for region-based retransmission of lost packets and for <br>
control-packet authentication, the SubgroupAuthKey is used instead <br>
of the GroupAuthKey (not both).<br>
<br>
Note that if a DR happens to be a child within a region and at the <br>
same time a parent within its own region, then that DR will hold two
<br>
distinct SubgroupAuthKeys corresponding to the two regions.<br>
<br>
In the future, RMTP-II hopes to take advantage of subtree-multicast,
<br>
where a packet can be sent to a constrained piece of the multicast <br>
tree. Ideally, a subtree-multicast only goes to the pieces of the
<br>
tree that have lost a packet. In this case, additional region keys
<br>
would have to be distributed, that spanned multiple levels of the <br>
hierarchy. We will leave this consideration for a future time,
<br>
however, since subtree-multicast does not yet exist in a deployable
<br>
form.<br>
<br>
- InteriorNodeKey: <br>
The InteriorNodeKey is a symmetric key shared by all interior <br>
control nodes within a given TRACK hierarchy. The key is <br>
independent of any data stream, and is used to authenticate control
<br>
packets exchanged among the DRs/TN. Should a child-DR request a
<br>
retransmission of a lost data packet from its parent-DR, then the <br>
parent-DR will deliver the (encrypted) lost packet to the child-DR,
<br>
authenticated using the InteriorNodeKey.<br>
<br>
Before the child-DR retransmits this lost data packet to its own <br>
region, it must first authenticate the packet from the parent-DR <br>
using the InteriorNodeKey. It must then use its own SubgroupAuthKey
<br>
of the region headed/parented by that child-DR to provide <br>
authentication for the retransmitted data packet. <br>
<br>
<br>
6. Limitations<br>
<br>
The proposed security architecture has certain limitations. These
<br>
include:<br>
<br>
(a) Brute Force Attacks. At the transport level, no admission
controls <br>
can be put in place to throttle a sender which is generating lots of
<br>
spurious packets to a multicast address. This is the requirement of
<br>
the network level. At the present time, no accepted standard exists
<br>
for doing so at the IP Multicast level.<br>
<br>
(b) Key Corruption. The recommended group key architecture makes a
<br>
careful tradeoff between the need to distribute many keys, and the <br>
need to localize the effects of a node which is compromised. This <br>
proposal allows a local receiver to perpetrate denial of service <br>
attacks to its local DR, and the receivers served by that DR.<br>
<br>
(c) Privacy. In order to prevent network traffic analysis attacks,
the <br>
group keys can be used with IPsec to encrypt the packets sent to the
<br>
group, in addition to doing packet authentication. However, it must
<br>
be recognized that this is not a general solution for data privacy.
<br>
In particular, the group keys can easily be passed from a valid <br>
receiver to an unauthorized receiver, to enable piracy of pay-per-<br>
use services. This is reasonable, as data privacy is not considered
<br>
part of the scope of TRACK protocols.<br>
<br>
(d) Multicast IPsec. Although currently IPsec is generally
implemented <br>
for pair-wise (one-to-one) communications between one sender and one
<br>
receiver, the design of IPsec itself allows for usage in IP <br>
multicast. Currently the Security Association (SA) definition
<br>
requires the Security Parameter Index (SPI) to be selected by the <br>
receiver [KA98a]. However, since in IP multicast a group address
<br>
may be associated with multiple receivers, the existing method of <br>
selecting the SPI must be re-interpreted. Hence, in the context of
<br>
"Multicast IPsec", a pre-defined entity (e.g. the source, or
the key <br>
server/manager) must first create the Group-SA (including selecting
<br>
the SPI) and deliver the Group-SA to all the members of the group <br>
(by either the "push" or "pull" paradigm). Thus
rather than being a <br>
modification to the IPsec specification, this requirement simply <br>
means that additional protocols are needed to establish a shared <br>
Group-SA. One possible approach for the Group Key Management (GKM)
<br>
protocol is to also deliver the Group-SA (and other keying material)
<br>
to the receiver at the same time it delivers the GroupDataKey <br>
[HCM98].<br>
<br>
<br>
7. Summary<br>
<br>
In summary, in the current work we have proposed for TRACK protocols the
<br>
separation of data stream confidentiality using a symmetric key (i.e.
<br>
implicit group-authentication) from data authentication using a <br>
symmetric key (i.e. explicit group-authentication). Data stream <br>
confidentiality using a symmetric key will be conducted at the <br>
application layer, while data authentication using a symmetric key will
<br>
be conducted at the network layer. Since the DRs/TN may be
(optionally) <br>
prevented from reading the multicast data, two (2) different symmetric
<br>
keys must be deployed corresponding to the needs of data stream <br>
confidentiality and data group-authentication.<br>
<br>
This proposal follows a number of requirements, some of which are <br>
specific to TRACK protocols. The use of group-authentication at the
<br>
network layer is:<br>
- for protection of the transport and IP headers.<br>
- to allow a DR to authentically retransmit lost packets to
<br>
a destination address (unicast or local
multicast) different <br>
from the original multicast group address.<br>
- to allow a separate symmetric key encryption to be applied
<br>
(at the application layer) in order prevent the
DRs/TN from<br>
reading the data.<br>
<br>
We assume encryption for confidentiality (using the GroupDataKey) has
<br>
been applied above the transport layer by the sender/source, in order to
<br>
prevent a DR/TN from decrypting the data. The GroupDataKey is only
<br>
available to the group members, excluding the interior control
nodes.<br>
<br>
We propose the use of another key (GroupAuthKey) to provide group-<br>
authentication from the source/sender at the network layer using <br>
symmetric key cryptography. The GroupAuthKey is known by the
members of <br>
the group, as well as the interior control nodes.<br>
<br>
For the retransmission of lost packets to regions within a group, either
<br>
via unicast or local multicast, we propose the use of a SubgroupAuthKey
<br>
(instead of the GroupAuthKey) which is known only to entities within a
<br>
region (DR and its children). The SubgroupAuthKey is also used by the
<br>
entities in a region to group-authenticate control messages that are
<br>
exchanged with each other. <br>
<br>
<br>
8. References<br>
<br>
[HCM98] T. Hardjono, B. Cain and I. Monga, "Intra-Domain Group Key
<br>
Management Protocol", work in progress,
draft-ietf-ipsec-intragkm-<br>
00.txt, Nov 1998.<br>
<br>
[HH99a] H. Harney and E. Harder, "Group Security Association Key
<br>
Management Protocol", work in progress,
draft-harney-sparta-gsakmp-sec-<br>
00.txt, May 1999.<br>
<br>
[KCWP00] M. Kadansky, D. Chiu, J. Wesley, J. Provino.
"Tree-based <br>
Reliable Multicast (TRAM)", work in progress,
draft-kadansky-tram-<br>
02.txt, January 2000.<br>
<br>
[KA98a] S. Kent and R. Atkinson, "Security Architecture for the
Internet <br>
Protocol", IETF, RFC 1825, 1998.<br>
<br>
[KA98b] S. Kent and R. Atkinson, "IP Authentication Header",
work in <br>
progress, Internet Draft, July 1998.<br>
<br>
[MG98a] C. Madson, R. Glenn, "The Use of HMAC-MD5-96 within ESP and
AH", <br>
work in progress, draft-ietf-ipsec-auth-hmac-md5-96-03.txt, Feb
1998<br>
<br>
[MG98b] C. Madson, R Glenn, The Use of HMAC-SHA-1-96 within ESP and
AH", <br>
work in progress, "draft-ietf-ipsec-auth-hmac-sha1-96-03.txt, Feb,
1998.<br>
<br>
[R92] R. Rivest, "MD5 Digest Algorithm", RFC1321, April
1992.<br>
<br>
[RSA93] RSA Laboratories, "PKCS#1: RSA Encryption
Standard", Volume1.5, <br>
No. 1993.<br>
<br>
[WBPM98] B. Whetten, M. Basavaiah, S. Paul, T. Montgomery, "RMTP-II
<br>
Specification". Work in progress,
draft-whetten-rmtp-ii-00.txt, April <br>
8, 1998.<br>
<br>
<br>
</font><br>
</html>
--=====================_286204430==_.ALT--
>From owner-rmt@listserv.lbl.gov Tue Feb 15 15:39:48 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id PAA21877;
Tue, 15 Feb 2000 15:36:46 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id PAA21873
for <rmt@listserv.lbl.gov>; Tue, 15 Feb 2000 15:36:44 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id PAA24618
for <rmt@listserv.lbl.gov>; Tue, 15 Feb 2000 15:36:43 -0800 (PST)
Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id PAA24577
for <rmt@lbl.gov>; Tue, 15 Feb 2000 15:36:38 -0800 (PST)
Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate2.mot.com (VWALL-IN-motgate2 2.0) with ESMTP id QAA11669 for <rmt@lbl.gov>; Tue, 15 Feb 2000 16:36:35 -0700 (MST)]
Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [217.1.10.38]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id QAA29203 for <rmt@lbl.gov>; Tue, 15 Feb 2000 16:36:29 -0700 (MST)]
Received: from arc.corp.mot.com (t-il06-x-port9.corp.mot.com [129.188.170.119])
by homer.arc.corp.mot.com (8.9.3/8.9.3) with ESMTP id KAA27954
for <rmt@lbl.gov>; Wed, 16 Feb 2000 10:34:59 +1100 (EST)
Message-ID: <38A9E54C.C5B94058@arc.corp.mot.com>
Date: Wed, 16 Feb 2000 10:46:20 +1100
From: Roger Kermode <rkermode@arc.corp.mot.com>
Reply-To: Roger.Kermode@motorola.com
Organization: Motorola
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: rmt-list <rmt@lbl.gov>
Subject: Thank you...
Content-Type: multipart/mixed;
boundary="------------F4B72D15639A2536D677AC53"
Sender: owner-rmt@lbl.gov
Precedence: bulk
This is a multi-part message in MIME format.
--------------F4B72D15639A2536D677AC53
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Dear RMT'ers,
thank you all for contributing so much last Thursday. Your efforts
were greatly appreciated. The minutes should be out shortly once
I've received all the various bits from the scribes and glued
them together.
One reminder from now on could we please use the subject prefixes
below for emails sent to the rmt-list.
FEC
TREE
ALC
NACK
CONG_{SR,MR}
TRACK
GRA
GUIDE
e.g. Subject "TREE: Table of contents"
Cheers,
Roger
--------------F4B72D15639A2536D677AC53
Content-Type: text/x-vcard; charset=us-ascii;
name="rkermode.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Roger Kermode
Content-Disposition: attachment;
filename="rkermode.vcf"
begin:vcard
n:Kermode;Roger
tel;cell:+61-408-212-284
tel;fax:+61-2-9666-0501
tel;home:+61-2-9664-8335
tel;work:+61-2-9666-0558
x-mozilla-html:FALSE
-mozilla-cpt:;0;;;
url:www.mot.com.au
org:Motorola Australian Research Centre;Scalable Commodity Internet Lab
version:2.1
email;internet:Roger.Kermode@motorola.com
title:Principal Research Engineer
adr;quoted-printable:;;PHYSICAL: Level 3, 12 Lord St., Botany, NSW=0D=0A=
x-mozilla-cpt:;0
fn:Roger Kermode
end:vcard
--------------F4B72D15639A2536D677AC53--
>From owner-rmt@listserv.lbl.gov Wed Feb 16 01:40:02 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id BAA22622;
Wed, 16 Feb 2000 01:39:36 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id BAA22618
for <rmt@listserv.lbl.gov>; Wed, 16 Feb 2000 01:39:33 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id BAA09312
for <rmt@listserv.lbl.gov>; Wed, 16 Feb 2000 01:39:32 -0800 (PST)
Received: from info.iet.unipi.it (info.iet.unipi.it [131.114.9.184])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id BAA09308
for <rmt@lbl.gov>; Wed, 16 Feb 2000 01:39:30 -0800 (PST)
Received: (from luigi@localhost)
by info.iet.unipi.it (8.9.3/8.9.3) id KAA69380;
Wed, 16 Feb 2000 10:39:23 +0100 (CET)
(envelope-from luigi)
From: Luigi Rizzo <luigi@info.iet.unipi.it>
Message-Id: <200002160939.KAA69380@info.iet.unipi.it>
Subject: pgm web page in place
To: rm@mash.cs.berkeley.edu
Date: Wed, 16 Feb 2000 10:39:23 +0100 (CET)
X-Mailer: ELM [version 2.4ME+ PL61 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-rmt@lbl.gov
Precedence: bulk
[To: rm list, Bcc: rmt list]
Just a brief note to inform you that i have put in place the web
page containing with a TCP-friendly congestion-controlled PGM
implementation (source code, a bootable PicoBSD floppy with lots
of good stuff on it so you can actually run it, and a report
describing the work).
http://www.iet.unipi.it/~luigi/pgm.html
cheers
luigi
-----------------------------------+-------------------------------------
Luigi RIZZO, luigi@iet.unipi.it . Dip. di Ing. dell'Informazione
http://www.iet.unipi.it/~luigi/ . Universita` di Pisa
TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy)
Mobile +39-347-0373137
-----------------------------------+-------------------------------------
>From owner-rmt@listserv.lbl.gov Thu Feb 24 01:31:08 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id BAA23450;
Thu, 24 Feb 2000 01:28:59 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id BAA23446
for <rmt@listserv.lbl.gov>; Thu, 24 Feb 2000 01:28:57 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id BAA10879
for <rmt@listserv.lbl.gov>; Thu, 24 Feb 2000 01:28:56 -0800 (PST)
Received: from pi4.informatik.uni-mannheim.de (root@pi4.informatik.uni-mannheim.de [134.155.48.96])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id BAA10869
for <rmt@lbl.gov>; Thu, 24 Feb 2000 01:28:55 -0800 (PST)
Received: from pi4.informatik.uni-mannheim.de (mauve@pi4 [134.155.48.96])
by pi4.informatik.uni-mannheim.de (8.9.3/8.9.3) with ESMTP id KAA20015;
Thu, 24 Feb 2000 10:28:46 +0100 (MET)
Message-ID: <38B4F9CE.17C28427@pi4.informatik.uni-mannheim.de>
Date: Thu, 24 Feb 2000 10:28:46 +0100
From: Martin Mauve <mauve@pi4.informatik.uni-mannheim.de>
Organization: University of Mannheim
X-Mailer: Mozilla 4.08 [en] (X11; I; SunOS 5.6 sun4u)
MIME-Version: 1.0
To: rem-conf@es.net, rmt@lbl.gov
Subject: RTP/I Internet Draft
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-rmt@lbl.gov
Precedence: bulk
Hi all,
please excuse if this mail is slightly off topic.
We have submitted an Internet Draft specifying a Real Time Application
Level Protocol for Distributed Interactive Media (RTP/I).
Here is the abstract of the RTP/I Internet Draft:
This document specifies RTP/I, an application level real-time
protocol for distributed interactive media. Typical examples of
distributed interactive media are shared whiteboards, networked
computer games and distributed virtual environments. RTP/I defines
a standardized framing for the transmission of data and provides
mechanisms that are universally needed for this media class.
Thereby RTP/I enables the development of reusable functionality and
generic services that can be employed for multiple distributed
interactive media. Examples for this kind of functionality are the
ability to record sessions, to support late coming participants,
and to provide security services. RTP/I is a protocol that follows
the ideas of application level framing and integrated layer
processing. It has been designed to be independent of the
underlying network and transport layers. To a large extend RTP/I
has been inspired by the real-time transport protocol (RTP), which
is used for continuous non-interactive media.
This document is intended to stimulate the discussion on how to
transport distributed interactive media over the Internet.
There exists an RTP/I mailing list. Instructions on how to subscribe
to this list can be found at the RTP/I homepage
(http://www.informatik.uni-mannheim.de/informatik/pi4/projects/RTPI/index.html).
Feedback on this document should be addressed to the RTP/I mailing
list or directly to the authors.
The RTP/I Internet Draft can be downloaded from the IETF directory or
from our RTP/I homepage (see above for the URL).
We would welcome any kind of feedback!
cheers,
Martin
--
---------------------------------------------------------------------------
Martin Mauve University of Mannheim
Praktische Informatik IV Phone: +49-621-181-2616
L 15,16 Fax : +49-621-181-2601
68131 Mannheim mauve@pi4.informatik.uni-mannheim.de
Germany
---------------------------------------------------------------------------
>From owner-rmt@listserv.lbl.gov Sun Mar 5 04:00:02 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id DAA14487;
Sun, 5 Mar 2000 03:58:00 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id DAA14483
for <rmt@listserv.lbl.gov>; Sun, 5 Mar 2000 03:57:57 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id DAA02865
for <rmt@listserv.lbl.gov>; Sun, 5 Mar 2000 03:57:56 -0800 (PST)
Received: from motgate.mot.com (motgate.mot.com [129.188.136.100])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id DAA02860
for <rmt@lbl.gov>; Sun, 5 Mar 2000 03:57:55 -0800 (PST)
Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (motgate 2.1) with ESMTP id EAA21434 for <rmt@lbl.gov>; Sun, 5 Mar 2000 04:57:54 -0700 (MST)]
Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [217.1.10.38]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id EAA17112 for <rmt@lbl.gov>; Sun, 5 Mar 2000 04:57:46 -0700 (MST)]
Received: from motorola.com ([217.2.31.248])
by homer.arc.corp.mot.com (8.9.3/8.9.3) with ESMTP id WAA12101
for <rmt@lbl.gov>; Sun, 5 Mar 2000 22:54:47 +1100 (EST)
Message-ID: <38C24AE1.C9C83844@motorola.com>
Date: Sun, 05 Mar 2000 22:54:11 +1100
From: Roger Kermode <Roger.Kermode@motorola.com>
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: rmt-list <rmt@lbl.gov>
Subject: RMT Meeting Feb 10, minutes draft
Content-Type: multipart/mixed;
boundary="------------12DAB1FB4EB5F784B0A83607"
Sender: owner-rmt@lbl.gov
Precedence: bulk
This is a multi-part message in MIME format.
--------------12DAB1FB4EB5F784B0A83607
Content-Type: multipart/alternative;
boundary="------------83EEF7F1661A5FD3901798F2"
--------------83EEF7F1661A5FD3901798F2
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Dear RMT'ers,
First of all please accept my apologies for the tardiness
in sending out these minutes/notes. Much thanks must go to
Sally Floyd and Bob Quinn for taking them during the meeting
Please take a moment to puruse them and point out any errors.
thanks!
Roger
------------------------------------------------------------
RMT Interim Working Group Meeting Feb 10, 2000
Minutes
-----------------------------
Attendees
Initials/Name/Interest
MH Mark Handley CC, NACK
SF Sally Floyd CC
DC Dah Ming Chiu ACK, TREE, CC
SK Shivkumar Kalyanaraman CC
LR Lars Rasmussen ALC
BQ Bob Quinn all aspects
CB Carsten Borman NACK (and the rest)
VO Volkan Ozdemir CC
YY Yung Yi CC
DA Deb Agarwal all aspects
BL Brian Levine tree building, yoga (!)
SB Supratek Bhattacharyya tree building
IR Injong Rhee CC
AC Adam Costello GRA, tree building
ML Michael Luby ALC, FEC, CC
BLu Bruce Lueckenhoff ALC
CP Christos Papadolulos GRA, tree building
JM Joe Macker NACK, ALC
BA Brian Adamson NACK, ALC
TH Thomas Hardjono Security
HR Hayder Radha CC/ALC
BW Brian Whetten track, CC
JG Jim Gemmell ALC, FEC, NACK
BC Brad Cain GRA, Tree building
TO Tokuop Oishi
GR Gursel Taskale all
RK Roger Kermode all
LV Lorenzo Vicisano all
----------------------------------------------------
Interim Reliable Multicast Transport Working Group
Feb. 10 2000, ACIRI, Berkeley CA.
[RK: thanks to Sally Floyd]
Several people are late, because highway 880 was closed for a while.
There is a SMUG (Secure Multicast Research Group) meeting here
tomorrow.
Intro by Roger:
[Add a pointer to Roger's viewgraphs.]
Goals of meeting,
Overview of agenda.
Call to Arms:
Building-Block and Design Space drafts are waiting for review by Mark.
Mike: Are we on-schedule with the goals listed in our charter?
Roger: We are behind schedule.
The group will standardize building block and protocol instantiation
documents.
The Guidelines draft:
[Add a pointer to Roger's viewgraphs.]
What is missing from here?
Mike: What about revision control between the PI (Protocol
Instantiation) and the BB (Building Blocks) documents? Do they
cross-reference each other?
This comes to the API issue: what parts of the BB documents are
referenced by the PI documents? The BBs have, not an API, but
a higher-level interface description.
NACK: There is a BB and a PI. How does this work?
Answer: The BB has the more general stuff. And a NACK PI
might also use ACK-based stuff.
Jim: Can we do an example, with PGM?
BBs should discuss design tradeoffs.
Building blocks might be more applicable than just bulk transfer,
though that is our immediate focus.
Mike: There is a danger of designing a BB without a PI in mind.
Maybe each PI should write its BBs, and then come together.
Mark, Sally: For NACK and TRACK, it is clear that there
is a CC (Congestion Control) BB that can be broken out now, in
parallel. For ALC, there might not be as many BBs that can
be broken out now.
FEC is a building block that can be taken out of ALC now.
What will go in the NACK BB?
Mike: Maybe the BB role can be more informational.
>From SMUG: BBs are coarse-grained, and might need more
fine-grained components within them.
Mark: BBs should not include all possible options, but should
narrow down the design space.
A call for BBs and PIs to start with overviews first, not the
nitty-gritty details. Out of today, perhaps we can end up
with overviews of each of the BBs.
------------------------------------------------------
Congestion Control:
Mark:
TFRC, Unicast TCP-Friendly Rate Control
[Add a pointer to Mark's viewgraphs.]
Pointer to paper: "http://www.aciri.org/tfrc/".
The talk shows results from experiments and simulations with TFRC.
For unicast, the performance is very good.
Question: Simulations with TFRC: in simulations, TFRC tends to drop to
zero with many flows, very high bandwidth? Mark didn't see this, will
look at it later.
Oscillations from smoothing the roundtrip time, and sending at 1/RTT:
For unicast TFRC, we added RTT-based Congestion Avoidance.
This is needed more for Drop-Tail than for RED queues, or for
high levels of statistical multiplexing.
Issues for multicast: timely feedback, measuring RTT.
Question: Does this apply to non-sender-based congestion control?
Mike Luby:
The work on CC for ALC is not finalized.
It is interesting to see if sender-based TFRC schemes will apply
to receiver-based ALC.
VRC: [Viziano, Rizzo, Crowcroft], the RLC protocol. Receivers join
a layer and all lower-bandwidth layers. Each layer has twice
the bandwidth of the previous layer.
Join times are quick, and leave times might now be quick also.
In his opinion, the RLC approach has more power than the
single-source approach.
For TCP-friendly issues, how does the RTT get taken into account?
Mark: In small levels of stat mux, increasing the sending rate can
dramatically increase the packet drop rate. This is not the
case with large-scale stat mux.
Mike: There is a lot of interesting work to be done.
Remark: Fine-grained video coding is the coming thing.
Roger: Is the discussion leading to BBs? Are we going into
too much detail?
Brian: We have a TRACK architecture overview, that shows how BBs
fit together.
TEAR:
Similar to a TFRC building block. Differs in how to measure a
fair TCP throughput.
TEAR differs from TFRC in the receiver. Instead of using the
TCP-friendly equation, TEAR emulates TCP at the receiver.
Takes a weighted average of eight TCP congestion control
rounds. TEAR trys to give a more accurate model of TCP.
Mark: TEAR is sensitive to the pattern of losses. And they
differ in the modeling of retransmit timeouts.
Shiv Kalyanaraman:
Generic source-based multicast congestion control.
[Get a pointer to viewgraphs.]
This is sender-based congestion control.
No measurement support from the receiver set, except for NACKS or ACKS
that are already there.
No aggregation support expected in the tree.
Congestion periods are broken into congestion epochs, which is
a period with a single rate reduction, with time for the
rate-reduction to diffuse to the congested sub-tree.
Mark: He is assuming a very low level of stat mux? He is assuming that
if the sending rate is increased, the packet loss rate increases also?
The protocol mimics TCP at every point.
They have implemented this in NS, and they have a PGM implementation.
----------------------------------------------
-----------------------------------
RMT Interim Working Group Meeting
-- Draft Minutes --
[ RK: thanks to Bob Quinn]
Feb 10, /2000 - Hosted by Aciri
at ICSI in Berkeley, CA
-----------------------------------
Roger Kermode, RMT working group co-chair, started the meeting
at AM with 18 people present (we had 28 by 11AM) with a review
of the agenda.
Tentative Agenda
---------------------------------
09:00 - 09:10 10 mins Agenda Bashing
[Roger]
09:10 - 09:10 10 mins WG status update
bb + ds drafts
Recharter
09:10 - 09:20 10 mins Call to arms/editorship selection update
[Roger]
09:20 - 09:40 40 mins Guidelines Draft Update/Discussion
[Roger/Lorenzo/Allison]
10 mins draft outline
30 mins discussion
10:00 - 11:20 1hr20mins Congestion Control: [Handley/Flloyd?]
10 mins TFMCC update [Handley/Flloyd]
10 mins ALC implications for CC [Luby]
10 mins TEAR implications for CC [Rhee]
10 mins Generic source-based multicast CC
[Kalyanaraman]
40 mins discussion
11:20 - 12:20 1hr NACK: [Bormann & Adamson?]
10 mins BB Update [Borman]
20 mins BB Discussion
10 mins PI Update [Adamson]
20 mins PI Discusion
12:20 - 13:00 1hr Lunch
13:00 - 14:00 1hr Asynchronous Layered Coding: [Luby]
10 mins BB update
10 mins Gemmell?
40 mins discussion
14:00 - 14:30 1hr Tree-Building: [??]
10 mins table of contents update [Chiu]
20 mins discussion
14:30 - 16:00 1hr TRACK progress [Whetten/Chiu]
10 mins [Whetten]
10 mins [Chiu]
40 mins Discussion
16:00 - 16:45 45 mins VACANT
16:45 - 17:00 15 mins Agenda bashing for Adelaide
RMT has been rechartered and the new charter--now approved
by IESG--is in place on the RMT working group webpage.
http://www.ietf.org/html.charters/rmt-charter.html
Mark Handley showed the new charter as it appears on
the RMT working group webpage.
Roger provided status for the existing documents. The charter
is agressive and we are a bit behind at this point. Many of
the documents are essentially done (though most are not issued
as Internet Drafts (I-D). Generic Router Assist (GRA) is the
only exception. The Multicast Congestion Control document is
due for Apri--after Addelaide--and it is acknowledged as the
most difficult problem, and the one that gates all others.
Mike Luby asked whether we expect to be doing work on both the
BBs or the instantiations, and Roger said, "Yes, both."
The Building Block (BB) Guidelines draft has been stalled.
That is likely a source of confusion, since many people may not
know how to proceed with creating a BB I-D without it. The idea
behind the BB is tp create some framework definitions for Reliable
multicast transport (RMT) that exist for Real-Time Protocol (RTP)
format.
Goal: to help people write Building Block (BB)
and Protocol Instantiation (PI) drafts
- How BBs and PIs fit together
- Sections to be included:
+ applicatiblity statement
= where to use and where NOT to use
= known failure modes
+ BB:
= bunctional description
= abstract API for use by other BBs
+ PI (protocol instantiation):
= core functionality not in BBs
= which BBs are used
= how they fit together
= packet formats
Mark Handley and Sally Floyd (MH and SF): PI needs to be
specific about the application targets
- the PI *may* have some mechanisms that BB doesn't
(but not all will)
Joe Macker (JM): The BB should describe the trade-offs
MH: Some BBs will be more generic as far as being applicable
to bulk file transfer alone, and others will not.
Mike Luby (ML): doing the BB first and the PI second seems
backwards. It would be better to do the PI, then try to
derive the commonalities that represent the BB.
MH: We alread have a lot of existing protocols that we
understand very well.
ML: But are these written down?
Roger Kermode (RK): Our hope is that people that have the
experience with specific protocols need to exchange their
experiences.
ML: But again, it is written down?
MH: We may well do some back-tracking after the fact, but
we expect that.
ML: I think it is important to do the PI first and write it
down.
MH: I think that ALC may be one where that is true
ML: Why is that?
SF: Because there are lots of TRACK and NACK based protocols
for which we understand the commonalities so it makes a lot
of sense to do the BBs in parallel with PIs.
Jim Gemmel (JG): I'm fuzzy about what goes into a BB, is it
going to simply say what NAK does or list many different
ways it could work.
MH: I think that NAK will have suppression mechanisms built
into it.
JG: Are you going to list the mechanisms/algorithms?
MH: We need to pick one and describe it.
JG: But there are so many
ML: You pick one and it may not be appropriate in all cases.
Thomas Hardjono (TH): In SMuG we have picked a number of them
RK: We are obviously still struggling with what a BB is, so
I tend to agree with Mike that we should concentrate on a PI
first.
??: I thought that the BB was supposed to describe what we
recommend with Interet health as the focus.
SF: It is a good idea to have things that refer to Internet
health, but we already have RFC 2357 (?) that describes the
requirements for any RM transport.
RK: I think we are approaching some concensus.
JG: Go write one and lets take a look at it
??: Suggested that we have an overview and functionality
description for each BB *first* then move into the other
details
---
TFRC - TCP-Freindly rate control Mark Handley
(Equation based congestion control)
- we thought we understood this (for unicast) a year ago,
but we did not and we don't know multicast yet.
Scripts and paper all available at http://www.aciri.org/tfrc
It is fair to TCP in general, although we have seen TCP
get beat up because it was too bursty
Key measures are loss fraction and round trip time
Measuring round trip time, there are oscillations in TCP
and with multicast the delays between these is longer.
To dampen oscillations but still gain RTT-based congestion
avoideance behavior, need inverse dependence on RTT but
lower gain. <<see equation>> The result of this is a
smoothing of the oscilllations.
- If you fix the RTT time, you get the oscillations, but
if you don't (as described above) then they are smoothed.
- we've tried these things with a wide variety of Queuing
congestion control mechmanisms, and it works well with
all (though having RED reduces the need for this mechansism).
Issues for Multicast
- how to ensure timely feeback? Delay reporting loss event
fraction may affect dynamics
- How to measure RTT to all receivers quickly? Not a showstopper,
but may affect how CCC fits together with other components
- RTT-based Congestion Avoidance is difficult (referring to
the algorithm described above): It is not clear that this is
necessary, but the consequences of not doing it are not yet
fully understood.
??: What is the traffic load for reporting congestion control?
MH: You really want your NACK or ACK trafffic to report it,
and with aggregation points (TRACK or other local/shared
recovery points) you have additional delay. None of this
applies to ALC though, of course (since it is one-way).
ML: Yes, but reading through your paper I got the impression
that a lot of it is based on the receiver, so it could well
be applicable.
ML: If you actually did an experiment with two TCPs then they
would not be fair to each other. The one that has longer
timeout (say 10 times) would be 100 times more loss.
SF: I don't believe that loss rate would be 10 times more
Brian Whetten (BW): I don't beleive it would be, either.
JM: What about slow-start mechanism for multicast?
MH: We may not need one for multicast since the advantage
of having one is not clear yet.
----
Asynchronous Layered Coding (ALC) BB Mike Luby
The work on ALC CC is not finalized yet, though there has
been some great work done so far.
- thing about ALC is that you can have different receivers
receiving at different rates (determined by the number
of groups they have joined, and streams they are receiving
in parallel) and we need to take advantage of it.
- VRC (authors Lorenzo V. , R. and Crowcroft mechanism
is used for this (also referred to as RLC for author names
also ...for some unknown reason).
- Synchronization points happen more often at the lower
layers than at the upper layers. Layers are cumulative.
It is now a very course-grained CC, and we should make it
more fine-grained (more fine-grained than the synch points
can provide). Current one gives a linear increase.
SF: A factor involved with whether you couild ramp up send
rater slowly is whether you have either small or large-scale
statistical multiplexing.
Hayder Radha (HR): ALC sounds much like MPEg-4, which provides
fine-grained scalability and uses many different multicast
groups (roughly 10-20).
--
Short talk on TEAR Rhee
- TFRC uses equations looking at 8 loss events that have
occurred and is based on what it finds from the sender,
whereas TEAR emulates TCP within the receiver and how.
MH: TEAR is sensitive to the pattern of losses (which
may be good or bad) and sensitive to the timeouts.
--
Generic Source-Based Mcast Congewstion Control
Shivkumar Kalyanaraman (RPI) <<missed the URL>>
- implosion control needed
- need timing info on Sender & Reciever (may need GPS at
receivers)
- Need to know the (S,G) state
"Generic" means
- completely implemented at the source
- no measurement support from receivers
- no extra contol traffic inserted
- no extra fields
- no aggregation support expected
- should work with NAKs, HACKs, ACKs, bit maps or other
reverse traffic which provides congestion and timing
information
Weak requirements on RTT & loss estimation:
- suppress NAKs from long RTTs (partial timing info)
Basic idea is that they devide congestion time periods
into "epochs" where the source reduces the send rate
exactly once and enough time is given for rate-reduction
to diffuse throughout the congested sub-tree.
They do not depend on the loss rate.
They have implemented it in their version of PGM.
MH: Seems like you are not depending on having large-scale
statistical multiplexing rate and that assumes that the
competing flows are doing the same thing, which is a flawed
assumption.
--
Brian Whetten said he has done a description of how the
BBs fit together from the perspective of TRACK.* reliability
======
short break
======
RK: This is a new process we've been doing with the BB approach,
so we need to describe it in more detail.
Boorman: The BB needs to be normative, we need to have it as
something that people can reference as opposed to something
that is not
BW: It should have exact algorithms and abstract APIs
SF: BBs need to describe design tradeoffs required for Application-
specific variations (e.g. optional feedback).
Single Rate CC BB Team:
Mark H (leader), Sally F., Injong, Brian W., Shiv, Supratek, Hursel,
Joe Macker, Brian A.
MultiRate CC BB Team:
Mike L (leader), Lorenzo, Hayder, Injong, Jim Gemmel, Luigi Rizzo,
Jon Crowcroft
??: I come from a satellite company and I'd like to see some
satellite-specific considerations described.
RK: We deal with the Big 'I' Internet and this includes the
satellite media, so it is included implicitly.
MH: It looks like Single Source multicast (e.g. PIM Source Only)
will have an earlier deployment than others so it is likely that
we will have one-way links as well as two-way, so in that context
satellite is not that special despite the fact it has a long fat
pipe (long delay and high bandwidth capacity).
RK: Can we have a document by Adelaide on Single Rate, Mark?
MH: Yes, we can have a *start* on a document. We need at least
a first pass of *every* building block by that time.
RK: The due date for drafts is March 10 and we should really
strive to have something done by this time.
MH: We should also submit the names to the RFC editor beforehand
so it doesn't get delayed (we should do this on the mailing list).
RK: Ok, will do.
MH: Should we have discussions in sub-groups or on the main RMT
mailing list. <<A number of people responded that they would
prefer having this traffic on the main RMT mailing list>>
<<begin from whiteboard>>
CC Building Block Guidelines
-----------------------------
Must be normative - exact specific algorithms and abstract APIs
Discussions of tradeoffs - application specific variations (e.g.
optional feedback). Cover design space.
Purpose: RFC 2357 and Sally Floyd's Congestion Control Principles
draft, see http://www.aciri.org/floyd/papers/draft-floyd-cong-01.txt
+ 2 parts:
= Mandatory to satisfy IESG reqs
= Application specific
Requirements for other BBs:
- what messages can be piggy-backed (existing BB msgs and
additional msgs) .
- loss detection
- RTT measurement
Two Separate BBs:
-> single source (e.g., PIM-SO)
-> Others (single rate)
- satellite, asymmetric, wireless,
GRA Considerations
target scale (in terms of number of receivers).
<<end from whiteboard>>
---
How TRACK fits with other BBs Brian Whetten
(( his view of what needs to go into BBs ))
Goals
- functional decomposition across other BBs
- sees TRACK as a superset of NACK
Exponential back-off on loss detection
Unicast NACK generation
- issue: NACK needs multicast NACKS?
response to retransmission request
GRA signaling
Integration with TRACK hierarchy
- how do you do this well
SF: Why is this included here?
BW: We repeat it in both places
Question: Since it is a superset of NACK, why have a separate BB?
BW: Interesting thought.
MH: We need to do suppression so the question is how to do it.
You can do it by a tree or not, so the discussion needs to talk
about it with that focus
MH: One thing missing here is how it interacts with and uses FEC.
Lorenzo Vicanso (LV): Yes, FEC is very mixed with suppression.
MH: FEC itself is not in there, but a description of its
functionality is.
??: Why do you call it NACK when it should really be a generic
feedback mechanism?
BW: We have differentiated the feedback (for CC) and the
NACK for data loss and the TRACK since it has to deal with
hierarchy.
Brad Cain: What do you think the biggest issue is?
BW: The issue of how and when you deal with the NACKs.
FEC BB:
- input of a (sub) window of data packets
+ issue: packet nameing
- creating parity packet
+ issue: exhaustion of parity packets
+ proactive parity (which block owns it)?
- flush data stream with only a small sub-window
- FEC decode
- Bind to different codecs
LV: It seems that some of these issues (like flush) belong
in the protocol instantiation.
BW: This is a highlight of the functions and not specifications
of what they are doing
ML: I would just talk about the protocol and not how it will
work in all protocol instantiations. That cannot work.
RK: The model to look at for this framework is RTP, where
there is enough generality to allow a common, versatile
framework.
LV: You need an API for making state available
ML: There is a way to describe FECs in general without going
into detail with exactly how to use them.
??: This has actually been done in the AVT RFCs that deal
with codecs (may still be I-Ds at this point). They may not
be exact, but it is a good thing to start with.
LV: You can define blocks and when you can reveal the blocks
and deal with them.
TFMCC BB:
- Initialization
- Receiver measuraments
+ issue: RTT measurements
- Receiver feedback (on TRACK/NACK)
+ Issue: how to bias NACK timers?
- hierarchical aggregation
- sender rate control
MH: There's no requirement for interoperability until you get
into a PI. The packet formats are defined in terms of funcionatlity
rather than generically as "feedback" to be efficient in terms of
size used.
GRA BB (draft-ietf-rmt-gra-arch-00.txt):
- Core, simple router functionality
+ issue: how to instantiate this?
- signaling guidelines
- NACK
Brad Cain (co-author): we will have a separate document that will
include feedback mechanism defined and we will define packet
format. It will be incrementally deployable (as spec already
says). We will be dealing with server-to-server traffic, which
is the auto-tree configuration.
Auto-Tree Configuration BB:
- Discover hierarchy that matches the multicast topology
- works in all environments
- provides children with an address list of candidates
+ if/when first fails you go to second one
BC: You need to discover namers, create hierarchy (some sort
of routing protocols where you abstract away who is closest
to the root).
JM: Is this going to be a routing-ish shared tree?
BC: We are not doing that level of detail ...we are not creating
PIM over a mesh. Once you abstract away what a possible root
could be (source, RP, etc.), then there has to be a route from
whatever it is. Then that has to be...??? I wouldn't touch that
one with a ten-foot pole. There will be packets between servers,
and there will need to be a way to measure distance between server
to source and you can do that LOTS of different ways. You need
to know what the metric means.
BW: Yes, I agree that the problem is not yet well defined
======
lunch break
======
<< Brian Whetten, on TRACK BB Requirements, continued >>
Common Packet Headers
- Data Naming
+ sequence number, FEC offset
+ issues: Add object ID? Need sequential packet numbering.
Need to support application level multicast
- Session naming
+ stream ID
+ TRACK may need a Tree ID
- Also issues with Application Level Framing (Talarian,
TIBCO and FastForward are three examples), since you are
multiplexing at a different level
MH: There seems to be three sequence spaces:
- packets within FEC block
- FEC blocks themselves
- Object ID itself
You might be able to build over to create frames over
that, but it must be at the object level to get reliability.
I think it might be worthwhile to go down this path to see
what comes out, what meta-information we need.
BW: The other consideration that is important is the number
of bits we add to support this.
MH: My view on bits is don't worry about it, since it is only
on low-bandwidth links that it is a concern
Security BB
- Really SMuG's area and our area
- Transports only job is to protect itself
- Interface to key managerment is what we need
- IPSec for lightweight version
TRACK functions
- hierarchy creation and maintenance
+ join, leave, falure recovery, keepalives
+ local multicast groups for control, retransmission
- parameter initializeation/distribution
+ server and tree-wide
- source ordered, unordered, time bounded (?)
- network management
JM: Is there a new security consideration for ACK Aggregation
TH: At last IETF I talked about a mechanism whereby an intermediate
point that received a NACK would have to forward them upstream
for signing (so intermediate point does not need to be a trusted
participant). Authentication and trust models are the issues.
LV: The NACK authentication is an end-to-end issue
TH: Yes, but NACKS are from routers
BW: Routers don't issue NACKs, however. Routers create the tree
(for TRACK).
MH: Tree-based protocols help you to generate round trip times.
TRACK Issues
- Kill TN and Aggregators?
+ shared tree versus per-source tree?
- Can we have dynamic DR/receivers
- Multicast address sharing
BW: Is top of the tree always co-located with the sender?
MH: There are lots of different ways to build trees
BW: You can have multiple data sources for a single tree
BC: It would be good if anyone desiging NACKs talk to
him and BL about how to define them for each of the
BB type (e.g. NACK, TRACK, ALC), specifically in terms
of application interface and packet formats.
======
We then had break-out meetings for separate sub-groups:
"ALC", ""NACK," and "Tree Building" (in quotes since these
are very loosely defined). Here are the topics discussed:
"ALC":
- FEC
- PI for ALC
- Congestion Control
"NACK":
- PI versus BB
- NACK
- Congestion Control
"Tree Building"
- Auto Tree config
=========
Wrap Up
=========
Roger Kermode on Auto-Tree Creation BB discussion:
- Preconfigured solution
+ assumes the existence of a mesh of delivery servers
(which may be statically configured or dynamically
generated):
+ requires existing infrastructure on internal nodes
- Ad hoc solution
+ does not require predeployment
+ assumes mesh discovery protocol
+ no GRA
+ no TTL scoping (needs to support PIM_SO)
+ no static config info in hosts
MH: Do you have any reference implementations for these models?
I'd like to see some running code.
Mike Luby on ALC:
- we had lots of concensus and progress
- We also took on the FEC BB
TRACK:
- what identifies a source or a receiver?
NACK:
- We also discussed FEC a lot too since it is tied in
Rather than having different mailing lists for each subgroup,
Roger proposed that everything go to RMT and we preface subjects
with what the topic is relevant to (and add "PI" as a suffix if
that's the topic) FEC, TREE, ALC, NACK, CONG_{SR | MR}, TRACK,
GRA, or GUIDE. He will send a message to the RMT mailing list
describing this.
<<end>>
=========================================
Notes from TRACK sub-group Discussions
RMT Working Group Meeting 2/6/00
=========================================
blame bob quinn <rcq@stardust.com> for any innaccuracies
Motivation for creating a tree
- Good for error control and congestion control
- Distributed aggregation (caching hierarchies, e.g., for
use in a Content Distribution Network (CDN))
- Anycast
- Security, group key management
- Distributed gaming/simulations
All have similar requirements
Why is it useful?
1) hierarchical construction assists with load balancing
2) topologically aware aggregation
3) topologically aware subcasting
First is sufficient (2nd and 3rd are efficient).
Why by aware of topography?
- topologically based structures have dramatic performance benefits
+ localized aggregation
+ subcasts that are focused towards downstream logical descendants
+ allow use of subcast, period.
+ ensures reduced latency between pairs
Applications
- local aggregation
+ error, congestion control, CDN, security
- focused subcasts
+ error, congestion, security
- reduced latency between pairs
+ gaming, anycast
BW: So is the goal topological congruency?
Brian Levine (BL): Yes
BW: Would anyone debate that?
BL: yes. You can't do it now without difficulty, but that
does not mean it is not something we should *try* to do.
BC: That is something we should strive for.
BW: There are some that would say it is better for error
control
BL: I don't agree with that
BW: I just want to talk about it since it is relevant to
asymmetric routing, among other thigns.
BC: That is a really tricky issue and the other reason
is inter-domain
BW: Exactly, which is why single-AS is going to rule
BC: Exactly.
BW: Should we scope it to a single domain?
<general disagreement>
"Easy" way to do topo-aware
- use GRA!!
- Source periodically multicast packets with GRA and
router alert (MD5 Auth)
+ They go down the tree from a parent
+ I'm assuming we are doing Express mode stuff
- GRA routers with their IP address in the payload of
the packet (perhaps both in and out interfaces ...?)
+ Each hop adds as packet traverses
+ As there are more routers, you get a better idea
- Receivers subcast from last revised router announcing
their path strings
- Receivers pick parents, send unicast to confirm
- Or...new mtrace messages (added by Brad Cain)
+ This would trace down the tree (though we have not
yet figured out the format ...though many don't like
mtrace since it gathers statistics, has latency and
adds overhead)
??: There was a guy at MCast2000 who said that the hyperqueue
could build a tree very quickly
BC: There is part of this that people can use to do other
tricky things. For example how do you find out how close
you are to a source or an intermediate routers and there
are lots of ways to do it.
Two problems with finding a metric that's good: congruency
and how best to announce to the group
Breaking Up the Problem:
- Neighbor Discovery
- routing-like protocol
+ who is closest to the "source" (for mcast)
+ who is closest to other point (e.g. server)
- How to find distance to server or seoruce?
- How to make it generic?
+ can we do it for others than reliable multicast, such
as the content delivery people.
- Fault tolerance
BC: Looking at a graph or mesh of servers and over the top
of that there is some sort of protocol that you use to build
a hierarchy in the server to server protocol itself. To do
so you need to have some sort of metric, such as who is
closest to data source or RP.
You discover a set of neighbors within a scope (that's how
the mesh is built), then over that mesh you establish the
tree.
BW: That is basically what we are looking at but that could
be a heavy weight protocol.
BC: You can statically configure the mesh (which will most
often be the case anyway ...that's the way these content
distribution network guys are doing already).
RK: We have to be able to exist where GRA doesn't already
exist.
BL: If we didn't bring up topological awareness then
we woudln't have any issue with non-GRA implementations.
We are being passed-by and need to do *something*:
- companies can do non-topo aware without us, though
standards are nice
- eventually they *will* do topo-aware without us
- As IETF'ers we should make recommendations
BW: The barriers to getting GRA into all the routing
infrastructure is so high that from a practical standpoint
we should be able to use it without GRA.
BL: I think it will take 3 years to get GRA widely available
BW: I think that is really wishful, which is why we should
think about new mtrace messages.
BC: The mtrace command needs access control (password, maybe?)
since it reveals the tree which can be very dangerous.
RK: If you are going to use mtrace, think about a network
with 10000 nodes
BC: MTrace would not scale to that many receivers
BC: you can try to match receivers with nearest server
or make tree closest to source. The content delivery is
focused on making caches close by to receivers.
??: Seems a question of how tall you want to make the tree
with respect to how much fan-out there is (the optimality
of the tree).
BC: Yes, that all relates to how you build the tree
Miriam Kadansky did a doc that relates to requirements
BL referenced this and created slides from the TOC.
Dah Ming (DM): How the the tree is formed and then used.
This was a strawman for generating discussions. We have
lots of information about tree optimization and maintenance
as well as tree building and what I'd like to see is a
discussion of how much of this belongs in the BB.
BW: I think only the building of the tree is important.
BC: I think there should be two layers: a base layer that
can be useful for a lot of things and the second that is
specific to reliable multicast.
RK: Auto-Tree Requirements (RM specific)
--------------------------
1) Aggregation of things like ACKs, NACKS, congestion control
2) Subcasting
- parent to child unicast (application level)
- parent to all descendents local multicast group
- parent to child (GRA)
3) Others (non-RM specific)
- group membership
- list of GRA-capable routers
- billing
RK: It has to be spelled-out in the draft what is RM-specific
and what is not.
TH: Some mechanisms used to design the tree are exactly the
same that is needed to deliver some of the services that the
tree is supposed to support.
BW: So, for example, you could use subcast to do auto tree
configuration.
TH: Good examplee
BW: Goals:
- Perfect topology congruence
- failing that, do something not stupid
- list of parents
BC: Where does the metric fit in? How do you determine a
"perfect tree?" What does the API give you?
BW: These are the list of parents and the metric(s). There
are other interactions to prevent loops (for example). We
may be able to pick one metric.
BL: we should have one metric in mind.
BC: There are a number of different possibilities.
RK: You are building a tree to do what, connect sources with
receivers or with end-points??
DM: The DR could be either the source or the distribution head.
BW: The head of the tree is always the source
BC: the problem is that if you are given just a list of neighbors
and metrics, then you could construct a tree that has loops.
BW: I was assuming it was at least an ordered list so there are
no loops.
BL: you can always override this, so we must assume that it
has no loops. Congurence is the goal and besides, it is not even
a tree if it has loops.
DM: There are diffferent ways to make sure you don't have a loop,
BW: Yes, but if you just know the depth of the tree then this is
enough information to create a non-looped system.
DH: That implies the tree is built top-down
BW: The issue comes down to work
BC: right.
BW: Who has to do the job
BC: The loop protection depends on what info is exchnaged between
nodes.
Requirements (according to BW)
- Universally deployable
+ multi-AS
+ All multicast routing
+ GRA
- Safe
- Receiver auto-config
+ e.g. receivers can find their nearest server
- Keep it Simple
BC: I think the receiver auto-config is DONE: DNS
(though Anycast or a web-page or other out-of-band
mechanism could be used also)
BW: I am just defining high-level requirements without
considering solutions
BC: We need to be able to "prune protocols" (to quote
Steve Deering) to make it simple
BC: Do we want to get into Policy metrics when considering
inter-AS (inter-domain)?
BW: I really don't think we want to go there.
BC: All protocols are source based now
BW: Huh? Applications don't have a way to specify the
source.
??: the tree building protocol is running all the time?
BW: Yes, so you can ask anytime for what parents are
RK: It sounds like you are trying to punt things away, so
if it does not get done here where does it get done?
BW: In TRACK
BC: We still need to determine the line between TRACK and
here.
BW: The issue is that keep-alives, HACK packets, get generated.
It is control path versus data path issue.
RK: I like that separation between control and data paths.
This document should be sufficient to create a control path
and that control path is used to deliver data.
BW: There is realistic three peices here: all error packets
are part of data. We want auto-tree config information.
BC: I agree they are separate, but think there is anough
commonality to keep them together.
BW: I am abstracting out configuration information for control
RK: Can we separate out like:
- Ctrl path: tree creation and maintainenace
- Data path: "repair" PI specific control
<< short diversion into discussing whether it is possible to
create a generic BB or whether we have to start with a PI
...the challenge being whether we can have something generic
without getting into protocol details >>
BC: You can do something really simple, but if it is going
to be that minimal, there is some question about whether
it is useful.
TH: It has to work, so it can't be that thin. The thing is
that to be useful, we need to agree on some common elements.
BW: I think the NACK BB is going to be very short (deal with
retry timer and action) and I suspect that we can make this
Tree Building BB just as small.
BC: CDN people want all these things. I don't know where
the line is between generic BB and PI.
??: There are two main things: discovery and maintenance.
DM: Yes, but it is more complex since there are different
scenarios (e.g. late joins).
RK: Tree "functions"
- Discovery: learning *possible* parents (manually or auto)
- Construction: Joining the tree
+ BC: e.g. applying Dijkstra and creating link-state
- Maintenance: Fail over, leaving
- Service Hooks (sub-cast, aggregation, etc.)
BW: Problem is you can't discover parents without considering
where the source is.
BC: What is the signal for generating a tree, is it that a
receiver joined or that a source is there?
BW: I would say when receiver joins
BC: I would agree with that
RK: Discovery:
- who starts the process?
+ source: top-down tree generation
+ receiver: bottom up tree generation
BW: The way the world actually works is you have a collection
of Sources, a collection of potential DR's (intermediates)
and receivers (he illustrated on board with three layers).
BC: We are not dealing with the receivers to servers in this
tree building (which is a server location problem ...and we
can safely assume that DNS solves this). Most of the time
the configuration of the mesh of intermediates is statically
configured (99% of the time) ...call it "the Mesh." At this
point there are NO TREES yet (an important point), so there's
no concept of loops at this point since nothing is source
specific.
BW: Mesh:
1) neighbor disovery
2) senders announce
3) receivers initiate join
BC: Alternately, the source finds a server
DM: Yes, there may be many servers that are not relevant
to a source
BC: Ok, yes, so let's assume that the source does NOT
announce to the servers. We already know how to do this
and it's called multicast routing (using PIM). It requires
that each server knows the metric distance to the source(s).
BW: Ok, so we're done! We will just run another routing
protocol (along with the one below us at the IP layer that
we cannot access and the one that may be above at the
application level).
??: Ok, this assumes that there is a mesh, but what if
we don't assume this?
BC: I disagree, since if you look at anything on the net
it is formed as a mesh and there are a lot of administrative
issues about who can talk to who.
Lots of discussion/debate about whether we can assume that
the mesh is avilable as preconfigured infrastructure. To do
auto configuration we cannot assume many-to-many SRM-like
discovery.
Dah Ming and BL agreed that having the intermediate mesh
assumed makes having the receivers going directly to senders
impossible (e.g. so the receivers can organize into a tree
without having an intermediate layer).
BL: Could send from source with IP list, as I described earlier.
DM: Yes.
BC: Ok, if source sends magic packet then each receiver
picks a receiving parent.
DM: Yes. This should be allowed and the static intermediate
layer could be optional.
BL: Yes, and then any intermediate node can declare that
they don't want to be part of the tree.
-> Some disagreement about which of the two models should be
the primary requirement.
RK: My dream protocol that I want
- Doesn't require GRA (but be compatible with GRA)
- Doesn't use TTL scoping
- Needs to work in PIM source only (PIM-SO)
- Doesn't require config info in hosts
- Doesn't require statically deployed mesh
BC: You may want to determine your tree with metrics other
than hops (e.g., server load, geographic location, etc.).
BL (and others): the one where receivers can be DRs makes
the static mesh possible, but the converse is NOT true.
BC: I disagree. Since not all receivers can send, it becomes
an access control issue that assumes many-to-many multicast
is possible.
Summary of differences between the two models:
> Dynamic Discovery version sends a probe from the source and
each *logical* hop adds its addres and the metric you end up
using is a router-like distance metric that uses the number
of hops. In that model also, any receiver can (potentially)
be a repair node, which Brad and BW both say is not realistic
since that assumes many-to-many (like SRM) and that is simply
not available in the real world. In this model only the members
in the mesh can be repair nodes. Brad pointed out that this
is how all of the CDN folk do things.
> Other version assumes the creation/existence of a mesh
which can use *any* number of different metrics for distance
(not just a router-like "number of hops", which would have
to count virtual hops, since it counts servers rather than
routers).
The first model can co-exist with the second, but the first
cannot exist if the existence of the mesh in the first is
assumed.
<<end>>
--------------83EEF7F1661A5FD3901798F2
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<tt>Dear RMT'ers,</tt>
<p><tt>First of all please accept my apologies for the tardiness</tt>
<br><tt>in sending out these minutes/notes. Much thanks must go to</tt>
<br><tt>Sally Floyd and Bob Quinn for taking them during the meeting</tt>
<br><tt>Please take a moment to puruse them and point out any errors.</tt>
<p><tt>thanks!</tt>
<p><tt>Roger</tt>
<br><tt></tt> <tt></tt>
<p><tt>------------------------------------------------------------</tt><tt></tt>
<p><tt>RMT Interim Working Group Meeting Feb 10, 2000</tt>
<br><tt>Minutes</tt>
<br><tt>-----------------------------</tt><tt></tt>
<p><tt>Attendees</tt>
<p><tt>Initials/Name/Interest</tt>
<br><tt>MH Mark Handley
CC, NACK</tt>
<br><tt>SF Sally Floyd
CC</tt>
<br><tt>DC Dah Ming Chiu
ACK, TREE, CC</tt>
<br><tt>SK Shivkumar Kalyanaraman CC</tt>
<br><tt>LR Lars Rasmussen
ALC</tt>
<br><tt>BQ Bob Quinn
all aspects</tt>
<br><tt>CB Carsten Borman
NACK (and the rest)</tt>
<br><tt>VO Volkan Ozdemir
CC</tt>
<br><tt>YY Yung Yi
CC</tt>
<br><tt>DA Deb Agarwal
all aspects</tt>
<br><tt>BL Brian Levine
tree building, yoga (!)</tt>
<br><tt>SB Supratek Bhattacharyya tree building</tt>
<br><tt>IR Injong Rhee
CC</tt>
<br><tt>AC Adam Costello
GRA, tree building</tt>
<br><tt>ML Michael Luby
ALC, FEC, CC</tt>
<br><tt>BLu Bruce Lueckenhoff ALC</tt>
<br><tt>CP Christos Papadolulos GRA, tree building</tt>
<br><tt>JM Joe Macker
NACK, ALC</tt>
<br><tt>BA Brian Adamson
NACK, ALC</tt>
<br><tt>TH Thomas Hardjono
Security</tt>
<br><tt>HR Hayder Radha
CC/ALC</tt>
<br><tt>BW Brian Whetten
track, CC</tt>
<br><tt>JG Jim Gemmell
ALC, FEC, NACK</tt>
<br><tt>BC Brad Cain
GRA, Tree building</tt>
<br><tt>TO Tokuop Oishi</tt>
<br><tt>GR Gursel Taskale
all</tt>
<p><tt>RK Roger Kermode
all</tt>
<br><tt>LV Lorenzo Vicisano
all</tt>
<br>
<p><tt>----------------------------------------------------</tt><tt></tt>
<p><tt>Interim Reliable Multicast Transport Working Group</tt>
<br><tt>Feb. 10 2000, ACIRI, Berkeley CA.</tt>
<br><tt>[RK: thanks to Sally Floyd]</tt><tt></tt>
<p><tt>Several people are late, because highway 880 was closed for a while.</tt><tt></tt>
<p><tt>There is a SMUG (Secure Multicast Research Group) meeting here</tt>
<br><tt>tomorrow.</tt><tt></tt>
<p><tt>Intro by Roger:</tt>
<br><tt>[Add a pointer to Roger's viewgraphs.]</tt>
<br><tt>Goals of meeting,</tt>
<br><tt>Overview of agenda.</tt>
<br><tt>Call to Arms:</tt>
<br><tt>Building-Block and Design Space drafts are waiting for review by
Mark.</tt>
<br><tt>Mike: Are we on-schedule with the goals listed in our charter?</tt>
<br><tt>Roger: We are behind schedule.</tt>
<br><tt>The group will standardize building block and protocol instantiation</tt>
<br><tt> documents.</tt><tt></tt>
<p><tt>The Guidelines draft:</tt>
<br><tt>[Add a pointer to Roger's viewgraphs.]</tt>
<br><tt>What is missing from here?</tt>
<br><tt>Mike: What about revision control between the PI (Protocol</tt>
<br><tt> Instantiation) and the BB (Building Blocks) documents?
Do they</tt>
<br><tt> cross-reference each other?</tt>
<br><tt>This comes to the API issue: what parts of the BB documents are</tt>
<br><tt> referenced by the PI documents? The BBs have, not
an API, but</tt>
<br><tt> a higher-level interface description.</tt>
<br><tt>NACK: There is a BB and a PI. How does this work?</tt>
<br><tt>Answer: The BB has the more general stuff. And a NACK PI</tt>
<br><tt> might also use ACK-based stuff.</tt>
<br><tt>Jim: Can we do an example, with PGM?</tt>
<br><tt>BBs should discuss design tradeoffs.</tt>
<br><tt>Building blocks might be more applicable than just bulk transfer,</tt>
<br><tt> though that is our immediate focus.</tt>
<br><tt>Mike: There is a danger of designing a BB without a PI in mind.</tt>
<br><tt>Maybe each PI should write its BBs, and then come together.</tt>
<br><tt>Mark, Sally: For NACK and TRACK, it is clear that there</tt>
<br><tt> is a CC (Congestion Control) BB that can be broken out now,
in</tt>
<br><tt> parallel. For ALC, there might not be as many BBs
that can</tt>
<br><tt> be broken out now.</tt>
<br><tt>FEC is a building block that can be taken out of ALC now.</tt>
<br><tt>What will go in the NACK BB?</tt>
<br><tt>Mike: Maybe the BB role can be more informational.</tt>
<br><tt>>From SMUG: BBs are coarse-grained, and might need more</tt>
<br><tt> fine-grained components within them.</tt>
<br><tt>Mark: BBs should not include all possible options, but should</tt>
<br><tt> narrow down the design space.</tt>
<br><tt>A call for BBs and PIs to start with overviews first, not the</tt>
<br><tt> nitty-gritty details. Out of today, perhaps we can
end up</tt>
<br><tt> with overviews of each of the BBs.</tt><tt></tt>
<p><tt>------------------------------------------------------</tt><tt></tt>
<p><tt>Congestion Control:</tt><tt></tt>
<p><tt>Mark:</tt>
<br><tt>TFRC, Unicast TCP-Friendly Rate Control</tt>
<br><tt>[Add a pointer to Mark's viewgraphs.]</tt>
<br><tt>Pointer to paper: "<A HREF="http://www.aciri.org/tfrc/">http://www.aciri.org/tfrc/</A>".</tt>
<br><tt>The talk shows results from experiments and simulations with TFRC.</tt>
<br><tt>For unicast, the performance is very good.</tt>
<br><tt>Question: Simulations with TFRC: in simulations, TFRC tends to
drop to</tt>
<br><tt> zero with many flows, very high bandwidth? Mark didn't
see this, will</tt>
<br><tt> look at it later.</tt>
<br><tt>Oscillations from smoothing the roundtrip time, and sending at
1/RTT:</tt>
<br><tt> For unicast TFRC, we added RTT-based Congestion Avoidance.</tt>
<br><tt> This is needed more for Drop-Tail than for RED queues, or
for</tt>
<br><tt> high levels of statistical multiplexing.</tt>
<br><tt>Issues for multicast: timely feedback, measuring RTT.</tt>
<br><tt>Question: Does this apply to non-sender-based congestion control?</tt><tt></tt>
<p><tt>Mike Luby:</tt>
<br><tt>The work on CC for ALC is not finalized.</tt>
<br><tt>It is interesting to see if sender-based TFRC schemes will apply</tt>
<br><tt> to receiver-based ALC.</tt>
<br><tt>VRC: [Viziano, Rizzo, Crowcroft], the RLC protocol. Receivers
join</tt>
<br><tt> a layer and all lower-bandwidth layers. Each layer
has twice</tt>
<br><tt> the bandwidth of the previous layer.</tt>
<br><tt>Join times are quick, and leave times might now be quick also.</tt>
<br><tt>In his opinion, the RLC approach has more power than the</tt>
<br><tt> single-source approach.</tt>
<br><tt>For TCP-friendly issues, how does the RTT get taken into account?</tt>
<br><tt>Mark: In small levels of stat mux, increasing the sending
rate can</tt>
<br><tt> dramatically increase the packet drop rate. This is
not the</tt>
<br><tt> case with large-scale stat mux.</tt>
<br><tt>Mike: There is a lot of interesting work to be done.</tt>
<br><tt>Remark: Fine-grained video coding is the coming thing.</tt><tt></tt>
<p><tt>Roger: Is the discussion leading to BBs? Are we going
into</tt>
<br><tt> too much detail?</tt>
<br><tt>Brian: We have a TRACK architecture overview, that shows
how BBs</tt>
<br><tt> fit together.</tt><tt></tt>
<p><tt>TEAR:</tt>
<br><tt>Similar to a TFRC building block. Differs in how to measure
a</tt>
<br><tt> fair TCP throughput.</tt>
<br><tt>TEAR differs from TFRC in the receiver. Instead of using
the</tt>
<br><tt> TCP-friendly equation, TEAR emulates TCP at the receiver.</tt>
<br><tt> Takes a weighted average of eight TCP congestion control</tt>
<br><tt> rounds. TEAR trys to give a more accurate model of
TCP.</tt>
<br><tt>Mark: TEAR is sensitive to the pattern of losses. And
they</tt>
<br><tt> differ in the modeling of retransmit timeouts.</tt><tt></tt>
<p><tt>Shiv Kalyanaraman:</tt>
<br><tt>Generic source-based multicast congestion control.</tt>
<br><tt>[Get a pointer to viewgraphs.]</tt>
<br><tt>This is sender-based congestion control.</tt>
<br><tt>No measurement support from the receiver set, except for NACKS
or ACKS</tt>
<br><tt> that are already there.</tt>
<br><tt>No aggregation support expected in the tree.</tt>
<br><tt>Congestion periods are broken into congestion epochs, which is</tt>
<br><tt> a period with a single rate reduction, with time for the</tt>
<br><tt> rate-reduction to diffuse to the congested sub-tree.</tt>
<br><tt>Mark: He is assuming a very low level of stat mux? He is
assuming that</tt>
<br><tt> if the sending rate is increased, the packet loss rate increases
also?</tt>
<br><tt>The protocol mimics TCP at every point.</tt>
<br><tt>They have implemented this in NS, and they have a PGM implementation.</tt><tt></tt>
<p><tt>----------------------------------------------</tt>
<br><tt></tt> <tt></tt>
<p><tt>-----------------------------------</tt>
<br><tt> RMT Interim Working Group Meeting</tt><tt></tt>
<p><tt> -- Draft Minutes --</tt>
<br><tt> [ RK: thanks to Bob Quinn]</tt><tt></tt>
<p><tt> Feb 10, /2000 - Hosted by Aciri</tt>
<br><tt> at ICSI in Berkeley, CA</tt>
<br><tt>-----------------------------------</tt><tt></tt>
<p><tt>Roger Kermode, RMT working group co-chair, started the meeting</tt>
<br><tt>at AM with 18 people present (we had 28 by 11AM) with a review</tt>
<br><tt>of the agenda.</tt><tt></tt>
<p><tt>Tentative Agenda</tt>
<br><tt>---------------------------------</tt>
<br><tt>09:00 - 09:10 10 mins Agenda Bashing</tt>
<br><tt>
[Roger]</tt>
<br><tt>09:10 - 09:10 10 mins WG status update</tt>
<br><tt>
bb + ds drafts</tt>
<br><tt>
Recharter</tt>
<br><tt>09:10 - 09:20 10 mins Call to arms/editorship
selection update</tt>
<br><tt>
[Roger]</tt>
<br><tt>09:20 - 09:40 40 mins Guidelines Draft
Update/Discussion</tt>
<br><tt>
[Roger/Lorenzo/Allison]</tt>
<br><tt>
10 mins draft outline</tt>
<br><tt>
30 mins discussion</tt>
<br><tt>10:00 - 11:20 1hr20mins Congestion Control: [Handley/Flloyd?]</tt>
<br><tt>
10 mins TFMCC update [Handley/Flloyd]</tt>
<br><tt>
10 mins ALC implications for CC [Luby]</tt>
<br><tt>
10 mins TEAR implications for CC [Rhee]</tt>
<br><tt>
10 mins Generic source-based multicast CC</tt>
<br><tt>
[Kalyanaraman]</tt>
<br><tt>
40 mins discussion</tt>
<br><tt>11:20 - 12:20 1hr
NACK: [Bormann & Adamson?]</tt>
<br><tt>
10 mins BB Update [Borman]</tt>
<br><tt>
20 mins BB Discussion</tt>
<br><tt>
10 mins PI Update [Adamson]</tt>
<br><tt>
20 mins PI Discusion</tt>
<br><tt>12:20 - 13:00 1hr
Lunch</tt>
<br><tt>13:00 - 14:00 1hr
Asynchronous Layered Coding: [Luby]</tt>
<br><tt>
10 mins BB update</tt>
<br><tt>
10 mins Gemmell?</tt>
<br><tt>
40 mins discussion</tt>
<br><tt>14:00 - 14:30 1hr
Tree-Building: [??]</tt>
<br><tt>
10 mins table of contents update [Chiu]</tt>
<br><tt>
20 mins discussion</tt>
<br><tt>14:30 - 16:00 1hr
TRACK progress [Whetten/Chiu]</tt>
<br><tt>
10 mins [Whetten]</tt>
<br><tt>
10 mins [Chiu]</tt>
<br><tt>
40 mins Discussion</tt>
<br><tt>16:00 - 16:45 45 mins VACANT</tt>
<br><tt>16:45 - 17:00 15 mins Agenda bashing for
Adelaide</tt><tt></tt>
<p><tt>RMT has been rechartered and the new charter--now approved</tt>
<br><tt>by IESG--is in place on the RMT working group webpage.</tt>
<br><tt><A HREF="http://www.ietf.org/html.charters/rmt-charter.html">http://www.ietf.org/html.charters/rmt-charter.html</A></tt>
<br><tt>Mark Handley showed the new charter as it appears on</tt>
<br><tt>the RMT working group webpage.</tt><tt></tt>
<p><tt>Roger provided status for the existing documents. The charter</tt>
<br><tt>is agressive and we are a bit behind at this point. Many
of</tt>
<br><tt>the documents are essentially done (though most are not issued</tt>
<br><tt>as Internet Drafts (I-D). Generic Router Assist (GRA) is
the</tt>
<br><tt>only exception. The Multicast Congestion Control document
is</tt>
<br><tt>due for Apri--after Addelaide--and it is acknowledged as the</tt>
<br><tt>most difficult problem, and the one that gates all others.</tt><tt></tt>
<p><tt>Mike Luby asked whether we expect to be doing work on both the</tt>
<br><tt>BBs or the instantiations, and Roger said, "Yes, both."</tt><tt></tt>
<p><tt>The Building Block (BB) Guidelines draft has been stalled.</tt>
<br><tt>That is likely a source of confusion, since many people may not</tt>
<br><tt>know how to proceed with creating a BB I-D without it. The
idea</tt>
<br><tt>behind the BB is tp create some framework definitions for Reliable</tt>
<br><tt>multicast transport (RMT) that exist for Real-Time Protocol (RTP)</tt>
<br><tt>format.</tt><tt></tt>
<p><tt>Goal: to help people write Building Block (BB)</tt>
<br><tt>and Protocol Instantiation (PI) drafts</tt>
<br><tt>- How BBs and PIs fit together</tt>
<br><tt>- Sections to be included:</tt>
<br><tt> + applicatiblity statement</tt>
<br><tt> = where to use and where NOT to use</tt>
<br><tt> = known failure modes</tt>
<br><tt> + BB:</tt>
<br><tt> = bunctional description</tt>
<br><tt> = abstract API for use by other BBs</tt>
<br><tt> + PI (protocol instantiation):</tt>
<br><tt> = core functionality not in BBs</tt>
<br><tt> = which BBs are used</tt>
<br><tt> = how they fit together</tt>
<br><tt> = packet formats</tt><tt></tt>
<p><tt>Mark Handley and Sally Floyd (MH and SF): PI needs to be</tt>
<br><tt>specific about the application targets</tt>
<br><tt>- the PI *may* have some mechanisms that BB doesn't</tt>
<br><tt> (but not all will)</tt><tt></tt>
<p><tt>Joe Macker (JM): The BB should describe the trade-offs</tt><tt></tt>
<p><tt>MH: Some BBs will be more generic as far as being applicable</tt>
<br><tt>to bulk file transfer alone, and others will not.</tt><tt></tt>
<p><tt>Mike Luby (ML): doing the BB first and the PI second seems</tt>
<br><tt>backwards. It would be better to do the PI, then try to</tt>
<br><tt>derive the commonalities that represent the BB.</tt><tt></tt>
<p><tt>MH: We alread have a lot of existing protocols that we</tt>
<br><tt>understand very well.</tt><tt></tt>
<p><tt>ML: But are these written down?</tt><tt></tt>
<p><tt>Roger Kermode (RK): Our hope is that people that have the</tt>
<br><tt>experience with specific protocols need to exchange their</tt>
<br><tt>experiences.</tt><tt></tt>
<p><tt>ML: But again, it is written down?</tt><tt></tt>
<p><tt>MH: We may well do some back-tracking after the fact, but</tt>
<br><tt>we expect that.</tt><tt></tt>
<p><tt>ML: I think it is important to do the PI first and write it</tt>
<br><tt>down.</tt><tt></tt>
<p><tt>MH: I think that ALC may be one where that is true</tt><tt></tt>
<p><tt>ML: Why is that?</tt><tt></tt>
<p><tt>SF: Because there are lots of TRACK and NACK based protocols</tt>
<br><tt>for which we understand the commonalities so it makes a lot</tt>
<br><tt>of sense to do the BBs in parallel with PIs.</tt><tt></tt>
<p><tt>Jim Gemmel (JG): I'm fuzzy about what goes into a BB, is it</tt>
<br><tt>going to simply say what NAK does or list many different</tt>
<br><tt>ways it could work.</tt><tt></tt>
<p><tt>MH: I think that NAK will have suppression mechanisms built</tt>
<br><tt>into it.</tt><tt></tt>
<p><tt>JG: Are you going to list the mechanisms/algorithms?</tt><tt></tt>
<p><tt>MH: We need to pick one and describe it.</tt><tt></tt>
<p><tt>JG: But there are so many</tt><tt></tt>
<p><tt>ML: You pick one and it may not be appropriate in all cases.</tt><tt></tt>
<p><tt>Thomas Hardjono (TH): In SMuG we have picked a number of them</tt><tt></tt>
<p><tt>RK: We are obviously still struggling with what a BB is, so</tt>
<br><tt>I tend to agree with Mike that we should concentrate on a PI</tt>
<br><tt>first.</tt><tt></tt>
<p><tt>??: I thought that the BB was supposed to describe what we</tt>
<br><tt>recommend with Interet health as the focus.</tt><tt></tt>
<p><tt>SF: It is a good idea to have things that refer to Internet</tt>
<br><tt>health, but we already have RFC 2357 (?) that describes the</tt>
<br><tt>requirements for any RM transport.</tt><tt></tt>
<p><tt>RK: I think we are approaching some concensus.</tt><tt></tt>
<p><tt>JG: Go write one and lets take a look at it</tt><tt></tt>
<p><tt>??: Suggested that we have an overview and functionality</tt>
<br><tt>description for each BB *first* then move into the other</tt>
<br><tt>details</tt><tt></tt>
<p><tt>---</tt>
<br><tt>TFRC - TCP-Freindly rate control
Mark Handley</tt>
<br><tt>(Equation based congestion control)</tt><tt></tt>
<p><tt>- we thought we understood this (for unicast) a year ago,</tt>
<br><tt>but we did not and we don't know multicast yet.</tt><tt></tt>
<p><tt>Scripts and paper all available at <A HREF="http://www.aciri.org/tfrc">http://www.aciri.org/tfrc</A></tt><tt></tt>
<p><tt>It is fair to TCP in general, although we have seen TCP</tt>
<br><tt>get beat up because it was too bursty</tt><tt></tt>
<p><tt>Key measures are loss fraction and round trip time</tt><tt></tt>
<p><tt>Measuring round trip time, there are oscillations in TCP</tt>
<br><tt>and with multicast the delays between these is longer.</tt><tt></tt>
<p><tt>To dampen oscillations but still gain RTT-based congestion</tt>
<br><tt>avoideance behavior, need inverse dependence on RTT but</tt>
<br><tt>lower gain. <<see equation>> The result of this
is a</tt>
<br><tt>smoothing of the oscilllations.</tt><tt></tt>
<p><tt>- If you fix the RTT time, you get the oscillations, but</tt>
<br><tt> if you don't (as described above) then they are smoothed.</tt><tt></tt>
<p><tt>- we've tried these things with a wide variety of Queuing</tt>
<br><tt> congestion control mechmanisms, and it works well with</tt>
<br><tt> all (though having RED reduces the need for this mechansism).</tt><tt></tt>
<p><tt>Issues for Multicast</tt>
<br><tt>- how to ensure timely feeback? Delay reporting loss event</tt>
<br><tt> fraction may affect dynamics</tt>
<br><tt>- How to measure RTT to all receivers quickly? Not a showstopper,</tt>
<br><tt> but may affect how CCC fits together with other components</tt>
<br><tt>- RTT-based Congestion Avoidance is difficult (referring to</tt>
<br><tt> the algorithm described above): It is not clear that this
is</tt>
<br><tt> necessary, but the consequences of not doing it are not
yet</tt>
<br><tt> fully understood.</tt><tt></tt>
<p><tt>??: What is the traffic load for reporting congestion control?</tt><tt></tt>
<p><tt>MH: You really want your NACK or ACK trafffic to report it,</tt>
<br><tt>and with aggregation points (TRACK or other local/shared</tt>
<br><tt>recovery points) you have additional delay. None of this</tt>
<br><tt>applies to ALC though, of course (since it is one-way).</tt><tt></tt>
<p><tt>ML: Yes, but reading through your paper I got the impression</tt>
<br><tt>that a lot of it is based on the receiver, so it could well</tt>
<br><tt>be applicable.</tt><tt></tt>
<p><tt>ML: If you actually did an experiment with two TCPs then they</tt>
<br><tt>would not be fair to each other. The one that has longer</tt>
<br><tt>timeout (say 10 times) would be 100 times more loss.</tt><tt></tt>
<p><tt>SF: I don't believe that loss rate would be 10 times more</tt><tt></tt>
<p><tt>Brian Whetten (BW): I don't beleive it would be, either.</tt><tt></tt>
<p><tt>JM: What about slow-start mechanism for multicast?</tt><tt></tt>
<p><tt>MH: We may not need one for multicast since the advantage</tt>
<br><tt>of having one is not clear yet.</tt><tt></tt>
<p><tt>----</tt>
<br><tt>Asynchronous Layered Coding (ALC) BB
Mike Luby</tt><tt></tt>
<p><tt>The work on ALC CC is not finalized yet, though there has</tt>
<br><tt>been some great work done so far.</tt><tt></tt>
<p><tt>- thing about ALC is that you can have different receivers</tt>
<br><tt> receiving at different rates (determined by the number</tt>
<br><tt> of groups they have joined, and streams they are receiving</tt>
<br><tt> in parallel) and we need to take advantage of it.</tt><tt></tt>
<p><tt>- VRC (authors Lorenzo V. , R. and Crowcroft mechanism</tt>
<br><tt> is used for this (also referred to as RLC for author names</tt>
<br><tt> also ...for some unknown reason).</tt><tt></tt>
<p><tt>- Synchronization points happen more often at the lower</tt>
<br><tt> layers than at the upper layers. Layers are cumulative.</tt><tt></tt>
<p><tt>It is now a very course-grained CC, and we should make it</tt>
<br><tt>more fine-grained (more fine-grained than the synch points</tt>
<br><tt>can provide). Current one gives a linear increase.</tt><tt></tt>
<p><tt>SF: A factor involved with whether you couild ramp up send</tt>
<br><tt>rater slowly is whether you have either small or large-scale</tt>
<br><tt>statistical multiplexing.</tt><tt></tt>
<p><tt>Hayder Radha (HR): ALC sounds much like MPEg-4, which provides</tt>
<br><tt>fine-grained scalability and uses many different multicast</tt>
<br><tt>groups (roughly 10-20).</tt><tt></tt>
<p><tt>--</tt>
<br><tt>Short talk on TEAR
Rhee</tt><tt></tt>
<p><tt>- TFRC uses equations looking at 8 loss events that have</tt>
<br><tt> occurred and is based on what it finds from the sender,</tt>
<br><tt> whereas TEAR emulates TCP within the receiver and how.</tt><tt></tt>
<p><tt>MH: TEAR is sensitive to the pattern of losses (which</tt>
<br><tt>may be good or bad) and sensitive to the timeouts.</tt><tt></tt>
<p><tt>--</tt>
<br><tt>Generic Source-Based Mcast Congewstion Control</tt>
<br><tt>Shivkumar Kalyanaraman (RPI) <<missed the URL>></tt><tt></tt>
<p><tt>- implosion control needed</tt>
<br><tt>- need timing info on Sender & Reciever (may need GPS at</tt>
<br><tt> receivers)</tt>
<br><tt>- Need to know the (S,G) state</tt><tt></tt>
<p><tt>"Generic" means</tt>
<br><tt>- completely implemented at the source</tt>
<br><tt>- no measurement support from receivers</tt>
<br><tt>- no extra contol traffic inserted</tt>
<br><tt>- no extra fields</tt>
<br><tt>- no aggregation support expected</tt>
<br><tt>- should work with NAKs, HACKs, ACKs, bit maps or other</tt>
<br><tt> reverse traffic which provides congestion and timing</tt>
<br><tt> information</tt><tt></tt>
<p><tt>Weak requirements on RTT & loss estimation:</tt>
<br><tt> - suppress NAKs from long RTTs (partial timing info)</tt><tt></tt>
<p><tt>Basic idea is that they devide congestion time periods</tt>
<br><tt>into "epochs" where the source reduces the send rate</tt>
<br><tt>exactly once and enough time is given for rate-reduction</tt>
<br><tt>to diffuse throughout the congested sub-tree.</tt><tt></tt>
<p><tt>They do not depend on the loss rate.</tt><tt></tt>
<p><tt>They have implemented it in their version of PGM.</tt><tt></tt>
<p><tt>MH: Seems like you are not depending on having large-scale</tt>
<br><tt>statistical multiplexing rate and that assumes that the</tt>
<br><tt>competing flows are doing the same thing, which is a flawed</tt>
<br><tt>assumption.</tt><tt></tt>
<p><tt>--</tt>
<br><tt>Brian Whetten said he has done a description of how the</tt>
<br><tt>BBs fit together from the perspective of TRACK.* reliability</tt><tt></tt>
<p><tt>======</tt>
<br><tt>short break</tt>
<br><tt>======</tt><tt></tt>
<p><tt>RK: This is a new process we've been doing with the BB approach,</tt>
<br><tt>so we need to describe it in more detail.</tt><tt></tt>
<p><tt>Boorman: The BB needs to be normative, we need to have it as</tt>
<br><tt>something that people can reference as opposed to something</tt>
<br><tt>that is not</tt><tt></tt>
<p><tt>BW: It should have exact algorithms and abstract APIs</tt><tt></tt>
<p><tt>SF: BBs need to describe design tradeoffs required for Application-</tt>
<br><tt>specific variations (e.g. optional feedback).</tt><tt></tt>
<p><tt> Single Rate CC BB Team:</tt>
<br><tt> Mark H (leader), Sally F., Injong, Brian W., Shiv,
Supratek, Hursel,</tt>
<br><tt> Joe Macker, Brian A.</tt><tt></tt>
<p><tt> MultiRate CC BB Team:</tt>
<br><tt> Mike L (leader), Lorenzo, Hayder, Injong, Jim Gemmel,
Luigi Rizzo,</tt>
<br><tt> Jon Crowcroft</tt><tt></tt>
<p><tt>??: I come from a satellite company and I'd like to see some</tt>
<br><tt>satellite-specific considerations described.</tt><tt></tt>
<p><tt>RK: We deal with the Big 'I' Internet and this includes the</tt>
<br><tt>satellite media, so it is included implicitly.</tt><tt></tt>
<p><tt>MH: It looks like Single Source multicast (e.g. PIM Source Only)</tt>
<br><tt>will have an earlier deployment than others so it is likely that</tt>
<br><tt>we will have one-way links as well as two-way, so in that context</tt>
<br><tt>satellite is not that special despite the fact it has a long fat</tt>
<br><tt>pipe (long delay and high bandwidth capacity).</tt><tt></tt>
<p><tt>RK: Can we have a document by Adelaide on Single Rate, Mark?</tt><tt></tt>
<p><tt>MH: Yes, we can have a *start* on a document. We need at least</tt>
<br><tt>a first pass of *every* building block by that time.</tt><tt></tt>
<p><tt>RK: The due date for drafts is March 10 and we should really</tt>
<br><tt>strive to have something done by this time.</tt><tt></tt>
<p><tt>MH: We should also submit the names to the RFC editor beforehand</tt>
<br><tt>so it doesn't get delayed (we should do this on the mailing list).</tt><tt></tt>
<p><tt>RK: Ok, will do.</tt><tt></tt>
<p><tt>MH: Should we have discussions in sub-groups or on the main RMT</tt>
<br><tt>mailing list. <<A number of people responded that they
would</tt>
<br><tt>prefer having this traffic on the main RMT mailing list>></tt><tt></tt>
<p><tt><<begin from whiteboard>></tt>
<br><tt>CC Building Block Guidelines</tt>
<br><tt>-----------------------------</tt>
<br><tt>Must be normative - exact specific algorithms and abstract APIs</tt><tt></tt>
<p><tt>Discussions of tradeoffs - application specific variations (e.g.</tt>
<br><tt>optional feedback). Cover design space.</tt><tt></tt>
<p><tt>Purpose: RFC 2357 and Sally Floyd's Congestion Control Principles</tt>
<br><tt>draft, see <A HREF="http://www.aciri.org/floyd/papers/draft-floyd-cong-01.txt">http://www.aciri.org/floyd/papers/draft-floyd-cong-01.txt</A></tt>
<br><tt> + 2 parts:</tt>
<br><tt> = Mandatory to satisfy IESG reqs</tt>
<br><tt> = Application specific</tt><tt></tt>
<p><tt>Requirements for other BBs:</tt>
<br><tt> - what messages can be piggy-backed (existing BB msgs and</tt>
<br><tt> additional msgs) .</tt>
<br><tt> - loss detection</tt>
<br><tt> - RTT measurement</tt><tt></tt>
<p><tt>Two Separate BBs:</tt>
<br><tt> -> single source (e.g., PIM-SO)</tt>
<br><tt> -> Others (single rate)</tt>
<br><tt> - satellite, asymmetric, wireless,</tt><tt></tt>
<p><tt>GRA Considerations</tt><tt></tt>
<p><tt>target scale (in terms of number of receivers).</tt>
<br><tt><<end from whiteboard>></tt><tt></tt>
<p><tt>---</tt>
<br><tt>How TRACK fits with other BBs
Brian Whetten</tt>
<br><tt>(( his view of what needs to go into BBs ))</tt><tt></tt>
<p><tt>Goals</tt>
<br><tt>- functional decomposition across other BBs</tt>
<br><tt>- sees TRACK as a superset of NACK</tt><tt></tt>
<p><tt>Exponential back-off on loss detection</tt><tt></tt>
<p><tt>Unicast NACK generation</tt>
<br><tt> - issue: NACK needs multicast NACKS?</tt><tt></tt>
<p><tt>response to retransmission request</tt>
<br><tt>GRA signaling</tt>
<br><tt>Integration with TRACK hierarchy</tt>
<br><tt> - how do you do this well</tt><tt></tt>
<p><tt>SF: Why is this included here?</tt><tt></tt>
<p><tt>BW: We repeat it in both places</tt><tt></tt>
<p><tt>Question: Since it is a superset of NACK, why have a separate BB?</tt><tt></tt>
<p><tt>BW: Interesting thought.</tt><tt></tt>
<p><tt>MH: We need to do suppression so the question is how to do it.</tt>
<br><tt>You can do it by a tree or not, so the discussion needs to talk</tt>
<br><tt>about it with that focus</tt><tt></tt>
<p><tt>MH: One thing missing here is how it interacts with and uses FEC.</tt><tt></tt>
<p><tt>Lorenzo Vicanso (LV): Yes, FEC is very mixed with suppression.</tt><tt></tt>
<p><tt>MH: FEC itself is not in there, but a description of its</tt>
<br><tt>functionality is.</tt><tt></tt>
<p><tt>??: Why do you call it NACK when it should really be a generic</tt>
<br><tt>feedback mechanism?</tt><tt></tt>
<p><tt>BW: We have differentiated the feedback (for CC) and the</tt>
<br><tt>NACK for data loss and the TRACK since it has to deal with</tt>
<br><tt>hierarchy.</tt><tt></tt>
<p><tt>Brad Cain: What do you think the biggest issue is?</tt><tt></tt>
<p><tt>BW: The issue of how and when you deal with the NACKs.</tt><tt></tt>
<p><tt>FEC BB:</tt>
<br><tt>- input of a (sub) window of data packets</tt>
<br><tt> + issue: packet nameing</tt>
<br><tt>- creating parity packet</tt>
<br><tt> + issue: exhaustion of parity packets</tt>
<br><tt> + proactive parity (which block owns it)?</tt>
<br><tt>- flush data stream with only a small sub-window</tt>
<br><tt>- FEC decode</tt>
<br><tt>- Bind to different codecs</tt><tt></tt>
<p><tt>LV: It seems that some of these issues (like flush) belong</tt>
<br><tt>in the protocol instantiation.</tt><tt></tt>
<p><tt>BW: This is a highlight of the functions and not specifications</tt>
<br><tt>of what they are doing</tt><tt></tt>
<p><tt>ML: I would just talk about the protocol and not how it will</tt>
<br><tt>work in all protocol instantiations. That cannot work.</tt><tt></tt>
<p><tt>RK: The model to look at for this framework is RTP, where</tt>
<br><tt>there is enough generality to allow a common, versatile</tt>
<br><tt>framework.</tt><tt></tt>
<p><tt>LV: You need an API for making state available</tt><tt></tt>
<p><tt>ML: There is a way to describe FECs in general without going</tt>
<br><tt>into detail with exactly how to use them.</tt><tt></tt>
<p><tt>??: This has actually been done in the AVT RFCs that deal</tt>
<br><tt>with codecs (may still be I-Ds at this point). They may not</tt>
<br><tt>be exact, but it is a good thing to start with.</tt><tt></tt>
<p><tt>LV: You can define blocks and when you can reveal the blocks</tt>
<br><tt>and deal with them.</tt><tt></tt>
<p><tt>TFMCC BB:</tt>
<br><tt>- Initialization</tt>
<br><tt>- Receiver measuraments</tt>
<br><tt> + issue: RTT measurements</tt>
<br><tt>- Receiver feedback (on TRACK/NACK)</tt>
<br><tt> + Issue: how to bias NACK timers?</tt>
<br><tt>- hierarchical aggregation</tt>
<br><tt>- sender rate control</tt><tt></tt>
<p><tt>MH: There's no requirement for interoperability until you get</tt>
<br><tt>into a PI. The packet formats are defined in terms of funcionatlity</tt>
<br><tt>rather than generically as "feedback" to be efficient in terms
of</tt>
<br><tt>size used.</tt><tt></tt>
<p><tt>GRA BB (draft-ietf-rmt-gra-arch-00.txt):</tt>
<br><tt>- Core, simple router functionality</tt>
<br><tt> + issue: how to instantiate this?</tt>
<br><tt>- signaling guidelines</tt>
<br><tt>- NACK</tt><tt></tt>
<p><tt>Brad Cain (co-author): we will have a separate document that will</tt>
<br><tt>include feedback mechanism defined and we will define packet</tt>
<br><tt>format. It will be incrementally deployable (as spec already</tt>
<br><tt>says). We will be dealing with server-to-server traffic,
which</tt>
<br><tt>is the auto-tree configuration.</tt><tt></tt>
<p><tt>Auto-Tree Configuration BB:</tt>
<br><tt>- Discover hierarchy that matches the multicast topology</tt>
<br><tt>- works in all environments</tt>
<br><tt>- provides children with an address list of candidates</tt>
<br><tt> + if/when first fails you go to second one</tt><tt></tt>
<p><tt>BC: You need to discover namers, create hierarchy (some sort</tt>
<br><tt>of routing protocols where you abstract away who is closest</tt>
<br><tt>to the root).</tt><tt></tt>
<p><tt>JM: Is this going to be a routing-ish shared tree?</tt><tt></tt>
<p><tt>BC: We are not doing that level of detail ...we are not creating</tt>
<br><tt>PIM over a mesh. Once you abstract away what a possible root</tt>
<br><tt>could be (source, RP, etc.), then there has to be a route from</tt>
<br><tt>whatever it is. Then that has to be...??? I wouldn't
touch that</tt>
<br><tt>one with a ten-foot pole. There will be packets between servers,</tt>
<br><tt>and there will need to be a way to measure distance between server</tt>
<br><tt>to source and you can do that LOTS of different ways. You
need</tt>
<br><tt>to know what the metric means.</tt><tt></tt>
<p><tt>BW: Yes, I agree that the problem is not yet well defined</tt><tt></tt>
<p><tt>======</tt>
<br><tt>lunch break</tt>
<br><tt>======</tt><tt></tt>
<p><tt><< Brian Whetten, on TRACK BB Requirements, continued >></tt><tt></tt>
<p><tt>Common Packet Headers</tt>
<br><tt>- Data Naming</tt>
<br><tt> + sequence number, FEC offset</tt>
<br><tt> + issues: Add object ID? Need sequential packet numbering.</tt>
<br><tt> Need to support application level multicast</tt>
<br><tt>- Session naming</tt>
<br><tt> + stream ID</tt>
<br><tt> + TRACK may need a Tree ID</tt>
<br><tt>- Also issues with Application Level Framing (Talarian,</tt>
<br><tt> TIBCO and FastForward are three examples), since you are</tt>
<br><tt> multiplexing at a different level</tt><tt></tt>
<p><tt>MH: There seems to be three sequence spaces:</tt>
<br><tt> - packets within FEC block</tt>
<br><tt> - FEC blocks themselves</tt>
<br><tt> - Object ID itself</tt><tt></tt>
<p><tt> You might be able to build over to create frames over</tt>
<br><tt> that, but it must be at the object level to get reliability.</tt>
<br><tt> I think it might be worthwhile to go down this path to see</tt>
<br><tt> what comes out, what meta-information we need.</tt><tt></tt>
<p><tt>BW: The other consideration that is important is the number</tt>
<br><tt>of bits we add to support this.</tt><tt></tt>
<p><tt>MH: My view on bits is don't worry about it, since it is only</tt>
<br><tt>on low-bandwidth links that it is a concern</tt><tt></tt>
<p><tt>Security BB</tt>
<br><tt>- Really SMuG's area and our area</tt>
<br><tt>- Transports only job is to protect itself</tt>
<br><tt>- Interface to key managerment is what we need</tt>
<br><tt>- IPSec for lightweight version</tt><tt></tt>
<p><tt>TRACK functions</tt>
<br><tt>- hierarchy creation and maintenance</tt>
<br><tt> + join, leave, falure recovery, keepalives</tt>
<br><tt> + local multicast groups for control, retransmission</tt>
<br><tt>- parameter initializeation/distribution</tt>
<br><tt> + server and tree-wide</tt>
<br><tt>- source ordered, unordered, time bounded (?)</tt>
<br><tt>- network management</tt><tt></tt>
<p><tt>JM: Is there a new security consideration for ACK Aggregation</tt><tt></tt>
<p><tt>TH: At last IETF I talked about a mechanism whereby an intermediate</tt>
<br><tt>point that received a NACK would have to forward them upstream</tt>
<br><tt>for signing (so intermediate point does not need to be a trusted</tt>
<br><tt>participant). Authentication and trust models are the issues.</tt><tt></tt>
<p><tt>LV: The NACK authentication is an end-to-end issue</tt><tt></tt>
<p><tt>TH: Yes, but NACKS are from routers</tt><tt></tt>
<p><tt>BW: Routers don't issue NACKs, however. Routers create the
tree</tt>
<br><tt>(for TRACK).</tt><tt></tt>
<p><tt>MH: Tree-based protocols help you to generate round trip times.</tt><tt></tt>
<p><tt>TRACK Issues</tt>
<br><tt>- Kill TN and Aggregators?</tt>
<br><tt> + shared tree versus per-source tree?</tt>
<br><tt>- Can we have dynamic DR/receivers</tt>
<br><tt>- Multicast address sharing</tt><tt></tt>
<p><tt>BW: Is top of the tree always co-located with the sender?</tt><tt></tt>
<p><tt>MH: There are lots of different ways to build trees</tt><tt></tt>
<p><tt>BW: You can have multiple data sources for a single tree</tt><tt></tt>
<p><tt>BC: It would be good if anyone desiging NACKs talk to</tt>
<br><tt>him and BL about how to define them for each of the</tt>
<br><tt>BB type (e.g. NACK, TRACK, ALC), specifically in terms</tt>
<br><tt>of application interface and packet formats.</tt><tt></tt>
<p><tt>======</tt>
<br><tt>We then had break-out meetings for separate sub-groups:</tt>
<br><tt>"ALC", ""NACK," and "Tree Building" (in quotes since these</tt>
<br><tt>are very loosely defined). Here are the topics discussed:</tt><tt></tt>
<p><tt>"ALC":</tt>
<br><tt> - FEC</tt>
<br><tt> - PI for ALC</tt>
<br><tt> - Congestion Control</tt><tt></tt>
<p><tt>"NACK":</tt>
<br><tt> - PI versus BB</tt>
<br><tt> - NACK</tt>
<br><tt> - Congestion Control</tt><tt></tt>
<p><tt>"Tree Building"</tt>
<br><tt> - Auto Tree config</tt><tt></tt>
<p><tt>=========</tt>
<br><tt> Wrap Up</tt>
<br><tt>=========</tt>
<br><tt>Roger Kermode on Auto-Tree Creation BB discussion:</tt>
<br><tt>- Preconfigured solution</tt>
<br><tt> + assumes the existence of a mesh of delivery servers</tt>
<br><tt> (which may be statically configured or dynamically</tt>
<br><tt> generated):</tt>
<br><tt> + requires existing infrastructure on internal nodes</tt><tt></tt>
<p><tt>- Ad hoc solution</tt>
<br><tt> + does not require predeployment</tt>
<br><tt> + assumes mesh discovery protocol</tt>
<br><tt> + no GRA</tt>
<br><tt> + no TTL scoping (needs to support PIM_SO)</tt>
<br><tt> + no static config info in hosts</tt><tt></tt>
<p><tt>MH: Do you have any reference implementations for these models?</tt>
<br><tt>I'd like to see some running code.</tt><tt></tt>
<p><tt>Mike Luby on ALC:</tt>
<br><tt> - we had lots of concensus and progress</tt>
<br><tt> - We also took on the FEC BB</tt><tt></tt>
<p><tt>TRACK:</tt>
<br><tt> - what identifies a source or a receiver?</tt><tt></tt>
<p><tt>NACK:</tt>
<br><tt> - We also discussed FEC a lot too since it is tied in</tt><tt></tt>
<p><tt>Rather than having different mailing lists for each subgroup,</tt>
<br><tt>Roger proposed that everything go to RMT and we preface subjects</tt>
<br><tt>with what the topic is relevant to (and add "PI" as a suffix if</tt>
<br><tt>that's the topic) FEC, TREE, ALC, NACK, CONG_{SR | MR}, TRACK,</tt>
<br><tt>GRA, or GUIDE. He will send a message to the RMT mailing
list</tt>
<br><tt>describing this.</tt><tt></tt>
<p><tt><<end>></tt>
<br><tt></tt>
<br><tt></tt>
<br><tt></tt> <tt></tt>
<p><tt>=========================================</tt>
<br><tt> Notes from TRACK sub-group Discussions</tt>
<br><tt> RMT Working Group Meeting 2/6/00</tt>
<br><tt>=========================================</tt>
<br><tt>blame bob quinn <rcq@stardust.com> for any innaccuracies</tt><tt></tt>
<p><tt>Motivation for creating a tree</tt>
<br><tt>- Good for error control and congestion control</tt>
<br><tt>- Distributed aggregation (caching hierarchies, e.g., for</tt>
<br><tt> use in a Content Distribution Network (CDN))</tt>
<br><tt>- Anycast</tt>
<br><tt>- Security, group key management</tt>
<br><tt>- Distributed gaming/simulations</tt><tt></tt>
<p><tt>All have similar requirements</tt><tt></tt>
<p><tt>Why is it useful?</tt>
<br><tt>1) hierarchical construction assists with load balancing</tt>
<br><tt>2) topologically aware aggregation</tt>
<br><tt>3) topologically aware subcasting</tt><tt></tt>
<p><tt>First is sufficient (2nd and 3rd are efficient).</tt><tt></tt>
<p><tt>Why by aware of topography?</tt>
<br><tt>- topologically based structures have dramatic performance benefits</tt>
<br><tt> + localized aggregation</tt>
<br><tt> + subcasts that are focused towards downstream logical descendants</tt>
<br><tt> + allow use of subcast, period.</tt>
<br><tt> + ensures reduced latency between pairs</tt><tt></tt>
<p><tt>Applications</tt>
<br><tt>- local aggregation</tt>
<br><tt> + error, congestion control, CDN, security</tt>
<br><tt>- focused subcasts</tt>
<br><tt> + error, congestion, security</tt>
<br><tt>- reduced latency between pairs</tt>
<br><tt> + gaming, anycast</tt><tt></tt>
<p><tt>BW: So is the goal topological congruency?</tt>
<br><tt>Brian Levine (BL): Yes</tt>
<br><tt>BW: Would anyone debate that?</tt>
<br><tt>BL: yes. You can't do it now without difficulty, but that</tt>
<br><tt> does not mean it is not something we should *try* to do.</tt>
<br><tt>BC: That is something we should strive for.</tt>
<br><tt>BW: There are some that would say it is better for error</tt>
<br><tt> control</tt>
<br><tt>BL: I don't agree with that</tt>
<br><tt>BW: I just want to talk about it since it is relevant to</tt>
<br><tt> asymmetric routing, among other thigns.</tt>
<br><tt>BC: That is a really tricky issue and the other reason</tt>
<br><tt> is inter-domain</tt>
<br><tt>BW: Exactly, which is why single-AS is going to rule</tt>
<br><tt>BC: Exactly.</tt>
<br><tt>BW: Should we scope it to a single domain?</tt>
<br><tt> <general disagreement></tt><tt></tt>
<p><tt>"Easy" way to do topo-aware</tt>
<br><tt>- use GRA!!</tt>
<br><tt>- Source periodically multicast packets with GRA and</tt>
<br><tt> router alert (MD5 Auth)</tt>
<br><tt> + They go down the tree from a parent</tt>
<br><tt> + I'm assuming we are doing Express mode stuff</tt>
<br><tt>- GRA routers with their IP address in the payload of</tt>
<br><tt>the packet (perhaps both in and out interfaces ...?)</tt>
<br><tt> + Each hop adds as packet traverses</tt>
<br><tt> + As there are more routers, you get a better idea</tt>
<br><tt>- Receivers subcast from last revised router announcing</tt>
<br><tt> their path strings</tt>
<br><tt>- Receivers pick parents, send unicast to confirm</tt>
<br><tt>- Or...new mtrace messages (added by Brad Cain)</tt>
<br><tt> + This would trace down the tree (though we have not</tt>
<br><tt> yet figured out the format ...though many don't like</tt>
<br><tt> mtrace since it gathers statistics, has latency and</tt>
<br><tt> adds overhead)</tt><tt></tt>
<p><tt>??: There was a guy at MCast2000 who said that the hyperqueue</tt>
<br><tt> could build a tree very quickly</tt>
<br><tt>BC: There is part of this that people can use to do other</tt>
<br><tt> tricky things. For example how do you find out how
close</tt>
<br><tt> you are to a source or an intermediate routers and there</tt>
<br><tt> are lots of ways to do it.</tt><tt></tt>
<p><tt>Two problems with finding a metric that's good: congruency</tt>
<br><tt>and how best to announce to the group</tt><tt></tt>
<p><tt>Breaking Up the Problem:</tt>
<br><tt>- Neighbor Discovery</tt>
<br><tt>- routing-like protocol</tt>
<br><tt> + who is closest to the "source" (for mcast)</tt>
<br><tt> + who is closest to other point (e.g. server)</tt>
<br><tt>- How to find distance to server or seoruce?</tt>
<br><tt>- How to make it generic?</tt>
<br><tt> + can we do it for others than reliable multicast, such</tt>
<br><tt> as the content delivery people.</tt>
<br><tt>- Fault tolerance</tt><tt></tt>
<p><tt>BC: Looking at a graph or mesh of servers and over the top</tt>
<br><tt> of that there is some sort of protocol that you use to build</tt>
<br><tt> a hierarchy in the server to server protocol itself.
To do</tt>
<br><tt> so you need to have some sort of metric, such as who is</tt>
<br><tt> closest to data source or RP.</tt><tt></tt>
<p><tt>You discover a set of neighbors within a scope (that's how</tt>
<br><tt>the mesh is built), then over that mesh you establish the</tt>
<br><tt>tree.</tt><tt></tt>
<p><tt>BW: That is basically what we are looking at but that could</tt>
<br><tt> be a heavy weight protocol.</tt><tt></tt>
<p><tt>BC: You can statically configure the mesh (which will most</tt>
<br><tt> often be the case anyway ...that's the way these content</tt>
<br><tt> distribution network guys are doing already).</tt><tt></tt>
<p><tt>RK: We have to be able to exist where GRA doesn't already</tt>
<br><tt> exist.</tt><tt></tt>
<p><tt>BL: If we didn't bring up topological awareness then</tt>
<br><tt> we woudln't have any issue with non-GRA implementations.</tt><tt></tt>
<p><tt>We are being passed-by and need to do *something*:</tt>
<br><tt>- companies can do non-topo aware without us, though</tt>
<br><tt> standards are nice</tt>
<br><tt>- eventually they *will* do topo-aware without us</tt>
<br><tt>- As IETF'ers we should make recommendations</tt><tt></tt>
<p><tt>BW: The barriers to getting GRA into all the routing</tt>
<br><tt> infrastructure is so high that from a practical standpoint</tt>
<br><tt> we should be able to use it without GRA.</tt><tt></tt>
<p><tt>BL: I think it will take 3 years to get GRA widely available</tt>
<br><tt>BW: I think that is really wishful, which is why we should</tt>
<br><tt> think about new mtrace messages.</tt>
<br><tt>BC: The mtrace command needs access control (password, maybe?)</tt>
<br><tt> since it reveals the tree which can be very dangerous.</tt>
<br><tt>RK: If you are going to use mtrace, think about a network</tt>
<br><tt> with 10000 nodes</tt>
<br><tt>BC: MTrace would not scale to that many receivers</tt>
<br><tt>BC: you can try to match receivers with nearest server</tt>
<br><tt> or make tree closest to source. The content delivery
is</tt>
<br><tt> focused on making caches close by to receivers.</tt>
<br><tt>??: Seems a question of how tall you want to make the tree</tt>
<br><tt> with respect to how much fan-out there is (the optimality</tt>
<br><tt> of the tree).</tt>
<br><tt>BC: Yes, that all relates to how you build the tree</tt><tt></tt>
<p><tt> Miriam Kadansky did a doc that relates to requirements</tt>
<br><tt> BL referenced this and created slides from the TOC.</tt><tt></tt>
<p><tt>Dah Ming (DM): How the the tree is formed and then used.</tt>
<br><tt> This was a strawman for generating discussions. We
have</tt>
<br><tt> lots of information about tree optimization and maintenance</tt>
<br><tt> as well as tree building and what I'd like to see is a</tt>
<br><tt> discussion of how much of this belongs in the BB.</tt><tt></tt>
<p><tt>BW: I think only the building of the tree is important.</tt><tt></tt>
<p><tt>BC: I think there should be two layers: a base layer that</tt>
<br><tt> can be useful for a lot of things and the second that is</tt>
<br><tt> specific to reliable multicast.</tt><tt></tt>
<p><tt>RK: Auto-Tree Requirements (RM specific)</tt>
<br><tt>--------------------------</tt>
<br><tt>1) Aggregation of things like ACKs, NACKS, congestion control</tt>
<br><tt>2) Subcasting</tt>
<br><tt> - parent to child unicast (application level)</tt>
<br><tt> - parent to all descendents local multicast group</tt>
<br><tt> - parent to child (GRA)</tt>
<br><tt>3) Others (non-RM specific)</tt>
<br><tt> - group membership</tt>
<br><tt> - list of GRA-capable routers</tt>
<br><tt> - billing</tt><tt></tt>
<p><tt>RK: It has to be spelled-out in the draft what is RM-specific</tt>
<br><tt> and what is not.</tt><tt></tt>
<p><tt>TH: Some mechanisms used to design the tree are exactly the</tt>
<br><tt> same that is needed to deliver some of the services that
the</tt>
<br><tt> tree is supposed to support.</tt>
<br><tt>BW: So, for example, you could use subcast to do auto tree</tt>
<br><tt> configuration.</tt>
<br><tt>TH: Good examplee</tt><tt></tt>
<p><tt>BW: Goals:</tt>
<br><tt> - Perfect topology congruence</tt>
<br><tt> - failing that, do something not stupid</tt>
<br><tt> - list of parents</tt><tt></tt>
<p><tt>BC: Where does the metric fit in? How do you determine a</tt>
<br><tt> "perfect tree?" What does the API give you?</tt>
<br><tt>BW: These are the list of parents and the metric(s). There</tt>
<br><tt> are other interactions to prevent loops (for example).
We</tt>
<br><tt> may be able to pick one metric.</tt>
<br><tt>BL: we should have one metric in mind.</tt>
<br><tt>BC: There are a number of different possibilities.</tt>
<br><tt>RK: You are building a tree to do what, connect sources with</tt>
<br><tt> receivers or with end-points??</tt>
<br><tt>DM: The DR could be either the source or the distribution head.</tt>
<br><tt>BW: The head of the tree is always the source</tt><tt></tt>
<p><tt>BC: the problem is that if you are given just a list of neighbors</tt>
<br><tt> and metrics, then you could construct a tree that has loops.</tt>
<br><tt>BW: I was assuming it was at least an ordered list so there are</tt>
<br><tt> no loops.</tt>
<br><tt>BL: you can always override this, so we must assume that it</tt>
<br><tt> has no loops. Congurence is the goal and besides,
it is not even</tt>
<br><tt> a tree if it has loops.</tt>
<br><tt>DM: There are diffferent ways to make sure you don't have a loop,</tt>
<br><tt>BW: Yes, but if you just know the depth of the tree then this is</tt>
<br><tt> enough information to create a non-looped system.</tt>
<br><tt>DH: That implies the tree is built top-down</tt>
<br><tt>BW: The issue comes down to work</tt>
<br><tt>BC: right.</tt>
<br><tt>BW: Who has to do the job</tt>
<br><tt>BC: The loop protection depends on what info is exchnaged between</tt>
<br><tt> nodes.</tt><tt></tt>
<p><tt>Requirements (according to BW)</tt>
<br><tt>- Universally deployable</tt>
<br><tt> + multi-AS</tt>
<br><tt> + All multicast routing</tt>
<br><tt> + GRA</tt>
<br><tt>- Safe</tt>
<br><tt>- Receiver auto-config</tt>
<br><tt> + e.g. receivers can find their nearest server</tt>
<br><tt>- Keep it Simple</tt><tt></tt>
<p><tt>BC: I think the receiver auto-config is DONE: DNS</tt>
<br><tt> (though Anycast or a web-page or other out-of-band</tt>
<br><tt> mechanism could be used also)</tt>
<br><tt>BW: I am just defining high-level requirements without</tt>
<br><tt> considering solutions</tt><tt></tt>
<p><tt>BC: We need to be able to "prune protocols" (to quote</tt>
<br><tt> Steve Deering) to make it simple</tt><tt></tt>
<p><tt>BC: Do we want to get into Policy metrics when considering</tt>
<br><tt> inter-AS (inter-domain)?</tt>
<br><tt>BW: I really don't think we want to go there.</tt><tt></tt>
<p><tt>BC: All protocols are source based now</tt>
<br><tt>BW: Huh? Applications don't have a way to specify the</tt>
<br><tt> source.</tt><tt></tt>
<p><tt>??: the tree building protocol is running all the time?</tt>
<br><tt>BW: Yes, so you can ask anytime for what parents are</tt><tt></tt>
<p><tt>RK: It sounds like you are trying to punt things away, so</tt>
<br><tt> if it does not get done here where does it get done?</tt>
<br><tt>BW: In TRACK</tt>
<br><tt>BC: We still need to determine the line between TRACK and</tt>
<br><tt> here.</tt>
<br><tt>BW: The issue is that keep-alives, HACK packets, get generated.</tt>
<br><tt> It is control path versus data path issue.</tt>
<br><tt>RK: I like that separation between control and data paths.</tt>
<br><tt> This document should be sufficient to create a control path</tt>
<br><tt> and that control path is used to deliver data.</tt>
<br><tt>BW: There is realistic three peices here: all error packets</tt>
<br><tt> are part of data. We want auto-tree config information.</tt>
<br><tt>BC: I agree they are separate, but think there is anough</tt>
<br><tt> commonality to keep them together.</tt>
<br><tt>BW: I am abstracting out configuration information for control</tt><tt></tt>
<p><tt>RK: Can we separate out like:</tt>
<br><tt> - Ctrl path: tree creation and maintainenace</tt>
<br><tt> - Data path: "repair" PI specific control</tt><tt></tt>
<p><tt><< short diversion into discussing whether it is possible
to</tt>
<br><tt>create a generic BB or whether we have to start with a PI</tt>
<br><tt>...the challenge being whether we can have something generic</tt>
<br><tt>without getting into protocol details >></tt><tt></tt>
<p><tt>BC: You can do something really simple, but if it is going</tt>
<br><tt> to be that minimal, there is some question about whether</tt>
<br><tt> it is useful.</tt>
<br><tt>TH: It has to work, so it can't be that thin. The thing is</tt>
<br><tt> that to be useful, we need to agree on some common elements.</tt>
<br><tt>BW: I think the NACK BB is going to be very short (deal with</tt>
<br><tt> retry timer and action) and I suspect that we can make this</tt>
<br><tt> Tree Building BB just as small.</tt>
<br><tt>BC: CDN people want all these things. I don't know where</tt>
<br><tt> the line is between generic BB and PI.</tt><tt></tt>
<p><tt>??: There are two main things: discovery and maintenance.</tt>
<br><tt>DM: Yes, but it is more complex since there are different</tt>
<br><tt> scenarios (e.g. late joins).</tt><tt></tt>
<p><tt>RK: Tree "functions"</tt>
<br><tt>- Discovery: learning *possible* parents (manually or auto)</tt>
<br><tt>- Construction: Joining the tree</tt>
<br><tt> + BC: e.g. applying Dijkstra and creating link-state</tt>
<br><tt>- Maintenance: Fail over, leaving</tt>
<br><tt>- Service Hooks (sub-cast, aggregation, etc.)</tt><tt></tt>
<p><tt>BW: Problem is you can't discover parents without considering</tt>
<br><tt> where the source is.</tt>
<br><tt>BC: What is the signal for generating a tree, is it that a</tt>
<br><tt>receiver joined or that a source is there?</tt>
<br><tt>BW: I would say when receiver joins</tt>
<br><tt>BC: I would agree with that</tt><tt></tt>
<p><tt>RK: Discovery:</tt>
<br><tt>- who starts the process?</tt>
<br><tt> + source: top-down tree generation</tt>
<br><tt> + receiver: bottom up tree generation</tt><tt></tt>
<p><tt>BW: The way the world actually works is you have a collection</tt>
<br><tt> of Sources, a collection of potential DR's (intermediates)</tt>
<br><tt> and receivers (he illustrated on board with three layers).</tt>
<br><tt>BC: We are not dealing with the receivers to servers in this</tt>
<br><tt> tree building (which is a server location problem ...and
we</tt>
<br><tt> can safely assume that DNS solves this). Most of the
time</tt>
<br><tt> the configuration of the mesh of intermediates is statically</tt>
<br><tt> configured (99% of the time) ...call it "the Mesh."
At this</tt>
<br><tt> point there are NO TREES yet (an important point), so there's</tt>
<br><tt> no concept of loops at this point since nothing is source</tt>
<br><tt> specific.</tt><tt></tt>
<p><tt>BW: Mesh:</tt>
<br><tt>1) neighbor disovery</tt>
<br><tt>2) senders announce</tt>
<br><tt>3) receivers initiate join</tt><tt></tt>
<p><tt>BC: Alternately, the source finds a server</tt>
<br><tt>DM: Yes, there may be many servers that are not relevant</tt>
<br><tt> to a source</tt>
<br><tt>BC: Ok, yes, so let's assume that the source does NOT</tt>
<br><tt> announce to the servers. We already know how to do
this</tt>
<br><tt> and it's called multicast routing (using PIM). It
requires</tt>
<br><tt> that each server knows the metric distance to the source(s).</tt>
<br><tt>BW: Ok, so we're done! We will just run another routing</tt>
<br><tt> protocol (along with the one below us at the IP layer that</tt>
<br><tt> we cannot access and the one that may be above at the</tt>
<br><tt> application level).</tt><tt></tt>
<p><tt>??: Ok, this assumes that there is a mesh, but what if</tt>
<br><tt> we don't assume this?</tt>
<br><tt>BC: I disagree, since if you look at anything on the net</tt>
<br><tt> it is formed as a mesh and there are a lot of administrative</tt>
<br><tt> issues about who can talk to who.</tt><tt></tt>
<p><tt>Lots of discussion/debate about whether we can assume that</tt>
<br><tt>the mesh is avilable as preconfigured infrastructure. To
do</tt>
<br><tt>auto configuration we cannot assume many-to-many SRM-like</tt>
<br><tt>discovery.</tt><tt></tt>
<p><tt>Dah Ming and BL agreed that having the intermediate mesh</tt>
<br><tt>assumed makes having the receivers going directly to senders</tt>
<br><tt>impossible (e.g. so the receivers can organize into a tree</tt>
<br><tt>without having an intermediate layer).</tt><tt></tt>
<p><tt>BL: Could send from source with IP list, as I described earlier.</tt>
<br><tt>DM: Yes.</tt>
<br><tt>BC: Ok, if source sends magic packet then each receiver</tt>
<br><tt> picks a receiving parent.</tt>
<br><tt>DM: Yes. This should be allowed and the static intermediate</tt>
<br><tt> layer could be optional.</tt>
<br><tt>BL: Yes, and then any intermediate node can declare that</tt>
<br><tt> they don't want to be part of the tree.</tt><tt></tt>
<p><tt>-> Some disagreement about which of the two models should be</tt>
<br><tt> the primary requirement.</tt><tt></tt>
<p><tt>RK: My dream protocol that I want</tt>
<br><tt>- Doesn't require GRA (but be compatible with GRA)</tt>
<br><tt>- Doesn't use TTL scoping</tt>
<br><tt>- Needs to work in PIM source only (PIM-SO)</tt>
<br><tt>- Doesn't require config info in hosts</tt>
<br><tt>- Doesn't require statically deployed mesh</tt><tt></tt>
<p><tt>BC: You may want to determine your tree with metrics other</tt>
<br><tt> than hops (e.g., server load, geographic location, etc.).</tt><tt></tt>
<p><tt>BL (and others): the one where receivers can be DRs makes</tt>
<br><tt> the static mesh possible, but the converse is NOT true.</tt>
<br><tt>BC: I disagree. Since not all receivers can send, it becomes</tt>
<br><tt> an access control issue that assumes many-to-many multicast</tt>
<br><tt> is possible.</tt><tt></tt>
<p><tt>Summary of differences between the two models:</tt><tt></tt>
<p><tt>> Dynamic Discovery version sends a probe from the source and</tt>
<br><tt> each *logical* hop adds its addres and the metric you end
up</tt>
<br><tt> using is a router-like distance metric that uses the number</tt>
<br><tt> of hops. In that model also, any receiver can (potentially)</tt>
<br><tt> be a repair node, which Brad and BW both say is not realistic</tt>
<br><tt> since that assumes many-to-many (like SRM) and that is simply</tt>
<br><tt> not available in the real world. In this model only
the members</tt>
<br><tt> in the mesh can be repair nodes. Brad pointed out
that this</tt>
<br><tt> is how all of the CDN folk do things.</tt><tt></tt>
<p><tt>> Other version assumes the creation/existence of a mesh</tt>
<br><tt> which can use *any* number of different metrics for distance</tt>
<br><tt> (not just a router-like "number of hops", which would have</tt>
<br><tt> to count virtual hops, since it counts servers rather than</tt>
<br><tt> routers).</tt><tt></tt>
<p><tt>The first model can co-exist with the second, but the first</tt>
<br><tt>cannot exist if the existence of the mesh in the first is</tt>
<br><tt>assumed.</tt><tt></tt>
<p><tt><<end>></tt></html>
--------------83EEF7F1661A5FD3901798F2--
--------------12DAB1FB4EB5F784B0A83607
Content-Type: text/x-vcard; charset=us-ascii;
name="Roger.Kermode.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Roger Kermode
Content-Disposition: attachment;
filename="Roger.Kermode.vcf"
begin:vcard
n:Kermode;Roger
tel;cell:+61-408-212-284
tel;fax:+61-2-966-0501
tel;work:+61-2-9666-0558
x-mozilla-html:FALSE
url:www.motorola.com.au/arc/
org:Communications And Networking Lab;Motorola Australian Research Centre
adr:;;Locked Bag 5028;Botany;NSW;1455;Australia
version:2.1
email;internet:Roger.Kermode@motorola.com
title:Principal Research Engineer/Lab Manager
fn:Roger Kermode
end:vcard
--------------12DAB1FB4EB5F784B0A83607--
>From owner-rmt@listserv.lbl.gov Sun Mar 5 04:26:30 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id EAA14554;
Sun, 5 Mar 2000 04:26:25 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id EAA14550
for <rmt@listserv.lbl.gov>; Sun, 5 Mar 2000 04:26:23 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id EAA04788
for <rmt@listserv.lbl.gov>; Sun, 5 Mar 2000 04:26:23 -0800 (PST)
Received: from motgate.mot.com (motgate.mot.com [129.188.136.100])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id EAA04784
for <rmt@lbl.gov>; Sun, 5 Mar 2000 04:26:22 -0800 (PST)
Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (motgate 2.1) with ESMTP id FAA25363 for <rmt@lbl.gov>; Sun, 5 Mar 2000 05:26:21 -0700 (MST)]
Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [217.1.10.38]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id FAA21864 for <rmt@lbl.gov>; Sun, 5 Mar 2000 05:26:19 -0700 (MST)]
Received: from motorola.com ([217.2.31.248])
by homer.arc.corp.mot.com (8.9.3/8.9.3) with ESMTP id XAA12338
for <rmt@lbl.gov>; Sun, 5 Mar 2000 23:23:23 +1100 (EST)
Message-ID: <38C25197.2B860A5D@motorola.com>
Date: Sun, 05 Mar 2000 23:22:47 +1100
From: Roger Kermode <Roger.Kermode@motorola.com>
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: rmt-list <rmt@lbl.gov>
Subject: RMT Call for agenda items for Adelaide
Content-Type: multipart/mixed;
boundary="------------372261E48FE8926E5CBF5D96"
Sender: owner-rmt@lbl.gov
Precedence: bulk
This is a multi-part message in MIME format.
--------------372261E48FE8926E5CBF5D96
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Dear RMTers,
The draft ietf-draft deadline is rapdily approaching...so it's
time that we start to put together an agenda for Adelaide.
Let's keep the momemtum going from the interim meeting,
please send items for disucssion to the chairs as soon as
you can
cheers,
Roger
FYI ...We have two chunks of time booked, so there should
be plenty of time for discussion:
Tuesday 1545-1645, 1700-1800
Wednesday 0900-1130
--------------372261E48FE8926E5CBF5D96
Content-Type: text/x-vcard; charset=us-ascii;
name="Roger.Kermode.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Roger Kermode
Content-Disposition: attachment;
filename="Roger.Kermode.vcf"
begin:vcard
n:Kermode;Roger
tel;cell:+61-408-212-284
tel;fax:+61-2-966-0501
tel;work:+61-2-9666-0558
x-mozilla-html:FALSE
url:www.motorola.com.au/arc/
org:Communications And Networking Lab;Motorola Australian Research Centre
adr:;;Locked Bag 5028;Botany;NSW;1455;Australia
version:2.1
email;internet:Roger.Kermode@motorola.com
title:Principal Research Engineer/Lab Manager
fn:Roger Kermode
end:vcard
--------------372261E48FE8926E5CBF5D96--
>From owner-rmt@listserv.lbl.gov Mon Mar 6 01:47:06 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id BAA16647;
Mon, 6 Mar 2000 01:43:23 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id BAA16642
for <rmt@listserv.lbl.gov>; Mon, 6 Mar 2000 01:43:19 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id BAA04675
for <rmt@listserv.lbl.gov>; Mon, 6 Mar 2000 01:43:19 -0800 (PST)
Received: from smtp2.cluster.oleane.net (smtp2.cluster.oleane.net [195.25.12.17])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id BAA04668
for <rmt@lbl.gov>; Mon, 6 Mar 2000 01:43:17 -0800 (PST)
Received: from oleane (dyn-1-1-132.Vin.dialup.oleane.fr [195.25.4.132]) by smtp2.cluster.oleane.net with SMTP id KAA78930; Mon, 6 Mar 2000 10:42:56 +0100 (CET)
Message-ID: <00f401bf874f$be56f800$0401a8c0@oleane.com>
From: "Peter Lewis" <peter.lewis@upperside.fr>
To: <Undisclosed-Recipient:@smtp2.cluster.oleane.net;>
Subject: SIP 2000 International Conference
Date: Mon, 6 Mar 2000 10:38:24 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_00F1_01BF8758.19B928A0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-rmt@lbl.gov
Precedence: bulk
This is a multi-part message in MIME format.
------=_NextPart_000_00F1_01BF8758.19B928A0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Unknown and even rejected by many vendors and operators only a few =
months ago, SIP is on the brink of making a definitive name for itself.=20
Visit the SIP 2000 International Conference programme:
http://www.upperside.fr/basip.htm
=20
------=_NextPart_000_00F1_01BF8758.19B928A0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>
<DIV><FONT face=3DArial size=3D2>
<DIV>Unknown and even rejected by many vendors and operators only a few =
months=20
ago, SIP is on the brink of making a definitive name for itself. </DIV>
<DIV>Visit the SIP 2000 International Conference programme:</DIV>
<DIV><A=20
href=3D"http://www.upperside.fr/basip.htm">http://www.upperside.fr/basip.=
htm</A></DIV>
<DIV></FONT> </DIV></DIV></FONT></DIV>
<DIV> </DIV></BODY></HTML>
------=_NextPart_000_00F1_01BF8758.19B928A0--
>From owner-rmt@listserv.lbl.gov Wed Mar 8 16:37:01 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id QAA01920;
Wed, 8 Mar 2000 16:35:05 -0800 (PST)
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id QAA01916
for <rmt@listserv.lbl.gov>; Wed, 8 Mar 2000 16:35:03 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id QAA21004
for <rmt@listserv.lbl.gov>; Wed, 8 Mar 2000 16:35:03 -0800 (PST)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id QAA21000
for <rmt@lbl.gov>; Wed, 8 Mar 2000 16:35:02 -0800 (PST)
Received: from lorenzo-u10.cisco.com (lorenzo-u10.cisco.com [171.69.65.85])
by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id QAA11874
for <rmt@lbl.gov>; Wed, 8 Mar 2000 16:34:31 -0800 (PST)
Received: from localhost (lorenzo@localhost) by lorenzo-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id QAA29554 for <rmt@lbl.gov>; Wed, 8 Mar 2000 16:35:09 -0800 (PST)
Message-Id: <200003090035.QAA29554@lorenzo-u10.cisco.com>
X-Authentication-Warning: lorenzo-u10.cisco.com: lorenzo owned process doing -bs
X-Mailer: exmh version 2.0.2 2/24/98
To: rmt@lbl.gov
Subject: FEC BB draft
Mime-Version: 1.0
Content-Type: multipart/mixed ;
boundary="==_Exmh_-17452598970"
Date: Wed, 08 Mar 2000 16:35:09 -0800
From: Lorenzo Vicisano <lorenzo@cisco.com>
Sender: owner-rmt@lbl.gov
Precedence: bulk
This is a multipart MIME message.
--==_Exmh_-17452598970
Content-Type: text/plain; charset=us-ascii
Dear RTM-ers,
As established, the ALC subgroup has worked on the attached
FEC BB draft. We intend to submit it by Friday.
As this BB also interests other subgroups, we are circulating
it to collect comments.
This draft addresses the following:
- gives a general description/classification of the FEC codes pertinent to
RMT.
- discusses FEC-related information needed in packet fields.
- addresses security issues.
Please note that this is only the 1-st draft. Things can
be changed later. In particular my guess is that section 3,
that describes packets fields, will be expanded and detailed
in the next revision of this spec.
cheers,
Lorenzo Vicisano
--==_Exmh_-17452598970
Content-Type: text/plain ; name="draft-ietf-rmt-bb-fec-00.txt"; charset=us-ascii
Content-Description: draft-ietf-rmt-bb-fec-00.txt
Content-Disposition: attachment; filename="draft-ietf-rmt-bb-fec-00.txt"
RMT Working Group M. Luby
INTERNET DRAFT L. Vicisano
Expires 8 September 2000 L. Rizzo
J. Gemmell
J. Crowcroft
B. Lueckenhoff
8 March 2000
Reliable Multicast Transport Building Block:
Forward Error Correction Codes
<draft-ietf-rmt-bb-fec-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved.
Abstract
This memo describes the use of Forward Error Correction (FEC) codes
within the context of reliable IP multicast transport and provides an
introduction to some commonly-used FEC codes.
1. Rationale and Overview
Luby, Vicisano, Rizzo, Gemmell, Crowcroft, Lueckenhoff [Page 1]
Internet Draft RMT BB, Forward Error Correction Codes March 2000
There are many ways to provide reliability for transmission proto-
cols. A common method is to use ARQ, automatic request for
retransmission. With ARQ, receivers use a back channel to the sender
to send requests for retransmission of lost packets. ARQ works well
for one-to-one reliable protocols, as evidenced by the pervasive suc-
cess of TCP/IP. ARQ has also been an effective reliability tool for
one-to-many reliability protocols, and in particular for some reli-
able IP multicast protocols. However, for one-to-very many reliabil-
ity protocols, ARQ has limitations, including the feedback implosion
problem because many receivers are transmitting back to the sender,
and the need for a back channel to send these requests from the
receiver. Another limitation is that receivers may experience dif-
ferent loss patterns of packets, and thus receivers may be delayed by
retransmission of packets that other receivers have lost that but
they have already received. This may also cause wasteful use of
bandwidth used to retransmit packets that have already been received
by many of the receivers.
In environments where ARQ is either costly or impossible because
there is either a very limited capacity back channel or no back chan-
nel at all, such as satellite transmission, a Data Carousel approach
to reliability is sometimes used [AFZ95]. With a Data Carousel, the
sender partitions the object into equal length source symbols, places
them into packets, and then continually cycles through and sends
these packets. Receivers continually receive packets until they have
received a copy of each packet. Data Carousel has the advantage that
it requires no back channel because there is no data that flows from
receivers to the sender. However, Data Carousel also has limita-
tions. For example, if a receiver loses a packet in one round of
transmission it must wait an entire round before it has a chance to
receive that packet again. This may also cause wasteful use of
bandwidth, as the sender continually cycles through and transmits the
packets until no receiver is missing a packet.
FEC codes provide a reliability method that can be used to augment or
replace other reliability methods, especially for one-to-many relia-
bility protocols such as reliable IP multicast. Ideally, FEC codes
in the context of IP multicast can be used to encode an object into
packets in such a way that each received packet is fully useful to a
receiver to reassemble the object regardless of previous packet
reception patterns. Thus, if some packets are lost in transit between
the sender and the receiver, instead of asking for retransmission
using ARQ or waiting till the packets are resent using Data Carousel,
the receiver can use any other subsequent equal number of packets
that arrive to reassemble the object. This implies that the same
packet is fully useful to all receivers to reassemble the object,
even though the receivers may have previously experienced different
packet loss patterns. This property can reduce or even eliminate the
Luby, Vicisano, Rizzo, Gemmell, Crowcroft, Lueckenhoff [Page 2]
Internet Draft RMT BB, Forward Error Correction Codes March 2000
problems mentioned above associated with ARQ and Data Carousel and
thereby dramatically increase the scalability of the protocol to ord-
ers of magnitude more receivers.
For some reliable IP multicast protocols, FEC codes are used in con-
junction with ARQ to provide reliability. For example, in a first
round all of the source symbols could be transmitted, and then
receivers could report back to the sender the number of symbols they
are missing from each block. Then, the sender could compute the max-
imum number of missing symbols from each block among all receivers,
and then transmit that number of redundant symbols for each block.
In this case, even if different receivers are missing different sym-
bols in different blocks, transmitted redundant symbols for a given
block are useful to all receivers missing symbols from that block.
For others, FEC codes are used in a Data Carousel fashion to provide
reliability, by cycling through and transmitting the encoding symbols
instead of the source symbols. For example, suppose an FEC code is
applied to the entire object consisting of k source symbols to gen-
erate n encoding symbols with the property that the entire object can
be reassembled from any k encoding symbols, and the sender cycles
through and transmits the n encoding symbols in the same order in
each round. Then, a receiver can join the transmission at any point
in time, and as long as the receiver receives at least k encoding
symbols during the transmission of n encoding symbols then the
receiver can completely recover the object. This is true even if the
receiver joins the data carousel in the middle of a round.
For yet other reliable IP multicast protocols the sole method to
obtain reliability is to use FEC codes. For example, the sender can
decide a priori how many encoding symbols it will transmit, use an
FEC code to generate that number of encoding symbols from the object,
and then transmit the encoding symbols to all receivers. This method
is for example applicable to streaming protocols, where the stream is
partitioned into objects, each object is encoded into encoding sym-
bols using an FEC code, and then the sets of encoding symbols for
each object are transmitted one after the other using IP multicast.
The large on demand codes described below have the property that the
FEC encoder can generate sequentially as many encoding symbols as are
desired on demand. Thus, reliable IP multicast protocols that use
large on demand codes generally rely solely on these codes for relia-
bility.
In the general literature, FEC refers to the ability to overcome both
erasures (losses) and bit-level corruption. However, in the case of
IP multicast, lower network layers will detect corrupted packets and
discard them. Therefore, an IP multicast protocol need not be con-
cerned with corruption; the focus is solely on erasure codes. The
Luby, Vicisano, Rizzo, Gemmell, Crowcroft, Lueckenhoff [Page 3]
Internet Draft RMT BB, Forward Error Correction Codes March 2000
payloads are generated and processed using an FEC erasure encoder and
objects are reassembled from reception of packets using the
corresponding FEC erasure decoder.
The primary purpose of using FEC codes is to ensure that minimal
number of packets need be received in order for a receiver to
reassemble an object. Reception overhead is used to measure how
close a protocol comes to achieving this minimum. Reception overhead
is the aggregate length of packets needed to recover the object
beyond the object length, measured as a percentage of the object
length. For example, if it takes 15 MB of packets in order to
recover a 10 MB object, then the reception overhead is (15 10)/10
times 100, or 50%. The minimal reception overhead possible is 0%.
2. FEC Codes
2.1. Simple codes
There are some very simple codes that are effective for repairing
packet loss under very low loss conditions. For example, one simple
way to provide protection from a single loss is to partition the
object into fixed size source symbols and then add a redundant symbol
that is the parity (XOR) of all the source symbols. The size of a
source symbol is chosen so that it fits perfectly into the payload of
a packet, i.e. if the packet payload is 512 bytes then each source
symbol is 512 bytes. The header of each packet contains enough
information to identify the payload. In this case, this includes a
symbol ID. The symbol IDs are numbered consecutively starting from
zero independently for the source symbols and for the redundant sym-
bol. Thus, the packet header also contains an encoding flag that
indicates whether they symbol in the payload is a source symbol or a
redundant symbol, where 1 indicates source symbol and 0 indicates
redundant symbol. For example, if the object consists of four source
symbols that have values a, b, c and d, then the value of the redun-
dant symbol is e = a XOR b XOR c XOR d. Then, the packets carrying
these symbols look like (0, 1: a), (1, 1: b), (2, 1: c), (3, 1: d),
(0, 0: e). In this example, the first two fields are in the header
of the packet, where the first field is the symbol ID and the second
field is the encoding flag. The portion of the packet after the
colon is the payload. Any single symbol of the object can be
recovered as the parity of all the other symbols. For example, if
packets (0, 1: a), (1, 1: b), (3, 1: d), (0, 0: e) are received then
the symbol value for the missing source symbol with ID 2 can be
recovered by computing a XOR b XOR d XOR e = c.
When the number of source symbols in the object is large, a simple
block code variant of the above can be used. In this case, the
source symbols are grouped together into source blocks of k
Luby, Vicisano, Rizzo, Gemmell, Crowcroft, Lueckenhoff [Page 4]
Internet Draft RMT BB, Forward Error Correction Codes March 2000
consecutive symbols each, and then for each block of source symbols a
redundant symbol is added to form encoding blocks of k+1 symbols
each. Then, a source block can be recovered from any k of the k+1
symbols from the associated encoding block.
Slightly more sophisticated ways of adding redundant symbols using
parity can also be used. For example, one can group the k source sym-
bols in the object into a p x p square matrix, where p = sqrt(k).
Then, for each row a redundant symbol is added that is the parity of
all the source symbols in the row. Similarly, for each column a
redundant symbol is added that is the parity of all the source sym-
bols in the column. Then, Any row of the matrix can be recovered
from any p of the p+1 symbols in the row, and similarly for any
column. Higher dimensional product codes using this technique can
also be used. However, one must be wary of using these constructions
without some thought towards the possible loss patterns of symbols.
Ideally, the property that one would like to obtain is that if k
source symbols are encoded into n encoding symbols (the encoding sym-
bols consist of the source symbols and the redundant symbols) then
the k source symbols can be recovered from any k of the n encoding
symbols. Using the simple constructions described above does not
yield codes that come close to obtaining this ideal behavior.
2.2. Small block codes
Reliable IP multicast protocols may use a block (n, k) FEC erasure
code [BLA94]. For such a code, k source symbols are encoded into n >
k encoding symbols, such that any k of the encoding symbols can be
used to reassemble the original k source symbols. Thus, these codes
have 0% reception overhead when used to encode the entire object
directly. Block codes are usually systematic, which means that the n
encoding symbols consist of the k source symbols and n-k redundant
symbols generated from these k source symbols, where the size of a
redundant symbol is the same as that for a source symbol. For exam-
ple, the first simple code (XOR) described in the previous subsection
is a (k+1, k) code. In general, the freedom to choose n larger than
k+1 is desirable, as this can provide much better protection against
losses. Codes of this sort are often based on algebraic methods
using finite fields. Some of the most popular such codes are based
on linear block codes. Implementations of (n, k) FEC erasure codes
are efficient enough to be used by personal computers [RIZ97c,
NON97]. For example, [Riz97b] describes an implementation where the
encoding and decoding speeds decay as C/j, where the constant C is on
the order of 10 to 80 Mbytes/second for Pentium class machines of
various vintages and j is upper bounded by min(k, n-k).
In practice, the values of k and n must be small for these codes as
large values make encoding and decoding prohibitively expensive. As
Luby, Vicisano, Rizzo, Gemmell, Crowcroft, Lueckenhoff [Page 5]
Internet Draft RMT BB, Forward Error Correction Codes March 2000
many objects are longer than k symbols for reasonable values of k and
the symbol length (e.g. larger than 16 KB for k = 16 using 1 KB sym-
bols), they are divided into m source blocks consisting of k source
symbols each. An erasure code is used to encode each source block
into an encoding block consisting of n encoding symbols. For a
receiver to completely recover the object, k distinct encoding sym-
bols (i.e., with different symbol IDs) must be received for each of
the encoding blocks. For some encoding blocks, more than k encoding
symbols may be received, in which case any additional encoding sym-
bols are discarded. An example encoding structure is shown in Figure
1.
| source symbols | source symbols |
| of source block 0 | of source block 1 |
| |
v v
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|0 |1 |2 |3 |4 |5 |6 |7 |0 |1 |2 |3 | 4|5 |6 |7 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|
encode
|
v
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|0 |1 |2 |3 | 4| 5| 6| 7| 8| 9| 0| 1| 2| 3| 4| 5| 6| 7| 8| 9|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
^ ^
| |
| encoding symbols | encoding symbols |
| of encoding block 0 | of encoding block 1 |
Figure 1. Encoding structure for object divided into m = 2 source
blocks, k = 8 and n = 10
When using small block codes for objects that are larger than k
source symbols in length, the source symbols in the object are
assigned to blocks. Typically, each k contiguous source symbols of
the object is assigned to a block, i.e., block c consists of the
range of source symbols [ck, (c+1)k-1]. This ensures that memory
reference are local when the sender reads source symbols to encode,
and when the receiver reads encoding symbols to decode.Locality of
reference is particularly important when the object is stored on
disk, as it reduces the disk seeks required.
The block number and the source symbol ID within that block can be
used to uniquely specify a source symbol within the object. If the
Luby, Vicisano, Rizzo, Gemmell, Crowcroft, Lueckenhoff [Page 6]
Internet Draft RMT BB, Forward Error Correction Codes March 2000
size of the object is not a multiple of k source symbols, then the
last source block will contain less than k symbols.
Encoding symbols can be uniquely identified by block number and
encoding symbol ID. The block numbers can be numbered consecutively
starting from zero. One way of identifying encoding symbols within a
block are to use symbol IDs and an encoding flag that is used to
specify whether an encoding symbol is a source symbol or a redundant
symbol, where for example 1 indicates source symbol and 0 indicate
redundant symbol. The symbol IDs can be numbered consecutively
starting from zero for each block independently for the source sym-
bols and for the redundant symbols. Thus, an encoding symbol can be
identified by its block number, the encoding flag, and the symbol ID.
For example, if the object consists 10 source symbols with values a,
b, c, d, e, f, g, h, i, and j, and k = 5 and n = 8, then there are
two source blocks consisting of 5 symbols each, and there are two
encoding blocks consisting of 8 symbols each. Let p, q and r be the
values of the redundant symbols for the first encoding block, and let
x, y and z be the values of the redundant symbols for the second
encoding block. Then the encoding symbols together with their iden-
tifiers are (0, 0, 1:a), (0, 1, 1: b), (0, 2, 1: c), (0, 3, 1: d),
(0, 4, 1: e), (0, 0, 0: p), (0, 1, 0: q), (0, 2, 0: r), (1, 0, 1: f),
(1, 1, 1: g), (1, 2, 1: h), (1, 3, 1: i), (1, 4, 1: j), (1, 0, 0: x),
(1, 1, 0: y) and (1, 2, 0: z). In this example, the first three
fields identify the encoding symbol, where the first field is the
block number, the second field is the symbol ID and the third field
is the encoding flag. The value of the encoding symbol is written
after the colon. Each block can be recovered from any 5 of the 8
encoding symbols associated with that block. For example, reception
of (0, 1, 1: b), (0, 2, 1: c), (0, 3, 1: d), (0, 0, 0: p) and (0, 1,
0: q) are sufficient to recover the first source block and reception
of (1, 0, 1: f), (1, 1, 1: g), (1, 0, 0: x), (1, 1, 0: y) and (1, 2,
0: z) are sufficient to recover the second source block.
2.3. Large block codes
Tornado codes [LUB97] are block FEC erasure codes that provide an
alternative to small block codes. A (n, k) Tornado code requires
slightly more than k out of n encoding symbols to reassemble k source
symbols. However, the advantage is that the value of k may be on the
order of tens of thousands and still run efficiently. Because of
memory considerations, in practice the value of n is restricted to be
a small multiple of k, e.g., n = 2k. For example, [BYE98] describes
an implementation of Tornado codes where the encoding and decoding
speeds are proportional to 10 Mbytes/second to 80 Mbytes/second for
Pentium class machines of various vintages when k is in the tens of
thousands and n = 2k. The reception overhead for such values of k
and n is in the 5-10% range. Tornado codes require a large amount of
Luby, Vicisano, Rizzo, Gemmell, Crowcroft, Lueckenhoff [Page 7]
Internet Draft RMT BB, Forward Error Correction Codes March 2000
out of band information to be communicated to all senders and
receivers for each different object length, and require an amount of
memory on the encoder and decoder which is proportional to the object
length times 2n/k.
Tornado codes are designed to have low reception overhead on average
with respect to reception of a random portion of the encoding pack-
ets. Thus, to ensure that a receiver can reassemble the object with
low reception overhead, the packets are permuted into a random order
before transmission.
2.4. On demand codes
All of the FEC erasure codes described up to this point are block
codes. There is a different type of FEC erasure code that we call on
demand codes. Like block codes, an on demand encoder operates on an
object of known size that is partitioned into equal length source
symbols. Unlike block codes, there is no predetermined number of
encoding symbols that can be generated for on demand codes.
Instead, an on demand encoder can generate as few or as many encoding
symbols as required on demand. Also unlike block codes, optimal on
demand codes have the additional attractive property that encoding
symbols for the same object can be generated and transmitted from
multiple servers and concurrently received by a receiver and yet the
receiver incurs a 0% reception overhead.
LT codes are an example of a large on demand FEC code. An LT encoder
uses randomization to generate each encoding symbol randomly and
independently of all other encoding symbols. An LT encoder satisfies
the on demand property, as it can generate as few or as many encoding
symbols as required on demand. Let k be the number of source symbols
that the object is partitioned into. An LT decoder has the property
that with very high probability the receipt of any set of slightly
more than k encoding symbols is sufficient to reassemble the object.
Like Tornado codes, the value of k may be very large, i.e., on the
order of tens or hundreds of thousands, and the encoder and decoder
run efficiently in software. For example the encoding and decoding
speeds for LT codes are proportional to 3 Mbytes/second to 20
Mbytes/second for Pentium class machines of various vintages when k
is in the high tens of thousands. The reception overhead for such
values of k is in the 2-4% range.
When a new encoding symbol is to be generated, it is based on a key
that uniquely describes how the encoding symbol is to be generated.
Because encoding symbols are randomly and independently generated, LT
codes have the property that encoding symbols for the same object can
be generated and transmitted from multiple servers and concurrently
received by a receiver with no more reception overhead than if all
Luby, Vicisano, Rizzo, Gemmell, Crowcroft, Lueckenhoff [Page 8]
Internet Draft RMT BB, Forward Error Correction Codes March 2000
the encoding symbols were generated by a single sender.
There is a tradeoff between the number of source symbols and the
reception overhead, and the larger the number of source symbols the
smaller the reception overhead. Thus, for shorter objects, it is
sometimes advantageous to include multiple symbols in each packet.
Normally, and in the discussion below, there is only one symbol per
packet.
Like small block codes, there is a point when the object is large
enough that it makes sense to partition it into blocks when using LT
codes. Generally the object is partitioned into blocks whenever the
number of source symbols times the packet payload length is less than
the size of the object. Thus, if the packet payload is 1024 bytes
and the number of source symbols is 64,000 then any object over 64 MB
will be partitioned into more than one block. One can choose the
number of source symbols to partition the object into, depending on
the desired encoding and decoding speed versus reception overhead
tradeoff desired. Encoding symbols can be uniquely identified by a
block number (when the object is large enough to be partitioned into
more than one block) and an encoding symbol ID. The block numbers,
if they are used, are generally numbered consecutively starting from
zero within the object. The range of possible values for an encoding
symbol ID is orders of magnitude larger than the number of source
symbols in a block, i.e., on the range of possible values is gen-
erally in the billions. The block number and the encoding symbol ID
are both chosen uniformly and randomly from their range when an
encoding symbol is to be generated and transmitted. For example,
suppose the number of source symbols is 64,000 and the number of
blocks is 2. Then, each packet generated by the LT encoder could be
of the form (b, x: y). In this example, the first two fields iden-
tify the encoding symbol, where the first field is the block number b
= 0 or 1 and the second field is the randomly chosen encoding symbol
ID x. The value y after the colon is the value of the encoding sym-
bol.
3. Passing FEC coding information to receivers
There are two basic methods for passing FEC coding information to
receivers in order to decode an object: within the IP multicast
packet headers or through out of band methods. A description of the
variety of out of band methods is outside the scope of this document.
The FEC coding information can be classified as three types. FEC ses-
sion information is information needed by the FEC decoder that may
remain fixed for the transmission of many objects. FEC object
transmission information is information particular to the object
transmission session needed by the FEC decoder. The FEC payload ID
identifies the symbols in the payload of the ALC packet.
Luby, Vicisano, Rizzo, Gemmell, Crowcroft, Lueckenhoff [Page 9]
Internet Draft RMT BB, Forward Error Correction Codes March 2000
FEC coding information include the FEC codec type, the source block
length, the symbol length, the object length, the encoding block
number, the encoding symbol ID, and an encoding flag indicating
whether the encoding symbol is a source symbol or a redundant symbol.
The FEC codec type, the source block length and the symbol length are
often FEC session information, although they may classified as FEC
object transmission information for some protocols. Thus, sometimes
this information is passed to the receiver out of band, although they
can equally well be included in each IP multicast packet header as
long as the amount of space they take within each packet is minimal.
The object length is part of FEC object transmission information.
Depending on the protocol, the object length is passed to the
receiver out of band or included within each IP multicast packet
header. The FEC payload ID consists of the encoding block number (if
used), the encoding symbol ID and the encoding flag. The FEC payload
ID must be contained within each IP multicast packet header.
4. Security Considerations
The use of FEC, in and of itself, imposes no additional security con-
siderations versus sending the same information without FEC. How-
ever, just like for any transmission system, a malicious sender may
intentionally transmit bad symbols. If a receiver accepts one or more
bad symbols in place of authentic ones then such a receiver will have
its entire object download corrupted by the bad symbol.
Application-level transmission object authentication can detect the
corrupted transfer, but the receiver must then discard the
transferred object. Thus, transmitting false symbols is at least an
effective denial of service attack. At worst, a malicious sender
could add, delete, or replace arbitrary data within the transmitted
object.
In light of this possibility, FEC receivers may screen the source
address of a received symbol against a list of authentic transmitter
addresses. Since source addresses may be spoofed, FEC transport pro-
tocols may provide mechanisms for robust source authentication of
each encoded symbol. Multicast routers along the path of a FEC
transfer may provide the capability of discarding multicast packets
that originated on that subnet, and whose source IP address does not
correspond with that subnet.
5. Intellectual Property Disclosure
Both Tornado codes and LT codes have patents pending.
6. References
[AFZ95] Acharya, S., Franklin, M., and Zdonik, S., ``Dissemination-
Luby, Vicisano, Rizzo, Gemmell, Crowcroft, Lueckenhoff [Page 10]
Internet Draft RMT BB, Forward Error Correction Codes March 2000
Based Data Delivery Using Broadcast Disks'', IEEE Personal
Communications, pp.50-60, Dec 1995.
[BLA94] Blahut, R.E., ``Theory and Practice of Error Control Codes'',
Addison Wesley, MA 1984.
[BYE98] Byers, J.W., Luby, M., Mitzenmacher, M., and Rege, A., ``A
Digital Fountain Approach to Reliable Distribution of Bulk Data'',
Proceedings ACM SIGCOMM '98, Vancouver, Canada, Sept 1998.
[DEE88] Deering, S., ``Host Extensions for IP Multicasting'', RFC
1058, Stanford University, Stanford, CA, 1988.
[GEM99] Gemmell, J., Schooler, E., and Gray, J., ``ALC Scalable
Multicast File Distribution: Caching and Parameters Optimizations''
Technical Report MSR-TR-99-14, Microsoft Research, Redmond, WA, April,
1999.
[HAN98] Handley, M., and Jacobson, V., ``SDP: Session Description
Protocol'', RFC 2327, April 1998.
[HAN96] Handley, M., ``SAP: Session Announcement Protocol'', Internet
Draft, IETF MMUSIC Working Group, Nov 1996.
[LUB97] Luby, M., Mitzenmacher, M., Shokrollahi, A., Spielman, D.,
Stemann, V., ``Practical Loss-Resilient Codes'' 29th STOC'97.
[LUB99] Luby, M., Vicisano, L., Speakman, T. ``Heterogeneous multicast
congestion control based on router packet filtering'', presented at
RMT meeting in Pisa, March 1999.
[R2068] Fielding, R., Gettys, J., Mogul, J. Frystyk, H., Berners-Lee,
T., Hypertext Transfer Protocol HTTP/1.1 (IETF RFC2068)
http://www.rfc-editor.org/rfc/rfc2068.txt
[R2119] Bradner, S., Key words for use in RFCs to Indicate Requirement
Levels (IETF RFC 2119) http://www.rfc-editor.org/rfc/rfc2119.txt
[RIZ97a] Rizzo, L, and Vicisano, L., ``Reliable Multicast Data
Distribution protocol based on software FEC techniques'', Proceedings
of the Fourth IEEES Workshop on the Architecture and Implementation of
High Performance Communication Systems, HPCS-97, Chalkidiki, Greece,
June 1997.
[RIZ97b] Rizzo, L., and Vicisano, L., ``Effective Erasure Codes for
Reliable Computer Communication Protocols'', ACM SIGCOMM Computer
Communication Review, Vol.27, No.2, pp.24-36, Apr 1997.
Luby, Vicisano, Rizzo, Gemmell, Crowcroft, Lueckenhoff [Page 11]
Internet Draft RMT BB, Forward Error Correction Codes March 2000
[RIZ97c] Rizzo, L., ``On the Feasibility of Software FEC'', DEIT Tech
Report, http://www.iet.unipi.it/~luigi/softfec.ps, Jan 1997.
[RUB99] Rubenstein, Dan, Kurose, Jim and Towsley, Don, ``The Impact of
Multicast Layering on Network Fairness'', Proceedings of ACM SIGCOMM'99.
[VIC98A] L.Vicisano, L.Rizzo, J.Crowcroft, ``TCP-like Congestion
Control for Layered Multicast Data Transfer'', IEEE Infocom '98, San
Francisco, CA, Mar.28-Apr.1 1998.
[VIC98B] Vicisano, L., ``Notes On a Cumulative Layered Organization
of Data Packets Across Multiple Streams with Different Rates'',
University College London Computer Science Research Note RN/98/25,
Work in Progress (May 1998).
7. Authors' Addresses
Michael Luby
luby@dfountain.com
Digital Fountain
600 Alabama Street
San Francisco, CA, USA, 94110
Lorenzo Vicisano
lorenzo@cisco.com
cisco Systems, Inc.
170 West Tasman Dr.,
San Jose, CA, USA, 95134
Luigi Rizzo
luigi@iet.unipi.it
Dip. di Ing. dell'Informazione
Universita` di Pisa
via Diotisalvi 2, 56126 Pisa, Italy
Jim Gemmell
jgemmell@microsoft.com
Microsoft Research
301 Howard St., #830
San Francisco, CA, USA, 94105
Jon Crowcroft
J.Crowcroft@cs.ucl.ac.uk
Department of Computer Science
University College London
Gower Street,
London WC1E 6BT, UK
Luby, Vicisano, Rizzo, Gemmell, Crowcroft, Lueckenhoff [Page 12]
Internet Draft RMT BB, Forward Error Correction Codes March 2000
Bruce Lueckenhoff
brucelu@cadence.com
[address here]
Luby, Vicisano, Rizzo, Gemmell, Crowcroft, Lueckenhoff [Page 13]
--==_Exmh_-17452598970--
>From owner-rmt@listserv.lbl.gov Fri Mar 10 13:01:28 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id MAA19330;
Fri, 10 Mar 2000 12:59:30 -0800 (PST)
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id MAA19326
for <rmt@listserv.lbl.gov>; Fri, 10 Mar 2000 12:59:28 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id MAA13719
for <rmt@listserv.lbl.gov>; Fri, 10 Mar 2000 12:59:27 -0800 (PST)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id MAA13716
for <rmt@lbl.gov>; Fri, 10 Mar 2000 12:59:27 -0800 (PST)
Received: from lorenzo-u10.cisco.com (lorenzo-u10.cisco.com [171.69.65.85])
by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id MAA16103;
Fri, 10 Mar 2000 12:58:55 -0800 (PST)
Received: from localhost (lorenzo@localhost) by lorenzo-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id MAA04438; Fri, 10 Mar 2000 12:59:35 -0800 (PST)
Message-Id: <200003102059.MAA04438@lorenzo-u10.cisco.com>
X-Authentication-Warning: lorenzo-u10.cisco.com: lorenzo owned process doing -bs
X-Mailer: exmh version 2.0.2 2/24/98
To: Dah Ming Chiu - Sun Microsystems <Dahming.Chiu@east.sun.com>
cc: sob@harvard.edu, vern@aciri.org, mankin@EAST.ISI.EDU, ark008@email.mot.com,
rcoltun@siara.com, oran@cisco.com, brian@cs.umass.edu,
bcain@nortelnetworks.com, mjh@aciri.org, whetten@talarian.com,
Radia.Perlman@east.sun.com, Miriam.Kadansky@east.sun.com, rmt@lbl.gov
Subject: Re: PIM-SO and RMT
In-reply-to: Your message of "Fri, 10 Mar 2000 15:22:53 EST."
<200003102022.PAA00543@bcn.East.Sun.COM>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 10 Mar 2000 12:59:35 -0800
From: Lorenzo Vicisano <lorenzo@cisco.com>
Sender: owner-rmt@lbl.gov
Precedence: bulk
Dah,
The charter does not state that a "single source" model should
be assumed, however it is very likely that the future multicast
deployment will be largely based on single source.
Moreover, the current heterogeneity of multicast deployment does
not allow to assume the presence of multicast feedback (mainly
because providers do not allow "normal" customers to source multicast).
Nor it does allow to assume the presence of "dense mode" protocols only
(and most of the techniques you mentioned only work with dense mode).
For the above reasons, in the last meeting (at ACIRI) the group agreed
(I think) to assume no multicast back-channel (protocols can still take
advantage of it, if present, as an optimization). Note that this does
not exactly mean "assume Single Source".
I also have two personal remark:
- establishing multicast distribution trees is much more expensive
than using unicast, hence, I think, we should not abuse this --precious--
resource if possible.
- most of the techniques you mentioned do
not work well with multicast back-channel, unless you assume the
presence of a dense mode protocol (and this is not the case).
E.g. expanding ring search is broken (most of the times) in PIM-SM
because, it common cases, packets have to reach the RP first. On the
other side there are application level algorithms that make *all* these
techniques work without multicast back channels.
cheers,
Lorenzo Vicisano
> In the recent RMT Interim meeting in Berkeley, I learned from Brad Cain
> that we have to assume the IP multicast infrastructure is PIM-SourceOnly
> (or PIM-SO) and IGMPv3. In particular, this means we must assume that
> only one host can multicast to a given group. This is confirmed by Mark
> Handley and Roger Kermode (see the meeting minutes under "My dream protocol"
> for example).
>
> Later in separate discussions in the TREE BB subgroup, some stated that
> the PIM-SO (hence only one host can multicast per multicast address)
> is part of the RMT working group charter.
>
> I am seeking a clear statement regarding this requirement. I don't see
> "must assume PIM-SO" are part of the charter. If it is, can it be stated?
> Is it mandated as a requirement for the RMT? Can someone succinctly
> summarize what is the PIM-SO requirement on RMT, and justify it?
>
> I am pressing for this because the lack of many-to-many IP multicast
> capability means a lot of techniques/algorithms reported in the literature
> will not work any more. For example:
> - A NACK protocol depends on the NACK be sent via multicast to suppress
> redundant NACKs that cause implosion.
> - Some tree building protocols use Expanding Ring Search (ERS) to nearby
> servers. Although ERS is considered costly in terms of message overheads,
> it can still be a useful autoconfiguration technique for many scenarios.
> - In a tree-based ACK protocol (TRACK), the repair heads should be able to
> share multicast addresses for sending out multicast repairs. This would
> not be possible if only one host can send on a multicast address.
>
> I understand that in the current public Internet, limiting multicast to a
> single sender fits certain business models of ISPs who can charge for
> multicast. But this constraint is not needed in many intranet environments.
>
> I understand many people support the Simple Multicast model, under which
> there is no single-source constraint. Is that proposal still being studied
> by IETF? Also, what is happening to the BGMP model that allows dense mode
> multicast in administrative domains? Is the PIM-SO requirement premature?
>
> Dah Ming Chiu
> Sun Labs
>
>
>From owner-rmt@listserv.lbl.gov Fri Mar 10 17:38:00 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id RAA21038;
Fri, 10 Mar 2000 17:37:31 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id RAA21034
for <rmt@listserv.lbl.gov>; Fri, 10 Mar 2000 17:37:30 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id RAA01804
for <rmt@listserv.lbl.gov>; Fri, 10 Mar 2000 17:37:28 -0800 (PST)
Received: from virtualworkshop.com (IDENT:root@dino.virtualworkshop.com [208.14.33.1])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id RAA01801
for <rmt@lbl.gov>; Fri, 10 Mar 2000 17:37:27 -0800 (PST)
Received: from virtualworkshop.com (barney.virtualworkshop.com [208.14.33.4])
by virtualworkshop.com (8.9.1/8.8.7) with ESMTP id UAA16595;
Fri, 10 Mar 2000 20:33:06 -0500
Message-ID: <38C9A253.D6D46902@virtualworkshop.com>
Date: Fri, 10 Mar 2000 20:33:07 -0500
From: "Michael D. Myjak" <mmyjak@virtualworkshop.com>
Reply-To: mmyjak@virtualworkshop.com
Organization: The Virtual Workshop, Inc.
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Lorenzo Vicisano <lorenzo@cisco.com>
CC: Dah Ming Chiu - Sun Microsystems <Dahming.Chiu@east.sun.com>,
sob@harvard.edu, vern@aciri.org, mankin@EAST.ISI.EDU,
ark008@email.mot.com, rcoltun@siara.com, oran@cisco.com,
brian@cs.umass.edu, bcain@nortelnetworks.com, mjh@aciri.org,
whetten@talarian.com, Radia.Perlman@east.sun.com,
Miriam.Kadansky@east.sun.com, rmt@lbl.gov
Subject: Re: PIM-SO and RMT
References: <200003102059.MAA04438@lorenzo-u10.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-rmt@lbl.gov
Precedence: bulk
Lorenzo Vicisano wrote:
> Dah,
>
> The charter does not state that a "single source" model should
> be assumed, however it is very likely that the future multicast
> deployment will be largely based on single source.
I take issue with this statement; Its about as far-sighted as next week. How can
you possibly say, with any assurance or credibility, that future multicast
deployment will largely be based on single sources?? Are you not familiar with any
of the on-going work in NASA's Integrated Synthetic Environments? DoEs Shared
Collaboratories? or DoEd's Advanced Distributed Learning?
Certainly to date, the predominate model has been point-to-multipoint. But this
statement is as reassuring as "Certainly... 32-bits is more than enough address
space." Oh Please...
--
All the best -
_
___|0|_|___ Michael D. Myjak, Vice President R&D and CTO
| N & W | The Virtual Workshop, Inc.
= oo---oo = P.O. Box 98 Titusville Fl 32781
email: <mmyjak@virtualworkshop.com> voice&fax: 321.264.0440
>From owner-rmt@listserv.lbl.gov Fri Mar 10 18:09:29 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id SAA21158;
Fri, 10 Mar 2000 18:09:19 -0800 (PST)
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id SAA21154
for <rmt@listserv.lbl.gov>; Fri, 10 Mar 2000 18:09:18 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id SAA05648
for <rmt@listserv.lbl.gov>; Fri, 10 Mar 2000 18:09:17 -0800 (PST)
Received: from kickme.cisco.com (kickme.cisco.com [198.92.30.42])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id SAA05642
for <rmt@lbl.gov>; Fri, 10 Mar 2000 18:09:16 -0800 (PST)
Received: from lorenzo-u10.cisco.com (lorenzo-u10.cisco.com [171.69.65.85])
by kickme.cisco.com (8.9.1a/8.9.1) with ESMTP id RAA20398;
Fri, 10 Mar 2000 17:56:58 -0800 (PST)
Received: from localhost (lorenzo@localhost) by lorenzo-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id SAA05057; Fri, 10 Mar 2000 18:09:24 -0800 (PST)
Message-Id: <200003110209.SAA05057@lorenzo-u10.cisco.com>
X-Authentication-Warning: lorenzo-u10.cisco.com: lorenzo owned process doing -bs
X-Mailer: exmh version 2.0.2 2/24/98
To: mmyjak@virtualworkshop.com
cc: Dah Ming Chiu - Sun Microsystems <Dahming.Chiu@east.sun.com>,
sob@harvard.edu, vern@aciri.org, mankin@EAST.ISI.EDU,
ark008@email.mot.com, rcoltun@siara.com, oran@cisco.com,
brian@cs.umass.edu, bcain@nortelnetworks.com, mjh@aciri.org,
whetten@talarian.com, Radia.Perlman@east.sun.com,
Miriam.Kadansky@east.sun.com, rmt@lbl.gov
Subject: Re: PIM-SO and RMT
In-reply-to: Your message of "Fri, 10 Mar 2000 20:33:07 EST."
<38C9A253.D6D46902@virtualworkshop.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 10 Mar 2000 18:09:24 -0800
From: Lorenzo Vicisano <lorenzo@cisco.com>
Sender: owner-rmt@lbl.gov
Precedence: bulk
> > The charter does not state that a "single source" model should
> > be assumed, however it is very likely that the future multicast
> > deployment will be largely based on single source.
>
> I take issue with this statement; Its about as far-sighted as next week. How
> can
> you possibly say, with any assurance or credibility, that future multicast
> deployment will largely be based on single sources?? Are you not familiar wit
>h any
> of the on-going work in NASA's Integrated Synthetic Environments? DoEs Shared
> Collaboratories? or DoEd's Advanced Distributed Learning?
Michael,
the context of my statement was in the RMT framework, which is
bulk-data transfer for IP multicast (as currently specified).
Moreover there was more in my email beside the statement that
you are quoting...
I agree with you that interactive applications work much better
with a symmetric Multicast service and that this is probably the
main the reason why we should keep working on its deployment. However
this is out of the scope of RMT (please check the WG charter).
Lorenzo Vicisano
>
> Certainly to date, the predominate model has been point-to-multipoint. But t
>his
> statement is as reassuring as "Certainly... 32-bits is more than enough addre
>ss
> space." Oh Please...
>
>
> --
> All the best -
> _
> ___|0|_|___ Michael D. Myjak, Vice President R&D and CTO
> | N & W | The Virtual Workshop, Inc.
> = oo---oo = P.O. Box 98 Titusville Fl 32781
> email: <mmyjak@virtualworkshop.com> voice&fax: 321.264.0440
>
>
>
>From owner-rmt@listserv.lbl.gov Fri Mar 10 19:04:55 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id TAA21297;
Fri, 10 Mar 2000 19:04:32 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id TAA21293
for <rmt@listserv.lbl.gov>; Fri, 10 Mar 2000 19:04:30 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id TAA10266
for <rmt@listserv.lbl.gov>; Fri, 10 Mar 2000 19:04:29 -0800 (PST)
Received: from virtualworkshop.com (IDENT:root@dino.virtualworkshop.com [208.14.33.1])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id TAA10258
for <rmt@lbl.gov>; Fri, 10 Mar 2000 19:04:28 -0800 (PST)
Received: from virtualworkshop.com (barney.virtualworkshop.com [208.14.33.4])
by virtualworkshop.com (8.9.1/8.8.7) with ESMTP id WAA16747;
Fri, 10 Mar 2000 22:04:24 -0500
Message-ID: <38C9B7B9.4DD89566@virtualworkshop.com>
Date: Fri, 10 Mar 2000 22:04:25 -0500
From: "Michael D. Myjak" <mmyjak@virtualworkshop.com>
Reply-To: mmyjak@virtualworkshop.com
Organization: The Virtual Workshop, Inc.
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Lorenzo Vicisano <lorenzo@cisco.com>
CC: RMT <rmt@lbl.gov>
Subject: Re: PIM-SO and RMT
References: <200003110209.SAA05057@lorenzo-u10.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-rmt@lbl.gov
Precedence: bulk
Lorenzo,
I read what you wrote... I'm just trying to earmark what's on the horizon. And I do
understand that the RMT charter is highly focused toward a narrow-cast solution
space. Be that as it may, the issue in my mind irrespective of that, is that that
the prevailing mind set in this arena seems to be just as you stated - it prefers a
closed, unidirectional, asymmetrical point-to-multipoint communications path which
has little to no regard for application(s) performance (i.e., real-time). (In
fact, the preferred application may be little more than a file or web site
mirror.) Further, applications which are sufficiently "different" or fall outside
of this groups perceived "mainstream" scope may yet evolve and attempt to utilize
the approach developed here, whether we perceive it as applicable or not. (Ex.
Distributed Interactive Simulation [IEEE-1278] used subnet broadcasting to
accomplish what it could not using IP Multicast. Clearly, subnet broadcasting was
never designed with such a (multipoint-to-multipoint) application in mind.)
In short, all I'm trying to say is that we cannot assume that this (or any)
specific application will be the only one(s) to use RMT.
--
All the best -
_
___|0|_|___ Michael D. Myjak, Vice President R&D and CTO
| N & W | The Virtual Workshop, Inc.
= oo---oo = P.O. Box 98 Titusville Fl 32781
email: <mmyjak@virtualworkshop.com> voice&fax: 321.264.0440
Lorenzo Vicisano wrote:
> > > The charter does not state that a "single source" model should
> > > be assumed, however it is very likely that the future multicast
> > > deployment will be largely based on single source.
> >
> > I take issue with this statement; Its about as far-sighted as next week. How
> > can
> > you possibly say, with any assurance or credibility, that future multicast
> > deployment will largely be based on single sources?? Are you not familiar wit
> >h any
> > of the on-going work in NASA's Integrated Synthetic Environments? DoEs Shared
> > Collaboratories? or DoEd's Advanced Distributed Learning?
>
> Michael,
>
> the context of my statement was in the RMT framework, which is
> bulk-data transfer for IP multicast (as currently specified).
> Moreover there was more in my email beside the statement that
> you are quoting...
>
> I agree with you that interactive applications work much better
> with a symmetric Multicast service and that this is probably the
> main the reason why we should keep working on its deployment. However
> this is out of the scope of RMT (please check the WG charter).
>
> Lorenzo Vicisano
>
> >
> > Certainly to date, the predominate model has been point-to-multipoint. But t
> >his
> > statement is as reassuring as "Certainly... 32-bits is more than enough addre
> >ss
> > space." Oh Please...
> >
> >
> > --
> > All the best -
> > _
> > ___|0|_|___ Michael D. Myjak, Vice President R&D and CTO
> > | N & W | The Virtual Workshop, Inc.
> > = oo---oo = P.O. Box 98 Titusville Fl 32781
> > email: <mmyjak@virtualworkshop.com> voice&fax: 321.264.0440
> >
> >
> >
>From owner-rmt@listserv.lbl.gov Sun Mar 12 23:24:00 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id XAA03052;
Sun, 12 Mar 2000 23:21:14 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id XAA03048
for <rmt@listserv.lbl.gov>; Sun, 12 Mar 2000 23:21:12 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id XAA21669
for <rmt@listserv.lbl.gov>; Sun, 12 Mar 2000 23:21:10 -0800 (PST)
Received: from phobos.talarian.com (mailhost.talarian.com [207.5.32.17])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id XAA21665
for <rmt@lbl.gov>; Sun, 12 Mar 2000 23:21:10 -0800 (PST)
Received: from tahoe (talarian32-66.talarian.com [207.5.32.66]) by phobos.talarian.com (8.9.0/8.9.0) with SMTP id XAA26353; Sun, 12 Mar 2000 23:17:53 -0800 (PST)
Message-Id: <4.1.20000312131129.0a957aa0@mailhost.talarian.com>
X-Sender: bwhetten@mailhost.talarian.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1
Date: Sun, 12 Mar 2000 15:51:34 -0800
To: mmyjak@virtualworkshop.com, Lorenzo Vicisano <lorenzo@cisco.com>
From: Brian Whetten <whetten@talarian.com>
Subject: Re: PIM-SO and RMT
Cc: Dah Ming Chiu - Sun Microsystems <Dahming.Chiu@east.sun.com>,
sob@harvard.edu, vern@aciri.org, mankin@EAST.ISI.EDU,
ark008@email.mot.com, rcoltun@siara.com, oran@cisco.com,
brian@cs.umass.edu, bcain@nortelnetworks.com, mjh@aciri.org,
Radia.Perlman@east.sun.com, Miriam.Kadansky@east.sun.com, rmt@lbl.gov
In-Reply-To: <38C9A253.D6D46902@virtualworkshop.com>
References: <200003102059.MAA04438@lorenzo-u10.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-rmt@lbl.gov
Precedence: bulk
>I take issue with this statement; Its about as far-sighted as next week.
>How can
>you possibly say, with any assurance or credibility, that future multicast
>deployment will largely be based on single sources?? Are you not familiar
>with any
>of the on-going work in NASA's Integrated Synthetic Environments? DoEs Shared
>Collaboratories? or DoEd's Advanced Distributed Learning?
>
>Certainly to date, the predominate model has been point-to-multipoint. But
>this
>statement is as reassuring as "Certainly... 32-bits is more than enough
address
>space." Oh Please...
Mike,
Even if a significant piece of multicast deployment eventually support
many-many, there will still be a big piece that does NOT. We have to
design to the least common denominator. As a side note, we'd all love to
see many-many worldwide multicast, but I think there is growing consensus
that it is extremely difficult to justify it economically. The costs are
too high (the inter-domain issue is just too much) and the benefits too low
(there are much easier way to implement many-many apps on top of 1-many
multicast...Talarian has customers deployed with 10K client many-many
environments). This does NOT mean that there are no compelling, scaleable
many-many apps...just that we don't necessarily need to support them with
true many-many multicast.
Brian
>From owner-rmt@listserv.lbl.gov Mon Mar 13 01:02:18 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id BAA03223;
Mon, 13 Mar 2000 01:02:03 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id BAA03219
for <rmt@listserv.lbl.gov>; Mon, 13 Mar 2000 01:02:01 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id BAA26984
for <rmt@listserv.lbl.gov>; Mon, 13 Mar 2000 01:01:57 -0800 (PST)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
by SpamWall.lbl.gov (8.9.3/8.9.3) with SMTP id BAA26981
for <rmt@lbl.gov>; Mon, 13 Mar 2000 01:01:56 -0800 (PST)
Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP
id <g.05507-0@bells.cs.ucl.ac.uk>; Mon, 13 Mar 2000 08:57:11 +0000
To: Brian Whetten <whetten@talarian.com>
cc: mmyjak@virtualworkshop.com, Lorenzo Vicisano <lorenzo@cisco.com>,
Dah Ming Chiu - Sun Microsystems <Dahming.Chiu@east.sun.com>,
sob@harvard.edu, vern@aciri.org, mankin@EAST.ISI.EDU,
ark008@email.mot.com, rcoltun@siara.com, oran@cisco.com,
brian@cs.umass.edu, bcain@nortelnetworks.com, mjh@aciri.org,
Radia.Perlman@east.sun.com, Miriam.Kadansky@east.sun.com, rmt@lbl.gov
Subject: Re: PIM-SO and RMT
In-reply-to: Your message of "Sun, 12 Mar 2000 15:51:34 PST." <4.1.20000312131129.0a957aa0@mailhost.talarian.com>
Date: Mon, 13 Mar 2000 08:57:09 +0000
Message-ID: <2208.952937829@cs.ucl.ac.uk>
From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
Sender: owner-rmt@lbl.gov
Precedence: bulk
>>environments). This does NOT mean that there are no compelling, scaleable
>>many-many apps...just that we don't necessarily need to support them with
>>true many-many multicast.
Brian
yes...
i think another argument can show that we have a deployment credibility
problem with the internet standard multicast service model ....we're already
having a lot of ISPs clamp down on source addresses for unicast traffic so
that they can rapidly respond to Denial of Service attacks - whatever
the pro many=-to=many multicast people say (and i am one of them,
believe me), its at least n-fold harder to audit n sources than 1...
in fact ,there is going to be at least a BOF in adelaide on this topic
- i wonder if any multicast considerations are going to be represented
there?
cheers
jon
>From owner-rmt@listserv.lbl.gov Mon Mar 13 03:20:18 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id DAA03412;
Mon, 13 Mar 2000 03:19:29 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id DAA03408
for <rmt@listserv.lbl.gov>; Mon, 13 Mar 2000 03:19:27 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id DAA04064
for <rmt@listserv.lbl.gov>; Mon, 13 Mar 2000 03:19:26 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id DAA04061
for <rmt@lbl.gov>; Mon, 13 Mar 2000 03:19:25 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15271;
Mon, 13 Mar 2000 06:19:22 -0500 (EST)
Message-Id: <200003131119.GAA15271@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: rmt@lbl.gov
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-rmt-pi-alc-00.txt
Date: Mon, 13 Mar 2000 06:19:21 -0500
Sender: owner-rmt@lbl.gov
Precedence: bulk
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Reliable Multicast Transport Working Group of the IETF.
Title : Asynchronous Layered Coding A scalable reliable
multicast protocol
Author(s) : M. Luby, L. Vicisano et.al
Filename : draft-ietf-rmt-pi-alc-00.txt
Pages : 28
Date : 10-Mar-00
This document describes Asynchronous Layered Coding, a scalable reli-
able multicast protocol, hereafter referred to as ALC. ALC can be
used to reliably transmit objects to multiple receivers. An object
can be any well-defined piece of data. Examples include any type of
file such as a group of pictures in an MPEG stream, a MP3 music file,
a JPEG image, and a collection of files that are zipped into one
file. In addition, the ALC delivery model is fairly flexible, e.g.,
on demand or a push delivery. When using ALC, the payload of the
packets that flow from senders to receivers in no way depend on net-
work conditions or the reaction of receivers to these conditions,
although the rate of flow of the packets in various parts of the net-
work does depend on network conditions. Receivers may join or leave
an existing packet stream in an asynchronous manner independent of
other receivers. Congestion control is achieved by sending several
packet streams ordered in a layered fashion and delivering only a
subset of these to individual receivers. The number of streams
received is dictated by the local bandwidth availability and network
conditions. A possible way to achieve this is by using a distinct
multicast address for each stream. Receivers join the lowest layer
stream they are not currently joined to at coordinated points in time
when there is more available bandwidth between those receivers and
the sender. Similarly, receivers leave one or more highest layer
streams they are currently joined to as soon as they feel congestion
(typically as evidenced by packet loss). Another possibility to
achieve this form of congestion control is through router-assisted
schemes. Reliability is achieved via FEC coding only, i.e. there is
no request for feedback for retransmission from receivers that miss
packets for whatever reason.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rmt-pi-alc-00.txt
Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-rmt-pi-alc-00.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.
Send a message to:
mailserv@ietf.org.
In the body type:
"FILE /internet-drafts/draft-ietf-rmt-pi-alc-00.txt".
NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv@ietf.org"
Content-Type: text/plain
Content-ID: <20000310135058.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-rmt-pi-alc-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-rmt-pi-alc-00.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <20000310135058.I-D@ietf.org>
--OtherAccess--
--NextPart--
>From owner-rmt@listserv.lbl.gov Mon Mar 13 03:20:18 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id DAA03418;
Mon, 13 Mar 2000 03:19:35 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id DAA03414
for <rmt@listserv.lbl.gov>; Mon, 13 Mar 2000 03:19:33 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id DAA04080
for <rmt@listserv.lbl.gov>; Mon, 13 Mar 2000 03:19:32 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id DAA04076
for <rmt@lbl.gov>; Mon, 13 Mar 2000 03:19:31 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15339;
Mon, 13 Mar 2000 06:19:28 -0500 (EST)
Message-Id: <200003131119.GAA15339@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: rmt@lbl.gov
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-rmt-bb-fec-00.txt
Date: Mon, 13 Mar 2000 06:19:28 -0500
Sender: owner-rmt@lbl.gov
Precedence: bulk
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Reliable Multicast Transport Working Group of the IETF.
Title : Reliable Multicast Transport Building Block: Forward
Error Correction Codes
Author(s) : M. Luby, L. Vicisano et.al
Filename : draft-ietf-rmt-bb-fec-00.txt
Pages : 14
Date : 10-Mar-00
This memo describes the use of Forward Error Correction (FEC) codes
within the context of reliable IP multicast transport and provides an
introduction to some commonly-used FEC codes.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rmt-bb-fec-00.txt
Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-rmt-bb-fec-00.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.
Send a message to:
mailserv@ietf.org.
In the body type:
"FILE /internet-drafts/draft-ietf-rmt-bb-fec-00.txt".
NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv@ietf.org"
Content-Type: text/plain
Content-ID: <20000310135108.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-rmt-bb-fec-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-rmt-bb-fec-00.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <20000310135108.I-D@ietf.org>
--OtherAccess--
--NextPart--
>From owner-rmt@listserv.lbl.gov Wed Mar 15 03:27:44 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id DAA13025;
Wed, 15 Mar 2000 03:25:32 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id DAA13021
for <rmt@listserv.lbl.gov>; Wed, 15 Mar 2000 03:25:29 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id DAA27008
for <rmt@listserv.lbl.gov>; Wed, 15 Mar 2000 03:25:29 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id DAA27000
for <rmt@lbl.gov>; Wed, 15 Mar 2000 03:25:26 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29694;
Wed, 15 Mar 2000 06:25:25 -0500 (EST)
Message-Id: <200003151125.GAA29694@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: rmt@lbl.gov
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-rmt-gra-arch-01.txt
Date: Wed, 15 Mar 2000 06:25:24 -0500
Sender: owner-rmt@lbl.gov
Precedence: bulk
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Reliable Multicast Transport Working Group of the IETF.
Title : Generic Router Assist (GRA) Building Block
Motivation and Architecture
Author(s) : B. Cain, T. Speakman, D. Towsley
Filename : draft-ietf-rmt-gra-arch-01.txt
Pages : 21
Date : 14-Mar-00
Generic Router Assist (GRA) is a network-based service that enables
end-to-end multicast transport protocols to take advantage of infor-
mation distributed across the network elements in a given multicast
distribution tree. The service consists of a canonical set of simple
functions which network elements may apply to selected packets in the
transport session as they traverse the distribution tree. The choice
of function and the packet parameters to which it is applied can be
defined and customized for a given transport session in a highly con-
trolled fashion that still permits enough flexibility for GRA to be
used to address a wide range of multicast transport problems not
amenable to end-to-end solution. This document provides the motiva-
tion and an architecture for GRA.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rmt-gra-arch-01.txt
Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-rmt-gra-arch-01.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.
Send a message to:
mailserv@ietf.org.
In the body type:
"FILE /internet-drafts/draft-ietf-rmt-gra-arch-01.txt".
NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv@ietf.org"
Content-Type: text/plain
Content-ID: <20000314133149.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-rmt-gra-arch-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-rmt-gra-arch-01.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <20000314133149.I-D@ietf.org>
--OtherAccess--
--NextPart--
>From owner-rmt@listserv.lbl.gov Thu Mar 16 13:25:29 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id NAA24737;
Thu, 16 Mar 2000 13:21:10 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id NAA24733
for <rmt@listserv.lbl.gov>; Thu, 16 Mar 2000 13:21:08 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id NAA08479
for <rmt@listserv.lbl.gov>; Thu, 16 Mar 2000 13:21:07 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id NAA08472
for <rmt@lbl.gov>; Thu, 16 Mar 2000 13:21:06 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24101;
Thu, 16 Mar 2000 16:21:02 -0500 (EST)
Message-Id: <200003162121.QAA24101@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: rmt@lbl.gov
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-rmt-buildingblocks-02.txt
Date: Thu, 16 Mar 2000 16:21:01 -0500
Sender: owner-rmt@lbl.gov
Precedence: bulk
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Reliable Multicast Transport Working Group of the IETF.
Title : Reliable Multicast Transport Building Blocks for
One-to-Many Bulk-Data Transfer
Author(s) : B. Whetten, M. Handley, S. Floyd, R. Kermode,
L. Vicisano, M. Luby
Filename : draft-ietf-rmt-buildingblocks-02.txt
Pages : 21
Date : 15-Mar-00
This document describes a framework for the standardization of bulk-data
reliable multicast transport. It builds upon the experience gained
during the deployment of several classes of contemporary reliable
multicast transport, and attempts to pull out the commonalities between
these classes of protocols into a number of building blocks. To that
end, this document recommends that certain components that are common to
multiple protocol classes be standardized as 'building blocks.' The
remaining parts of the protocols, consisting of highly protocol
specific, tightly intertwined functions, shall be designated as
'protocol cores.' Thus, each protocol can then be constructed by
merging a 'protocol core' with a number of 'building blocks' which can
be re-used across multiple protocols.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rmt-buildingblocks-02.txt
Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-rmt-buildingblocks-02.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.
Send a message to:
mailserv@ietf.org.
In the body type:
"FILE /internet-drafts/draft-ietf-rmt-buildingblocks-02.txt".
NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv@ietf.org"
Content-Type: text/plain
Content-ID: <20000315132959.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-rmt-buildingblocks-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-rmt-buildingblocks-02.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <20000315132959.I-D@ietf.org>
--OtherAccess--
--NextPart--
>From owner-rmt@listserv.lbl.gov Thu Mar 16 13:25:29 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id NAA24743;
Thu, 16 Mar 2000 13:21:15 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id NAA24739
for <rmt@listserv.lbl.gov>; Thu, 16 Mar 2000 13:21:13 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id NAA08503
for <rmt@listserv.lbl.gov>; Thu, 16 Mar 2000 13:21:13 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id NAA08496
for <rmt@lbl.gov>; Thu, 16 Mar 2000 13:21:12 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24145;
Thu, 16 Mar 2000 16:21:08 -0500 (EST)
Message-Id: <200003162121.QAA24145@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: rmt@lbl.gov
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-rmt-design-space-01.txt
Date: Thu, 16 Mar 2000 16:21:08 -0500
Sender: owner-rmt@lbl.gov
Precedence: bulk
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Reliable Multicast Transport Working Group of the IETF.
Title : The Reliable Multicast Design Space for Bulk Data
Transfer
Author(s) : M. Handley, S. Floyd, B. Whetten, R. Kermode,
L. Vicisano
Filename : draft-ietf-rmt-design-space-01.txt
Pages : 21
Date : 15-Mar-00
The design space for reliable multicast is rich, with many possible
solutions having been devised. However, application requirements serve
to constrain this design space to a relatively small solution space.
This document provides an overview of the design space and the ways in
which application constraints affect possible solutions.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rmt-design-space-01.txt
Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-rmt-design-space-01.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.
Send a message to:
mailserv@ietf.org.
In the body type:
"FILE /internet-drafts/draft-ietf-rmt-design-space-01.txt".
NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv@ietf.org"
Content-Type: text/plain
Content-ID: <20000315133011.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-rmt-design-space-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-rmt-design-space-01.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <20000315133011.I-D@ietf.org>
--OtherAccess--
--NextPart--
>From owner-rmt@listserv.lbl.gov Fri Mar 17 13:18:21 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id NAA29378;
Fri, 17 Mar 2000 13:17:24 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id NAA29374
for <rmt@listserv.lbl.gov>; Fri, 17 Mar 2000 13:17:22 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id NAA19329
for <rmt@listserv.lbl.gov>; Fri, 17 Mar 2000 13:17:21 -0800 (PST)
Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id NAA19322
for <rmt@lbl.gov>; Fri, 17 Mar 2000 13:17:20 -0800 (PST)
Received: from [132.250.92.151] (manimac.itd.nrl.navy.mil [132.250.92.151])
by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id QAA23979
for <rmt@lbl.gov>; Fri, 17 Mar 2000 16:17:17 -0500 (EST)
Mime-Version: 1.0
X-Sender: adamson@pop.itd.nrl.navy.mil
Message-Id: <v04210123b4f8508d6289@[132.250.92.151]>
Date: Fri, 17 Mar 2000 16:17:15 -0500
To: RMT <rmt@lbl.gov>
From: Brian Adamson <adamson@itd.nrl.navy.mil>
Subject: Initial draft of NACK-Oriented Reliable Multicast Building Blocks
Content-Type: multipart/mixed; boundary="============_-1258794657==_============"
Sender: owner-rmt@lbl.gov
Precedence: bulk
--============_-1258794657==_============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
RMT:
We go bounced on the draft submission deadline, but since we will
probably provide an update on it in Adeleide, attached is an initial
cut at a Building Blocks document for NACK-oriented Reliable
Multicast.
best regards,
--============_-1258794657==_============
Content-Id: <v04210123b4f8508d6289@[132.250.92.151].0.0>
Content-Type: text/plain; name="draft-ietf-rmt-norm-bb-00.txt"; charset="us-ascii" ; format="flowed"
Content-Disposition: attachment; filename="draft-ietf-rmt-norm-bb-00.txt"
; modification-date="Fri, 17 Mar 2000 14:40:08 -0500"
RMT Working Group B. Adamson
INTERNET-DRAFT C. Borman
draft-ietf-rmt-norm-bb-00.txt S. Floyd
Expires: Jul 2000 M. Handley
J. Macker
15 March 2000
NACK-Oriented Reliable Multicast (NORM) Protocol Building Blocks
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other docu-
ments at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (1999). All Rights Reserved.
Abstract
This memo describes issues related to the creation of NACK-oriented
reliable multicast protocols (NORM). The general goals and assump-
tions for NORM are defined. Some issues related to NACK-oriented
(and in some cases general) reliable multicast protocol design are
identified. These issues are resolved into a number of "building
block" components which are described in further detail. It is
anticipated that these building block components (as they are fur-
ther refined and defined in future revisions of this document) will
be useful in generating different instantiations of NACK-oriented
reliable multicast protocols.
Adamson, Borman, et al. Expires September 2000 [Page 1]
Internet Draft NORM Building Blocks March 2000
1.0 Background
Reliable multicast transport is a desirable technology for the
efficient and reliable distribution of data to a group on the
Internet. The complexity of group communication paradigms necessi-
tates the creation of different protocol types and instantiations
to meet the range of performance and scalability requirements of
different potential reliable multicast applications and users
[Mankin98]. Properly designed negative acknowledgement (NACK)
based reliable multicast protocols offer scalability advantages for
applications and/or network topologies where, for various reasons,
it is prohibitive to construct a higher order delivery infrastruc-
ture above the basic Layer 3 IP multicast service (e.g. unicast or
hybrid unicast/multicast data distribution trees). Additionally,
the scalability property of NACK-oriented protocols [Pingali93,
Levine96] may be applicable where broad "fanout" is expected for a
single network hop (e.g. cable-TV data delivery, satellite, or
other broadcast communication communication services). Further-
more, the simplicity of a protocol based on "flat" group-wide mul-
ticast distribution may offer advantages for a broad range of dis-
tributed services or dynamic networks and applications.
While different protocol instantiations may be required to meet
specific application and network architecture demands [Clark90],
there are a number of fundamental components which may be common to
these different instantiations. This document describes the frame-
work and common "building block" components relevant to multicast
protocols based primarily on NACK operation for reliable transport.
2.0 Goals and Assumptions
Each potential protocol instantiation derived from the building
blocks presented here (and other applicable building block docu-
ments) will have specific criteria which will influence individual
protocol design. To support the development of applicable building
blocks, it is useful to define the categories of these driving pro-
tocol design goals and assumptions. Some general categories which
are likely to impact protocol instantiation design are described in
the sections below. These are areas which each protocol instantia-
tion will need to address.
2.1 Data content model
The implicit goal of a reliable multicast protocol is the reliable
delivery of "data" among a group of participants communicating
through IP multicast datagram service. However, the nature of the
data content and the service the application is attempting to pro-
vide can impact design decisions. The service model may range from
Adamson, Borman, et al. Expires September 2000 [Page 2]
Internet Draft NORM Building Blocks March 2000
long-lived transfer sessions of bulk quantities of data (file
broadcast) to more interactive exhanges of small messages (e.g.
white-boarding, text chat). And within those different models
there are other issues such as the sender's ability to cache trans-
mitted data (or state referencing it) for retransmission or repair.
The need for ordering and/or causality in the sequence of transmis-
sions/receptions among participants in the group can be a function
of the data content. The group communication paradigm differs sig-
nificantly from the point-to-point model in that, depending upon
the data content type, some receivers may complete reception of a
portion of data content and be able to act upon it before other
participants have received the content. This may be acceptable (or
even desirable) for some applications but not for others. These
varying requirements drives the need for a number of different pro-
tocol instantiation designs.
A significant challenge in developing generally useful building
block mechanisms is accommodating even a limited range of these
capabilities without defining specific application-level details.
Note that this particular building block "guideline" may be gener-
ally applicable beyond the realm of NACK-oriented reliable multi-
cast.
2.2) Group membership dynamics
Group communication can differ from point-to-point communications
with respect to the fact that even if the composition of the group
changes, the "thread" of communication can still exist. This con-
trasts with the point-to-point communication model where, if either
of the two parties leave, the communication process (exchange of
data) is terminated (or at least paused). Depending upon applica-
tion goals, senders and receivers participating in a reliable mul-
ticast transport "session" may be able to join late, leave, and/or
potentially rejoin while the ongoing group communication "thread"
still remains functional and useful.
Also note that this can impact protocol message content. If "late
joiners" are supported, some amount of additional information may
be placed in message headers to accommodate this functionality.
Alternatively, the information may be sent in its own message (on
demand or intermittently) if the impact to the overhead of typical
message transmissions is deemed too great. Group dynamics can also
impact other protocol mechanisms such as NACK or other timing, con-
gestion control operation, etc.
2.3) Sender/receiver relationships
The relationship of senders and receivers among group participants
Adamson, Borman, et al. Expires September 2000 [Page 3]
Internet Draft NORM Building Blocks March 2000
requires consideration. In some applications, there may be a sin-
gle sender multicasting to a group of receivers. In other cases,
there may be more than one sender or the potential for everyone in
the group to be a sender _and_ receiver of data may exist.
2.4) Group size
Native IP multicast [Deering89] may scale to extremely large group
sizes. It may be desirable for some applications to be able to
scale along with the multicast infrastructure's ability to scale.
In its simplest form, there are limits to the group size to which a
NACK-oriented protocol can apply without NACK implosion problems,
but with the potential for router assistance or other non-linear
NACK suppression mechanisms, these protocols may scale to very
large group sizes. In large scale cases, it may be prohibitive for
participants to maintain state on all other participants (in par-
ticular, other receivers) in the group. The impact of group size
needs to be considered in the development of generally applicable
building blocks.
2.5) Data delivery performance
There is a trade-off between scalability and data delivery latency
when designing NACK-oriented protocols. If NACK suppression is to
be used, there will be some delays built into the NACK generation
and repair transmission process to allow suppression to occur and
for the sender of data to identify appropriate content for effi-
cient repair transmission. For example, backoff timeouts can be
used to ensure efficient NACK suppression and repair transmission,
but this comes at a cost of increased delivery latency and
increased buffering requirements for both senders and receivers.
The building blocks should allow applications to establish bounds
for data delivery performance. Note that application designers
must be aware of the scalabilty trade-off which is made when such
bounds are applied.
2.6) Network topology
The Internet Protocol has historically assumed a role of providing
service across heterogeneous network topologies. It is desirable
that a reliable multicast protocol be capable of effectively oper-
ating across a wide range of the networks to which general purpose
IP service applies. Recently, a number of asymmetric network ser-
vices including 56K/ADSL modems, CATV Internet service, satellite
and other wireless communication services have begun to prolifer-
ate. Many of these are inherently broadcast media with potentially
large "fanouts" to which IP multicast service is highly applicable.
Adamson, Borman, et al. Expires September 2000 [Page 4]
Internet Draft NORM Building Blocks March 2000
Additionally, policy and/or technical issues may result in topolo-
gies where multicast connectivity is limited to a single logical
direction from a specific source or set of sources to the group at
large. Receivers in the group may be restricted to unicast feed-
back for NACKs and other messages. Consideration must be given, in
building block development and protocol design, to the nature of
the underlying networks over which the protocols may be operating.
2.7) Router/Intermediate System Assistance
While intermediate assistance from devices/systems with direct
knowledge of the underlying network topology may used to leverage
the performance and scalability of reliable multicast protocols,
there will continue to be a number of instances where this is not
available or practical. Any building block components for NACK-
oriented reliable multicast should be capable of operating without
such assistance but should also be capable of utilizing these fea-
tures when available.
3.0 Building Block Areas
(Aside: OK. We've presented in general what building blocks are
intended to be and some of the critera which may affect building
block identification/ design. So now let's list possible building
blocks. Some of these may be unique to NACK-oriented protocols
while some may be more generally applicable)
This section describes different building block areas applicable to
NACK-oriented reliable multicast protocols. Some of these areas
are specific to NACK-oriented protocols. Detailed descriptions of
such areas are provided below. In other cases, the areas (e.g.
node identifiers, FEC, etc) may be generally applicable to other
forms of reliable multicast. In those cases, the discussion below
describes requirements placed on those other general building block
areas from the standpoint of NACK-oriented reliable multicast.
For the individual building blocks to be incorporated as part of a
specific protocol instantiation, it expected that a description of
some notional "interface" to the building blocks' functionality be
provided. For example, a building block component may require some
form of "input" from another building block component or other
source in order to perform its function. Any "inputs" required by
each building block component and/or any resultant "output" pro-
vided by the building block will be defined and described as the
building block component's interface definition.
The following building block areas are described below:
Adamson, Borman, et al. Expires September 2000 [Page 5]
Internet Draft NORM Building Blocks March 2000
(NACK-Oriented Components)
1) Sender transmission
2) NACK-oriented Repair Process
3) "Late-joining" Receiver Policies and Mechanisms
(Generally-applicable Conponents)
4) Participant Identification
5) Data Content Identification
6) Forward Error Correction
7) Round-trip Timing Collection
8) Group Size Determination/Estimation
9) Congestion Control Operation
10) Router/Intermediate System Assistance
11) Additional Protocol Mechanisms
3.1 Sender transmission
Senders will transmit data content to the multicast session. The
data content will be application dependent. The sender will trans-
mit data content at a rate and with packet sizes determined by
application and/or network architecture requirements. When conges-
tion control mechanisms are used (recommended), the transmission
rate will be controlled by the congestion control mechanism. It is
recommended that all data transmissions from senders be subject to
rate limitations determined by the application or congestion con-
trol algorithm. The sender's transmissions should make good utl-
ization of the available capacity (either application or congestion
control specified). As a result, it is expected there will be
overlap and multiplexing of new data content transmission with
repair content.
Other sender messages or commands may be employed as part of proto-
col operation. For NACK-oriented operation, the reliability of any
such commands may depend upon redundant transmission. Other fac-
tors related to NACK-oriented operation may determine sender trans-
mission formats and methods. Some consideration may need to be
given to the sender's behavior during intermittent idle periods
when it has no data to transmit. While many aspects may be proto-
col-specific, there are techniques which may be generally applica-
ble to NACK-oriented reliable multicast. For example, the period-
icity of redundant transmission of command messages issued by a
sender should be dependent upon the greatest round trip timing
estimate and the resultant NACK operation. More specifically, a
command message might be redundantly transmitted by a sender to
indicate that it is temporarily (or permanently) halting transmis-
sion. At this time, it may be appropriate for receivers to respond
with NACKs for any outstanding repairs they require following the
rules of the NACK process described below. For efficiency, the
Adamson, Borman, et al. Expires September 2000 [Page 6]
Internet Draft NORM Building Blocks March 2000
sender whould allow sufficient time between redundant transmissions
to receive any NACK-oriented responses from the receiver set to
this command. Other protocol components may benefit from a similar
approach.
Inputs:
1) Data content
2) Segmentation size
3) Transmission rate
Outputs:
1) Rate-controlled stream of packets with headers uniquely
identifying data or repair content within the context of the
reliable multicast session.
3.2 NACK-oriented repair process
The most critical component of the NACK-oriented reliable multicast
protocol building block is the NACK repair process. There are four
primary elements of a general NACK repair process:
1) Method for determining when receivers will initiate the NACK
process in response to sender transmission for which they
need repair.
2) NACK message content.
3) NACK suppression mechanisms to promote scalability of the
protocol.
4) Sender NACK reception, aggregation, and repair response.
3.2.1 NACK Process Initiation
The NACK process (cycle) will be initiated by receivers who detect
they require repair transmissions from a specific sender at defined
opportunities. When FEC is applied, a NACK cycle should only be
initiated when it is known by the receiver that its repair require-
ments exceed the amount of FEC pending transmission for a given
coding block of packets. This may be determined by the receiver if
the sender's transmission advertises the quantity of repair packets
it is already planning to send for a block, and/or at the end of
the current transmission block (if it is indicated) or at the start
of subsequent coding block for packets transmitted within the con-
text of a designed data content set (See object/stream data content
identifier discussion below).
Allowing receivers to initiate NACK cycles at any time they detect
Adamson, Borman, et al. Expires September 2000 [Page 7]
Internet Draft NORM Building Blocks March 2000
their repair needs have exceeded pending repair transmissions may
result in slightly quicker repair cycles. However, it may be use-
ful to limit the initiation opportunities to specific events such
as at the end-of-transmission of an FEC coding block (or alterna-
tively at detection of subsequent coding blocks). This can allow
for a degree of synchronization among receivers requesting repair
and may increase the effectiveness of timer-based NACK suppression
mechanisms. In either case, the NACK cycle should begin with
receivers observing backoff timeouts to facilitate NACK suppression
as described below.
Interface Description
Inputs:
1) Object/stream data content and sequencing identifiers from
sender transmissions.
Outputs:
1) NACK Process Initiation Decision
3.2.2 NACK Content
(TBD - Note this will be driven by the data content identification
means used. Certainly, FEC repair counts will be needed, but
encoding of more explicit repair information may be useful for
other purposes (e.g. decorrelating loss clusters to help congestion
control mechanism identify bottlenecks.)
3.2.3 NACK Suppression Mechanisms
A primary NACK suppression mechanism is the use of initial backoff
timeouts by receivers wishing to transmit NACK messages[Floyd95].
Upon expiration of the timeout, a receiver will transmit a NACK
unless the content of his pending repair request is completely
superseded by NACK messages heard from other receivers (when
receivers are multicasting NACKs) or from some indicator from the
sender . (Note: When receivers are unicasting NACK messages, the
sender may facilitate NACK suppression by forwarding appropriate
NACKs it has received to the group at large or provide some other
indicator of repair information it will be subsequently transmit-
ting).
The backoff timeout periods used by receivers should be indepen-
dently, randomly picked by receivers with an exponential distribu-
tion [Nonnemacher98]. This results in the bulk of the receiver set
holding off transmission of NACK messages under the assumption that
Adamson, Borman, et al. Expires September 2000 [Page 8]
Internet Draft NORM Building Blocks March 2000
the smaller number of "early NACKers" will supersede the repair
needs of the remainder of the group. The mean of the distribution
should be determined as a function of the current estimate of
sender<->group greatest round trip time (GRTT) and a group size
estimate which could be determined by other mechanisms within the
protocol (See discussion below) or preset by the multicast applica-
tion. (This function TBD) For small group sizes (and even for large
group sizes) the tail of the distribution should be hard-limited so
that repair requests are deterministically transmitted within some
desirable interval. Additionally, the buffering limitations of
sender and receiver applications may dictate some bound on the time
limits for receiver NACK backoff timeouts (and sender repair aggre-
gation holdoff timeouts). Note that these factors affect scalabil-
ity of the protocol to large group sizes due to increased potential
for NACK implosion.
There are some secondary NACK suppression mechanisms which can be
considered. For example, the sender's transmissions follow some
ordinal sequence of transmission (observed through data/repair con-
tent <objectIds> and/or <segmentIds>) which is "rewound" during
repair transmissions. Receivers may wish to limit transmission of
their NACKs only when the sender's current sequence of transmission
passes the point at which the receiver has incomplete transmis-
sions, thus reducing premature requests for repair of data the
sender may be providing in response to other receiver requests.
This mechanism can be very effective for protocol convergence in
high loss conditions when transmissions of NACKs from other
receivers (or indicators from the sender) are lost. Another mecha-
nism (particularly applicable when FEC is used) is for the server
to embed an indication of impending repair transmissions in current
packets sent. For example, the indication may be as simple as an
advertisment of the number of FEC packets to be sent for the cur-
rent applicable coding block. Finally, some consideration might be
given to using the NACKing history of receivers to weight their
selection of NACK backoff timeout intervals. For example, if a
receiver has historically been experiencing the greatest degree of
loss, it may promote itself to statistically NACK sooner than other
receivers. Note this assumes there is some degree of correlation
over successive intervals of time in the loss experienced by
receivers. This adjustment of backoff timeout selection may
require the creation of an "early NACK" slot for these historical
NACKers. This additional slot in the NACK backoff window will
result in a longer repair cycle process which may not be desirable
for some applications. The resolution of these trade-offs may be
dependent upon the protocol's target application set or network.
Interface Description
Adamson, Borman, et al. Expires September 2000 [Page 9]
Internet Draft NORM Building Blocks March 2000
Inputs:
1) Group greatest round trip time estimate (GRTT).
2) Group size estimate.
3) Application-defined bound on backoff timeout period.
4) NACKs from other receivers.
5) Pending repair indication from sender (may be forwarded
NACKs).
6) Current sender transmission position.
Outputs:
1) Yes/no decision to generate NACK message upon backoff timer
expiration.
3.2.4 Sender NACK Processing and Repair Response
Upon reception of a repair request from a receiver in the group,
the sender will initiate a repair response procedure. The sender
may wish to delay transmission of repair content until it has had
sufficient time to accumulate potentially multiple NACKs from the
receiver set. This allows the sender to determine the most effi-
cient repair strategy for a given transport stream/object or FEC
coding block. Depending upon the approach used, some protocols may
find it beneficial for the sender to provide an indicator of pend-
ing repair transmissions as part of the its current transmitted
message content. This can aid some NACK suppression mechanisms.
Alternatively, in the case of unicast feedback from the receiver
set, it may be useful for the sender to forward (via multicast)
superseding NACK messages to the group to allow for NACK suppres-
sion when there is not multicast connectivity among the receiver
set.
When FEC is used, it is beneficial that the sender transmit previ-
ously untransmitted parity content whenever possible. This maxi-
mizes the receiving nodes' ability to reconstruct the entire trans-
mitted content from their individual subsets of received messages.
The transmitted he object and/or stream content will be marked with
monotonically increasing sequence numbers (within a reasonably
large ordinal space). If the sender observes the discipline of
transmitting repair for the earliest content first, the receivers
can use a strategy of witholding repair requests for later content
until the sender once again returns to that point in the
object/stream transmission sequence. This can increase overall
message efficiency among the group and help work to keep repair
cycles relatively synchronized without dependence upon strict tim-
ing. This also helps minimize the buffering requirements of
Adamson, Borman, et al. Expires September 2000 [Page 10]
Internet Draft NORM Building Blocks March 2000
receivers and senders and reduces redundant transmission of data to
the group at large.
Interface Description
Inputs:
1) Receiver NACKs
1) Group timing information
Outputs:
1) Repair messages (FEC and/or Data content retransmission)
3.3 Group "Join" Policy/ Procedure
(TBD - What does the protocol need to do accommodate group member-
ship dynamics? For example, what policies do receivers need to
abide by to join a group and begin NACKing? What information needs
to be advertised in protocol message headers so that a receiver can
efficiently join a session in progress? etc)
Inputs:
1) Current object/stream data/repair content and sequencing
identifiers from sender transmissions.
Outputs:
1) Receiver yes/no decision to begin receiving and NACKing for
reliable reception of data
3.4 Reliable multicast participant identification
In a NACK-based reliable multicast protocol (or other multicast
protocols) where there is the potential for multiple sources of
data, it is necessary to provide some mechanism to uniquely iden-
tify the sources (and possibly some or all receivers in some cases)
within the group. Identity based on arriving packet source
addresses is insufficient for several reasons. These reasons
include routing changes for hosts with multiple interfaces which
result different packet source addresses for a given host over
time, network address translation (NAT) or firewall devices, or
other transport/network bridging approaches. As a result, some
type of unique source identifier (sourceId) field should be present
in packets transmitted by reliable multicast session participants.
3.5 Data content identification
Adamson, Borman, et al. Expires September 2000 [Page 11]
Internet Draft NORM Building Blocks March 2000
The data content transmitted by the multicast sender requires some
form of identification in the protocol header fields. This identi-
fication is required to facilitate the reliable NACK-based repair
process. These identifiers will be used in NACK messages gener-
ated.
There are two very general types of data which may comprise bulk
transfer session content. These data types are static objects of
finite size and continuous non-finite streams. A given application
may wish to reliably multicast data content using either one or
both of these data models. While it may be possible for some
applications to further generalize this model and provide mecha-
nisms to encapsulate static objects as content embedded within a
stream, there are advantages to many applications to provide dis-
tinct support for static bulk objects and messages with the context
of a reliable multicast session. These applications may include
content caching servers, file transfer or collaborative tools with
bulk content. Applications with requirements for these static
object types can then take advantage of transport layer mechanisms
(i.e. segmentation/reassembly, caching, integrated forward error
correction coding, etc) rather than being required to provide their
own mechanisms for these functions at the application layer.
As noted, some applications may alternatively desire to transmit
bulk content in the form of one or more streams of non-finite size.
Example streams include continuous quasi-realtime message broad-
casts (e.g. stock ticker) or some content types which are part of
collaborative tools or other more complex applications. And, as
indicated above, some applications may wish to encapsulate other
bulk content (e.g. files) into one more streams within a multicast
session. Additionally, multiple streams can allow for parallized
transmission within the context of a single multicast session.
The components described within this building block draft document
are envisioned to be applicable to both of these models with the
potential for a mix of both types within a single multicast ses-
sion. To support this requirement, the normal data content identi-
fication should include a field to uniquely identify the object or
stream within some reasonable temporal or ordinal interval. Note
that it is _not_ expected that this data content identification
will be globally unique. It is expected that the object/stream
identifier will be unique with respect to a given sender within the
reliable multicast session.
Since the "bulk" object/stream content will generally require seg-
mentation, some form of segment identification must also be pro-
vided. This segment identifier will be relative to any object or
stream identifier which has been provided. Thus, in some cases,
Adamson, Borman, et al. Expires September 2000 [Page 12]
Internet Draft NORM Building Blocks March 2000
NACK-based protocol instantiations may be able to receive transmis-
sions of and NACK for repair of multiple streams and one (or possi-
bly more) sets of static objects in parallel.
Additionally, flags to determine the usage of the content identi-
fier fields (e.g. stream vs. object) may be applicable. Flags may
also serve other purposes in data content identification. It is
expected that any flags defined will be dependent upon individual
protocol instantiations.
In summary, the following data content identifiers may be required
to NACK-based protocols:
1) Object/Stream identifier (<objectId>)
2) Segment identifier (<segmentId>)
3) Flags to differentiate interpretation of identifier fields
or identifier structure which implicitly indicates usage.
These fields have been identified since any generated NACK messages
will use these identifiers in requesting repair or retransmission
of data. NACK-based protocols are expected to greatly benefit from
interaction with other reliable multicast building blocks (Generic
Router Assist(GRA), in particular) and those other building blocks
will need to appropriately consider these anticipated requirements.
3.6 Forward Error Correction
Multiple forward error correction (FEC)approaches have be identi-
fied which can provide great performance enhancements to the repair
process of NACK-based and other reliable multicast protocols [Met-
zner84, Macker97]. NACK-based protocols can reap additional bene-
fits since FEC-based repair does not _generally_ require explicit
knowledge of repair content within the bounds of its coding block
size (in packets).
Generally, repair packets generated using FEC algorithms with good
erasure filling properties (e.g. Reed-Solomon) will be transmitted
only in response to NACK repair requests from receiving nodes.
However, there are benefits in some network environments for trans-
mitting some predetermined quantity of FEC repair packets multi-
plexed with the regular data segment transmissions [Gossink98].
This can reduce the amount of NACK traffic generated with rela-
tively little overhead cost when group sizes are very large or the
network connectivity has a large delay*bandwidth product with some
nominal level of expected packet loss. While the application of
FEC is not unique to NACK-based protocols, these cumulative
requirements may dictate the types of algorithms and protocol
approaches applicable to NACK-based protocols.
Adamson, Borman, et al. Expires September 2000 [Page 13]
Internet Draft NORM Building Blocks March 2000
A specific issue related to the use of FEC with NACK-based proto-
cols is the mechanism used to identify which portion(s) of trans-
mitted data content to which specific FEC packet are applicable.
It is expected that FEC algorithms will be based on generating a
set of parity repair packets for a corresponding block of transmit-
ted data packets. Since data content packets are uniquely identi-
fied by the concatenation of <sourceId/objectId/segmentId> during
transport, it is expected that FEC packets will be identified in a
similar manner. It may be sufficient to identify FEC packets using
the <sourceId/objectId/segmentId> of the first segment of the block
of data content packets for which the FEC repair packet is applica-
ble and add an additional FEC identifier <fecId> field to its posi-
tion within the set of FEC packets for the block. The size of the
<fecId> field can potentially be small (8 or 16 bits) relative to
other identifier fields since its size is limited by the FEC coding
algorithm used.
3.7 Round-trip Timing Collection
(TBD - There are tradeoffs here ... one-to-many vs. many-to-many
protocol operation, etc)
3.8 Group Size Determination/Estimation
(TBD)
3.9 Congestion Control Operation
(TBD - A NACK-oriented protocol may place limitations/requirements
on collection of information to facilitate congestion control of
senders. There are a number of specific issues of TCP-Friendly
Multicast Congestion Control (TFMCC)which must be addressed.)
3.10 Router/Intermediate System assistance
(TBD - NACK-oriented protocols can potentially benefit greatly from
router assistance. In particular, additional NACK suppression
would be beneficial (This may impact how synchronized receiver NACK
cycles are, sender advertisement of NACK-cycle parameters (i.e.
GRTT, group size, etc), NACK content, others)
3.11 Additional protocol mechanisms
(TBD- e.g. positive acknowledgement collection, performance statis-
tics collection, session management, etc)
4.0 Security Considerations (TBD)
Adamson, Borman, et al. Expires September 2000 [Page 14]
Internet Draft NORM Building Blocks March 2000
5.0 References
[Mankin98] A. Mankin, A. Romanow, S. Bradner, V. Paxson, "IETF Cri-
teria for Evaluating Reliable Multicast Transport and Application
Protocols", RFC 2357, June 1998.
[Pingali93] S. Pingali, D. Towsley, J. Kurose. "A Comparison of
Sender-Initiated and Receiver-Initiated Reliable Multicast Proto-
cols". In Proc. INFOCOM, San Francisco, CA, October 1993.
[Levine96] B.N. Levine, J.J. Garcia-Luna-Aceves. "A Comparison of
Known Classes of Reliable Multicast Protocols", Proc. International
Conference on Network Protocols (ICNP-96), Columbus, Ohio, Oct
29--Nov 1, 1996.
[Clark90] D. Clark, D. Tennenhouse, "Architectural Considerations
for a New Generation of Protocols". In Proc. ACM SIGCOMM, pages
201--208, September 1990.
[Deering89] S. Deering. "Host Extensions for IP Multicasting".
Internet RFC1112, August 1989.
[Floyd95] S. Floyd, V. Jacobson, S. McCanne, C. Liu, and L. Zhang.
"A Reliable Multicast Framework for Light-weight Sessions and
Application Level Framing", Proc. ACM SIGCOMM, August 1995.
[Nonnenmacher98] J. Nonnenmacher and E. W. Biersack, "Optimal mul-
ticast feedback," in IEEE Infocom , (San Francisco, California), p.
964, March/April 1998.
[Gossink98] D. Gossink, J. Macker, "Reliable Multicast and Inte-
grated Parity Retransmission with Channel Estimation", IEEE GLOBE-
COM 98'.
[Metzner84] J. Metzner, "An Improved Broadcast Retransmission Pro-
tocol", IEEE Transactions on Communications, Vol. Com-32, No.6,
June 1984.
[Macker97a] J. Macker, "Integrated Erasure-Based Coding for Reli-
able Multicast Transmission", IRTF Meeting presentation, March
1997.
[Macker97b] J. Macker, "Reliable Multicast Transport and Integrated
Erasure-based Forward Error Correction", Proc. IEEE MILCOM 97, Oct
1997.
Adamson, Borman, et al. Expires September 2000 [Page 15]
Internet Draft NORM Building Blocks March 2000
6.0 Authors' Addresses
Brian Adamson
adamson@itd.nrl.navy.mil
Newlink Global Engineering Corporation
8580 Cinder Bed Road, Suite 1000
Newington, VA, USA, 22122
Dr. Carsten Borman
cabo@tzi.org
Universit"^Hat Bremen
Postfach 330 440
D - 28334 Bremen, Germany
Sally Floyd
floyd@aciri.org
1947 Center Street, Suite 600
Berkeley, CA 94704
Mark Handley
mjh@aciri.org
1947 Center Street, Suite 600
Berkeley, CA 94704
Joe Macker
macker@itd.nrl.navy.mil
Naval Research Laboratory
Washington, DC, USA, 20375
Adamson, Borman, et al. Expires September 2000 [Page 16]
--============_-1258794657==_============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Brian
__________________________________
Brian Adamson
<http://manimac.itd.nrl.navy.mil>
<mailto:adamson@itd.nrl.navy.mil>
--============_-1258794657==_============--
>From owner-rmt@listserv.lbl.gov Mon Mar 20 04:43:35 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id EAA05155;
Mon, 20 Mar 2000 04:41:36 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id EAA05151
for <rmt@listserv.lbl.gov>; Mon, 20 Mar 2000 04:41:34 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id EAA11834
for <rmt@listserv.lbl.gov>; Mon, 20 Mar 2000 04:41:34 -0800 (PST)
Received: from motgate.mot.com (motgate.mot.com [129.188.136.100])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id EAA11831
for <rmt@lbl.gov>; Mon, 20 Mar 2000 04:41:33 -0800 (PST)
Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (motgate 2.1) with ESMTP id FAA07320; Mon, 20 Mar 2000 05:41:32 -0700 (MST)]
Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [217.1.10.38]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id FAA08893; Mon, 20 Mar 2000 05:41:29 -0700 (MST)]
Received: from motorola.com ([217.2.31.112])
by homer.arc.corp.mot.com (8.9.3/8.9.3) with ESMTP id XAA21291;
Mon, 20 Mar 2000 23:41:26 +1100 (EST)
Message-ID: <38D61C51.36C0EDA@motorola.com>
Date: Mon, 20 Mar 2000 23:40:49 +1100
From: Roger Kermode <Roger.Kermode@motorola.com>
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: rmt-list <rmt@lbl.gov>
CC: Allison Mankin <mankin@EAST.ISI.EDU>, Lorenzo Vicisano <lorenzo@cisco.com>
Subject: Draft RMT agenda: PLS send comments
Content-Type: multipart/mixed;
boundary="------------FA190BEEAD9367C8B094B307"
Sender: owner-rmt@lbl.gov
Precedence: bulk
This is a multi-part message in MIME format.
--------------FA190BEEAD9367C8B094B307
Content-Type: multipart/alternative;
boundary="------------406FE68B19589A6083E9D5C9"
--------------406FE68B19589A6083E9D5C9
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Dear Everyone,
below is a first pass at the Agenda for Adelaide.
If we just do presentations with minimal discussions,
we'll just about fill one of our two sessions. If there
are additional items please let me know ASAP. We will
adjust the agenda to include the additional items and
to allow for more discussions in a couple of days time.
cheers,
Roger
----------------------------------------------------------------
Reliable Multicast Transport WG (rmt)
Tuesday, March 28 at 0900-1130
Wednesday, March 29 at 0900- 1130
=================================
CHAIRS: Roger Kermode <Roger.Kermode@motorola.com>
Lorenzo Vicisano <lorenzo@cisco.com>
Allison Mankin <mankin@ isi.edu>
AGENDA:
Tuesday 28th March 2000, 09:00-11:30
- Introduction and Agenda Bashing
Kermode (5 mins)
- Design Space/Building Blocks draft progress
Vicisano (5 mins)
draft-ietf-rmt-design-space-01.txt
draft-ietf-rmt-buildingblocks-02.txt
- Guidelines Draft progress
Kermode (15 mins)
draft-ietf-rmt-author-guidelines-xx.txt
- FEC Building Block
Luby (20 mins)
draft-ietf-rmt-bb-fec-00.txt
- ALC Protocol Instantiation
Luby (20 mins)
draft-ietf-rmt-pi-alc-00.txt
- Track Archictecure
Whetten (20 mins)
draft-ietf-rmt-track-arch-xx.txt
- Tree Building
Levine ?? (20 mins)
- NACK-Oriented Reliable multicast Buoilding Block
Adamson (20 mins)
draft-ietf-rmt-norm-bb-00.tx
Wednesday 29th March 2000, 09:00-11:30
--------------406FE68B19589A6083E9D5C9
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<tt>Dear Everyone,</tt><tt></tt>
<p><tt>below is a first pass at the Agenda for Adelaide.</tt>
<br><tt>If we just do presentations with minimal discussions,</tt>
<br><tt>we'll just about fill one of our two sessions. If there</tt>
<br><tt>are additional items please let me know ASAP. We will</tt>
<br><tt>adjust the agenda to include the additional items and</tt>
<br><tt>to allow for more discussions in a couple of days time.</tt><tt></tt>
<p><tt>cheers,</tt><tt></tt>
<p><tt>Roger</tt>
<br><tt></tt>
<br><tt></tt>
<br><tt></tt> <tt></tt>
<p><tt>----------------------------------------------------------------</tt>
<br><tt>Reliable Multicast Transport WG (rmt)</tt>
<p><tt>Tuesday, March 28 at 0900-1130</tt>
<br><tt>Wednesday, March 29 at 0900- 1130</tt>
<br><tt>=================================</tt>
<p><tt>CHAIRS: Roger Kermode <Roger.Kermode@motorola.com></tt>
<br><tt> Lorenzo Vicisano <lorenzo@cisco.com></tt>
<br><tt> Allison Mankin <mankin@
isi.edu></tt>
<p><tt>AGENDA:</tt>
<p><tt>Tuesday 28th March 2000, 09:00-11:30</tt>
<p><tt>- Introduction and Agenda Bashing</tt>
<br><tt> Kermode (5 mins)</tt>
<p><tt>- Design Space/Building Blocks draft progress</tt>
<br><tt> Vicisano (5 mins)</tt>
<br><tt> draft-ietf-rmt-design-space-01.txt</tt>
<br><tt> draft-ietf-rmt-buildingblocks-02.txt</tt>
<p><tt>- Guidelines Draft progress</tt>
<br><tt> Kermode (15 mins)</tt>
<br><tt> draft-ietf-rmt-author-guidelines-xx.txt</tt>
<p><tt>- FEC Building Block</tt>
<br><tt> Luby (20 mins)</tt>
<br><tt> draft-ietf-rmt-bb-fec-00.txt</tt>
<p><tt>- ALC Protocol Instantiation</tt>
<br><tt> Luby (20 mins)</tt>
<br><tt> draft-ietf-rmt-pi-alc-00.txt</tt>
<p><tt>- Track Archictecure</tt>
<br><tt> Whetten (20 mins)</tt>
<br><tt> draft-ietf-rmt-track-arch-xx.txt</tt>
<p><tt>- Tree Building</tt>
<br><tt> Levine ?? (20 mins)</tt>
<p><tt>- NACK-Oriented Reliable multicast Buoilding Block</tt>
<br><tt> Adamson (20 mins)</tt>
<br><tt> draft-ietf-rmt-norm-bb-00.tx</tt>
<br>
<p><tt>Wednesday 29th March 2000, 09:00-11:30</tt></html>
--------------406FE68B19589A6083E9D5C9--
--------------FA190BEEAD9367C8B094B307
Content-Type: text/x-vcard; charset=us-ascii;
name="Roger.Kermode.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Roger Kermode
Content-Disposition: attachment;
filename="Roger.Kermode.vcf"
begin:vcard
n:Kermode;Roger
tel;cell:+61-408-212-284
tel;fax:+61-2-966-0501
tel;work:+61-2-9666-0558
x-mozilla-html:FALSE
url:www.motorola.com.au/arc/
org:Communications And Networking Lab;Motorola Australian Research Centre
adr:;;Locked Bag 5028;Botany;NSW;1455;Australia
version:2.1
email;internet:Roger.Kermode@motorola.com
title:Principal Research Engineer/Lab Manager
fn:Roger Kermode
end:vcard
--------------FA190BEEAD9367C8B094B307--
>From owner-rmt@listserv.lbl.gov Mon Mar 20 06:58:58 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id GAA06205;
Mon, 20 Mar 2000 06:57:03 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id GAA06201
for <rmt@listserv.lbl.gov>; Mon, 20 Mar 2000 06:57:01 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id GAA22991
for <rmt@listserv.lbl.gov>; Mon, 20 Mar 2000 06:57:00 -0800 (PST)
Received: from motgate.mot.com (motgate.mot.com [129.188.136.100])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id GAA22985
for <rmt@lbl.gov>; Mon, 20 Mar 2000 06:57:00 -0800 (PST)
Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (motgate 2.1) with ESMTP id HAA07710 for <rmt@lbl.gov>; Mon, 20 Mar 2000 07:56:58 -0700 (MST)]
Received: [from s-il02-e.comm.mot.com (s-il02-e.comm.mot.com [145.1.204.15]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id HAA24003 for <rmt@lbl.gov>; Mon, 20 Mar 2000 07:56:56 -0700 (MST)]
Received: by s-il02-e.comm.mot.com with Internet Mail Service (5.5.2650.21)
id <GRLRCS9Q>; Mon, 20 Mar 2000 08:44:33 -0600
Message-ID: <57B7E404C641D211A39A0008C7A4FBA701C05045@s-il02-q.comm.mot.com>
From: Avasthi Pradeep-CCOF59 <Pradeep.Avasthi@motorola.com>
To: rmt-list <rmt@lbl.gov>
Subject: remove
Date: Mon, 20 Mar 2000 08:44:30 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
charset="iso-8859-1"
Sender: owner-rmt@lbl.gov
Precedence: bulk
-----Original Message-----
From: Roger Kermode [mailto:Roger.Kermode@motorola.com]
Sent: Monday, March 20, 2000 6:41 AM
To: rmt-list
Cc: Allison Mankin; Lorenzo Vicisano
Subject: Draft RMT agenda: PLS send comments
Dear Everyone,
below is a first pass at the Agenda for Adelaide.
If we just do presentations with minimal discussions,
we'll just about fill one of our two sessions. If there
are additional items please let me know ASAP. We will
adjust the agenda to include the additional items and
to allow for more discussions in a couple of days time.
cheers,
Roger
----------------------------------------------------------------
Reliable Multicast Transport WG (rmt)
Tuesday, March 28 at 0900-1130
Wednesday, March 29 at 0900- 1130
=================================
CHAIRS: Roger Kermode <Roger.Kermode@motorola.com>
Lorenzo Vicisano <lorenzo@cisco.com>
Allison Mankin <mankin@ isi.edu>
AGENDA:
Tuesday 28th March 2000, 09:00-11:30
- Introduction and Agenda Bashing
Kermode (5 mins)
- Design Space/Building Blocks draft progress
Vicisano (5 mins)
draft-ietf-rmt-design-space-01.txt
draft-ietf-rmt-buildingblocks-02.txt
- Guidelines Draft progress
Kermode (15 mins)
draft-ietf-rmt-author-guidelines-xx.txt
- FEC Building Block
Luby (20 mins)
draft-ietf-rmt-bb-fec-00.txt
- ALC Protocol Instantiation
Luby (20 mins)
draft-ietf-rmt-pi-alc-00.txt
- Track Archictecure
Whetten (20 mins)
draft-ietf-rmt-track-arch-xx.txt
- Tree Building
Levine ?? (20 mins)
- NACK-Oriented Reliable multicast Buoilding Block
Adamson (20 mins)
draft-ietf-rmt-norm-bb-00.tx
Wednesday 29th March 2000, 09:00-11:30
>From owner-rmt@listserv.lbl.gov Mon Mar 20 11:59:32 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id LAA07263;
Mon, 20 Mar 2000 11:58:28 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id LAA07259
for <rmt@listserv.lbl.gov>; Mon, 20 Mar 2000 11:58:26 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id LAA26846
for <rmt@listserv.lbl.gov>; Mon, 20 Mar 2000 11:58:26 -0800 (PST)
Received: from pi4.informatik.uni-mannheim.de (root@pi4.informatik.uni-mannheim.de [134.155.48.96])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id LAA26836
for <rmt@lbl.gov>; Mon, 20 Mar 2000 11:58:25 -0800 (PST)
Received: from pi4.informatik.uni-mannheim.de (mauve@pi4 [134.155.48.96])
by pi4.informatik.uni-mannheim.de (8.9.3/8.9.3) with ESMTP id UAA06905;
Mon, 20 Mar 2000 20:58:16 +0100 (MET)
Message-ID: <38D682D8.39604EE8@pi4.informatik.uni-mannheim.de>
Date: Mon, 20 Mar 2000 20:58:16 +0100
From: Martin Mauve <mauve@pi4.informatik.uni-mannheim.de>
Organization: University of Mannheim
X-Mailer: Mozilla 4.08 [en] (X11; U; SunOS 5.6 sun4u)
MIME-Version: 1.0
To: Brian Adamson <adamson@itd.nrl.navy.mil>
CC: RMT <rmt@lbl.gov>
Subject: Re: Initial draft of NACK-Oriented Reliable Multicast Building Blocks
References: <v04210123b4f8508d6289@[132.250.92.151]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-rmt@lbl.gov
Precedence: bulk
Hi Brian, hi all,
I have read the NORM draft and I like it. There are two minor questions
I would like to ask:
1. How is the unique source ID supposed to be determined? I assume that
a collision would be unacceptable and that the ID should be small?
2. How long does the sender have to be prepared to retransmit any given
packet?
I do understand that these two questions might be out of scope for the
draft. However, I assume that a building block implementation would have
to worry about these things?
thanks,
Martin
--
---------------------------------------------------------------------------
Martin Mauve University of Mannheim
Praktische Informatik IV Phone: +49-621-181-2616
L 15,16 Fax : +49-621-181-2601
68131 Mannheim mauve@pi4.informatik.uni-mannheim.de
Germany
---------------------------------------------------------------------------
>From owner-rmt@listserv.lbl.gov Wed Mar 22 14:30:32 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id OAA18141;
Wed, 22 Mar 2000 14:28:40 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id OAA18137
for <rmt@listserv.lbl.gov>; Wed, 22 Mar 2000 14:28:38 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id OAA24981
for <rmt@listserv.lbl.gov>; Wed, 22 Mar 2000 14:28:37 -0800 (PST)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id OAA24968
for <rmt@lbl.gov>; Wed, 22 Mar 2000 14:28:35 -0800 (PST)
Received: from eastmail1.East.Sun.COM ([129.148.1.240])
by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA06818
for <rmt@lbl.gov>; Wed, 22 Mar 2000 14:28:33 -0800 (PST)
Received: from bcn.East.Sun.COM (bcn.East.Sun.COM [129.148.75.4])
by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id RAA01645;
Wed, 22 Mar 2000 17:28:30 -0500 (EST)
Received: from bridge (bridge [129.148.75.125])
by bcn.East.Sun.COM (8.9.1b+Sun/8.9.1) with SMTP id RAA09211;
Wed, 22 Mar 2000 17:28:26 -0500 (EST)
Message-Id: <200003222228.RAA09211@bcn.East.Sun.COM>
Date: Wed, 22 Mar 2000 17:28:20 -0500 (EST)
From: Dah Ming Chiu - Sun Microsystems <Dahming.Chiu@east.sun.com>
Reply-To: Dah Ming Chiu - Sun Microsystems <Dahming.Chiu@east.sun.com>
Subject: TRACK: Draft of TRACK architecture
To: rmt@lbl.gov
Cc: whetten@talarian.com, sanjoy@edgix.com, Miriam.Kadansky@east.sun.com
MIME-Version: 1.0
Content-Type: MULTIPART/mixed; BOUNDARY=Brace_of_Greyhounds_614_000
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc
Sender: owner-rmt@lbl.gov
Precedence: bulk
--Brace_of_Greyhounds_614_000
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: 6kPLopFrZC4PeG3SsrmZcA==
Hi,
Attached is a draft of the TRACK architecture document. We ran out of
time to resolve all the issues. The remaining issues are listed in an
"open issues" section at the end of the document. This is published
for discussion at the Adelaide meeting. Hopefully shortly after that
we will be able to put together a draft ID.
I apologize for not having managed to get the document in the correct
ID format. I think it is more important for me to send this out now
so that people going to adelaide can get a chance to look at it, rather
and delaying it.
I'd like to thank all for working hard on this, specially Brian Whetten
for putting the initial draft together, and Miriam for helping me get
the attached document ready.
Regards
Dah Ming
--Brace_of_Greyhounds_614_000
Content-Type: TEXT/plain; name="draft-whetten-track-architecture-xxrev06.txt"; charset=ISO-8859-1; x-unix-mode=0644
Content-Transfer-Encoding: QUOTED-PRINTABLE
Content-Description: draft-whetten-track-architecture-xxrev06.txt
Content-MD5: rlWTzw5/bnx7WCJaB7+dYg==
Reliable Multicast Transport (RMT) WG B. Whetten
Internet Draft Talarian
Document: draft-ietf-rmt-track-arch-xx.txt D.Chiu
Sun Microsystems
S.Paul
Edgix
March 22, 2000
TRACK ARCHITECTURE
A SCALEABLE REAL-TIME RELIABLE MULTICAST PROTOCOL
Status of this Memo
This document is an Internet-Draft and is in full conformance with=20
all provisions of Section 10 of RFC2026 [1].=20
Internet-Drafts are working documents of the Internet Engineering=20
Task Force (IETF), its areas, and its working groups. Note that=20
other groups may also distribute working documents as Internet-
Drafts. Internet-Drafts are draft documents valid for a maximum of=20
six months and may be updated, replaced, or obsoleted by other=20
documents at any time. It is inappropriate to use Internet- Drafts=20
as reference material or to cite them other than as "work in=20
progress."=20
The list of current Internet-Drafts can be accessed at=20
http://www.ietf.org/ietf/1id-abstracts.txt=20
The list of Internet-Draft Shadow Directories can be accessed at=20
http://www.ietf.org/shadow.html.
1. Abstract
One of the protocol instantiations the RMT WG is chartered to create=20
is a TRee-based ACKnowledgement protocol (TRACK). Rather than=20
create a set of monolithic protocol specifications, the RMT WG has=20
chosen to break the reliable multicast protocols in to Building=20
Blocks (BB) and Protocol Instantiations (PI). A Building Block is a=20
specification of the algorithms of a single component, with an=20
abstract interface to other BBs and PIs. A PI combines a set of=20
BBs, adds in the additional required functionality not specified in=20
any BB, and specifies the specific instantiation of the protocol.=20
For more information, see the Reliable Multicast Transport Building=20
Blocks and Reliable Multicast Design Space documents [2][3].
The TRACK protocol instantiation (TRACK for short) is designed to=20
reliably and efficiently send data from a single sender to large=20
groups of simultaneous recipients. It provides functions similar to=20
the NACK PI, and adds in support for a tree-based hierarchy (in its=20
simplest form may consist of only the sender as the Repair Head) of=20
Repair Heads, which increases scalability by providing aggregation=20
of control traffic and local retransmission of lost packets. In=20
addition to using negative acknowledgements (NACKs) and forward=20
error correction (FEC) for efficient reporting and retransmission of=20
lost packets, it also provides tree-based ACKnowledgements (ACKs). =20
ACKs provide the Sender with confirmation of delivery of data=20
packets to the Receivers. Like the NACK PI, it may also take=20
advantage of Generic Router Assist where available.
This document proposes a design rationale for the TRACK PI, an=20
architecture for TRACK, and a set of functional requirements TRACK=20
has of other Building Blocks. =20
2. Conventions Used in this Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=20
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in=20
this document are to be interpreted as described in RFC-2119 [4].
3. Design Rationale and Protocol Requirements
This section discusses many of the requirements imposed on the=20
design of the TRACK PI, as well as a design rationale which guides=20
the aspects where there is flexibility in selecting from different=20
potential design decisions.
3.1 Private and Public Networks
TRACK is designed to work in both private, controlled networks and=20
in the public Internet. A controlled network typically has a single=20
administrative domain, has more homogenous network bandwidth, and is=20
more easily managed and controlled. These networks have the fewest=20
barriers to IP multicast deployment and the most immediate need for=20
reliable multicast services. Deployment in the Internet requires a=20
protocol to span multiple administrative domains, over vastly=20
heterogeneous networks. The IETF is specifically chartered with=20
producing standards for the Internet, so this must be the primary=20
target network type. However, robust transport protocols are grown,=20
not created, and most of the short term deployment experience will=20
likely come from controlled networks. Therefore, TRACK is designed=20
to support both.
3.2 Manual vs. Automatic Controls
Some networks can take advantage of manual or centralized tools for=20
configuring and controlling the usage of a reliable multicast group. =20
In the public Internet, these tools have to fully distributed, and=20
preferably automatic, because they have to deal with the need to=20
span multiple AS=92s, each with their own policies. To address these=20
requirements, TRACK supports both manual and automatic algorithms=20
for monitoring, management, and configuration.
3.3 Heterogeneous Networks
While the majority of controlled networks are symmetrical and=20
support many-to-many multicast, in designing a protocol for the=20
Internet, it must deal with virtually all major network types. =20
These include asymmetrical networks, satellite networks, networks=20
where only a single node may send to a multicast group, and wireless=20
networks. TRACK takes this into account by not requiring any many-
to-many multicast services. In addition, the congestion control=20
component used in TRACK will specifically deal with the high=20
bandwidth-delay product faced in many satellite networks and the=20
high link level loss rate faced by some wireless networks. Finally,=20
TRACK does not assume that the topology used for sending control=20
packets has any congruence to the topology of the multicast address=20
used for sending data packets.
3.4 Use of Network Infrastructure=20
There is wide consensus that in order to scale a real-time reliable=20
multicast protocol, there must be some use made of the network=20
infrastructure (the routers and servers inside the network). New=20
software that supports the transport layer typically would run in=20
either the routers or the servers in the network, or both. =20
Deployment of router software (such as that in the Generic Router=20
Assist BB) is a powerful solution, but typically requires very long=20
time cycles, is of necessity limited in functionality, and requires=20
a graceful upgrade path. Server software (such as the Repair Head=20
control tree) is much easier to deploy, but may require new hardware=20
to be added to the network. =20
In controlled networks, particularly during the first deployment=20
phases of reliable multicast, it is reasonable to deploy servers=20
that only support a single application, or even to use selected end=20
clients themselves to perform the functions necessary for=20
scalability. For widely deployed Internet infrastructure=20
components, the server infrastructure is usually dedicated to just=20
the single protocol, but supports all instances of that protocol=20
running across that piece of the network. Examples of this usage=20
model include DNS, DHCP, NNTP, and HTTP. Therefore, the control=20
nodes used in TRACK are primarily designed to be run on dedicated=20
network servers, and support hundreds or thousands of simultaneous=20
data sessions over each server. Optionally, these components MAY=20
run on an end user computer. =20
A number of extensions to IP multicast, such as subtree multicast,=20
NACK suppression, ACK aggregation, tree configuration discovery, and=20
higher fidelity congestion control reports, have been proposed which=20
can run in the routers. If deployed widely, these would make=20
reliable multicast protocols easier to configure and to scale more=20
readily. Some or all of these features are being standardized as=20
part of the Generic Router Assist (GRA) component. TRACK is=20
designed to take advantage of GRA as it becomes available, but not=20
to require it. Ubiquitous deployment of GRA would likely reduce the=20
number of dedicated TRACK servers needed for large scale (i.e. more=20
than 1000 Receiver) deployments, and improve the performance of the=20
protocol.
3.5 Targeted Application Types
Multicast applications can be divided into two classes, few-to-many =20
and many-to-many. Many-to-many applications include server=20
replication, multi-user games, small group conferencing, and=20
computer supported collaborative work. These applications typically=20
treat all members in a group as peers, require special semantics=20
such as total ordering of messages from multiple Senders, and often=20
have moderate scalability requirements. Other protocols, such as=20
RMP [WMK94], have been designed to support these many-many=20
applications.
In line with the charter for RMT, TRACK focuses on one to many bulk=20
data distribution applications, such as multicast file transfer,=20
electronic software distribution, real time news and financial=20
market data distribution, "push" applications, audio/video/data=20
streaming, distance learning, and some types of server replication. =20
In order to meet these requirements, TRACK treats each Sender as an=20
independent entity, and provides no ordering or other shared state=20
across data sessions, although multiple data sessions can share the=20
same control infrastructure. The protocol is designed to scale to=20
at least many thousands of simultaneous Receivers. TRACK provides a=20
strong, but fully distributed membership protocol, which supports=20
scaling to many thousands of simultaneous Receivers while providing=20
confirmed delivery on messages. Similar to TCP, TRACK continuously=20
streams data to receivers, performing acknowledgement and=20
retransmission of older data packets at the same time that new data=20
packets are being sent. It also provides some special support for=20
real-time applications such as audio/video/data streaming and live=20
financial market data distribution.
TRACK meets a requirement of synchronous streaming applications with=20
a new reliability level called Time Bounded Reliability. Time=20
Bounded Reliability restricts recovery of packets to a limited time=20
interval. This keeps dropped packets from blocking the rest of a=20
synchronous data stream and helps prevent a failed Receiver from=20
affecting other Receivers.
3.6 IETF Mandated Criteria
In addition to the requirements imposed by the targeted network and=20
application types, TRACK is designed to meet all of the requirements=20
proposed by the IETF in RFC2357.
- Congestion Control. TRACK includes provably safe and TCP-friendly=20
congestion control algorithms that also scale to large groups.=20
- Well-controlled, Scaleable Behavior. TRACK includes carefully=20
analyzed algorithms that manage and smooth the control traffic and=20
retransmissions. These are key to avoiding NACK implosion, ACK=20
implosion, and retransmission implosion (the local recovery=20
pathology).
- Security. TRACK supports protection of the transport=20
infrastructure, through the use of lightweight authentication of=20
control and data packets.
3.7 Graceful Evolution
Creating robust, universally applicable standard protocols takes a=20
great deal of time and protocol evolution. While TRACK is being=20
written as a standard, it will have to continue to evolve as real=20
world experience is gained with the protocol, similar to how TCP has=20
been tuned over almost 20 years of research and development. TRACK=20
addresses this through its use of Building Blocks, which allow=20
particular algorithms to be broken out in to separate components=20
with well defined interfaces. This allows evolution of these=20
components, hopefully with little or no changes required to the rest=20
of the protocol. =20
TRACK also addresses this through its use of session parameters. =20
TRACK is presently dependent on a number of parameters which MUST be=20
configured throughout the tree for optimal operation. TRACK=20
provides mechanisms to automatically distribute these parameters to=20
all members of the group, and OPTIONALLY provides mechanisms to=20
dynamically change some of these parameters during group operation.
It also provides SNMP management and monitoring tools. Over time,=20
deployment experiences will provide input on which values work best=20
for most deployments, leading to further refinements of the=20
standard.=20
3.8 Algorithm Selection
The above design criteria applies to the general architecture of the=20
protocol. Additional criteria were used for selecting the optimal=20
algorithms for different sets of functions. These rationales are=20
described below, along with the individual functions they apply to.
4. Architectural Overview
4.1 TRACK Entities=20
4.1.1 Node Types
TRACK divides the operation of the protocol in to three major=20
entities: Sender, Receiver, and Repair Head. It is assumed that=20
Senders and Receivers typically run as part of an application on an=20
end host client. It is assumed that Repair Heads are components in=20
the network infrastructure, managed by different network managers as=20
part of different administrative domains. A Repair Head MAY be run=20
on an end host client, in which case it functions as both a Receiver=20
and a Repair Head. Absent of any automatic tree configuration, it=20
is assumed that the Repair Heads have relatively static=20
configurations, which consist of a list of nearby possible Repair=20
Heads. Senders and Receivers, on the other hand, are transient=20
entities, which typically only exist for the duration of a single=20
data session. Again, these entities MAY be used in other ways than=20
this, but this is the primary design rationale for TRACK. In=20
addition to these core components, applications that use TRACK are=20
expected to interface with other services that reside in other=20
network entities, such as multicast address allocation, session=20
advertisement, network management consoles, DHCP, DNS, server level=20
multicast, and multicast key management.
4.1.2 Multicast Group Address
A multicast group address is a pair consisting of an IP multicast=20
address and a UDP port number. It may optionally have a Time To=20
Live (TTL) value, although this value MUST only be used for=20
providing a global scope to a Data Session.=20
4.1.3 Data Session
A Data Session is the unit of reliable delivery of TRACK. It=20
consists of a sequence of sequentially numbered Data packets, which=20
are sent by a single Sender over a single Data Multicast Address. =20
They are delivered reliably, with acknowledgements and=20
retransmissions occurring over the Control Tree. It is uniquely=20
identified by a combination of a Session ID, senders address and=20
port, and the multicast address and port.=20
A given Data Session is received by a set of zero or more Receivers,=20
and a set of zero or more of Repair Heads. One or more Data=20
Sessions MAY share the same Data Multicast Address (although this is=20
not recommended). Each TRACK node can simultaneously participate in=20
multiple Data Sessions. A receiver MUST join all the Data Multicast=20
Addresses and Control Trees corresponding to the Data Streams it=20
wishes to receive.
4.1.4 Control Tree
A Control Tree is a hierarchical communication path used to send=20
control information from a set of Receivers, through zero or more=20
Repair Heads (RHs), to a Sender. It forms a tree, allowing the=20
interior nodes to aggregate this control information as it moves up=20
the tree. Each Data Session uses a Control Tree.
Each RH in the control tree uses a separate multicast address for=20
communicating with its children. Optionally, these RH multicast=20
addresses may be the same as the multicast address of the Data=20
Channel.
4.1.5 Session ID
A Session ID is a 32-bit number (to be formally defined in the=20
Common Packet Header BB) chosen either by the application that=20
creates the session or selected by TRACK. Senders and Receivers use=20
the Session ID to distinguish Data Streams. A Sender may specify a=20
Session ID in the range from (2^31) to (2^32)-1. Numbers in the=20
range from 0 to (2^31)-1 are reserved. If a sender specifies 0 as=20
the Stream ID, then TRACK randomly assigns a Stream ID in the range=20
from 1 to (2^31)-1. If a Session ID is selected that is already in=20
use on a Control Tree, the new stream will fail, and will need to=20
select a new Session ID.
A session is uniquely identified by its Session ID, its sender=92s=20
address/port, and its Data Multicast Address and port.
4.1.6 Packet Sequence Numbers
A packet sequence number is a 32 bit number in the range from 1=20
through 2^32 =96 1, which is used to specify the sequential order of a=20
Data packet in a Data Stream. A sender node assigns consecutive=20
sequence numbers to the Data packets provided by the Sender=20
application. Zero is reserved to indicate that the data session has=20
not yet started. =20
4.1.7 Data Queue
A Data Queue is a buffer, maintained by a Sender or a Repair Head,=20
for transmission and retransmission of the Data packets provided by=20
the Sender application. New Data packets are added to the data=20
queue as they arrive from the sending application, up to a specified=20
buffer limit. The admission rate of packets to the network is=20
controlled by flow and congestion control algorithms. Once a packet=20
has been received by the Receivers of a Data Stream, it may be=20
deleted from the buffer.
4.1.8 Packet Types
TRACK defines a set of packets, which can be implemented either on=20
top of UDP or directly on top of IP. All TRACK packets will conform=20
to the Common Packet Headers BB. Each TRACK packet definition=20
consists of a fixed header, zero or more option headers, followed by=20
data or control information.
Data is carried in Data packets. The same packet type is used both=20
to transmit Data the first time and for retransmissions of lost=20
packets (see open issue). Each Data packet has a Session ID and a=20
sequence number, which identify the packet and allow a receiver=20
application to reconstruct the data stream from the Data packets. =20
When a Data packet has been received by all Receivers, it is said to=20
have gone stable.
Receivers and Repair Heads unicast periodic status packets to their=20
parents. An ACK is sent regularly to indicate the status of the=20
Data packets which have arrived and to furnish congestion control=20
statistics about the state of data reception at the node. An ACK=20
requests retransmission of Data packets that have not been received. =20
An ACK also acknowledges packets that have become stable. A packet=20
becomes stable when it has been received by enough Repair Heads and=20
Receivers that the sender is no longer required to hold the packet=20
for retransmission. A NACK is an ACK that is used to request=20
immediate recovery of lost Data packets. ACKs and NACKs have the=20
same format, but ACKs are passed all the way up the tree, while=20
NACKs are only sent as far as needed to find a node which can=20
provide all the requested retransmissions. A child will also send=20
an ACK in response to a NullData or Heartbeat packet if it has not=20
sent an ACK within a certain time interval.
When a Receiver or Repair Head wishes to establish a repair service=20
relationship, it uses a Bind packet to bind to a parent Repair Head.=20
A parent sends an Accept or Reject after it processes a Bind packet.
The Reject message comes with a reason code that explains the reason=20
for rejection. The reason may indicate that the parent is not=20
connected into the tree yet, so that the receiver can try again=20
later (see open issue).
When a Receiver or Repair Head wishes to leave a session, it sends a=20
Leave request to its parent. The parent replies with a LeaveConfirm=20
packet, at which time the child is allowed to leave.
A Repair Head or Sender periodically sends Heartbeat packets to=20
notify its child nodes that it is alive.=20
If a Sender has no data to send for a session, it periodically
multicasts a NullData packet on the Data Multicast Address. =20
NullData packets inform receivers about the state of the Data Stream=20
and the Sender. =20
If a child node is not operating normally, or a parent node restarts
after a failure and receives a packet from a child not in its child=20
list, then the parent node sends an Eject packet to the child node. =20
4.2 Basic Operation of the Protocol
For each Data Session, TRACK provides sequenced, reliable delivery=20
of data from a single Sender to up to tens of thousands of=20
Receivers. A TRACK Data Session consists of a network that has=20
exactly one Sender node, zero or more Receiver nodes and zero or=20
more Repair Heads.
The figure below illustrates a TRACK Data Session with multiple=20
Repair Heads.
=20
A Sender joins the TRACK tree and multicasts data packets on the=20
Data Multicast Address. All of the nodes in the session subscribe=20
to the class D IP multicast address and UDP port associated with the=20
Data Multicast Address.=20
There is no assumption of congruence between the topology of the=20
Data Multicast Address and the topology of the Control Tree.
-------> SD (Sender node)----->|
^^^ |
ACKs / | \ Control |
and / | \ Tree |
NACKs / | \ |
/ | \ (Repair |
/ | \ Head |
/ | \ nodes) v
RH RH RH <------------|
^^ ^^^ ^^ | Data
/ | / | \ | \ |=20
Channel
/ | / | \ | \ |
/ | / | \ | \ v
R R R R R R R <---------
(Receiver Nodes)
A Receiver joins a Data Multicast Address to receive data. A=20
Receiver periodically informs its parent about the packets that it=20
has or has not received by unicasting an ACK packet to the parent. =20
Each parent node aggregates the ACKs from its child nodes and (if it=20
is not the Sender) unicasts a single aggregated ACK to its parent. =20
For lower latency recovery in low loss networks, Receivers can also=20
generate NACKs upon detection of losses. These have the same format=20
as a ACK, but are only passed up the tree as far as necessary in=20
order to find a Repair Head that can retransmit the packet. The=20
Repair Heads provide NACK suppression, which provides traffic=20
minimization benefits similar to ACK aggregation.
The Sender and each Repair Head have a multicast Local Control=20
Channel to their children. This is used for transmitting Heartbeat=20
packets that inform their child nodes that the parent node is still=20
functioning. This channel is also used to perform local=20
retransmission of lost data packets to just these children. TRACK=20
will still provide correct operation even if multicast addresses are=20
reused across multiple Data Sessions or multiple Local Control=20
Channels. It is NOT RECOMMENDED to use the same multicast address=20
for multiple Local Control Channels serving any given Data Session.
A tree forms a loop from the Sender to the Receivers, to the Repair=20
Heads, and back to the Sender. Data and NullData packets regularly=20
exercise the downward data direction. Heartbeat packets exercise=20
the downward control direction. ACKs, NACKs, and HeartbeatResponse=20
packets regularly exercise the control tree in the upward direction. =20
This combination constantly checks that all of the nodes in the tree=20
are still functioning correctly, and initiates fault recovery when=20
required.
In addition to using ACKs, NACKs, and Repair Heads for scaleable=20
loss notification and retransmission, TRACK also supports the=20
optional use of Generic Router Assist (GRA) and integrated Forward=20
Error Correction (FEC). Two of the major functions of GRA are NACK=20
suppression and dynamically scoped local retransmission. These=20
functions, if enabled, are independently deployed between each=20
parent and its children. For the purpose of GRA NACK functions,=20
each parent is considered to be a Sender and the children of that=20
parent are considered as the Receivers.
Retransmission requests, both NACKs and ACKs, contain selective=20
bitmaps indicating which packets need to be retransmitted. If FEC=20
is enabled, these bitmaps provide enough information to determine=20
the number of parity packets to be sent rather than sending=20
individual retransmissions.
4.3 Session Creation
Before a data session starts delivering data, the tree for the Data=20
Session needs to be created. This process binds each Receiver to=20
either a Repair Head or the Sender, and binds the participating=20
Repair Heads in to a loop-free tree structure with the Sender as the=20
root of the tree. This process requires tree configuration=20
knowledge, which can be provided with some combination of manual=20
and/or automatic configuration. The actual algorithms for tree=20
configuration will be part of the Automatic Tree Configuration BB,=20
and are discussed in the next section.
To start a data session, a Sender communicates to the Receivers, via=20
either an external service or through the application itself, the=20
Data Multicast Address that will be used for the Data Session. It=20
may advertise other relevant session information such as whether or=20
not Repair Heads should be used, whether manual or automatic tree=20
configuration should be used, and the time at which the session will=20
start. It may also advertise certain hints for the tree=20
configuration algorithms.=20
After receiving this out of band communication, the Receivers join=20
the Data Multicast Address, and attempt to bind to either the Sender=20
or a local Repair Head. The tree configuration algorithms are=20
responsible for providing the Receiver with a list of one or more=20
nodes which it will attempt to bind to. It will attempt to bind to=20
the first node in the list, and if this fails, it will move to the=20
next one. A Receiver only binds to a single Repair Head or Sender,=20
at a time, for each Data Session.=20
When a Repair Head has a Receiver bind to it for a given Data=20
Session, it then also binds to another Repair Head or to the Sender,=20
depending on the list given to it by the tree configuration=20
algorithms. The tree configuration algorithms are responsible for=20
ensuring that the tree is formed without loops.=20
Once the bind process has traversed from the Receivers up to the=20
Sender, it then repeats the process in the reverse direction. In=20
this confirmation phase, the Sender enforces a set of uniform=20
Session Configuration Parameters on all members of the session, and=20
verifies that no loops have formed in the tree. The Session=20
Configuration Parameters include values for certain protocol=20
constants, and indicate the set of optional algorithms which will be=20
used for this Data Session, and which each member must support in=20
order to be a member of the tree. Any failures to create a loop=20
free tree, or among members unable to support all the required=20
features, are handled as failures of those particular members.
At the same time as the Sender initiates the second half of the tree=20
binding, it is also free to start sending Data packets on the Data=20
Multicast Address. Repair Heads and Receivers may start receiving=20
these packets, but may not request retransmission or deliver data to=20
the application until they receive confirmation that they have=20
successfully bound to the group.
Some of the Session Configuration Parameters MAY be changed=20
dynamically by the Sender by advertising the changed values as part=20
of the keep-alive control packets periodically sent through the=20
tree. If a given Session Configuration Parameter must be the same=20
at all nodes in order to provide safe operation, it MUST NOT be=20
dynamically changed once the Data Session has started.=20
4.4 Tree Configuration
TRACK is designed to work either with manual configuration of the=20
tree, or with optional automatic tree configuration. Tree=20
configuration is responsible for providing each Receiver and Repair=20
Head with a list of one or more appropriate parents to attempt to=20
bind to. =20
The goals of automatic tree configuration are:
? allow Receivers to automatically locate their best Repair Head(s).
? provide automatic configuration of the Repair Head with the=20
assumption that Repair Heads are servers operating in the network.
? dynamically select which receivers become repair heads.
These algorithms are specified in the Tree Configuration BB. In=20
order to make sure that TRACK can be standardized in a timely=20
fashion, the automatic tree configuration algorithms need to be=20
separate from the rest of the TRACK protocol, so that TRACK can be=20
deployed even without these algorithms. When these algorithms from=20
the Tree Configuration BB are not available, TRACK will use static=20
configuration.
4.5 Data Transmission and Retransmission
Data is multicast by a Sender on the Data Multicast Address. =20
Retransmissions of data packets may be multicast by the Sender on=20
the Data Multicast Address or be multicast on a Local Control=20
Channel by a Repair Head. In order to provide NACK suppression and=20
to work with proactive FEC, retransmissions are always multicast. =20
If Generic Router Assist is enabled, the routers may provide NACK=20
suppression and allow dynamically scoped retransmission to just the=20
subset of Receivers and Repair Heads that have missed a packet. =20
A Repair Head joins all of the Data Multicast Addresses that any of=20
its descendants have joined. A Repair Head is responsible for=20
receiving and buffering all data packets using the reliability=20
semantics configured for a stream. As a simple to implement option,=20
a Repair Head MAY also function as a Receiver, and pass these data=20
packets to an attached application.
For additional fault tolerance, a Receiver MAY subscribe to the=20
multicast address associated with the Local Control Channel of one=20
or more Repair Heads in addition to the multicast address of its=20
parent. In this case it does not bind to this Repair Head or=20
Sender, but will process Retransmission packets sent to this=20
address. If the Receiver=92s Repair Head fails and it transfers to=20
another Repair Head, this minimizes the number of data packets it=20
needs to recover after binding to the new Repair Head.=20
There are three types of retransmissions: local retransmission,=20
global retransmission, and dynamically scoped retransmission.
4.5.1 Local Retransmission
If a Repair Head determines from its child node's ACKs or NACKs that=20
a Data packet was missed, the Repair Head retransmits the Data=20
packet or, if FEC is enabled, an FEC parity packet. The Repair Head=20
multicasts the Retransmission packet on its multicast Local Control=20
Channel. In the event that a Repair Head receives a retransmission=20
and knows that its children need this repair, it re-multicasts the=20
retransmission to its children.
The scope of retransmission is considered part of the Control=20
Channel=92s multicast address, and is derived during tree=20
configuration.
4.5.2 Global Retransmission
If a Sender node receives an ACK or NACK that indicates missing=20
packets, the Sender MAY support an option for global retransmission.
(Note: the Sender is always a Repair Head for its own Control=20
Channel, which is irrespective of whether Global Retransmission is=20
selected). In this case, the Sender multicasts the requested=20
packets on the Data Multicast Address. Again, if FEC is enabled,=20
the Sender will transmit one or more parity packets instead of the=20
actual data packets. This is an optional feature, used as an=20
optimization for some environments such as asymmetrical networks. =20
It MUST NOT be enabled if Generic Router Assist is being used.
4.5.3 Dynamically Scoped Retransmission
On a network whose routers support dynamically scoped=20
retransmissions through Generic Router Assist, then this may be=20
used. Dynamically Scoped Retransmissions use soft state kept in the=20
routers to constrain the Retransmission to only the children that=20
have requested them through a NACK. Dynamically Scoped=20
Retransmissions are known to be susceptible to router topology=20
changes. Therefore, only the first retransmission of a packet is=20
sent via this mechanism. Thereafter, only the above two mechanisms=20
should be used. This will allow the protocol to provide=20
connectivity even during router topology changes, albeit with less=20
efficiency.
4.6 Control Traffic Management
One of the largest challenges for scaleable reliable multicast=20
protocols has been that of controlling the potential explosion of=20
control traffic. There is a fundamental tradeoff between the=20
latency with which losses can be detected and repaired, and the=20
amount of control traffic generated by the protocol. In conjunction=20
with the dynamic global tree parameters, TRACK provides a set of=20
algorithms that carefully control and manage this traffic,=20
preventing control traffic explosion.
Despite their different names, ACKs and NACKs both function as=20
selective acknowledgements of the window of contiguous sequence=20
numbers that have not yet been fully acknowledged. The only=20
difference between the packet headers is a single flag.
ACKs are controlled by setting a number of tree wide parameters=20
controlling their maximum rate of generation. The primary parameter=20
is the ratio parameter, R, for the maximum number of ACK packets to=20
be generated per data packet sent. The higher R is, the faster=20
positive acknowledgements will be generated all the way back to the=20
sender, but the more traffic that is generated. =20
ACKs MUST be enabled for any Data Session. NACKs SHOULD be=20
implemented as part of any implementation, and MAY be enabled for=20
any given Data Session. If enabled, then on detection of a lost=20
packet, a Receiver waits a random interval before sending a NACK. =20
If the Receiver receives the retransmitted data before the NACK=20
timer expires, the Receiver cancels the NACK. This reduces the=20
chance that multiple Receivers generate a NACK for the same packet.
A Repair Head node multicasts a Data packet to its children as soon=20
as it gets a NACK request for that packet, unless it recently=20
retransmitted that packet. If it does not have the missing packet,=20
it forwards the NACK to its parent, and multicasts a control packet=20
to its children to suppress any further NACKs for that packet from=20
them. The Repair Head forwards only one NACK for a missing Data=20
packet within a specified period of time. If more than one packet=20
has been detected as missing before the NACK is sent, the NACK will=20
request all of the missing packets.
NACKs are particularly good for providing real-time data=20
distribution in networks with low loss rates and short to moderate=20
RTT times. See [5] for comparisons on the tradeoffs between ACKs=20
and NACKs for low latency recovery of lost packets.
4.7 Integrated Forward Error Correction
Work [6][7][8] has shown the benefits of incorporating reactive=20
forward error correction (FEC) into reliable multicast protocols. =20
This feature encodes data packets with FEC algorithms, but does not=20
transmit the parity packets until a loss is detected. The parity=20
packets are then transmitted and are able to repair different lost=20
packets at different Receivers. This is a powerful tool for=20
providing scalability in the face of independent loss. When=20
implemented, it is a simple matter to also provide proactive FEC=20
which automatically transmits a certain percentage of parity packets=20
along with the data. This is particularly useful when a high=20
minimum error rate is expected, or when low latency is particularly=20
important. Both of these are optionally supported in TRACK.
FEC is organized around windows of packets. TRACK Data packets=20
include an FEC offset window field, which identifies the offset of a=20
given packet within an FEC window. Combined with the FEC session=20
configuration parameters, this allows receivers to decode a=20
combination of Data and parity packets, to generate each window of=20
Data packets. Proactive FEC packets are parity packets sent as=20
global retransmissions at the same time a window of Data packets are=20
sent. Reactive FEC packets are sent either from a Repair Head or a=20
Sender, in response to requests for retransmissions. If using=20
reactive FEC, a Repair Head must first have all the packets in a=20
window before it can respond to any request for retransmission. The=20
ACK and NACK bitmaps, combined with the information in the headers=20
of the Data packets, provides each Repair Head with enough=20
information to determine which parity packets the RH must compute=20
and send in response to requests for retransmission.
4.8 Flow and Congestion Control
Flow and congestion control algorithms act to prevent the Senders=20
from overflowing the Receivers=92 buffers and to force them to share=20
the network fairly and safely with other TCP and RM connections. =20
TRACK uses a combination of a transmission window for flow control,=20
and the dynamic rate control algorithms specified in the Congestion=20
Control (CC) BB for congestion control. These algorithms have been=20
proven to meet all the requirements for flow and congestion control,=20
including being safe for use in a general Internet environment, and=20
provably fair with TCP.
The Sender application provides the minimum and maximum rate limits=20
as part of the global parameters. A Sender will not transmit at=20
lower than the minimum rate (except possibly during short periods of=20
time when certain slow receivers are being ejected), or higher than=20
the maximum rate. If a Receiver is not able to keep up with the=20
minimum rate for a period of time, the CC BB algorithms will cause=20
it to leave the group. Receivers that leave the group MAY attempt to=20
rejoin the group at a later time, but SHOULD NOT attempt an=20
immediate reconnection.
4.9 Membership
TRACK provides a simple counted membership for each session,=20
available at the Sender node. This counted membership is a simple=20
count of the Receiver nodes that have joined a session as well as=20
any Repair Heads that are also acting as Receivers. A failure=20
report is also provided, which will notify a Sender of any Receivers=20
or Repair Heads that have been detected as having failed or being=20
forced to leave the group. Both the counted membership and failure=20
reports are piggybacked on ACK and NACK packets that are sent=20
towards the Sender, and aggregated together at each Repair Head. A=20
failure report is bounded in size, and so may not be able to report=20
all failures if many occur at once. =20
Each Repair Head and Sender also keeps track of the list of=20
currently attached children, and makes this information available to=20
authorized entities through an SNMP interface. An external=20
membership server could be used to periodically poll the full per=20
session membership from all the Repair Heads and Senders. Combined=20
with the real-time counted membership and failure reports, this=20
enables an application to keep accurate track of global group=20
membership.
4.10 Fault Detection and Recovery
4.10.1 Sender node failure detection
A Sender node that has no data to send will periodically send=20
NullData packets on the Data Multicast Address. If a Receiver or a=20
Repair Head fails to receive Data packets or NullData packets for a=20
session sent by the Sender, the Receiver detects a Sender failure.
4.10.2 Receiver node failure detection
A Receiver node sends ACKs and (optionally) NACKs for each of the=20
active sessions that it has joined. If none of the sessions are=20
active, then the Receiver sends HeartbeatResponse packets to its=20
parent.
If a Receiver's parent node does not receive a ACK, NACK or a=20
HeartbeatResponse within a specified time interval, the parent=20
detects the failure of the Receiver and removes the child from its=20
child list.
4.10.3 Repair Head failure detection
Each Repair Head node sends Heartbeat packets to its child nodes on=20
its multicast Control Tree. If the child nodes do not receive any=20
Heartbeats from their parent Repair Head, they detect failure of the=20
parent.
4.10.4 Repair Head discovery
TRACK supports an option which allows the nodes in the TRACK tree to=20
acquire the addresses and location of its ancestors in the control=20
tree and the addresses of its parent's siblings. If a TRACK node's=20
parent fails, then the node can use the acquired information to join=20
an alternate control node.
4.10.5 Message Stability Semantics
To successfully recover from a failed Repair Head, the children of=20
that Repair Head need to be able to recover the packets they missed=20
while transferring over to a new parent. TRACK provides two levels=20
of message stability, pessimistic and optimistic, to assist in this. =20
With pessimistic stability, a parent may only release a packet from=20
its Data Queue when it has been acknowledged by all of its=20
descendants. With optimistic stability, a parent may release a=20
packet from its Data Queue when each of its direct children have=20
acknowledged it. Pessimistic stability allows a child to recover by=20
switching to any node in the tree, since the Sender will still have=20
a copy of all that child=92s missing packets. Optimistic stability=20
requires less buffer space and may provide higher throughput, but=20
does not provide strong assurances that children will be able to=20
always recover from a failure of their parent.
4.10.6 Recovery
When a child node detects failure of its parent node, it can try to=20
reconnect to an alternate Repair Head of the TRACK tree, or it can=20
try to reconnect directly to the Sender. The failure detection=20
timeouts, coupled with the use of pessimistic stability semantics=20
(if enabled), provide reasonable assurances that a single node=20
failure can be handled without any Receivers losing any of the data=20
packets in a session.
4.11 Ordering Semantics
TRACK offers three levels of delivery ordering semantics: Unordered=20
Reliable, Time Bounded Reliable, and Source Ordered Reliable. These=20
are selected on a per session basis as part of the Session=20
Configuration Parameters. =20
Unordered Reliable provides a reliable stream of packets, without=20
duplicates, and delivers them in the order received. This allows=20
the lowest latency delivery for extremely time sensitive=20
applications. If a packet in the session can not be delivered for=20
some reason, a failure is declared for the session.
Source Ordered Reliable provides TCP semantics on delivery. All=20
packets are delivered in the order sent, without duplicates, and=20
without losses. If a loss occurs, a failure is declared for the=20
session.
Time Bounded Reliable provides bounded TCP semantics on delivery. A=20
specific time period is associated with the session, and this is the=20
maximum time allowed for recovery of a packet at the Receiver after=20
it is detected as lost. If recovery of all lost packets happen=20
within this time bound, then the session will have Source Ordered=20
Reliable semantics. For any packets that take longer than the time=20
bound to recover, the Receiver declares them as lost, notifies the=20
application of this, and then will deliver any packets that have=20
been pending due to the packets now declared as lost. =20
4.12 SNMP Support
The Repair Heads and the Sender are designed to interact with SNMP=20
management tools. This allows network managers to easily monitor=20
and control the sessions being transmitted. All TRACK nodes have=20
SNMP MIBs defined. SNMP support is optional for Receiver nodes, but=20
is required for all other nodes.
5. Functional Specification for TRACK Requirements of Building Blocks=20
Work [2] provides a rationale for decomposing the RMT protocols in=20
to Building Blocks and Protocol Instantiations. This section=20
provides a simple specification of the functions that TRACK requires=20
from each of the Building Blocks. It also provides some basic=20
description of the interfaces between these components.
Since the following overlaps with what is done in the BBs, all of=20
section 5 is for discussion purposes only, and is not meant to=20
replace what is specified in the supporting BBs. The BBs will=20
define the actual algorithms.
5.1 NACK-based Reliability
This building block defines NACK-based loss detection/notification=20
and recovery. The major issues it addresses are implosion=20
prevention (suppression) and NACK semantics (i.e. how packets to be=20
retransmitted should be specified, both in the case of selective and=20
FEC loss repair).
The NACK suppression mechanisms used by TRACK are unicast NACKs with=20
multicast confirmation and exponentially distributed timers. These=20
suppression mechanisms primarily need to both minimize delay while=20
also minimizing redundant messages. They may also need to have=20
special weighting to work with Congestion Feedback.
5.1.1 NACK BB Algorithms
Exponential Back Off. When a packet is detected as lost, an=20
exponentially distributed timer is set, based on the algorithms in=20
[9]. This timer is biased based on the input congestion weighting=20
factor. If either a packet or an explicit suppression message with=20
the same sequence number is detected before the timer goes off, the=20
timer is cancelled.
NACK Generation. When a timer goes off, the protocol instantiation=20
is notified to generate a NACK for that sequence number. The=20
protocol instantiation may, at its discretion, group multiple NACK=20
notifications in to a single NACK packet. For TRACK, NACKs are=20
implemented as a unicast packet with a multicast confirmation=20
response.
Response to a Retransmission Request. When a Repair Head or other=20
possible retransmission agent receives the first NACK from another=20
group member for a given packet, it notifies the protocol=20
instantiation to send either a data retransmission or, if it doesn=92t=20
have the packet for retransmission, an optional suppression message. =20
It then sets an embargo timeout, tied to the RTT to the furthest=20
Receiver, during which other requests for the same packet will be=20
ignored. The length of this embargo doubles each time that a=20
retransmission is sent. This algorithm should also work with=20
requests for retransmissions that come in the form of ACKs, as the=20
algorithms and packet formats for both are identical, with the=20
exception of the suppression mechanisms used.
GRA Signaling. A primary function of GRA is to do NACK=20
elimination/suppression and subcasting of repairs. In order to do=20
this, the transport need to signal the GRA-enabled routers to turn=20
on the appropriate algorithms. This algorithm has to deal with=20
issues such as router topology changes. While not dealt with in=20
detail here, this is a very subtle issue, which will have to be=20
dealt with carefully.
5.1.2 NACK BB Parameters
Congestion Weighting. From Congestion Control BB. This is a=20
weighting parameter for NACK suppression timers. The exact=20
algorithms for this are still to be determined.
Loss Notification. From TRACK protocol instantiation. Notification=20
at a Sender that a packet has been detected as lost, and the=20
sequence number of that packet.
Retransmission Request. From TRACK protocol instantiation. When a=20
NACK or ACK with a request for retransmission is received, this=20
needs to be passed to the BB for handling retransmission requests.
=20
GRA Enabled. From PI. Is GRA enabled in the network?
5.2 FEC Repair BB
This building block is concerned with packet level FEC repair. It=20
specifies the FEC codec selection and the FEC packet naming=20
(indexing) for both reactive FEC and proactive FEC.
5.2.1 FEC BB Algorithms
FEC Input. Receive a window of packets (not necessarily all at=20
once), and store pointers to them for use in the FEC Create Parity=20
algorithm.
FEC Create Parity. Given a window of packets, create and return a=20
parity packet. If a window is not yet full, first call the FEC=20
Flush function. If there are no more parity packets that can be=20
generated for this window, then return an error or else return a=20
parity packet that has already been generated. This uses one of a=20
set of codecs, specified through the use of codepoints. For TRACK,=20
it is expected that the codecs will operate over relatively small=20
windows, to work with real-time applications and congestion control.
FEC Flush. For a window that needs a parity packet, but is not yet=20
full, FEC flush creates all-zero packets for the rest of the packets=20
in the window. No more calls to FEC input can be made for this=20
window after FEC flush has been called.
FEC Decode. Given a set of received data and/or parity packets,=20
decode the window using the specified FEC codec.
5.2.2 FEC BB Parameters
Codec Code Point Index. What is the codec being used for encoding=20
and decoding? This is a fixed parameter per data stream.
FEC Window Size. What is the number of packets in an FEC window? =20
This is a fixed parameter per data stream.
FEC Maximum Parity. This is the maximum number of parity packets=20
that can be generated over a given window size. This is a fixed=20
parameter per data stream.
Data Packet Sequence Number. This is the sequence number of a data=20
packet. This is input to FEC Input from the PI. =20
FEC Window Offset. For a given packet, what is the offset in to an=20
FEC window? This is associated with each Data packet that uses FEC. =20
It is a header field on each Data packet sent. It is sequential=20
over each packet in a window, unless a Flush occurs on a partially=20
full window. In that case, the window offset of this last packet is=20
set to FEC Window Size=961. For parity packets, the FEC Window Offset=20
starts at FEC Window Size, and goes up to FEC Window Size + FEC=20
Maximum Parity=961. This is returned from FEC Input and from FEC=20
Create Parity.
5.3 Congestion Control BB
TRACK uses a source-based rate regulation algorithm, with a single=20
rate provided to all the Receivers in the session.
The following set of algorithms and parameters is a subset of those=20
needed for a full implementation, but give an idea of what is=20
required.=20
5.3.1 Congestion Control BB Algorithms
Initialization. A number of transport-wide parameters must be fed=20
to each of the nodes in the group, such as minimum rate, maximum=20
rate, data segment size, etc.
Receiver Measurements. The Receiver must keep track of its average=20
loss rate, and RTT to the Sender. We will call these measures=20
=93congestion reports=94.
Receiver Feedback. The Receivers must feed these congestion back=20
to the Sender, piggybacked on both NACKs and ACKs. =20
Hierarchical Aggregation. Restricted worst edge aggregation should=20
be used to aggregate the congestion reports in the ACKs and/or NACKs=20
being fed up the tree [10]. Every time that an ACK or NACK is=20
generated, this algorithm should be called to fill in the=20
appropriate fields. Every time an ACK or NACK is received, this=20
algorithm should be called to process the congestion control fields=20
in the packet. This algorithm must also be notified every time a=20
new child joins or leaves at a Repair Head or Sender.
Sender Rate Control. Based on the congestion reports received, the=20
Sender must change its sending rate.
TCP Friendly Equation. Given values for RTT, DataSize, and=20
LossRate, this generates a target throughput rate according to a=20
modified version of the complex TCP model given in [11].
5.3.2 Congestion Control BB Parameters
Initialization Parameters. A set of different options, some of=20
which can be permanent constants, but others are selected by either=20
the Sender or a network manager.
=20
Lost Packet. Every time a packet is detected as lost, the Senders=20
must be notified of this.
RTT Measurement. Every time a RTT measurement is generated, either=20
between Sender and Receiver(s), or between one level of the tree and=20
another, the CC BB must be notified.
Highest Allowed Sequence Number (HASN). This is used to implement=20
=93receiver-driven=94 window control [13]. Each receiver can keep track=20
of a congestion window and compute the HASN to be included in each=20
ACK. A Repair Head aggregates the HASNs by computing the minimum=20
value from all its children and forwards that as its own HASN up the=20
tree.
5.4 Generic Router Assist BB
The task of designing scaleable RM protocols can be made easier by=20
the presence of some specific support in routers. In some=20
application- specific cases, the increased benefits afforded by the=20
addition of special router support can justify the resulting=20
additional complexity and expense.
Functional components which can take advantage of router support=20
include feedback aggregation/suppression (both for loss notification=20
and congestion control) and constrained retransmission of repair=20
packets. =20
The process of designing and deploying these mechanisms inside=20
routers can be much slower than the one required for end-host=20
protocol mechanisms. Therefore, it would be highly advantageous to=20
define these mechanisms in a generic way that multiple protocols can=20
use if it is available, but do not necessarily need to depend on.
This component has two halves, a signaling protocol and actual=20
router algorithms. The signaling protocol allows the transport=20
protocol to request from the router the functions that it wishes to=20
perform, and the router algorithms actually perform these functions.=20
An important component of the signaling protocol is some level of=20
commonality between the packet headers of multiple protocols, which=20
allows the router to recognize and interpret the headers. This is=20
covered in the section on common packet headers, below.
5.4.1 GRA BB Algorithms
NACK Suppression. NACKs are sent towards the parent Repair Head or=20
Sender, with a Router Alert option on. GRA enabled routers detect=20
these packets and suppress redundant NACKs. It then updates a soft=20
state table so that it knows to retransmit the requested packet to=20
the requesting children, using Dynamic Selective Retransmission. The=20
NACK suppression algorithm needs to work with both ACKs and NACKs,=20
in order for Dynamic Selective Retransmission to work with TRACK. =20
This means that GRA can not suppress ACKs but must still use them to=20
update its state for retransmissions. It also means that GRA must=20
work with ACK and NACK selective bitmaps, not just NACKs that=20
request a single packet.
Dynamic Selective Retransmission. When a retransmission occurs, it=20
is only forwarded to the interfaces of each router that have=20
signaled through the use of NACKs that they need to see that packet.
Nearest Repair Head Hint. The router is made aware of the nearest=20
Repair Heads, and is able to tell a child which is the best=20
candidate for it to use. This must only be used as a hint to=20
children.
Fine Grained Loss Reports. A major limitation of TFMCC is its=20
limitation of only getting 1-bit loss reports (i.e. a packet is=20
lost, or it is not) from the routers. A 8 or 16 bit report,=20
piggybacked on to data packets, with the cumulative loss detected=20
across all interfaces of GRA enabled routers the data packet=20
crossed, would allow TRACK to become much more responsive to changes=20
in network conditions. These reports can only be used as hints.
Signaling Protocol. The functions for GRA need to be requested by=20
the protocol ahead of time, and then the run time packet headers=20
need to be decipherable by the router. =20
5.4.2 GRA BB Parameters
GRA Enabled. Is GRA enabled in any of the routers in the network? =20
Which functions do the deployed version of GRA support?
Packet Format. Which type of packet format is GRA to operate over? =20
It is likely that different protocol instantiations will require=20
differences in the packet headers they send to the router. This is=20
tied to the common packet header BB, below.
5.5 Automatic Tree Configuration BB
TRACK takes advantage of hierarchical Repair Heads, to greatly=20
increase the theoretical scalability of the protocol. These Repair=20
Heads are used to form a tree with the source at the root, the=20
Receivers at the leaves of the tree, and the Repair Heads in the=20
middle. The Repair Heads can either be dedicated server software=20
for this task, or they may be application nodes that are performing=20
dual duty.
The effectiveness of these agents to assist in the delivery of data=20
is highly dependent upon how well the logical tree they use to=20
communicate matches the underlying routing topology. The purpose of=20
this building block is to construct and manage the logical tree=20
connecting the agents. Ideally, this building block will perform=20
these functions in a manner that adapts to changes in session=20
membership, routing topology, and network availability.
5.5.1 Auto Tree BB Algorithms
These are discussed in section 3.3. They are not yet mature enough=20
to break down in to component parts.
5.5.2 Auto Tree BB Parameters
These are discussed in section 3.3. The algorithms are not yet=20
mature enough to break down in to the parameters needed.
5.6 Security
As specified in [12], the primary security requirement for a TRACK=20
protocol is protection of the transport infrastructure. This is=20
accomplished through the use of lightweight group authentication of=20
the control and, optionally, the data packets sent to the group. =20
These algorithms use IPsec and shared symmetric keys. For TRACK,=20
[12] recommends that there be one shared key for the Data Session=20
and one for each Local Control Channel. These keys are distributed=20
through a separate key manager component, which may be either=20
centralized or distributed. Each member of the group is responsible=20
for contacting the key manager, establishing a pair-wise security=20
association with the key manager, and obtaining the appropriate=20
keys. The TRACK protocol then provides options for piggy-backing=20
key update messages on the Data Session and each Local Control=20
Channel of the protocol. These can either include a new shared=20
group key (encrypted with the old group key) or a notification that=20
the group key(s) are being changed and that the group members should=20
contact the key manager to get the new key(s). The former typically=20
occurs on a periodic basis, while the latter may occur when a group=20
member leaves.
The exact algorithms for this BB is presently the subject of=20
research within the IRTF Secure Multicast Group (SMuG). Solutions=20
for these requirements will be standardized within the IETF when=20
ready.
5.7 Common Headers BB
As pointed out in the generic router support section, it is=20
important to have some level of commonality across packet headers. =20
It may also be useful to have common data header formats for other=20
reasons. This building block consists of recommendations on fields=20
in their packet headers that protocols should make common across=20
themselves. TRACK needs to implement these recommendations in the=20
TRACK PI.
5.7.1 Common Header BB Fields
GRA Signaling. The Retransmission, NACK and ACK packet headers need=20
to provide a means for signaling their existence to GRA. For NACK=20
and ACK headers, the selective bitmap needs to be specified in a=20
common way across all protocols so that the GRA component can=20
interpret these fields and determine the sequence numbers of the=20
packets that are being requested. For the Retransmission packets,=20
the sequence number of the packet needs to be in a standard position=20
so that GRA can interpret it. For both NACK, ACK and Retransmission=20
packets, the Session ID needs to be specified in a standard way=20
across protocols.
Data Packets. The identification of data packets within a stream=20
should be common across all protocols, both to aid in commonality of=20
application semantics across protocols and to aid in GRA signaling.=20
A Data Packet is identified by three fields: the Session ID, the=20
Sequence Number, and the FEC Window Offset. The Session ID may=20
include the multicast address and/or a unique ID. The sequence=20
number starts at 1 and increments with each Data packet sent in the=20
Session. Sequence numbers are always sequentially generated,=20
without gaps. The FEC Window Offset specifies the offset of a Data=20
packet in to an FEC window. For a window of W generated packets, a=20
maximum window size of M, and a maximum parity size of P, the=20
packets are numbered as follows. The first W-1 packets are numbered=20
as 0 through W-2, with W never to exceed M. Packet W is always=20
numbered as M-1, so that Receivers and Repair Heads can detect a=20
partially filled window. The P parity packets are numbered M=20
through M+P-1.
IP and UDP. It is easiest to implement protocols in the application=20
space using UDP packets, but eventual kernel implementations will=20
have TRACK implemented directly on top of IP. Other protocols share=20
this requirement, and the way that this transition is done should be=20
specified across all protocols.
6. Security Considerations
7. Open Issues
1. At various places in the document (e.g. Section 1, 3.5), different=20
flavors of reliability services are described. We need to define=20
them and describe how they are selected/configured. It seems=20
there are at least three flavors of reliability:
? ACK-to-sender (also known as pessimistic)
? ACK-to-RH (also known as optimistic)
? Time-bounded (useful for supporting real-time applications)
It is argued that the pessimistic flavor should be optional (for=20
implementation) as it is less useful.
Currently, Time-bounded is included in 4.11 as a kind of ordering=20
semantics, which does not seem appropriate.
2. Receivers talk to their parents with three kinds of messages:=20
ACKs, NACKs and heartbeatResponse. They can all be the same=20
message. The recipient of the message can always tell from the=20
packet content and recipient=92s local state the message=92s intent.
3. Control Tree. TreeId has been removed. It is not clear how to=20
refer to a subset of a control tree (a set of RHs bind with each=20
other, without a sender as a root) to be re-used/shared. Since=20
half of the Session Id is not controlled by TRACK, it seems that=20
they can be used to identify such sharable control (sub)trees when=20
appropriate.
4. It is suggested that a different type be used to distinguish=20
retransmission Data Packets from original Data Packets. The=20
ability to distinguish retransmission from the original packet=20
helps quickly determine if the packet came from the sender or a=20
Repair Head.
5. Section 4.1.8. Originally, there was a AcceptPending packet, used=20
to indicate that the Bind is successful pending further=20
confirmation. This has been removed in favor of using a Reject=20
with a reason code. The reason for this change is that the=20
AcceptPending approach leaves state at the RH that becomes=20
difficult to clean up. If not careful, it may be open to Denial-
of-service attack. The simple reject and retry approach is=20
considered more robust. The change, however, has not been agreed=20
to by all authors, and becomes an open issue.
6. Section 4.1.8 and 4.10.2. The descriptions of how heartbeat and=20
heartbeatResponses are generated are lacking. There is a proposal=20
to allow heartbeat to contain mechanism to prompt for=20
heartbeatResponse. Such prompting can reduce the need for regular=20
heartbeatResponses from receivers. These algorithms need further=20
agreements.
7. Section 4.3 describes a 2-pass =93bottom-up=94 tree construction=20
algorithm. It has been suggested that if the Binding is done=20
=93top-down=94 there is no need for a 2-pass process and hence the=20
whole algorithm can be simpler. Furthermore, these algorithms=20
should be debated and worked out in the Tree Configuration BB.
8. TRACK depends on being able to configure a Control Tree. The Tree=20
Configuration BB must deliver some standard base-level mechanism,=20
even if completely static. Otherwise, some static configuration=20
mechanisms need to be specified in the TRACK PI.
9. Section 4.10.4 describes a mechanism for a receiver to find RH=20
information from its current RH, to serve as backup RHs. This is=20
really a requirement for the Tree Configuration BB to supply such=20
a mechanism. If one is not available from the Tree BB, then the=20
described mechanism would be used.
10. Need to add discussion of Late Join support
11. Need to add discussion of how session can gracefully close
12. In section 4.6, a number of other tactics for controlling ACK=20
and NACK traffic are possible, for instance, having receivers=20
stagger NACK production on different window boundaries.
13. Need to specify how RH determines the retransmission rate.
8. References
1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP=20
9, RFC 2026, October 1996.
2 Whetten, B., et. al. =93Reliable Multicast Transport Building=20
Blocks for One-to-Many Bulk-Data Transfer.=94 Internet Draft,=20
draft-ietf-rmt-buildingblocks-02.txt, Work in Progress.
3 Handley, M., et. al. =93The Reliable Multicast Design Space for=20
Bulk Data Transfer.=94 Internet Draft, draft-ietf-rmt-design-
space-01.txt, Work in Progress.=20
4 Bradner, S., "Key words for use in RFCs to Indicate Requirement=20
Levels", BCP 14, RFC 2119, March 1997
5 Whetten, B., Taskale, G. =93Overview of the Reliable Multicast=20
Transport Protocol II (RMTP-II).=94 IEEE Networking, Special Issue=20
on Multicast, February 2000.
6 Nonnenmacher, J., Biersack, E. "Reliable Multicast: Where
to use Forward Error Correction", Proc. 5th. Workshop on=20
Protocols for High Speed Networks, Sophia Antipolis, France, Oct.=20
1996.
7 Nonnenmacher, J., et. al. "Parity-Based Loss Recovery for=20
Reliable Multicast Transmission", In Proc. of ACM SIGCOMM '97,=20
Cannes, France, September 1997.
8 Rizzo, L. "Effective erasure codes for reliable computer
communications protocols", DEIT Technical Report LR-970115.
9 Nonnenmacher, J., Biersack, E. "Optimal Multicast Feedback",=20
Proc. IEEE INFOCOM 1998, March 1998.
10 Whetten, B., Conlan, J. =93A Rate Based Congestion Control Scheme=20
for Reliable Multicast=94, GlobalCast Communications Technical=20
White Paper, November 1998. http://www.talarian.com/rmtp-ii
11 Padhye, J., et. al. =93Modeling TCP Throughput: A Simple Model=20
and its Empirical Validation=94. University of Massachusetts=20
Technical Report CMPSCI TR 98-008.
12 Hardjorno, T., Whetten, B. =93Security Requirements for TRACK=20
Protocols.=94 Work in Progress.
13 Golestani, J., =93Fundamental Observations on Multicast Congestion=20
Control in the Internet=94, Bell Labs, Lucent Technology, paper=20
presented at the July 1998 RMRG meeting.
14 Kadansky, M., D. Chiu, J. Wesley, J. Provino, =93Tree-based=20
Reliable Multicast (TRAM)=94, draft-kadansky-tram-02.txt, Work in=20
Progress.
15 Whetten, B., M. Basavaiah, S. Paul, T. Montgomery, =93RMTP-II=20
Specification=94, draft-whetten-rmtp-ii-00.txt, April 8, 1998. Work=20
in Progress.
8. Acknowledgments
Special thanks goes to the following individuals, who have=20
contributed to the design and review of this document.
Supratik Bhattacharyya, Sprint Labs
Miriam Kadansky, Sun Microsystems
Seok Koh, ETRI Korea
Joseph Wesley, Sun Microsystems
9. Author's Addresses
Brian Whetten
Talarian Corporation
333 Distel Circle
Los Altos CA 94022
whetten@talarian.com
Dah Ming Chiu
Sun Microsystems Laboratories
1 Network Drive
Burlington, MA 01803
dahming.chiu@sun.com
Sanjoy Paul
Edgix Corporation
130 W. 42nd Street, Suite 850
New York, NY 10036
sanjoy@edgix.com
Full Copyright Statement
Copyright (C) The Internet Society, 2000. All Rights Reserved. This=20
document and translations of it may be copied and furnished to=20
others, and derivative works that comment on or otherwise explain it=20
or assist in its implementation may be prepared, copied, published=20
and distributed, in whole or in part, without restriction of any=20
kind, provided that the above copyright notice and this paragraph=20
are included on all such copies and derivative works. However, this=20
document itself may not be modified in any way, such as by removing=20
the copyright notice or references to the Internet Society or other=20
Internet organizations, except as needed for the purpose of=20
developing Internet standards in which case the procedures for=20
copyrights defined in the Internet Standards process must be=20
followed, or as required to translate it into other languages.
=09TRACK ARCHITECTURE=09March 2000
=20
B. Whetten=09Internet Draft =96 Expires September 2000=0925
=20
B. Whetten=09Internet Draft =96 Expires September 2000=091
--Brace_of_Greyhounds_614_000--
>From owner-rmt@listserv.lbl.gov Sat Apr 29 01:23:25 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id BAA08684;
Sat, 29 Apr 2000 01:21:30 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id BAA08680
for <rmt@listserv.lbl.gov>; Sat, 29 Apr 2000 01:21:29 -0700 (PDT)
From: jeffallen@spotbuy.com
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id BAA27401
for <rmt@listserv.lbl.gov>; Sat, 29 Apr 2000 01:21:28 -0700 (PDT)
Received: from spotbuy.com (host-209-214-98-67.sav.bellsouth.net [209.214.98.67])
by SpamWall.lbl.gov (8.9.3/8.9.3) with SMTP id BAA27382;
Sat, 29 Apr 2000 01:21:21 -0700 (PDT)
Subject: Would you like to save 30% on your phone bills and...
Date: Sat, 29 Apr 2000 04:27:40
Message-Id: <845.90767.552162@spotbuy.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-rmt@lbl.gov
Precedence: bulk
To be removed from this mailing list immediately press reply and enter REMOVE on the subject line.
Would you like some information on saving 30% on your Phone bills each month and how to get up to 8% back each month on your Utilities including phone. This service works for both business and residential, domestic and international. Sign up is FREE
Reply with "MORE INFO" in the subject field
>From owner-rmt@listserv.lbl.gov Sun Apr 30 22:56:39 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id WAA12919;
Sun, 30 Apr 2000 22:54:48 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id WAA12915
for <rmt@listserv.lbl.gov>; Sun, 30 Apr 2000 22:54:46 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id WAA22558
for <rmt@listserv.lbl.gov>; Sun, 30 Apr 2000 22:54:45 -0700 (PDT)
Received: from motgate.mot.com (motgate.mot.com [129.188.136.100])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id WAA22555
for <rmt@lbl.gov>; Sun, 30 Apr 2000 22:54:45 -0700 (PDT)
Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (motgate 2.1) with ESMTP id WAA21332; Sun, 30 Apr 2000 22:54:44 -0700 (MST)]
Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [217.1.10.38]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id WAA24949; Sun, 30 Apr 2000 22:54:41 -0700 (MST)]
Received: from motorola.com (mccoy.arc.corp.mot.com [217.1.10.204])
by homer.arc.corp.mot.com (8.9.3/8.9.3) with ESMTP id PAA13919;
Mon, 1 May 2000 15:54:38 +1000 (EST)
Message-ID: <390D1C1E.9452CBAB@motorola.com>
Date: Mon, 01 May 2000 15:54:38 +1000
From: Roger Kermode <Roger.Kermode@motorola.com>
Organization: Motorola Austrlian Research Centre
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: rmt-list <rmt@lbl.gov>, Scott Bradner <sob@harvard.edu>
Subject: RMT WG Last CALL:
Content-Type: multipart/mixed;
boundary="------------8F38AEAC6FB5130BE03D6DE9"
Sender: owner-rmt@lbl.gov
Precedence: bulk
This is a multi-part message in MIME format.
--------------8F38AEAC6FB5130BE03D6DE9
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Please be advised that the Design Space and Building Blocks
drafts:
http://www.ietf.org/internet-drafts/draft-ietf-rmt-design-space-01.txt
http://www.ietf.org/internet-drafts/draft-ietf-rmt-buildingblocks-02.txt
are now officially in WG Last Call that will expire 15 May 2000.
Please address any comments/requests for clarification to the
document authors,
regards,
Roger Kermode
Allison Mankin
Lorenzo Vicisano
--------------8F38AEAC6FB5130BE03D6DE9
Content-Type: text/x-vcard; charset=us-ascii;
name="Roger.Kermode.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Roger Kermode
Content-Disposition: attachment;
filename="Roger.Kermode.vcf"
begin:vcard
n:Kermode;Roger
tel;cell:+61-408-212-284
tel;fax:+61-2-9666-0501
tel;work:+61-2-9666-0558
x-mozilla-html:FALSE
url:http://www.arc.corp.mot.com
org:Motorola Australian Research Centre;Communications and Networks Laboratory
version:2.1
email;internet:ark008@email.mot.com
title:Principal Research Engineer / Manager
adr;quoted-printable:;;12 Lord St. Level 3=0D=0A=0D=0A;Botany;NSW;2019;Australia
x-mozilla-cpt:;-27712
fn:Roger Kermode
end:vcard
--------------8F38AEAC6FB5130BE03D6DE9--
>From owner-rmt@listserv.lbl.gov Thu May 11 17:42:49 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id RAA04247;
Thu, 11 May 2000 17:38:35 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id RAA04243
for <rmt@listserv.lbl.gov>; Thu, 11 May 2000 17:38:33 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id RAA10613
for <rmt@listserv.lbl.gov>; Thu, 11 May 2000 17:38:32 -0700 (PDT)
Received: from hercules.cs.ucsb.edu (hercules.cs.ucsb.edu [128.111.41.30])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id RAA10606
for <rmt@lbl.gov>; Thu, 11 May 2000 17:38:32 -0700 (PDT)
Received: from duke.cs.ucsb.edu (duke [128.111.49.49])
by hercules.cs.ucsb.edu (8.9.3+Sun/8.8.6) with ESMTP id RAA19567
for <rmt@lbl.gov>; Thu, 11 May 2000 17:38:30 -0700 (PDT)
Received: by duke.cs.ucsb.edu (8.9.3+Sun/SMI-SVR4)
id RAA14135 for rmt@lbl.gov; Thu, 11 May 2000 17:38:30 -0700 (PDT)
Date: Thu, 11 May 2000 17:38:30 -0700 (PDT)
From: almeroth@cs.ucsb.edu (Kevin C. Almeroth)
Message-Id: <200005120038.RAA14135@duke.cs.ucsb.edu>
To: rmt@lbl.gov
Subject: NGC 2000 Call for Papers
Sender: owner-rmt@lbl.gov
Precedence: bulk
C A L L F O R P A P E R S
D U E : J U N E 5 T H
The 2nd International Workshop on
Networked Group Communication (NGC 2000)
November 8-10, 2000
Stanford University
Palo Alto, California, USA
Organized by Sprint and COST 264 in cooperation with ACM Sigcomm
---------------------------------
Scope of the Conference
-----------------------
The aim of the Workshop is to allow researchers and practioners to
present the design and implementation techniques for networked group
communication. The focus of the Workshop is strictly on multicast and
networked group communication. This Workshop is the second and only
international event in this area (first workshop was in Pisa, Italy,
in November 1999).
The workshop will start with half day tutorials on the 8th. The
technical program will include two keynotes and invited talks on the
9th and the 10th of November 2000.
Authors are invited to submit papers on any issue related to networked
group communication, including but not limited to:
multicast congestion control
multicast routing, naming, address allocation
scalability in multicast services
reliable and semi-reliable multicast protocols
novel multicast architectures
multicast security
multicast deployment related issues
multicast over heterogeneous media
multipeer applications (distributed interactive apps, games, DIS)
QoS issues with multicast
Pricing and economic model for multicast traffic
group management techniques
network engineering for multicast services
Paper Submission Guidelines
---------------------------
Papers must be less than 20 double-spaced pages long, have an abstract
of 100-150 words, and be original material that has not been previously
published nor is currently under review by another conference or journal.
Authors must submit papers electronically, using the instructions at
http://www.cs.ucsb.edu/ngc2000/ (NOTE: paper submission will be available
starting May 15th).
The Proceedings of the Workshop will be published by ACM and papers will
be available on-line prior to the workshop.
Important Dates
---------------
Paper Submission: June 5, 2000
Author Notification: August 28, 2000
Camera Ready: September 11, 2000
-----------------------------------------------
For more information, visit the workshop WWW page at:
http://www.cs.ucsb.edu/ngc2000/
>From owner-rmt@listserv.lbl.gov Mon May 15 22:20:49 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id WAA16879;
Mon, 15 May 2000 22:19:08 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id WAA16875
for <rmt@listserv.lbl.gov>; Mon, 15 May 2000 22:19:06 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id WAA06501
for <rmt@listserv.lbl.gov>; Mon, 15 May 2000 22:19:05 -0700 (PDT)
Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id WAA06498
for <rmt@lbl.gov>; Mon, 15 May 2000 22:19:04 -0700 (PDT)
Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate2.mot.com (motgate2 2.1) with ESMTP id WAA28192; Mon, 15 May 2000 22:19:03 -0700 (MST)]
Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [217.1.10.38]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id WAA05110; Mon, 15 May 2000 22:19:01 -0700 (MST)]
Received: from motorola.com (mccoy.arc.corp.mot.com [217.1.10.204])
by homer.arc.corp.mot.com (8.9.3/8.9.3) with ESMTP id PAA02204;
Tue, 16 May 2000 15:18:54 +1000 (EST)
Message-ID: <3920DA3E.D26D177A@motorola.com>
Date: Tue, 16 May 2000 15:18:54 +1000
From: Roger Kermode <Roger.Kermode@motorola.com>
Organization: Motorola Austrlian Research Centre
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Roger Kermode <Roger_Kermode-ARK008@email.mot.com>
CC: rmt-list <rmt@lbl.gov>, Scott Bradner <sob@harvard.edu>
Subject: Last chance RMT WG Last CALL on DS and BB drafts
References: <390D1C1E.9452CBAB@motorola.com>
Content-Type: multipart/mixed;
boundary="------------809E6C4B4FD0D879DF73BA76"
Sender: owner-rmt@lbl.gov
Precedence: bulk
This is a multi-part message in MIME format.
--------------809E6C4B4FD0D879DF73BA76
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Absolute last chance for comments. If none are received within the
next 24hours then I will send these two drafts up for IESG last call,
cheers,
Roger
Roger Kermode wrote:
> Please be advised that the Design Space and Building Blocks
> drafts:
>
> http://www.ietf.org/internet-drafts/draft-ietf-rmt-design-space-01.txt
> http://www.ietf.org/internet-drafts/draft-ietf-rmt-buildingblocks-02.txt
>
> are now officially in WG Last Call that will expire 15 May 2000.
>
> Please address any comments/requests for clarification to the
> document authors,
>
> regards,
>
> Roger Kermode
> Allison Mankin
> Lorenzo Vicisano
--------------809E6C4B4FD0D879DF73BA76
Content-Type: text/x-vcard; charset=us-ascii;
name="Roger.Kermode.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Roger Kermode
Content-Disposition: attachment;
filename="Roger.Kermode.vcf"
begin:vcard
n:Kermode;Roger
tel;cell:+61-408-212-284
tel;fax:+61-2-9666-0501
tel;work:+61-2-9666-0558
x-mozilla-html:FALSE
url:http://www.arc.corp.mot.com
org:Motorola Australian Research Centre;Communications and Networks Laboratory
version:2.1
email;internet:ark008@email.mot.com
title:Principal Research Engineer / Manager
adr;quoted-printable:;;12 Lord St. Level 3=0D=0A=0D=0A;Botany;NSW;2019;Australia
x-mozilla-cpt:;-27712
fn:Roger Kermode
end:vcard
--------------809E6C4B4FD0D879DF73BA76--
>From owner-rmt@listserv.lbl.gov Thu Jun 1 08:00:37 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id HAA06821;
Thu, 1 Jun 2000 07:55:14 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id HAA06817
for <rmt@listserv.lbl.gov>; Thu, 1 Jun 2000 07:55:12 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id HAA03291
for <rmt@listserv.lbl.gov>; Thu, 1 Jun 2000 07:55:11 -0700 (PDT)
Received: from hercules.cs.ucsb.edu (hercules.cs.ucsb.edu [128.111.41.30])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id HAA03286
for <rmt@lbl.gov>; Thu, 1 Jun 2000 07:55:10 -0700 (PDT)
Received: from jackson.cs.ucsb.edu (jackson [128.111.52.10])
by hercules.cs.ucsb.edu (8.9.3+Sun/8.8.6) with ESMTP id HAA25603;
Thu, 1 Jun 2000 07:55:03 -0700 (PDT)
Received: by jackson.cs.ucsb.edu (8.9.3+Sun/SMI-SVR4)
id HAA18411 for ; Thu, 1 Jun 2000 07:55:01 -0700 (PDT)
Date: Thu, 1 Jun 2000 07:55:01 -0700 (PDT)
From: almeroth@cs.ucsb.edu (Kevin C. Almeroth)
Message-Id: <200006011455.HAA18411@jackson.cs.ucsb.edu>
To: almeroth@cs.ucsb.edu, cdiot@sprintlabs.com
Subject: NGC CFP (Deadline June 5th)
Sender: owner-rmt@lbl.gov
Precedence: bulk
The paper submission deadline is June 5th.
C A L L F O R P A P E R S
The 2nd International Workshop on
Networked Group Communication (NGC 2000)
November 8-10, 2000
Stanford University
Palo Alto, California, USA
Organized by Sprint, Cisco Systems, and COST 264
in cooperation with ACM Sigcomm
---------------------------------
Scope of the Conference
-----------------------
The aim of the Workshop is to allow researchers and practioners to
present the design and implementation techniques for networked group
communication. The focus of the Workshop is strictly on multicast and
networked group communication. This Workshop is the second and only
international event in this area (first workshop was in Pisa, Italy,
in November 1999).
The workshop will start with half day tutorials on the 8th. The
technical program will include two keynotes and invited talks on the
9th and the 10th of November 2000.
Authors are invited to submit papers on any issue related to networked
group communication, including but not limited to:
multicast congestion control
multicast routing, naming, address allocation
scalability in multicast services
reliable and semi-reliable multicast protocols
novel multicast architectures
multicast security
multicast deployment related issues
multicast over heterogeneous media
multipeer applications (distributed interactive apps, games, DIS)
QoS issues with multicast
Pricing and economic model for multicast traffic
group management techniques
network engineering for multicast services
The Proceedings of the Workshop will be published by ACM and papers will
be available on-line prior to the workshop.
Paper Submission Guidelines
---------------------------
Papers must be less than 20 double-spaced pages long, have an abstract
of 100-150 words, and be original material that has not been previously
published nor is currently under review by another conference or journal.
Authors must submit papers electronically, using the instructions at
http://www.cs.ucsb.edu/ngc2000/
Important Dates
---------------
Paper Submission: June 5, 2000
Author Notification: August 28, 2000
Camera Ready: September 11, 2000
-----------------------------------------------
For more information, visit the workshop WWW page at:
http://www.cs.ucsb.edu/ngc2000/
>From owner-rmt@listserv.lbl.gov Thu Jun 8 09:39:29 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id JAA02605;
Thu, 8 Jun 2000 09:35:09 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id JAA02601
for <rmt@listserv.lbl.gov>; Thu, 8 Jun 2000 09:35:07 -0700 (PDT)
From: zainprov@swbell.net
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id JAA07041
for <rmt@listserv.lbl.gov>; Thu, 8 Jun 2000 09:35:06 -0700 (PDT)
Received: from mta5.rcsntx.swbell.net (mta5.rcsntx.swbell.net [151.164.30.29])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id JAA07034
for <rmt@lbl.gov>; Thu, 8 Jun 2000 09:35:06 -0700 (PDT)
Received: from zainprov ([207.193.24.81]) by mta5.rcsntx.swbell.net
(Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9)
with SMTP id <0FVU00BB0FA6SN@mta5.rcsntx.swbell.net> for rmt@lbl.gov; Thu,
8 Jun 2000 11:06:12 -0500 (CDT)
Date: Thu, 08 Jun 2000 11:06:12 -0500 (CDT)
Date-warning: Date header was inserted by mta5.rcsntx.swbell.net
Subject: Shocking LOSE 10-100lbs. DESTINY
To: rmt@lbl.gov
Message-id: <0FVU00BLUFEASN@mta5.rcsntx.swbell.net>
MIME-version: 1.0
Content-type: text/plain; charset=unknown-8bit
Sender: owner-rmt@lbl.gov
Precedence: bulk
Hello From Destiny,
You will LOOSE 20-100 pounds easy!
Do to Such a high demand for Destiny, we are able
To Dramatically reduce our price for the entire System!
You will LOVE our incredible offer on this
Scientific Breakthrough in Weight Loss.
Now with a 105% Money Back Guarantee!
LOOK! http://home.swbell.net/zainprov/destiny.htm
We hope things are going well for you. Good luck, God Bless, and
HAVE A GREAT DAY!
Either you are someone else subscribed to our list. To be removed
Simply reply with a blank email.
Thank you,
Sherry Wilson
>From owner-rmt@listserv.lbl.gov Fri Jun 9 19:04:06 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id TAA13155;
Fri, 9 Jun 2000 19:02:15 -0700 (PDT)
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id TAA13151
for <rmt@listserv.lbl.gov>; Fri, 9 Jun 2000 19:02:13 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id TAA07431
for <rmt@listserv.lbl.gov>; Fri, 9 Jun 2000 19:02:12 -0700 (PDT)
Received: from gslacks.cs.umass.edu (gslacks.cs.umass.edu [128.119.245.66])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id TAA07428
for <rmt@lbl.gov>; Fri, 9 Jun 2000 19:02:11 -0700 (PDT)
Received: from localhost (brian@localhost)
by gslacks.cs.umass.edu (8.9.3/8.9.3) with SMTP id VAA28314;
Fri, 9 Jun 2000 21:57:06 -0400
X-Authentication-Warning: gslacks.cs.umass.edu: brian owned process doing -bs
Date: Fri, 9 Jun 2000 21:57:06 -0400 (EDT)
From: Brian Levine <brian@cs.umass.edu>
cc: brian@cs.umass.edu
Subject: SIGCOMM Student Travel Grants due June 22
Message-ID: <Pine.LNX.4.02.10006092128430.28066-100000@gslacks.cs.umass.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-rmt@lbl.gov
Precedence: bulk
The application deadline for Sigcomm 2000 Student Travel Grants is fast
approaching. This year, we are fortunate and expect to receive funding
from the NSF, ACM SIGCOMM, and the Nokia Corporation! Thanks to our
generous benefactors, we are expecting to fund quite a large number of
students.
The committee strongly prefers to give grants to students who are not
paper authors, though such students are welcome to apply. Other criteria
will include evidence of a serious interest in networking, as demonstrated
by coursework and project experience. ACM SIGCOMM encourages participation
of women and under-represented minorities. The amount of support provided
to each student is intended to cover the student's travel, food and
lodging for four nights. Students throughout the world are encouraged to
apply, however, funding from NSF is limited solely to US students.
The recipients of the travel grants will be decided by a committee
including
Brian Neil Levine, U. Massachusetts Amherst, USA
Ellen Zegura, Georgia Tech, USA
Roch Guerin, U. Pennsylvania, USA
Luigi Rizzo, Universit di Pisa, Italy
An application for a travel grant will consist of a letter from the
student and a recommendation letter from the student's advisor. Please see
the conference web site for important details regarding each letter.
Send application and recommendation letters by email to Brian Levine,
brian@cs.umass.edu, in ASCII, Postscript or PDF format. Use the same
email address also for questions on the ACM SIGCOMM travel grant program.
Important Dates:
Application deadline: June 22, 2000
Notification date: July 6, 2000
http://www.acm.org/sigcomm/sigcomm2000
Please accept my apologies if you receive this message from multiple
sources or if I have disrupted your mailing list.
Sincerely,
Brian Neil Levine
Department of Computer Science
UMass Amherst
>From owner-rmt@listserv.lbl.gov Wed Jun 14 11:21:53 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id LAA02681;
Wed, 14 Jun 2000 11:19:35 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id LAA02677
for <rmt@listserv.lbl.gov>; Wed, 14 Jun 2000 11:19:33 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id LAA05968
for <rmt@listserv.lbl.gov>; Wed, 14 Jun 2000 11:19:32 -0700 (PDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id LAA05943
for <rmt@lbl.gov>; Wed, 14 Jun 2000 11:19:31 -0700 (PDT)
Received: from eastmail2.East.Sun.COM ([129.148.1.241])
by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA17668
for <rmt@lbl.gov>; Wed, 14 Jun 2000 11:19:19 -0700 (PDT)
Received: from bcn.East.Sun.COM (bcn.East.Sun.COM [129.148.75.4])
by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA29334
for <rmt@lbl.gov>; Wed, 14 Jun 2000 14:18:44 -0400 (EDT)
Received: from maple (maple [129.148.75.29])
by bcn.East.Sun.COM (8.9.1b+Sun/8.9.1) with SMTP id OAA18484
for <rmt@lbl.gov>; Wed, 14 Jun 2000 14:18:43 -0400 (EDT)
Message-Id: <200006141818.OAA18484@bcn.East.Sun.COM>
Date: Wed, 14 Jun 2000 14:18:43 -0400 (EDT)
From: Miriam Kadansky - SUN Microsystems <Miriam.Kadansky@east.sun.com>
Reply-To: Miriam Kadansky - SUN Microsystems <Miriam.Kadansky@east.sun.com>
Subject: Tree Configuration and TRACK Design team meeting
To: rmt@lbl.gov
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: f+IZQv8vuZR7VCc39TJHdw==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc
Sender: owner-rmt@lbl.gov
Precedence: bulk
Hello,
Brian Whetten suggested that those of us signed up to work on
the tree-building BB and the TRACK PI get together in person
before the Pittsburgh IETF and get our drafts done.
Dah Ming Chiu and I will be hosting the meeting here at Sun's
Burlington MA office from June 26th through June 29th. The
other attendees so far are
Brad Cain
Brian Levine
Brian Whetten
Other contributors are certainly welcome to attend, but rest
assured that the RMT group will have ample time to review and
comment on our results before and during the IETF meeting.
You won't miss anything unless you have something to contribute
that you haven't already sent to the list.
If you'd like to attend, please email both Dah Ming and I
(miriam.kadansky@sun.com dahming.chiu@sun.com) and we'll let you
know the details.
-----------------------------
Miriam Kadansky
Senior Staff Engineer
Sun Microsystems Labs
781-442-0750
miriam.kadansky@sun.com
Dah Ming Chiu
Senior Staff Engineer
Sun Microsystems Labs
office: 781-442-0525
cell: 617-283-6261
dahming.chiu@sun.com
>From owner-rmt@listserv.lbl.gov Fri Jun 16 10:05:09 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id KAA12959;
Fri, 16 Jun 2000 10:02:53 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id KAA12955
for <rmt@listserv.lbl.gov>; Fri, 16 Jun 2000 10:02:51 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id KAA06388
for <rmt@listserv.lbl.gov>; Fri, 16 Jun 2000 10:02:50 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id KAA06373
for <rmt@lbl.gov>; Fri, 16 Jun 2000 10:02:49 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17241;
Fri, 16 Jun 2000 13:02:46 -0400 (EDT)
Message-Id: <200006161702.NAA17241@ietf.org>
To: IETF-Announce: ;
Cc: RFC Editor <rfc-editor@ISI.EDU>
Cc: Internet Architecture Board <iab@ISI.EDU>
Cc: rmt@lbl.gov
From: The IESG <iesg-secretary@ietf.org>
Subject: Document Action: The Reliable Multicast Design Space for Bulk
Data Transfer to Informational
Date: Fri, 16 Jun 2000 13:02:46 -0400
Sender: owner-rmt@lbl.gov
Precedence: bulk
The IESG has approved the Internet-Draft 'The Reliable Multicast Design
Space for Bulk Data Transfer' <draft-ietf-rmt-design-space-01.txt> as
an Informational RFC. This document is the product of the Reliable
Multicast Transport Working Group. The IESG contact persons are
Allison Mankin and Scott Bradner.
>From owner-rmt@listserv.lbl.gov Fri Jun 23 05:21:33 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id FAA20063;
Fri, 23 Jun 2000 05:18:56 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id FAA20059
for <rmt@listserv.lbl.gov>; Fri, 23 Jun 2000 05:18:53 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id FAA02797
for <rmt@listserv.lbl.gov>; Fri, 23 Jun 2000 05:18:53 -0700 (PDT)
Received: from nilla.aciri.org (p25.stsn.com [208.32.226.25] (may be forged))
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id FAA02794
for <rmt@lbl.gov>; Fri, 23 Jun 2000 05:18:51 -0700 (PDT)
Received: from nilla.aciri.org (localhost [127.0.0.1])
by nilla.aciri.org (8.9.3/8.9.3) with ESMTP id FAA02122;
Fri, 23 Jun 2000 05:38:17 -0700 (PDT)
(envelope-from mjh@nilla.aciri.org)
Message-Id: <200006231238.FAA02122@nilla.aciri.org>
From: Mark Handley <mjh@aciri.org>
X-Organisation: ACIRI
To: rmt@lbl.gov, rm@mash.cs.berkeley.edu
Subject: RMRG Meeting Jul 28 in Arlington, VA
Date: Fri, 23 Jun 2000 05:38:17 -0700
Sender: owner-rmt@lbl.gov
Precedence: bulk
We didn't get back very many responses saying people were interested
in an RMRG meeting before the IETF. Thus, the plan now is to have a
one-day meeting on Friday July 28th, at ISI-East in Arlington, VA.
See http://www.east.isi.edu for details of the location.
The focus of the meeting will be purely on multicast congestion
control, with the aim of understanding where we stand with regard to
allowing some of this work to move into the IETF for standardization.
The room at ISI is rather small, so we need people who wish to attend
to RSVP to both Allison and me so we can tell if we will have enough
space. Also, please mail us with agenda items.
- Mark and Allison
>From owner-rmt@listserv.lbl.gov Fri Jun 23 09:29:28 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id JAA21737;
Fri, 23 Jun 2000 09:27:17 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id JAA21733
for <rmt@listserv.lbl.gov>; Fri, 23 Jun 2000 09:27:15 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id JAA22635
for <rmt@listserv.lbl.gov>; Fri, 23 Jun 2000 09:27:14 -0700 (PDT)
Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122])
by SpamWall.lbl.gov (8.9.3/8.9.3) with SMTP id JAA22623
for <rmt@lbl.gov>; Fri, 23 Jun 2000 09:27:13 -0700 (PDT)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com
with Novell_GroupWise; Fri, 23 Jun 2000 10:26:21 -0600
Message-Id: <s9533b4d.009@prv-mail20.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 5.5.3.1
Date: Fri, 23 Jun 2000 10:26:17 -0600
From: "Sukanta Ganguly" <SGANGULY@novell.com>
To: <mjh@aciri.org>, <rmt@lbl.gov>, <rm@mash.cs.berkeley.edu>
Subject: Re: RMRG Meeting Jul 28 in Arlington, VA
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by SpamWall.lbl.gov id JAA21734
Sender: owner-rmt@lbl.gov
Precedence: bulk
Mark,
Since the IETF is just a couple of days after this scheduled meeting, wouldn't it be possible to reschedule this sometime during the week of the IETF. Due to other work assignments it may be difficult for many to attend. Atleast in my case, though I am a newbie to this, I would eagerly want to attend it but won't be in the position to be physically present at the ISI-east Arlington site on the specified day.
I can't say anything about others. Though this is not a formal IETF WG, people could always schedule informal get togethers. As far as IETF is concerned they should not have any objection such informal evening technical discussion.
Is it feasible? If not then unlucky but interested individuals like can always go though the meeting notes, conclusions, minutes etc.
Would appreciate your response
Thanks
>>> Mark Handley <mjh@aciri.org> 06/23/00 06:38AM >>>
We didn't get back very many responses saying people were interested
in an RMRG meeting before the IETF. Thus, the plan now is to have a
one-day meeting on Friday July 28th, at ISI-East in Arlington, VA.
See http://www.east.isi.edu for details of the location.
The focus of the meeting will be purely on multicast congestion
control, with the aim of understanding where we stand with regard to
allowing some of this work to move into the IETF for standardization.
The room at ISI is rather small, so we need people who wish to attend
to RSVP to both Allison and me so we can tell if we will have enough
space. Also, please mail us with agenda items.
- Mark and Allison
>From owner-rmt@listserv.lbl.gov Fri Jun 23 09:55:11 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id JAA21858;
Fri, 23 Jun 2000 09:54:52 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id JAA21854
for <rmt@listserv.lbl.gov>; Fri, 23 Jun 2000 09:54:50 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id JAA02744
for <rmt@listserv.lbl.gov>; Fri, 23 Jun 2000 09:54:49 -0700 (PDT)
Received: from nilla.aciri.org ([18.170.2.5])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id JAA02730
for <rmt@lbl.gov>; Fri, 23 Jun 2000 09:54:48 -0700 (PDT)
Received: from nilla.aciri.org (localhost [127.0.0.1])
by nilla.aciri.org (8.9.3/8.9.3) with ESMTP id KAA03040;
Fri, 23 Jun 2000 10:14:48 -0700 (PDT)
(envelope-from mjh@nilla.aciri.org)
Message-Id: <200006231714.KAA03040@nilla.aciri.org>
From: Mark Handley <mjh@aciri.org>
X-Organisation: ACIRI
To: "Sukanta Ganguly" <SGANGULY@novell.com>
cc: rmt@lbl.gov, rm@mash.cs.berkeley.edu
Subject: Re: RMRG Meeting Jul 28 in Arlington, VA
In-reply-to: Your message of "Fri, 23 Jun 2000 10:26:17 MDT."
<s9533b3d.069@prv-mail25.provo.novell.com>
Date: Fri, 23 Jun 2000 10:14:48 -0700
Sender: owner-rmt@lbl.gov
Precedence: bulk
> Since the IETF is just a couple of days after this scheduled meeting,
>wouldn't it be possible to reschedule this sometime during the week of
>the IETF.
I'm afraid not - there's no way to schedule a full-day meeting during
the IETF without clashing with sessions that Allison and I have to
attend.
Cheers,
Mark
>From owner-rmt@listserv.lbl.gov Thu Jun 29 02:24:37 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id CAA07252;
Thu, 29 Jun 2000 02:21:25 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id CAA07248
for <rmt@listserv.lbl.gov>; Thu, 29 Jun 2000 02:21:23 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id CAA27706
for <rmt@listserv.lbl.gov>; Thu, 29 Jun 2000 02:21:23 -0700 (PDT)
Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id CAA27703
for <rmt@lbl.gov>; Thu, 29 Jun 2000 02:21:22 -0700 (PDT)
Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate2.mot.com (motgate2 2.1) with ESMTP id CAA21991 for <rmt@lbl.gov>; Thu, 29 Jun 2000 02:21:18 -0700 (MST)]
Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [217.1.10.38]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id CAA24587 for <rmt@lbl.gov>; Thu, 29 Jun 2000 02:21:16 -0700 (MST)]
Received: from arc.corp.mot.com ([217.1.10.142])
by homer.arc.corp.mot.com (8.10.2/8.10.2) with ESMTP id e5T9L4e26237
for <rmt@lbl.gov>; Thu, 29 Jun 2000 19:21:14 +1000 (EST)
Message-ID: <395B14FD.48D489E6@arc.corp.mot.com>
Date: Thu, 29 Jun 2000 19:21:01 +1000
From: Roger Kermode <rkermode@arc.corp.mot.com>
Reply-To: Roger.Kermode@motorola.com
Organization: Motorola
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: rmt-list <rmt@lbl.gov>
Subject: RMT Call for agenda items for Pittsburgh
Content-Type: multipart/mixed;
boundary="------------B2C981EF2CFFF2D0D02E55AA"
Sender: owner-rmt@lbl.gov
Precedence: bulk
This is a multi-part message in MIME format.
--------------B2C981EF2CFFF2D0D02E55AA
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Dear RMTers,
The draft ietf-draft deadline is rapdily approaching...so it's
time that we start to put together an agenda for Adelaide.
Let's keep the momemtum going from the interim meeting,
please send items for disucssion to the chairs as soon as
you can
cheers,
Roger
FYI ...Lorenzo and I have been working on the guidelines
draft, we will post what we have to the list by the end of
the week.
--------------B2C981EF2CFFF2D0D02E55AA
Content-Type: text/x-vcard; charset=us-ascii;
name="rkermode.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Roger Kermode
Content-Disposition: attachment;
filename="rkermode.vcf"
begin:vcard
n:Kermode;Roger
tel;cell:+61-408-212-284
tel;fax:+61-2-9666-0501
tel;home:+61-2-9664-8335
tel;work:+61-2-9666-0558
x-mozilla-html:FALSE
url:www.mot.com.au
org:Motorola Australian Research Centre;Communications and Networking Lab
version:2.1
email;internet:Roger.Kermode@motorola.com
title:Principal Research Engineer, Manager
adr;quoted-printable:;;Level 3,=0D=0A12 Lord St.;Botany;NSW;2019;Australia
fn:Roger Kermode
end:vcard
--------------B2C981EF2CFFF2D0D02E55AA--
>From owner-rmt@listserv.lbl.gov Thu Jun 29 02:29:44 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id CAA07304;
Thu, 29 Jun 2000 02:29:41 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id CAA07300
for <rmt@listserv.lbl.gov>; Thu, 29 Jun 2000 02:29:39 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id CAA28061
for <rmt@listserv.lbl.gov>; Thu, 29 Jun 2000 02:29:39 -0700 (PDT)
Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id CAA28058
for <rmt@lbl.gov>; Thu, 29 Jun 2000 02:29:38 -0700 (PDT)
Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id CAA28276 for <rmt@lbl.gov>; Thu, 29 Jun 2000 02:29:02 -0700 (MST)]
Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [217.1.10.38]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id CAA23141 for <rmt@lbl.gov>; Thu, 29 Jun 2000 02:29:04 -0700 (MST)]
Received: from arc.corp.mot.com ([217.1.10.142])
by homer.arc.corp.mot.com (8.10.2/8.10.2) with ESMTP id e5T9Sue26280
for <rmt@lbl.gov>; Thu, 29 Jun 2000 19:28:56 +1000 (EST)
Message-ID: <395B16D5.4E5C096@arc.corp.mot.com>
Date: Thu, 29 Jun 2000 19:28:53 +1000
From: Roger Kermode <rkermode@arc.corp.mot.com>
Reply-To: Roger.Kermode@motorola.com
Organization: Motorola
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: rmt-list <rmt@lbl.gov>
Subject: Re: RMT Call for agenda items for Pittsburgh
References: <395B14FD.48D489E6@arc.corp.mot.com>
Content-Type: multipart/mixed;
boundary="------------C4BA31062458B8CA05C39E91"
Sender: owner-rmt@lbl.gov
Precedence: bulk
This is a multi-part message in MIME format.
--------------C4BA31062458B8CA05C39E91
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Roger Kermode wrote:
> Dear RMTers,
>
> The draft ietf-draft deadline is rapdily approaching...so it's
> time that we start to put together an agenda for Adelaide.
Ahh the joys of cut and paste and hitting the send key to early
at the end of a long day...make that Pittsburgh *sigh*!
> Let's keep the momemtum going from the interim meeting,
Groan ...make that the last meeting
> please send items for disucssion to the chairs as soon as
> you can
>
> cheers,
>
> Roger
>
> FYI ...Lorenzo and I have been working on the guidelines
> draft, we will post what we have to the list by the end of
> the week.
--------------C4BA31062458B8CA05C39E91
Content-Type: text/x-vcard; charset=us-ascii;
name="rkermode.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Roger Kermode
Content-Disposition: attachment;
filename="rkermode.vcf"
begin:vcard
n:Kermode;Roger
tel;cell:+61-408-212-284
tel;fax:+61-2-9666-0501
tel;home:+61-2-9664-8335
tel;work:+61-2-9666-0558
x-mozilla-html:FALSE
url:www.mot.com.au
org:Motorola Australian Research Centre;Communications and Networking Lab
version:2.1
email;internet:Roger.Kermode@motorola.com
title:Principal Research Engineer, Manager
adr;quoted-printable:;;Level 3,=0D=0A12 Lord St.;Botany;NSW;2019;Australia
fn:Roger Kermode
end:vcard
--------------C4BA31062458B8CA05C39E91--
>From owner-rmt@listserv.lbl.gov Tue Jul 11 04:26:20 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id EAA21218;
Tue, 11 Jul 2000 04:20:12 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id EAA21214
for <rmt@listserv.lbl.gov>; Tue, 11 Jul 2000 04:20:09 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id EAA20532
for <rmt@listserv.lbl.gov>; Tue, 11 Jul 2000 04:20:08 -0700 (PDT)
Received: from motgate.mot.com (motgate.mot.com [129.188.136.100])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id EAA20529
for <rmt@lbl.gov>; Tue, 11 Jul 2000 04:20:07 -0700 (PDT)
Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (motgate 2.1) with ESMTP id EAA05440 for <rmt@lbl.gov>; Tue, 11 Jul 2000 04:20:07 -0700 (MST)]
Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [217.1.10.38]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id EAA05344 for <rmt@lbl.gov>; Tue, 11 Jul 2000 04:20:04 -0700 (MST)]
Received: from arc.corp.mot.com ([217.2.31.106])
by homer.arc.corp.mot.com (8.10.2/8.10.2) with ESMTP id e6BBK1e23046
for <rmt@lbl.gov>; Tue, 11 Jul 2000 21:20:02 +1000 (EST)
Message-ID: <396B02DF.E80DB2F8@arc.corp.mot.com>
Date: Tue, 11 Jul 2000 21:19:59 +1000
From: Roger Kermode <rkermode@arc.corp.mot.com>
Reply-To: Roger.Kermode@motorola.com
Organization: Motorola
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: rmt-list <rmt@lbl.gov>
Subject: RMT Author Guidelines Draft
Content-Type: multipart/mixed;
boundary="------------E7C941D9DE1B05428797AEE5"
Sender: owner-rmt@lbl.gov
Precedence: bulk
This is a multi-part message in MIME format.
--------------E7C941D9DE1B05428797AEE5
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Dear patient RMT Working Group members,
please find attached the first pass on the long awaited
guidelines draft:
"Author Guidelines for RMT Building Blocks and
Protocol Instantiation documents"
The draft should appear on the Internet Drafts
archive shortly. Please take the time to read through
the draft and to provide feedback to the list. We'd
like to rev this document through to RFC as soon
as we can.
regards,
Roger Kermode
Lorenzo Vicisano
Allison Mankin
--------------E7C941D9DE1B05428797AEE5
Content-Type: text/plain; charset=us-ascii;
name="draft-ietf-rmt-author-guidelines-00.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="draft-ietf-rmt-author-guidelines-00.txt"
RMT Working Group R.Kermode/Motorola
Internet Engineering Task Force L.Vicisano/Cisco
INTERNET-DRAFT draft-ietf-rmt-author-guidelines-00.txt 29 June 2000
Expires 29 December 2000
Author Guidelines for RMT Building Blocks and Protocol Instantiation documents
<draft-ietf-rmt-author-guidelines-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are valid for a maximum of six months and may be
updated, replaced, or obsoleted by other documents at any time. It
is inappropriate to use Internet-Drafts as reference material or to
cite them other than as a "work in progress".
To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html.
Abstract
This document provides general guidelines to assist the authors of
reliable multicast transport (RMT) building block and protocol
instantiation definitions. The purpose of these guidelines is to ensure
that any building block and protocol instantiation definitions produced
contain sufficient information to fully explain their operation and use.
If followed these guidelines will result in clearly defined RMT building
blocks and protocol instantiation definitions that can be refined and
augmented to create new protocols for use in new scenarios for which any
existing protocols were not designed.
Copyright Notice
Copyright (C) The Internet Society (1999). All Rights Reserved.
Draft RMT Draft Author Guidelines 29 June 2000
1. Introduction
Reliable Multicast Transport (RMT) protocols can be constructed in a
variety of ways, some of which will work better for certain situations
then others. It is believed that the requirements space for reliable
multicast transport is sufficiently diverse that no one protocol can
meet all the requirements [RMT-DS]. However, it is also believed that
there is sufficient commonality between the various approaches that it
should be possible to define a number of building blocks [RMT-BB] from
which the various RMT protocols can be constructed.
One key benefit of this approach is that the same building block can be
used multiple times in different protocol instantiations. Another key
benefit is that building blocks may be upgraded as experience and
understanding is gained. For this operation to be possible the building
block needs to be clearly defined in terms of what it does, how
interacts with other building blocks and how fits into the overall
architecture of a protocol instantiation. This description should also
be sufficiently detailed so that those wishing to improve upon a
particular building block or protocol instantiation can do with a full
understanding of the design decisions and tradeoffs were made earlier.
The building block approach presents also some dangers that must be well
understood in order to avoid potential specification flaws. The most
important danger is related to inappropriate usage of building blocks.
Although any effort should be made in order to produce a modular and
reusable specification of building blocks, for practical reasons this
goal is not always fully achievable. This results in the specification
of building blocks whose applicability is context dependent. In order to
avoid mis-usage of the building blocks, any external dependency must be
highlighted in the building block specification. Furthermore, the
specification must contain a precise applicability statement for the
building block. Conversely, any protocol instantiation specification
must state how any building block being used in it meets the protocol
instantiation's applicability requirements.
1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and"OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Expires 29 December 2000 [Page 2]
Draft RMT Draft Author Guidelines 29 June 2000
2. The Guidelines
This document provides guidelines for authors of the two main kinds of
RMT drafts; building block drafts and protocol instantiation drafts. The
guidelines for each are as follows.
2.1. Building Block Draft Guidelines
All RMT Building block drafts MUST contain sections that cover the
following.
2.1.1. Rationale
Individual building blocks SHOULD be reusable within multiple protocols
and MUST provide functionality not present within other building blocks.
If a building block is currently used in a single protocol
instantiation, then it MUST specify some functionality that is likely to
be reused in another (future) protocol instantiation.
The rational section of a building block draft must clearly define why
the particular level of granularity for the functional decomposition
that resulted in the building block was chosen. If the granularity is
too small it is highly likely that the building blocks will be trivial,
and therefore require excessive additional effort to realize a working
protocol. Conversely, if the level of granularity is too large building
blocks will only usable within a single protocol instantiation. This
section MUST show that level of granularity is appropriate so that
neither problem occurs.
2.1.2. Functionality
The functionality section within a building block draft MUST describe
all algorithms and functions contained within the building block. In
addition, the external interfaces for accessing these algorithms and
functions must be fully specified so that the building block can be
combined with other building blocks and any additional functionality
specified within a protocol instantiation draft to realize a working
protocol.
Expires 29 December 2000 [Page 3]
Draft RMT Draft Author Guidelines 29 June 2000
2.1.3. Applicability Statement
One of the most important sections of a building block draft will be the
Applicability Statement. The purpose of this section is to provide
sufficient details about the intended use of the building block so that
potential authors of protocol instantiation will be able to use the
building block in conformance to its applicability constraints. Also
the Applicability Statement section will enable future building blocks
drafts authors to quickly be able to determine whether or not their
particular need can be met with an existing building block. For this to
be possible the Applicability Statement MUST describe
o Intended scenarios for the building block's use
o The building blocks known failure modes, why they occur, and how they
can be detected.
o A list of environmental considerations that includes but is not
limited to whether the building block requires multi-source multicast
or can be used in single-source only multicast networks, satellite
networks, asymmetric networks, and wireless networks.
2.1.4. Packet-Header Fields
If a building block implements a functionality whose realization
requires an exchange of protocol messages between multiple agents, then
the building block specification MUST state what kind of information is
required and how this is exchanged. This includes detailed description
the data format and various communication requirements, such as timing
constraints, and network requirement (e.g. multicast vs. unicast
delivery).
Typically the data format specification is at the level of "generic
header fields" without a full bit-level header specification. Generic
header fields MAY specify additional requirement, such as representation
precision or preferred position within the packet header (this last
constraint might be dictated by efficiency concerns).
A building block specification MAY specify "abstract messages" that
carry particular information for exclusive use within the building
block, however, more frequently, it will rely on the protocol messages
specified in the protocol instantiation to carry the information it
needs.
Expires 29 December 2000 [Page 4]
Draft RMT Draft Author Guidelines 29 June 2000
The building block that provides Generic Router Assist functionality is
and exception to the rule state above. For efficiency reason, this
building block may fully specify header fields and position of these
fields within the packet-header.
2.1.5. Requirements from other Building Blocks
Each building block will encapsulate a specific well defined piece of
functionality that is common to multiple protocol instantiations.
However, this does not mean that building block definitions will be
generated in isolation from other building blocks. For example, a
congestion control building block will have specific requirements
regarding loss notification from either a NACK or ACK building block.
The "Requirements from other Building Blocks" section is included to
capture these requirements so that the authors of related building
blocks can determine what functionality they need to provide in order to
use a particular building block.
Specifically, the "Requirements from other Building Blocks section" MUST
provide a complete and exhaustive enumeration of all the requirements
that will be made upon other building blocks in order for the building
block being specified to operate in its intended manner. Requirements
that SHOULD be enumerated include but are not limited to
o Event generation for and responses to other building blocks
o Message ordering relative to messages from other building blocks.
2.1.6. Security Considerations
Protocol instantiations have the ultimate responsibility of addressing
security requirements, in conformance to RFC2357. Security
consideration may not be applicable to generic building blocks other
than a specific "security" building block. Some building blocks,
however, may rise special security issues, either due to the nature of
communication required by the building block or due to the intended
usage of the building block in a protocol instantiation. When special
security issues are present in a building block, its specification MUST
address them explicitly.
An example of this might be a building block that involves exchange of
data that is particularly sensitive to security attacks.
Expires 29 December 2000 [Page 5]
Draft RMT Draft Author Guidelines 29 June 2000
2.1.7. Codepoint Considerations
Certain Building Blocks will specify general frameworks for describing
functionality while leaving the detail open for implementation specific
algorithms. One example of such a building block is the Forward Error
Correction (FEC) building block which describes how the framing aspects
for FEC message fragments but not the algorithms used to generate the
redundant data.
2.1.8. Summary Checklist
Rationale
_ Provide justification for the building block's existence
_ Provide rationale for the building block's granularity
Functionality
_ Functionality contained within the building block
_ External interfaces
Applicability Statement
_ Intended usage
_ Failure modes (including means of detection if known)
_ Environmental considerations
Packety Header Fields
_ Specification of logical packet-header fields (*)
_ Abstract messages specifications (*)
Requirements from other building blocks;
_ Mandatory needs from other building blocks
Security Considerations
_ Specify as much as possible (w.r.t. procedures, algorithms and
data encoding), without affecting the general applicability of
the building block.
(*) May not be applicable to some building blocks.
Expires 29 December 2000 [Page 6]
Draft RMT Draft Author Guidelines 29 June 2000
2.2. Protocol Instantiation Draft Guidelines
Protocol Instantiation drafts have one purpose: to specify how one can
combine multiple building blocks to construct a new fully specified
working protocol. To that end RMT Protocol Instantiation drafts MUST
contain the following four sections.
2.2.1. Applicability Statement
The applicability statement's purpose is to frame the design space in
which the fully realized protocol will operate and to thereby enable
subsequent would be RMT protocol designers to determine whether or not
an existing protocol already meets their needs. For this to be possible
the applicability statement MUST adhere to the following guidelines
1) The target application space for which the protocol is intended MUST
be clearly identified. For example; is the protocol to be used for
real-time delivery or not, or non-real time file transfer.
2) The target scale, in terms of maximum number of receivers per
session, for which the protocol is intended MUST be clearly
specified. If the protocol has an architectural limitation resulting
from the optimization of another feature, say per packet
acknowledgment, this SHOULD be included.
3) The applicability statement MUST identify the intended environment's
for the protocols use AND list any environments in which the
protocol should not be used. Example environments that should be
considered include asymmetric networks, wireless networks, and
satellite networks.
4) Finally, all protocols have inherent weaknesses that stem from the
optimization for a specific feature. These weaknesses can manifest
in spectacular failure modes when certain conditions occur. When
known these conditions and the nature of how the subsequent failure
can be detected MUST be included in the applicability statement.
2.2.2. Architecture Definition
Protocol Instantiations define how to combine one or more building
blocks to create a working protocol. The Architecture Definition lays
out the framework for how this take place. For this framework to be
complete, it MUST contain the following information:
Expires 29 December 2000 [Page 7]
Draft RMT Draft Author Guidelines 29 June 2000
1) An overview of the major facets of the protocols operation.
2) Full enumeration and overview of which Building Blocks with explicit
references to their documents that define them.
3) An overview of how the aforementioned building blocks are to be
joined.
4) A discussion of the design tradeoffs made in the selection of the
chosen architecture.
2.2.3. Conformance Statement
The conformance statement below MUST be included and adhered to
"This Protocol Instantiation document, in conjunction with the
following Building Block documents identified in [list of
relevant building block references] completely specifies a
working reliable multicast transport protocol that conforms
to the requirements described in RFC 2357."
Protocol instantiation document authors are specifically reminded that
RFC2357 requires that any RMT protocol put forward for standardization
with the IETF is required to protect the network in as much as is
possible. This does not mean that RMT protocols will be held to a higher
standard than unicast transport protocols, merely that they should be
designed to perform at least as well as unicast transport protocols when
it comes to the possibility of protocol failure.
2.2.4. Functionality Definition
Building Block documents will be incomplete in that they will specify an
abstract framework of a building block's functionality. Complete
algorithmic specifications for each building block along with any
additional functionality MUST provided within the Protocol Instantiation
document's functionality definition. Furthermore, this description must
show that each building block is used in accordance with its respective
applicability statement. Finally the functionality description must
provide a description of the abstract programming interface for
interfacing the protocol instantiation with the applications that will
use it.
Expires 29 December 2000 [Page 8]
Draft RMT Draft Author Guidelines 29 June 2000
2.2.5. Packet Formats
Once all the functionality has been fully defined, the Protocol
Instantiation document must defined the packet formats that will be used
by the protocol. Each message part and the rules for their concatenation
MUST be specified for both IPv4 [RFC791] and IPv6 [RFC2460]. Support for
IPSEC [RFC2401] MUST be explicitly shown.
In recognition of the fact that protocols will evolve and that IP
protocol numbers are a scarce resource, protocol instantiations MUST
initially define packet formats for use over UDP [RFC768].
[RK: Open issue about general purpose RMT protocol number]
2.2.6. Summary Checklist
Applicability Statement
_ Target application space
_ Target scale
_ Intended environment
_ Weaknesses and known failure modes
Architecture Definition
_ Operational overview
_ Building blocks used
_ Details on how building blocks are joined
Conformance Statement
_ Inclusion of mandatory paragraph
Functionality Definition
_ Building block algorithmic specification
_ Addition functionality specification
_ Compliance with building block applicability statements
_ Abstract program interface
Packet Formats
_ IPv4 message parts
_ IPv6 message parts
_ IPSEC support
_ Message ordering
Expires 29 December 2000 [Page 9]
Draft RMT Draft Author Guidelines 29 June 2000
3. IANA Considerations
General RMT protocol number? [RK: need to talk with ADs about this]
4. Acknowledgments
This document represents an overview of the mandatory elements required
for the specification of building blocks and protocol instantiations
within the the for RMT working group. The requirements presented are a
summarization of discussions held between the RMT Working Group chairs
and the participants in the IRTF Reliable Multicast Research Group.
Although the name of these participants are too numerous to list here,
the Working Group chairs would like to thank everyone who has
participated in these discussions for their contributions.
5. References
[HWKFV99]
M. Handley, B.Whetten, R. Kermode, S.Floyd, L. Vicisano, and M.
Luby, "The Reliable Multicast Design Space for Bulk Data Transfer,"
Internet Draft, Internet Engineering Task Force, March 1999.
[WLKHFL99]
B.Whetten, L. Vicisano, R. Kermode, M. Handley, S.Floyd, and M.
Luby, "Reliable Multicast Transport Building Blocks for One-to-Many
Bulk-Data Transfer," Internet Draft, Internet Engineering Task
Force, March 1999.
[RFC2401]
S. Kent, R. Atkinson, "Security Architecture for the Internet
Protocol", RFC2401, November 1998.
[RFC791]
J. Postel, "Darpa Internet Protocol Specification", ST5, RFC791,
September 1981.
[RFC2460]
S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC2460, December 1998.
[RFC768]
J. Postel, "User Datagram Protocol", RFC768, August 1980.
Expires 29 December 2000 [Page 10]
Draft RMT Draft Author Guidelines 29 June 2000
6. Authors' Addresses
Roger Kermode
Motorola Australian Research Centre
Locked Bag 5028
Botany NSW 1455,
Australia.
Roger.Kermode@motorola.com
Lorenzo Vicisano
Cisco Systems,
170 West Tasman Dr.
San Jose, CA 95134, USA
lorenzo@cisco.com
7. Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are included
on all such copies and derivative works. However, this document itself
may not be modified in any way, such as by removing the copyright notice
or references to the Internet Society or other Internet organizations,
except as needed for the purpose of developing Internet standards in
which case the procedures for copyrights defined in the Internet
languages other than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE."
Expires 29 December 2000 [Page 11]
Draft RMT Draft Author Guidelines 29 June 2000
Table of Contents
1 Introduction .................................................... 2
1.1 Terminology ................................................... 2
2 The Guidelines .................................................. 3
2.1 Building Block Draft Guidelines ............................... 3
2.1.1 Rationale ................................................... 3
2.1.2 Functionality ............................................... 3
2.1.3 Applicability Statement ..................................... 4
2.1.4 Packet-Header Fields ........................................ 4
2.1.5 Requirements from other Building Blocks ..................... 5
2.1.6 Security Considerations ..................................... 5
2.1.7 Codepoint Considerations .................................... 6
2.1.8 Summary Checklist ........................................... 6
2.2 Protocol Instantiation Draft Guidelines ....................... 7
2.2.1 Applicability Statement ..................................... 7
2.2.2 Architecture Definition ..................................... 7
2.2.3 Conformance Statement ....................................... 8
2.2.4 Functionality Definition .................................... 8
2.2.5 Packet Formats .............................................. 9
2.2.6 Summary Checklist ........................................... 9
3 IANA Considerations ............................................. 10
4 Acknowledgments ................................................. 10
5 References ...................................................... 10
6 Authors' Addresses .............................................. 11
7 Full Copyright Statement ........................................ 11
Expires 29 December 2000 [Page 12]
--------------E7C941D9DE1B05428797AEE5
Content-Type: text/x-vcard; charset=us-ascii;
name="rkermode.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Roger Kermode
Content-Disposition: attachment;
filename="rkermode.vcf"
begin:vcard
n:Kermode;Roger
tel;cell:+61-408-212-284
tel;fax:+61-2-9666-0501
tel;home:+61-2-9664-8335
tel;work:+61-2-9666-0558
x-mozilla-html:FALSE
url:www.mot.com.au
org:Motorola Australian Research Centre;Communications and Networking Lab
version:2.1
email;internet:Roger.Kermode@motorola.com
title:Principal Research Engineer, Manager
adr;quoted-printable:;;Level 3,=0D=0A12 Lord St.;Botany;NSW;2019;Australia
fn:Roger Kermode
end:vcard
--------------E7C941D9DE1B05428797AEE5--
>From owner-rmt@listserv.lbl.gov Wed Jul 12 02:01:01 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id BAA25535;
Wed, 12 Jul 2000 01:58:44 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id BAA25531
for <rmt@listserv.lbl.gov>; Wed, 12 Jul 2000 01:58:41 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id BAA05685
for <rmt@listserv.lbl.gov>; Wed, 12 Jul 2000 01:58:41 -0700 (PDT)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
by SpamWall.lbl.gov (8.9.3/8.9.3) with SMTP id BAA05681
for <rmt@lbl.gov>; Wed, 12 Jul 2000 01:58:40 -0700 (PDT)
Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP
id <g.07633-0@bells.cs.ucl.ac.uk>; Wed, 12 Jul 2000 09:58:24 +0100
To: Roger.Kermode@motorola.com
cc: rmt-list <rmt@lbl.gov>, J.Crowcroft@cs.ucl.ac.uk
Subject: Re: RMT Author Guidelines Draft
In-reply-to: Your message of "Tue, 11 Jul 2000 21:19:59 +1000." <396B02DF.E80DB2F8@arc.corp.mot.com>
Date: Wed, 12 Jul 2000 09:58:22 +0100
Message-ID: <2313.963392302@cs.ucl.ac.uk>
From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
Sender: owner-rmt@lbl.gov
Precedence: bulk
In message <396B02DF.E80DB2F8@arc.corp.mot.com>, Roger Kermode typed:
>>
>>"Author Guidelines for RMT Building Blocks and
>> Protocol Instantiation documents"
Roger et al,
typo in 2.1.6 security considerations - 3rd sentance - "some building
blocks, however, may rise"... - should be "raise"
meanwhile, i would say you need another section - the building block
approach brings in a new risk compared with other transport protocol
efforts:- that of feature interactions - you could have blocks A+B
go together ok and B+C, but not A+B+C ....i can't think of an exact
example, but i am sure there's one in the area of
multirate congestion control, router supprt, and security,
for example:-)
cheers
jon
>From owner-rmt@listserv.lbl.gov Wed Jul 12 03:34:04 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id DAA25671;
Wed, 12 Jul 2000 03:32:22 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id DAA25667
for <rmt@listserv.lbl.gov>; Wed, 12 Jul 2000 03:32:20 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id DAA12351
for <rmt@listserv.lbl.gov>; Wed, 12 Jul 2000 03:32:19 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id DAA12347
for <rmt@lbl.gov>; Wed, 12 Jul 2000 03:32:18 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15232;
Wed, 12 Jul 2000 06:32:17 -0400 (EDT)
Message-Id: <200007121032.GAA15232@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: rmt@lbl.gov
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-rmt-author-guidelines-00.txt
Date: Wed, 12 Jul 2000 06:32:17 -0400
Sender: owner-rmt@lbl.gov
Precedence: bulk
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Reliable Multicast Transport Working Group of the IETF.
Title : Author Guidelines for RMT Building Blocks and Protocol
Instantiation documents
Author(s) : R. Kermode, L. Vicisano
Filename : draft-ietf-rmt-author-guidelines-00.txt
Pages : 12
Date : 11-Jul-00
This document provides general guidelines to assist the authors of
reliable multicast transport (RMT) building block and protocol
instantiation definitions. The purpose of these guidelines is to ensure
that any building block and protocol instantiation definitions produced
contain sufficient information to fully explain their operation and use.
If followed these guidelines will result in clearly defined RMT building
blocks and protocol instantiation definitions that can be refined and
augmented to create new protocols for use in new scenarios for which any
existing protocols were not designed.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rmt-author-guidelines-00.txt
Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-rmt-author-guidelines-00.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.
Send a message to:
mailserv@ietf.org.
In the body type:
"FILE /internet-drafts/draft-ietf-rmt-author-guidelines-00.txt".
NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv@ietf.org"
Content-Type: text/plain
Content-ID: <20000711135128.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-rmt-author-guidelines-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-rmt-author-guidelines-00.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <20000711135128.I-D@ietf.org>
--OtherAccess--
--NextPart--
>From owner-rmt@listserv.lbl.gov Wed Jul 12 08:33:41 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id IAA27260;
Wed, 12 Jul 2000 08:31:50 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id IAA27256
for <rmt@listserv.lbl.gov>; Wed, 12 Jul 2000 08:31:48 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id IAA15677
for <rmt@listserv.lbl.gov>; Wed, 12 Jul 2000 08:31:47 -0700 (PDT)
Received: from p-biset.issy.cnet.fr (p-biset.issy.cnet.fr [139.100.0.33])
by SpamWall.lbl.gov (8.9.3/8.9.3) with SMTP id IAA15644
for <rmt@lbl.gov>; Wed, 12 Jul 2000 08:31:44 -0700 (PDT)
Received: by p-biset.issy.cnet.fr with Internet Mail Service (5.5.2448.0)
id <3JZBJW0Q>; Wed, 12 Jul 2000 17:31:21 +0200
Message-ID: <C166CCE3B1B0D311B16C0060974B1C634EB505@r-mhs.rennes.cnet.fr>
From: =?iso-8859-1?Q?BABONNEAU_G=E9rard_FTRD/DMI/REN?=
<gerard.babonneau@rd.francetelecom.fr>
To: "'ietf-rmt-list'" <rmt@lbl.gov>
Subject: Building Blocks
Date: Wed, 12 Jul 2000 17:31:25 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by SpamWall.lbl.gov id IAA27257
Sender: owner-rmt@lbl.gov
Precedence: bulk
Hello,
I'm modeling multicast protocols, and I'm currently working on PGM.
Many networks works better when senders have a constant or limited
throughput. Do you intend to include a function to control the throughput in
the congestion control block, or to create a new BB to control the sender
rate? In this second case, it could receive information from congestion
control to adapt the rate, if necessary.
Best regards,
Salutations,
Gérard BABONNEAU
>From owner-rmt@listserv.lbl.gov Wed Jul 12 12:10:53 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id MAA28025;
Wed, 12 Jul 2000 12:10:17 -0700 (PDT)
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id MAA28021
for <rmt@listserv.lbl.gov>; Wed, 12 Jul 2000 12:10:15 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id MAA03251
for <rmt@listserv.lbl.gov>; Wed, 12 Jul 2000 12:10:14 -0700 (PDT)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id MAA03244
for <rmt@lbl.gov>; Wed, 12 Jul 2000 12:10:14 -0700 (PDT)
Received: from lorenzo-u10.cisco.com (lorenzo-u10.cisco.com [171.69.65.85])
by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id MAA23449;
Wed, 12 Jul 2000 12:09:58 -0700 (PDT)
Received: from localhost (lorenzo@localhost) by lorenzo-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id MAA04222; Wed, 12 Jul 2000 12:09:43 -0700 (PDT)
Message-Id: <200007121909.MAA04222@lorenzo-u10.cisco.com>
X-Authentication-Warning: lorenzo-u10.cisco.com: lorenzo owned process doing -bs
X-Mailer: exmh version 2.0.2 2/24/98
To: =?iso-8859-1?Q?BABONNEAU_G=E9rard_FTRD/DMI/REN?= <gerard.babonneau@rd.francetelecom.fr>
cc: "'ietf-rmt-list'" <rmt@lbl.gov>
Subject: Re: Building Blocks
In-Reply-To: Your message of "Wed, 12 Jul 2000 17:31:25 +0200."
<C166CCE3B1B0D311B16C0060974B1C634EB505@r-mhs.rennes.cnet.fr>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Date: Wed, 12 Jul 2000 12:09:43 -0700
From: Lorenzo Vicisano <lorenzo@cisco.com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by SpamWall.lbl.gov id MAA28022
Sender: owner-rmt@lbl.gov
Precedence: bulk
Gerard,
> I'm modeling multicast protocols, and I'm currently working on PGM.
> Many networks works better when senders have a constant or limited
> throughput. Do you intend to include a function to control the throughput in
> the congestion control block, or to create a new BB to control the sender
> rate? In this second case, it could receive information from congestion
> control to adapt the rate, if necessary.
If the issue is "using a fixed rate instead of doing congestion
control", it's only acceptable in privately controlled network,
not in the Internet (RFC2357).
If instead you are proposing to add an upper bound to the sender rate
and still perform congestion control without crossing the upper limit,
I believe that you can just go ahead and implement this (it doesn't
require specification). It is true that you might end up using less
than your fair share and hence you should be allowed to customize you
CC algorithm (e.g. making it more aggressive), however I believe that
is a complex issue to be dealt with carefully.
Lorenzo
>From owner-rmt@listserv.lbl.gov Wed Jul 12 17:19:54 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id RAA00136;
Wed, 12 Jul 2000 17:19:10 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id RAA00132
for <rmt@listserv.lbl.gov>; Wed, 12 Jul 2000 17:19:08 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id RAA08177
for <rmt@listserv.lbl.gov>; Wed, 12 Jul 2000 17:19:07 -0700 (PDT)
Received: from vedatel.com (root@[216.207.224.25])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id RAA08167
for <rmt@lbl.gov>; Wed, 12 Jul 2000 17:19:00 -0700 (PDT)
Received: from vedatel.com (adsl-77.dacor.net [205.133.74.77])
by vedatel.com (8.9.3/8.9.3) with ESMTP id UAA68613;
Wed, 12 Jul 2000 20:53:40 -0400 (EDT)
(envelope-from tscott@vedatel.com)
Message-ID: <396D0C23.574BB3AF@vedatel.com>
Date: Wed, 12 Jul 2000 20:24:03 -0400
From: Telecom Tom <tscott@vedatel.com>
Organization: Vedatel
X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.7 sun4m)
X-Accept-Language: en-US, es, de, fr
MIME-Version: 1.0
To: rmt@lbl.gov
Subject: Re: I-D ACTION:draft-ietf-rmt-author-guidelines-00.txt
References: <200007121032.GAA15232@ietf.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-rmt@lbl.gov
Precedence: bulk
Internet-Drafts@ietf.org wrote:
> Title : Author Guidelines for RMT Building Blocks and Protocol
> Instantiation documents
> Author(s) : R. Kermode, L. Vicisano
> Filename : draft-ietf-rmt-author-guidelines-00.txt
> Pages : 12
> Date : 11-Jul-00
>
> This document provides general guidelines to assist the authors of
> reliable multicast transport (RMT) building block and protocol
> instantiation definitions. The purpose of these guidelines is to ensure
> that any building block and protocol instantiation definitions produced
> contain sufficient information to fully explain their operation and use.
> If followed these guidelines will result in clearly defined RMT building
> blocks and protocol instantiation definitions that can be refined and
> augmented to create new protocols for use in new scenarios for which any
> existing protocols were not designed.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-rmt-author-guidelines-00.txt
Would you consider adding two references at the end of the draft:
[Boecking00]
S. Boecking, "Object-Oriented Network Protocols," London:
Addison-Wesley, 2000.
[Gouda98]
M. Gouda, "Elements of Network Protocol Design," New York:
Wiley, 1998.
I can't resist the temptation to explicitly mention the O-word. These
building blocks resemble objects. Is that the intention of the RMT WG?
-- TT
---------------------------------------------------
Tom Nelson Scott Vedatel Co
1411 Sheffield Dr. Bowling Green OH 43402
"In IP We Trust" "Java Rules" "E Pluribus Unix"
---------------------------------------------------
>From owner-rmt@listserv.lbl.gov Wed Jul 12 17:34:32 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id RAA00236;
Wed, 12 Jul 2000 17:34:05 -0700 (PDT)
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id RAA00232
for <rmt@listserv.lbl.gov>; Wed, 12 Jul 2000 17:34:03 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id RAA11620
for <rmt@listserv.lbl.gov>; Wed, 12 Jul 2000 17:34:02 -0700 (PDT)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id RAA11615
for <rmt@lbl.gov>; Wed, 12 Jul 2000 17:34:02 -0700 (PDT)
Received: from lorenzo-u10.cisco.com (lorenzo-u10.cisco.com [171.69.65.85])
by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id RAA01581;
Wed, 12 Jul 2000 17:33:46 -0700 (PDT)
Received: from localhost (lorenzo@localhost) by lorenzo-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id RAA04784; Wed, 12 Jul 2000 17:33:31 -0700 (PDT)
Message-Id: <200007130033.RAA04784@lorenzo-u10.cisco.com>
X-Authentication-Warning: lorenzo-u10.cisco.com: lorenzo owned process doing -bs
X-Mailer: exmh version 2.0.2 2/24/98
To: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
cc: Roger.Kermode@motorola.com, rmt-list <rmt@lbl.gov>
Subject: Re: RMT Author Guidelines Draft
In-Reply-To: Your message of "Wed, 12 Jul 2000 09:58:22 BST."
<2313.963392302@cs.ucl.ac.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 12 Jul 2000 17:33:31 -0700
From: Lorenzo Vicisano <lorenzo@cisco.com>
Sender: owner-rmt@lbl.gov
Precedence: bulk
> meanwhile, i would say you need another section - the building block
> approach brings in a new risk compared with other transport protocol
> efforts:- that of feature interactions - you could have blocks A+B
> go together ok and B+C, but not A+B+C ....i can't think of an exact
> example, but i am sure there's one in the area of
> multirate congestion control, router supprt, and security,
> for example:-)
Jon,
2.1.3 (Applicability Statement) addresses this in part,
but we should make it more explicit.
Thanks for your comments,
Lorenzo
>From owner-rmt@listserv.lbl.gov Thu Jul 13 17:40:55 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id RAA04492;
Thu, 13 Jul 2000 17:39:13 -0700 (PDT)
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id RAA04488
for <rmt@listserv.lbl.gov>; Thu, 13 Jul 2000 17:39:11 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id RAA02891
for <rmt@listserv.lbl.gov>; Thu, 13 Jul 2000 17:39:10 -0700 (PDT)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id RAA02876
for <rmt@lbl.gov>; Thu, 13 Jul 2000 17:39:09 -0700 (PDT)
Received: from lorenzo-u10.cisco.com (lorenzo-u10.cisco.com [171.69.65.85])
by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id RAA20089
for <rmt@lbl.gov>; Thu, 13 Jul 2000 17:38:52 -0700 (PDT)
Received: from localhost (lorenzo@localhost) by lorenzo-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id RAA07084 for <rmt@lbl.gov>; Thu, 13 Jul 2000 17:38:38 -0700 (PDT)
Message-Id: <200007140038.RAA07084@lorenzo-u10.cisco.com>
X-Authentication-Warning: lorenzo-u10.cisco.com: lorenzo owned process doing -bs
X-Mailer: exmh version 2.0.2 2/24/98
To: rmt-list <rmt@lbl.gov>
Subject: draft-ietf-rmt-pi-alc-01.txt and draft-ietf-rmt-bb-fec-01.txt
Mime-Version: 1.0
Content-Type: multipart/mixed ;
boundary="==_Exmh_924555160"
Date: Thu, 13 Jul 2000 17:38:38 -0700
From: Lorenzo Vicisano <lorenzo@cisco.com>
Sender: owner-rmt@lbl.gov
Precedence: bulk
This is a multipart MIME message.
--==_Exmh_924555160
Content-Type: text/plain; charset=us-ascii
Dear RMT-ers,
Please find attached the latest revisions of the FEC-BB and ALC-PI
drafts, just submitted to the IETF directory.
The FEC-BB draft is in "tune" with the ALC-PI one and we (the document
editors) have tried to accommodate the NORM PI needs as well
(FEC+ARQ in general). We believe, however, that the FEC BB needs more work
in this direction. It would be great if NORM PI editors, or any other
interested party could provide feedback (or oven better written text)
on this.
Also, in the FEC draft we had to face the issue of how to designate FEC
encoders that cannot be (or are not) formally specified. Our (proposed)
solution is in sections 3 and 4 of the draft. We would really like to get
some feedback on this important issue as well.
Regards,
Lorenzo Vicisano
--==_Exmh_924555160
Content-Type: text/plain ; name="draft-ietf-rmt-pi-alc-01.txt"; charset=us-ascii
Content-Description: draft-ietf-rmt-pi-alc-01.txt
Content-Disposition: attachment; filename="draft-ietf-rmt-pi-alc-01.txt"
RMT Working Group M.Luby/Digital Fountain
Internet Engineering Task Force J.Gemmell/Microsoft
INTERNET-DRAFT L.Vicisano/Cisco
draft-ietf-rmt-pi-alc-01.txt L.Rizzo/U. of Pisa
13 July 2000 J. Crowcroft/UCL
B. Lueckenhoff/Cadence
Expires 13 January 2000
Asynchronous Layered Coding
A massively scalable reliable multicast protocol
<draft-ietf-rmt-pi-alc-01.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are valid for a maximum of six months and may be
updated, replaced, or obsoleted by other documents at any time. It
is inappropriate to use Internet-Drafts as reference material or to
cite them other than as a "work in progress".
To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html.
Abstract
This document describes Asynchronous Layered Coding, a massively
scalable reliable multicast protocol, hereafter referred to as ALC.
ALC can be used to reliably deliver content to multiple receivers. The
content can be any well-defined object. Examples include any type of
file such as a group of pictures in an MPEG stream, a MP3 music file, a
JPEG image, and a collection of files that are archived into one file.
In addition, the delivery service model that can be provided with ALC is
fairly flexible, e.g., an on demand service model and a push service
model. A session is initiated by a single sender to transmit packets
that contain data about a particular object. Receivers may join or
Draft RMT PI, Asynchronous Layered Coding 13 July 2000
leave an existing session in an asynchronous manner independent of other
receivers.
Reliability is achieved via FEC coding only, i.e. all packets in a
session contain FEC coded information about the object to be delivered.
The crucial point is that there is no request for retransmission of
individual packets from receivers that miss packets in order to assure
reliable reception of the object, and the packets and their rate of
transmission out of the sender are independent of the number and the
individual reception experiences of the receivers. In some delivery
service models, e.g, a push delivery model, it is appropriate that
receivers send messages to the sender (either in or out of band) to
either continue the session if receivers have not yet received enough
packets or to terminate the session when receivers have received enough
packets. To be able to track usage of the system, receivers can also
send messages out of band to the sender that contain statistics on their
reception experience. ALC, however, does not require nor specify such
messages, with the aim of avoiding unnecessary limitation to the
scalability of the protocol.
Congestion control is achieved by sending packets in the session to
several ALC groups. Receivers increase and decrease their session
reception rate in reaction to network conditions by joining and leaving
ALC groups associated with the session in a manner that is network
friendly, similar to how TCP is network friendly. The congestion
control algorithm is receiver driven, i.e., signals are placed into
packets by the sender to indicate to receivers how to react to changing
network conditions, and receivers adjust their reception rate in
response to these signals and packet loss. Thus, each receiver
experiences a reception rate appropriate to that receiver independent of
other receivers.
ALC has the following properties:
o To each receiver, it appears as if though there is a dedicated unicast
session from the sender to the receiver, where the reception rate
adjusts to congestion along the path from sender to receiver in a
manner similar to TCP.
o To the sender, there is no difference in load or outgoing rate if one
receiver is joined to the session or a million (or any number of)
receivers are joined to the session, independent of when the receivers
join and leave.
Luby, Gemmell, Vicisano, Rizzo, Crowcroft, Lueckenhoff [Page 2]
Draft RMT PI, Asynchronous Layered Coding 13 July 2000
o On each link in the network, the packet traffic from the session and
its reaction to competing traffic is the same whether there is one
receiver or a million receivers beyond the link, and this reaction is
similar to how a TCP session reacts.
Thus, ALC provides a massively scalable content delivery system that
is network friendly.
1. Introduction
This document describes a massively scalable reliable protocol for
content delivery using IP multicast. IP multicast, while powerful and
efficient, is a "best effort" service [DEE88]. It does not guarantee
packet reception, or reception order. Many reliable multicast protocols
have been built on top of multicast. However, scalability is not a
design goal for many reliable multicast protocols. Even among those
reliable multicast protocols that target improved scalability, many
still fall far short of the scalability of IP multicast itself. Others,
while as scalable as IP multicast, require changes to routers or other
infrastructure, making their deployment unlikely in the near term.
One of the key difficulties in scaling reliable multicast is dealing
with the amount of data that flows from receivers back to the sender.
Protocols that avoid any such feedback can be massively scalable. The
data carousel [AFZ95] approach is a simple protocol that avoids any
feedback from the receivers. The sender simply loops repeatedly through
the symbols of the object to be delivered, places the symbols into
packets, and transmits the packets (a symbol is a small fixed size
portion of data). If the receiver misses any symbol, it simply waits for
the symbol to be sent again in the next loop. However, a receiver has to
wait for the full loop to repeat to receive a symbol that is missed if
the packet carrying it is lost. Forward error correction (FEC) coding
can be used to improve the data carousel approach [RIZ97a], [GEM99],
[VIC98A], [BYE98], [LUB00]. Using a FEC codec, i.e., a FEC encoder at
the sender to generate packets from an object and the corresponding FEC
decoder at the receivers to process packets in order to recover the
object, can dramatically reduce the number of packets a given receiver
needs to receive in order to recover the object. ALC relies exclusively
on a FEC codec to achieve reliability, thereby avoiding non-scalable
reliability mechanisms that rely on receiver feedback to the sender to
trigger retransmission of missing packets. A description of FEC codes
with packet content specification and considerations for their use in
reliable IP multicast can be found in [FEC00]. This document utilizes
the terminology and concepts introduced in it.
Luby, Gemmell, Vicisano, Rizzo, Crowcroft, Lueckenhoff [Page 3]
Draft RMT PI, Asynchronous Layered Coding 13 July 2000
An attractive feature of ALC is the ability for different receivers to
join and leave a session and ALC groups within the session
asynchronously without adversely affecting the reception experience of
other receivers and without affecting the scalability of the protocol.
ALC congestion control is achieved by sending packets associated with a
given session to several ALC groups and individual receivers only join
to a subset of these groups. The set of ALC groups a receiver joins is
determined by the receiver based on signals placed into packets by the
sender and by loss measured by the receiver along the path from the
sender to that receiver. Receivers that can receive packets at a rate
higher than their current rate are allowed to increase their reception
rate, and receivers that are receiving packets at a higher rate than
they have the capacity for (as evidenced by packet loss) MUST reduce
their rate. A detailed description of this type of multi-rate
congestion control can be found in [MRCC00].
Another possibility to implement congestion control is through a router-
assisted scheme where the selection of which ALC groups to forward is
performed by routers. Having routers select which groups to forward
allows finer grain congestion control and a faster reaction to network
congestion. A limitation of this approach is that it potentially
requires changes to the hardware router infrastructure. See [CAI99,
LUB99] for a preliminary design description. We do not discuss this
approach further in this document.
One of the attractions of ALC is that it is multicast routing
independent and that it does not require multicast reverse connectivity,
i.e. ALC receivers do not send multicast traffic. In particular, ALC
works with the original multicast model introduced in [DEE88], which we
call Internet Standard Multicast (ISM) in this document, and with the
Source Specific Multicast (SSM) model that is based on [HOL99]. The
definition of an ALC group used throughout this document is slightly
different with ISM and with SSM. When using ISM, packets of an ALC
group are sent to a multicast group address G. When using SSM, packets
of an ALC group are sent to a channel address (S,G), where S is the IP
address of the sender and G is a multicast group address.
SSM is more attractive to ALC than ISM for a few reasons. First, ALC
may use more than one ALC group in a session, and ALC may be used to
deliver a large number of objects in different sessions over time that
use different sets of ALC groups for the transmission. With ISM, the
multicast group address G that corresponds to an ALC group must be
allocated so that it is unique across the Internet. With SSM, the
multicast group address G can be allocated locally by the sender with
Luby, Gemmell, Vicisano, Rizzo, Crowcroft, Lueckenhoff [Page 4]
Draft RMT PI, Asynchronous Layered Coding 13 July 2000
the only requirement that it is unique to the sender, because it is the
(S,G) channel that corresponds to the ALC group that a receiver joins.
Second, ALC supports an unlimited number of dynamically changing
receivers. Changes in the multicast tree topology with SSM are light
weight operations (a new branch from the receiver towards S grows when a
receiver joins, and the branch is deleted when the receiver leaves), and
with ISM changes can be heavier weight (involving transitions from a
(*,G)-tree rooted at an RP to the tree rooted at S). Third, ALC is
scalable to an unlimited number of receivers that may span the global
Internet. Thus, the light weight mechanisms that SSM uses to cross ISP
boundaries (standard BGP+ routing tables) is distinct advantage over the
heavier weight mechanisms used by ISM (the MSDP and BGMP protocols, both
of which are not needed by SSM). Finally, a receiver joins an ALC group
by joining a channel (S,G) with SSM, and thus the receiver will only
receive packets sent from the sender S. With ISM, the receiver joins an
ALC group by joining a multicast group G, and all packets sent to G,
regardless of their origin sender, will be received by the receiver.
Thus, SSM has compelling security advantages over ISM for prevention of
denial of service attacks.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [R2119].
2. Related Documents
This specification is based on the "Forward Error Correction" building
block specified in [FEC00] and on the "Multi-Rate Congestion Control"
building block ([MRCC00], yet to be specified).
ALC can use any FEC coder that complies to the specifications in [FEC00]
and that is either specified in [FEC00] or in one of its companion
documents. ALC refers to specifications and general description provided
in [FEC00]. ALC uses FEC without feedback from receivers, in the
'proactive' form described in [FEC00]. The present document complements
[FEC00] by providing an actual instantiation header-fields that are
described in abstract terms in [FEC00].
ALC does not specify congestion control directly, but relies in the
specification given in [MRCC00]. This specification of ALC reserves
opaque header fields that can be used by [MRCC00] to transport
information related to congestion control. Implementors of ALC MUST also
implement [MRCC00] or an equivalent that provide congestion control in
accordance to RFC2357 ([MRBP98]).
Luby, Gemmell, Vicisano, Rizzo, Crowcroft, Lueckenhoff [Page 5]
Draft RMT PI, Asynchronous Layered Coding 13 July 2000
3. Applicability
ALC is intended for reliable delivery of objects. ALC is most
applicable for delivery of objects of substantial length, i.e., objects
that range in length from hundreds of kilobytes to many gigabytes. ALC
is directly applicable to all multicast enabled networks, including
asymmetric networks, wireless networks, and satellite networks. Thus,
the inherent raw scalability of ALC is unlimited. However, when other
specific applications are built on top of ALC, then these applications
by their very nature may limit scalability. For example, if an
application requires receivers to request out of band information in
order to join a session, or an application allows receivers to send
requests back to the sender in order to extend an ongoing session, then
the scalability of the application is limited by the ability to send,
receive, and process this additional data.
The particular FEC coder and congestion control protocols used by ALC to
provide a complete protocol have an impact on the applicability of ALC.
For example, some FEC coders are inherently limited in the size of the
object they can encode, and for objects larger than this size the
reception overhead on the receivers can grow substantially. As another
example, some networks are not amenable to some congestion control
protocols that could be used with ALC. In particular, for a satellite
or wireless network, there may be no mechanism for receivers to
effectively reduce their reception rate since there may be a fixed
transmission rate allocated to the session.
4. General Architecture
An object transmission session comprises all packets sent to ALC groups
from a single sender that pertain to the transmission of a particular
object that could potentially be received by a receiver to recover the
object. For example, packets pertaining to a particular object could be
transmitted from a sender to four ALC groups at different rates. A
receiver may join and receive packets from subsets of these four groups
concurrently until it has enough packets in total to recover the object.
ALC allows for the more general possibility that several senders are
each concurrently transmitting packets to a session for the same object.
In this case, a receiver may concurrently join several of these sessions
in order to receive the object. Since the senders for these sessions
may be located in varying parts of the network, the receiver must
perform congestion control on each session independently, although the
receiver can take advantage of the aggregate set of packets that arrive
Luby, Gemmell, Vicisano, Rizzo, Crowcroft, Lueckenhoff [Page 6]
Draft RMT PI, Asynchronous Layered Coding 13 July 2000
through all sessions to reconstruct an object. For example, there could
be four senders, each using three ALC groups for a session pertaining to
the same object. A receiver could join all four sessions and collect
enough packets to reconstruct the object, but the receiver must perform
congestion control independently for each of the four sessions. This
document does not specify this mode of operation, assuming that it can
be implemented by multiple concurrent ALC sessions. Note however that
additional coordination among senders is recommended in order to achieve
good reception overhead (see [FEC00]).
The receivers need to obtain an object transmission session description
before starting the download of an object. The session description must
include the relevant session parameters needed by a receiver to enact a
download of an object from the senders participating in the session.
The object transmission session description is determined and agreed
upon by the senders and communicated to the receivers out of band, or,
in some cases, included or partially included in the header of each
packet. The session description could include the object name, the
object length, the packet format and length, the FEC codec type, the
sender IP address, the multicast address(es) of the multicast groups,
their port number(s), and transmission rates. The session description
could be in a form such as SDP [HAN98]. We assume that there exists an
out of band mechanism for receivers to obtain the session description.
The session description might be carried in a session announcement
protocol such as SAP [HAN96], located on a Web page with scheduling
information, or conveyed via E-mail or other out of band methods.
Discussion of session description format, and distribution of session
descriptions is beyond the scope of this document.
An FEC encoder is used to generate encoding symbols that are placed in
the payload of ALC packets. A description of FEC codecs can be found in
[FEC00], and the current document relies upon and uses the terminology
introduced in it. The FEC coding information is information that needs
to be passed to a receiver in order to decode objects. FEC coding
information includes the FEC codec type, the source block length, the
symbol length, the object length, the encoding block number, the
encoding symbol ID, and an encoding flag indicating whether the encoding
symbol is a source symbol or a redundant symbol for block codes. The
FEC protocol ID specifies the FEC codec type and the way it is to be
used for the transmission (see delivery service models below). The
object length, source block length and the symbol length are part of FEC
object transmission information. The encoding block number (if used)
and the encoding symbol ID that identify the encoding symbol in the
payload of an ALC packet constitute the FEC payload ID.
Luby, Gemmell, Vicisano, Rizzo, Crowcroft, Lueckenhoff [Page 7]
Draft RMT PI, Asynchronous Layered Coding 13 July 2000
Congestion control information must be included in the ALC packet
header. The content of this information depends on the type of
congestion control used, and [MRCC00] or an equivalent must be used. The
type of congestion control to use is also encoded in the ALC header.
Some specific congestion control algorithm(s) are defined in [MRCC00].
All ALC packets pertaining to a particular object transmission session
MUST have the same format. An ALC packet consists of an ALC header and
a payload. Together with other information, the ALC header MUST contain
congestion control information, an FEC protocol ID, and an FEC payload
ID. Receivers use congestion control information to coordinate the rate
at which they receive packets and to measure congestion as indicated by
packet loss in order to determine this rate.
Other OPTIONAL information that an ALC header may contain is an object
transmission label, FEC session information, FEC object transmission
information, and authentication information. The object transmission
label can be used by receivers to verify that received packets are
associated with a particular object transmission session. Therefore,
object transmission labels for sessions pertaining to different objects
should be different. As an example, the object transmission label may
be the MD5 hash of the object name, object length and FEC object
transmission information described below. As another example, the
object transmission label may be the MD5 hash of the object itself.
The ALC packet format described in this document is intended to be used
in conjunction to the UDP transport protocol [POST80]. Future version
of this document or companion documents MAY specify a different
encapsulation for ALC.
5. Minimizing reception overhead
The primary purpose of using FEC codes is to ensure that minimal number
of packets need be received in order for a receiver to reconstruct an
object. Reception overhead is used to measure this. Reception
overhead is the aggregate length of packets needed to recover the object
beyond the object length, measured as a percentage of the object length.
For example, if it takes 15 MB of packets in order to recover a 10 MB
object, then the reception overhead is (15-10)/10 times 100, or 50%.
The minimal reception overhead possible is 0%.
Under ideal conditions, reception overhead is 0% using even the simplest
of FEC codes. For example, a simple carousel achieves 0% reception
overhead when transmission is over a network with no packet loss using a
Luby, Gemmell, Vicisano, Rizzo, Crowcroft, Lueckenhoff [Page 8]
Draft RMT PI, Asynchronous Layered Coding 13 July 2000
single ALC group with receivers that join and stay attached to the group
until they have enough encoding symbols to recover the object. However,
under more realistic conditions when transmission uses multiple ALC
groups, when there is packet loss, and when receivers join and leave
groups during the download process, more sophisticated FEC codes are
clearly useful to minimize reception overhead.
There are three primary contributors to reception overhead, and these
guide the design of how to use FEC codes for ALC. These contributors
are: (1) redundant encoding symbol reception due to division of the
object into blocks; (2) duplicate encoding symbol reception due to fixed
length FEC codes; (3) inherent reception overhead of the FEC code. ALC
based on small block codes is prone to (1) and (2), ALC based on large
block codes is most prone to (2) and (3), and ALC based on large
expandable codes is most prone to (3).
5.1. Division into blocks
One concern is the order of encoding symbol transmission from different
blocks when the object is partitioned into blocks. Suppose the object
is partitioned into m blocks of k source symbols each, and any k
encoding symbols from a block is sufficient to recover the k source
symbols from that block. Ideally, reception of any km encoding symbols
is sufficient to recover the entire object. Actually, reception of k
encoding symbols for each of the m blocks is necessary to recover the
entire object. Thus, it is important to schedule the transmission of
symbols so that in the face of most patterns of packet loss receivers
can recover the object from reception of as close to km encoding symbols
as possible. A RECOMMENDED ordering is to interleave encoding symbols
from different blocks. This interleaving can be described in terms of
rounds, where in a round m encoding symbols are transmitted, one from
each block. A particular sending order in each round is not specified by
ALC. However, it is RECOMMENDED that some randomization be performed to
eliminate correlation with periodic losses. For example, sending could
be performed as follows: In round i, randomly choose a permutation p(i)
of the m blocks, and then send the i-th encoding symbol from each of the
m blocks in the order determined by p(i). In the following example, the
object is split into 3 blocks of 4 source symbols each:
Luby, Gemmell, Vicisano, Rizzo, Crowcroft, Lueckenhoff [Page 9]
Draft RMT PI, Asynchronous Layered Coding 13 July 2000
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
+ s00 + s01 + s02 + s03 + s10 + s11 + s12 + s13 + s20 + s21 + s22 + s23 +
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
Source block 0 | Source block 1 | Source block 2
Then the first 4 permutations chosen are p(0) = (1,0,2), p(1) =
(0,2,1), p(2) = (2,0,1), p(3) = (0,1,2), and the send order for the
first 4 rounds is:
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
+ e10 + e00 + e20 + e01 + e21 + e11 + e22 + e02 + e12 + e03 + e13 + e23 +
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
Encoding symbol send order
Object division into blocks, and thus application of this scheme, is
applicable to all the codes, as the value of k is ultimately limited
for all the codes. For example, small block codes use small values of
k because of computational limits, and large block codes and large
expandable codes use much larger yet still limited values of k because of
memory and packet length limitations. This interleaving scheme minimizes the
induced reception overhead due to division into blocks for any
predefined loss pattern for a given value of k. However, it is likely
that the induced reception overhead will be larger and more variable
when k is small and when losses are moderate or more. For example,
when k = 20 and m = 50, the induced reception overhead with respect to
a 10% random packet loss is on average 18%, and will reach over 40%
for some receiver among 1,000 receivers. See [BYE98] for a more
detailed analysis of this. Thus, the reception overhead will tend to
be smaller and less variable when using either large block codes or
large expandable codes than when using small block codes. For small
block codes and large block codes the limit on the number of encoding
symbols n for the codes will limit the number of distinct rounds to n.
For large expandable codes, since there is no limit to the number of
encoding symbols there can be an unlimited number of rounds.
A simple way to choose the permutation in each round is the following,
and this is RECOMMENDED when protecting against arbitrary packet loss
patterns. At each round, the permutation p(i) is determined by
selecting a first block randomly, and the rest of the ordering is the
consecutive blocks following this first block, modulo the number of
Luby, Gemmell, Vicisano, Rizzo, Crowcroft, Lueckenhoff [Page 10]
Draft RMT PI, Asynchronous Layered Coding 13 July 2000
blocks.
For example, if there are m blocks, and block j is selected as the
first, the permutation p(i) consists of block j through block m-1,
followed by block 0 through block j-1. For more detailed discussion,
see [VIC98B,GEM99].
5.2. Block FEC codes
For some FEC codes for a given object consisting of s source symbols
there is a limited supply t of encoding symbols that are produced. If
the number of encoding symbols to be sent exceeds t then some encoding
symbols need to be sent more than once. Thus, it is important to
schedule the order of sending encoding symbols in such a way as to avoid
as much as possible reception of the same encoding symbol more than once
by the same receiver. This applies to ALC based on block codes as these
codes produce a limited number of encoding symbols. However, this does
not apply to ALC based on large expandable codes, as these codes can
produce an essentially unlimited supply of encoding symbols.
5.2.1. A single group
In some simple scenarios, receivers will join a single ongoing ALC
group, collect enough encoding symbols to decode the object, and then
leave the object transmission session. In this situation, in order to
avoid as much as possible duplicate reception of packets by such
receivers, it is important to send the encoding symbols the second and
subsequent times in the same order that they were sent the first time.
Thus, for example, a receiver that joins the session towards the end of
the transmission of the encoding symbols for the first time can continue
receiving packets from the transmission of the encoding symbols for the
second time and be sure to receive distinct encoding symbols. However,
it is inevitable that the reception overhead due to reception of
duplicate encoding symbols can be large for receivers that join and
leave the transmission over intervals of time that span the transmission
of more than the total supply of encoding symbols. For example, a
receiver may join the session at the beginning of the first transmission
of encoding symbols and receive e0, e1, ... , e98, e99, leave the
session and then rejoin the session again at the beginning of the second
transmission of encoding symbols and receive again e0, e1, ... , e98,
e99, thus receiving 100 duplicate encoding symbols that provide no
benefit to recovering the object.
Luby, Gemmell, Vicisano, Rizzo, Crowcroft, Lueckenhoff [Page 11]
Draft RMT PI, Asynchronous Layered Coding 13 July 2000
+-----+-----+ +-----+-----+ +-----+-----+ +-----+-----+
+ e0 + e1 + ... + e98 + e99 + ... + e0 + e1 + ... + e98 + e99 +
+-----+-----+ +-----+-----+ +-----+-----+ +-----+-----+
first transmission | second transmission
5.2.2. Multiple groups
In more general scenarios, in order to recover an object, receivers will
join multiple ongoing ALC groups dynamically. These groups may emanate
from more than one server and may be running at different rates.
Furthermore, receivers may join a given group and rejoin the same group
an arbitrary amount of time later (for example, the next day) to
complete the recovery. Finally, for congestion control purposes,
receivers dynamically change the set of ALC groups they are receiving
from based on dynamically changing loss conditions.
How to schedule the encoding symbols from a block code among the various
ALC groups in order to minimize reception overhead under all of these
different conditions is a challenge. Let r = t/s be the ratio of the
number of encoding symbols to the number of source symbols. The larger
the value of r the easier it is to avoid receiver reception of duplicate
encoding symbols, and in particular as r goes to infinity then reception
overhead due to this problem can go to zero. There are ordering schemes
that keep reception overhead minimal for small value of r under certain
restrictions. For example, in the previous subsection a scheme is
described that minimizes reception overhead under the restriction that
there is only one group and the receiver is able to complete recovery
within a time period that encompasses the transmission of t encoding
symbols.
However, under general conditions the best and simplest scheme for
minimizing reception overhead for objects that aren't blocked is the
following. For each group, organize the sending of encoding symbols into
rounds. In each round, choose independently a random permutation of all
t encoding symbols and send the encoding symbols in this order. Using
this ordering, it is not hard to show that no matter in which order and
at what time a receiver may join and leave groups the induced reception
overhead due to reception of duplicate encoding symbols of a receiver is
at most on average r*ln(r/r-1)-1. Furthermore, there are examples of
receiver behavior that achieves these maximum averages. As examples,
when r is two then the induced reception overhead is at most 38.6%, when
r is five then the reception overhead is at most 11.5%, and when r is
ten then the reception overhead is at most 5.4%. Thus, to achieve a
Luby, Gemmell, Vicisano, Rizzo, Crowcroft, Lueckenhoff [Page 12]
Draft RMT PI, Asynchronous Layered Coding 13 July 2000
reasonable overhead the total length of the encoding must be
substantially longer than the length of the object.
5.3. Inherent overhead
A (n, k) linear block code has no inherent reception overhead, as any k
encoding symbols are sufficient to recover all k source symbols. On the
other hand, both the large block codes and large expandable codes
described in [FEC00] do have a small amount of inherent reception
overhead.
6. Delivery service models
ALC can support several different delivery service models. Some examples
are briefly enumerated here.
On demand delivery model. Receivers may join the ongoing object
transmission session at their discretion, obtain the necessary encoding
symbols to reproduce the object, and then leave the session. For an on
demand service model senders typically transmit for some given time
period selected to be long enough to allow all the intended receivers to
join the session and recover the object. The time period would typically
be much larger than the download time for the object to make it
convenient for receivers to enact the download at their discretion. For
example a popular software update might be sent using ALC for several
days, even though a receiver may be able to complete the download in one
hour total of connection time, perhaps spread over several intervals of
time.
Push service model. This is a variant of the on demand delivery model,
with the difference that the transmission is intended for a set of
loosely synchronized receivers. Receivers join the session at
approximatively the same time the sender start the transmission (one way
to to this is to have the sender send the required out of band
information about the session to the designated list of receivers, and
this triggers the receivers to join the session to start the download).
Then receivers provide feedback about the status of reception in order
to allow the sender to keep the session alive until the last receiver
has finished. This specification describes an OPTIONAL lightweight
scalable mechanism for receivers to provide in-band feedback in ALC.
Other out of band mechanisms can be used, including those that rely on
explicit knowledge of the session participants and demand that all of
them send explicit notification of the successful reception.
Luby, Gemmell, Vicisano, Rizzo, Crowcroft, Lueckenhoff [Page 13]
Draft RMT PI, Asynchronous Layered Coding 13 July 2000
Streaming service model. Typically, receivers join and remain joined to
a particular set of ALC groups to receive multiple related objects in
consecutive object transmission sessions. For a streaming service model
senders typically transmit a fixed number of encoding symbols for each
object. This number may depend on network conditions that are obtained
using out of band methods. For example, if network conditions are such
that at most 33% of the packets are lost over any 15 MB of transmitted
packets, then 15 MB of encoding symbols may be transmitted for a 10 MB
object to ensure that receivers are able to reassemble the object under
the worst loss conditions. A typical application is a streaming real-
time MPEG video, where each object consists of a segment of the stream.
For each object, the receiver obtains enough ALC packets to recover the
object and then discards all subsequent packets associated with the
object until packets start arriving for the next object.
There are many other delivery service models that ALC can be used for
that are not covered above. The description of the many potential
applications and the appropriate delivery service model is beyond the
scope of this document. With many of these delivery service models
substantial additional mechanisms beyond what is described in this
document will be needed to support the delivery service model, i.e. the
out of band mechanism for delivering object transmission session
information to the receivers. This document only attempts to describe
the minimal common scalable elements to these diverse applications using
ALC as the delivery mechanism.
7. Congestion Control
A congestion control algorithm for ALC is specified in a companion
document [MRCC00].
8. Packet Content
ALC defines two types of packets: a Data Packet and Request Packet. In
this specification of ALC both these packets are transmitted as UDP
payload [POST80]. Future versions of this specification or companion
documents may remove this limitation. Data packets are sent by the
sender(s) to a multicast IP destination address. Request packets are
sent by receivers to the unicast IP destination address of the sender
(one of them, if there is more than one) or to the unicast address of a
session-control node. ALC does not strictly require the presence of
Request packets, the only purpose of these is to implement the OPTIONAL
"transmission extension" mechanism.
Luby, Gemmell, Vicisano, Rizzo, Crowcroft, Lueckenhoff [Page 14]
Draft RMT PI, Asynchronous Layered Coding 13 July 2000
When present, the ALC payload immediately follows the ALC header. In
the ALC header, all integer fields are carried in "big-endian" or
"network order", that is, most significant byte (octet) first. Bits
designated as "padding" or "reserved" MUST by set to 0 by senders and
ignored by receivers. Unless otherwise noted, numeric constants are in
decimal (base 10).
8.1. Data-Packet content
The ALC data-packet header contains the following types of information
provided by the sender(s):
o Congestion Control Information (mandatory)
Used by receivers (or intermediate nodes) to implement congestion
control algorithms.
o FEC Information
This is the instantiation of the abstract fields defined in
[FEC00]. This class is further decomposable as follows:
o FEC Encoding Identifier (mandatory)
Identifies the type of FEC coding scheme being used.
o FEC Object Transmission Information (optional)
Identifies the parameters associated with the encoding of an
object through the FEC coding scheme in use.
o FEC Payload Identifier (mandatory)
Identifies the content of the data packet for the purpose of
decoding.
o FEC Encoding Flag (mandatory)
Identifies packets containing only source symbols
o Object Transmission Label (optional)
Used by receivers to de-multiplex different objects being
transmitted in a single session and possibly to associate them to
Luby, Gemmell, Vicisano, Rizzo, Crowcroft, Lueckenhoff [Page 15]
Draft RMT PI, Asynchronous Layered Coding 13 July 2000
their description provided out of band.
o Source Authentication Information (optional)
Used by receivers to authenticate the content of the packet.
o Object Transmission Status (optional)
Used by receivers to implement the OPTIONAL "transmission
extension" mechanism.
The actual packet format is depicted in Figure 1 below.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Congestion Control Information |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V | HDR_LEN |FEC Encoding ID| CCID|E| resvd |F|TLL|TIL|R|A|X|
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| FEC Payload ID (1-:-2 32-bit words) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Object Transmission Label (0,1,2 or 4 32-bit words) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC Object Transmission Information (0-:-3 32-bit words) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C|r| Residual Object Transmission Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Authentication Information (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 - ALC Data-packet header layout
The ALC data-packet header is made of a fixed part, 64 bits long,
followed by a variable part. The fixed part contains congestion
control information, general protocol settings and information
describing the variable part of the header. The variable part is
composed by one or more variable-length fields. The presence of each
of those field is determined by the description provided in the fixed
part of the header. The length of each field is either constant or
determined in the fixed part of the header or defined in the field
itself.
Luby, Gemmell, Vicisano, Rizzo, Crowcroft, Lueckenhoff [Page 16]
Draft RMT PI, Asynchronous Layered Coding 13 July 2000
Optionally an ALC data-packet header can contain additional
header-extension fields intended both for protocol extensions
and as a mechanism to extend the length of some of the fields already
present in the header. Header extensions fields are described in
a separate section.
The explanation each field in the packet header is the following.
Congestion Control Information (CCI): 32 bits
Used for Congestion Control purposes. This field is opaque for the
purpose of this specification. [MRCC00] defines its format and
usage according to the value of the CCID field.
ALC version number (V): 3 bits
The ALC version number for this specification is 0.
Non-fixed ALC header Length (HDR_LEN): 5 bits
Length of the non-fixed portion of the ALC header in units of
32-bit words, starting form the 3rd 32-bits word in the ALC header
up to the ALC payload (including header extensions, see below).
I.e. this is the total header length excluding the first two
32-bit words. This field can be used for direct access to the
beginning of the ALC payload.
FEC encoding ID (FEC_ENC_ID): 8 bits
Specifies the type of FEC encoding being used and, implicitly, the
specification of the decoder [FEC00]. FEC_ENC_ID also determines
the internal format of the FTI and FPI fields described below.
This field is the instantiation of the "FEC encoding ID" abstract
field defined in [FEC00].
Congestion Control ID (CCID): 3 bits
Specifies the congestion control algorithm being used and,
implicitly, the meaning of the CCI field. This field is the
instantiation of the "Congestion Control ID" field defined in
[MRCC00].
FEC Encoding flag (E): 1 bit
Luby, Gemmell, Vicisano, Rizzo, Crowcroft, Lueckenhoff [Page 17]
Draft RMT PI, Asynchronous Layered Coding 13 July 2000
E = 1 indicates that the packet payload contains only source
symbols. E = 0 indicates redundant symbols in the payload. The
meaning of this field is not defined for some values of
FEC_ENC_ID, when this happens E MUST be set to 0 by the sender.
This field is the instantiation of the "encoding flag" abstract
field defined in [FEC00].
reserved: 4 bits
FEC payload-ID length (F): 1 bit
Length of FEC payload ID field (FPI). F = 0 indicates the FPI
field is 32-bits long. F = 1 indicates the FPI field is 64-bits
in length.
Object Transmission Label length (TLL): 2 bits
Length of object transmission label field (OTL). An TLL value of 0
means "OTL field not present"; TLL values of 1, 2 and 3 mean 32,
64, 128 bits OTL-field length respectively.
FEC-object Transmission-Information length (TIL): 2 bit
Length of FEC object transmission information field (FTI) in units
of 32-bit words. TIL = y indicates the FTI field is y words in
length. TIL = 0 means that the FTI field is not present.
Residual Object Transmission Time flag (R): 1 bit
R = 1 indicates that the field Residual Object Transmission Time
(ROT) is present. R = 0 indicates "no ROT field".
Source Authentication flag (A): 1 bit
A = 1 indicates that the Source Authentication header field (SAI)
is present. A = 0 indicates "no SAI field".
Header-extension fields flag (X): 1 bit
X = 1 indicates that additional fields, beside the ones specified
in this section, are present in the ALC header. X = 0 indicates no
additional header fields is present. See the "Header Extension"
section for the definition of additional header field.
Luby, Gemmell, Vicisano, Rizzo, Crowcroft, Lueckenhoff [Page 18]
Draft RMT PI, Asynchronous Layered Coding 13 July 2000
FEC Payload ID (FPI): 1 -:- 2 x 32 bits
The FEC Payload ID field identifies the content of the ALC payload
for the purpose of decoding. For example this may be the the ID of
the FEC symbol carried in the packet and its encoding block
number, if the object is partitioned into blocks. The exact format
and interpretation of the FPI field is dependent on the value of
FEC_ENC_ID as specified in [FEC00]. The FPI field is the
instantiation of the "FEC Payload ID" abstract field defined in
[FEC00]. The length of the FEC payload ID field is determined by
the F field.
Object Transmission Label (OTL): 0,1,2 or 4 x 32 bits
Its content is opaque to receivers and is used by them to de-
multiplex different objects being transmitted within a single
session and possibly to associate the objects to their description
provided out of band. In the scope of a session, each label MUST
be uniquely associated to a single object, the opposite in NOT
REQUIRED. The length of the Object transmission label field is
determined by the TLL field.
FEC object transmission information (FTI): 0 -:- 3 x 32 bits
This field defines the parameters of the FEC coding scheme and of
its application to the object being encoded. For example this
could include the length of the object and the source block
length, in the case of block-codes. The format of this field is
dependent on the value of FEC_ENC_ID, as specified in [FEC00]. The
FTI field is the instantiation of the "FEC Transmission
Information" abstract field specified in [FEC00]. The length of
the FTI field is determined by the TIL field. When the FTI field
is not present in the ALC header, this information MUST be
communicated out of band.
Continuation Request flag (C): 1 bit
reserved: 1 bit
Residual Object Transmission Time (ROT): 30 bits
These three fields encode the "Object Transmission Status"
information, used to implement the OPTIONAL in-band 'transmission-
extension' mechanism. Their presence is controlled by the field R:
R = 1 means that they are present. The field ROT Represents the
time left until the end of the transmission of the Object,
expressed in ms (milliseconds). The field C indicates whether
Luby, Gemmell, Vicisano, Rizzo, Crowcroft, Lueckenhoff [Page 19]
Draft RMT PI, Asynchronous Layered Coding 13 July 2000
receivers are allowed to send continuation request using the
Request Packet: C = 1 means that they are allowed.
Source authentication information (SAI): variable length.
This field is used to authenticate the content of the packet, it
is a self-descriptive, variable-length field. Its format is
defined below. The SAI field is only present if A = 1.
Although the ALC packet headers may have different formats, All ALC
packets pertaining to the same session MUST have the same header format,
i.e. all optional field MUST be either present or not-present in all
packets and all variable-length header MUST keep a constant length. Also
the FEC encoding type MUST NOT vary within the session, which implies
that FEC_ENC_ID MUST NOT vary either.
The encoding parameters carried in the FTI field MUST be the same within
the same object, but MAY vary across different sessions for different
objects, even if the sessions occur sequentially in time using the same
set of ALC groups for each session.
8.1.1. Source Authentication Information Field
The format of the SAI field is depicted below.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SAL | SAT | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
. .
. Actual Source Authentication Information (variable length) .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The explanation of each sub-field is the following.
Source Authentication Information length (SAL): 8 bits
The length of the whole SAI filed included the SAL sub-field,
expressed in multiples of 32-bit words.
Luby, Gemmell, Vicisano, Rizzo, Crowcroft, Lueckenhoff [Page 20]
Draft RMT PI, Asynchronous Layered Coding 13 July 2000
Source Authentication Information type (SAT): 8 bits
The type of the authentication algorithm being used. This field
also determines the structure of the ASA sub-field.
Actual Source Authentication Information (ASA): variable length
Used by receivers to authenticate the content of the packet. Its
internal structure is implicitly defined by the value of the SAT
sub-field.
Values of the SAT sub-field, their association to an authentication
scheme and the format of the ASA sub-field are specified in a separate
document.
8.2. Request-Packet content
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V | HDR_LEN | reserved |TLL|resvd|A|X|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Object Transmission Label (0,1,2 or 4 32-bit words) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|res| Requested Object Transmission Extension |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Authentication Information (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ALC Request header layout
ALC version number (V): 3 bits
The ALC version number for this specification is 0.
Non-fixed ALC header Length (HDR_LEN): 5 bits
Length of the non-fixed portion of the ALC header in units of
32-bit words, starting form the 3rd 32-bits word in the ALC header
up to the end of the request packet. I.e. this is the total
length length of the request packet excluding the first two 32-bit
Luby, Gemmell, Vicisano, Rizzo, Crowcroft, Lueckenhoff [Page 21]
Draft RMT PI, Asynchronous Layered Coding 13 July 2000
words (request packets do not contain payload).
reserved: 17 bits
Object Transmission Label length (TLL): 2 bits
Length of object transmission label field (OTL). An TLL value of 0
means "OTL field not present"; TLL values of 1, 2 and 3 mean 32,
64, 128 bits OTL-field length respectively.
reserved: 3 bits
Receiver Authentication flag (A): 1 bit
A = 1 indicates that the Receiver Authentication header field
(RAI) is present. A = 0 indicates "no RAI field".
Additional header-fields flag (X): 1 bit
X = 1 indicates that additional fields, beside the ones specified
in this section, are present in the ALC header. X = 0 indicates no
additional header fields is present. See the "Header Extension"
section for the definition of additional header field.
Object Transmission Label (OTL): 0,1,2 or 4 x 32 bits
This is the Object Transmission Label of the object for which the
extension is requested. This field is the copy of the analogous
field present in data packets. The OTL field is omitted from
Request packets when the analogous field is not present in Data
packets.
reserved: 2 bit
Requested Object Transmission Extension (ROE): 30 bits
Represents the requested time until the end of the transmission of
the Object, expressed in ms (milliseconds). This value is computed
as the Residual Object transmission Time (ROE) plus the extension
needed by the receiver.
Receiver authentication information (RAI): variable length.
This is an optional field used to authenticate the receiver that
sends the request. Its structure is identical to the SAI field
Luby, Gemmell, Vicisano, Rizzo, Crowcroft, Lueckenhoff [Page 22]
Draft RMT PI, Asynchronous Layered Coding 13 July 2000
structure. Actual authentication mechanisms may be defined in a
companion document, similarly to what specified for the SAI field.
The RAI field is only present if A = 1.
The Request-packet header can be extended using the same mechanism used
for data packet headers (see section "Header-Extension Fields").
8.3. Header-Extension Fields
To allow for unanticipated or rarely used additional header fields and
to extend the size of some of the predefined fields, the ALC header
contains an additional header fields flag "X". If "X" is set to 0 then
no additional header fields are included within the ALC header beyond
the predefined fields. When additional headers beyond the predefined
fields are used, the value of "X" within the ALC header MUST be set to
1.
Header-extension fields have the standard format depicted below.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| HEL | HET | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
. .
. Header Extension Content .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5 - format of additional headers
The explanation of each sub-field is the following.
Last Header Extension (L): 1 bit
MUST be set to 1 in the last Header Extension field present in a
packet header, MUST be set to 0 in all the others.
Header Extension length (HEL): 7 bits
Luby, Gemmell, Vicisano, Rizzo, Crowcroft, Lueckenhoff [Page 23]
Draft RMT PI, Asynchronous Layered Coding 13 July 2000
The length of the whole Header Extension field expressed in
multiples of 32-bit words.
Header Extension type (HET): 8 bits
The type of the header extension. This document defines a number
of possible types. Additional types may be defined in future
version of this specification.
Header Extension Content (HEC): variable length
The content of the Header Extension. The format of this sub-field
depends on the header extension type.
The originator of a packet with header extensions SHOULD not leave
additional space between the end of the last Header Extension and the
beginning of the ALC payload. The recipient of a packet MUST ignore any
data present between the end of the last header extension field and the
beginning of the ALC payload.
The following header extension types are defined:
0 Reserved
EXT_CCI = 1 Congestion Control Information extension. This extension
field extends the CCI field present in the fixed part of
the header. It is used when the congestion control
information does not fit in the 32 bits CCI field.
EXT_FPI = 2 FEC Payload ID extension. This extension field extends
the FPI field of the fixed header. It is used when the FEC
payload ID information does not fit in 64 bits (maximum
length of FPI).
EXT_OTL = 3 Object Transmission Label extension. This extension field
extends the OTL field of the fixed header. It is used when
the object transmission label does not fit in 128 bits
(maximum length of OTL).
EXT_FTI = 4 FEC object transmission information extension. This
extension field extends the FTI field of the fixed header.
It is used when the FEC object transmission information
does not fit in 96 bits (maximum length of FTI).
Luby, Gemmell, Vicisano, Rizzo, Crowcroft, Lueckenhoff [Page 24]
Draft RMT PI, Asynchronous Layered Coding 13 July 2000
9. Procedures
9.1. Sender Operation
Within a ALC session, An ALC sender transmits a sequence of packets
containing encoding symbols (either source symbols and/or redundant
symbols) addressed to one or more multicast groups which together
constitute a session. Transmission rates may be different in different
groups. This document does not specify the policy used to place symbols
into packets, nor the order in which packets are transmitted, nor the
scheduling of packets in multiple groups. Although these issues affect
the efficiency of the protocol, they do not affect is the correctness
nor the inter-operability between senders and receivers. To address
these issues, ALC implementors SHOULD follows the guidelines provided in
the introductory sections of this document.
If multiple senders are transmitting data about the same object in
different sessions, congestion control must be performed independently
on each session, although a receiver may benefit by increasing its rate
and reliability of reception by participating in more than one session
for the same object concurrently. Multiple ALC sessions may transport
multiple objects using the same set of multicast groups, either
transmitted at different times or intermixed.
Typically, the sender(s) continue to send encoding symbols in a session
until the transmission is complete. The transmission may be considered
complete when some time has expired, a certain number of encoding
symbols have been sent, or some out of band signal (from a higher level
protocol, perhaps) has indicated completion by a sufficient number of
receivers. Feedback through ALC Request packets MAY also be used to
determine the end of the session.
All encoding symbols in an ALC session MUST be the same size. The
sender(s) may determine the symbol size arbitrarily, but must coordinate
or use a default symbol size to ensure that all encoding symbols are of
equal length. Larger encoding symbols sizes are generally desirable for
FEC decoding efficiency reason. ALC does not require that each data
packet contains a single symbol, however we believe that this is by far
the most common case, hence in the following we will assume it. An
additional reason to use large symbol sizes, and hence large packet
sizes is to reduce the overhead apported by the combination of IP + UDP
+ ALC headers. On the other hand, if the packet size is larger than the
network's maximum transmission unit (MTU), packets would be fragmented,
introducing inefficiency in case of network packet loss. It should also
Luby, Gemmell, Vicisano, Rizzo, Crowcroft, Lueckenhoff [Page 25]
Draft RMT PI, Asynchronous Layered Coding 13 July 2000
be considered that the decoding of large object may require the use of
secondary storage, for which symbol sizes of 512 bytes or multiples of
it are appropriate. For all the above reasons we RECOMMEND to use an
ALC payload size of either 512 or 1024 bytes.
An ALC sender MUST take part to the implementation of a congestion
control strategy in accordance to RFC2357 [MRBP98]. [MRCC00] specifies
the details of this.
Together with the encoding symbols, an ALC sender MUST provide
additional information regarding the symbols being transmitted, the
objects provided and the session. The sender MAY also provide additional
optional information. Part of this information must be provided within
ALC, using the above specified packet headers, part must be provided out
of band and part may be provided either out of band or in the ALC
headers.
An ALC sender MUST provide:
Congestion Control Information, consisting on:
Identification of the congestion control algorithm being used.
This must be provided before or with the start of the session.
The sender MUST use the ALC header field CCID for this
purpose. It may additionally use out of band mechanisms.
Parameter of the Congestion control algorithm (e.g. rates of
different layers).
This MUST be provided either in the ALC header (part of the
CCI field) or out of band, as defined in [MRCC00] for the
particular congestion control algorithm being used.
Per-packet congestion control information (e.g. sequence numbers
to detect packet loss).
The CCI field of the data-packet header MUST be used for this
purpose. [MRCC00] defines the content and encoding of this
information.
FEC information
FEC encoding Identifier
Luby, Gemmell, Vicisano, Rizzo, Crowcroft, Lueckenhoff [Page 26]
Draft RMT PI, Asynchronous Layered Coding 13 July 2000
This must be provided in the FEC_ENC_ID data-header field.
FEC Object Transmission Information
It MAY be provided in the FTI data-header fields ([FEC00]
defines its format). If the FTI field is not present in the
data-packet header, the FEC Object Transmission Information
MUST be provided out of band for each object prior the start
of the object transmission. The content of this is defined by
[FEC00] for the FEC_ENC_ID being used.
FEC Payload Identifier
This MUST be provided for each symbol transmitted, using the
FPI data-header field. The format of FPI is defined in [FEC00]
for the particular FEC_ENC_ID being used.
FEC Encoding flag
This is the F flag in the data-packet header. It MUST be set
to 1 if the packet contains only source symbols.
A sender MUST NOT change the FEC encoder or the congestion control
algorithm within a session.
An ALC sender MAY also provide:
Object Transmission Label
Object Transmission Label may be provided either out of band or
using the OTL data-header field. If a session is used to transmit
multiple objects, than the relative transmission labels MUST be
provided in the data-header to enable receivers to demultiplex
packets belonging to different objects.
Source Authentication Information
This has the purpose of authenticating the packet content and is
contained in the SAI data-header field.
Object Transmission Status
This is contained in the ROT data-header field. If the sender(s)
provide this information, it can also be required to handle
Luby, Gemmell, Vicisano, Rizzo, Crowcroft, Lueckenhoff [Page 27]
Draft RMT PI, Asynchronous Layered Coding 13 July 2000
Request Packets, depending on the value of the C flag. The action
that the sender(s) must perform in this case are specified in the
"Session Extension" section below.
9.2. Receiver Operation
Receivers can operate differently depending on the delivery service
model. For example, for an on demand service model receivers may join a
session, obtain the necessary encoding symbols to reproduce the object,
and then leave the session. As another example, for a push service model
a receiver may be tuned in to a continuous session announcement
multicast group or channel to determine when objects of interest are
scheduled for transmission. Then, at the appropriate time the receiver
automatically joins the session to download objects of interest. As
another example, for a streaming service model a receiver may be
continuously joined to a set of multicast groups to download all objects
in sequential session all using the same set of ALC groups.
To be able to participate to a session, receivers MUST first obtain the
multicast group(s) and UDP port number(s) used for the session. This
information is available through some out of band protocol. In certain
cases (e.g. when multicast routing protocols inspired to [HOL99] are
used) receivers MUST also obtain the IP address of the sender(s).
At the moment of joining the session, receivers MUST either
o have already identified the congestion control algorithm being used
through out of band means;
OR
o acquire this information through the CCID field of the header first
data packet received.
In either case receiver MUST implement the congestion control algorithm
specified. If a receiver is not able to implement the congestion control
algorithm used in the session, it MUST NOT join the session or MUST drop
it immediately, if the CCID is learned after having joined the session.
When the session is transmitted on multiple multicast groups receivers
MUST join it by subscribing to the first group only, unless they have
already learned the type of congestion control algorithm through out of
band means. Once they know the type of congestion control in use, they
are allowed to join other groups in accordance to the congestion control
Luby, Gemmell, Vicisano, Rizzo, Crowcroft, Lueckenhoff [Page 28]
Draft RMT PI, Asynchronous Layered Coding 13 July 2000
algorithm itself. This rule has the purpose of preventing receivers from
starting at high data rates, if the congestion control algorithm is
based on layered transmission on multiple groups. For this to work, the
list of groups provided to the receivers MUST be sorted and the first
group in the list must be "base layer", if a layered congestion control
algorithm is used.
To be able to participate to a session, receivers MUST be able to
implement the decoder for the FEC encoding in use.
If source authentication information is present in data packets,
receivers MAY use it to authenticate the packet content.
If object transmission status information is present in data packets and
the C flag is set, then receivers MAY originate Request packets to
extend the transmission of an object. See "Session Extension" section
for more details.
9.3. Session Extension
ALC defines an OPTIONAL mechanism for the sender(s) to advertise the
remaining transmission time of an object in a session. This information
MAY be used by receivers to request an extension of the transmission
time of the object.
A sender MAY use the ROT field in data-packet headers to advertise the
remaining transmission time for an object. This time is expressed in
milliseconds. A sender MAY additionally set the C flag to 1, indicating
that receivers MAY originate requests for transmission extension through
the ALC Request packet defined above.
If a sender sets the C flag to 1, it MUST be prepared to accept requests
for transmission extension and process them. The sender MUST *either*
honor the request or immediately indicate that it is not willing to
accept further requests for that object, by setting C to 0 in any
subsequent data packet transmitted for that object. When a sender
decides to honor a request, it MUST immediately reflect this decision
back to the receivers by increasing the value of ROT to a value equal or
larger than the one present in the request packet. The new value of ROT
must be advertised in subsequent data packets transmitted for the
object. Failure to do so may result in implosion of receiver-originated
requests.
Receivers MAY learn the residual transmission time for an object through
Luby, Gemmell, Vicisano, Rizzo, Crowcroft, Lueckenhoff [Page 29]
Draft RMT PI, Asynchronous Layered Coding 13 July 2000
the ROT field optionally present in data packets. If the C flag in these
data packet is set to 1, then receivers MAY originate request for
transmission extension for an object using Request ALC packets. The
object(s) for which receivers can generate transmission-extension
requests are those whose symbols are transmitted in data packets with C
flag set to 1. The association from a data packet to an object is given
by the Object Transmission Label (OTL) field in the packet. If this
field is not present receivers MAY assume that the session is used to
transmit a single object and still originate extension request for that
object (provided that the value of the C flag allows it).
Receivers MUST NOT originate transmission extension request if the C
flag is set to 0 or if this flag is not present in the data-packet
header.
Similarly to Data packets, ALC Requests are encapsulated in UDP packets
and sent to the unicast IP address of the node designated to receive
extension request. The UDP destination port to use is the destination
port used for multicast data packets, unless otherwise specified through
out of band means. By default the destination IP address is the source
address used in the Data packets. Out of band mechanism MAY override
this default behavior by explicitly designating the node to which
extension requests must be sent. Note that when multiple senders are
sending to a session and a specific node that accepts requests is not
designated, then receivers MAY pick any of the senders as destination of
their Request packets. In this case all the senders MUST coordinate in
their reaction to requests (e.g. when they increase the residual
transmission time or when they decide to set C to 0). A receiver that
originates a Request packet for an object whose Transmission Label was
advertised in Data packets MUST copy the Object Transmission Label in
the OTL field of the Request packet. The Requested Object transmission
Extension (ROE) field must be computed as the Residual Object
transmission Time (ROE) plus the extension requested by the receiver.
Receivers MUST implement feedback-implosion avoidance procedures as
follows:
o Receivers use the Residual Object transmission Time advertised by
the sender(s) to predict whether or not they will be able to
recover the object from the packets they have already received and
from the packets they can expect to receive in the future. This
prediction SHOULD also consider data-rate fluctuations caused by
congestion control adaptations.
Luby, Gemmell, Vicisano, Rizzo, Crowcroft, Lueckenhoff [Page 30]
Draft RMT PI, Asynchronous Layered Coding 13 July 2000
o When a receiver predicts that the residual object transmission time
is not sufficient to successfully recover the object, it MAY
schedule the transmission of an extension request at a random time
in the future, before the scheduled end of the transmission.
o When a receiver has a pending extension request scheduled for
transmission, it must keep monitoring the progress of the reception
and cancel the pending request if either of the following happens:
- The residual object transmission time becomes larger the
predicted time needed to complete the reception.
- A Data packet for the object of interest is received with the C
flag set to 0 or without the C header field.
o A receiver MUST cancel pending extension-request when the
transmission time of an object is over.
The rules stated above are not sufficient to obtain a good implosion
prevention in all the cases. For improved performance the following
guidelines SHOULD be followed:
o Extension requests should be *scheduled* only when the reception of
the object is in an advanced status of completion (e.g. more than
50%). This improves the accuracy of the receivers' prediction
reducing the chance that an extension is requested uselessly.
o The time needed for a Request to suppress pending Request from
other receivers is approximatively a packet round trip time
(unicast request to the sender and multicast data packets to the
receivers). Using random-time scheduling for requests is an
effective suppression mechanism only if the the interval from which
to select the actual transmission time is much larger than a round
trip time. For this reason extension requests should be
*scheduled* at least a few seconds before the end of transmission.
10. ALC and Generic Router Assist
Router filtering of ALC packets to assist in congestion control is
described in [LUB99]. The addresses of the multicast groups or channels
can be communicated to the routers and they can do filtering of groups
or channels based on congestion. This is one of the reasons why it is
good to have the sequence number information in a fixed place in the ALC
Luby, Gemmell, Vicisano, Rizzo, Crowcroft, Lueckenhoff [Page 31]
Draft RMT PI, Asynchronous Layered Coding 13 July 2000
packet header, so that the routers can probe this field if necessary
(although it may not be necessary). There are some interesting
strategies for combining router assisted congestion control with
receiver congestion control in such a way that ALC will perform well
when only receivers are doing congestion control, and will perform even
better with router assist. Describing these strategies is outside the
scope of this document.
11. IANA Considerations
The identifiers of FEC encoding (FEC Encoding Identifier), congestion
control algorithm (Congestion Control Identifier) and source
authentication scheme (Source Authentication Information Type) are
subject to IANA registering. This issues is better discussed in the
building-block specifications (e.g. [FEC00] and [MRCC00]).
Building blocks may introduce additional IANA considerations.
12. Intellectual Property Issues
Digital Fountain has patents pending for Tornado codes and for LT codes.
Digital Fountain has patents pending for congestion control protocols
that may be needed to use some of the congestion control protocols
described in this document in a commercial product or service. Digital
Fountain is willing to provide a royalty free license to the rights it
holds that are needed to use the congestion control protocols described
in this document if and when these congestion control protocols become
part of the IETF standards.
13. Acknowledgments
Thanks to Hayder Radha and Vincent Roca for detailed comments on this
paper.
14. References
[MRCC00] "Congestion Control for multi-rate building block", draft
to be written for submission to the IETF.
[AFZ95] Acharya, S., Franklin, M., and Zdonik, S.,
Luby, Gemmell, Vicisano, Rizzo, Crowcroft, Lueckenhoff [Page 32]
Draft RMT PI, Asynchronous Layered Coding 13 July 2000
"Dissemination-Based Data Delivery Using Broadcast Disks", IEEE
Personal Communications, pp.50-60, Dec 1995.
[BLA94] Blahut, R.E., "Theory and Practice of Error Control Codes",
Addison Wesley, MA 1984.
[R2119] Bradner, S., Key words for use in RFCs to Indicate Requirement
Levels (IETF RFC 2119) http://www.rfc-editor.org/rfc/rfc2119.txt
[BYE98] Byers, J.W., Luby, M., Mitzenmacher, M., and Rege, A., "A
Digital Fountain Approach to Reliable Distribution of Bulk Data",
Proceedings ACM SIGCOMM '98, Vancouver, Canada, Sept 1998.
[BYE00] Byers, J.W., Frumin, M., Horn, G., Luby, M., Mitzenmacher, M., Roetter, A.,
"Improved Congestion Control for IP Multicast Using Dynamic Layers",
Digital Fountain research paper, June 2000.
[CAI99] Cain, B., Speakman, T., and Towsley, D., "Generic Router
Assist (GRA) Building Block, Motivation and Architecture", Internet
Draft draft-ietf-rmt-gra-arch-00.txt, a work in progress.
[DEE88] Deering, S., "Host Extensions for IP Multicasting", RFC
1058, Stanford University, Stanford, CA, 1988.
[R2068] Fielding, R., Gettys, J., Mogul, J. Frystyk, H., Berners-Lee,
T., Hypertext Transfer Protocol - HTTP /1.1 (IETF RFC2068)
http://www.rfc-editor.org/rfc/rfc2068.txt
[GEM99] Gemmell, J., Schooler, E., and Gray, J., "FCast Scalable
Multicast File Distribution: Caching and Parameters Optimizations",
Technical Report MSR-TR-99-14, Microsoft Research, Redmond, WA, April,
1999.
[HAN98] Handley, M., and Jacobson, V., "SDP: Session Description
Protocol", RFC 2327, April 1998.
[HAN96] Handley, M., "SAP: Session Announcement Protocol", Internet
Draft, IETF MMUSIC Working Group, Nov 1996.
[HOL99] Holbrook, H., Cheriton, D., "IP Multicast Channels: Experss
Support for Large-scale Single-source Applications", ACM SIGCOMM'99
[HOR00] Horn, G., Luby, M., Mitzenmacher, M.,
"Fair Layered Increase/Decrease Congestion Control",
Digital Fountain research paper, June 2000.
Luby, Gemmell, Vicisano, Rizzo, Crowcroft, Lueckenhoff [Page 33]
Draft RMT PI, Asynchronous Layered Coding 13 July 2000
[FEC00] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., Crowcroft, J.,
Luekenhoff, B., "Reliable Multicast Transport Building Blocks: Forward
Error Correction", Internet Draft draft-ietf-rmt-bb-fec-00.txt, a work
in progress.
[LUB99] Luby, M., Vicisano, L., Speakman, T. "Heterogeneous
multicast congestion control based on router packet filtering",
presented at RMT meeting in Pisa, March 1999.
[LUB00] Luby, M., "An Overview of LT codes", Digital Fountain technical
paper, July 2000.
[MRBP98] Mankin, A., Romanow, A., Brander, S., Paxson, V., "IETF Criteria for
Evaluating Reliable Multicast Transport and Application Protocols,"
RFC2357, June 1998.
[MRCC00] Luby, M., Vicisano, L., Haken, A.,
"Reliable Multicast Transport Building Block:
Multirate Congestion Control", yet to be specified.
[POST80] J. Postel, "User Datagram Protocol", RFC768, August 1980.
[RIZ97a] Rizzo, L, and Vicisano, L., "Reliable Multicast Data
Distribution protocol based on software FEC techniques", Proceedings
of the Fourth IEEES Workshop on the Architecture and Implementation of
High Performance Communication Systems, HPCS'97, Chalkidiki, Greece,
June 1997.
[RIZ97b] Rizzo, L., and Vicisano, L., "Effective Erasure Codes
for Reliable Computer Communication Protocols", ACM SIGCOMM Computer
Communication Review, Vol.27, No.2, pp.24-36, Apr 1997.
[RIZ97c] Rizzo, L., "On the Feasibility of Software FEC",
DEIT Tech Report, http://www.iet.unipi.it/ luigi/softfec.ps, Jan 1997.
[RUB99] Rubenstein, D., Kurose, J. and Towsley, D., "The Impact of
Multicast Layering on Network Fairness", Proceedings of ACM SIGCOMM '99.
[VIC98A] Vicisano, L., Rizzo, L., Crowcroft, J., "TCP-like
Congestion Control for Layered Multicast Data Transfer", IEEE Infocom '98,
San Francisco, CA, Mar.28-Apr.1 1998.
[VIC98B] Vicisano, L., "Notes On a Cumulative Layered
Organization of Data Packets Across Multiple groups with Different
Rates", University College London Computer Science Research Note
Luby, Gemmell, Vicisano, Rizzo, Crowcroft, Lueckenhoff [Page 34]
Draft RMT PI, Asynchronous Layered Coding 13 July 2000
RN/98/25, Work in Progress (May 1998).
A File Transfer using ALC - 'Fcast'
While ALC can be used to transfer arbitrary objects, file transfer is
expected to be a primary application. This appendix describes a standard
for file transfer, called "Fcast".
When the object being transmitted is a file, the receiver usually
requires "metadata" in addition to the file itself, such as the file
name, its creation date, etc. Metadata can be sent a number of ways.
For example, it could be part of the object session description or sent
as a separate ALC object with a well-known object transmission label.
The method described here combines the file with its metadata in a
single ALC object. The metadata is logically appended to the end of the
file as a trailer and sent as part of the transmission. The file with
appended trailer is referred to as the extended file. In order to find
the beginning of the trailer, the last 4 bytes in the object indicate
the length of the trailer. Including metadata is OPTIONAL, so the length
may be zero. Figure 8 shows the layout of the Fcast file transmission.
The metadata is appended rather than prepended to the file so that the
file length may be corrected by simply truncating the extended file
(rather than requiring re-writing). The nature of ALC does not ensure
that the start of the file is received before the end, so there is no
drawback to using a trailer in terms of latency to get the information.
+----------------------------------------------+
| Object | 4-byte checksum | Null padding|
+----------------------------------------------+
/ \\
| ...........
| \\
| ..........
/ \\
+--------------------------------------+
| File data | Trailer | Trailer Length |
+--------------------------------------+
Figure 8 - Fcast file transmission: The ALC object is the file
data, followed by the meta-data trailer, followed by the trailer
length (in bytes - 4 byte value)
Luby, Gemmell, Vicisano, Rizzo, Crowcroft, Lueckenhoff [Page 35]
Draft RMT PI, Asynchronous Layered Coding 13 July 2000
The metadata in the file trailer is stored as ASCII text. It carries
the same information as HTTP object metainformation header fields, as
defined in RFC 2068 [R2068]. As in the RFC, field names should be
followed by a colon, followed by the field value, followed by a CR-LF.
The header fields that are RECOMMENDED/OPTIONAL to be supported by all
receiving clients are listed below and should be interpreted as per
RFC 2068.
RECOMMENDED fields:
Content-Location (indicates the URI for the file - could be
just the file name)
Last-modified
OPTIONAL fields:
Content-Length (indicates the length of the file)
Content-Encoding
Content-Type
Content-Base
Content-Language
Content-Style-Type
Date
Expires
Any other header field defined in RFC 2068 or subsequent HTTP
standards.
Example:
Luby, Gemmell, Vicisano, Rizzo, Crowcroft, Lueckenhoff [Page 36]
Draft RMT PI, Asynchronous Layered Coding 13 July 2000
Content-Length : 1024
Content-Location : http://www.foo.com/myfile.zip
15. Authors' Addresses
Michael Luby
luby@digitalfountain.com
Digital Fountain
600 Alabama Street
San Francisco, CA, USA, 94110
Jim Gemmell
jgemmell@microsoft.com
Microsoft Research
301 Howard St., #830
San Francisco, CA, USA, 94105
Lorenzo Vicisano
lorenzo@cisco.com
cisco Systems, Inc.
170 West Tasman Dr.,
San Jose, CA, USA, 95134
Luigi Rizzo
luigi@iet.unipi.it
Dip. di Ing. dell'Informazione
Universita` di Pisa
via Diotisalvi 2, 56126 Pisa, Italy
Jon Crowcroft
J.Crowcroft@cs.ucl.ac.uk
Department of Computer Science
University College London
Gower Street,
London WC1E 6BT, UK
Bruce Lueckenhoff
brucelu@cadence.com
Cadence Design Systems, Inc.
120 Cremona Drive, Suite C
Santa Barbara, CA 93117
Luby, Gemmell, Vicisano, Rizzo, Crowcroft, Lueckenhoff [Page 37]
Draft RMT PI, Asynchronous Layered Coding 13 July 2000
16. Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are included
on all such copies and derivative works. However, this document itself
may not be modified in any way, such as by removing the copyright notice
or references to the Internet Society or other Internet organizations,
except as needed for the purpose of developing Internet standards in
which case the procedures for copyrights defined in the Internet
languages other than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE."
Luby, Gemmell, Vicisano, Rizzo, Crowcroft, Lueckenhoff [Page 38]
Draft RMT PI, Asynchronous Layered Coding 13 July 2000
Table of Contents
1 Introduction .................................................... 3
2 Related Documents ............................................... 5
3 Applicability ................................................... 6
4 General Architecture ............................................ 6
5 Minimizing reception overhead ................................... 8
5.1 Division into blocks .......................................... 9
5.2 Block FEC codes ............................................... 11
5.2.1 A single group .............................................. 11
5.2.2 Multiple groups ............................................. 12
5.3 Inherent overhead ............................................. 13
6 Delivery service models ......................................... 13
7 Congestion Control .............................................. 14
8 Packet Content .................................................. 14
8.1 Data-Packet content ........................................... 15
8.1.1 Source Authentication Information Field ..................... 20
8.2 Request-Packet content ........................................ 21
8.3 Header-Extension Fields ....................................... 23
9 Procedures ...................................................... 25
9.1 Sender Operation .............................................. 25
9.2 Receiver Operation ............................................ 28
9.3 Session Extension ............................................. 29
10 ALC and Generic Router Assist .................................. 31
11 IANA Considerations ............................................ 32
12 Intellectual Property Issues ................................... 32
13 Acknowledgments ................................................ 32
14 References ..................................................... 32
A File Transfer using ALC - 'Fcast' .............................. 35
15 Authors' Addresses ............................................. 37
16 Full Copyright Statement ....................................... 38
Luby, Gemmell, Vicisano, Rizzo, Crowcroft, Lueckenhoff [Page 39]
--==_Exmh_924555160
Content-Type: text/plain ; name="draft-ietf-rmt-bb-fec-01.txt"; charset=us-ascii
Content-Description: draft-ietf-rmt-bb-fec-01.txt
Content-Disposition: attachment; filename="draft-ietf-rmt-bb-fec-01.txt"
RMT Working Group M.Luby/Digital Fountain
Internet Engineering Task Force L.Vicisano/Cisco
INTERNET-DRAFT L.Rizzo/U. of Pisa
draft-ietf-rmt-bb-fec-01.txt J.Gemmell/Microsoft
13 July 2000 J.Crowcroft/UCL
B. Lueckenhoff/Cadence
Expires 13 January 2000
Reliable Multicast Transport Building Block:
Forward Error Correction Codes
<draft-ietf-rmt-bb-fec-01.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are valid for a maximum of six months and may be
updated, replaced, or obsoleted by other documents at any time. It
is inappropriate to use Internet-Drafts as reference material or to
cite them other than as a "work in progress".
To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html.
Abstract
This memo describes the use of Forward Error Correction (FEC) codes
within the context of reliable IP multicast transport and provides an
introduction to some commonly-used FEC codes.
Draft RMT BB, Forward Error Correction Codes 13 July 2000
1. Rationale and Overview
There are many ways to provide reliability for transmission protocols.
A common method is to use ARQ, automatic request for retransmission.
With ARQ, receivers use a back channel to the sender to send requests
for retransmission of lost packets. ARQ works well for one-to-one
reliable protocols, as evidenced by the pervasive success of TCP/IP.
ARQ has also been an effective reliability tool for one-to-many
reliability protocols, and in particular for some reliable IP multicast
protocols. However, for one-to-very many reliability protocols, ARQ has
limitations, including the feedback implosion problem because many
receivers are transmitting back to the sender, and the need for a back
channel to send these requests from the receiver. Another limitation is
that receivers may experience different loss patterns of packets, and
thus receivers may be delayed by retransmission of packets that other
receivers have lost that but they have already received. This may also
cause wasteful use of bandwidth used to retransmit packets that have
already been received by many of the receivers.
In environments where ARQ is either costly or impossible because there
is either a very limited capacity back channel or no back channel at
all, such as satellite transmission, a Data Carousel approach to
reliability is sometimes used [AFZ95]. With a Data Carousel, the sender
partitions the object into equal length pieces of data, which we
hereafter call source symbols, places them into packets, and then
continually cycles through and sends these packets. Receivers
continually receive packets until they have received a copy of each
packet. Data Carousel has the advantage that it requires no back
channel because there is no data that flows from receivers to the
sender. However, Data Carousel also has limitations. For example, if a
receiver loses a packet in one round of transmission it must wait an
entire round before it has a chance to receive that packet again. This
may also cause wasteful use of bandwidth, as the sender continually
cycles through and transmits the packets until no receiver is missing a
packet.
FEC codes provide a reliability method that can be used to augment or
replace other reliability methods, especially for one-to-many
reliability protocols such as reliable IP multicast. We first briefly
review some of the basic properties and types of FEC codes before
reviewing their uses in the context of reliable IP multicast. Later, we
provide a more detailed description of some of FEC codes.
In the general literature, FEC refers to the ability to overcome both
erasures (losses) and bit-level corruption. However, in the case of IP
Luby, Vicisano, Rizzo, Gemmell, Crowcroft, Lueckenhoff [Page 2]
Draft RMT BB, Forward Error Correction Codes 13 July 2000
multicast, lower network layers will detect corrupted packets and
discard them. Therefore, an IP multicast protocol need not be concerned
with corruption; the focus is solely on erasure codes. The payloads are
generated and processed using an FEC erasure encoder and objects are
reassembled from reception of packets using the corresponding FEC
erasure decoder.
The input to an FEC encoder is some number k of equal length source
symbols. The FEC encoder generates some number of encoding symbols that
are of the same length as the source symbols. The chosen length of the
symbols can vary upon each application of the FEC encoder, or it can be
fixed. These encoding symbols are placed into packets for transmission.
The number of encoding symbols placed into each packet can vary on a per
packet basis, or a fixed number of symbols (often one) can be placed
into each packet. Also, in each packet is placed enough information to
identify the particular encoding symbols carried in that packet. Upon
receipt of packets containing encoding symbols, the receiver feeds these
encoding symbols into the corresponding FEC decoder to recreate an exact
copy of the k source symbols. Ideally, the FEC decoder can recreate an
exact copy from any k of the encoding symbols.
In a later section, we describe a technique for using FEC codes as
described above to handle blocks with variable length source symbols.
Block FEC codes work as follows. The input to a block FEC encoder is k
source symbols and a number n. The encoder generates n-k redundant
symbols yielding an encoding block of n encoding symbols in total
composed of the k source symbols and the n-k redundant symbols. A block
FEC decoder has the property that any k of the n encoding symbols in the
encoding block is sufficient to reconstruct the original k source
symbols.
Expandable FEC codes work as follows. An expandable FEC encoder takes
as input k source symbols and generates as many unique encoding symbols
as requested on demand, where the amount of time for generating each
encoding symbol is the same independent of how many encoding symbols are
generated. Unlike block FEC codes, the source symbols are not
considered part of the encoding symbols for an expandable FEC code. An
expandable FEC decoder has the property that any k of the unique
encoding symbols is sufficient to reconstruct the original k source
symbols.
Along a different dimension, we classify FEC codes loosely as being
either small or large. A small FEC code is efficient in terms of
processing time requirements for encoding and decoding for small values
Luby, Vicisano, Rizzo, Gemmell, Crowcroft, Lueckenhoff [Page 3]
Draft RMT BB, Forward Error Correction Codes 13 July 2000
of k, and a large FEC code is efficient for encoding and decoding for
much large values of k. There are implementations of standard block FEC
codes that have encoding times proportional to n times the length of the
k source symbols, and decoding times proportional l times the length of
the k source symbols, where l is the number of missing source symbols
among the k received encoding symbols. Because of the growth rate of
the encoding and decoding times as a function of k and n, these are
typically considered to be small block FEC codes. There are close
approximations to block FEC codes which for all practical purposes can
generate n encoding symbols and can decode the k source symbols in time
proportional to the length of the n encoding symbols. These codes are
considered to be large block FEC codes. There are close approximations
to expandable FEC codes which for all practical purposes can generate
each encoding symbol in time proportional to its length, and can decode
all k source symbols in time proportional to their length. These are
considered to be large expandable FEC codes.
Ideally, FEC codes in the context of IP multicast can be used to
generate encoding symbols that are transmitted in packets in such a way
that each received packet is fully useful to a receiver to reassemble
the object regardless of previous packet reception patterns. Thus, if
some packets are lost in transit between the sender and the receiver,
instead of asking for specific retransmission of the lost packets or
waiting till the packets are resent using Data Carousel, the receiver
can use any other subsequent equal amount of data contained in packets
that arrive to reassemble the object. These packets can either be
proactively transmitted or they can be explicitly requested by
receivers. This implies that the data contained in the same packet is
fully useful to all receivers to reassemble the object, even though the
receivers may have previously experienced different packet loss
patterns. This property can reduce or even eliminate the problems
mentioned above associated with ARQ and Data Carousel and thereby
dramatically increase the scalability of the protocol to orders of
magnitude more receivers.
1.1. Application of FEC codecs
For some reliable IP multicast protocols, FEC codes are used in
conjunction with ARQ to provide reliability. For example, a large
object could be partitioned into a number of source blocks consisting of
a small number of source symbols each, and in a first round of
transmission all of the source symbols for all the source blocks could
be transmitted. Then, receivers could report back to the sender the
number of source symbols they are missing from each source block. The
Luby, Vicisano, Rizzo, Gemmell, Crowcroft, Lueckenhoff [Page 4]
Draft RMT BB, Forward Error Correction Codes 13 July 2000
sender could then compute the maximum number of missing source symbols
from each source block among all receivers. Based on this, a small
block FEC encoder could be used to generate for each source block a
number of redundant symbols equal to the computed maximum number of
missing source symbols from the block among all receivers. In a second
round of transmission, the server would then send all of these redundant
symbols for all blocks. In this example, if there are no losses in the
second round of transmission then all receivers will be able to recreate
an exact copy of each original block. In this case, even if different
receivers are missing different symbols in different blocks, transmitted
redundant symbols for a given block are useful to all receivers missing
symbols from that block in the second round.
For other reliable IP multicast protocols, FEC codes are used in a Data
Carousel fashion to provide reliability, which we call an FEC Data
Carousel. For example, an FEC Data Carousel using a large block FEC
code could work as follows. The large block FEC encoder produces n
encoding symbols considering all the k source symbols of an object as
one block. The sender cycles through and transmits the n encoding
symbols in packets in the same order in each round. An FEC Data
Carousel can have much better protection against packet loss than a Data
Carousel. For example, a receiver can join the transmission at any
point in time, And, as long as the receiver receives at least k encoding
symbols during the transmission of the next n encoding symbols, the
receiver can completely recover the object. This is true even if the
receiver starts receiving packets in the middle of a pass through the
encoding symbols. This method can also be used when the object is
partitioned into blocks and a short block FEC code is applied to each
block separately. In this case, as we explain in more detail below, it
is useful to interleave the symbols from the different blocks when they
are transmitted.
Since any number of encoding symbols can be generated using an
expandable FEC encoder, reliable IP multicast protocols that use
expandable FEC codes generally rely solely on these codes for
reliability. For example, when an expandable FEC code is used in a FEC
Data Carousel application, the encoding packets never repeat, and thus
any k of the encoding symbols in the potentially unbounded number of
encoding symbols are sufficient to recover the original k source
symbols.
For yet other reliable IP multicast protocols the method to obtain
reliability is to generate enough encoding symbols so that each encoding
symbol is transmitted at most once. For example, the sender can decide
a priori how many encoding symbols it will transmit, use an FEC code to
Luby, Vicisano, Rizzo, Gemmell, Crowcroft, Lueckenhoff [Page 5]
Draft RMT BB, Forward Error Correction Codes 13 July 2000
generate that number of encoding symbols from the object, and then
transmit the encoding symbols to all receivers. This method is for
example applicable to streaming protocols, where the stream is
partitioned into objects, the source symbols for each object are encoded
into encoding symbols using an FEC code, and then the sets of encoding
symbols for each object are transmitted one after the other using IP
multicast.
2. FEC Codes
2.1. Simple codes
There are some very simple codes that are effective for repairing packet
loss under very low loss conditions. For example, one simple way to
provide protection from a single loss is to partition the object into
fixed size source symbols and then add a redundant symbol that is the
parity (XOR) of all the source symbols. The size of a source symbol is
chosen so that it fits perfectly into the payload of a packet, i.e. if
the packet payload is 512 bytes then each source symbol is 512 bytes.
The header of each packet contains enough information to identify the
payload. In this case, this includes a symbol ID. The symbol IDs are
numbered consecutively starting from zero independently for the source
symbols and for the redundant symbol. Thus, the packet header also
contains an encoding flag that indicates whether the symbol in the
payload is a source symbol or a redundant symbol, where 1 indicates
source symbol and 0 indicates redundant symbol. For example, if the
object consists of four source symbols that have values a, b, c and d,
then the value of the redundant symbol is e = a XOR b XOR c XOR d.
Then, the packets carrying these symbols look like
(0, 1: a), (1, 1: b), (2, 1: c), (3, 1: d), (0, 0: e).
In this example, the first two fields are in the header of the packet,
where the first field is the symbol ID and the second field is the
encoding flag. The portion of the packet after the colon is the
payload. Any single symbol of the object can be recovered as the parity
of all the other symbols. For example, if packets
(0, 1: a), (1, 1: b), (3, 1: d), (0, 0: e)
are received then the symbol value for the missing source symbol with ID
2 can be recovered by computing a XOR b XOR d XOR e = c.
Luby, Vicisano, Rizzo, Gemmell, Crowcroft, Lueckenhoff [Page 6]
Draft RMT BB, Forward Error Correction Codes 13 July 2000
When the number of source symbols in the object is large, a simple block
code variant of the above can be used. In this case, the source symbols
are grouped together into source blocks of some number k of consecutive
symbols each, where k may be different for different blocks. If a block
consists of k source symbols then a redundant symbol is added to form an
encoding block consisting of k+1 encoding symbols. Then, a source block
consisting of k source symbols can be recovered from any k of the k+1
encoding symbols from the associated encoding block.
Slightly more sophisticated ways of adding redundant symbols using
parity can also be used. For example, one can group a block consisting
of k source symbols in an object into a p x p square matrix, where p =
sqrt(k). Then, for each row a redundant symbol is added that is the
parity of all the source symbols in the row. Similarly, for each column
a redundant symbol is added that is the parity of all the source symbols
in the column. Then, any row of the matrix can be recovered from any p
of the p+1 symbols in the row, and similarly for any column. Higher
dimensional product codes using this technique can also be used.
However, one must be wary of using these constructions without some
thought towards the possible loss patterns of symbols. Ideally, the
property that one would like to obtain is that if k source symbols are
encoded into n encoding symbols (the encoding symbols consist of the
source symbols and the redundant symbols) then the k source symbols can
be recovered from any k of the n encoding symbols. Using the simple
constructions described above does not yield codes that come close to
obtaining this ideal behavior.
2.2. Small block FEC codes
Reliable IP multicast protocols may use a block (n, k) FEC code [BLA84].
A popular example of these types of codes is a class of Reed-Solomon
codes. For such codes, k source symbols are encoded into n > k encoding
symbols, such that any k of the encoding symbols can be used to
reassemble the original k source symbols. Thus, these codes have 0%
reception overhead when used to encode the entire object directly.
Block codes are usually systematic, which means that the n encoding
symbols consist of the k source symbols and n-k redundant symbols
generated from these k source symbols, where the size of a redundant
symbol is the same as that for a source symbol. For example, the first
simple code (XOR) described in the previous subsection is a (k+1, k)
code. In general, the freedom to choose n larger than k+1 is desirable,
as this can provide much better protection against losses. Codes of
this sort are often based on algebraic methods using finite fields.
Some of the most popular such codes are based on linear block codes.
Luby, Vicisano, Rizzo, Gemmell, Crowcroft, Lueckenhoff [Page 7]
Draft RMT BB, Forward Error Correction Codes 13 July 2000
Implementations of (n, k) FEC erasure codes are efficient enough to be
used by personal computers [RIZ97c, NON97]. For example, [RIZ97b]
describes an implementation where the encoding and decoding speeds decay
as C/j, where the constant C is on the order of 10 to 80 Mbytes/second
for Pentium class machines of various vintages and j is upper bounded by
min(k, n-k).
In practice, the values of k and n must be small (below 256) for such
FEC codes as large values make encoding and decoding prohibitively
expensive. As many objects are longer than k symbols for reasonable
values of k and the symbol length (e.g. larger than 16 kilobyte for k =
16 using 1 kilobyte symbols), they can be divided into a number of
source blocks. Each source block consists of some number k of source
symbols, where k may vary between different source blocks. The FEC
encoder is used to encode a k source symbol source block into a n
encoding symbol encoding block, where the length n of the encoding block
may vary for each source block. For a receiver to completely recover
the object, for each source block consisting of k source symbols, k
distinct encoding symbols (i.e., with different symbol IDs) must be
received from the corresponding encoding block. For some encoding
blocks, more encoding symbols may be received than there are source
symbols in the corresponding source block, in which case any additional
encoding symbols are discarded. An example encoding structure is shown
in Figure 1.
Luby, Vicisano, Rizzo, Gemmell, Crowcroft, Lueckenhoff [Page 8]
Draft RMT BB, Forward Error Correction Codes 13 July 2000
| source symbols | source symbols |
| of source block 0 | of source block 1 |
| |
v v
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|0 |1 |2 |3 |4 |5 |6 |7 |0 |1 |2 |3 | 4|5 |6 |7 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|
FEC encoder
|
v
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|0 |1 |2 |3 | 4| 5| 6| 7| 8| 9| 0| 1| 2| 3| 4| 5| 6| 7| 8| 9|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
^ ^
| |
| encoding symbols | encoding symbols |
| of encoding block 0 | of encoding block 1 |
Figure 1. Encoding structure for object divided into two source
blocks consisting of 8 source symbols each, and the FEC encoder
is used to generate 2 additional redundant symbols (10 encoding
symbols in total) for each of the two source blocks.
In many cases, an object is partitioned into equal length source blocks
each consisting of k contiguous source symbols of the object, i.e.,
block c consists of the range of source symbols [ck, (c+1)k-1]. This
ensure that the FEC encoder can be optimized to handle a particular
number k of source symbols. This also ensures that memory references
are local when the sender reads source symbols to encode, and when the
receiver reads encoding symbols to decode. Locality of reference is
particularly important when the object is stored on disk, as it reduces
the disk seeks required. The block number and the source symbol ID
within that block can be used to uniquely specify a source symbol within
the object. If the size of the object is not a multiple of k source
symbols, then the last source block will contain less than k symbols.
Encoding symbols can be uniquely identified by block number and encoding
symbol ID. The block numbers can be numbered consecutively starting
from zero. One way of identifying encoding symbols within a block are
to use symbol IDs and an encoding flag that is used to specify whether
an encoding symbol is a source symbol or a redundant symbol, where for
example 1 indicates source symbol and 0 indicate redundant symbol. The
Luby, Vicisano, Rizzo, Gemmell, Crowcroft, Lueckenhoff [Page 9]
Draft RMT BB, Forward Error Correction Codes 13 July 2000
symbol IDs can be numbered consecutively starting from zero for each
block independently for the source symbols and for the redundant
symbols. Thus, an encoding symbol can be identified by its block
number, the encoding flag, and the symbol ID. For example, if the
object consists 10 source symbols with values a, b, c, d, e, f, g, h, i,
and j, and k = 5 and n = 8, then there are two source blocks consisting
of 5 symbols each, and there are two encoding blocks consisting of 8
symbols each. Let p, q and r be the values of the redundant symbols for
the first encoding block, and let x, y and z be the values of the
redundant symbols for the second encoding block. Then the encoding
symbols together with their identifiers are
(0, 0, 1: a), (0, 1, 1: b), (0, 2, 1: c), (0, 3, 1: d), (0, 4, 1: e),
(0, 0, 0: p), (0, 1, 0: q), (0, 2, 0: r),
(1, 0, 1: f), (1, 1, 1: g), (1, 2, 1: h), (1, 3, 1: i), (1, 4, 1: j),
(1, 0, 0: x), (1, 1, 0: y), (1, 2, 0: z).
In this example, the first three fields identify the encoding symbol,
where the first field is the block number, the second field is the
symbol ID and the third field is the encoding flag. The value of the
encoding symbol is written after the colon. Each block can be recovered
from any 5 of the 8 encoding symbols associated with that block. For
example, reception of (0, 1, 1: b), (0, 2, 1: c), (0, 3, 1: d), (0, 0,
0: p) and (0, 1, 0: q) are sufficient to recover the first source block
and reception of (1, 0, 1: f), (1, 1, 1: g), (1, 0, 0: x), (1, 1, 0: y)
and (1, 2, 0: z) are sufficient to recover the second source block.
2.3. Large block FEC codes
Tornado codes [LUB97] are block FEC codes that provide an alternative to
small block FEC codes. A (n, k) Tornado code requires slightly more
than k out of n encoding symbols to reassemble k source symbols.
However, the advantage is that the value of k may be on the order of
tens of thousands and still run efficiently. Because of memory
considerations, in practice the value of n is restricted to be a small
multiple of k, e.g., n = 2k. For example, [BYE98] describes an
implementation of Tornado codes where the encoding and decoding speeds
are tens of megabytes per second range for Pentium class machines of
various vintages when k is in the tens of thousands and n = 2k. The
reception overhead for such values of k and n is in the 5-10% range.
Tornado codes require a large amount of out of band information to be
communicated to all senders and receivers for each different object
Luby, Vicisano, Rizzo, Gemmell, Crowcroft, Lueckenhoff [Page 10]
Draft RMT BB, Forward Error Correction Codes 13 July 2000
length, and require an amount of memory on the encoder and decoder which
is proportional to the object length times 2n/k.
Tornado codes are designed to have low reception overhead on average
with respect to reception of a random portion of the encoding packets.
Thus, to ensure that a receiver can reassemble the object with low
reception overhead, the packets are permuted into a random order before
transmission.
2.4. Expandable FEC codes
All of the FEC codes described up to this point are block codes. There
is a different type of FEC codes that we call expandable FEC codes.
Like block codes, an expandable FEC encoder operates on an object of
known size that is partitioned into equal length source symbols. Unlike
block codes, ideally there is no predetermined number of encoding
symbols that can be generated for expandable FEC codes. Instead, an
expandable FEC encoder can generate as few or as many unique encoding
symbols as required on demand. Also unlike block codes, optimal
expandable FEC codes have the additional attractive property that
encoding symbols for the same object can be generated and transmitted
from multiple servers and concurrently received by a receiver and yet
the receiver incurs a 0% reception overhead.
LT codes [LUB00] are an example of large expandable FEC codes. An LT
encoder uses randomization to generate each encoding symbol randomly and
independently of all other encoding symbols. Like Tornado codes, the
number of source symbols k may be very large for LT codes, i.e., on the
order of tens to hundreds of thousands, and the encoder and decoder run
efficiently in software. For example the encoding and decoding speeds
for LT codes are in the range 3-20 megabytes per second for Pentium
class machines of various vintages when k is in the high tens of
thousands. An LT encoder closely approximates the properties of an
ideal expandable FEC encoder, as it can generate as few or as many
encoding symbols as required on demand. When a new encoding symbol is
to be generated by an LT encoder, it is based on a randomly chosen
32-bit encoding symbol ID that uniquely describes how the encoding
symbol is to be generated from the input symbols. In general, each
encoding symbol ID value corresponds to a unique encoding symbol, and
thus the space of possible encoding symbols is approximately four
billion. Thus, the chance that a particular encoding symbol is the same
as any other particular encoding symbol is tiny. An LT decoder has the
property that with very high probability the receipt of any set of
slightly more than k randomly and independently generated encoding
Luby, Vicisano, Rizzo, Gemmell, Crowcroft, Lueckenhoff [Page 11]
Draft RMT BB, Forward Error Correction Codes 13 July 2000
symbols is sufficient to reassemble the k source symbols. For example,
when k is on the order of tens to hundreds of thousands the reception
overhead is less than 5% with no failures in tens of millions of trials
under a variety of loss conditions.
Because encoding symbols are randomly and independently generated by
choosing random encoding symbol IDs, LT codes have the property that
encoding symbols for the same k source symbols can be generated and
transmitted from multiple senders ad than if all the encoding symbols
were generated by a single sender. The only requirement is that the
senders choose their encoding symbol IDs randomly and independently of
one another.
There is a weak tradeoff between the number of source symbols and the
reception overhead for LT codes, and the larger the number of source
symbols the smaller the reception overhead. Thus, for shorter objects,
it is sometimes advantageous to include multiple symbols in each packet.
Normally, and in the discussion below, there is only one symbol per
packet.
There are a couple of factors for choosing the appropriate symbol
length/ number of input symbols tradeoff. The primary consideration is
that there is a fixed overhead per symbol component in the overall
processing requirements of the encoding and decoding, independent of the
number of input symbols. Thus, using shorter symbols means that this
fixed overhead processing per symbol will be a larger component of the
overall processing requirements, leading to larger overall processing
requirements. Because of this, it is advisable to use a reasonably
sized fixed symbol length independent of the length of the object, and
thus shorter objects will be partitioned into fewer symbols than larger
objects. A second much less important consideration is that there is a
component of the processing per symbol that depends logarithmically on
the number of input symbols, and thus for this reason there is a slight
preference towards less input symbols.
Like small block codes, there is a point when the object is large enough
that it makes sense to partition it into blocks when using LT codes.
Generally the object is partitioned into blocks whenever the number of
source symbols times the packet payload length is less than the size of
the object. Thus, if the packet payload is 1024 bytes and the number of
source symbols is 64,000 then any object over 64 megabytes will be
partitioned into more than one block. One can choose the number of
source symbols to partition the object into, depending on the desired
encoding and decoding speed versus reception overhead tradeoff desired.
Encoding symbols can be uniquely identified by a block number (when the
Luby, Vicisano, Rizzo, Gemmell, Crowcroft, Lueckenhoff [Page 12]
Draft RMT BB, Forward Error Correction Codes 13 July 2000
object is large enough to be partitioned into more than one block) and
an encoding symbol ID. The block numbers, if they are used, are
generally numbered consecutively starting from zero within the object.
The block number and the encoding symbol ID are both chosen uniformly
and randomly from their range when an encoding symbol is to be generated
and transmitted. For example, suppose the number of source symbols is
64,000 and the number of blocks is 2. Then, each packet generated by
the LT encoder could be of the form (b, x: y). In this example, the
first two fields identify the encoding symbol, where the first field is
the block number b = 0 or 1 and the second field is the randomly chosen
encoding symbol ID x. The value y after the colon is the value of the
encoding symbol.
2.5. Source blocks with variable length source symbols
For all the FEC codes described above, all the source symbols in the
same source block are all of the same length. In this section, we
describe a general technique to handle the case when it is desirable to
use source symbols of varying lengths in a single source block. This
technique is applicable to block FEC codes.
Let l_1, l_2, ... , l_k be the lengths of k varying length source
symbols to be considered part of the same source block. Let lmax be the
maximum over i = 1, ... , k of l_i. To prepare the source block for the
FEC encoder, pad each source symbol i out to length lmax with a suffix
of lmax-i zeroes, and then prepend to the beginning of this the value
l_i. Thus, each padded source symbol is of length x+lmax, assuming that
the length of an original symbol takes x bytes to store. These padded
source symbols, each of length x+lmax, are the input to the encoder,
together with the value n. The encoder then generates n-k redundant
symbols, each of length x+lmax.
The encoding symbols that are placed into packets consist of the
original k varying length source symbols and n-k redundant symbols, each
of length x+lmax. >From any k of the received encoding symbols, the FEC
decoder recreates the k original source symbols as follows. If all k
original source symbols are received, then no decoding is necessary.
Otherwise, at least one redundant symbol is received, from which the
receiver can easily whether the block was composed of variable-length
source symbols: if the redundant symbol(s) has a size different (larger)
from the source symbols then the source symbols are variable-length.
Note that in a variable-length block the redundant symbols are always
larger than the largest source symbol, due to the presence of the
encoded symbol-length. The receiver can determine the value of lmax by
Luby, Vicisano, Rizzo, Gemmell, Crowcroft, Lueckenhoff [Page 13]
Draft RMT BB, Forward Error Correction Codes 13 July 2000
subtracting x from the length of a received redundant symbol. Note that
x MUST be a protocol constant. For each of the received original source
symbols, the receiver can generate the corresponding padded source
symbol as described above. Then, the input to the FEC decoder is the
set of received redundant symbols, together with the set of padded
source symbols constructed from the received original symbols. The FEC
decoder then produces the set of k padded source symbols. Once the k
padded source symbols have been recovered, the length l_i of original
source symbol i can be recovered from the first x bytes of the ith
padded source symbol, and then original source symbol i is obtained by
taking the next l_i bytes following the x bytes of the length field.
3. FEC Abstract Packet Fields and Out-of-Band Information
This section specify the information that protocol packets must carry to
implement the various forms of FEC-based reliability. A session is
defined to be all the information associated with a transmission of data
about a particular object by a single sender. There are three classes
of packets that may contain FEC information within a session: data
packets, session-control packets and feedback packets. They generally
contain different kinds of FEC information. Note that some protocols do
not use feedback packets.
Data packets MAY sometime serve as session-control packets as well; both
data and session-control packets generally travel downstream (from the
sender towards receivers) and are addressed to a multicast IP address
(sometime the might be addressed to the unicast address of a specific
receiver). In the following, for simplicity we will refer to both data
and session control packets as downstream-traveling packets, or simply
downstream packets.
As a general rule, feedback packets travel upstream (from receivers to
the sender) and are addressed to the unicast address of the sender.
Sometimes, however, they might be addressed to a multicast IP address or
to the unicast address of a receiver or also the the unicast address of
some different node (intermediate node that provides recovery services
or neighboring router).
The FEC-related information that can be present in downstream packets
can be classified as follows:
1) FEC Encoding Identifier
Luby, Vicisano, Rizzo, Gemmell, Crowcroft, Lueckenhoff [Page 14]
Draft RMT BB, Forward Error Correction Codes 13 July 2000
Identifies the FEC encoding being used and has the purpose of
allowing receivers to select the appropriate FEC decoder. As a
general rule, the "FEC Encoding Identifier" MUST be the same for
a given session, i.e., for all transmission of data related to a
particular object, but MAY vary across different transmissions of
data about different objects in different sessions, even if
transmitted using the same set of multicast groups.
2) FEC payload ID
Identifies the symbol(s) in the payload of the packet. The
content of this piece of information depends on the encoder being
used (e.g. in Block FEC codes this may be the combination of
block index and symbol index; in expandable FEC codes this may be
just a flat symbol identifier).
3) FEC Object Transmission Information
This is information regarding the encoding of a specific object
needed by the FEC decoder (e.g. for Block FEC codes this may be
the combination of block length and object length). This might
also include general parameters of the FEC encoder.
All the classes of information above, except 2), can either be
transmitted within the transport session (using protocol packet-header
fields) or out of band. The information described in 2) MUST be
transmitted in data-packet header fields, as it provides a description
of the data contained in the packet. In the following we specify the
content of 1), 2) and 3) independent of whether these pieces of
information are transmitted in protocol packets or out of band. This
document does not specify out of band methods to transport the
information.
Within the context of FEC repair schemes, feedback packets are
(optionally) used to request FEC retransmission. The FEC-related
information present in feedback packets can be classified as follow:
1) FEC Block Identifier
This is the identifier of the FEC block for which retransmission
is requested. This information does not apply to some type of
decoders.
Luby, Vicisano, Rizzo, Gemmell, Crowcroft, Lueckenhoff [Page 15]
Draft RMT BB, Forward Error Correction Codes 13 July 2000
2) Number of Repair Symbols
This is the number of repair symbols requested, needed to recover
the object.
3.1. FEC Encoding Identifier
This is a numeric index that identifies a specific FEC encoding scheme
OR a class of encoding schemes that share the same format of "FEC
Payload ID" and "FEC Object Transmission Information".
The FEC Encoding Identifier identifies a specific FEC encoding scheme
when the encoding scheme is formally and fully specified, in a way that
independent implementors can implement both encoder and decoder from the
specification. Companion documents of this specification may specify
such FEC encoding schemes and associate them with "FEC Encoding
Identifier" values. These documents MUST also specify a correspondent
format for the "FEC Payload ID" and "FEC Object Transmission
Information". Currently FEC Encoding Identifiers in the range 0-127 are
reserved for this class of encoding schemes.
It is possible that a FEC encoding scheme cannot be completely specified
or that such a specification is simply not available or also that a
party exists that owns the encoding scheme and it is not willing to
disclose its algorithm. We refer to these encoding schemes as "Under-
Specified" schemes. Under-specified schemes can still be identified as
follows:
o A format of the fields "FEC Payload ID" and "FEC Object
Transmission Information" MUST be defined for the encoding scheme.
o A value of "FEC Encoding Identifier" MUST be reserved and
associated to the format definitions above. An already reserved
"FEC Encoding Identifier" MUST be reused if it is associated to
the same format of "FEC Payload ID" and "FEC Object Transmission
Information" as the ones needed for the new under-specified FEC
encoding scheme.
o A value of "FEC Encoding Name" must be reserved (see below).
An Under-specified FEC scheme is completely identified by the tuple (FEC
Encoding Identifier, FEC Encoding Name). The party that owns this tuple
MUST be able to provide an FEC encoder and decoder that implement the
Luby, Vicisano, Rizzo, Gemmell, Crowcroft, Lueckenhoff [Page 16]
Draft RMT BB, Forward Error Correction Codes 13 July 2000
under-specified FEC encoding scheme identified by the tuple.
"FEC Encoding Names" are numeric identifiers scoped by a FEC Encoding
Identifier.
The FEC Encoding Name MUST be part of the "FEC Object Transmission
Information" and must be communicated to receivers together with the FEC
Encoding Identifier.
An FEC Encoding Identifier MAY also define a format for the (abstract)
feedback packet fields "FEC Block Identifier" and "Number of Repair
Symbols".
3.2. FEC Payload ID and FEC Object Transmission Information
A document that specifies an encoding scheme and reserves a value of FEC
Encoding Identifier MUST define a packet-field format for FEC Payload ID
and FEC Object Transmission Information according to the need of the
encoding scheme. This also applies to documents that reserves values of
FEC Encoding Identifiers for under-specified encoding schemes. In this
case the FEC Object Transmission Information must also include a field
to contain the "FEC Encoding Name".
A packet field definition of FEC Object Transmission Information MUST be
provided despite the fact that protocol instantiation may decide to
communicate this information out of band.
The packet field format of "FEC Block Identifier" and "Number of Repair
Symbols" SHOULD be specified for each FEC encoding scheme, even the
scheme is mainly intended for feedback-less protocols. FEC Block
Identifier may not apply to some encoding schemes.
All packet field definition (FEC Payload ID, FEC Object Transmission
Information, FEC Block Identifier and Number of Repair Symbols) MUST be
fully specified at level of bit-fields and they must have a length that
is a multiple of a 4-byte word (this is to facilitate the alignment of
packet fields in protocol instantiations).
4. IANA Considerations
Values of FEC Encoding Identifiers and FEC Encoding Names are subject to
IANA registration. FEC Encoding Identifiers and FEC Encoding Names are
hierarchical: FEC Encoding Identifiers (at the top level) scope ranges
Luby, Vicisano, Rizzo, Gemmell, Crowcroft, Lueckenhoff [Page 17]
Draft RMT BB, Forward Error Correction Codes 13 July 2000
of FEC Encoding Names. Not all FEC Encoding Identifiers have a
corresponding FEC Encoding Name scope (see below).
A FEC Encoding Identifier is a numeric non-negative index. Value from 0
to 127 are reserved for FEC encoders that are fully specified, as
described in section 3.1. The assignment of a FEC Encoding Identifier in
this range can only be granted if the requestor can provide such a
specification published as an IETF RFC. Value grater than 127 can be
assigned to under-specified encoding schemes.
In any case values of FEC Encoding Identifiers can only be assigned if
the required FEC packet fields corresponding to it (see section 3.1) are
specified in a RFC.
Each FEC Encoding Identifier assigned to an under-specified encoding
scheme scopes a range of FEC Encoding Names. An FEC Encoding Name is a
numeric non-negative index. The document that reserves a FEC Encoding
Identifier MAY also specify a range for the subordinate FEC Encoding
Names.
Under the scope of a FEC Encoding Identifier, FEC Encoding Names are
assigned on a First Come First Served base to requestors that are able
to provide point of contact information and a pointer to publicly
accessible documentation describing the FEC encoder and a ways to obtain
it. The requestor is responsible for keeping this information up to
date.
5. Security Considerations
The use of FEC, in and of itself, imposes no additional security
considerations versus sending the same information without FEC.
However, just like for any transmission system, a malicious sender may
intentionally transmit bad symbols. If a receiver accepts one or more
bad symbols in place of authentic ones then such a receiver will have
its entire object down-load corrupted by the bad symbol. Application-
level transmission object authentication can detect the corrupted
transfer, but the receiver must then discard the transferred object.
Thus, transmitting false symbols is at least an effective denial of
service attack. At worst, a malicious sender could add, delete, or
replace arbitrary data within the transmitted object.
In light of this possibility, FEC receivers may screen the source
address of a received symbol against a list of authentic transmitter
addresses. Since source addresses may be spoofed, FEC transport
Luby, Vicisano, Rizzo, Gemmell, Crowcroft, Lueckenhoff [Page 18]
Draft RMT BB, Forward Error Correction Codes 13 July 2000
protocols may provide mechanisms for robust source authentication of
each encoded symbol. Multicast routers along the path of a FEC transfer
may provide the capability of discarding multicast packets that
originated on that subnet, and whose source IP address does not
correspond with that subnet.
6. Intellectual Property Disclosure
Tornado codes [LUB97] have both patents issued and patents pending. LT
codes [LUB00] have patents pending.
7. Acknowledgments
Thanks to Vincent Roca and Hayder Radha for their detailed comments on
this draft.
8. References
[AFZ95] Acharya, S., Franklin, M., and Zdonik, S., ``Dissemination-
Based Data Delivery Using Broadcast Disks'', IEEE Personal
Communications, pp.50-60, Dec 1995.
[BLA94] Blahut, R.E., ``Theory and Practice of Error Control Codes'',
Addison Wesley, MA 1984.
[BYE98] Byers, J.W., Luby, M., Mitzenmacher, M., and Rege, A., ``A
Digital Fountain Approach to Reliable Distribution of Bulk Data'',
Proceedings ACM SIGCOMM '98, Vancouver, Canada, Sept 1998.
[DEE88] Deering, S., ``Host Extensions for IP Multicasting'', RFC
1058, Stanford University, Stanford, CA, 1988.
[GEM99] Gemmell, J., Schooler, E., and Gray, J., ``ALC Scalable
Multicast File Distribution: Caching and Parameters Optimizations''
Technical Report MSR-TR-99-14, Microsoft Research, Redmond, WA, April,
1999.
[HAN98] Handley, M., and Jacobson, V., ``SDP: Session Description
Protocol'', RFC 2327, April 1998.
[HAN96] Handley, M., ``SAP: Session Announcement Protocol'', Internet
Draft, IETF MMUSIC Working Group, Nov 1996.
Luby, Vicisano, Rizzo, Gemmell, Crowcroft, Lueckenhoff [Page 19]
Draft RMT BB, Forward Error Correction Codes 13 July 2000
[LUB97] Luby, M., Mitzenmacher, M., Shokrollahi, A., Spielman, D.,
Stemann, V., ``Practical Loss-Resilient Codes'' 29th STOC'97.
[LUB99] Luby, M., Vicisano, L., Speakman, T. ``Heterogeneous multicast
congestion control based on router packet filtering'', presented at
RMT meeting in Pisa, March 1999.
[LUB00] Luby, M., "An overview of LT codes", Digital Fountain white paper,
July 2000.
[R2068] Fielding, R., Gettys, J., Mogul, J. Frystyk, H., Berners-Lee,
T., Hypertext Transfer Protocol HTTP/1.1 (IETF RFC2068)
http://www.rfc-editor.org/rfc/rfc2068.txt
[R2119] Bradner, S., Key words for use in RFCs to Indicate Requirement
Levels (IETF RFC 2119) http://www.rfc-editor.org/rfc/rfc2119.txt
[RIZ97a] Rizzo, L, and Vicisano, L., ``Reliable Multicast Data
Distribution protocol based on software FEC techniques'', Proceedings
of the Fourth IEEE Workshop on the Architecture and Implementation of
High Performance Communication Systems, HPCS-97, Chalkidiki, Greece,
June 1997.
[RIZ97b] Rizzo, L., and Vicisano, L., ``Effective Erasure Codes for
Reliable Computer Communication Protocols'', ACM SIGCOMM Computer
Communication Review, Vol.27, No.2, pp.24-36, Apr 1997.
[RIZ97c] Rizzo, L., ``On the Feasibility of Software FEC'', DEIT Tech
Report, http://www.iet.unipi.it/ luigi/softfec.ps, Jan 1997.
[RUB99] Rubenstein, Dan, Kurose, Jim and Towsley, Don, ``The Impact of
Multicast Layering on Network Fairness'', Proceedings of ACM SIGCOMM'99.
[VIC98A] L.Vicisano, L.Rizzo, J.Crowcroft, ``TCP-like Congestion
Control for Layered Multicast Data Transfer'', IEEE Infocom '98, San
Francisco, CA, Mar.28-Apr.1 1998.
[VIC98B] Vicisano, L., ``Notes On a Cumulative Layered Organization
of Data Packets Across Multiple Streams with Different Rates'',
University College London Computer Science Research Note RN/98/25,
Work in Progress (May 1998).
Luby, Vicisano, Rizzo, Gemmell, Crowcroft, Lueckenhoff [Page 20]
Draft RMT BB, Forward Error Correction Codes 13 July 2000
A. Predefined FEC encoders
This appendix specifies the FEC Encoding Identifier and the relative
packets field for a number of known schemes that follow under the class
of under-specified FEC encoding schemes. Others may be specified in
companion documents.
A.1. Small Block, Large Block and Expandable FEC Codes
This section reserves a FEC Encoding Identifier for the family of codes
described in Section 2.2, 2.3 and 2.4 and specifies the relative packet
fields. Under-specified FEC encoding schemes that belong to this class
MUST use this identifier and packet field definitions.
The FEC Encoding Identifier assigned to Small Block, Large Block, and
Expandable FEC Codes is 128.
The FEC Payload ID is composed of an encoding symbol index and an
encoding block number structured as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| encoding block number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| encoding symbol ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In addition, a one bit FEC Encoding Flag SHOULD be included, and this
flag indicates whether the encoding symbol(s) in the payload of the
packet are source symbol(s) or redundant symbol(s). The FEC Object
Transmission Information has the following structure:
Luby, Vicisano, Rizzo, Gemmell, Crowcroft, Lueckenhoff [Page 21]
Draft RMT BB, Forward Error Correction Codes 13 July 2000
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC Encoding Name | Object Length (MSB) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Object Length (LSB) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Block Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note that this structure limits the range of possible FEC Encoding Names
to 0-:-65536, despite the FEC Object Transmission Information can also
be transmitted out of band.
The Object Length, composed of a Most Significant Bytes portion (MSB)
and a Least Significant Bytes portion (LSB), is expressed in bytes.
Feedback packet MUST contain both FEC Block Identifier and Number of
Repair Symbols. Their structure is the following:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC Block Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Repair Symbols |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
9. Authors' Addresses
Michael Luby
luby@digitalfountain.com
Digital Fountain
600 Alabama Street
San Francisco, CA, USA, 94110
Luby, Vicisano, Rizzo, Gemmell, Crowcroft, Lueckenhoff [Page 22]
Draft RMT BB, Forward Error Correction Codes 13 July 2000
Lorenzo Vicisano
lorenzo@cisco.com
cisco Systems, Inc.
170 West Tasman Dr.,
San Jose, CA, USA, 95134
Luigi Rizzo
luigi@iet.unipi.it
Dip. di Ing. dell'Informazione
Universita` di Pisa
via Diotisalvi 2, 56126 Pisa, Italy
Jim Gemmell
jgemmell@microsoft.com
Microsoft Research
301 Howard St., #830
San Francisco, CA, USA, 94105
Jon Crowcroft
J.Crowcroft@cs.ucl.ac.uk
Department of Computer Science
University College London
Gower Street,
London WC1E 6BT, UK
Bruce Lueckenhoff
brucelu@cadence.com
Cadence Design Systems, Inc.
120 Cremona Drive, Suite C
Santa Barbara, CA 93117
Luby, Vicisano, Rizzo, Gemmell, Crowcroft, Lueckenhoff [Page 23]
Draft RMT BB, Forward Error Correction Codes 13 July 2000
10. Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are included
on all such copies and derivative works. However, this document itself
may not be modified in any way, such as by removing the copyright notice
or references to the Internet Society or other Internet organizations,
except as needed for the purpose of developing Internet standards in
which case the procedures for copyrights defined in the Internet
languages other than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE."
Luby, Vicisano, Rizzo, Gemmell, Crowcroft, Lueckenhoff [Page 24]
Draft RMT BB, Forward Error Correction Codes 13 July 2000
Table of Contents
1 Rationale and Overview .......................................... 2
1.1 Application of FEC codecs ..................................... 4
2 FEC Codes ....................................................... 6
2.1 Simple codes .................................................. 6
2.2 Small block FEC codes ......................................... 7
2.3 Large block FEC codes ......................................... 10
2.4 Expandable FEC codes .......................................... 11
2.5 Source blocks with variable length source symbols ............. 13
3 FEC Abstract Packet Fields and Out-of-Band Information .......... 14
3.1 FEC Encoding Identifier ....................................... 16
3.2 FEC Payload ID and FEC Object Transmission Information ........ 17
4 IANA Considerations ............................................. 17
5 Security Considerations ......................................... 18
6 Intellectual Property Disclosure ................................ 19
7 Acknowledgments ................................................. 19
8 References ...................................................... 19
A. Predefined FEC encoders ....................................... 21
A.1. Small Block, Large Block and Expandable FEC Codes ........... 21
9 Authors' Addresses .............................................. 22
10 Full Copyright Statement ....................................... 24
Luby, Vicisano, Rizzo, Gemmell, Crowcroft, Lueckenhoff [Page 25]
--==_Exmh_924555160--
>From owner-rmt@listserv.lbl.gov Fri Jul 14 23:34:11 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id XAA09546;
Fri, 14 Jul 2000 23:30:57 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id XAA09542
for <rmt@listserv.lbl.gov>; Fri, 14 Jul 2000 23:30:55 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id XAA27631
for <rmt@listserv.lbl.gov>; Fri, 14 Jul 2000 23:30:54 -0700 (PDT)
Received: from hotmail.com (f49.law8.hotmail.com [216.33.241.49])
by SpamWall.lbl.gov (8.9.3/8.9.3) with SMTP id XAA27624
for <rmt@lbl.gov>; Fri, 14 Jul 2000 23:30:53 -0700 (PDT)
Received: (qmail 46957 invoked by uid 0); 15 Jul 2000 06:29:20 -0000
Message-ID: <20000715062920.46956.qmail@hotmail.com>
Received: from 202.141.150.16 by www.hotmail.com with HTTP;
Fri, 14 Jul 2000 23:29:20 PDT
X-Originating-IP: [202.141.150.16]
From: "Danesh Tarapore" <daneshtarapore@hotmail.com>
To: mankin@EAST.ISI.EDU, ark008@email.mot.com, lorenzo@cisco.com, rmt@lbl.gov
Subject: More Info on Multicasting
Date: Sat, 15 Jul 2000 11:59:20 IST
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Sender: owner-rmt@lbl.gov
Precedence: bulk
Respected Sir,
I am a Computer Sc Enginnering student in the final year,studying ina
Goverment Enginnering College in India.
I want to do a project on Multicasting as I have read some of the
whitepapers from ipmulticasting.com and found the topic very intresting.
However as I am new to this field I would need your expert guidance to steer
me through this project.Kindly send me the related URL's and the emails of
some of the people who may be able to help me if you are buzy.
Yours most obediently,
Danesh Tarapore.
________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
>From owner-rmt@listserv.lbl.gov Mon Jul 17 03:44:52 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id DAA14263;
Mon, 17 Jul 2000 03:42:45 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id DAA14259
for <rmt@listserv.lbl.gov>; Mon, 17 Jul 2000 03:42:42 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id DAA10294
for <rmt@listserv.lbl.gov>; Mon, 17 Jul 2000 03:42:41 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id DAA10291
for <rmt@lbl.gov>; Mon, 17 Jul 2000 03:42:40 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26085;
Mon, 17 Jul 2000 06:42:34 -0400 (EDT)
Message-Id: <200007171042.GAA26085@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: rmt@lbl.gov
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-rmt-bb-tree-config-00.txt
Date: Mon, 17 Jul 2000 06:42:34 -0400
Sender: owner-rmt@lbl.gov
Precedence: bulk
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Reliable Multicast Transport Working Group of the IETF.
Title : Reliable Multicast Transport Building Block: Tree
Auto-Configuration
Author(s) : B. Cain, D. Chiu, M. Kadansky, S. Koh,
B. Levine, G. Taskale, B. Whetten
Filename : draft-ietf-rmt-bb-tree-config-00.txt
Pages : 16
Date : 14-Jul-00
The Reliable Multicast Transport Working Group has been chartered to
standardize multicast transport services. This working group expects
to initially standardize three protocol instantiations. This draft is
concerned with the requirements of the tree-based ACK protocol. In
particular, it is concerned with defining the building block for
auto-configuration of the logical ACK-tree. According to the charter,
a building block is 'a coarse-grained modular component that is
common to multiple protocols along with abstract APIs that define a
building block's access methods and their arguments.' For more
information, see the Reliable Multicast Transport Building Blocks and
Reliable Multicast Design Space documents [WLKHFL00][HWKFV00].
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rmt-bb-tree-config-00.txt
Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-rmt-bb-tree-config-00.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.
Send a message to:
mailserv@ietf.org.
In the body type:
"FILE /internet-drafts/draft-ietf-rmt-bb-tree-config-00.txt".
NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv@ietf.org"
Content-Type: text/plain
Content-ID: <20000714143913.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-rmt-bb-tree-config-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-rmt-bb-tree-config-00.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <20000714143913.I-D@ietf.org>
--OtherAccess--
--NextPart--
>From owner-rmt@listserv.lbl.gov Mon Jul 17 07:12:57 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id HAA15353;
Mon, 17 Jul 2000 07:12:35 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id HAA15349
for <rmt@listserv.lbl.gov>; Mon, 17 Jul 2000 07:12:33 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id HAA25211
for <rmt@listserv.lbl.gov>; Mon, 17 Jul 2000 07:12:32 -0700 (PDT)
Received: from poseidon.bwc.state.oh.us ([198.234.212.100])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id HAA25208
for <rmt@lbl.gov>; Mon, 17 Jul 2000 07:12:31 -0700 (PDT)
Received: by poseidon.bwc.state.oh.us; id KAA19466; Mon, 17 Jul 2000 10:10:18 -0400 (EDT)
Received: from venus.bwc.state.oh.us(165.223.131.35) by neptune.bwc.state.oh.us via smap (V5.0)
id xma019434; Mon, 17 Jul 00 10:09:23 -0400
Received: from mswg6.bwc.state.oh.us ([165.223.130.24])
by venus.bwc.state.oh.us (8.9.3/8.9.1) with ESMTP id KAA11819;
Mon, 17 Jul 2000 10:17:01 -0400 (EDT)
Received: by MSWG6 with Internet Mail Service (5.5.2650.21)
id <M0L9AC3G>; Mon, 17 Jul 2000 10:09:21 -0400
Message-ID: <6FDE0867413DD21182BF00A0C972519204C98ACD@MSWG4>
From: "Morrisey Matthew J." <Matthew.Morrisey@bwc.state.oh.us>
To: rmt@lbl.gov
Cc: "'azinin@cisco.com'" <azinin@cisco.com>,
"'myeung@procket.com'"
<myeung@procket.com>
Subject: RE: I-D ACTION:draft-ietf-rmt-author-guidelines-00.txt
Date: Mon, 17 Jul 2000 10:09:15 -0400
X-Mailer: Internet Mail Service (5.5.2650.21)
Sender: owner-rmt@lbl.gov
Precedence: bulk
1. I was confused by section 6 "Deployment Considerations", I couldn't
decide where area zero was. But maybe i'm the only one who couldn't.
2. I was wondering how these implementation behaviours were enabled and
disabled in the respective routers.
Other than that i was delighted to read this draft.
Matt Morrisey
>From owner-rmt@listserv.lbl.gov Mon Jul 17 10:47:45 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id KAA23208;
Mon, 17 Jul 2000 10:47:12 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id KAA23204
for <rmt@listserv.lbl.gov>; Mon, 17 Jul 2000 10:47:10 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id KAA01332
for <rmt@listserv.lbl.gov>; Mon, 17 Jul 2000 10:47:10 -0700 (PDT)
Received: from ce-nfs-1.cisco.com (ce-nfs-1.cisco.com [171.68.202.251])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id KAA01325
for <rmt@lbl.gov>; Mon, 17 Jul 2000 10:47:09 -0700 (PDT)
Received: from dhcp-c2-2-107.cisco.com (dhcp-c2-2-107.cisco.com [171.68.171.107])
by ce-nfs-1.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id KAA06944;
Mon, 17 Jul 2000 10:46:35 -0700 (PDT)
Date: Mon, 17 Jul 2000 10:41:38 -0700
From: Alex Zinin <azinin@cisco.com>
X-Mailer: The Bat! (v1.41) REG'D / CD5BF9353B3B7091
Reply-To: Alex Zinin <azinin@cisco.com>
Organization: Cisco Systems
X-Priority: 3 (Normal)
Message-ID: <10445.000717@cisco.com>
To: "Morrisey Matthew J." <Matthew.Morrisey@bwc.state.oh.us>
CC: rmt@lbl.gov, "'myeung@procket.com'" <myeung@procket.com>
Subject: Re: I-D ACTION:draft-ietf-rmt-author-guidelines-00.txt
In-reply-To: <6FDE0867413DD21182BF00A0C972519204C98ACD@MSWG4>
References: <6FDE0867413DD21182BF00A0C972519204C98ACD@MSWG4>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-rmt@lbl.gov
Precedence: bulk
The subject is a bit misleading, btw :)
It should've been draft-ietf-ospf-abr-alt-02.txt AFAIU.
Answers:
1) We call area 0 a "backbone area"
2) It is rather an implementation detail. Anyway,
I implemented a configuration command in Zebra.
Cisco always uses 'cisco' behavior :)
--
Alex Zinin
Monday, July 17, 2000, 7:09 AM, Morrisey Matthew J. <Matthew.Morrisey@bwc.state.oh.us> wrote:
> 1. I was confused by section 6 "Deployment Considerations", I couldn't
> decide where area zero was. But maybe i'm the only one who couldn't.
> 2. I was wondering how these implementation behaviours were enabled and
> disabled in the respective routers.
> Other than that i was delighted to read this draft.
> Matt Morrisey
>From owner-rmt@listserv.lbl.gov Tue Jul 18 03:36:48 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id DAA02463;
Tue, 18 Jul 2000 03:36:09 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id DAA02459
for <rmt@listserv.lbl.gov>; Tue, 18 Jul 2000 03:36:07 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id DAA02256
for <rmt@listserv.lbl.gov>; Tue, 18 Jul 2000 03:36:07 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id DAA02253
for <rmt@lbl.gov>; Tue, 18 Jul 2000 03:36:06 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14000;
Tue, 18 Jul 2000 06:36:05 -0400 (EDT)
Message-Id: <200007181036.GAA14000@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: rmt@lbl.gov
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-rmt-bb-fec-01.txt
Date: Tue, 18 Jul 2000 06:36:05 -0400
Sender: owner-rmt@lbl.gov
Precedence: bulk
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Reliable Multicast Transport Working Group of the IETF.
Title : Reliable Multicast Transport Building Block: Forward
Error Correction Codes
Author(s) : M. Luby, L. Rizzo, J. Gemmell, J. Crowcroft,
B. Lueckenhoff
Filename : draft-ietf-rmt-bb-fec-01.txt
Pages : 25
Date : 17-Jul-00
This memo describes the use of Forward Error Correction (FEC) codes
within the context of reliable IP multicast transport and provides an
introduction to some commonly-used FEC codes.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rmt-bb-fec-01.txt
Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-rmt-bb-fec-01.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.
Send a message to:
mailserv@ietf.org.
In the body type:
"FILE /internet-drafts/draft-ietf-rmt-bb-fec-01.txt".
NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv@ietf.org"
Content-Type: text/plain
Content-ID: <20000717150054.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-rmt-bb-fec-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-rmt-bb-fec-01.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <20000717150054.I-D@ietf.org>
--OtherAccess--
--NextPart--
>From owner-rmt@listserv.lbl.gov Tue Jul 18 03:36:48 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id DAA02457;
Tue, 18 Jul 2000 03:36:05 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id DAA02453
for <rmt@listserv.lbl.gov>; Tue, 18 Jul 2000 03:36:02 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id DAA02249
for <rmt@listserv.lbl.gov>; Tue, 18 Jul 2000 03:36:02 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id DAA02245
for <rmt@lbl.gov>; Tue, 18 Jul 2000 03:36:01 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13950;
Tue, 18 Jul 2000 06:36:00 -0400 (EDT)
Message-Id: <200007181036.GAA13950@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: rmt@lbl.gov
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-rmt-pi-alc-01.txt
Date: Tue, 18 Jul 2000 06:36:00 -0400
Sender: owner-rmt@lbl.gov
Precedence: bulk
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Reliable Multicast Transport Working Group of the IETF.
Title : Asynchronous Layered Coding A scalable reliable
multicast protocol
Author(s) : M. Luby, J. Gemmell
Filename : draft-ietf-rmt-pi-alc-01.txt
Pages : 39
Date : 17-Jul-00
This document describes Asynchronous Layered Coding, a massively
scalable reliable multicast protocol, hereafter referred to as ALC.
ALC can be used to reliably deliver content to multiple receivers. The
content can be any well-defined object. Examples include any type of
file such as a group of pictures in an MPEG stream, a MP3 music file, a
JPEG image, and a collection of files that are archived into one file.
In addition, the delivery service model that can be provided with ALC is
fairly flexible, e.g., an on demand service model and a push service
model. A session is initiated by a single sender to transmit packets
that contain data about a particular object. Receivers may join or
leave an existing session in an asynchronous manner independent of other
receivers
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rmt-pi-alc-01.txt
Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-rmt-pi-alc-01.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.
Send a message to:
mailserv@ietf.org.
In the body type:
"FILE /internet-drafts/draft-ietf-rmt-pi-alc-01.txt".
NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv@ietf.org"
Content-Type: text/plain
Content-ID: <20000717150045.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-rmt-pi-alc-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-rmt-pi-alc-01.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <20000717150045.I-D@ietf.org>
--OtherAccess--
--NextPart--
>From owner-rmt@listserv.lbl.gov Tue Jul 18 11:57:57 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id LAA05988;
Tue, 18 Jul 2000 11:56:40 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id LAA05984
for <rmt@listserv.lbl.gov>; Tue, 18 Jul 2000 11:56:38 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id LAA27900
for <rmt@listserv.lbl.gov>; Tue, 18 Jul 2000 11:56:38 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id LAA27881
for <rmt@lbl.gov>; Tue, 18 Jul 2000 11:56:37 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16675;
Tue, 18 Jul 2000 14:56:35 -0400 (EDT)
Message-Id: <200007181856.OAA16675@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: rmt@lbl.gov
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-rmt-bb-fec-01.txt
Date: Tue, 18 Jul 2000 14:56:34 -0400
Sender: owner-rmt@lbl.gov
Precedence: bulk
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Reliable Multicast Transport Working Group of the IETF.
Title : Reliable Multicast Transport Building Block: Forward
Error Correction Codes
Author(s) : M. Luby, L. Vicisano, L. Rizzo, J. Gemmell,
J. Crowcroft, B. Lueckenhoff
Filename : draft-ietf-rmt-bb-fec-01.txt
Pages : 25
Date : 17-Jul-00
This memo describes the use of Forward Error Correction (FEC) codes
within the context of reliable IP multicast transport and provides an
introduction to some commonly-used FEC codes.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rmt-bb-fec-01.txt
Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-rmt-bb-fec-01.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.
Send a message to:
mailserv@ietf.org.
In the body type:
"FILE /internet-drafts/draft-ietf-rmt-bb-fec-01.txt".
NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv@ietf.org"
Content-Type: text/plain
Content-ID: <20000717150054.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-rmt-bb-fec-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-rmt-bb-fec-01.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <20000717150054.I-D@ietf.org>
--OtherAccess--
--NextPart--
>From owner-rmt@listserv.lbl.gov Tue Jul 18 11:57:57 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id LAA05980;
Tue, 18 Jul 2000 11:56:34 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id LAA05976
for <rmt@listserv.lbl.gov>; Tue, 18 Jul 2000 11:56:32 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id LAA27841
for <rmt@listserv.lbl.gov>; Tue, 18 Jul 2000 11:56:32 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id LAA27834
for <rmt@lbl.gov>; Tue, 18 Jul 2000 11:56:31 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16607;
Tue, 18 Jul 2000 14:56:29 -0400 (EDT)
Message-Id: <200007181856.OAA16607@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: rmt@lbl.gov
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-rmt-pi-alc-01.txt
Date: Tue, 18 Jul 2000 14:56:29 -0400
Sender: owner-rmt@lbl.gov
Precedence: bulk
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Reliable Multicast Transport Working Group of the IETF.
Title : Asynchronous Layered Coding A scalable reliable
multicast protocol
Author(s) : M. Luby, J. Gemmell, L. Vicisano, L. Rizzo,
J.Crowcroft, B. Lueckenhoff
Filename : draft-ietf-rmt-pi-alc-01.txt
Pages : 39
Date : 17-Jul-00
This document describes Asynchronous Layered Coding, a massively
scalable reliable multicast protocol, hereafter referred to as ALC.
ALC can be used to reliably deliver content to multiple receivers. The
content can be any well-defined object. Examples include any type of
file such as a group of pictures in an MPEG stream, a MP3 music file, a
JPEG image, and a collection of files that are archived into one file.
In addition, the delivery service model that can be provided with ALC is
fairly flexible, e.g., an on demand service model and a push service
model. A session is initiated by a single sender to transmit packets
that contain data about a particular object. Receivers may join or
leave an existing session in an asynchronous manner independent of other
receivers
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rmt-pi-alc-01.txt
Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-rmt-pi-alc-01.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.
Send a message to:
mailserv@ietf.org.
In the body type:
"FILE /internet-drafts/draft-ietf-rmt-pi-alc-01.txt".
NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv@ietf.org"
Content-Type: text/plain
Content-ID: <20000717150045.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-rmt-pi-alc-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-rmt-pi-alc-01.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <20000717150045.I-D@ietf.org>
--OtherAccess--
--NextPart--
>From owner-rmt@listserv.lbl.gov Wed Jul 19 03:37:24 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id DAA09307;
Wed, 19 Jul 2000 03:35:40 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id DAA09303
for <rmt@listserv.lbl.gov>; Wed, 19 Jul 2000 03:35:37 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id DAA03117
for <rmt@listserv.lbl.gov>; Wed, 19 Jul 2000 03:35:36 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id DAA03114
for <rmt@lbl.gov>; Wed, 19 Jul 2000 03:35:36 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21526;
Wed, 19 Jul 2000 06:35:35 -0400 (EDT)
Message-Id: <200007191035.GAA21526@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: rmt@lbl.gov
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-rmt-bb-mrcc-00.txt
Date: Wed, 19 Jul 2000 06:35:35 -0400
Sender: owner-rmt@lbl.gov
Precedence: bulk
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Reliable Multicast Transport Working Group of the IETF.
Title : Reliable Multicast Transport Building Block: Multirate
Congestion Control
Author(s) : M. Luby, J. Gemmell, A. Haken
Filename : draft-ietf-rmt-bb-mrcc-00.txt
Pages : 20
Date : 18-Jul-00
This document describes MRCC, a scalable multirate congestion control
building block for multicast. MRCC is an approach that allows multiple
receivers to concurrently receive packets from a single sender at vary-
ing rates depending on individual bandwidth connections and network con-
ditions. Two basic goals of the approach are to allow each receiver to
obtain the full benefit of the available bandwidth to the sender and to
be fair to other flows in the network.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rmt-bb-mrcc-00.txt
Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-rmt-bb-mrcc-00.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.
Send a message to:
mailserv@ietf.org.
In the body type:
"FILE /internet-drafts/draft-ietf-rmt-bb-mrcc-00.txt".
NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv@ietf.org"
Content-Type: text/plain
Content-ID: <20000718140656.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-rmt-bb-mrcc-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-rmt-bb-mrcc-00.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <20000718140656.I-D@ietf.org>
--OtherAccess--
--NextPart--
>From owner-rmt@listserv.lbl.gov Thu Jul 20 03:53:23 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id DAA12747;
Thu, 20 Jul 2000 03:47:56 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id DAA12743
for <rmt@listserv.lbl.gov>; Thu, 20 Jul 2000 03:47:54 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id DAA23460
for <rmt@listserv.lbl.gov>; Thu, 20 Jul 2000 03:47:53 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id DAA23457
for <rmt@lbl.gov>; Thu, 20 Jul 2000 03:47:53 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12658;
Thu, 20 Jul 2000 06:47:51 -0400 (EDT)
Message-Id: <200007201047.GAA12658@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: rmt@lbl.gov
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-rmt-bb-mrcc-00.txt
Date: Thu, 20 Jul 2000 06:47:51 -0400
Sender: owner-rmt@lbl.gov
Precedence: bulk
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Reliable Multicast Transport Working Group of the IETF.
Title : Reliable Multicast Transport Building Block:
Multirate Congestion Control
Author(s) : M. Luby, L. Vicisano, A. Haken
Filename : draft-ietf-rmt-bb-mrcc-00.txt
Pages : 20
Date : 18-Jul-00
This document describes MRCC, a scalable multirate congestion control
building block for multicast. MRCC is an approach that allows multiple
receivers to concurrently receive packets from a single sender at vary-
ing rates depending on individual bandwidth connections and network con-
ditions. Two basic goals of the approach are to allow each receiver to
obtain the full benefit of the available bandwidth to the sender and to
be fair to other flows in the network.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rmt-bb-mrcc-00.txt
Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-rmt-bb-mrcc-00.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.
Send a message to:
mailserv@ietf.org.
In the body type:
"FILE /internet-drafts/draft-ietf-rmt-bb-mrcc-00.txt".
NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv@ietf.org"
Content-Type: text/plain
Content-ID: <20000719151429.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-rmt-bb-mrcc-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-rmt-bb-mrcc-00.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <20000719151429.I-D@ietf.org>
--OtherAccess--
--NextPart--
>From owner-rmt@listserv.lbl.gov Thu Jul 20 08:27:01 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id IAA14126;
Thu, 20 Jul 2000 08:26:37 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id IAA14122
for <rmt@listserv.lbl.gov>; Thu, 20 Jul 2000 08:26:35 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id IAA24100
for <rmt@listserv.lbl.gov>; Thu, 20 Jul 2000 08:26:34 -0700 (PDT)
Received: from mail.monisys.ca (mail.monisys.ca [204.225.249.10])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id IAA24083;
Thu, 20 Jul 2000 08:26:30 -0700 (PDT)
Received: from mailcity.com (ts1-044.wnpg.ca.ziplink.net [165.154.32.44])
by mail.monisys.ca (8.9.3/8.9.3) with SMTP id LAA09925;
Thu, 20 Jul 2000 11:35:39 -0400
Date: Thu, 20 Jul 2000 11:35:39 -0400
Message-Id: <200007201535.LAA09925@mail.monisys.ca>
X-Mailer: Sent with E-Mail Magnet Version 4.3
From: secrets47@lycos.com
Subject: God bless YOU as WE are in the NEXT Millennium!
MIME-Version: 1.0
Content-Type: text/html; charset=us-ascii
Sender: owner-rmt@lbl.gov
Precedence: bulk
<HTML>
<HEAD>
<TITLE>Online Fantasy Media for a healthy future</TITLE>
<STYLE fprolloverstyle>A:hover {
COLOR: red; FONT-FAMILY: Verdana; FONT-SIZE: 12pt; FONT-STYLE: italic;
TEXT-DECORATION: underline
}
</STYLE>
</HEAD>
<body background="http://members.infomak.com/gem3style/skyback2.gif"
TEXT="#000000" LINK="#0000FF" VLINK="#0000FF">
<font face="Arial">
<BR>
<i>
Dear Web site Owner<BR>
<BR>
I am writing to you to inquire if you would<BR>
be interested in me helping you get a taste<BR>
for New Innovations. Your web site is very<BR>
informative and very interesting. I know <BR>
customers who would be extremely interested<BR>
in your products and services. This powerful<BR>
idea was designed for Large Companies, but<BR>
now others are using it.<BR>
<BR>
This is a Wonderful Idea that was featured in<BR>
<U>The Wall Street Journal</U>, <U>The New York Times</U><BR>
and all the other cutting edge publications!<BR>
Our Company values helping web site owners.<BR>
We want to help you grow and to also improve<BR>
your quality of life in every way we can.<BR>
<BR>
So Please scroll down for more information to get<BR>
started today!<BR>
<BR>
I'll be looking forward to hearing from you<BR>
soon! Thank You!<BR>
<BR>
Sincerely,<BR>
<B>Kaizee Anderson</B><BR>
CEO of <B>Fantasy Media 2000</B> <BR>
</i>
<BR>
<BR>
<center>
<font size=25>Fantasy Media 2000</font>
<br>
<b><i>Helping Large companies become Larger<br>
& small businesses into large corporations.</i></b>
<img src="http://gemini3.vr9.com/gembar1.jpg">
<br>
<br>
<b>The Next Revolution</b>, The Next Solution! Be part of this
phenomenon.<br>
Our Focus is to <b>improve</b> <u>your quality of life</u> in every way we
can...
<br>
<br>
YOUR Journey begins Here!<a href="http://members.infomak.com/start">Click
Here</a>
<br>
<br>
<b>Many large companies</b> are spending too much money on<br>
Banner Ads & Search Engines with mostly bellow average<br>
results. We are here to <u>save you money</u> at the same<br>
time <u>give you much better results</u> than search<br>
engines & banner ads. You'll be Amazed!<br>
<br>
This might <b>sound unbelievable,</b> but there are large<br>
companies out there that spend over $1,000,000 dollars<br>
a day on banner ads with 1% to 2% click through<br>
response, and that's just half the battle, customers<br>
still need to make the purchase. This could mean<br>
a tremendous lost to their Investment!!!<br>
<br>
However if you were to do the same with <b>Opt-in<br>
Emails</b>, you will more than quadruple "Your Investment".<br>
<br>
The Best Way is through <b>Opt-in Email.</b> These people<br>
in Opt-in emails will be more than happy to here<br>
from you! This is by far the most <u>Powerful Direct Response<br>
Marketing Idea</u> Ever. This is one concept the<br>
<b>Fortune 500 Companies</b> are realizing as being lucrative<br>
<br>
<a href="http://members.infomak.com/companies">Click Here</a> to see the
Types of companies that benefits from it!
<br>
<br>
<b>Marketers have generated response rates</b>
as high as 5%<br> to 15%
and sales as great as $50,000 in a single day.<br>
It doesn't matter if you're a <u><i>small business</i></u> or<br>
a <u><i>large corporation</i></u>, you will get the same results.<br>
After you sign up you will get a confirmation in<br>
your email to rent lists of over 1.2 million people<br> who are ready to
buy any product or service<br>
that you are selling. <i>WARNING!</i><br> The results could be
staggering!!!<br>
<br>
<a
href="http://signup.postmasterdirect.com/affiliates?owner=NetCent_Communicat
ions&affiliate=kaizee">
<img src="http://gfx.postmasterdirect.com/gfx/banners/list468x60_5.gif"
height="60" width="468" border=0>
</a>
<br>
<br>
<b>Fantasy Media 2000 & Gemini3Style,</b> This is <b>TOP SECRET!</b><br>
So you wouldn't find this FREE Offer anywhere else<br>
You wouldn't find us anywhere else, you wouldn't find<br>
us on any <u>Online Classifieds</u>, <u>Search Engines</u>, <u>Banner
Ads</u>,<br>
<u>Newsgroups</u> or anywhere else on the Internet.<br>
So if you're one of those LUCKY people that found us through<br>
your email, consider this your only <b>opportunity of
a life time</b><br>
to bring <u>your business</u> to the next level, you'll be amazed!<br>
<br>
<a href="http://hop.clickbank.net/hop.cgi?kaizee/ccross">Place Your tiny
Classified Ads</a>
<br>
<br>
<img src="http://gemini3.vr9.com/gembar1.jpg">
<br>
<br>
<b>"MailLoop"</b> learn more about this powerful software!<a
href="http://members.infomak.com/mailloop">Click Here!</a>
<br>
<br>
</center>
<BR>
<br>
<center>
<br>
<address>
<a href="mailto:kaizee@excite.com"><h4>E-mail Us</h4></a>
</adress>
<br>
<b><u>PO Box 68014</u> rpo
Osborne Village<br>
Winnipeg, Manitoba,
Canada, r3l 2v9</b>
<br>
<br>
<A HREF="http://counter.xoom.com/xc-cgi/map1/93080">
<IMG SRC="http://counter.xoom.com/xc-cgi/counter.gif?93080" BORDER=0
ISMAP></A>
<p><h5>Fantasy Media 2000 Copyright 1999-2000 All rights reserved</h5>
</center>
</font>
</BODY>
</HTML>
>From owner-rmt@listserv.lbl.gov Fri Jul 21 00:06:13 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id AAA17521;
Fri, 21 Jul 2000 00:03:51 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id AAA17517
for <rmt@listserv.lbl.gov>; Fri, 21 Jul 2000 00:03:50 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id AAA02222
for <rmt@listserv.lbl.gov>; Fri, 21 Jul 2000 00:03:49 -0700 (PDT)
Received: from daffy.ee.lbl.gov (daffy.ee.lbl.gov [131.243.1.31])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id AAA02219
for <rmt@lbl.gov>; Fri, 21 Jul 2000 00:03:49 -0700 (PDT)
Received: (from vern@localhost)
by daffy.ee.lbl.gov (8.10.0/8.10.0) id e6L73mX13156;
Fri, 21 Jul 2000 00:03:48 -0700 (PDT)
Message-Id: <200007210703.e6L73mX13156@daffy.ee.lbl.gov>
To: rmt@lbl.gov
Subject: you may be deleted from rmt@lbl.gov - please read!
Date: Fri, 21 Jul 2000 00:03:48 PDT
From: Vern Paxson <vern@ee.lbl.gov>
Sender: owner-rmt@lbl.gov
Precedence: bulk
I have been getting repeated bounces from the following addresses for the
RMT mailing list rmt@lbl.gov:
Joseph.Wesley@east.sun.com
Paul.G.Mallasch@grc.nasa.gov
aconta@lucent.com
bcain@nortelnetworks.com
bkumar@glenvan.glenayre.com
bohallor@fore.com
chris@novedia.de
gvjohn@miel.mot.com
jr1734@yahoo.com
lillie@rsch.comm.mot.com
mmichel@bbt.com
murchiso@newbridge.com
philip@newbridge.com
rrt@research.bellcore.com
sanjoy@dnrc.bell-labs.com
senaka@rsch.comm.mot.com
sergeh@nortelnetworks.com
thardjon@nortelnetworks.com
yzhu@us.ibm.com
zbecka@newbridge.com
I plan to delete these addresses in a week or so unless I hear from back
that particular addresses should be kept or changed.
Your RMT list maintainer,
Vern
>From owner-rmt@listserv.lbl.gov Sun Jul 23 16:46:25 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id QAA24751;
Sun, 23 Jul 2000 16:42:54 -0700 (PDT)
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id QAA24747
for <rmt@listserv.lbl.gov>; Sun, 23 Jul 2000 16:42:52 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id QAA14663
for <rmt@listserv.lbl.gov>; Sun, 23 Jul 2000 16:42:51 -0700 (PDT)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id QAA14660
for <rmt@lbl.gov>; Sun, 23 Jul 2000 16:42:51 -0700 (PDT)
Received: from lorenzo-u10.cisco.com (lorenzo-u10.cisco.com [171.69.65.85])
by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id QAA13710
for <rmt@lbl.gov>; Sun, 23 Jul 2000 16:42:36 -0700 (PDT)
Received: from localhost (lorenzo@localhost) by lorenzo-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id QAA09022 for <rmt@lbl.gov>; Sun, 23 Jul 2000 16:42:21 -0700 (PDT)
Message-Id: <200007232342.QAA09022@lorenzo-u10.cisco.com>
X-Authentication-Warning: lorenzo-u10.cisco.com: lorenzo owned process doing -bs
X-Mailer: exmh version 2.0.2 2/24/98
To: rmt@lbl.gov
Subject: Proposed meeting agenda
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <9017.964395740.1@cisco.com>
Date: Sun, 23 Jul 2000 16:42:20 -0700
From: Lorenzo Vicisano <lorenzo@cisco.com>
Sender: owner-rmt@lbl.gov
Precedence: bulk
Dear all,
This is the proposed agenda.
If we have left anything out, please let us know. This is to
be submitted by Monday, 17:00 ET, but we can still change it
informally later.
Due to the tight schedule some of the slots might be shorter than
requested, please try to limit the presentation to the key points
and leave time for discussion.
thanks,
the WG chairs.
##
48th IETF - Pittsburgh, PA, USA
Reliable Multicast Transport WG, Meeting Agenda.
- agenda bashing 5 mins
- guidelines draft 10 mins
- Tree-Building BB 25 mins
- Track arch, PI and security 35 mins
- FEC BB 15 mims
- ALC PI 15 mins
- MRCC BB 30 mins
- discussion 15 mins
Possible topics for discussion are:
- draft-ietf-rmt-buildingblocks-02.txt status
- NORM status (no submissions nor presentations in agenda)
- what's done and what's left
>From owner-rmt@listserv.lbl.gov Mon Jul 24 03:41:38 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id DAA25706;
Mon, 24 Jul 2000 03:38:19 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id DAA25702
for <rmt@listserv.lbl.gov>; Mon, 24 Jul 2000 03:38:17 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id DAA21127
for <rmt@listserv.lbl.gov>; Mon, 24 Jul 2000 03:38:17 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id DAA21124
for <rmt@lbl.gov>; Mon, 24 Jul 2000 03:38:16 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09161;
Mon, 24 Jul 2000 06:38:15 -0400 (EDT)
Message-Id: <200007241038.GAA09161@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: rmt@lbl.gov
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-rmt-track-arch-00.txt
Date: Mon, 24 Jul 2000 06:38:15 -0400
Sender: owner-rmt@lbl.gov
Precedence: bulk
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Reliable Multicast Transport Working Group of the IETF.
Title : TRACK ARCHITECTURE A SCALEABLE REAL-TIME RELIABLE
MULTICAST PROTOCOL
Author(s) : B. Whetten, D. Chiu, S. Paul, M. Kadansky, G. Taskale
Filename : draft-ietf-rmt-track-arch-00.txt
Pages :
Date : 21-Jul-00
One of the protocol instantiations the RMT WG is chartered to create is a TRee-based ACKnowledgement protocol (TRACK). Rather than create a set of monolithic protocol specifications, the RMT WG has chosen to break the reliable multicast protocols in to Building Blocks (BB) and Protocol
Instantiations (PI). A Building Block is a specification of the algorithms of a single component, with an abstract interface to other BBs and PIs. A PI combines a set of BBs, adds in the additional required functionality not specified in any BB, and specifies the specific instantiation of the protocol. For more information, see the Reliable Multicast Transport Building Blocks and Reliable Multicast Design Space documents [2][3].
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rmt-track-arch-00.txt
Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-rmt-track-arch-00.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.
Send a message to:
mailserv@ietf.org.
In the body type:
"FILE /internet-drafts/draft-ietf-rmt-track-arch-00.txt".
NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv@ietf.org"
Content-Type: text/plain
Content-ID: <20000721172539.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-rmt-track-arch-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-rmt-track-arch-00.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <20000721172539.I-D@ietf.org>
--OtherAccess--
--NextPart--
>From owner-rmt@listserv.lbl.gov Mon Jul 24 03:41:46 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id DAA25700;
Mon, 24 Jul 2000 03:38:15 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id DAA25696
for <rmt@listserv.lbl.gov>; Mon, 24 Jul 2000 03:38:13 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id DAA21118
for <rmt@listserv.lbl.gov>; Mon, 24 Jul 2000 03:38:12 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id DAA21115
for <rmt@lbl.gov>; Mon, 24 Jul 2000 03:38:12 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09149;
Mon, 24 Jul 2000 06:38:11 -0400 (EDT)
Message-Id: <200007241038.GAA09149@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: rmt@lbl.gov
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-rmt-pi-track-security-00.txt
Date: Mon, 24 Jul 2000 06:38:10 -0400
Sender: owner-rmt@lbl.gov
Precedence: bulk
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Reliable Multicast Transport Working Group of the IETF.
Title : Security Requirements For TRACK
Author(s) : T. Hardjono, B. Whetten
Filename : draft-ietf-rmt-pi-track-security-00.txt
Pages :
Date : 21-Jul-00
This document discusses the security issues within the TRee-based
ACKnowledgement (TRACK) reliable multicast protocol instantiation, and
identifies some constraints and requirements for security provisions for
this protocol. Based on the constraints and requirements, the document
proposes a separation of data packet confidentiality and authentication,
from transport layer protection. It proposes that TRACK be primarily
concerned with group authentication of control and data packets, to
protect against attacks on the transport infrastructure. It proposes
that data confidentiality and source authentication be provided
separately from this low level group authentication, ideally at the
application level. We show that this is particularly important for
TRACK, because of the requirement that the interior control nodes only
OPTIONALLY have access to the data packet payload.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rmt-pi-track-security-00.txt
Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-rmt-pi-track-security-00.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.
Send a message to:
mailserv@ietf.org.
In the body type:
"FILE /internet-drafts/draft-ietf-rmt-pi-track-security-00.txt".
NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv@ietf.org"
Content-Type: text/plain
Content-ID: <20000721172527.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-rmt-pi-track-security-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-rmt-pi-track-security-00.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <20000721172527.I-D@ietf.org>
--OtherAccess--
--NextPart--
>From owner-rmt@listserv.lbl.gov Mon Jul 24 06:21:12 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id GAA26676;
Mon, 24 Jul 2000 06:17:59 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id GAA26672
for <rmt@listserv.lbl.gov>; Mon, 24 Jul 2000 06:17:57 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id GAA02400
for <rmt@listserv.lbl.gov>; Mon, 24 Jul 2000 06:17:56 -0700 (PDT)
Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id GAA02396
for <rmt@lbl.gov>; Mon, 24 Jul 2000 06:17:55 -0700 (PDT)
Received: from [132.250.92.151] (manimac.itd.nrl.navy.mil [132.250.92.151])
by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id JAA23558;
Mon, 24 Jul 2000 09:18:05 -0400 (EDT)
Mime-Version: 1.0
X-Sender: adamson@pop.itd.nrl.navy.mil
Message-Id: <v04210101b5a1f1b93a67@[132.250.92.151]>
In-Reply-To: <200007232342.QAA09022@lorenzo-u10.cisco.com>
References: <200007232342.QAA09022@lorenzo-u10.cisco.com>
Date: Mon, 24 Jul 2000 09:17:51 -0400
To: Lorenzo Vicisano <lorenzo@cisco.com>
From: Brian Adamson <adamson@itd.nrl.navy.mil>
Subject: Re: Proposed meeting agenda
Cc: rmt@lbl.gov
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-rmt@lbl.gov
Precedence: bulk
Lorenzo, Roger,
I have an updated version of the NORM BB draft but I missed the
submission deadline. The updated version contains more algorithmic
details on NACK suppression backoffs and other areas which were less
complete in the last version. With the WG chairs' permission, I will
post it to the mailing list and provide an brief overview of the
update at the meeting ...
best regards,
Brian Adamson
At 4:42 PM -0700 7/23/00, Lorenzo Vicisano wrote:
>Dear all,
>
>This is the proposed agenda.
>
>If we have left anything out, please let us know. This is to
>be submitted by Monday, 17:00 ET, but we can still change it
>informally later.
>
>Due to the tight schedule some of the slots might be shorter than
>requested, please try to limit the presentation to the key points
>and leave time for discussion.
>
> thanks,
> the WG chairs.
>
>##
>
>48th IETF - Pittsburgh, PA, USA
>Reliable Multicast Transport WG, Meeting Agenda.
>
> - agenda bashing 5 mins
> - guidelines draft 10 mins
> - Tree-Building BB 25 mins
> - Track arch, PI and security 35 mins
> - FEC BB 15 mims
> - ALC PI 15 mins
> - MRCC BB 30 mins
> - discussion 15 mins
>
>Possible topics for discussion are:
>
> - draft-ietf-rmt-buildingblocks-02.txt status
> - NORM status (no submissions nor presentations in agenda)
> - what's done and what's left
Brian
__________________________________
Brian Adamson
<http://manimac.itd.nrl.navy.mil>
<mailto:adamson@itd.nrl.navy.mil>
>From owner-rmt@listserv.lbl.gov Mon Jul 24 08:25:13 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id IAA27152;
Mon, 24 Jul 2000 08:23:04 -0700 (PDT)
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id IAA27148
for <rmt@listserv.lbl.gov>; Mon, 24 Jul 2000 08:23:02 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id IAA22557
for <rmt@listserv.lbl.gov>; Mon, 24 Jul 2000 08:23:01 -0700 (PDT)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id IAA22554
for <rmt@lbl.gov>; Mon, 24 Jul 2000 08:23:01 -0700 (PDT)
Received: from lorenzo-u10.cisco.com (lorenzo-u10.cisco.com [171.69.65.85])
by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id IAA24467;
Mon, 24 Jul 2000 08:22:45 -0700 (PDT)
Received: from localhost (lorenzo@localhost) by lorenzo-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id IAA11635; Mon, 24 Jul 2000 08:22:30 -0700 (PDT)
Message-Id: <200007241522.IAA11635@lorenzo-u10.cisco.com>
X-Authentication-Warning: lorenzo-u10.cisco.com: lorenzo owned process doing -bs
X-Mailer: exmh version 2.0.2 2/24/98
To: Brian Adamson <adamson@itd.nrl.navy.mil>
cc: rmt@lbl.gov
Subject: Re: Proposed meeting agenda
In-Reply-To: Your message of "Mon, 24 Jul 2000 09:17:51 EDT."
<v04210101b5a1f1b93a67@[132.250.92.151]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 24 Jul 2000 08:22:30 -0700
From: Lorenzo Vicisano <lorenzo@cisco.com>
Sender: owner-rmt@lbl.gov
Precedence: bulk
> I have an updated version of the NORM BB draft but I missed the
> submission deadline. The updated version contains more algorithmic
> details on NACK suppression backoffs and other areas which were less
> complete in the last version. With the WG chairs' permission, I will
> post it to the mailing list and provide an brief overview of the
> update at the meeting ...
Brian, please go ahead, we will reserve a short presentation
slot for you.
Lorenzo
>From owner-rmt@listserv.lbl.gov Wed Jul 26 11:05:03 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id LAA07206;
Wed, 26 Jul 2000 11:02:34 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id LAA07202
for <rmt@listserv.lbl.gov>; Wed, 26 Jul 2000 11:02:33 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id LAA26119
for <rmt@listserv.lbl.gov>; Wed, 26 Jul 2000 11:02:32 -0700 (PDT)
Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id LAA26110
for <rmt@lbl.gov>; Wed, 26 Jul 2000 11:02:30 -0700 (PDT)
Received: from [132.250.92.151] (manimac.itd.nrl.navy.mil [132.250.92.151])
by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id OAA08191
for <rmt@lbl.gov>; Wed, 26 Jul 2000 14:02:30 -0400 (EDT)
Mime-Version: 1.0
X-Sender: adamson@pop.itd.nrl.navy.mil
Message-Id: <v0421010db5a4d716efc4@[132.250.92.151]>
In-Reply-To: <200007241522.IAA11635@lorenzo-u10.cisco.com>
References: <200007241522.IAA11635@lorenzo-u10.cisco.com>
Date: Wed, 26 Jul 2000 14:02:27 -0400
To: rmt@lbl.gov
From: Brian Adamson <adamson@itd.nrl.navy.mil>
Subject: NORM Building Block draft
Content-Type: multipart/mixed; boundary="============_-1247487947==_============"
Sender: owner-rmt@lbl.gov
Precedence: bulk
--============_-1247487947==_============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Attached (text file) is the latest cut of the NORM Building Block
draft (finally!). I apologize for not meeting the submission cutoff.
I will provide an overview of the changes that have been made since
last time. I look forward to the working groups comments and inputs.
Let me know if anyone has any problems with the file. .
best regards,
Brian Adamson
At 8:22 AM -0700 7/24/00, Lorenzo Vicisano wrote:
>
> > I have an updated version of the NORM BB draft but I missed the
> > submission deadline. The updated version contains more algorithmic
> > details on NACK suppression backoffs and other areas which were less
> > complete in the last version. With the WG chairs' permission, I will
> > post it to the mailing list and provide an brief overview of the
> > update at the meeting ...
>
>Brian, please go ahead, we will reserve a short presentation
>slot for you.
>
> Lorenzo
--============_-1247487947==_============
Content-Id: <v0421010db5a4d716efc4@[132.250.92.151].0.0>
Content-Type: text/plain; name="draft-ietf-rmt-norm-bb-01.txt"; charset="us-ascii"
Content-Disposition: attachment; filename="draft-ietf-rmt-norm-bb-01.txt"
; modification-date="Wed, 26 Jul 2000 13:52:21 -0400"
RMT Working Group B. Adamson/Newlink
INTERNET-DRAFT C. Bormann/Tellique
draft-ietf-rmt-norm-bb-01.txt S. Floyd/ACIRI
Expires: January 2001 M. Handley/ACIRI
J. Macker/NRL
July 2000
NACK-Oriented Reliable Multicast (NORM) Protocol Building Blocks
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other docu-
ments at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (1999). All Rights Reserved.
Abstract
This memo describes issues related to the creation of negative-
acknowledgment (NACK) oriented reliable multicast (NORM) protocols.
The general goals and assumptions for NORM are defined. The tech-
nical challenges related to NACK-oriented (and in some cases gen-
eral) reliable multicast protocol design are identified. These
challenges are resolved into a set of applicable "building blocks"
which are described in further detail. It is anticipated that
these building blocks (as they are further refined and defined in
future revisions of this document) will be useful in generating
Adamson, Bormann, et al. Expires January 2001 [Page 1]
Internet Draft NORM Building Blocks July 2000
different instantiations of reliable multicast protocols.
1.0 Background
Reliable multicast transport is a desirable technology for the
efficient and reliable distribution of data to a group on the
Internet. The complexities of group communication paradigms neces-
sitate different protocol types and instantiations to meet the
range of performance and scalability requirements of different
potential reliable multicast applications and users [Mankin98].
Properly designed negative-acknowledgement (NACK) oriented reliable
multicast (NORM) protocols offer scalability advantages for appli-
cations and/or network topologies where, for various reasons, it
is prohibitive to construct a higher order delivery infrastructure
above the basic Layer 3 IP multicast service (e.g. unicast or
hybrid unicast/multicast data distribution trees). Additionally,
the scalability property of NACK-oriented protocols [Pingali93,
Levine96] may be applicable where broad "fanout" is expected for a
single network hop (e.g. cable-TV data delivery, satellite, or
other broadcast communication communication services). Further-
more, the simplicity of a protocol based on "flat" group-wide mul-
ticast distribution may offer advantages for a broad range of dis-
tributed services or dynamic networks and applications.
While different protocol instantiations may be required to meet
specific application and network architecture demands [Clark90],
there are a number of fundamental components which may be common to
these different instantiations. This document describes the frame-
work and common "building block" components relevant to multicast
protocols based primarily on NACK operation for reliable transport.
2.0 Applicability
Each potential protocol instantiation using the building blocks
presented here (and other applicable building block documents) will
have specific criteria which will influence individual protocol
design. To support the development of applicable building blocks,
it is useful to identify and summarize driving general protocol
design goals and assumptions. These are areas which each protocol
instantiation will need to address in detail. Each building block
description in this document will include a discussion of the
impact of these design criteria. The categories of design criteria
considered here include:
1) Data content model
2) Group membership dynamics
3) Sender/receiver relationships
4) Group size
Adamson, Bormann, et al. Expires January 2001 [Page 2]
Internet Draft NORM Building Blocks July 2000
5) Data delivery performance
6) Network topology
3) Router/intermediate system assistance
In some cases, a building block may be designed to address a wide
range of assumptions while in other cases there will be trade-offs
required to meet different application needs. Where necessary,
building block features will designed to be parametric to meet dif-
ferent requirements. Of course, an underlying goal will be to min-
imize design complexity and to at least recommend default values
for any such parameters which meet a general purpose "bulk data
transfer" requirement in a typical Internet environment.
2.1 Data content model
The implicit goal of a reliable multicast protocol is the reliable
delivery of "data" among a group of members communicating through
IP multicast datagram service. However, the nature of the data
content and the service the application is attempting to provide
can impact design decisions. The service model may range from
long-lived transfer sessions of bulk quantities of data (file
broadcast) to more interactive exhanges of small messages (e.g.
white-boarding, text chat). And within those different models
there are other issues such as the sender's ability to cache
transmitted data (or state referencing it) for retransmission or
repair. The needs for ordering and/or causality in the sequence of
transmissions and receptions among members in the group may be dif-
ferent depending upon data content. The group communication
paradigm differs significantly from the point-to-point model in
that, depending upon the data content type, some receivers may com-
plete reception of a portion of data content and be able to act
upon it before other members have received the content. This may
be acceptable (or even desirable) for some applications but not for
others. These varying requirements drives the need for a number of
different protocol instantiation designs.
A significant challenge in developing generally useful building
block mechanisms is accommodating even a limited range of these
capabilities without defining specific application-level details.
Note that this particular building block "guideline" may be gener-
ally applicable beyond the realm of NACK-oriented reliable multi-
cast.
2.2 Group membership dynamics
Group communication can differ from point-to-point communications
with respect to the fact that even if the composition of the group
changes, the "thread" of communication can still exist. This
Adamson, Bormann, et al. Expires January 2001 [Page 3]
Internet Draft NORM Building Blocks July 2000
contrasts with the point-to-point communication model where, if
either of the two parties leave, the communication process
(exchange of data) is terminated (or at least paused). Depending
upon application goals, senders and receivers participating in a
reliable multicast transport "session" may be able to join late,
leave, and/or potentially rejoin while the ongoing group communi-
cation "thread" still remains functional and useful.
Also note that this can impact protocol message content. If "late
joiners" are supported, some amount of additional information may
be placed in message headers to accommodate this functionality.
Alternatively, the information may be sent in its own message (on
demand or intermittently) if the impact to the overhead of typical
message transmissions is deemed too great. Group dynamics can also
impact other protocol mechanisms such as NACK or other timing, con-
gestion control operation, etc.
2.3 Sender/receiver relationships
The relationship of senders and receivers among group members
requires consideration. In some applications, there may be a sin-
gle sender multicasting to a group of receivers. In other cases,
there may be more than one sender or the potential for everyone in
the group to be a sender _and_ receiver of data may exist.
2.4 Group size
Native IP multicast [Deering89] may scale to extremely large group
sizes. It may be desirable for some applications to be able to
scale along with the multicast infrastructure's ability to scale.
In its simplest form, there are limits to the group size to which a
NACK-oriented protocol can apply without NACK implosion problems.
However, the potential for router assistance or other non-linear
NACK suppression mechanisms may enable these protocols to scale to
very large group sizes. In large scale cases, it may be pro-
hibitive for members to maintain state on all other members (in
particular, other receivers) in the group. The impact of group
size needs to be considered in the development of generally appli-
cable building blocks.
2.5 Data delivery performance
There is a trade-off between scalability and data delivery latency
when designing NACK-oriented protocols. If NACK suppression is to
be used, there will be some delays built into the NACK generation
and repair transmission process to allow suppression to occur and
for the sender of data to identify appropriate content for effi-
cient repair transmission. For example, backoff timeouts can be
Adamson, Bormann, et al. Expires January 2001 [Page 4]
Internet Draft NORM Building Blocks July 2000
used to ensure efficient NACK suppression and repair transmission,
but this comes at a cost of increased delivery latency and
increased buffering requirements for both senders and receivers.
The building blocks should allow applications to establish bounds
for data delivery performance. Note that application designers
must be aware of the scalabilty trade-off which is made when such
bounds are applied.
2.6 Network topology
The Internet Protocol has historically assumed a role of providing
service across heterogeneous network topologies. It is desirable
that a reliable multicast protocol be capable of effectively oper-
ating across a wide range of the networks to which general purpose
IP service applies. The bandwidth available on the links between
the members of a single group today may vary between low numbers
of kbit/s for wireless links and multiple Gbit/s for high speed LAN
connections, with varying degrees of contention from other flows.
Recently, a number of asymmetric network services including
56K/ADSL modems, CATV Internet service, satellite and other wire-
less communication services have begun to proliferate. Many of
these are inherently broadcast media with potentially large
"fanouts" to which IP multicast service is highly applicable.
Additionally, policy and/or technical issues may result in topolo-
gies where multicast connectivity is limited to a single logical
direction from a specific source or set of sources to the group at
large. Receivers in the group may be restricted to unicast feed-
back for NACKs and other messages. Consideration must be given, in
building block development and protocol design, to the nature of
the underlying networks over which the protocols may be operating.
2.7 Router/Intermediate System Assistance
While intermediate assistance from devices/systems with direct
knowledge of the underlying network topology may used to leverage
the performance and scalability of reliable multicast protocols,
there will continue to be a number of instances where this is not
available or practical. Any building block components for NACK-
oriented reliable multicast should be capable of operating without
such assistance but should also be capable of utilizing these fea-
tures when available.
3.0 Building Block Areas
The previous section has presented in general what building blocks
are intended to be and some of the criteria which may affect build-
ing block identification/design. This section describes different
Adamson, Bormann, et al. Expires January 2001 [Page 5]
Internet Draft NORM Building Blocks July 2000
building block areas applicable to NACK-oriented reliable multi-
cast protocols. Some of these areas are specific to NACK-oriented
protocols. Detailed descriptions of such areas are provided
below. In other cases, the areas (e.g. node identifiers, FEC,
etc) may be generally applicable to other forms of reliable multi-
cast. In those cases, the discussion below describes requirements
placed on those other general building block areas from the stand-
point of NACK-oriented reliable multicast.
For the individual building blocks to be incorporated as part of a
specific protocol instantiation, it is expected that a description
of some notional "interface" to the building blocks' functionality
be provided. For example, a building block component may require
some form of "input" from another building block component or
other source in order to perform its function. Any "inputs"
required by each building block component and/or any resultant
"output" provided by the building block will be defined and
described as the building block component's interface definition.
The following building block areas are described below:
(NACK-Oriented Components)
1) Sender transmission
2) NACK-oriented Repair Process
3) "Late-joining" Receiver Policies and Mechanisms
(Generally-applicable Components)
4) Node (member) Identification
5) Data Content Identification
6) Forward Error Correction
7) Round-trip Timing Collection
8) Group Size Determination/Estimation
9) Congestion Control Operation
10) Router/Intermediate System Assistance
11) Additional Protocol Mechanisms
Figure 1 provides an pictoral overview of these building block
areas and their relationships. For example, the content of the
data messages that sender initially transmits depends upon the
"Node Identification", Data Content Identification", "FEC" , and
"Congestion Control components (Note that the rate of message
transmission will generally depend upon the "Congestion Control"
component). Subsequently, the receivers response to these trans-
missions (e.g. NACKing for repair) will depend upon the content of
these transmissions and inputs from other building block compo-
nents. Then, the sender's processing of these responses will feed
back into its transmission strategy.
Adamson, Bormann, et al. Expires January 2001 [Page 6]
Internet Draft NORM Building Blocks July 2000
Application Data
|
V
.---------------------. .-----------------------.
| Node Identification |----------->| Sender Transmission |<------.
'---------------------' _.-' '-----------------------' |
.---------------------. _.-' .' | |
| Data Identification |--' .'' | ("Join" Policy) |
'---------------------' .' ' V |
.---------------------. .' ' .------------------------. |
.->| Congestion Control |-' ' | Receiver NACK-oriented | |
| '---------------------' .' | Repair Process | |
| .---------------------. .' | .------------------. | |
| | FEC |'. | | NACK Initiation | | |
| '---------------------'. '._ | '------------------' | |
| .---------------------. , '-._ | .------------------. | |
'--| RTT Collection |._' '->| | NACK Content | | |
'---------------------' .''. | '------------------' | |
.---------------------. ' ''-._ | .------------------. | |
| Group Size Est. |---'-'---'->| | NACK Suppression | | |
'---------------------''. ' ' | '------------------' | |
.---------------------. ' ' ' '------------------------' |
| Other | ' ' ' | |
'---------------------' ' ' ' | (Router Assistance) |
'. ' ' V |
'.'' .-------------------------. |
'>| Sender NACK Processing |_____/
| and Repair Response |
'-------------------------'
^ ^
| |
.-----------------------------.
| (Security) |
'-----------------------------'
Fig. 1 - NORM Building Block Framework
The components on the left side of this figure represent the components
which may be generally applicable beyond NORM and those on the right are
specific to NORM protocols. Some components (e.g. "Security") will
impact to many aspects of the protocol and others such as "Router Assis-
tance" may be more transparent to the core protocol processing. The
sections below discuss issues with regards to these building block com-
ponents and their relationships. Where applicable, specific technical
recommendations are made for mechanisms which will properly satisfy the
goals of reliable multicast bulk transport for the Internet.
Adamson, Bormann, et al. Expires January 2001 [Page 7]
Internet Draft NORM Building Blocks July 2000
3.1 Sender transmission
Senders will transmit data content to the multicast session. The data
content will be application dependent. The sender will transmit data
content at a rate and with packet sizes determined by application and/or
network architecture requirements. When congestion control mechanisms
are used (recommended), the transmission rate will be controlled by the
congestion control mechanism. It is recommended that all data transmis-
sions from senders be subject to rate limitations determined by the
application or congestion control algorithm. The sender's transmissions
should make good utlization of the available capacity (which may be lim-
ited by the application and/or by congestion control). As a result, it
is expected there will be overlap and multiplexing of new data content
transmission with repair content.
In addition to data content, other sender messages or commands may be
employed as part of protocol operation. For NACK-oriented operation,
the reliability of any such commands may depend upon redundant transmis-
sion. Other factors related to NACK-oriented operation may determine
sender transmission formats and methods. Some consideration needs to be
given to the sender's behavior during intermittent idle periods when it
has no data to transmit. While many aspects may be protocol-specific,
there are techniques which may be generally applicable to NACK-oriented
reliable multicast. For example, the periodicity of redundant transmis-
sion of command messages issued by a sender should be dependent upon the
greatest round trip timing estimate and the resultant NACK operation.
More specifically, a command message might be redundantly transmitted by
a sender to indicate that it is temporarily (or permanently) halting
transmission. At this time, it may be appropriate for receivers to
respond with NACKs for any outstanding repairs they require following
the rules of the NACK process described below. For efficiency, the
sender should allow sufficient time between redundant transmissions to
receive any NACK-oriented responses from the receiver set to this com-
mand. Other protocol components may benefit from a similar approach.
Inputs:
1) Data content
2) Segmentation size
3) Transmission rate
4) Application controls
Outputs:
1) Rate-controlled stream of packets with headers uniquely
identifying data or repair content within the context of the
reliable multicast session.
2) Commands indicating sender's status or other transport
Adamson, Bormann, et al. Expires January 2001 [Page 8]
Internet Draft NORM Building Blocks July 2000
control actions to be taken.
3.2 NACK-oriented repair process
The most critical component of the NACK-oriented reliable multicast
protocol building block is the NACK repair process. There are four
primary elements of a general NACK repair process:
1) Method for determining when receivers will initiate the NACK
process in response to sender transmission for which they
need repair.
2) NACK message content.
3) NACK suppression mechanisms to promote scalability of the
protocol.
4) Sender NACK reception, aggregation, and repair response.
3.2.1 NACK Process Initiation
The NACK process (cycle) will be initiated by receivers who detect
they require repair transmissions from a specific sender at defined
opportunities. When FEC is applied, a NACK cycle should only be
initiated when it is known by the receiver that its repair require-
ments exceed the amount of FEC pending transmission for a given
coding block of packets. This may be determined by the receiver if
the sender's transmission advertises the quantity of repair packets
it is already planning to send for a block, and/or at the end of
the current transmission block (if it is indicated) or at the start
of subsequent coding block for packets transmitted within the con-
text of a designed data content set (See object/stream data content
identifier discussion below).
Allowing receivers to initiate NACK cycles at any time they detect
their repair needs have exceeded pending repair transmissions may
result in slightly quicker repair cycles. However, it may be use-
ful to limit the initiation opportunities to specific events such
as at the end-of-transmission of an FEC coding block (or alterna-
tively at detection of subsequent coding blocks). This can allow
receivers to aggregate NACK content into a smaller number of NACK
messages. In either case, the NACK cycle should begin with
receivers observing backoff timeouts to facilitate NACK suppression
as described below.
Interface Description
Inputs:
1) Object/stream data content and sequencing identifiers from
sender transmissions.
Adamson, Bormann, et al. Expires January 2001 [Page 9]
Internet Draft NORM Building Blocks July 2000
Outputs:
1) NACK Process Initiation Decision
3.2.2 NACK Content
The content of NACK messages generated by reliable multicast
receivers will include information detailing the current repair
needs of each receiver. The specific information depends on the
use and type of FEC in the NORM repair process. The identification
of repair needs is dependent upon the data content identification
(See Section 3.5 below). At the highest level the NACK content
will identify the data transport object (or stream) within the mul-
ticast session which needs repair. For the indicated transport
entity, the NACK content will then identify the specific coding
blocks and/or segments of coding blocks it needs to reconstruct the
transmitted data. This content may be one or more of the items
described in the sections below.
3.2.2.1 FEC Block Erasure Counts
Where FEC-based repair is used, the NACK message content will need
to identify the coding block(s) for which repair is needed and the
count of erasures (missing packets) in the coding block. Note that
this assumes the FEC algorithm is capable of repairing _any_ loss
combination within the coding block and that the quantity of unique
FEC parity packets the server has available to transmit is essen-
tially unlimited (i.e. the server will always be able to provide
new parity packets in response to anysubsequent repair requests for
the same coding block). In other cases, the NACK content will need
to also _explicitly_ identify which packets (information and/or
parity) the receiver needs to successfully reconstruct the content
of the coding block.
3.2.2.2 Encoding of Explicit NACK Content
When FEC is not used as part of the repair process or the protocol
instantiation is required to provide reliability even when the
sender has transmitted all available parity for a given coding
block (or the sender's ability to buffer transmission history is
exceeded by the delay*bandwidth*loss characteristics of the network
topology), the NACK content will need to contain _explicit_ coding
block and/or packet loss information so that the sender can provide
appropriate repair packets and/or data retransmissions. Explicit
loss information in NACK content may also potentially serve other
purposes. For example, it may be useful for decorrelating loss
characteristics among a group of receivers to help differentiate
candidate congestion control bottlenecks among the receiver set.
Adamson, Bormann, et al. Expires January 2001 [Page 10]
Internet Draft NORM Building Blocks July 2000
For cases where the amount of loss is very small with respect to
the coding block size, it may be efficient to simply provide a list
of coding block vector identifiers. However, in many cases, a bit
mask marking the locations of missing packets may be significantly
more efficient for communicating receiver repair needs. And since
the data content is logically divided into coding blocks, a system
of hierarchical bit masks can be used to encode missing content at
the object/stream, FEC block, and individual packet levels. Hier-
archical bit mask encoding can provide compact NACK messages even
in high delay*bandwidth*loss conditions. Bit mask based NACK con-
tent can also be efficiently processed with logical operations dur-
ing protocol operation.
3.2.2.3 Hybrid Approach
When FEC is used and NACK content is designed to contain explicit
repair requests, there is strategy where the receivers can NACK for
specific content which will help facilitate NACK suppression and
repair efficiency. The assumptions for this strategy are that
sender may potentially exhaust its supply of new, unique parity
packets available for a given coding block and be required to
explicitly retransmit some data or parity segments to complete
reliable transfer. Another assumption is that an FEC algorithm
where any parity packet can fill any erasure within the coding
block is used. The goal of this strategy is to make maximum use of
the available parity and provide the minimal amount of data and
repair transmissions during reliable transfer of a coding block to
the group.
In this approach, the sender transmits the data content of the cod-
ing block (and optionally some quantity of parity packets) in its
initial transmission. Note that a coding block is considered to be
logically made up of the contiguous set of data vectors plus parity
vectors for the given FEC algorithm used. The sender transmits
parity vectors from the lowest ordinal part of the parity portion
of the coding block. When the receivers construct explicit NACK
content, they request transmission of only the _upper_ ordinal por-
tion, corresponding to the number of _data_ vectors, of the logical
coding block required to fill their packet erasures (Note this
_may_ include data vectors if there is a smaller number of parity
vectors than data vectors for the selected code, but generally will
consist solely of parity vectors). The receivers can also provide
a count of erasures as a convenience (saves processing time) to the
sender. Upon receipt of the NACK message, the sender will schedule
transmission of fresh, new parity vectors based on the erasure
count _if_ it has a sufficient quantity of vectors which were _not_
previously transmitted and ignore the explicit content requested..
Otherwise, the sender will resort to transmitting the set of repair
Adamson, Bormann, et al. Expires January 2001 [Page 11]
Internet Draft NORM Building Blocks July 2000
vectors requested. With this approach, the sender needs to main-
tain very little state on requests it has received from the group
without need for synchronization of repair requests from the group.
Since all receivers use this same algorithm to express their
explict repair needs, NACK suppression among receivers is simpli-
fied over the course of multiple repair cycles. The receivers can
simply compare NACKs heard from other receivers against their own
calculated repair needs to determine whether they should transmit
or suppress their pending NACK messages.
3.2.3 NACK Suppression Mechanisms
A primary NACK suppression mechanism is the use of initial backoff
timeouts by receivers wishing to transmit NACK messages[Floyd95].
Upon expiration of the timeout, a receiver will transmit a NACK
unless the content of the pending repair request is completely
superseded by NACK messages heard from other receivers (when
receivers are multicasting NACKs) or from some indicator from the
sender. (Note: When receivers are unicasting NACK messages, the
sender may facilitate NACK suppression by forwarding appropriate
NACKs it has received to the group at large or provide some other
indicator of the repair information it will be subsequently trans-
mitting).
The backoff timeout periods used by receivers should be indepen-
dently, randomly picked by receivers with an exponential distribu-
tion [Nonnenmacher98]. This results in the bulk of the receiver
set holding off transmission of NACK messages under the assumption
that the smaller number of "early NACKers" will supersede the
repair needs of the remainder of the group. The mean of the dis-
tribution should be determined as a function of the current esti-
mate of sender<->group greatest round trip time (GRTT) and a group
size estimate which determined by other mechanisms within the pro-
tocol (See section below) or preset by the multicast application.
A simple algorithm can be constructed to generate random backoff
timeouts with the appropriate distribution. Additionally, the
algorithm may be designed to optimize the backoff distribution
given the number of receivers (R) potentially generating feedback.
This "optimization" minimizes the number of feedback messages (e.g.
NACK) in the worst-case situation where all receivers generate a
NACK. The maximum backoff timeout (T) can also be controlled to
allow the application or protocol tradeoff NACK latency versus vol-
ume of feedback traffic. A larger value of T will result in a
lower density of feedback traffic for a given repair cycle. A
smaller value of T results in shorter latency which reduces the
buffering requirements of senders and receivers for reliable trans-
port.
Adamson, Bormann, et al. Expires January 2001 [Page 12]
Internet Draft NORM Building Blocks July 2000
Given the receiver group size (R), and maximum allowed backoff
timeout (T), a truncated exponential backoff timeout (t') can be
picked with the following algorithm:
1) Establish an optimal mean (L) for the exponential backoff based
on the group size:
L = ln(R) + 1
2) Pick a random number (x) from a uniform distribution
over a range of:
L L L
---------------- to ---------------- + ---
T * (exp(L) - 1) T * (exp(L) - 1) T
3) Transform this random variate to generate the
desired random backoff time (t) with the following
equation:
t' = T/L * ln(x * (exp(L) - 1) * (T/L))
This is a C language function which can be used to perform this
function:
double RandomBackoff(double maxTime, double groupSize)
{
double lambda = log(groupSize) + 1;
double x = UniformRand(lambda/maxTime) +
lambda / (maxTime*(exp(lambda)-1));
return ((maxTime/lambda) *
log(x*(exp(lambda)-1)*(maxTime/lambda)));
} // end RandomBackoff()
where UniformRand(double max) returns random numbers with a uniform
distribution from the range of 0..max. For example, based on the
POSIX "rand()" function, the following code can be used:
double UniformRand(double max)
{
return (max * ((double)rand()/(double)RAND_MAX));
}
The number of expected NACKs generated (N) within the first round
trip time for a single loss event can be approximately expected to
be:
N = exp(1.2 * L / (2*T/GRTT))
Adamson, Bormann, et al. Expires January 2001 [Page 13]
Internet Draft NORM Building Blocks July 2000
Thus the maximum backoff time (T) can be adjusted to tradeoff
worst-case NACK feedback volume versus latency. This is derived
from [Nonnenmacher98] and assumes T >= GRTT, and L is the mean of
the distribution optimized for the given group size as shown in the
algorithm above. Note that other mechanisms within protocol may
work to reduce redundant NACK generation further.
There are some secondary NACK suppression mechanisms which can also
be considered. For example, the sender's transmissions may follow
an ordinal sequence of transmission (observed through data/repair
content <objectIds> and/or <segmentIds>) which is "rewound" during
repair transmissions. Receivers may wish to limit transmission of
their NACKs only when the sender's current sequence of transmission
passes the point at which the receiver has incomplete transmis-
sions, thus reducing premature requests for repair of data the
sender may be providing in response to other receiver requests.
This mechanism can be very effective for protocol convergence in
high loss conditions when transmissions of NACKs from other
receivers (or indicators from the sender) are lost. Another mecha-
nism (particularly applicable when FEC is used) is for the sender
to embed an indication of impending repair transmissions in current
packets sent. For example, the indication may be as simple as an
advertisment of the number of FEC packets to be sent for the cur-
rent applicable coding block. Finally, some consideration might be
given to using the NACKing history of receivers to weight their
selection of NACK backoff timeout intervals. For example, if a
receiver has historically been experiencing the greatest degree of
loss, it may promote itself to statistically NACK sooner than other
receivers. Note this assumes there is some degree of correlation
over successive intervals of time in the loss experienced by
receivers. This adjustment of backoff timeout selection may
require the creation of an "early NACK" slot for these historical
NACKers. This additional slot in the NACK backoff window will
result in a longer repair cycle process which may not be desirable
for some applications. The resolution of these trade-offs may be
dependent upon the protocol's target application set or network.
Interface Description
Inputs:
1) Group greatest round trip time estimate (GRTT).
2) Group size estimate.
3) Application-defined bound on backoff timeout period.
4) NACKs from other receivers.
5) Pending repair indication from sender (may be forwarded
NACKs).
6) Current sender transmission sequence position.
Adamson, Bormann, et al. Expires January 2001 [Page 14]
Internet Draft NORM Building Blocks July 2000
Outputs:
1) Yes/no decision to generate NACK message upon backoff timer
expiration.
3.2.4 Sender NACK Processing and Repair Response
Upon reception of a repair request from a receiver in the group,
the sender will initiate a repair response procedure. The sender
may wish to delay transmission of repair content until it has had
sufficient time to accumulate potentially multiple NACKs from the
receiver set. This allows the sender to determine the most effi-
cient repair strategy for a given transport stream/object or FEC
coding block. Depending upon the approach used, some protocols may
find it beneficial for the sender to provide an indicator of pend-
ing repair transmissions as part of the its current transmitted
message content. This can aid some NACK suppression mechanisms.
Alternatively, in the case of unicast feedback from the receiver
set, it may be useful for the sender to forward (via multicast)
superseding NACK messages to the group to allow for NACK suppres-
sion when there is not multicast connectivity among the receiver
set.
When FEC is used, it is beneficial that the sender transmit previ-
ously untransmitted parity content whenever possible. This maxi-
mizes the receiving nodes' ability to reconstruct the entire trans-
mitted content from their individual subsets of received messages.
The transmitted object and/or stream content will be marked with
monotonically increasing sequence numbers (within a reasonably
large ordinal space). If the sender observes the discipline of
transmitting repair for the earliest content first, the receivers
can use a strategy of witholding repair requests for later content
until the sender once again returns to that point in the
object/stream transmission sequence. This can increase overall
message efficiency among the group and help work to keep repair
cycles relatively synchronized without dependence upon strict tim-
ing. This also helps minimize the buffering requirements of
receivers and senders and reduces redundant transmission of data to
the group at large.
Interface Description
Inputs:
1) Receiver NACKs
1) Group timing information
Adamson, Bormann, et al. Expires January 2001 [Page 15]
Internet Draft NORM Building Blocks July 2000
Outputs:
1) Repair messages (FEC and/or Data content retransmission)
3.3 Group "Join" Policies/ Procedures
Consideration should be given to how new receivers join a group
(perhaps where reliable transmission is already in progress) and
beging NACKing for any repair needs. If this is unconstrained, the
dynamics of group membership may impede the application's ability
to meet it goals progressing the transmission of data. Policies
limiting the opportunities at which receivers begin participating
in the NACK process may be used to achieve the desired behavior.
For example, it may be beneficial if receivers only attempt reli-
able reception from a newly-heard sender when upon non-repair
transmissions of data in the first FEC block of an object or logi-
cal portion of a stream. The sender may also implement policies
limiting which receivers from which it will accept NACK requests,
but this may be prohibitive for scalability reasons in some situa-
tions. In some types of bulk transfer applications (and for poten-
tial interactive applications), it may alternatively desirable to
have a looser transport synchronization policy and rely upon ses-
sion management mechanisms to control group dynamics which may
result in poor behavior.
Inputs:
1) Current object/stream data/repair content and sequencing
identifiers from sender transmissions.
Outputs:
1) Receiver yes/no decision to begin receiving and NACKing for
reliable reception of data
3.4 Reliable multicast member identification
In a NORM protocol (or other multicast protocols) where there is
the potential for multiple sources of data, it is necessary to pro-
vide some mechanism to uniquely identify the sources (and possibly
some or all receivers in some cases) within the group. Identity
based on arriving packet source addresses is insufficient for sev-
eral reasons. These reasons include routing changes for hosts with
multiple interfaces which result different packet source addresses
for a given host over time, network address translation (NAT) or
firewall devices, or other transport/network bridging approaches.
As a result, some type of unique source identifier (sourceId) field
should be present in packets transmitted by reliable multicast
Adamson, Bormann, et al. Expires January 2001 [Page 16]
Internet Draft NORM Building Blocks July 2000
session members.
3.5 Data content identification
The data content transmitted by a NORM sender requires some form of
identification in the protocol header fields. This identification
is required to facilitate the reliable NACK-oriented repair pro-
cess. These identifiers will be used in NACK messages generated.
There are two very general types of data which may comprise bulk
transfer session content. These data types are static objects of
finite size and continuous non-finite streams. A given application
may wish to reliably multicast data content using either one or
both of these data models. While it may be possible for some
applications to further generalize this model and provide mecha-
nisms to encapsulate static objects as content embedded within a
stream, there are advantages to many applications to provide dis-
tinct support for static bulk objects and messages with the context
of a reliable multicast session. These applications may include
content caching servers, file transfer or collaborative tools with
bulk content. Applications with requirements for these static
object types can then take advantage of transport layer mechanisms
(i.e. segmentation/reassembly, caching, integrated forward error
correction coding, etc) rather than being required to provide their
own mechanisms for these functions at the application layer.
As noted, some applications may alternatively desire to transmit
bulk content in the form of one or more streams of non-finite size.
Example streams include continuous quasi-realtime message broad-
casts (e.g. stock ticker) or some content types which are part of
collaborative tools or other more complex applications. And, as
indicated above, some applications may wish to encapsulate other
bulk content (e.g. files) into one more streams within a multicast
session. Additionally, multiple streams can allow for parallized
transmission within the context of a single multicast session.
The components described within this building block draft document
are envisioned to be applicable to both of these models with the
potential for a mix of both types within a single multicast ses-
sion. To support this requirement, the normal data content identi-
fication should include a field to uniquely identify the object or
stream <objectId> within some reasonable temporal or ordinal inter-
val. Note that it is _not_ expected that this data content identi-
fication will be globally unique. It is expected that the
object/stream identifier will be unique with respect to a given
sender within the reliable multicast session and during the time
that sender is supporting a specific transport instance of that
object or stream.
Adamson, Bormann, et al. Expires January 2001 [Page 17]
Internet Draft NORM Building Blocks July 2000
Since the "bulk" object/stream content will generally require seg-
mentation, some form of segment identification <segmentId> must
also be provided. This segment identifier will be relative to any
object or stream identifier which has been provided. Thus, in some
cases, NORM protocol instantiations may be able to receive trans-
missions and request repair for multiple streams and one or more
sets of static objects in parallel.
Additionally, flags to determine the usage of the content identi-
fier fields (e.g. stream vs. object) may be applicable. Flags
may also serve other purposes in data content identification. It
is expected that any flags defined will be dependent upon individ-
ual protocol instantiations.
In summary, the following data content identifiers may be required
for NORM protocol data content messages:
1) Object/Stream identifier (<objectId>)
2) Segment identifier (<segmentId>)
3) Flags to differentiate interpretation of identifier fields
or identifier structure which implicitly indicates usage.
These fields have been identified since any generated NACK messages
will use these identifiers in requesting repair or retransmission
of data. NORM protocols are expected to greatly benefit from
interaction with other reliable multicast building blocks (Generic
Router Assist(GRA), in particular) and those other building blocks
will need to appropriately consider these anticipated requirements.
3.6 Forward Error Correction
Multiple forward error correction (FEC) approaches have been iden-
tified which can provide great performance enhancements to the
repair process of NACK-oriented and other reliable multicast proto-
cols [Metzner84, Macker97]. NORM protocols can reap additional
benefits since FEC-based repair does not _generally_ require
explicit knowledge of repair content within the bounds of its cod-
ing block size (in packets).
Generally, repair packets generated using FEC algorithms with good
erasure filling properties (e.g. Reed-Solomon) will be transmitted
only in response to NACK repair requests from receiving nodes.
However, there are benefits in some network environments for trans-
mitting some predetermined quantity of FEC repair packets multi-
plexed with the regular data segment transmissions [Gossink98].
This can reduce the amount of NACK traffic generated with rela-
tively little overhead cost when group sizes are very large or the
network connectivity has a large delay*bandwidth product with some
Adamson, Bormann, et al. Expires January 2001 [Page 18]
Internet Draft NORM Building Blocks July 2000
nominal level of expected packet loss. While the application of
FEC is not unique to NORM, these sorts of requirements may dictate
the types of algorithms and protocol approaches which are applica-
ble.
A specific issue related to the use of FEC with NORM is the mecha-
nism used to identify which portion(s) of transmitted data content
to which specific FEC packets are applicable. It is expected that
FEC algorithms will be based on generating a set of parity repair
packets for a corresponding block of transmitted data packets.
Since data content packets are uniquely identified by the concate-
nation of <sourceId/objectId/segmentId> during transport, it is
expected that FEC packets will be identified in a similar manner.
It may be sufficient to identify FEC packets using the identifier
of the first segment of the block of data content packets for which
the FEC repair packet is applicable and add an additional FEC iden-
tifier <fecId> field to its position within the set of FEC packets
for the block. The size of the <fecId> field can potentially be
small (8 or 16 bits) relative to other identifier fields since its
size is limited by the FEC coding algorithm used.
3.7 Round-trip Timing Collection
The measurement of packet propagation round-trip time (RTT) among
members of the group is required to support NACK suppression algo-
rithms, timing of sender commands or certain repair functions, and
congestion control operation. The nature of the round-trip infor-
mation collected is dependent upon the type of interaction among
the members of the group. In the case where only "one-to-many"
transmission is required, it may be necessary that only the sender
require RTT knowledge of the greatest RTT (GRTT) among the receiver
set and/or RTT knowledge of only a portion of the group. Here, the
GRTT information might be collected in a reasonably scalable man-
ner. For congestion control operation, it is possible that RTT
information may be required by each receiver in the group. In this
case, an alternative RTT collection scheme may be utilized where
receivers collect individual RTT measurements with respect to the
sender and advertise them (or an competed subset) to the group or
sender. Where it is likely that exchange of reliable multicast
data will occur among the group on a "many-to-many" basis, there
are alternative measurement techniques which might be employed for
increased efficiency [Ozdemir99]. And in some cases, there might
be absolute time synchronization among hosts which may simplify RTT
measurement. There are trade-offs in multicast congestion control
design which need further consideration before a universal recom-
mendation on RTT (or GRTT) measurement can be specified. Regard-
less of how the RTT information is collected (and more specifically
GRTT) with respect to congestion control or other requirements, the
Adamson, Bormann, et al. Expires January 2001 [Page 19]
Internet Draft NORM Building Blocks July 2000
sender will need to advertise its current GRTT estimate to the
group for timing of the
3.7.1 One-to-Many Sender GRTT Measurement
The goal of this form of RTT measurement is for the sender to learn
the GRTT among the receivers who are actively participating in NORM
operation. The set of receivers participating in this process may
be the entire group or some subset of the group determined from
another mechanism within the protocol instantiation. An approach
to collect this GRTT information follows.
The sender periodically polls the group with a message (independent
or "piggy-backed" with other transmissions) containing a <sendTime>
timestamp relative to an internal clock at the sender. Upon recep-
tion of this message, the receivers will record this <sendTime>
timestamp and the time (referenced to their own clocks) at which it
was received <recvTime>. When the receiver provides feedback to
the sender (either explicitly or as part of other feedback messages
depending upon protocol instantion specification), it will con-
struct a "response" using the formula:
<grttResponse> = <sendTime> + (<currentTime> - <recv_Time>)
where the <sendTime> is the timestamp from the last probe message
received from the source and the (<currentTime> - <recvTime>) is
the amount of time differential since that request was received
until the receiver generated the response.
The sender processes each receiver response by calculating a cur-
rent RTT measurement for the receiver from whom the response was
received using the following formula:
<receiverRtt> = <currentTime> - <grttResponse>
During the each periodic GRTT probing interval, the source keeps
the peak round trip estimate from the set of responses it has
received. The GRTT estimate should be filtered to be conservative
towards maintaining an estimate biased towards the greatest
receiver RTT measurements received. A conservative estimate of
GRTT maximizes the efficiency redundant NACK suppression and repair
aggregation. The update to the source's ongoing estimate of GRTT
is done observing the following rules:
1) If a receiver's response round trip calculation is greater
than the current GRTT estimate AND current peak, the
response value is immediately fed into the GRTT update fil-
ter given below. In any case, the source records the "peak"
Adamson, Bormann, et al. Expires January 2001 [Page 20]
Internet Draft NORM Building Blocks July 2000
receiver RTT measurement for the current probe interval.
2) At the end of the response collection period (i.e. the GRTT
probe interval), if the recorded "peak" response is less
than the current GRTT estimate AND this is the third consec-
utive collection period with a peak less than the current
GRTT estimate the recorded peak is fed into the GRTT update.
(Implicitly, Rule #1 was applied otherwise so no new update
is required).
3) At the end of the response collection period, the peak
tracking value is set to either ZERO if the "peak" is
greater than or equal to the current GRTT estimate (i.e.
Already incorporated into the filter under Rule #1) or kept
the same if its value is less than the current GRTT estimate
AND was not yet incorporated into the GRTT update filter
according to Rule #2. Thus for decreases in the source's
estimate of GRTT, the "peak" is tracked across three consec-
utive probe intervals. The current MDP implementation uses
the following GRTT update filter to incorporate new peak
responses into the the GRTT estimate:
if (peak > current_estimate)
current_estimate = 0.25 * current_estimate + 0.75 * peak;
else
current_estimate = 0.75 * current_estimate + 0.25 * peak;
This update method is biased towards maintaining an estimate of the
worst-case round trip delay. The reason the GRTT estimate is
reduced only after 3 consecutive collection periods with smaller
response peaks is to be conservative where packet loss may have
resulted in lost response messages. And then the reduction is
additionally conservatively weighted using the averaging filter
from above.
The GRTT collection period (i.e. period of probe transmission)
could be fixed at a value on the order of that expected for group
membership and/or network topology dynamics. For robustness, more
rapid probing could be used at protocol startup before settling to
a less frequent, steady-state interval. Optionally, an algorithm
may be developed to adjust the GRTT collection period dynamically
in response to the current GRTT estimate (or variations in it) and
to an estimation of packet loss. The overhead of probing messages
could then be reduced when the GRTT estimate is stable and unchang-
ing, but be adjusted to track more dynamically during periods of
variation with correspondingly shorter GRTT collection periods.
In summary, although NORM repair cycle timeouts are based on GRTT,
Adamson, Bormann, et al. Expires January 2001 [Page 21]
Internet Draft NORM Building Blocks July 2000
it should be noted that convergent operation of the protocol does
not _strictly_ depend on accurate GRTT estimation. The current
mechanism has proved sufficient in simulations and in the environ-
ments in which NORM-like protocols have been deployed to date. The
estimate provided by the algorithm tracks the peak envelope of
actual GRTT (including operating system effect as well as network
delays) even in relaitvely high loss connectivity. The steady-
state probing/update interval may potentially be varied to accommo-
date different levels of expected network dynamics in different
environments.
3.7.2 One-to-Many Receiver RTT Measurement
(TBD - Receivers "ping" sender for RTT measurement, and then
receivers competitively (worst case RTT metric) advertise their
measurements to the sender and optionally group so the sender can
determine GRTT ... Sender should still robustly advertise its cur-
rent GRTT knowledge to the group so group can use appropriate tim-
ing)
3.7.3 Many-to-Many RTT Measurement
(TBD - Describe approach based on Ozdemir99, if appropriate/appli-
cable?)
3.7.4 Sender GRTT Advertisement
To facilitate determistic NORM protocol operation, the sender
should robustly advertise its current estimation of GRTT to the
receiver set. Common, robust knowledge of the sender's current
operating GRTT estimate among the group will allow the protocol to
progress in its most efficient manner. The sender's GRTT estimate
can be robustly advertised to the group by simply embedding the
estimate into all pertinent messages transmitted by the sender.
The overhead of this can be made quite small by quantizing (com-
pressing) the GRTT estimate to a single byte of information. The
following C-lanquage function algorithm allows this to be done over
a wide range of GRTT values while maintaining a greater range of
precision for small GRTT values and less precision for large val-
ues:
unsigned char QuantizeGrtt(double grtt)
{
if (grtt > 1.0e03)
grtt = 1.0e03;
else if (grtt < 1.0e-06)
grtt = 1.0e-06;
if (grtt < 3.3e-05)
Adamson, Bormann, et al. Expires January 2001 [Page 22]
Internet Draft NORM Building Blocks July 2000
return ((unsigned char)(grtt * 1.0e06) - 1);
else
return ((unsigned char)(ceil(255.0.-
(13.0 * log(1.0e03/grtt)))));
}
Note that this function is useful for quantizing GRTT times in the
range of 1 microsecond to 1000 seconds. Of course, NORM protocol
implementations may wish to further constrain advertised GRTT esti-
mates (e.g. limit the maximum value) for practical reasons.
3.8 Group Size Determination/Estimation
(TBD)
3.9 Congestion Control Operation
(TBD - A NACK-oriented protocol may place limitations/requirements
on collection of information to facilitate congestion control of
senders. There are a number of specific issues of TCP-Friendly
Multicast Congestion Control (TFMCC)which must be addressed.)
3.10 Router/Intermediate System assistance
(TBD - NACK-oriented protocols can potentially benefit greatly from
router assistance. In particular, additional NACK suppression
would be beneficial (This may impact how synchronized receiver NACK
cycles are, sender advertisement of NACK-cycle parameters (i.e.
GRTT, group size, etc), NACK content, others)
3.11 Additional protocol mechanisms
(TBD- e.g. positive acknowledgement collection, performance
statistics collection, session management, etc)
4.0 Security Considerations (TBD)
5.0 References
[Mankin98] A. Mankin, A. Romanow, S. Bradner, V. Paxson, "IETF
Criteria for Evaluating Reliable Multicast Transport and Applica-
tion Protocols", RFC 2357, June 1998.
[Pingali93] S. Pingali, D. Towsley, J. Kurose. "A Comparison of
Sender-Initiated and Receiver-Initiated Reliable Multicast Proto-
cols". In Proc. INFOCOM, San Francisco, CA, October 1993.
[Levine96] B.N. Levine, J.J. Garcia-Luna-Aceves. "A Comparison of
Adamson, Bormann, et al. Expires January 2001 [Page 23]
Internet Draft NORM Building Blocks July 2000
Known Classes of Reliable Multicast Protocols", Proc. Interna-
tional Conference on Network Protocols (ICNP-96), Columbus, Ohio,
Oct 29--Nov 1, 1996.
[Clark90] D. Clark, D. Tennenhouse, "Architectural Considerations
for a New Generation of Protocols". In Proc. ACM SIGCOMM, pages
201--208, September 1990.
[Deering89] S. Deering. "Host Extensions for IP Multicasting".
Internet RFC1112, August 1989.
[Floyd95] S. Floyd, V. Jacobson, S. McCanne, C. Liu, and L.
Zhang. "A Reliable Multicast Framework for Light-weight Sessions
and Application Level Framing", Proc. ACM SIGCOMM, August 1995.
[Nonnenmacher98] J. Nonnenmacher and E. W. Biersack, "Optimal
multicast feedback," in IEEE Infocom , (San Francisco, California),
p. 964, March/April 1998.
[Gossink98] D. Gossink, J. Macker, "Reliable Multicast and Inte-
grated Parity Retransmission with Channel Estimation", IEEE GLOBE-
COM 98'.
[Metzner84] J. Metzner, "An Improved Broadcast Retransmission Pro-
tocol", IEEE Transactions on Communications, Vol. Com-32, No.6,
June 1984.
[Macker97a] J. Macker, "Integrated Erasure-Based Coding for Reli-
able Multicast Transmission", IRTF Meeting presentation, March
1997.
[Macker97b] J. Macker, "Reliable Multicast Transport and Integrated
Erasure-based Forward Error Correction", Proc. IEEE MILCOM 97,
October 1997.
[Ozdemir99] V. Ozdemir, S. Muthukrishnan, I. Rhee, "Scalable, Low-
Overhead Network Delay Estimation", NCSU/AT&T White Paper, February
1999.
6.0 Authors' Addresses
Brian Adamson
adamson@itd.nrl.navy.mil
Newlink Global Engineering Corporation
8580 Cinder Bed Road, Suite 1000
Newington, VA, USA, 22122
Adamson, Bormann, et al. Expires January 2001 [Page 24]
Internet Draft NORM Building Blocks July 2000
Carsten Bormann
cabo@tellique.de
Tellique Kommunikationstechnik GmbH
Gustav-Meyer-Allee 25 Geb ude 12
D-13355 Berlin, Germany
Sally Floyd
floyd@aciri.org
1947 Center Street, Suite 600
Berkeley, CA 94704
Mark Handley
mjh@aciri.org
1947 Center Street, Suite 600
Berkeley, CA 94704
Joe Macker
macker@itd.nrl.navy.mil
Naval Research Laboratory
Washington, DC, USA, 20375
Adamson, Bormann, et al. Expires January 2001 [Page 25]
--============_-1247487947==_============--
>From owner-rmt@listserv.lbl.gov Mon Jul 31 10:53:23 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id KAA24199;
Mon, 31 Jul 2000 10:51:05 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id KAA24189
for <rmt@listserv.lbl.gov>; Mon, 31 Jul 2000 10:50:53 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id KAA19608
for <rmt@listserv.lbl.gov>; Mon, 31 Jul 2000 10:50:52 -0700 (PDT)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
by SpamWall.lbl.gov (8.9.3/8.9.3) with SMTP id KAA19559
for <rmt@lbl.gov>; Mon, 31 Jul 2000 10:50:47 -0700 (PDT)
Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP
id <g.04803-0@bells.cs.ucl.ac.uk>; Mon, 31 Jul 2000 18:50:43 +0100
to: rmt@lbl.gov
Subject: NACK comment...
Date: Mon, 31 Jul 2000 18:50:42 +0100
Message-ID: <13272.965065842@cs.ucl.ac.uk>
From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
Sender: owner-rmt@lbl.gov
Precedence: bulk
In message <v0421010db5a4d716efc4@[132.250.92.151]>, Brian Adamson typed:
comment on NACK protocols and advance with Time windows (e.g. PGM)
its sometimes nice if there's not only a NACK (and a NACK confirm) but
also a NACK reject, so that both sender and receiver are synchronised
on their view of the data failure at about the same point in the
stream (i.e. for appllciations that are based on synchronouse
messageing style repliaction - e.g. highly avaialble transaction
servers).....
it also has API issues (you need an error return or exception or
event/message at both sender AND receiver at the right point - like
TCP oob data, only not:-)
cheers
jon
>From owner-rmt@listserv.lbl.gov Mon Jul 31 12:30:43 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id MAA24757;
Mon, 31 Jul 2000 12:29:54 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id MAA24753
for <rmt@listserv.lbl.gov>; Mon, 31 Jul 2000 12:29:52 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id MAA22346
for <rmt@listserv.lbl.gov>; Mon, 31 Jul 2000 12:29:51 -0700 (PDT)
Received: from sammy.tibco.com (sammy.tibco.com [192.216.111.146])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id MAA22341
for <rmt@lbl.gov>; Mon, 31 Jul 2000 12:29:50 -0700 (PDT)
Received: from osgood.tibco.com (osgood.tibco.com [160.101.240.42])
by sammy.tibco.com (8.9.3/8.9.3) with ESMTP id MAA20341
for <rmt@lbl.gov>; Mon, 31 Jul 2000 12:29:19 -0700 (PDT)
Received: from venus.tibco.com (venus.tibco.com [160.101.240.40])
by osgood.tibco.com (8.9.3/8.9.3) with ESMTP id MAA03200
for <rmt@lbl.gov>; Mon, 31 Jul 2000 12:32:45 -0700 (PDT)
Received: from tibco.com ([160.101.95.124]) by venus.tibco.com
(Netscape Messaging Server 3.6) with ESMTP id AAA4A60
for <rmt@lbl.gov>; Mon, 31 Jul 2000 12:29:18 -0700
Message-ID: <3985D38E.2B0A3E95@tibco.com>
Date: Mon, 31 Jul 2000 12:29:18 -0700
From: "Dan Leshchiner" <dleshc@tibco.com>
X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: rmt@lbl.gov
Subject: Re: NACK comment...
References: <13272.965065842@cs.ucl.ac.uk>
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 7bit
Sender: owner-rmt@lbl.gov
Precedence: bulk
in PGM this can be done by sending SPM -- trailing edge sequence number would be
greater than NAK'ed seqno.
Jon Crowcroft wrote:
>
> In message <v0421010db5a4d716efc4@[132.250.92.151]>, Brian Adamson typed:
>
> comment on NACK protocols and advance with Time windows (e.g. PGM)
>
> its sometimes nice if there's not only a NACK (and a NACK confirm) but
> also a NACK reject, so that both sender and receiver are synchronised
> on their view of the data failure at about the same point in the
> stream (i.e. for appllciations that are based on synchronouse
> messageing style repliaction - e.g. highly avaialble transaction
> servers).....
>
> it also has API issues (you need an error return or exception or
> event/message at both sender AND receiver at the right point - like
> TCP oob data, only not:-)
>
> cheers
> jon
>From owner-rmt@listserv.lbl.gov Thu Aug 3 05:40:43 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id FAA07057;
Thu, 3 Aug 2000 05:36:08 -0700 (PDT)
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id FAA07053
for <rmt@listserv.lbl.gov>; Thu, 3 Aug 2000 05:36:06 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id FAA12497
for <rmt@listserv.lbl.gov>; Thu, 3 Aug 2000 05:36:05 -0700 (PDT)
Received: from violin.dcs.uky.edu (violin.dcs.uky.edu [204.198.75.11])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id FAA12494
for <rmt@lbl.gov>; Thu, 3 Aug 2000 05:36:04 -0700 (PDT)
Received: from gladstone.dcs.uky.edu (gladstone.dcs.uky.edu [204.198.75.142])
by violin.dcs.uky.edu (8.9.1a/8.9.1) with ESMTP id IAA00659;
Thu, 3 Aug 2000 08:36:02 -0400 (EDT)
Received: from localhost (calvert@localhost)
by gladstone.dcs.uky.edu (8.9.1a/8.9.1) with ESMTP id IAA16386;
Thu, 3 Aug 2000 08:36:02 -0400 (EDT)
X-Authentication-Warning: gladstone.dcs.uky.edu: calvert owned process doing -bs
Date: Thu, 3 Aug 2000 08:36:02 -0400 (EDT)
From: Ken Calvert <calvert@dcs.uky.edu>
To: rmt@lbl.gov
cc: griff@dcs.uky.edu
Subject: concast
Message-ID: <Pine.GSO.4.10.10008030830180.16362-100000@gladstone>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-rmt@lbl.gov
Precedence: bulk
[I sent a similar message to the rm list earlier in the week, but it
appears not to have made it out.]
Folks,
We'd like to call your attention to draft-calvert-concast-svc-00.txt,
which describes the concast many-to-one service. After looking over the
current drafts and hearing the presentations earlier this week, it appears
that Concast would make a good RM building block. It is useful for
aggregation of feedback, both ack/nack and congestion-related.
We'd appreciate any comments. The draft describes the service independent
of RM, because it is also useful outside the context of multicast.
Cheers,
KC
--
Ken Calvert calvert@dcs.uky.edu
Associate Professor ***************NOTE NEW AREA CODE = 859
Computer Science, 773 Anderson Hall +1.859.257.6745
University of Kentucky Fax: +1.859.323.1971
Lexington, KY 40506-0046 http://www.cs.uky.edu/~calvert/
>From owner-rmt@listserv.lbl.gov Thu Aug 3 07:42:55 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id HAA08106;
Thu, 3 Aug 2000 07:40:59 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id HAA08102
for <rmt@listserv.lbl.gov>; Thu, 3 Aug 2000 07:40:57 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id HAA27850
for <rmt@listserv.lbl.gov>; Thu, 3 Aug 2000 07:40:56 -0700 (PDT)
Received: from nilla.aciri.org (wireless-132-79.ietf.marconi.com [147.73.132.79])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id HAA27835
for <rmt@lbl.gov>; Thu, 3 Aug 2000 07:40:55 -0700 (PDT)
Received: from nilla.aciri.org (localhost [127.0.0.1])
by nilla.aciri.org (8.9.3/8.9.3) with ESMTP id IAA01451;
Thu, 3 Aug 2000 08:10:40 -0700 (PDT)
(envelope-from mjh@nilla.aciri.org)
Message-Id: <200008031510.IAA01451@nilla.aciri.org>
From: Mark Handley <mjh@aciri.org>
X-Organisation: ACIRI
To: Ken Calvert <calvert@dcs.uky.edu>
cc: rmt@lbl.gov
Subject: Re: concast
In-reply-to: Your message of "Thu, 03 Aug 2000 08:36:02 EDT."
<Pine.GSO.4.10.10008030830180.16362-100000@gladstone>
Date: Thu, 03 Aug 2000 08:10:40 -0700
Sender: owner-rmt@lbl.gov
Precedence: bulk
>[I sent a similar message to the rm list earlier in the week, but it
>appears not to have made it out.]
I received it.
If anyone is on both lists, and didn't get both copies, please let me
know, so I can figure out if there's a problem with the mail server
that handles the rm list.
Cheers,
Mark
>From owner-rmt@listserv.lbl.gov Thu Aug 3 09:36:35 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id JAA08936;
Thu, 3 Aug 2000 09:34:49 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id JAA08932
for <rmt@listserv.lbl.gov>; Thu, 3 Aug 2000 09:34:47 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id JAA28496
for <rmt@listserv.lbl.gov>; Thu, 3 Aug 2000 09:34:46 -0700 (PDT)
Received: from omega.cisco.com (omega.cisco.com [171.69.63.141])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id JAA28491
for <rmt@lbl.gov>; Thu, 3 Aug 2000 09:34:46 -0700 (PDT)
Received: from localhost (lorenzo@localhost)
by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id JAA26174;
Thu, 3 Aug 2000 09:33:46 -0700 (PDT)
Message-Id: <200008031633.JAA26174@omega.cisco.com>
To: Ken Calvert <calvert@dcs.uky.edu>
cc: rmt@lbl.gov
Subject: Re: concast
In-Reply-To: Your message of "Thu, 03 Aug 2000 08:36:02 EDT."
<Pine.GSO.4.10.10008030830180.16362-100000@gladstone>
Date: Thu, 03 Aug 2000 09:33:46 -0700
From: Lorenzo Vicisano <lorenzo@cisco.com>
Sender: owner-rmt@lbl.gov
Precedence: bulk
Ken,
Your work seems to be very relevant to the chater of this WG
in the context of GRA (see draft-ietf-rmt-gra-arch-01.txt).
You might want to contact the authors of this draft and see if you
can coordinate your effort with theirs.
cheers,
Lorenzo
> We'd like to call your attention to draft-calvert-concast-svc-00.txt,
> which describes the concast many-to-one service. After looking over the
> current drafts and hearing the presentations earlier this week, it appears
> that Concast would make a good RM building block. It is useful for
> aggregation of feedback, both ack/nack and congestion-related.
>
> We'd appreciate any comments. The draft describes the service independent
> of RM, because it is also useful outside the context of multicast.
>
> Cheers,
>
> KC
> --
> Ken Calvert calvert@dcs.uky.edu
> Associate Professor ***************NOTE NEW AREA CODE = 859
> Computer Science, 773 Anderson Hall +1.859.257.6745
> University of Kentucky Fax: +1.859.323.1971
> Lexington, KY 40506-0046 http://www.cs.uky.edu/~calvert/
>
>
>From owner-rmt@listserv.lbl.gov Fri Aug 11 04:05:50 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id EAA02848;
Fri, 11 Aug 2000 04:02:05 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id EAA02840
for <rmt@listserv.lbl.gov>; Fri, 11 Aug 2000 04:02:02 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id EAA23092
for <rmt@listserv.lbl.gov>; Fri, 11 Aug 2000 04:02:01 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id EAA23087
for <rmt@lbl.gov>; Fri, 11 Aug 2000 04:02:00 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08886;
Fri, 11 Aug 2000 07:01:59 -0400 (EDT)
Message-Id: <200008111101.HAA08886@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: rmt@lbl.gov
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-rmt-norm-bb-00.txt
Date: Fri, 11 Aug 2000 07:01:58 -0400
Sender: owner-rmt@lbl.gov
Precedence: bulk
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Reliable Multicast Transport Working Group of the IETF.
Title : NACK-Oriented Reliable Multicast (NORM) Protocol
Building Blocks
Author(s) : B. Adamson, C. Bormann, S. Floyd,
M. Handley, J. Macker
Filename : draft-ietf-rmt-norm-bb-00.txt
Pages : 25
Date : 10-Aug-00
This memo describes issues related to the creation of negative-
acknowledgment (NACK) oriented reliable multicast (NORM) protocols.
The general goals and assumptions for NORM are defined. The tech-
nical challenges related to NACK-oriented (and in some cases gen-
eral) reliable multicast protocol design are identified. These
challenges are resolved into a set of applicable 'building blocks'
which are described in further detail. It is anticipated that
these building blocks (as they are further refined and defined in
future revisions of this document) will be useful in generating
different instantiations of reliable multicast protocols.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rmt-norm-bb-00.txt
Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-rmt-norm-bb-00.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.
Send a message to:
mailserv@ietf.org.
In the body type:
"FILE /internet-drafts/draft-ietf-rmt-norm-bb-00.txt".
NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv@ietf.org"
Content-Type: text/plain
Content-ID: <20000810140221.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-rmt-norm-bb-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-rmt-norm-bb-00.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <20000810140221.I-D@ietf.org>
--OtherAccess--
--NextPart--
>From owner-rmt@listserv.lbl.gov Fri Aug 11 07:07:24 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id HAA29896;
Fri, 11 Aug 2000 07:05:28 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id HAA29842
for <rmt@listserv.lbl.gov>; Fri, 11 Aug 2000 07:05:24 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id HAA07501
for <rmt@listserv.lbl.gov>; Fri, 11 Aug 2000 07:05:23 -0700 (PDT)
Received: from picard.noroff.no ([212.20.204.3])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id HAA07491
for <rmt@lbl.gov>; Fri, 11 Aug 2000 07:05:22 -0700 (PDT)
Received: by picard.noroff.no (Postfix, from userid 815)
id 1376122002; Fri, 11 Aug 2000 16:49:40 +0200 (CEST)
Received: from loki.ietf.org (loki.ietf.org [132.151.1.177])
by picard.noroff.no (Postfix) with ESMTP id BCECAB3802
for <magg@NOROFF.NO>; Fri, 11 Aug 2000 16:49:37 +0200 (CEST)
Received: (from adm@localhost)
by loki.ietf.org (8.9.1b+Sun/8.9.1) id JAA11482
for ietf-123-outbound.09@ietf.org; Fri, 11 Aug 2000 09:25:01 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [10.27.2.28])
by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id HAA10105
for <all-ietf@loki.ietf.org>; Fri, 11 Aug 2000 07:01:59 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08886;
Fri, 11 Aug 2000 07:01:59 -0400 (EDT)
Message-Id: <200008111101.HAA08886@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: rmt@lbl.gov
From: Internet-Drafts@ietf.org
Reply-To: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-rmt-norm-bb-00.txt
Date: Fri, 11 Aug 2000 07:01:58 -0400
X-AntiVirus: scanned for viruses by Amavis 0.2.1-pre2
Sender: owner-rmt@lbl.gov
Precedence: bulk
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Reliable Multicast Transport Working Group of the IETF.
Title : NACK-Oriented Reliable Multicast (NORM) Protocol
Building Blocks
Author(s) : B. Adamson, C. Bormann, S. Floyd,
M. Handley, J. Macker
Filename : draft-ietf-rmt-norm-bb-00.txt
Pages : 25
Date : 10-Aug-00
This memo describes issues related to the creation of negative-
acknowledgment (NACK) oriented reliable multicast (NORM) protocols.
The general goals and assumptions for NORM are defined. The tech-
nical challenges related to NACK-oriented (and in some cases gen-
eral) reliable multicast protocol design are identified. These
challenges are resolved into a set of applicable 'building blocks'
which are described in further detail. It is anticipated that
these building blocks (as they are further refined and defined in
future revisions of this document) will be useful in generating
different instantiations of reliable multicast protocols.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rmt-norm-bb-00.txt
Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-rmt-norm-bb-00.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.
Send a message to:
mailserv@ietf.org.
In the body type:
"FILE /internet-drafts/draft-ietf-rmt-norm-bb-00.txt".
NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv@ietf.org"
Content-Type: text/plain
Content-ID: <20000810140221.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-rmt-norm-bb-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-rmt-norm-bb-00.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <20000810140221.I-D@ietf.org>
--OtherAccess--
--NextPart--
>From owner-rmt@listserv.lbl.gov Tue Aug 15 17:45:53 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id RAA24015;
Tue, 15 Aug 2000 17:42:34 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id RAA24011
for <rmt@listserv.lbl.gov>; Tue, 15 Aug 2000 17:42:28 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id RAA09591
for <rmt@listserv.lbl.gov>; Tue, 15 Aug 2000 17:42:27 -0700 (PDT)
Received: from tech.cisco.com (tech.cisco.com [161.44.224.17])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id RAA09588
for <rmt@lbl.gov>; Tue, 15 Aug 2000 17:42:27 -0700 (PDT)
Received: from ORANLT ([171.71.147.155]) by tech.cisco.com
(Netscape Messaging Server 3.61) with SMTP id AAA5CAB
for <rmt@lbl.gov>; Tue, 15 Aug 2000 20:42:42 -0400
From: "Dave Oran" <oran@cisco.com>
To: <rmt@lbl.gov>
Subject: FW: Adding reliable transport layer above sgm/xcsat
Date: Tue, 15 Aug 2000 20:41:54 -0400
Message-ID: <NDBBKHCGKKIOOIJEGCOEOEGBDNAA.oran@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-rmt@lbl.gov
Precedence: bulk
-----Original Message-----
From: owner-xcast@public.alcatel.com
[mailto:owner-xcast@public.alcatel.com]On Behalf Of Tal Anker
Sent: Tuesday, August 15, 2000 7:27 AM
To: xcast@public.alcatel.com
Cc: dolev@cs.huji.ac.il
Subject: Adding reliable transport layer above sgm/xcsat
Hi,
We would like to share some thoughts on the benefit from the xcast
model (or sgm) to small group multicast applications. In particular,
we have been playing with reliable multicast transport layers in the
last few years. A reliable transport for small group multicast may not
be important for video conference application, but for other
collaborative application such as shared editor or shared drawing
board (whiteboard) it may be very usefull. Since the reliable
multicast working group concentrate (for now) on one-to-many within
the SSM architecture, this issue may fit to this
working group.
To trigger a discussion, we have comprised a list of issues that come up
when implementing reliale transport layer for multicast:
1) Fault detection - in xcast this is pretty simple to handle. In
large groups, the need to probe for liveness of every member is a
problem for the scalability proporty. In xcast, it becomes much simple
to handle. For instance every source can "ping" the liveness of all
the receivers in the members list, which leads us to the next item:
2) Dynamic Group Membership - In xcast every source is requested to
know the members list apriori. In general, learning the potential
group of members is a chalange. Special challange is the aggreement on
the "view" of the group - i.e., aggreement on the active members list.
In xcast, leader based or token based algorithms can be easily used.
3) Messages ordering - This is a problem that was discussed in various
forums and communities. Ordering is an important property for various
applications, such as distributed database applications or shared
whiteboards, etc. Typicall applications in xcast may not require a
full fledge database consistency requirements, but will certainly
benefit from various ordering properties. In particular, consider a
shared editor or whiteboard that a small group of participants
use. Consider scenarios where someone deletes an object fron the
drawing board, and another is moving the object around. An ordering
property (such as Total ordering) can resolve these conflicts
relatiely easily. We think that the xcast model alleviates the
deployments of ordering algorithms. For instance, logical "token based"
algorithms or leader based algorithms are very feasible for
implementation in the xcast model.
4) Buffering messages for retransmissions: When the group is small,
there is no real prolem in "saving" messages for later
retransmissions. This may not be nessary for video conferencing, but
wheh the conference is coupled with shared text editor or shared
drawing board, the two latter applications are sure to benefit from
this kind of reliability.
5) Flow control for small group multicast: We think that flow control
for small groups is a much easier problem to solve. For instance, one
can even think on maintaining a sliding window per receiver (from the
source point of view).
6) Handling leave/join of members: When a new member joins the group,
the fact that the group is of small size makes it easier to build a
"digest" of the group state and transferring this digest to the
newcomer. The convergence of the group membership changes is much
faster.
7) handling network partitions/merges: In case there is a link that
has failed, some of the group members may be temporary
partitioned. This calls for the reliability layer to adapt to such
cases, and do not try and attempt recovering/retransmitting messages
that were sent within each partition. This is a sort of a "can of
worms" and is heavily discusses within the area of Group Communication
Systems. We suggest to put it away at this time. In any case, in small
groups there is a high chance that a sort of temporary "relays" can be
constructed within the period of partition. These relays are
point-to-point communication channels that can bridge accross
partiotions (given that logical transitivity exist).
Comments? opinions? anything :) ?
Danny & Tal
=====================================
Institute of Computer Science
The Hebrew University of Jerusalem,
Givat Ram, Jerusalem 91904
Israel
>From owner-rmt@listserv.lbl.gov Tue Aug 15 18:15:34 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id SAA24053;
Tue, 15 Aug 2000 18:13:47 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id SAA24049
for <rmt@listserv.lbl.gov>; Tue, 15 Aug 2000 18:13:45 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id SAA14098
for <rmt@listserv.lbl.gov>; Tue, 15 Aug 2000 18:13:45 -0700 (PDT)
Received: from aardvark.aciri.org (aardvark.aciri.org [192.150.187.20])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id SAA14095
for <rmt@lbl.gov>; Tue, 15 Aug 2000 18:13:45 -0700 (PDT)
Received: from aardvark.aciri.org (localhost [127.0.0.1])
by aardvark.aciri.org (8.9.3/8.9.3) with ESMTP id SAA46797;
Tue, 15 Aug 2000 18:13:38 -0700 (PDT)
(envelope-from mjh@aardvark.aciri.org)
From: Mark Handley <mjh@aciri.org>
X-Organisation: ACIRI
To: "Dave Oran" <oran@cisco.com>
cc: rmt@lbl.gov
Subject: Re: FW: Adding reliable transport layer above sgm/xcsat
In-reply-to: Your message of "Tue, 15 Aug 2000 20:41:54 EDT."
<NDBBKHCGKKIOOIJEGCOEOEGBDNAA.oran@cisco.com>
Date: Tue, 15 Aug 2000 18:13:38 -0700
Message-ID: <46795.966388418@aardvark.aciri.org>
Sender: owner-rmt@lbl.gov
Precedence: bulk
The advantages they state seem to apply to any small group, whether
based on SGM, Internet Standard multicast or SSM. I don't see how SGM
helps.
Also not all RM protocols need to know who the receivers are.
(e.g. digital fountain approaches don't care who the receivers are)
Requiring the sender to know who the receivers are is therefore an
impediment, not an advantage.
The advantages of SGM (if any) do not seem to be at the
transport/application layer to me. The one exception might be the
very limited security gain you get by having slightly more control
over who receives the traffic. However IMHO such security gain is a
poor substitute for decent encryption.
Cheers,
Mark
>-----Original Message-----
>From: owner-xcast@public.alcatel.com
>[mailto:owner-xcast@public.alcatel.com]On Behalf Of Tal Anker
>Sent: Tuesday, August 15, 2000 7:27 AM
>To: xcast@public.alcatel.com
>Cc: dolev@cs.huji.ac.il
>Subject: Adding reliable transport layer above sgm/xcsat
>
>
>
>Hi,
>
>We would like to share some thoughts on the benefit from the xcast
>model (or sgm) to small group multicast applications. In particular,
>we have been playing with reliable multicast transport layers in the
>last few years. A reliable transport for small group multicast may not
>be important for video conference application, but for other
>collaborative application such as shared editor or shared drawing
>board (whiteboard) it may be very usefull. Since the reliable
>multicast working group concentrate (for now) on one-to-many within
>the SSM architecture, this issue may fit to this
>working group.
>
>To trigger a discussion, we have comprised a list of issues that come up
>when implementing reliale transport layer for multicast:
>
>1) Fault detection - in xcast this is pretty simple to handle. In
>large groups, the need to probe for liveness of every member is a
>problem for the scalability proporty. In xcast, it becomes much simple
>to handle. For instance every source can "ping" the liveness of all
>the receivers in the members list, which leads us to the next item:
>
>2) Dynamic Group Membership - In xcast every source is requested to
>know the members list apriori. In general, learning the potential
>group of members is a chalange. Special challange is the aggreement on
>the "view" of the group - i.e., aggreement on the active members list.
>In xcast, leader based or token based algorithms can be easily used.
>
>3) Messages ordering - This is a problem that was discussed in various
>forums and communities. Ordering is an important property for various
>applications, such as distributed database applications or shared
>whiteboards, etc. Typicall applications in xcast may not require a
>full fledge database consistency requirements, but will certainly
>benefit from various ordering properties. In particular, consider a
>shared editor or whiteboard that a small group of participants
>use. Consider scenarios where someone deletes an object fron the
>drawing board, and another is moving the object around. An ordering
>property (such as Total ordering) can resolve these conflicts
>relatiely easily. We think that the xcast model alleviates the
>deployments of ordering algorithms. For instance, logical "token based"
>algorithms or leader based algorithms are very feasible for
>implementation in the xcast model.
>
>4) Buffering messages for retransmissions: When the group is small,
>there is no real prolem in "saving" messages for later
>retransmissions. This may not be nessary for video conferencing, but
>wheh the conference is coupled with shared text editor or shared
>drawing board, the two latter applications are sure to benefit from
>this kind of reliability.
>
>5) Flow control for small group multicast: We think that flow control
>for small groups is a much easier problem to solve. For instance, one
>can even think on maintaining a sliding window per receiver (from the
>source point of view).
>
>6) Handling leave/join of members: When a new member joins the group,
>the fact that the group is of small size makes it easier to build a
>"digest" of the group state and transferring this digest to the
>newcomer. The convergence of the group membership changes is much
>faster.
>
>7) handling network partitions/merges: In case there is a link that
>has failed, some of the group members may be temporary
>partitioned. This calls for the reliability layer to adapt to such
>cases, and do not try and attempt recovering/retransmitting messages
>that were sent within each partition. This is a sort of a "can of
>worms" and is heavily discusses within the area of Group Communication
>Systems. We suggest to put it away at this time. In any case, in small
>groups there is a high chance that a sort of temporary "relays" can be
>constructed within the period of partition. These relays are
>point-to-point communication channels that can bridge accross
>partiotions (given that logical transitivity exist).
>
>Comments? opinions? anything :) ?
>
>Danny & Tal
>
>=====================================
>Institute of Computer Science
>The Hebrew University of Jerusalem,
>Givat Ram, Jerusalem 91904
>Israel
>
>
>From owner-rmt@listserv.lbl.gov Wed Aug 16 01:20:22 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id BAA24726;
Wed, 16 Aug 2000 01:18:15 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id BAA24722
for <rmt@listserv.lbl.gov>; Wed, 16 Aug 2000 01:18:14 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id BAA16839
for <rmt@listserv.lbl.gov>; Wed, 16 Aug 2000 01:18:13 -0700 (PDT)
Received: from cs.huji.ac.il (cs.huji.ac.il [132.65.16.10])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id BAA16831
for <rmt@lbl.gov>; Wed, 16 Aug 2000 01:18:07 -0700 (PDT)
Received: from haserver.cs.huji.ac.il ([132.65.200.200] ident=exim)
by cs.huji.ac.il with esmtp (Exim 3.15 #1)
id 13OyOY-0004ME-00; Wed, 16 Aug 2000 11:17:54 +0300
Received: from anker by haserver.cs.huji.ac.il with local (Exim 3.15 #1)
id 13OyOX-0001fM-00; Wed, 16 Aug 2000 11:17:53 +0300
Date: Wed, 16 Aug 2000 11:17:53 +0300 (IDT)
From: Tal Anker <anker@cs.huji.ac.il>
To: Mark Handley <mjh@aciri.org>
cc: Dave Oran <oran@cisco.com>, rmt@lbl.gov, xcast@public.alcatel.com,
dolev@cs.huji.ac.il
Subject: Re: FW: Adding reliable transport layer above sgm/xcsat
In-Reply-To: <46795.966388418@aardvark.aciri.org>
Message-ID: <Pine.BSI.4.20_heb2.08.0008161108440.891-100000@haserver.cs.huji.ac.il>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-rmt@lbl.gov
Precedence: bulk
On Tue, 15 Aug 2000, Mark Handley wrote:
>
> The advantages they state seem to apply to any small group, whether
> based on SGM, Internet Standard multicast or SSM.I don't see how SGM
> helps.
That is almost correct with one thing different (you already said it
bellow): there is more control on who are the receivers that receives the
traffic. There are many reliable multicast "flavors", and to some of them
the membership (of receivers and sources) is important. When the
membership is known, it is much easier to give stronger semantics to the
user application, e.g., to guarantee that ALL the messages will be
delivered to ALL the alive receivers. This is obviously requires failure
detector (in the transport layer) in order to declare a receiver
"faulty" and thus enable the progression within the group (otherwise, the
source might get stuck and wait for acks from a faulty receiver). These
kind of protocols make it easier to build shared whiteboard/editor, where
the consistency of the object that is shared is important.
- Tal.
>
> Also not all RM protocols need to know who the receivers are.
> (e.g. digital fountain approaches don't care who the receivers are)
> Requiring the sender to know who the receivers are is therefore an
> impediment, not an advantage.
>
> The advantages of SGM (if any) do not seem to be at the
> transport/application layer to me.The one exception might be the
> very limited security gain you get by having slightly more control
> over who receives the traffic.However IMHO such security gain is a
> poor substitute for decent encryption.
>
> Cheers,
> Mark
>
>
>
>From owner-rmt@listserv.lbl.gov Thu Aug 17 10:18:29 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id KAA03017;
Thu, 17 Aug 2000 10:14:58 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id KAA03013
for <rmt@listserv.lbl.gov>; Thu, 17 Aug 2000 10:14:56 -0700 (PDT)
From: announce@leisurewebcams.com
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id KAA12493
for <rmt@listserv.lbl.gov>; Thu, 17 Aug 2000 10:14:54 -0700 (PDT)
Received: from mail.yourdomain.com (m319-mp1-cvx1a.man.ntl.com [62.252.197.63])
by SpamWall.lbl.gov (8.9.3/8.9.3) with SMTP id KAA12468
for <rmt@lbl.gov>; Thu, 17 Aug 2000 10:14:51 -0700 (PDT)
Message-Id: <200008171714.KAA12468@SpamWall.lbl.gov>
Date: Thu, 17 Aug 2000 14:39:06
To: <rmt@lbl.gov>
Subject: LeisureWebcams.com - See the World
Sender: owner-rmt@lbl.gov
Precedence: bulk
LeisureWebcams.com is a recently launched website
specialising in providing free LIVE access to over
1,500 webcams and 2,000 Tourist Offices world wide.
Check it out:-
http://www.leisurewebcams.com/
This offers you the chance to check out live and
frequently updated images of your chosen location
through the webcams and get detailed local knowledge
through the Tourist Offices. Along with booking
holidays direct through our travel partner, there is
the opportunity to sell your unwanted clothes and
equipment through our free Swap Shop.
There is a lot to see, so if you have enjoyed your
trip through our site, do tell your friends and let
us know through 'Your Views'. If you have any
suggestions for the site, or queries, please feel
free to contact me at cy@LeisureWebcams.com.
I look forward to hearing from you.
Kind regards,
Charlie Yates
MARKETING DIRECTOR
LeisureWebcams.com
>From owner-rmt@listserv.lbl.gov Fri Aug 18 09:41:04 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id JAA18194;
Fri, 18 Aug 2000 09:37:14 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id JAA18190
for <rmt@listserv.lbl.gov>; Fri, 18 Aug 2000 09:37:12 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id JAA25942
for <rmt@listserv.lbl.gov>; Fri, 18 Aug 2000 09:37:11 -0700 (PDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id JAA25937
for <rmt@lbl.gov>; Fri, 18 Aug 2000 09:37:11 -0700 (PDT)
Received: from ISI.EDU (jet.isi.edu [128.9.160.87])
by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id JAA25974;
Fri, 18 Aug 2000 09:37:07 -0700 (PDT)
Message-Id: <200008181637.JAA25974@boreas.isi.edu>
To: IETF-Announce: ;
Subject: RFC 2887 on Multicast Design Space for Bulk Data Transfer
Cc: rfc-ed@ISI.EDU, rmt@lbl.gov
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Fri, 18 Aug 2000 09:37:07 -0700
From: RFC Editor <rfc-ed@ISI.EDU>
Sender: owner-rmt@lbl.gov
Precedence: bulk
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 2887
Title: The Reliable Multicast Design Space for Bulk Data
Transfer
Author(s): M. Handley, S. Floyd, B. Whetten, R. Kermode,
L. Vicisano, M. Luby
Status: Informational
Date: August 2000
Mailbox: mjh@aciri.org, floyd@aciri.org,
whetten@talarian.com, Roger.Kermode@motorola.com,
lorenzo@cisco.com, luby@digitalfountain.com
Pages: 22
Characters: 51135
Updates/Obsoletes/SeeAlso: None
I-D Tag: draft-ietf-rmt-design-space-01.txt
URL: ftp://ftp.isi.edu/in-notes/rfc2887.txt
The design space for reliable multicast is rich, with many possible
solutions having been devised. However, application requirements
serve to constrain this design space to a relatively small solution
space. This document provides an overview of the design space and the
ways in which application constraints affect possible solutions.
This document is a product of the Reliable Multicast Transport Working
Group of the IETF.
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST@IETF.ORG. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info@RFC-EDITOR.ORG
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for special distribution should be addressed to either the
author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo
Submissions for Requests for Comments should be sent to
RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC
Authors, for further information.
Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute
...
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the RFCs.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="RFC-INFO@RFC-EDITOR.ORG"
Content-Type: text/plain
Content-ID: <000818093455.RFC@RFC-EDITOR.ORG>
RETRIEVE: rfc
DOC-ID: rfc2887
--OtherAccess
Content-Type: Message/External-body;
name="rfc2887.txt";
site="ftp.isi.edu";
access-type="anon-ftp";
directory="in-notes"
Content-Type: text/plain
Content-ID: <000818093455.RFC@RFC-EDITOR.ORG>
--OtherAccess--
--NextPart--
>From owner-rmt@listserv.lbl.gov Tue Aug 22 04:34:44 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id EAA04811;
Tue, 22 Aug 2000 04:31:17 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id EAA04807
for <rmt@listserv.lbl.gov>; Tue, 22 Aug 2000 04:31:15 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id EAA29513
for <rmt@listserv.lbl.gov>; Tue, 22 Aug 2000 04:31:14 -0700 (PDT)
Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id EAA29510
for <rmt@lbl.gov>; Tue, 22 Aug 2000 04:31:13 -0700 (PDT)
Received: [from pobox3.mot.com ([10.64.251.242]) by motgate2.mot.com (motgate2 2.1) with ESMTP id EAA15759 for <rmt@lbl.gov>; Tue, 22 Aug 2000 04:31:12 -0700 (MST)]
Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [217.1.10.38]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id EAA03759 for <rmt@lbl.gov>; Tue, 22 Aug 2000 04:30:18 -0700 (MST)]
Received: from arc.corp.mot.com ([217.2.31.199])
by homer.arc.corp.mot.com (8.10.2/8.10.2) with ESMTP id e7MBV8s23311
for <rmt@lbl.gov>; Tue, 22 Aug 2000 21:31:09 +1000 (EST)
Message-ID: <39A26474.7623C9D2@arc.corp.mot.com>
Date: Tue, 22 Aug 2000 21:31:00 +1000
From: Roger Kermode <rkermode@arc.corp.mot.com>
Reply-To: Roger.Kermode@motorola.com
Organization: Motorola
X-Mailer: Mozilla 4.73 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: rmt-list <rmt@lbl.gov>
Subject: RMT Slides...
Content-Type: multipart/mixed;
boundary="------------DCD90943EAD0A24B08893E73"
Sender: owner-rmt@lbl.gov
Precedence: bulk
This is a multi-part message in MIME format.
--------------DCD90943EAD0A24B08893E73
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Dear RMT Pittsburgh Presenters,
if you have not yet submitted your slides for
inclusion in the IETF proceedings please
do so by sending them to minutes@ietf.org.
thanks!
Roger
--------------DCD90943EAD0A24B08893E73
Content-Type: text/x-vcard; charset=us-ascii;
name="rkermode.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Roger Kermode
Content-Disposition: attachment;
filename="rkermode.vcf"
begin:vcard
n:Kermode;Roger
tel;cell:+61-408-212-284
tel;fax:+61-2-9666-0501
tel;home:+61-2-9664-8335
tel;work:+61-2-9666-0558
x-mozilla-html:FALSE
url:www.mot.com.au
org:Motorola Australian Research Centre;Communications and Networking Lab
version:2.1
email;internet:Roger.Kermode@motorola.com
title:Principal Research Engineer, Manager
adr;quoted-printable:;;Level 3,=0D=0A12 Lord St.;Botany;NSW;2019;Australia
fn:Roger Kermode
end:vcard
--------------DCD90943EAD0A24B08893E73--
>From owner-rmt@listserv.lbl.gov Sun Aug 27 11:04:59 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id LAA24975;
Sun, 27 Aug 2000 11:00:58 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id LAA24971
for <rmt@listserv.lbl.gov>; Sun, 27 Aug 2000 11:00:56 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id LAA22971
for <rmt@listserv.lbl.gov>; Sun, 27 Aug 2000 11:00:55 -0700 (PDT)
Received: from tech.cisco.com (tech.cisco.com [161.44.224.17])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id LAA22963
for <rmt@lbl.gov>; Sun, 27 Aug 2000 11:00:54 -0700 (PDT)
Received: from ORANLT ([171.69.210.12]) by tech.cisco.com
(Netscape Messaging Server 3.61) with SMTP id AAA2C0F;
Sun, 27 Aug 2000 14:01:14 -0400
From: "Dave Oran" <oran@cisco.com>
To: <rhboivie@us.ibm.com>
Cc: <xcast@public.alcatel.com>, <rmt@lbl.gov>
Subject: RE: Adding reliable transport layer above sgm/xcsat
Date: Sun, 27 Aug 2000 14:00:20 -0400
Message-ID: <EAEEJFPMJNAIPMIPBEEGCEGACEAA.oran@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <85256944.0065FD30.00@d54mta04.raleigh.ibm.com>
Sender: owner-rmt@lbl.gov
Precedence: bulk
My knowledge of reliable multicast is spotty at best, so I wade in here with
some trepidation. Since this is a side issue wrt SGM, feel free to drop this
thread at any point. I just want to make sure that any claims are
supportable with analysis or hard facts. See below.
> -----Original Message-----
> From: rhboivie@us.ibm.com [mailto:rhboivie@us.ibm.com]
> Sent: Wednesday, August 23, 2000 2:34 PM
> To: Dave Oran
> Cc: xcast@public.alcatel.com
> Subject: RE: FW: FW: Adding reliable transport layer above sgm/xcsat
>
>
>
>
> >> >
> >> > The advantages they state seem to apply to any small group, whether
> >> > based on SGM, Internet Standard multicast or SSM. I don't
> see how SGM
> >> > helps.
> >>
> >> It is not true that the advantages apply to any small group. The
> >> distinguishing characteristic of SGM is that it can easily send to a
> >> subset of the destinations, which makes things like reliability and
> >> congestion control easier.
> >>
> >I'm not sure this dicussion is getting us anywhere, but I don't follow
> >Dirk's contention that having explicitly-addressed subsets of the group
> >helps in any substantial way for congestion control or reliability. An
> >explanation might help.
>
> The explicit list of addresses helps with respect to reliability in
> a couple of ways.
> - you know the address(es) at the other end which is helpful if
> you want to implement "end-to-end" reliability
In order to have any sort of end-to-end reliability, you either use FEC or
feedback to the transmitter. In the case of FEC the transmitter never finds
out (or needs to find out) who the receiver(s) is/are. In the case of
feedback, the feedback contains the (unicast) source address of the receiver
and hence you can target retransmissions via unicast if need be.
> - it's easy with SGM to send "appropriate" retransmissions when
> retransmissions are needed. ie you can send an SGM packet to
> the subset of destinations that have not acked, say, or to the
> subset that have nacked, say, and the retransmission is "optimal"
> in terms of the network bandwidth consumed.
Well, if you use ACKs/NAKs then the main problem is the number of ACKs/NAKs,
right? That's why nearly all rmt schemes use some form of ACK/NAK
elimination to avoid implosion. There may be some savings if you use
explicit multicast addressing for the retransmissions, but that savings
depends sensitively on where the losses occur (the closer to the source, the
better you do, I suppose). There is also the problem with estimating the
RTT, and hence tuning the retransmission scheme, which I don't think
explicit multicast doesn't helps with at all. If you don't have the timers
tuned you will wind up with multiple retransmissions to different subsets
and hence may have even less gain over multi-unicast, or pure multicast.
> - the routers don't have to do much to support reliable SGM (ie
> they don't have to do anything other than support unreliable SGM)
Well, that's true of some of the RMT schemes as well. For schemes that do
have router state, the difference is that with RMT the router state is
viewed as optimizations and the sources don't have to get involved in
figuring out the optimal strategy.
> - i.e. they don't have to keep track of multicast group
> state and they don't have to do retransmissions
> (since reliability would be end-to-end)
Some schemes have routers only holding protocol state and not data state and
hence the routers don't actually do any retransmissions. Note that
reliability is still end-to-end because the router state is used only as an
optimization.
> - the routers don't have to build special multicast trees
> when a source needs to send a retransmission to a subset
> of the destinations. (The tree for the retransmission
> is built (as is always the case in SGM) "on the fly" as
> the packet flows from the source to the destinations.)
>
I do not believe I know of schemes which build special trees. Some schemes
are smart and prune the existing tree to the subtree needed to cover the
receivers which need the retransmission, but this is not a tree computation.
> Of course the fact that the groups are "small" is also helpful.
>
Right. The question again is whether there is any gain compared to "rmt
classic" *for groups of identical size*. Has anyone actually done any
analysis or simulation? Some of these properties are anti-intuitive and need
hard justification.
> re: congestion control, if you have end-to-end awareness (as you have
> in SGM) you can implement end-to-end congestion control. And the
> fact that you can easily send to a subset helps too as Dirk mentioned.
>
I think I disagree with this, but I'm on REALLY shaky ground here so please
correct me as needed. The reason congestion control is hard for multicast in
general (and RMT in particular) is because you don't know where the
bottlenecks are relative to the delivery tree and because each receiver is
seeing a potentially different congestion environment. As long as the source
is going to try to get one packet to multiple destinations, no matter how it
does so, this fact doesn't change.
> You said you're "not sure this discussion is getting us anywhere".
> Well it has brought out certain points such as the fact that if one
> is using "conference bridges", it seems more appropriate to use
> SGM than "classical multicast" as Yuji has explained in his note.
>
I don't know at all how you got there. I didn't respond to Yuji's note
because I assumed he was just pointing out that if you did (audio)
conference bridges with SGM, that would win over multi-unicast. If you
factor out the group-state-in-the-routers, the optimal strategy is each
source unicasting to the bridge, and the bridge unicasting back to the
active sources (since each sees a unique mix), and multicasting to the
non-active sources. Since any even half-way rational conference only has
multiple simultaneous talkers for a brief back-off period, I don't see how
you can do better than normal multicast from the bridge to the receivers.
There are also hybrid techniques which I won't go into that optimize the
multicast case further.
> On the larger point of making progress, I'm ok with either of the
> problem statements that you proposed for the working group in a note
> a little while back. (If I had to choose I mightly lean slightly
> toward the first one.)
> And I haven't heard any feedback to the contrary so perhaps we should
> formally kick off an effort to address one or both of those problem
> statements.
>
I'm going to call the question at the end of the coming week.
> Is there any reason why we shouldn't?
>
Yes. I think the jury is still out. I'd really like to hear from a wider
audience than we've been hearing from.
Dave.
>
>
>
>From owner-rmt@listserv.lbl.gov Mon Aug 28 12:34:47 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id MAA28697;
Mon, 28 Aug 2000 12:31:01 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id MAA28693
for <rmt@listserv.lbl.gov>; Mon, 28 Aug 2000 12:30:59 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id MAA08248
for <rmt@listserv.lbl.gov>; Mon, 28 Aug 2000 12:30:58 -0700 (PDT)
Received: from computer (209-128-164-153.dial-up.ipa.net [209.128.164.153])
by SpamWall.lbl.gov (8.9.3/8.9.3) with SMTP id MAA08103
for <rmt@lbl.gov>; Mon, 28 Aug 2000 12:30:39 -0700 (PDT)
Message-Id: <200008281930.MAA08103@SpamWall.lbl.gov>
From: "Lloyd Gibson" <jerryg26@hotmail.com>
To: <rmt@lbl.gov>
Subject: Secrets of New Millonaires
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Date: Mon, 28 Aug 2000 14:31:14
Sender: owner-rmt@lbl.gov
Precedence: bulk
Secrets of New Millonaires
>
>
> >
> > ----- Original Message -----
> > From: "Tom Anderson" <billa30@hotmail.com>
> > To: <bjgib@ipa.net>
> > Sent: Thursday, June 22, 2000 2:19 PM
> > Subject: Fwd: Secrets of New Millionaires
> >
> >
> > >
> > >
> > >
> > > >From: "Lloyd Gibson" <jerryg26@hotmail.com>
> > > >To: billa30@hotmail.com
> > > >Subject: Fwd: Secrets of New Millionaires
> > > >Date: Wed, 14 Jun 2000 13:04:28 CDT
> > > >
> > > >
> > > >
> > > >
> > > >>From: <webfinderz00@Yahoo.com>
> > > >>Subject: Secrets of New Millionaires
> > > >>Date: Wed, 26 Apr 2000 02:47:02
> > > >>Received: from [4.3.96.183] by hotmail.com (3.2) with ESMTP id
> > > >>MHotMailBAD01C76007BD82197D4040360B709610; Wed Apr 26 04:22:35 2000
> > > >>From webfinderz00@Yahoo.com Wed Apr 26 04:26:05 2000
> > > >>Message-Id: <331.824584.698332@server>
> > > >>
> > > >>Dear Friend,
> > > >>
> > > >>You can earn $50,000 or more in the next 90 days
> > > >>sending e-mail.
> > > >>
> > > >> Seem impossible? Read on for details.
> > > >>
> > > >> "AS SEEN ON NATIONAL TV"
> > > >>
> > > >> Thank you for your time and interest. This is the
> > > >>letter you've been reading about in the news lately.
> > > >>Due to the popularity of this letter on the Internet,
> > > >>a major nightly news program recently devoted an
> > > >>entire show to the investigation of the program
> > > >>described below to see if it really can make people
> > > >>money.
> > > >>
> > > >> The show also investigated whether or not the
> > > >>program was legal. Their findings proved once and for
> > > >>all that there are absolutely no laws prohibiting the
> > > >>participation in the program. This has helped to show
> > > >>people that this is a simple, harmless and fun way to
> > > >>make some extra money at home.
> > > >>
> > > >> The results of this show have been truly
> > > >>remarkable. So many people are participating that
> > > >>those involved are doing much better than ever before.
> > > >>Since everyone makes more as more people try it out,
> > > >>it's been very exciting to be a part of lately. You
> > > >>will understand once you experience it.
> > > >>
> > > >> I did and so far it's going great! HERE IT IS BELOW:
> > > >>
> > > >> *** Print This Now For Future Reference ***
> > > >>
> > > >> The following income opportunity is one you may be
> > > >>interested in taking a look at. It can be started with
> > > >>VERY LITTLE investment and the income return is
> > > >>TREMENDOUS!!!
> > > >>
> > > >> $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
> > > >>
> > > >> If you would like to make at least $50,000 in less
> > > >>than 90 days! Please read the enclosed program...THEN
> > > >>READ IT AGAIN!!!
> > > >>
> > > >> $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
> > > >>
> > > >> THIS IS A LEGITIMATE, LEGAL, MONEY MAKING
> > > >>OPPORTUNITY. It does not require you to come into
> > > >>contact with people, do any hard work, and best of
> > > >>all, you never have to leave the house except to get
> > > >>the mail.
> > > >>
> > > >> If you believe that someday you'll get that big
> > > >>break that you've been waiting for, THIS IS IT!
> > > >>
> > > >> Simply follow the instructions, and your dreams
> > > >>will come true.
> > > >>
> > > >> This multi-level e-mail order marketing program
> > > >>works perfectly...100% EVERYTIME.
> > > >>
> > > >> E-mail is the sales tool of the future. Take
> > > >>advantage of this non-commercialized method of
> > > >>advertising NOW!!! The longer you wait, the more
> > > >>people will be doing business using e-mail. Get your
> > > >>piece of this action!!!
> > > >>
> > > >> MULTI-LEVEL MARKETING (MLM) has finally gained
> > > >>respectability. It is being taught in the Harvard
> > > >>Business School, and both Stanford Research and the
> > > >>Wall Street Journal have stated that between 50% and
> > > >>65% of all goods and services will be sold through
> > > >>multi-level methods by the mid to late 1990's.
> > > >>
> > > >> This is a Multi-Billion Dollar industry and of the
> > > >>500,000 millionaires in the U.S., 20% (100,000) made
> > > >>their fortune in the last several years in MLM.
> > > >> Moreover, statistics show 45 people become
> > > >>millionaire's everyday through Multi-Level Marketing.
> > > >>
> > > >> You may have heard this story before, but over the
> > > >>summer Donald Trump made an appearance on the David
> > > >>Letterman show. Dave asked him what he would do if he
> > > >>lost everything and had to start over from scratch.
> > > >>Without hesitating, Trump said he would find a good
> > > >>network marketing company and get to work. The
> > > >>audience started to hoot and boo him. He looked out at
> > > >>the audience and deadpanned his response:
> > > >>
> > > >> "That's why I'm sitting up here and you are all
> > > >>sitting out there!"
> > > >>
> > > >> The enclosed information is something I almost let
> > > >>slip through my fingers.
> > > >>
> > > >> Fortunately, sometime later I re-read everything
> > > >>and gave some thought and study to it. My name is
> > > >>Johnathon Rourke. Two years ago, the corporation I
> > > >>worked at for the past twelve years downsized and my
> > > >>position was eliminated. After unproductive job interviews, I
> > > >>decided to open my own business. Over the past year, I
> > > >>incurred many unforeseen financial problems.
> > > >>
> > > >> I owed my family, friends and creditors over
> > > >>$35,000. The economy was taking a toll on my business
> > > >>and I just couldn't seem to make ends meet. I had to
> > > >>refinance and borrow against my home to support my
> > > >>family and struggling business.
> > > >>
> > > >> AT THAT MOMENT something significant happened in my
> > > >>life and I am writing to share the experience in hopes
> > > >>that this will change your life FOREVER FINANCIALLY!!!
> > > >>
> > > >> In mid December, I received this program via
> > > >>e-mail. Six month's prior to receiving this program I
> > > >>had been sending away for information on various
> > > >>business opportunities. All of the programs I
> > > >>received, in my opinion, were not cost effective. They were
> > > >>either too difficult for me to comprehend or the initial
> > > >>investment was too much for me to risk to see if they
> > > >>would work or not. One claimed that I would make a
> > > >>million dollars in one year...it didn't tell me I'd
> > > >>have to write a book to make it!
> > > >>
> > > >> But like I was saying, in December of 1999 I
> > > >>received this program. I didn't send for it, or ask
> > > >>for it, they just got my name off a mailing list.
> > > >>THANK GOODNESS FOR THAT!!! After reading it several
> > > >>times, to make sure I was reading it correctly, I couldn't
> > > >>believe my eyes. Here was a MONEY MAKING PHENOMENON.
> > > >>I could invest as much as I wanted to start, without
> > > >>putting me further into debt. After I got a pencil and
> > > >>paper and figured it out, I would at least get my
> > > >>money back. But like most of you I was still a little
> > > >>skeptical and a little worried about the legal aspects
> > > >>of it all. So I checked it out with the U.S. Post
> > > >>Office (1-800-725-2161 24-hrs) and they confirmed that
> > > >>it is indeed legal! After determining the program was
> > > >>LEGAL and NOT A CHAIN LETTER, I decided WHY NOT."
> > > >>
> > > >> Initially I sent out 10,000 e-mails. It cost me
> > > >>about $15 for my time on-line. The great thing about
> > > >>e-mail is that I don't need any money for printing to
> > > >>send out the program, and because all of my orders are
> > > >>fulfilled via e-mail, my only expense is my time. I am
> > > >>telling you like it is I hope it don't turn you off,
> > > >>but I promised myself that I would not "rip-off"
> > > >>anyone, no matter how much money it made me.
> > > >>
> > > >> In less than one week, I was starting to receive
> > > >>orders for REPORT # 1 By January 13; I had received 26
> > > >>orders for REPORT # 1. Your goal is to "RECEIVE at
> > > >>least 20 ORDERS FOR REPORT # 1 WITHIN 2 WEEKS. IF YOU
> > > >>DON'T, SEND OUT MORE PROGRAMS UNTIL YOU DO!"
> > > >>
> > > >> My first step in making $50,000 in 90 days was done. By January
> > > >>30, I
> > > >>had received 196 orders for REPORT # 2. Your goal is to
> > > >>"RECEIVE AT LEAST 100+ ORDERS FOR REPORT # 2 WITHIN 2
> > > >>WEEKS. IF NOT, SEND OUT MORE PROGRAMS UNTIL YOU DO.
> > > >>ONCE YOU HAVE 100 ORDERS, THE REST IS EASY, RELAX, YOU
> > > >>WILL MAKE YOUR $50,000 GOAL." Well, I had 196 orders
> > > >>for REPORT # 296 more than I needed. So I sat back and
> > > >>relaxed. By March 1, of my e-mailing of 10,000, I
> > > >>received $58,000 with more coming in every day.
> > > >>
> > > >> I paid off ALL my debts and bought a much needed
> > > >>new car. Please take your time to read the attached
> > > >>program, IT WILL CHANGE YOUR LIFE FOREVER!!!
> > > >>
> > > >> Remember, it won't work if you don't try it. This
> > > >>program does work, but you must follow it EXACTLY!
> > > >>Especially the rules of not trying to place your name
> > > >>in a different place. It won't work and you'll lose
> > > >>out on a lot of money!
> > > >>
> > > >> In order for this program to work, you must meet
> > > >>your goal of 20 + orders for REPORT # 1, and 100 + orders
> > > >>for REPORT # 2 and you will make $50,000 or more in 90
> > > >>days. I AM LIVING PROOF THAT IT WORKS!!!
> > > >>
> > > >> If you choose not to participate in this program, I
> > > >>am sorry. It really is a great opportunity with little
> > > >>cost or risk to you. If you choose to participate,
> > > >>follow the program and you will be on your way to
> > > >>financial security. If you are a fellow business owner
> > > >>and are in financial trouble like I was, or you want
> > > >>to start your own business, consider this a sign.
> > > >>
> > > >> I DID!
> > > >>
> > > >> Sincerely,
> > > >> Johnathon Rourke
> > > >>
> > > >>
> > >
>>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~
> > > >>~~
> > > >>
> > > >> A PERSONAL NOTE FROM THE ORIGINATOR OF THIS
> > > >>PROGRAM:
> > > >>
> > > >> By the time you have read the enclosed program and
> > > >>reports, you should have concluded that such a
> > > >>program, and one that is legal, could not have been
> > > >>created by an amateur.
> > > >>
> > > >> Let me tell you a little about myself. I had a
> > > >>profitable business for 10 years. Then in 1979 my
> > > >>business began falling off. I was doing the same
> > > >>things that were previously successful for me, but it
> > > >>wasn't working. Finally, I figured it out. It wasn't me, it
> > > >>was the economy. Inflation and recession had replaced
> > > >>the stable economy that had been with us since 1945.
> > > >>
> > > >> I don't have to tell you what happened to the
> > > >>unemployment rate... because many of you know from
> > > >>first hand experience. There were more failures and
> > > >>bankruptcies than ever before. The middle class was
> > > >>vanishing. Those who knew what they were doing
> > > >>invested wisely and moved up. Those who did not,
> > > >>including those who never had anything to save or
> > > >>invest, were moving down into the ranks of the poor.
> > > >>
> > > >> As the saying goes, "THE RICH GET RICHER AND THE POOR
> > > >>GET POORER." The traditional methods of making money
> > > >>will never allow you to "move up" or "get rich", inflation will
> > > >>see to that.
> > > >>
> > > >> You have just received information that can give
> > > >>you financial freedom for the rest of your life, with
> > > >>"NO RISK" and "JUST A LITTLE BIT OF EFFORT." You can
> > > >>make more money in the next few months than you have
> > > >>ever imagined. I should also point out that I will not see
> > > >>a penny of this money, nor anyone else who has
> > > >>provided a testimonial for this program. I have
> > > >>already made over 4 MILLION DOLLARS! I have retired
> > > >>from the program after sending thousands and thousands
> > > >>of programs.
> > > >>
> > > >>Follow the program EXACTLY AS INSTRUCTED.
> > > >>Do not change it in any way. It works exceedingly well
> > > >>as it is now. Remember to e-mail a copy of this
> > > >>exciting report to everyone you can think of. One of the people
> > > >>you
> > > >>send this to may send out 50,000...and your name will be on
> > > >>every one of them!
> > > >>
> > > >> Remember though, the more you send out the more
> > > >>potential customers you will reach.
> > > >>
> > > >> So my friend, I have given you the ideas,
> > > >>information, materials and opportunity to become
> > > >>financially independent. IT IS UP TO YOU NOW!
> > > >>
> > > >> "THINK ABOUT IT"
> > > >>
> > > >> Before you delete this program from your mailbox,
> > > >>as I almost did, take a little time to read it and
> > > >>REALLY THINK ABOUT IT. Get a pencil and figure out
> > > >>what could happen when YOU participate. Figure out the
> > > >>worst possible response and no matter how you
> > > >>calculate it, you will still make a lot of money! You
> > > >>will definitely get back what you invested. Any doubts
> > > >>you have will vanish when your first orders come in.
> > > >>IT WORKS!
> > > >>
> > > >> Jody Jacobs
> > > >> Richmond, VA
> > > >>
> > > >> HERE'S HOW THIS AMAZING PROGRAM WILL MAKE YOU
> > > >>THOUSANDS OF DOLLAR$
> > > >>
> > > >> INSTRUCTIONS:
> > > >>
> > > >> This method of raising capital REALLY WORKS 100%
> > > >>EVERY TIME. I am sure that you could use up to $50,000
> > > >>or more in the next 90 days. Before you say "BULL...
> > > >>", please read this program carefully.
> > > >>
> > > >> This is not a chain letter, but a perfectly legal
> > > >>money making opportunity. Basically, this is what you
> > > >>do: As with all multi-level businesses, we build our
> > > >>business by recruiting new partners and selling our
> > > >>products. Every state in the USA allows you to recruit
> > > >>new multi-level business partners, and we offer a
> > > >>product for EVERY dollar sent.
> > > >>
> > > >> YOUR ORDERS COME BY MAIL AND ARE FILLED BY E-MAIL,
> > > >>so you are not involved in personal selling. You do it
> > > >>privately in your own home, store or office. This is
> > > >>the GREATEST Multi-Level Mail Order Marketing
> > > >>anywhere.
> > > >>
> > > >> This is what you MUST do:
> > > >>
> > > >> 1. Order all 4 reports shown on the list below (you
> > > >>can't sell them if you don't order them).
> > > >>
> > > >> -- For each report, send $5.00 CASH, the NAME &
> > > >>NUMBER OF THE REPORT YOU ARE ORDERING, YOUR E-MAIL
> > > >>ADDRESS, and YOUR NAME & RETURN ADDRESS (in case of a
> > > >>problem) to the person whose name appears on the list
> > > >>next to the report.
> > > >>
> > > >> MAKE SURE YOUR RETURN ADDRESS IS ON YOUR ENVELOPE
> > > >>IN CASE OF ANY MAIL PROBLEMS!
> > > >>
> > > >> -- When you place your order, make sure you order
> > > >>each of the four reports. You will need all four
> > > >>reports so that you can save them on your computer and
> > > >>resell them.
> > > >>
> > > >> -- Within a few days you will receive, via e-mail,
> > > >>each of the four reports. Save them on your computer
> > > >>so they will be accessible for you to send to the
> > > >>1,000's of people who will order them from you.
> > > >>
> > > >> 2. IMPORTANT DO NOT alter the names of the people
> > > >>who are listed next to each report, or their sequence
> > > >>on the list, in any way other than is instructed below
> > > >>in steps "a" through "f" or you will lose out on the
> > > >>majority of your profits. Once you understand the
> > > >>way this works, you'll also see how it doesn't work if
> > > >>you change it. Remember, this method has been tested,
> > > >>and if you alter it, it will not work.
> > > >>
> > > >> a. Look below for the listing of available reports.
> > > >>
> > > >> b. After you've ordered the four reports, take this
> > > >>advertisement and remove the name and address under
> > > >>REPORT # 4. This person has made it through the cycle
> > > >>and is no doubt counting their $50,000!
> > > >>
> > > >> c. Move the name and address under REPORT # 3 down
> > > >>to REPORT # 4.
> > > >>
> > > >> d. Move the name and address under REPORT # 2 down
> > > >>to REPORT # 3.
> > > >>
> > > >> e. Move the name and address under REPORT # 1 down
> > > >>to REPORT # 2.
> > > >>
> > > >> f. Insert your name/address in the REPORT # 1
> > > >>position.
> > > >>
> > > >> Please make sure you COPY ALL INFORMATION, every
> > > >>name and address, ACCURATELY!
> > > >>
> > > >> 3. Take this entire letter, including the modified
> > > >>list of names, and save it to your computer. Make NO
> > > >>changes to the instruction portion of this letter.
> > > >>
> > > >> Your cost to participate in this is practically
> > > >>nothing (surely you can afford $20). You obviously
> > > >>already have an Internet connection and
> > > >>e-mail is FREE!
> > > >>
> > > >> There are two primary methods of building your
> > > >>downline:
> > > >>
> > > >> METHOD # 1: SENDING BULK E-MAIL
> > > >>
> > > >> Let's say that you decide to start small, just to
> > > >>see how it goes, and we'll assume you and all those
> > > >>involved send out only 2,000 programs each. Let's
> > > >>also assume that the mailing receives a 0.5% response.
> > > >>Using a good list the response could be much better.
> > > >>Also, many people will send out hundreds of thousands
> > > >>of programs instead of 2,000. But continuing with this
> > > >>example, you send out only 2,000 programs. With a 0.5%
> > > >>response, that is only 10 orders for REPORT # 1. Those
> > > >>10 people respond by sending out 2,000 programs each
> > > >>for a total of 20,000. Out of those 0.5%, 100 people
> > > >>respond and order REPORT # 2. Those 100 mail out 2,000
> > > >>programs each for a total of 200,000. The 0.5%
> > > >>response to that are 1,000 orders for REPORT # 3. Those
> > > >>1,000 send out 2,000 programs each for a 2,000,000
> > > >>total.
> > > >>
> > > >>The 0.5% response to that are 10,000 orders for REPORT # 4.
> > > >>That's 10,000 $5 bills for you. CASH!!! Your total
> > > >>income in this example is $50 + $500 + $5,000 + $50,000
> > > >>for a total of $55,550!!! REMEMBER FRIEND, THIS IS
> > > >>ASSUMING 1,990 OUT OF THE 2,000 PEOPLE YOU MAIL TO
> > > >>WILL DO ABSOLUTELY NOTHING AND TRASH THIS PROGRAM!
> > > >>DARE TO THINK FOR A MOMENT WHAT WOULD HAPPEN IF
> > > >>EVERYONE, OR HALF SENT OUT 100,000 PROGRAMS INSTEAD OF
> > > >>2,000. Believe me, many people will do just that, and
> > > >>more! By the way, your cost to participate in this is
> > > >>practically nothing. You obviously already have an
> > > >>Internet connection and e-mail is FREE!!!
> > > >>
> > > >> REPORT # 2 will show you the best methods for bulk
> > > >>e-mailing; tell you where to obtain free bulk e-mail
> > > >>software and where to obtain e-mail lists.
> > > >>
> > > >> METHOD # 2 - PLACING FREE ADS ON THE INTERNET
> > > >>
> > > >> Advertising on the Internet is very, very
> > > >>inexpensive, and there are HUNDREDS of FREE places to
> > > >>advertise. Let's say you decide to start small just to
> > > >>see how well it works. Assume your goal is to get ONLY
> > > >>10 people to participate on your first level. (Placing
> > > >>a lot of FREE ads on the Internet will EASILY get a
> > > >>larger response.) Also assume that everyone else in
> > > >>YOUR ORGANIZATION gets ONLY 10 downline members.
> > > >>Follow this example to achieve the STAGGERING results
> > > >>below:
> > > >>
> > > >> 1st level--your 10 members with
> > > >> $5.......................................$50
> > > >>
> > > >> 2nd level--10 members from those 10
> > > >> ($5 x 100)..................$500
> > > >>
> > > >> 3rd level--10 members from those 100
> > > >> ($5 x 1,000)...........$5,000
> > > >>
> > > >> 4th level--10 members from those 1,000
> > > >> ($5 x 10,000).....$50,000
> > > >>
> > > >> THIS TOTALS ----------$55,550
> > > >>
> > > >> Remember friends, this assumes that the people who
> > > >>participate only recruit 10 people each. Think for a
> > > >>moment what would happen if they got 20 people to
> > > >>participate! Most people get 100's of participants!
> > > >>
> > > >> THINK ABOUT IT! For every $5.00 you receive, all
> > > >>you must do is e-mail them the report they ordered.
> > > >>THAT'S IT! ALWAYS PROVIDE SAME-DAY SERVICE ON ALL
> > > >>ORDERS! This will guarantee that the e-mail THEY send
> > > >>out with YOUR name and address on it will be prompt
> > > >>because they can't advertise until they receive the
> > > >>report!
> > > >>
> > > >> AVAILABLE REPORTS
> > > >>
> > > >> *** Order Each REPORT by NUMBER and NAME ***
> > > >> Notes:
> > > >>
> > > >> -- ALWAYS SEND $5 CASH (U.S. CURRENCY) FOR EACH
> > > >>REPORT. CHECKS NOT
> > > >>ACCEPTED.
> > > >>
> > > >> -- ALWAYS SEND YOUR ORDER VIA FIRST CLASS MAIL.
> > > >>
> > > >> Make sure the cash is concealed by wrapping it in at least two
> > > >>sheets of paper.
> > > >>On one of those sheets of paper, include:
> > > >>
> > > >> (a) the number & name of the report you are ordering,
> > > >>
> > > >> (b) your e-mail address, and
> > > >>
> > > >> (c) your name & postal address.
> > > >>
> > > >>
> > > >> ## PLACE YOUR ORDER FOR THESE REPORTS NOW:
> > > >>
> > > >> REPORT # 1 "The Insider's Guide to Advertising for
> > > >>Free on the Internet"
> > > >>
> > > >> ORDER REPORT FROM: # 1 FROM:
> > > >>Jerry G Enterprisess
> > > >> 19007 CopperMine RD. Rogers AR. 72756
> > > >> REPORT # 2 "The Insider's Guide to Sending Bulk
> > > >>E-mail on the Internet"
> > > >>
> > > >> ORDER REPORT # 2 FROM:
> > > >>Nitro Marketing
> > > >> 29250 Hwy. HH
> > > >> Sedalia, MO 65301
> > > >>> > > >>
> > > >> REPORT # 3 "The Secrets to Multilevel Marketing on
> > > >>the Internet"
> > > >>Jerry Bradford
> > > >> P.O. Box 366
> > > >> Cole Camp, MO 65235
> > > >>
> > > >>> > > >>
> > > >> REPORT # 4 "How to become a Millionaire utilizing
> > > >>the Power of Multilevel Marketing and the Internet"
> > > >>> > > >>> ORDER REport # 4 From> > > >> > > >
> > > >>
> > > >> > > >> Derald Ewing
> > > >> 4000 Hyde Park Ave. Apt. # 83
> > > >> Columbia, MO 65201
> > > >>
> > > >>
> > > >> About 50,000 new people get online every month!
> > > >>
> > > >> ******* TIPS FOR SUCCESS *******
> > > >>
> > > >> -- TREAT THIS AS YOUR BUSINESS! Be prompt,
> > > >>professional, and follow the directions accurately.
> > > >>
> > > >> -- Send for the four reports IMMEDIATELY so you
> > > >>will have them when the orders start coming in
> > > >>because: When you receive a $5 order, you MUST send
> > > >>out the requested product/report.
> > > >>
> > > >> -- ALWAYS PROVIDE SAME-DAY SERVICE ON THE ORDERS
> > > >>YOU RECEIVE.
> > > >>
> > > >> -- Be patient and persistent with this program. If
> > > >>you follow the instructions exactly, your results WILL
> > > >>BE SUCCESSFUL!
> > > >>
> > > >> -- ABOVE ALL, HAVE FAITH IN YOURSELF AND KNOW YOU
> > > >>WILL SUCCEED!
> > > >>
> > > >> ******* YOUR SUCCESS GUIDELINES *******
> > > >>
> > > >> Follow these guidelines to guarantee your success:
> > > >>
> > > >> If you don't receive 20 orders for REPORT # 1 within
> > > >>two weeks, continue advertising or sending e-mails
> > > >>until you do. Then, a couple of weeks later you should
> > > >>receive at least 100 orders for REPORT # 2. If you
> > > >>don't, continue advertising or sending e-mails until you do.
> > > >>Once you have received 100 or more orders for REPORT
> > > >># 2, YOU CAN RELAX, because the system is already
> > > >>working for you, and the cash will continue to roll in!
> > > >>
> > > >> THIS IS IMPORTANT TO REMEMBER:
> > > >>
> > > >> Every time your name is moved down on the list, you
> > > >>are placed in front of a DIFFERENT report. You can
> > > >>KEEP TRACK of your PROGRESS by watching which report
> > > >>people are ordering from you. If you want to generate
> > > >>more income, send another batch of e-mails or continue
> > > >>placing ads and start the whole process again! There
> > > >>is no limit to the income you will generate from this
> > > >>business! Before you make your decision as to whether
> > > >>or not you participate in this program. Please answer
> > > >>one question. DO YOU WANT TO CHANGE YOUR LIFE? If the
> > > >>answer is yes, please look at the following facts
> > > >>about this program:
> > > >>
> > > >> 1. You are selling a product which does not Cost
> > > >>anything to PRODUCE, SHIP OR ADVERTISE.
> > > >>
> > > >> 2. All of your customers pay you in CASH!
> > > >>
> > > >> 3. E-mail is without question the most powerful
> > > >>method of distributing information on earth. This
> > > >>program combines the distribution power of e-mail
> > > >>together with the revenue generating power of
> > > >>multi-level marketing.
> > > >>
> > > >> 4. Your only expense--other than your initial $20
> > > >>investment--is your time!
> > > >>
> > > >> 5. Virtually all of the income you generate from
> > > >>this program is PURE PROFIT!
> > > >>
> > > >> 6. This program will change your LIFE FOREVER.
> > > >> ACT NOW! Take your first step toward achieving
> > > >>financial independence. Order the reports and follow
> > > >>the program outlined above--SUCCESS will be
> > > >>your reward.
> > > >>
> > > >> Thank you for your time and consideration.
> > > >>
> > > >> PLEASE NOTE: If you need help with starting a
> > > >>business, registering a business name, learning how
> > > >>income tax is handled, etc., contact your local
> > > >>office of the Small Business Administration (a
> > > >>Federal Agency)1-800-827-5722 for free help and
> > > >>answers to questions.
> > > >>
> > > >>Also, the Internal Revenue Service
> > > >>offers free help via telephone and free seminars about
> > > >>business tax requirements. Your earnings are highly
> > > >>dependant on your activities and advertising. The information
> > > >>contained on this site and in the report constitutes
> > > >>no guarantees neither stated nor implied. In the event that it
> > > >>is determined that this site or report constitutes a
> > > >>guarantee of any kind, that guarantee is now void. The
> > > >>earnings amounts listed on this site and in the
> > > >>report are estimates only. If you have any questions
> > > >>of the legality of this program, contact the Office of
> > > >>Associate Director for Marketing Practices, Federal
> > > >>Trade Commission, and Bureau of
> > > >>Consumer Protection in Washington, DC.
> > > >>
> > > >>
> > > >>/////////////////////////////////////////////////////////////////
> > > >> ONE TIME MAILING, NO NEED TO REMOVE
> > > >>
> > > >>/////////////////////////////////////////////////////////////////
> > > >>
> > > >>
> > > >>********************************************************
> > > >> This message is sent in compliance of the proposed
> > > >>bill:SECTION 301.
> > > >> Per Section 301, Paragraph (a)(2)(C) of S. 1618,
> > > >> further transmissions to you by the sender of this
> > > >>email may be stopped at no cost to you by sending a
> > > >>reply to this email address with the word remove in
> > > >>the
> > > >>subject line. This message is not intended for
> > > >>residents in the State of Washington, screening of
> > > >>addresses has been done to the best of our technical
> > > >>ability. If you are a Washington, Virginia, or
> > > >>California resident or otherwise wish to be removed
> > > >>from this list, further transmissions to you by the
> > > >>sender of this email may be stopped at no cost to you
> > > >>by sending a reply to this email address with the word
> > > >>remove in the subject line.
> > > >>
> > > >>*********************************************************
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >
> > >
> > >
_______________________________________________________________________
_
> > > Get Your Private, Free E-mail from MSN Hotmail at
http://www.hotmail.com
> > >
> >
>
Error: Timeout , Sent From: tMTIAppUnlock.OnfTimer , Var:
Error: Timeout , Sent From: tMTIAppUnlock.OnfTimer , Var:
Error: Timeout , Sent From: tMTIAppUnlock.OnfTimer , Var:
>From owner-rmt@listserv.lbl.gov Mon Aug 28 15:19:53 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id PAA29501;
Mon, 28 Aug 2000 15:18:01 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id PAA29496
for <rmt@listserv.lbl.gov>; Mon, 28 Aug 2000 15:17:59 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id PAA01132
for <rmt@listserv.lbl.gov>; Mon, 28 Aug 2000 15:17:58 -0700 (PDT)
Received: from phobos.talarian.com (mailhost.talarian.com [207.5.32.17])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id PAA01122
for <rmt@lbl.gov>; Mon, 28 Aug 2000 15:17:56 -0700 (PDT)
Received: from tahoe (talarian32-66.talarian.com [207.5.32.66]) by phobos.talarian.com (8.9.0/8.9.0) with SMTP id PAA28945 for <rmt@lbl.gov>; Mon, 28 Aug 2000 15:17:30 -0700 (PDT)
Message-Id: <4.1.20000828143653.01ba80e0@mailhost.talarian.com>
X-Sender: bwhetten@mailhost.talarian.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1
Date: Mon, 28 Aug 2000 15:17:24 -0700
To: rmt@lbl.gov
From: Brian Whetten <whetten@talarian.com>
Subject: Choices for TRACK/NACK report encoding
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-rmt@lbl.gov
Precedence: bulk
Hi there,
A question just came up for me on how we should best do NACK (and TRACK)
encoding for the information that is sent up. I think there are two
primary ways that have been used so far: List NACKs (i.e. PGM) and bitmaps
(i.e. RMTP-II & TRAM). The other option, which hasn't been used yet but
has been discussed, is run length encoded bitmaps.
I'd ideally like to see us use the same encoding format (as part of the
common data headers BB) for each. I ran a quick comparison of the overhead
of encoding a window of N packets, with a uniform loss rate of P. The
overhead for each option is:
List NACK=32*N*P
Bitmap=N
RLE Bitmap=approximately Ceiling(Log2(1/P))*N*P (I think this is
reasonably accurate for low values of P)
Note that as P approaches 1 (worst case, which we need to plan for), we get:
List=32*N
Bitmap=N
RLE Bitmap=Actually goes down (because we encode successes rather than
losses), with a worst case always less than either of the other two (but
approaching the bitmap case).
Here are numeric results for these formulas, in bits, assuming N=1000.
p List NACK Bitmap RLE Bitmap
0.001 32 1000 10
0.0031 101 1000 28.5
0.01 320 1000 70
0.031 1012 1000 158.1
0.1 3200 1000 400
0.31 10119 1000 632
0.66 21120 1000 660
0.9 28800 1000 400
As you can see, List NACKs are better than a bitmap for P<3%, and worse
otherwise. A RLE bitmap is the most complicated to implement, but is also
the most efficient for all cases.
A related topic to this is the idea of reliable NACKs. Taking PGM as an
example, it uses reliable NACKs, which make a lot of sense if none of these
encoding mechanisms are used, since there is no built in redundancy across
successive NACKs in that case. I think that NORM/PGM's biggest advantage
is being able to work without needing reliability mechanisms, which gives
these protocols better scalability in the face of failures. The reliable
NACKs actually go directly in the face of this, and increase the amount of
NACK implosion traffic that would occur when a network partition occurs.
I believe that the need for reliable NACKs could be removed in NACK-only
protocols (as it is in TRACK oriented protocols) by reporting a full status
of all the non-stable packets. With a RLE mechanism, this scales very
nicely, and I think the overhead of adding the RLE mechanism would be less
than the complexity of reliable NACKs.
Conclusion: I think we should standardize on non-reliable NACKs/TRACKs
(they are basically the same thing, just generated at different times),
which use the same encoding format for their retransmission request
reports. I think that RLE encoded bitmaps should be used for this, since
the system needs to be stable even in the face of very high loss rates and
high data rates.
Comments?
Brian
>From owner-rmt@listserv.lbl.gov Mon Aug 28 16:08:41 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id QAA29611;
Mon, 28 Aug 2000 16:06:58 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id QAA29607
for <rmt@listserv.lbl.gov>; Mon, 28 Aug 2000 16:06:56 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id QAA15343
for <rmt@listserv.lbl.gov>; Mon, 28 Aug 2000 16:06:55 -0700 (PDT)
Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122])
by SpamWall.lbl.gov (8.9.3/8.9.3) with SMTP id QAA15338
for <rmt@lbl.gov>; Mon, 28 Aug 2000 16:06:54 -0700 (PDT)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com
with Novell_GroupWise; Mon, 28 Aug 2000 17:06:20 -0600
Message-Id: <s9aa9c0c.079@prv-mail20.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 5.5.3.1
Date: Mon, 28 Aug 2000 17:06:16 -0600
From: "Sukanta Ganguly" <SGANGULY@novell.com>
To: <rmt@lbl.gov>, <whetten@talarian.com>
Subject: Re: Choices for TRACK/NACK report encoding
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=_772FE97C.87E68BD3"
Sender: owner-rmt@lbl.gov
Precedence: bulk
This is a MIME message. If you are reading this text, you may want to
consider changing to a mail reader or gateway that understands how to
properly handle MIME multipart messages.
--=_772FE97C.87E68BD3
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Brian,
Reliable NACK should not be the fact based on which the design should be =
done. Scalability is the obvious probelm with it. So most of your =
assumptions are correct. I don't quite understand how you came up with the =
overheads. I also could not quite understand where did you get the 32 in =
the calculation.=20
However, what do you mean by full status of the non-stable packets? =
Where is this full status generated? Are we assumming that the RLE data =
reaches the target without any loss?
SG
>>> Brian Whetten <whetten@talarian.com> 08/28/00 04:17PM >>>
Hi there,
A question just came up for me on how we should best do NACK (and TRACK)
encoding for the information that is sent up. I think there are two
primary ways that have been used so far: List NACKs (i.e. PGM) and =
bitmaps
(i.e. RMTP-II & TRAM). The other option, which hasn't been used yet but
has been discussed, is run length encoded bitmaps. =20
I'd ideally like to see us use the same encoding format (as part of the
common data headers BB) for each. I ran a quick comparison of the =
overhead
of encoding a window of N packets, with a uniform loss rate of P. The
overhead for each option is:
List NACK=3D32*N*P
Bitmap=3DN
RLE Bitmap=3Dapproximately Ceiling(Log2(1/P))*N*P (I think this is
reasonably accurate for low values of P)
Note that as P approaches 1 (worst case, which we need to plan for), we =
get:
List=3D32*N
Bitmap=3DN
RLE Bitmap=3DActually goes down (because we encode successes rather than
losses), with a worst case always less than either of the other two (but
approaching the bitmap case).
Here are numeric results for these formulas, in bits, assuming N=3D1000.
p List NACK Bitmap RLE Bitmap
0.001 32 1000 10
0.0031 101 1000 28.5
0.01 320 1000 70
0.031 1012 1000 158.1
0.1 3200 1000 400
0.31 10119 1000 632
0.66 21120 1000 660
0.9 28800 1000 400
As you can see, List NACKs are better than a bitmap for P<3%, and worse
otherwise. A RLE bitmap is the most complicated to implement, but is also
the most efficient for all cases.
A related topic to this is the idea of reliable NACKs. Taking PGM as an
example, it uses reliable NACKs, which make a lot of sense if none of =
these
encoding mechanisms are used, since there is no built in redundancy across
successive NACKs in that case. I think that NORM/PGM's biggest advantage
is being able to work without needing reliability mechanisms, which gives
these protocols better scalability in the face of failures. The reliable
NACKs actually go directly in the face of this, and increase the amount of
NACK implosion traffic that would occur when a network partition occurs. =
=20
I believe that the need for reliable NACKs could be removed in NACK-only
protocols (as it is in TRACK oriented protocols) by reporting a full =
status
of all the non-stable packets. With a RLE mechanism, this scales very
nicely, and I think the overhead of adding the RLE mechanism would be less
than the complexity of reliable NACKs.
Conclusion: I think we should standardize on non-reliable NACKs/TRACKs
(they are basically the same thing, just generated at different times),
which use the same encoding format for their retransmission request
reports. I think that RLE encoded bitmaps should be used for this, since
the system needs to be stable even in the face of very high loss rates and
high data rates. =20
Comments?
Brian
--=_772FE97C.87E68BD3
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" http-equiv=3DContent-Type=
>
<META content=3D"MSHTML 5.00.2920.0" name=3DGENERATOR></HEAD>
<BODY style=3D"FONT: 8pt Tahoma; MARGIN-LEFT: 2px; MARGIN-TOP: 2px">
<DIV><FONT size=3D1>Brian,</FONT></DIV>
<DIV> Reliable NACK should not be the fact based on which the =
design=20
should be done. Scalability is the obvious probelm with it. So most =
of your=20
assumptions are correct. I don't quite understand how you came up with =
the=20
overheads. I also could not quite understand where did you get the 32 in =
the=20
calculation. </DIV>
<DIV> However, what do you mean by full status of the non-s=
table=20
packets? Where is this full status generated? Are we assumming that the =
RLE data=20
reaches the target without any loss?</DIV>
<DIV> </DIV>
<DIV>SG<BR><BR>>>> Brian Whetten <whetten@talarian.com> =
08/28/00=20
04:17PM >>><BR>Hi there,<BR>A question just came up for me on how =
we=20
should best do NACK (and TRACK)<BR>encoding for the information that is =
sent=20
up. I think there are two<BR>primary ways that have been used so=20
far: List NACKs (i.e. PGM) and bitmaps<BR>(i.e. RMTP-II & =
TRAM). =20
The other option, which hasn't been used yet but<BR>has been discussed, is =
run=20
length encoded bitmaps. <BR><BR>I'd ideally like to see us use the =
same=20
encoding format (as part of the<BR>common data headers BB) for each. =
I ran=20
a quick comparison of the overhead<BR>of encoding a window of N packets, =
with a=20
uniform loss rate of P. The<BR>overhead for each option is:<BR><BR>Li=
st=20
NACK=3D32*N*P<BR>Bitmap=3DN<BR>RLE Bitmap=3Dapproximately Ceiling(Log2(1/P)=
)*N*P =20
(I think this is<BR>reasonably accurate for low values of P)<BR><BR>Note =
that as=20
P approaches 1 (worst case, which we need to plan for), we=20
get:<BR>List=3D32*N<BR>Bitmap=3DN<BR>RLE Bitmap=3DActually goes down =
(because we=20
encode successes rather than<BR>losses), with a worst case always less =
than=20
either of the other two (but<BR>approaching the bitmap case).<BR><BR>Here =
are=20
numeric results for these formulas, in bits, assuming=20
N=3D1000.<BR><BR>p List=20
NACK Bitmap RLE=20
Bitmap<BR>0.001 32 =
=20
1000 =20
10<BR>0.0031 101 =20
1000 28.5<BR>0.01 =20=
320 =20
1000 70<BR>0.031 =20
1012 =20
1000 158.1<BR>0.1 =20=
3200 =20
1000 400<BR>0.31 =20
10119 =20
1000 632<BR>0.66 =20
21120 =20
1000 660<BR>0.9 =20
28800 =20
1000 400<BR><BR>As you can see, List =
NACKs=20
are better than a bitmap for P<3%, and worse<BR>otherwise. A RLE =
bitmap=20
is the most complicated to implement, but is also<BR>the most efficient =
for all=20
cases.<BR><BR>A related topic to this is the idea of reliable NACKs. =
=20
Taking PGM as an<BR>example, it uses reliable NACKs, which make a lot of =
sense=20
if none of these<BR>encoding mechanisms are used, since there is no built =
in=20
redundancy across<BR>successive NACKs in that case. I think that=20
NORM/PGM's biggest advantage<BR>is being able to work without needing=20
reliability mechanisms, which gives<BR>these protocols better scalability =
in the=20
face of failures. The reliable<BR>NACKs actually go directly in the =
face=20
of this, and increase the amount of<BR>NACK implosion traffic that would =
occur=20
when a network partition occurs. <BR><BR>I believe that the need =
for=20
reliable NACKs could be removed in NACK-only<BR>protocols (as it is in =
TRACK=20
oriented protocols) by reporting a full status<BR>of all the non-stable=20
packets. With a RLE mechanism, this scales very<BR>nicely, and I =
think the=20
overhead of adding the RLE mechanism would be less<BR>than the complexity =
of=20
reliable NACKs.<BR><BR>Conclusion: I think we should standardize =
on=20
non-reliable NACKs/TRACKs<BR>(they are basically the same thing, just =
generated=20
at different times),<BR>which use the same encoding format for their=20
retransmission request<BR>reports. I think that RLE encoded bitmaps =
should=20
be used for this, since<BR>the system needs to be stable even in the face =
of=20
very high loss rates and<BR>high data rates. =20
<BR><BR>Comments?<BR>Brian<BR><BR></DIV></BODY></HTML>
--=_772FE97C.87E68BD3--
>From owner-rmt@listserv.lbl.gov Tue Aug 29 06:54:32 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id GAA02929;
Tue, 29 Aug 2000 06:52:09 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id GAA02925
for <rmt@listserv.lbl.gov>; Tue, 29 Aug 2000 06:52:07 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id GAA14299
for <rmt@listserv.lbl.gov>; Tue, 29 Aug 2000 06:52:06 -0700 (PDT)
Received: from info.iet.unipi.it (info.iet.unipi.it [131.114.9.184])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id GAA14296
for <rmt@lbl.gov>; Tue, 29 Aug 2000 06:52:05 -0700 (PDT)
Received: (from luigi@localhost)
by info.iet.unipi.it (8.9.3/8.9.3) id PAA51220;
Tue, 29 Aug 2000 15:52:06 +0200 (CEST)
(envelope-from luigi)
From: Luigi Rizzo <luigi@info.iet.unipi.it>
Message-Id: <200008291352.PAA51220@info.iet.unipi.it>
Subject: Re: Choices for TRACK/NACK report encoding
In-Reply-To: <4.1.20000828143653.01ba80e0@mailhost.talarian.com> from Brian Whetten
at "Aug 28, 2000 03:17:24 pm"
To: Brian Whetten <whetten@talarian.com>
Date: Tue, 29 Aug 2000 15:52:06 +0200 (CEST)
CC: rmt@lbl.gov
X-Mailer: ELM [version 2.4ME+ PL61 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-rmt@lbl.gov
Precedence: bulk
> RLE Bitmap=approximately Ceiling(Log2(1/P))*N*P (I think this is
> reasonably accurate for low values of P)
mumble... wonder what did you use to compute the RLE bitmap size
for p in the range 0.1 to 0.5 below... was that an actual
encoding or just the result from the above formula (which might
not apply given your comment above)
note though that maybe it is not such a good idea to issue selective
naks for >100 losses at once (or said it differently, gropus of
1000 pkts with a loss rate of 10% or more), so maybe we could
limit our attention to a relatively small set of missing pkts
irrespective of window size.
cheers
luigi
> Note that as P approaches 1 (worst case, which we need to plan for), we get:
> List=32*N
> Bitmap=N
> RLE Bitmap=Actually goes down (because we encode successes rather than
> losses), with a worst case always less than either of the other two (but
> approaching the bitmap case).
>
> Here are numeric results for these formulas, in bits, assuming N=1000.
>
> p List NACK Bitmap RLE Bitmap
> 0.001 32 1000 10
> 0.0031 101 1000 28.5
> 0.01 320 1000 70
> 0.031 1012 1000 158.1
> 0.1 3200 1000 400
> 0.31 10119 1000 632
> 0.66 21120 1000 660
> 0.9 28800 1000 400
>
> As you can see, List NACKs are better than a bitmap for P<3%, and worse
> otherwise. A RLE bitmap is the most complicated to implement, but is also
> the most efficient for all cases.
>
> A related topic to this is the idea of reliable NACKs. Taking PGM as an
> example, it uses reliable NACKs, which make a lot of sense if none of these
> encoding mechanisms are used, since there is no built in redundancy across
> successive NACKs in that case. I think that NORM/PGM's biggest advantage
> is being able to work without needing reliability mechanisms, which gives
> these protocols better scalability in the face of failures. The reliable
> NACKs actually go directly in the face of this, and increase the amount of
> NACK implosion traffic that would occur when a network partition occurs.
>
> I believe that the need for reliable NACKs could be removed in NACK-only
> protocols (as it is in TRACK oriented protocols) by reporting a full status
> of all the non-stable packets. With a RLE mechanism, this scales very
> nicely, and I think the overhead of adding the RLE mechanism would be less
> than the complexity of reliable NACKs.
>
> Conclusion: I think we should standardize on non-reliable NACKs/TRACKs
> (they are basically the same thing, just generated at different times),
> which use the same encoding format for their retransmission request
> reports. I think that RLE encoded bitmaps should be used for this, since
> the system needs to be stable even in the face of very high loss rates and
> high data rates.
>
> Comments?
> Brian
>
>
>From owner-rmt@listserv.lbl.gov Tue Aug 29 10:38:46 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id KAA03744;
Tue, 29 Aug 2000 10:36:52 -0700 (PDT)
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id KAA03740
for <rmt@listserv.lbl.gov>; Tue, 29 Aug 2000 10:36:47 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id KAA17422
for <rmt@listserv.lbl.gov>; Tue, 29 Aug 2000 10:36:46 -0700 (PDT)
Received: from mail.webfountain.com (mail.webfountain.com [63.161.54.5])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id KAA17407
for <rmt@lbl.gov>; Tue, 29 Aug 2000 10:36:45 -0700 (PDT)
Received: from leningrad (gate.webfountain.com [63.161.54.3])
by mail.webfountain.com (8.9.3/8.9.3) with SMTP id KAA20092;
Tue, 29 Aug 2000 10:23:15 -0700
X-Authentication-Warning: mail.webfountain.com: Host gate.webfountain.com [63.161.54.3] claimed to be leningrad
From: "Mike Luby" <luby@digitalfountain.com>
To: "Luigi Rizzo" <luigi@info.iet.unipi.it>,
"Brian Whetten" <whetten@talarian.com>
Cc: <rmt@lbl.gov>
Subject: RE: Choices for TRACK/NACK report encoding
Date: Tue, 29 Aug 2000 10:27:31 -0700
Message-ID: <NEBBIAPCNKEDCLPNFBNCCELACDAA.luby@digitalfountain.com>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
In-Reply-To: <200008291352.PAA51220@info.iet.unipi.it>
Sender: owner-rmt@lbl.gov
Precedence: bulk
Is there an option to NACK based on FEC, i.e., to just give the number of
missing packets (and which block they are from) instead of an explicit list
of missing packets?
Mike
-----Original Message-----
From: owner-rmt@lbl.gov [mailto:owner-rmt@lbl.gov]On Behalf Of Luigi
Rizzo
Sent: Tuesday, August 29, 2000 6:52 AM
To: Brian Whetten
Cc: rmt@lbl.gov
Subject: Re: Choices for TRACK/NACK report encoding
> RLE Bitmap=approximately Ceiling(Log2(1/P))*N*P (I think this is
> reasonably accurate for low values of P)
mumble... wonder what did you use to compute the RLE bitmap size
for p in the range 0.1 to 0.5 below... was that an actual
encoding or just the result from the above formula (which might
not apply given your comment above)
note though that maybe it is not such a good idea to issue selective
naks for >100 losses at once (or said it differently, gropus of
1000 pkts with a loss rate of 10% or more), so maybe we could
limit our attention to a relatively small set of missing pkts
irrespective of window size.
cheers
luigi
> Note that as P approaches 1 (worst case, which we need to plan for), we
get:
> List=32*N
> Bitmap=N
> RLE Bitmap=Actually goes down (because we encode successes rather than
> losses), with a worst case always less than either of the other two (but
> approaching the bitmap case).
>
> Here are numeric results for these formulas, in bits, assuming N=1000.
>
> p List NACK Bitmap RLE Bitmap
> 0.001 32 1000 10
> 0.0031 101 1000 28.5
> 0.01 320 1000 70
> 0.031 1012 1000 158.1
> 0.1 3200 1000 400
> 0.31 10119 1000 632
> 0.66 21120 1000 660
> 0.9 28800 1000 400
>
> As you can see, List NACKs are better than a bitmap for P<3%, and worse
> otherwise. A RLE bitmap is the most complicated to implement, but is also
> the most efficient for all cases.
>
> A related topic to this is the idea of reliable NACKs. Taking PGM as an
> example, it uses reliable NACKs, which make a lot of sense if none of
these
> encoding mechanisms are used, since there is no built in redundancy across
> successive NACKs in that case. I think that NORM/PGM's biggest advantage
> is being able to work without needing reliability mechanisms, which gives
> these protocols better scalability in the face of failures. The reliable
> NACKs actually go directly in the face of this, and increase the amount of
> NACK implosion traffic that would occur when a network partition occurs.
>
> I believe that the need for reliable NACKs could be removed in NACK-only
> protocols (as it is in TRACK oriented protocols) by reporting a full
status
> of all the non-stable packets. With a RLE mechanism, this scales very
> nicely, and I think the overhead of adding the RLE mechanism would be less
> than the complexity of reliable NACKs.
>
> Conclusion: I think we should standardize on non-reliable NACKs/TRACKs
> (they are basically the same thing, just generated at different times),
> which use the same encoding format for their retransmission request
> reports. I think that RLE encoded bitmaps should be used for this, since
> the system needs to be stable even in the face of very high loss rates and
> high data rates.
>
> Comments?
> Brian
>
>
>From owner-rmt@listserv.lbl.gov Tue Aug 29 10:59:28 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id KAA03796;
Tue, 29 Aug 2000 10:57:41 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id KAA03792
for <rmt@listserv.lbl.gov>; Tue, 29 Aug 2000 10:57:40 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id KAA24824
for <rmt@listserv.lbl.gov>; Tue, 29 Aug 2000 10:57:39 -0700 (PDT)
Received: from phobos.talarian.com (mailhost.talarian.com [207.5.32.17])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id KAA24788
for <rmt@lbl.gov>; Tue, 29 Aug 2000 10:57:33 -0700 (PDT)
Received: from tahoe (talarian32-66.talarian.com [207.5.32.66]) by phobos.talarian.com (8.9.0/8.9.0) with SMTP id KAA15504; Tue, 29 Aug 2000 10:57:05 -0700 (PDT)
Message-Id: <4.1.20000829105244.01c0bb70@mailhost.talarian.com>
Message-Id: <4.1.20000829105244.01c0bb70@mailhost.talarian.com>
X-Sender: bwhetten@mailhost.talarian.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1
Date: Tue, 29 Aug 2000 10:58:00 -0700
To: "Sukanta Ganguly" <SGANGULY@novell.com>, <rmt@lbl.gov>
From: Brian Whetten <whetten@talarian.com>
Subject: Re: Choices for TRACK/NACK report encoding
In-Reply-To: <s9aa9c0c.080@prv-mail20.provo.novell.com>
Mime-Version: 1.0
Content-Type: multipart/alternative;
boundary="=====================_260870902==_.ALT"
Sender: owner-rmt@lbl.gov
Precedence: bulk
--=====================_260870902==_.ALT
Content-Type: text/plain; charset="us-ascii"
I'm glad you agree. 32 comes from the size of a sequence number. No, I'm not
assuming that any sets of packets reach the sender without loss...that is part
of the point of this. Most of the TRACK/NACK RMT protocols out there have the
notion of a non-stable receiver window, which is the set of packets from the
lost packet with lowest sequence packet that is still considered recoverable,
up through the loss detected with the highest sequence number (or
alternatively, up through the highest sequence number the receiver is aware
of).
The core idea is that if you only NACK individual packets, then there is no
built in redundancy from NACK to NACK, and you have to build in a reliability
mechanism for the NACKs. If you send up a compressed bitmap for the packets in
the non-stable window, then you don't need to do this. This status is
generated at the receivers, and passed up. (See TRAM or RMTP-II for details)
Brian
At 05:06 PM 8/28/2000 -0600, Sukanta Ganguly wrote:
>
> Brian,
> Reliable NACK should not be the fact based on which the design should be
> done. Scalability is the obvious probelm with it. So most of your assumptions
> are correct. I don't quite understand how you came up with the overheads. I
> also could not quite understand where did you get the 32 in the calculation.
> However, what do you mean by full status of the non-stable packets? Where
> is this full status generated? Are we assumming that the RLE data reaches the
> target without any loss?
>
> SG
>
> >>> Brian Whetten <whetten@talarian.com> 08/28/00 04:17PM >>>
> Hi there,
> A question just came up for me on how we should best do NACK (and TRACK)
> encoding for the information that is sent up. I think there are two
> primary ways that have been used so far: List NACKs (i.e. PGM) and bitmaps
> (i.e. RMTP-II & TRAM). The other option, which hasn't been used yet but
> has been discussed, is run length encoded bitmaps.
>
> I'd ideally like to see us use the same encoding format (as part of the
> common data headers BB) for each. I ran a quick comparison of the overhead
> of encoding a window of N packets, with a uniform loss rate of P. The
> overhead for each option is:
>
> List NACK=32*N*P
> Bitmap=N
> RLE Bitmap=approximately Ceiling(Log2(1/P))*N*P (I think this is
> reasonably accurate for low values of P)
>
> Note that as P approaches 1 (worst case, which we need to plan for), we get:
> List=32*N
> Bitmap=N
> RLE Bitmap=Actually goes down (because we encode successes rather than
> losses), with a worst case always less than either of the other two (but
> approaching the bitmap case).
>
> Here are numeric results for these formulas, in bits, assuming N=1000.
>
> p List NACK Bitmap RLE Bitmap
> 0.001 32 1000 10
> 0.0031 101 1000 28.5
> 0.01 320 1000 70
> 0.031 1012 1000 158.1
> 0.1 3200 1000 400
> 0.31 10119 1000 632
> 0.66 21120 1000 660
> 0.9 28800 1000 400
>
> As you can see, List NACKs are better than a bitmap for P<3%, and worse
> otherwise. A RLE bitmap is the most complicated to implement, but is also
> the most efficient for all cases.
>
> A related topic to this is the idea of reliable NACKs. Taking PGM as an
> example, it uses reliable NACKs, which make a lot of sense if none of these
> encoding mechanisms are used, since there is no built in redundancy across
> successive NACKs in that case. I think that NORM/PGM's biggest advantage
> is being able to work without needing reliability mechanisms, which gives
> these protocols better scalability in the face of failures. The reliable
> NACKs actually go directly in the face of this, and increase the amount of
> NACK implosion traffic that would occur when a network partition occurs.
>
> I believe that the need for reliable NACKs could be removed in NACK-only
> protocols (as it is in TRACK oriented protocols) by reporting a full status
> of all the non-stable packets. With a RLE mechanism, this scales very
> nicely, and I think the overhead of adding the RLE mechanism would be less
> than the complexity of reliable NACKs.
>
> Conclusion: I think we should standardize on non-reliable NACKs/TRACKs
> (they are basically the same thing, just generated at different times),
> which use the same encoding format for their retransmission request
> reports. I think that RLE encoded bitmaps should be used for this, since
> the system needs to be stable even in the face of very high loss rates and
> high data rates.
>
> Comments?
> Brian
--=====================_260870902==_.ALT
Content-Type: text/html; charset="us-ascii"
<html>
I'm glad you agree. 32 comes from the size of a sequence
number. No, I'm not assuming that any sets of packets reach the
sender without loss...that is part of the point of this. Most of
the TRACK/NACK RMT protocols out there have the notion of a non-stable
receiver window, which is the set of packets from the lost packet with
lowest sequence packet that is still considered recoverable, up through
the loss detected with the highest sequence number (or alternatively, up
through the highest sequence number the receiver is aware of).
<br>
<br>
The core idea is that if you only NACK individual packets, then there is
no built in redundancy from NACK to NACK, and you have to build in a
reliability mechanism for the NACKs. If you send up a compressed
bitmap for the packets in the non-stable window, then you don't need to
do this. This status is generated at the receivers, and passed
up. (See TRAM or RMTP-II for details)<br>
<br>
Brian<br>
<br>
At 05:06 PM 8/28/2000 -0600, Sukanta Ganguly wrote: <br>
<font size=1><blockquote type=cite cite>Brian,</font><br>
Reliable NACK should not be the fact based on which the design
should be done. Scalability is the obvious probelm with it. So most of
your assumptions are correct. I don't quite understand how you came up
with the overheads. I also could not quite understand where did you get
the 32 in the calculation. <br>
However, what do you mean by full status of the non-stable
packets? Where is this full status generated? Are we assumming that the
RLE data reaches the target without any loss?<br>
<br>
SG<br>
<br>
>>> Brian Whetten <whetten@talarian.com> 08/28/00 04:17PM
>>><br>
Hi there,<br>
A question just came up for me on how we should best do NACK (and
TRACK)<br>
encoding for the information that is sent up. I think there are
two<br>
primary ways that have been used so far: List NACKs (i.e. PGM) and
bitmaps<br>
(i.e. RMTP-II & TRAM). The other option, which hasn't been used
yet but<br>
has been discussed, is run length encoded bitmaps. <br>
<br>
I'd ideally like to see us use the same encoding format (as part of
the<br>
common data headers BB) for each. I ran a quick comparison of the
overhead<br>
of encoding a window of N packets, with a uniform loss rate of P.
The<br>
overhead for each option is:<br>
<br>
List NACK=32*N*P<br>
Bitmap=N<br>
RLE Bitmap=approximately Ceiling(Log2(1/P))*N*P (I think this
is<br>
reasonably accurate for low values of P)<br>
<br>
Note that as P approaches 1 (worst case, which we need to plan for), we
get:<br>
List=32*N<br>
Bitmap=N<br>
RLE Bitmap=Actually goes down (because we encode successes rather
than<br>
losses), with a worst case always less than either of the other two
(but<br>
approaching the bitmap case).<br>
<br>
Here are numeric results for these formulas, in bits, assuming
N=1000.<br>
<br>
p List NACK
Bitmap RLE Bitmap<br>
0.001
32
1000 10<br>
0.0031 101
1000 28.5<br>
0.01
320
1000 70<br>
0.031
1012
1000 158.1<br>
0.1
3200
1000 400<br>
0.31
10119
1000 632<br>
0.66
21120
1000 660<br>
0.9
28800
1000 400<br>
<br>
As you can see, List NACKs are better than a bitmap for P<3%, and
worse<br>
otherwise. A RLE bitmap is the most complicated to implement, but
is also<br>
the most efficient for all cases.<br>
<br>
A related topic to this is the idea of reliable NACKs. Taking PGM
as an<br>
example, it uses reliable NACKs, which make a lot of sense if none of
these<br>
encoding mechanisms are used, since there is no built in redundancy
across<br>
successive NACKs in that case. I think that NORM/PGM's biggest
advantage<br>
is being able to work without needing reliability mechanisms, which
gives<br>
these protocols better scalability in the face of failures. The
reliable<br>
NACKs actually go directly in the face of this, and increase the amount
of<br>
NACK implosion traffic that would occur when a network partition
occurs. <br>
<br>
I believe that the need for reliable NACKs could be removed in
NACK-only<br>
protocols (as it is in TRACK oriented protocols) by reporting a full
status<br>
of all the non-stable packets. With a RLE mechanism, this scales
very<br>
nicely, and I think the overhead of adding the RLE mechanism would be
less<br>
than the complexity of reliable NACKs.<br>
<br>
Conclusion: I think we should standardize on non-reliable
NACKs/TRACKs<br>
(they are basically the same thing, just generated at different
times),<br>
which use the same encoding format for their retransmission request<br>
reports. I think that RLE encoded bitmaps should be used for this,
since<br>
the system needs to be stable even in the face of very high loss rates
and<br>
high data rates. <br>
<br>
Comments?<br>
Brian<br>
</blockquote><br>
<br>
</html>
--=====================_260870902==_.ALT--
>From owner-rmt@listserv.lbl.gov Tue Aug 29 11:15:03 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id LAA03872;
Tue, 29 Aug 2000 11:13:05 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id LAA03868
for <rmt@listserv.lbl.gov>; Tue, 29 Aug 2000 11:13:03 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id LAA00963
for <rmt@listserv.lbl.gov>; Tue, 29 Aug 2000 11:13:02 -0700 (PDT)
Received: from phobos.talarian.com (mailhost.talarian.com [207.5.32.17])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id LAA00952
for <rmt@lbl.gov>; Tue, 29 Aug 2000 11:13:01 -0700 (PDT)
Received: from tahoe (talarian32-66.talarian.com [207.5.32.66]) by phobos.talarian.com (8.9.0/8.9.0) with SMTP id LAA15999; Tue, 29 Aug 2000 11:12:03 -0700 (PDT)
Message-Id: <4.1.20000829105816.01c12740@mailhost.talarian.com>
X-Sender: bwhetten@mailhost.talarian.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1
Date: Tue, 29 Aug 2000 11:10:35 -0700
To: Luigi Rizzo <luigi@info.iet.unipi.it>
From: Brian Whetten <whetten@talarian.com>
Subject: Re: Choices for TRACK/NACK report encoding
Cc: rmt@lbl.gov
In-Reply-To: <200008291352.PAA51220@info.iet.unipi.it>
References: <4.1.20000828143653.01ba80e0@mailhost.talarian.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-rmt@lbl.gov
Precedence: bulk
I just used the formula, which is only a quick and dirty approximation. I
need to go back and freshen up on encoding/compression algorithms (Mike,
I'm sure this is trivial for you...do you have a more accurate formula?).
I think the issue of the # of packets you NACK is orthogonal to how you
respond to the NACKs. It strikes me that we should always (within the
bounds of efficiency) be striving to get as much information as possible to
the sender, and then it is a different issue as to how those NACKs are
dealt with. The rate of retransmissions needs to be explicitly considered
by the congestion control BB.
Also, in very high bandwidth-delay product networks, I think you may want
to be NACKing 100 or more packets at a time in some cases...but again, this
should be dealt with by congestion control.
Brian
At 03:52 PM 8/29/2000 +0200, Luigi Rizzo wrote:
>> RLE Bitmap=approximately Ceiling(Log2(1/P))*N*P (I think this is
>> reasonably accurate for low values of P)
>
>mumble... wonder what did you use to compute the RLE bitmap size
>for p in the range 0.1 to 0.5 below... was that an actual
>encoding or just the result from the above formula (which might
>not apply given your comment above)
>
>note though that maybe it is not such a good idea to issue selective
>naks for >100 losses at once (or said it differently, gropus of
>1000 pkts with a loss rate of 10% or more), so maybe we could
>limit our attention to a relatively small set of missing pkts
>irrespective of window size.
>
> cheers
> luigi
>
>> Note that as P approaches 1 (worst case, which we need to plan for), we get:
>> List=32*N
>> Bitmap=N
>> RLE Bitmap=Actually goes down (because we encode successes rather than
>> losses), with a worst case always less than either of the other two (but
>> approaching the bitmap case).
>>
>> Here are numeric results for these formulas, in bits, assuming N=1000.
>>
>> p List NACK Bitmap RLE Bitmap
>> 0.001 32 1000 10
>> 0.0031 101 1000 28.5
>> 0.01 320 1000 70
>> 0.031 1012 1000 158.1
>> 0.1 3200 1000 400
>> 0.31 10119 1000 632
>> 0.66 21120 1000 660
>> 0.9 28800 1000 400
>>
>> As you can see, List NACKs are better than a bitmap for P<3%, and worse
>> otherwise. A RLE bitmap is the most complicated to implement, but is also
>> the most efficient for all cases.
>>
>> A related topic to this is the idea of reliable NACKs. Taking PGM as an
>> example, it uses reliable NACKs, which make a lot of sense if none of these
>> encoding mechanisms are used, since there is no built in redundancy across
>> successive NACKs in that case. I think that NORM/PGM's biggest advantage
>> is being able to work without needing reliability mechanisms, which gives
>> these protocols better scalability in the face of failures. The reliable
>> NACKs actually go directly in the face of this, and increase the amount of
>> NACK implosion traffic that would occur when a network partition occurs.
>>
>> I believe that the need for reliable NACKs could be removed in NACK-only
>> protocols (as it is in TRACK oriented protocols) by reporting a full status
>> of all the non-stable packets. With a RLE mechanism, this scales very
>> nicely, and I think the overhead of adding the RLE mechanism would be less
>> than the complexity of reliable NACKs.
>>
>> Conclusion: I think we should standardize on non-reliable NACKs/TRACKs
>> (they are basically the same thing, just generated at different times),
>> which use the same encoding format for their retransmission request
>> reports. I think that RLE encoded bitmaps should be used for this, since
>> the system needs to be stable even in the face of very high loss rates and
>> high data rates.
>>
>> Comments?
>> Brian
>>
>>
>
>From owner-rmt@listserv.lbl.gov Tue Aug 29 11:15:19 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id LAA03878;
Tue, 29 Aug 2000 11:13:37 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id LAA03874
for <rmt@listserv.lbl.gov>; Tue, 29 Aug 2000 11:13:35 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id LAA01156
for <rmt@listserv.lbl.gov>; Tue, 29 Aug 2000 11:13:35 -0700 (PDT)
Received: from phobos.talarian.com (mailhost.talarian.com [207.5.32.17])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id LAA01153
for <rmt@lbl.gov>; Tue, 29 Aug 2000 11:13:34 -0700 (PDT)
Received: from tahoe (talarian32-66.talarian.com [207.5.32.66]) by phobos.talarian.com (8.9.0/8.9.0) with SMTP id LAA16003; Tue, 29 Aug 2000 11:12:04 -0700 (PDT)
Message-Id: <4.1.20000829111049.01c18920@mailhost.talarian.com>
X-Sender: bwhetten@mailhost.talarian.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1
Date: Tue, 29 Aug 2000 11:14:45 -0700
To: "Mike Luby" <luby@digitalfountain.com>,
"Luigi Rizzo" <luigi@info.iet.unipi.it>
From: Brian Whetten <whetten@talarian.com>
Subject: RE: Choices for TRACK/NACK report encoding
Cc: <rmt@lbl.gov>
In-Reply-To: <NEBBIAPCNKEDCLPNFBNCCELACDAA.luby@digitalfountain.com>
References: <200008291352.PAA51220@info.iet.unipi.it>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-rmt@lbl.gov
Precedence: bulk
Hi there,
We certainly need to be able to send this information up. If the sender
knows the FEC window boundaries, then I believe the FEC information can be
extracted from the bitmap (another reason to use a compressed bitmap). So
unless the FEC coding windows were as a common case quite large, I'm not
sure that the added complexity of offering an explicit count per window
option would be worth it, at least for NACK/TRACK protocols.
Brain
At 10:27 AM 8/29/2000 -0700, Mike Luby wrote:
>Is there an option to NACK based on FEC, i.e., to just give the number of
>missing packets (and which block they are from) instead of an explicit list
>of missing packets?
>Mike
>
>-----Original Message-----
>From: owner-rmt@lbl.gov [mailto:owner-rmt@lbl.gov]On Behalf Of Luigi
>Rizzo
>Sent: Tuesday, August 29, 2000 6:52 AM
>To: Brian Whetten
>Cc: rmt@lbl.gov
>Subject: Re: Choices for TRACK/NACK report encoding
>
>
>> RLE Bitmap=approximately Ceiling(Log2(1/P))*N*P (I think this is
>> reasonably accurate for low values of P)
>
>mumble... wonder what did you use to compute the RLE bitmap size
>for p in the range 0.1 to 0.5 below... was that an actual
>encoding or just the result from the above formula (which might
>not apply given your comment above)
>
>note though that maybe it is not such a good idea to issue selective
>naks for >100 losses at once (or said it differently, gropus of
>1000 pkts with a loss rate of 10% or more), so maybe we could
>limit our attention to a relatively small set of missing pkts
>irrespective of window size.
>
> cheers
> luigi
>
>> Note that as P approaches 1 (worst case, which we need to plan for), we
>get:
>> List=32*N
>> Bitmap=N
>> RLE Bitmap=Actually goes down (because we encode successes rather than
>> losses), with a worst case always less than either of the other two (but
>> approaching the bitmap case).
>>
>> Here are numeric results for these formulas, in bits, assuming N=1000.
>>
>> p List NACK Bitmap RLE Bitmap
>> 0.001 32 1000 10
>> 0.0031 101 1000 28.5
>> 0.01 320 1000 70
>> 0.031 1012 1000 158.1
>> 0.1 3200 1000 400
>> 0.31 10119 1000 632
>> 0.66 21120 1000 660
>> 0.9 28800 1000 400
>>
>> As you can see, List NACKs are better than a bitmap for P<3%, and worse
>> otherwise. A RLE bitmap is the most complicated to implement, but is also
>> the most efficient for all cases.
>>
>> A related topic to this is the idea of reliable NACKs. Taking PGM as an
>> example, it uses reliable NACKs, which make a lot of sense if none of
>these
>> encoding mechanisms are used, since there is no built in redundancy across
>> successive NACKs in that case. I think that NORM/PGM's biggest advantage
>> is being able to work without needing reliability mechanisms, which gives
>> these protocols better scalability in the face of failures. The reliable
>> NACKs actually go directly in the face of this, and increase the amount of
>> NACK implosion traffic that would occur when a network partition occurs.
>>
>> I believe that the need for reliable NACKs could be removed in NACK-only
>> protocols (as it is in TRACK oriented protocols) by reporting a full
>status
>> of all the non-stable packets. With a RLE mechanism, this scales very
>> nicely, and I think the overhead of adding the RLE mechanism would be less
>> than the complexity of reliable NACKs.
>>
>> Conclusion: I think we should standardize on non-reliable NACKs/TRACKs
>> (they are basically the same thing, just generated at different times),
>> which use the same encoding format for their retransmission request
>> reports. I think that RLE encoded bitmaps should be used for this, since
>> the system needs to be stable even in the face of very high loss rates and
>> high data rates.
>>
>> Comments?
>> Brian
>>
>>
>
>
>From owner-rmt@listserv.lbl.gov Tue Aug 29 11:59:22 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id LAA04066;
Tue, 29 Aug 2000 11:57:25 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id LAA04062
for <rmt@listserv.lbl.gov>; Tue, 29 Aug 2000 11:57:23 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id LAA15929
for <rmt@listserv.lbl.gov>; Tue, 29 Aug 2000 11:57:22 -0700 (PDT)
Received: from nard.net (nard.net [63.66.160.50])
by SpamWall.lbl.gov (8.9.3/8.9.3) with SMTP id LAA15915
for <rmt@lbl.gov>; Tue, 29 Aug 2000 11:57:21 -0700 (PDT)
Received: (qmail 2754 invoked by uid 500); 29 Aug 2000 18:59:56 -0000
Received: from localhost (sendmail-bs@127.0.0.1)
by localhost with SMTP; 29 Aug 2000 18:59:56 -0000
Date: Tue, 29 Aug 2000 14:59:56 -0400 (EDT)
From: "Todd L. Montgomery" <todd@talarian.com>
X-Sender: tmont@cartman.nard.net
To: Mike Luby <luby@digitalfountain.com>
cc: Luigi Rizzo <luigi@info.iet.unipi.it>,
Brian Whetten <whetten@talarian.com>, rmt@lbl.gov
Subject: RE: Choices for TRACK/NACK report encoding
In-Reply-To: <NEBBIAPCNKEDCLPNFBNCCELACDAA.luby@digitalfountain.com>
Message-ID: <Pine.LNX.4.21.0008291458020.29724-100000@cartman.nard.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-rmt@lbl.gov
Precedence: bulk
I hope there is. PGMs FEC adds a nice feature that allows a block
to report it's loss count and pack that into a 32-bit number
no matter how big the block. That is a LOT smaller with List NAKs
than a bitmap can be.
To do this, the block size (in packets) must be a power of 2, but that is
not very restrictive.
On Tue, 29 Aug 2000, Mike Luby wrote:
> Is there an option to NACK based on FEC, i.e., to just give the number of
> missing packets (and which block they are from) instead of an explicit list
> of missing packets?
> Mike
>
> -----Original Message-----
> From: owner-rmt@lbl.gov [mailto:owner-rmt@lbl.gov]On Behalf Of Luigi
> Rizzo
> Sent: Tuesday, August 29, 2000 6:52 AM
> To: Brian Whetten
> Cc: rmt@lbl.gov
> Subject: Re: Choices for TRACK/NACK report encoding
>
>
> > RLE Bitmap=approximately Ceiling(Log2(1/P))*N*P (I think this is
> > reasonably accurate for low values of P)
>
> mumble... wonder what did you use to compute the RLE bitmap size
> for p in the range 0.1 to 0.5 below... was that an actual
> encoding or just the result from the above formula (which might
> not apply given your comment above)
>
> note though that maybe it is not such a good idea to issue selective
> naks for >100 losses at once (or said it differently, gropus of
> 1000 pkts with a loss rate of 10% or more), so maybe we could
> limit our attention to a relatively small set of missing pkts
> irrespective of window size.
>
> cheers
> luigi
>
> > Note that as P approaches 1 (worst case, which we need to plan for), we
> get:
> > List=32*N
> > Bitmap=N
> > RLE Bitmap=Actually goes down (because we encode successes rather than
> > losses), with a worst case always less than either of the other two (but
> > approaching the bitmap case).
> >
> > Here are numeric results for these formulas, in bits, assuming N=1000.
> >
> > p List NACK Bitmap RLE Bitmap
> > 0.001 32 1000 10
> > 0.0031 101 1000 28.5
> > 0.01 320 1000 70
> > 0.031 1012 1000 158.1
> > 0.1 3200 1000 400
> > 0.31 10119 1000 632
> > 0.66 21120 1000 660
> > 0.9 28800 1000 400
> >
> > As you can see, List NACKs are better than a bitmap for P<3%, and worse
> > otherwise. A RLE bitmap is the most complicated to implement, but is also
> > the most efficient for all cases.
> >
> > A related topic to this is the idea of reliable NACKs. Taking PGM as an
> > example, it uses reliable NACKs, which make a lot of sense if none of
> these
> > encoding mechanisms are used, since there is no built in redundancy across
> > successive NACKs in that case. I think that NORM/PGM's biggest advantage
> > is being able to work without needing reliability mechanisms, which gives
> > these protocols better scalability in the face of failures. The reliable
> > NACKs actually go directly in the face of this, and increase the amount of
> > NACK implosion traffic that would occur when a network partition occurs.
> >
> > I believe that the need for reliable NACKs could be removed in NACK-only
> > protocols (as it is in TRACK oriented protocols) by reporting a full
> status
> > of all the non-stable packets. With a RLE mechanism, this scales very
> > nicely, and I think the overhead of adding the RLE mechanism would be less
> > than the complexity of reliable NACKs.
> >
> > Conclusion: I think we should standardize on non-reliable NACKs/TRACKs
> > (they are basically the same thing, just generated at different times),
> > which use the same encoding format for their retransmission request
> > reports. I think that RLE encoded bitmaps should be used for this, since
> > the system needs to be stable even in the face of very high loss rates and
> > high data rates.
> >
> > Comments?
> > Brian
> >
> >
>
>
--
Todd L. Montgomery
Talarian Corporation
304-291-5972
todd@talarian.com
>From owner-rmt@listserv.lbl.gov Tue Aug 29 12:48:17 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id MAA04295;
Tue, 29 Aug 2000 12:45:29 -0700 (PDT)
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id MAA04291
for <rmt@listserv.lbl.gov>; Tue, 29 Aug 2000 12:45:28 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id MAA29190
for <rmt@listserv.lbl.gov>; Tue, 29 Aug 2000 12:45:27 -0700 (PDT)
Received: from mail.webfountain.com (mail.webfountain.com [63.161.54.5])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id MAA29180
for <rmt@lbl.gov>; Tue, 29 Aug 2000 12:45:26 -0700 (PDT)
Received: from leningrad (gate.webfountain.com [63.161.54.3])
by mail.webfountain.com (8.9.3/8.9.3) with SMTP id MAA26186;
Tue, 29 Aug 2000 12:32:13 -0700
X-Authentication-Warning: mail.webfountain.com: Host gate.webfountain.com [63.161.54.3] claimed to be leningrad
From: "Mike Luby" <luby@digitalfountain.com>
To: "Todd L. Montgomery" <todd@talarian.com>
Cc: "Luigi Rizzo" <luigi@info.iet.unipi.it>,
"Brian Whetten" <whetten@talarian.com>, <rmt@lbl.gov>
Subject: RE: Choices for TRACK/NACK report encoding
Date: Tue, 29 Aug 2000 12:36:29 -0700
Message-ID: <NEBBIAPCNKEDCLPNFBNCIELBCDAA.luby@digitalfountain.com>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
In-Reply-To: <Pine.LNX.4.21.0008291458020.29724-100000@cartman.nard.net>
Sender: owner-rmt@lbl.gov
Precedence: bulk
As design goals, it would seem to be desirable:
(1) That explicit packets can be NACKed per block.
(2) That a count of packets can be NACKed per block.
(3) That the mechanisms that achieve (1) and (2) are compatible with each
other.
(4) That the mechanisms would work relatively efficiently independent of the
loss per block or the size of the block.
(a) Would be desirable to work with small as well as large blocks (in
terms of number of packets per block).
(b) Would be desirable that the block size in packets doesn't have to
fit any special requirements, e.g., be a power of 2.
(c) Would be desirable that the scheme would scale with the number of
losses per block, in particular when the report is a count then one should
report any number between 0 and the size of the block in packets.
Do these goals make sense, and how would people prioritize these goals, and
are there other goals that are even more important that are missing? Once
the goals and their relative priority are clear, then the design may just
fall out as a natural consequence.
Mike
-----Original Message-----
From: Todd L. Montgomery [mailto:todd@talarian.com]
Sent: Tuesday, August 29, 2000 12:00 PM
To: Mike Luby
Cc: Luigi Rizzo; Brian Whetten; rmt@lbl.gov
Subject: RE: Choices for TRACK/NACK report encoding
I hope there is. PGMs FEC adds a nice feature that allows a block
to report it's loss count and pack that into a 32-bit number
no matter how big the block. That is a LOT smaller with List NAKs
than a bitmap can be.
To do this, the block size (in packets) must be a power of 2, but that is
not very restrictive.
On Tue, 29 Aug 2000, Mike Luby wrote:
> Is there an option to NACK based on FEC, i.e., to just give the number of
> missing packets (and which block they are from) instead of an explicit
list
> of missing packets?
> Mike
>
> -----Original Message-----
> From: owner-rmt@lbl.gov [mailto:owner-rmt@lbl.gov]On Behalf Of Luigi
> Rizzo
> Sent: Tuesday, August 29, 2000 6:52 AM
> To: Brian Whetten
> Cc: rmt@lbl.gov
> Subject: Re: Choices for TRACK/NACK report encoding
>
>
> > RLE Bitmap=approximately Ceiling(Log2(1/P))*N*P (I think this is
> > reasonably accurate for low values of P)
>
> mumble... wonder what did you use to compute the RLE bitmap size
> for p in the range 0.1 to 0.5 below... was that an actual
> encoding or just the result from the above formula (which might
> not apply given your comment above)
>
> note though that maybe it is not such a good idea to issue selective
> naks for >100 losses at once (or said it differently, gropus of
> 1000 pkts with a loss rate of 10% or more), so maybe we could
> limit our attention to a relatively small set of missing pkts
> irrespective of window size.
>
> cheers
> luigi
>
> > Note that as P approaches 1 (worst case, which we need to plan for), we
> get:
> > List=32*N
> > Bitmap=N
> > RLE Bitmap=Actually goes down (because we encode successes rather than
> > losses), with a worst case always less than either of the other two (but
> > approaching the bitmap case).
> >
> > Here are numeric results for these formulas, in bits, assuming N=1000.
> >
> > p List NACK Bitmap RLE Bitmap
> > 0.001 32 1000 10
> > 0.0031 101 1000 28.5
> > 0.01 320 1000 70
> > 0.031 1012 1000 158.1
> > 0.1 3200 1000 400
> > 0.31 10119 1000 632
> > 0.66 21120 1000 660
> > 0.9 28800 1000 400
> >
> > As you can see, List NACKs are better than a bitmap for P<3%, and worse
> > otherwise. A RLE bitmap is the most complicated to implement, but is
also
> > the most efficient for all cases.
> >
> > A related topic to this is the idea of reliable NACKs. Taking PGM as an
> > example, it uses reliable NACKs, which make a lot of sense if none of
> these
> > encoding mechanisms are used, since there is no built in redundancy
across
> > successive NACKs in that case. I think that NORM/PGM's biggest
advantage
> > is being able to work without needing reliability mechanisms, which
gives
> > these protocols better scalability in the face of failures. The
reliable
> > NACKs actually go directly in the face of this, and increase the amount
of
> > NACK implosion traffic that would occur when a network partition occurs.
> >
> > I believe that the need for reliable NACKs could be removed in NACK-only
> > protocols (as it is in TRACK oriented protocols) by reporting a full
> status
> > of all the non-stable packets. With a RLE mechanism, this scales very
> > nicely, and I think the overhead of adding the RLE mechanism would be
less
> > than the complexity of reliable NACKs.
> >
> > Conclusion: I think we should standardize on non-reliable NACKs/TRACKs
> > (they are basically the same thing, just generated at different times),
> > which use the same encoding format for their retransmission request
> > reports. I think that RLE encoded bitmaps should be used for this,
since
> > the system needs to be stable even in the face of very high loss rates
and
> > high data rates.
> >
> > Comments?
> > Brian
> >
> >
>
>
--
Todd L. Montgomery
Talarian Corporation
304-291-5972
todd@talarian.com
>From owner-rmt@listserv.lbl.gov Tue Aug 29 15:00:42 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id OAA04851;
Tue, 29 Aug 2000 14:58:51 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id OAA04847
for <rmt@listserv.lbl.gov>; Tue, 29 Aug 2000 14:58:49 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id OAA12656
for <rmt@listserv.lbl.gov>; Tue, 29 Aug 2000 14:58:49 -0700 (PDT)
Received: from phobos.talarian.com (mailhost.talarian.com [207.5.32.17])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id OAA12643
for <rmt@lbl.gov>; Tue, 29 Aug 2000 14:58:47 -0700 (PDT)
Received: from tahoe (talarian32-66.talarian.com [207.5.32.66]) by phobos.talarian.com (8.9.0/8.9.0) with SMTP id OAA22617; Tue, 29 Aug 2000 14:57:14 -0700 (PDT)
Message-Id: <4.1.20000829143701.01ba2b70@mailhost.talarian.com>
X-Sender: bwhetten@mailhost.talarian.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1
Date: Tue, 29 Aug 2000 14:46:10 -0700
To: "Mike Luby" <luby@digitalfountain.com>,
"Todd L. Montgomery" <todd@talarian.com>
From: Brian Whetten <whetten@talarian.com>
Subject: RE: Choices for TRACK/NACK report encoding
Cc: "Luigi Rizzo" <luigi@info.iet.unipi.it>, <rmt@lbl.gov>
In-Reply-To: <NEBBIAPCNKEDCLPNFBNCIELBCDAA.luby@digitalfountain.com>
References: <Pine.LNX.4.21.0008291458020.29724-100000@cartman.nard.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-rmt@lbl.gov
Precedence: bulk
I would add:
(5) Being able to efficiently encode as many losses across as many blocks
as possible. i.e. being able to report a history of outstanding lost
packets, rather than just the most recent ones.
(6) Simplicity
(7) Being stable in the face of very high loss rates, either of data
packets and/or NACK packets.
I would prioritize 1,2,6,7 as having the highest importance.
Brian
At 12:36 PM 8/29/2000 -0700, Mike Luby wrote:
>As design goals, it would seem to be desirable:
>
>(1) That explicit packets can be NACKed per block.
>(2) That a count of packets can be NACKed per block.
>(3) That the mechanisms that achieve (1) and (2) are compatible with each
>other.
>(4) That the mechanisms would work relatively efficiently independent of the
>loss per block or the size of the block.
> (a) Would be desirable to work with small as well as large blocks (in
>terms of number of packets per block).
> (b) Would be desirable that the block size in packets doesn't have to
>fit any special requirements, e.g., be a power of 2.
> (c) Would be desirable that the scheme would scale with the number of
>losses per block, in particular when the report is a count then one should
>report any number between 0 and the size of the block in packets.
>
>Do these goals make sense, and how would people prioritize these goals, and
>are there other goals that are even more important that are missing? Once
>the goals and their relative priority are clear, then the design may just
>fall out as a natural consequence.
>Mike
>
>-----Original Message-----
>From: Todd L. Montgomery [mailto:todd@talarian.com]
>Sent: Tuesday, August 29, 2000 12:00 PM
>To: Mike Luby
>Cc: Luigi Rizzo; Brian Whetten; rmt@lbl.gov
>Subject: RE: Choices for TRACK/NACK report encoding
>
>
>
>I hope there is. PGMs FEC adds a nice feature that allows a block
>to report it's loss count and pack that into a 32-bit number
>no matter how big the block. That is a LOT smaller with List NAKs
>than a bitmap can be.
>
>To do this, the block size (in packets) must be a power of 2, but that is
>not very restrictive.
>
>On Tue, 29 Aug 2000, Mike Luby wrote:
>
>> Is there an option to NACK based on FEC, i.e., to just give the number of
>> missing packets (and which block they are from) instead of an explicit
>list
>> of missing packets?
>> Mike
>>
>> -----Original Message-----
>> From: owner-rmt@lbl.gov [mailto:owner-rmt@lbl.gov]On Behalf Of Luigi
>> Rizzo
>> Sent: Tuesday, August 29, 2000 6:52 AM
>> To: Brian Whetten
>> Cc: rmt@lbl.gov
>> Subject: Re: Choices for TRACK/NACK report encoding
>>
>>
>> > RLE Bitmap=approximately Ceiling(Log2(1/P))*N*P (I think this is
>> > reasonably accurate for low values of P)
>>
>> mumble... wonder what did you use to compute the RLE bitmap size
>> for p in the range 0.1 to 0.5 below... was that an actual
>> encoding or just the result from the above formula (which might
>> not apply given your comment above)
>>
>> note though that maybe it is not such a good idea to issue selective
>> naks for >100 losses at once (or said it differently, gropus of
>> 1000 pkts with a loss rate of 10% or more), so maybe we could
>> limit our attention to a relatively small set of missing pkts
>> irrespective of window size.
>>
>> cheers
>> luigi
>>
>> > Note that as P approaches 1 (worst case, which we need to plan for), we
>> get:
>> > List=32*N
>> > Bitmap=N
>> > RLE Bitmap=Actually goes down (because we encode successes rather than
>> > losses), with a worst case always less than either of the other two (but
>> > approaching the bitmap case).
>> >
>> > Here are numeric results for these formulas, in bits, assuming N=1000.
>> >
>> > p List NACK Bitmap RLE Bitmap
>> > 0.001 32 1000 10
>> > 0.0031 101 1000 28.5
>> > 0.01 320 1000 70
>> > 0.031 1012 1000 158.1
>> > 0.1 3200 1000 400
>> > 0.31 10119 1000 632
>> > 0.66 21120 1000 660
>> > 0.9 28800 1000 400
>> >
>> > As you can see, List NACKs are better than a bitmap for P<3%, and worse
>> > otherwise. A RLE bitmap is the most complicated to implement, but is
>also
>> > the most efficient for all cases.
>> >
>> > A related topic to this is the idea of reliable NACKs. Taking PGM as an
>> > example, it uses reliable NACKs, which make a lot of sense if none of
>> these
>> > encoding mechanisms are used, since there is no built in redundancy
>across
>> > successive NACKs in that case. I think that NORM/PGM's biggest
>advantage
>> > is being able to work without needing reliability mechanisms, which
>gives
>> > these protocols better scalability in the face of failures. The
>reliable
>> > NACKs actually go directly in the face of this, and increase the amount
>of
>> > NACK implosion traffic that would occur when a network partition occurs.
>> >
>> > I believe that the need for reliable NACKs could be removed in NACK-only
>> > protocols (as it is in TRACK oriented protocols) by reporting a full
>> status
>> > of all the non-stable packets. With a RLE mechanism, this scales very
>> > nicely, and I think the overhead of adding the RLE mechanism would be
>less
>> > than the complexity of reliable NACKs.
>> >
>> > Conclusion: I think we should standardize on non-reliable NACKs/TRACKs
>> > (they are basically the same thing, just generated at different times),
>> > which use the same encoding format for their retransmission request
>> > reports. I think that RLE encoded bitmaps should be used for this,
>since
>> > the system needs to be stable even in the face of very high loss rates
>and
>> > high data rates.
>> >
>> > Comments?
>> > Brian
>> >
>> >
>>
>>
>
>--
>Todd L. Montgomery
>Talarian Corporation
>304-291-5972
>todd@talarian.com
>
>
>From owner-rmt@listserv.lbl.gov Tue Aug 29 16:11:08 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id QAA05190;
Tue, 29 Aug 2000 16:09:21 -0700 (PDT)
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id QAA05186
for <rmt@listserv.lbl.gov>; Tue, 29 Aug 2000 16:09:19 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id QAA04329
for <rmt@listserv.lbl.gov>; Tue, 29 Aug 2000 16:09:19 -0700 (PDT)
Received: from mail.webfountain.com (mail.webfountain.com [63.161.54.5])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id QAA04325
for <rmt@lbl.gov>; Tue, 29 Aug 2000 16:09:18 -0700 (PDT)
Received: from leningrad (gate.webfountain.com [63.161.54.3])
by mail.webfountain.com (8.9.3/8.9.3) with SMTP id PAA01934;
Tue, 29 Aug 2000 15:55:58 -0700
X-Authentication-Warning: mail.webfountain.com: Host gate.webfountain.com [63.161.54.3] claimed to be leningrad
From: "Mike Luby" <luby@digitalfountain.com>
To: "Brian Whetten" <whetten@talarian.com>,
"Todd L. Montgomery" <todd@talarian.com>
Cc: "Luigi Rizzo" <luigi@info.iet.unipi.it>, <rmt@lbl.gov>
Subject: RE: Choices for TRACK/NACK report encoding
Date: Tue, 29 Aug 2000 16:00:14 -0700
Message-ID: <NEBBIAPCNKEDCLPNFBNCOELCCDAA.luby@digitalfountain.com>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
In-Reply-To: <4.1.20000829143701.01ba2b70@mailhost.talarian.com>
Sender: owner-rmt@lbl.gov
Precedence: bulk
The additional design goals make sense. I would prioritize almost the same:
(1,2),6,(4,7),5,3.
(Parenthesis enclose goals of similar priority). Given this, the question
then is: does a NACK scheme that meets these goals in this priority order
jump out? (My only goal was to drive the design process starting from the
goals, not from the mechanisms. This may be where I stop contributing.)
Mike
-----Original Message-----
From: Brian Whetten [mailto:whetten@talarian.com]
Sent: Tuesday, August 29, 2000 2:46 PM
To: Mike Luby; Todd L. Montgomery
Cc: Luigi Rizzo; rmt@lbl.gov
Subject: RE: Choices for TRACK/NACK report encoding
I would add:
(5) Being able to efficiently encode as many losses across as many blocks
as possible. i.e. being able to report a history of outstanding lost
packets, rather than just the most recent ones.
(6) Simplicity
(7) Being stable in the face of very high loss rates, either of data
packets and/or NACK packets.
I would prioritize 1,2,6,7 as having the highest importance.
Brian
At 12:36 PM 8/29/2000 -0700, Mike Luby wrote:
>As design goals, it would seem to be desirable:
>
>(1) That explicit packets can be NACKed per block.
>(2) That a count of packets can be NACKed per block.
>(3) That the mechanisms that achieve (1) and (2) are compatible with each
>other.
>(4) That the mechanisms would work relatively efficiently independent of
the
>loss per block or the size of the block.
> (a) Would be desirable to work with small as well as large blocks (in
>terms of number of packets per block).
> (b) Would be desirable that the block size in packets doesn't have to
>fit any special requirements, e.g., be a power of 2.
> (c) Would be desirable that the scheme would scale with the number of
>losses per block, in particular when the report is a count then one should
>report any number between 0 and the size of the block in packets.
>
>Do these goals make sense, and how would people prioritize these goals, and
>are there other goals that are even more important that are missing? Once
>the goals and their relative priority are clear, then the design may just
>fall out as a natural consequence.
>Mike
>
>-----Original Message-----
>From: Todd L. Montgomery [mailto:todd@talarian.com]
>Sent: Tuesday, August 29, 2000 12:00 PM
>To: Mike Luby
>Cc: Luigi Rizzo; Brian Whetten; rmt@lbl.gov
>Subject: RE: Choices for TRACK/NACK report encoding
>
>
>
>I hope there is. PGMs FEC adds a nice feature that allows a block
>to report it's loss count and pack that into a 32-bit number
>no matter how big the block. That is a LOT smaller with List NAKs
>than a bitmap can be.
>
>To do this, the block size (in packets) must be a power of 2, but that is
>not very restrictive.
>
>On Tue, 29 Aug 2000, Mike Luby wrote:
>
>> Is there an option to NACK based on FEC, i.e., to just give the number of
>> missing packets (and which block they are from) instead of an explicit
>list
>> of missing packets?
>> Mike
>>
>> -----Original Message-----
>> From: owner-rmt@lbl.gov [mailto:owner-rmt@lbl.gov]On Behalf Of Luigi
>> Rizzo
>> Sent: Tuesday, August 29, 2000 6:52 AM
>> To: Brian Whetten
>> Cc: rmt@lbl.gov
>> Subject: Re: Choices for TRACK/NACK report encoding
>>
>>
>> > RLE Bitmap=approximately Ceiling(Log2(1/P))*N*P (I think this is
>> > reasonably accurate for low values of P)
>>
>> mumble... wonder what did you use to compute the RLE bitmap size
>> for p in the range 0.1 to 0.5 below... was that an actual
>> encoding or just the result from the above formula (which might
>> not apply given your comment above)
>>
>> note though that maybe it is not such a good idea to issue selective
>> naks for >100 losses at once (or said it differently, gropus of
>> 1000 pkts with a loss rate of 10% or more), so maybe we could
>> limit our attention to a relatively small set of missing pkts
>> irrespective of window size.
>>
>> cheers
>> luigi
>>
>> > Note that as P approaches 1 (worst case, which we need to plan for), we
>> get:
>> > List=32*N
>> > Bitmap=N
>> > RLE Bitmap=Actually goes down (because we encode successes rather than
>> > losses), with a worst case always less than either of the other two
(but
>> > approaching the bitmap case).
>> >
>> > Here are numeric results for these formulas, in bits, assuming N=1000.
>> >
>> > p List NACK Bitmap RLE Bitmap
>> > 0.001 32 1000 10
>> > 0.0031 101 1000 28.5
>> > 0.01 320 1000 70
>> > 0.031 1012 1000 158.1
>> > 0.1 3200 1000 400
>> > 0.31 10119 1000 632
>> > 0.66 21120 1000 660
>> > 0.9 28800 1000 400
>> >
>> > As you can see, List NACKs are better than a bitmap for P<3%, and worse
>> > otherwise. A RLE bitmap is the most complicated to implement, but is
>also
>> > the most efficient for all cases.
>> >
>> > A related topic to this is the idea of reliable NACKs. Taking PGM as
an
>> > example, it uses reliable NACKs, which make a lot of sense if none of
>> these
>> > encoding mechanisms are used, since there is no built in redundancy
>across
>> > successive NACKs in that case. I think that NORM/PGM's biggest
>advantage
>> > is being able to work without needing reliability mechanisms, which
>gives
>> > these protocols better scalability in the face of failures. The
>reliable
>> > NACKs actually go directly in the face of this, and increase the amount
>of
>> > NACK implosion traffic that would occur when a network partition
occurs.
>> >
>> > I believe that the need for reliable NACKs could be removed in
NACK-only
>> > protocols (as it is in TRACK oriented protocols) by reporting a full
>> status
>> > of all the non-stable packets. With a RLE mechanism, this scales very
>> > nicely, and I think the overhead of adding the RLE mechanism would be
>less
>> > than the complexity of reliable NACKs.
>> >
>> > Conclusion: I think we should standardize on non-reliable NACKs/TRACKs
>> > (they are basically the same thing, just generated at different times),
>> > which use the same encoding format for their retransmission request
>> > reports. I think that RLE encoded bitmaps should be used for this,
>since
>> > the system needs to be stable even in the face of very high loss rates
>and
>> > high data rates.
>> >
>> > Comments?
>> > Brian
>> >
>> >
>>
>>
>
>--
>Todd L. Montgomery
>Talarian Corporation
>304-291-5972
>todd@talarian.com
>
>
>From owner-rmt@listserv.lbl.gov Tue Aug 29 17:30:47 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id RAA05454;
Tue, 29 Aug 2000 17:28:55 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id RAA05450
for <rmt@listserv.lbl.gov>; Tue, 29 Aug 2000 17:28:53 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id RAA23564
for <rmt@listserv.lbl.gov>; Tue, 29 Aug 2000 17:28:53 -0700 (PDT)
Received: from phobos.talarian.com (mailhost.talarian.com [207.5.32.17])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id RAA23560
for <rmt@lbl.gov>; Tue, 29 Aug 2000 17:28:52 -0700 (PDT)
Received: from tahoe (talarian32-66.talarian.com [207.5.32.66]) by phobos.talarian.com (8.9.0/8.9.0) with SMTP id RAA25891; Tue, 29 Aug 2000 17:27:13 -0700 (PDT)
Message-Id: <4.1.20000829163742.01c18540@mailhost.talarian.com>
X-Sender: bwhetten@mailhost.talarian.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1
Date: Tue, 29 Aug 2000 17:21:36 -0700
To: "Mike Luby" <luby@digitalfountain.com>,
"Todd L. Montgomery" <todd@talarian.com>
From: Brian Whetten <whetten@talarian.com>
Subject: RE: Choices for TRACK/NACK report encoding
Cc: "Luigi Rizzo" <luigi@info.iet.unipi.it>, <rmt@lbl.gov>
In-Reply-To: <NEBBIAPCNKEDCLPNFBNCOELCCDAA.luby@digitalfountain.com>
References: <4.1.20000829143701.01ba2b70@mailhost.talarian.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-rmt@lbl.gov
Precedence: bulk
This was a good contribution. Thanks, Mike. As always, I was assuming
everyone already agreed on the design principles and was just throwing out
potential solutions. :)
Todd had a good point about being able to encode the number of lost packets
in a block very efficiently. I've added another column for this, which
I'll title block count. I model its overhead as:
Block Count=32*n/b*(1-(1-p)^b), where n=number of packets in the encoded
window, b is the size of the FEC block, and p is the probability for loss.
I ran three cases, for b=8, 32, and 128. I actually think that smaller
block sizes will most often be used for NACK/TRACK based protocols, since
otherwise you would likely use the ALC scheme instead. Again, for RLE it
is probably off by up to a factor of 2 for the middle cases due to my rough
model used.
For b=8, the block count is only marginally better than a straight list
NACK until the loss rate gets above 10%, and is still worse than bitmap at
that point. For b=32, the block count method is approximatley equal to
the list for low loss rates, and equal to bitmap for high loss rates, which
is a desireable combination. For b=128, Block Count is the most
efficient. For B=8 or B=32, RLE still appears to be the most efficient.
Going by your prioritization list:
- I believe that all of these EXCEPT for List NACKs can easily meet #1 and
#2, and therefore also #3. List NACKs has to be combined with one of the
others to meet these requirements. Again, this assumes that the sender can
derive block counts from a complete bitmap list.
- In terms of #6 (simplicity), I believe that RLE is the most complex of
the four, and that any single one is less complex than having to specify
and implement any two of the others. I think that List NACKs bring higher
reliance on reliable NACK mechanisms, which (in terms relative to the
complexity of these mechanisms) are very complex.
- In terms of #4 and #7 (efficiency in all/worst cases), I think that RLE
best meets these requirements, because it works efficiently with b=1 (no
FEC, which is a common case we need to be concerned with), b=8, and b=128.
The only scenario where it is not the best (again, given my rough model for
RLE) is when both p and b are large (p>=10% and b>=64).
- For #5, Bitmap and RLE satisfy this, the others don't.
So, I think that RLE is the best of the mechanisms proposed, given this
analysis and set of requirements. The complexity of having to do two
encoding schemes and/or reliable NACKs, combined with its efficiency, is
what recommends it to me.
Comments? Any mistakes I've made?
Brian
Tables:
b p List Bitmap RLE Block Count
8 0.001 32 1000 10 32
8 0.003 101 1000 28 100
8 0.010 320 1000 70 309
8 0.032 1012 1000 158 907
8 0.100 3200 1000 400 2278
8 0.316 10119 1000 632 3809
8 0.500 16000 1000 500 3984
8 0.660 21120 1000 660 3999
8 0.900 28800 1000 400 4000
b p List Bitmap RLE Block Count
32 0.001 32 1000 10 32
32 0.003 101 1000 28 96
32 0.010 320 1000 70 275
32 0.032 1012 1000 158 642
32 0.100 3200 1000 400 966
32 0.316 10119 1000 632 1000
32 0.500 16000 1000 500 1000
32 0.660 21120 1000 660 1000
32 0.900 28800 1000 400 1000
b p List Bitmap RLE Block Count
128 0.001 32 1000 10 30
128 0.003 101 1000 28 83
128 0.010 320 1000 70 181
128 0.032 1012 1000 158 246
128 0.100 3200 1000 400 250
128 0.316 10119 1000 632 250
128 0.500 16000 1000 500 250
128 0.660 21120 1000 660 250
128 0.900 28800 1000 400 250
At 04:00 PM 8/29/2000 -0700, Mike Luby wrote:
>The additional design goals make sense. I would prioritize almost the same:
>
>(1,2),6,(4,7),5,3.
>
>(Parenthesis enclose goals of similar priority). Given this, the question
>then is: does a NACK scheme that meets these goals in this priority order
>jump out? (My only goal was to drive the design process starting from the
>goals, not from the mechanisms. This may be where I stop contributing.)
>
>Mike
>
>-----Original Message-----
>From: Brian Whetten [mailto:whetten@talarian.com]
>Sent: Tuesday, August 29, 2000 2:46 PM
>To: Mike Luby; Todd L. Montgomery
>Cc: Luigi Rizzo; rmt@lbl.gov
>Subject: RE: Choices for TRACK/NACK report encoding
>
>
>I would add:
>(5) Being able to efficiently encode as many losses across as many blocks
>as possible. i.e. being able to report a history of outstanding lost
>packets, rather than just the most recent ones.
>(6) Simplicity
>(7) Being stable in the face of very high loss rates, either of data
>packets and/or NACK packets.
>
>I would prioritize 1,2,6,7 as having the highest importance.
>
>Brian
>
>At 12:36 PM 8/29/2000 -0700, Mike Luby wrote:
>>As design goals, it would seem to be desirable:
>>
>>(1) That explicit packets can be NACKed per block.
>>(2) That a count of packets can be NACKed per block.
>>(3) That the mechanisms that achieve (1) and (2) are compatible with each
>>other.
>>(4) That the mechanisms would work relatively efficiently independent of
>the
>>loss per block or the size of the block.
>> (a) Would be desirable to work with small as well as large blocks (in
>>terms of number of packets per block).
>> (b) Would be desirable that the block size in packets doesn't have to
>>fit any special requirements, e.g., be a power of 2.
>> (c) Would be desirable that the scheme would scale with the number of
>>losses per block, in particular when the report is a count then one should
>>report any number between 0 and the size of the block in packets.
>>
>>Do these goals make sense, and how would people prioritize these goals, and
>>are there other goals that are even more important that are missing? Once
>>the goals and their relative priority are clear, then the design may just
>>fall out as a natural consequence.
>>Mike
>>
>>-----Original Message-----
>>From: Todd L. Montgomery [mailto:todd@talarian.com]
>>Sent: Tuesday, August 29, 2000 12:00 PM
>>To: Mike Luby
>>Cc: Luigi Rizzo; Brian Whetten; rmt@lbl.gov
>>Subject: RE: Choices for TRACK/NACK report encoding
>>
>>
>>
>>I hope there is. PGMs FEC adds a nice feature that allows a block
>>to report it's loss count and pack that into a 32-bit number
>>no matter how big the block. That is a LOT smaller with List NAKs
>>than a bitmap can be.
>>
>>To do this, the block size (in packets) must be a power of 2, but that is
>>not very restrictive.
>>
>>On Tue, 29 Aug 2000, Mike Luby wrote:
>>
>>> Is there an option to NACK based on FEC, i.e., to just give the number of
>>> missing packets (and which block they are from) instead of an explicit
>>list
>>> of missing packets?
>>> Mike
>>>
>>> -----Original Message-----
>>> From: owner-rmt@lbl.gov [mailto:owner-rmt@lbl.gov]On Behalf Of Luigi
>>> Rizzo
>>> Sent: Tuesday, August 29, 2000 6:52 AM
>>> To: Brian Whetten
>>> Cc: rmt@lbl.gov
>>> Subject: Re: Choices for TRACK/NACK report encoding
>>>
>>>
>>> > RLE Bitmap=approximately Ceiling(Log2(1/P))*N*P (I think this is
>>> > reasonably accurate for low values of P)
>>>
>>> mumble... wonder what did you use to compute the RLE bitmap size
>>> for p in the range 0.1 to 0.5 below... was that an actual
>>> encoding or just the result from the above formula (which might
>>> not apply given your comment above)
>>>
>>> note though that maybe it is not such a good idea to issue selective
>>> naks for >100 losses at once (or said it differently, gropus of
>>> 1000 pkts with a loss rate of 10% or more), so maybe we could
>>> limit our attention to a relatively small set of missing pkts
>>> irrespective of window size.
>>>
>>> cheers
>>> luigi
>>>
>>> > Note that as P approaches 1 (worst case, which we need to plan for), we
>>> get:
>>> > List=32*N
>>> > Bitmap=N
>>> > RLE Bitmap=Actually goes down (because we encode successes rather than
>>> > losses), with a worst case always less than either of the other two
>(but
>>> > approaching the bitmap case).
>>> >
>>> > Here are numeric results for these formulas, in bits, assuming N=1000.
>>> >
>>> > p List NACK Bitmap RLE Bitmap
>>> > 0.001 32 1000 10
>>> > 0.0031 101 1000 28.5
>>> > 0.01 320 1000 70
>>> > 0.031 1012 1000 158.1
>>> > 0.1 3200 1000 400
>>> > 0.31 10119 1000 632
>>> > 0.66 21120 1000 660
>>> > 0.9 28800 1000 400
>>> >
>>> > As you can see, List NACKs are better than a bitmap for P<3%, and worse
>>> > otherwise. A RLE bitmap is the most complicated to implement, but is
>>also
>>> > the most efficient for all cases.
>>> >
>>> > A related topic to this is the idea of reliable NACKs. Taking PGM as
>an
>>> > example, it uses reliable NACKs, which make a lot of sense if none of
>>> these
>>> > encoding mechanisms are used, since there is no built in redundancy
>>across
>>> > successive NACKs in that case. I think that NORM/PGM's biggest
>>advantage
>>> > is being able to work without needing reliability mechanisms, which
>>gives
>>> > these protocols better scalability in the face of failures. The
>>reliable
>>> > NACKs actually go directly in the face of this, and increase the amount
>>of
>>> > NACK implosion traffic that would occur when a network partition
>occurs.
>>> >
>>> > I believe that the need for reliable NACKs could be removed in
>NACK-only
>>> > protocols (as it is in TRACK oriented protocols) by reporting a full
>>> status
>>> > of all the non-stable packets. With a RLE mechanism, this scales very
>>> > nicely, and I think the overhead of adding the RLE mechanism would be
>>less
>>> > than the complexity of reliable NACKs.
>>> >
>>> > Conclusion: I think we should standardize on non-reliable NACKs/TRACKs
>>> > (they are basically the same thing, just generated at different times),
>>> > which use the same encoding format for their retransmission request
>>> > reports. I think that RLE encoded bitmaps should be used for this,
>>since
>>> > the system needs to be stable even in the face of very high loss rates
>>and
>>> > high data rates.
>>> >
>>> > Comments?
>>> > Brian
>>> >
>>> >
>>>
>>>
>>
>>--
>>Todd L. Montgomery
>>Talarian Corporation
>>304-291-5972
>>todd@talarian.com
>>
>>
>
>
>
>From owner-rmt@listserv.lbl.gov Wed Aug 30 01:11:07 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id BAA06118;
Wed, 30 Aug 2000 01:07:44 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id BAA06114
for <rmt@listserv.lbl.gov>; Wed, 30 Aug 2000 01:07:43 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id BAA01884
for <rmt@listserv.lbl.gov>; Wed, 30 Aug 2000 01:07:42 -0700 (PDT)
Received: from daffy.ee.lbl.gov (daffy.ee.lbl.gov [131.243.1.31])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id BAA01881
for <rmt@lbl.gov>; Wed, 30 Aug 2000 01:07:41 -0700 (PDT)
Received: (from vern@localhost)
by daffy.ee.lbl.gov (8.10.0/8.10.0) id e7U87fX11665;
Wed, 30 Aug 2000 01:07:41 -0700 (PDT)
Message-Id: <200008300807.e7U87fX11665@daffy.ee.lbl.gov>
To: rmt@lbl.gov
Subject: Round 2 - you may be deleted from rmt@lbl.gov - please read!
Date: Wed, 30 Aug 2000 01:07:41 PDT
From: Vern Paxson <vern@ee.lbl.gov>
Sender: owner-rmt@lbl.gov
Precedence: bulk
I have been getting repeated bounces from the following addresses for the
RMT mailing list rmt@lbl.gov:
erwan.humez@detexis.thomson-csf.com
ietflist.rmt@icn.siemens.de
rmontgom@cabletron.com
sangli@cse.iitk.ac.in
I plan to delete these addresses in a week or so unless I hear back
that particular addresses should be kept or changed.
Your RMT list maintainer,
Vern
>From owner-rmt@listserv.lbl.gov Wed Aug 30 07:13:57 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id HAA07512;
Wed, 30 Aug 2000 07:11:42 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id HAA07508
for <rmt@listserv.lbl.gov>; Wed, 30 Aug 2000 07:11:40 -0700 (PDT)
From: rhboivie@us.ibm.com
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id HAA02763
for <rmt@listserv.lbl.gov>; Wed, 30 Aug 2000 07:11:39 -0700 (PDT)
Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id HAA02758
for <rmt@lbl.gov>; Wed, 30 Aug 2000 07:11:38 -0700 (PDT)
Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209])
by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id KAA36276;
Wed, 30 Aug 2000 10:00:06 -0500
Received: from d54mta04.raleigh.ibm.com (d54mta04.raleigh.ibm.com [9.67.228.36])
by southrelay02.raleigh.ibm.com (8.8.8m3/NCO v4.93) with SMTP id KAA20680;
Wed, 30 Aug 2000 10:11:37 -0400
Received: by d54mta04.raleigh.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 8525694B.004DF6F9 ; Wed, 30 Aug 2000 10:11:34 -0400
X-Lotus-FromDomain: IBMUS
To: "Dave Oran" <oran@cisco.com>
cc: xcast@public.alcatel.com, rmt@lbl.gov
Message-ID: <8525694B.004D959F.00@d54mta04.raleigh.ibm.com>
Date: Wed, 30 Aug 2000 10:07:09 -0400
Subject: RE: Adding reliable transport layer above sgm/xcsat
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-rmt@lbl.gov
Precedence: bulk
>My knowledge of reliable multicast is spotty at best, so I wade in here
with
>some trepidation. Since this is a side issue wrt SGM, feel free to drop
this
>thread at any point. I just want to make sure that any claims are
>supportable with analysis or hard facts. See below.
Dave,
I'm also ok with dropping this thread since this is, as you say, a side
issue wrt SGM.
I'm just saying that the the ability to selectively specify a subset of
the destinations and the ability to efficiently deliver data to a subset
of destinations lend themselves to reliable multicast since you can
do the re-transmissions efficiently if you want to.
But as I said, I agree that we can drop this thread since this is kind of
a side issue.
Rick
re:
>I don't know at all how you got there. I didn't respond to Yuji's note
>because I assumed he was just pointing out that if you did (audio)
>conference bridges with SGM, that would win over multi-unicast. If you
>factor out the group-state-in-the-routers, the optimal strategy is each
>source unicasting to the bridge, and the bridge unicasting back to the
>active sources (since each sees a unique mix), and multicasting to the
>non-active sources.
Yuji's point was that when you multicast to the non-active sources, you
may need a number of different class-D addresses, one for each combination
of non-active sources ie. in a 5-party conference consisting of parties
1, 2, 3, 4 and 5, you need one multicast group for 2,3,4,5, and one for
1,3,4,5 and one for 1,2,4,5 ... And you need one class D address for
each of the various combinations of 3 members, the combinations of 2
members etc.
>From owner-rmt@listserv.lbl.gov Wed Aug 30 07:14:55 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id HAA07518;
Wed, 30 Aug 2000 07:13:14 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id HAA07514
for <rmt@listserv.lbl.gov>; Wed, 30 Aug 2000 07:13:12 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id HAA03029
for <rmt@listserv.lbl.gov>; Wed, 30 Aug 2000 07:13:11 -0700 (PDT)
Received: from info.iet.unipi.it (info.iet.unipi.it [131.114.9.184])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id HAA03020
for <rmt@lbl.gov>; Wed, 30 Aug 2000 07:13:10 -0700 (PDT)
Received: (from luigi@localhost)
by info.iet.unipi.it (8.9.3/8.9.3) id QAA55310;
Wed, 30 Aug 2000 16:13:00 +0200 (CEST)
(envelope-from luigi)
From: Luigi Rizzo <luigi@info.iet.unipi.it>
Message-Id: <200008301413.QAA55310@info.iet.unipi.it>
Subject: Re: Choices for TRACK/NACK report encoding
In-Reply-To: <4.1.20000829111049.01c18920@mailhost.talarian.com> from Brian Whetten
at "Aug 29, 2000 11:14:45 am"
To: Brian Whetten <whetten@talarian.com>
Date: Wed, 30 Aug 2000 16:13:00 +0200 (CEST)
CC: Mike Luby <luby@digitalfountain.com>, rmt@lbl.gov
X-Mailer: ELM [version 2.4ME+ PL61 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-rmt@lbl.gov
Precedence: bulk
> Hi there,
...
> Brain
interesting typo... does not look so nice for my name!
lugii
>From owner-rmt@listserv.lbl.gov Wed Aug 30 14:38:29 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id OAA08855;
Wed, 30 Aug 2000 14:34:04 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id OAA08851
for <rmt@listserv.lbl.gov>; Wed, 30 Aug 2000 14:34:02 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id OAA16576
for <rmt@listserv.lbl.gov>; Wed, 30 Aug 2000 14:34:01 -0700 (PDT)
Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id OAA16573
for <rmt@lbl.gov>; Wed, 30 Aug 2000 14:34:00 -0700 (PDT)
Received: from [132.250.92.151] (manimac.itd.nrl.navy.mil [132.250.92.151])
by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id RAA01911;
Wed, 30 Aug 2000 17:30:49 -0400 (EDT)
Mime-Version: 1.0
X-Sender: adamson@pop.itd.nrl.navy.mil
Message-Id: <v04210105b5d2d167c268@[132.250.92.151]>
In-Reply-To: <4.1.20000829143701.01ba2b70@mailhost.talarian.com>
References: <Pine.LNX.4.21.0008291458020.29724-100000@cartman.nard.net>
<4.1.20000829143701.01ba2b70@mailhost.talarian.com>
Date: Wed, 30 Aug 2000 17:30:16 -0400
To: Brian Whetten <whetten@talarian.com>
From: Brian Adamson <adamson@itd.nrl.navy.mil>
Subject: RE: Choices for TRACK/NACK report encoding
Cc: "Mike Luby" <luby@digitalfountain.com>,
"Todd L. Montgomery" <todd@talarian.com>,
"Luigi Rizzo" <luigi@info.iet.unipi.it>, <rmt@lbl.gov>,
adamson@itd.nrl.navy.mil, macker@itd.nrl.navy.mil
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-rmt@lbl.gov
Precedence: bulk
I agree with these goals for NACKs as well ... The NACK Content
discussion in the current NORM building block draft (but I probably
should have put more on "goals" in the draft than just the
"solutions" presented) tries to meet these sorts of goals:
1) Explicit packets per block
2) Count of packets NACKed per block
3) Simplicity
4) Independent of block size (within constraints of messaging size
... if a coding blocks are so large that a bit mask (even compressed)
representing it can't be fit into a single NACK message some
additional fields to support
fragmentation might be needed ... but does not necessarily break the
protocol given other aspects of the sender<->receiver NACK/repair
process)
I think the other important goals (stability in high loss, _working_
at all) are also dependent upon the entire NACK process ... i.e. how
the NACK messages are used and of course not just the format of the
messages themselves.
I think it's worthwhile to consider creating a a general NACK format
... particularly to get to a goal of generic router assist in NACK
aggregation. I think a general format can be created which satisfies
the stated goals and provides the functionality needed for different
protocols using NACKs ... The goals outlined make sense for what I
hope NORM turns out to be
These are also in line with the goals we had for the MDP protocol
(some of the current NORM ideas are of course pulled from my
experience here) ... In MDP, a NACK message can contain a
concatenation of repair requests for coding blocks missed in entirety
(if any, which can happen for various reasons) as well as an explicit
indication of missing packets within specific partially received
coding blocks _and_ a count of the number of erasures for each of
those coding blocks.
So an individual Repair Request has the following fields:
ObjectId - Identifier of transport object or stream
requiring repair
RepairRequestType - SEGMENT, BLOCK, OBJECT, or INFO
NumErasures - count of missing packets (segments) for
SEGMENT repair request
Offset - starting point of bit mask which follows
(coding block identifier)
MaskLen - length of bit mask which follows
Mask - Bit mask which marks specific blocks or
segments needing repair depending upon
the RepairRequestType
Multiple of these "Repair Requests" are concatenated as needed to
form a NACK message. We limit the growth of the size of an
individual NACK message to the current multicast session MTU. At
most, a single NACK message is sent per repair cycle by a given
receiver with respect to a given sender. There is no need for
reliability of NACKs given that subsequent transmissions (or lack
thereof) by the sender provide an implicit indication of whether the
receiver needs to NACK again or not.
As Brian Whetten points out, run-length encoding of the bit masks
would improve the efficiency of NACK packing in _some_ cases. We
have found the above scheme to work well in a variety of situations,
but haven't studied NACK size explicitly. (BTW, this could be easily
studied with some ns simulations)
The above hierarchical NACK lets us NACK for either an entire object
(or stream), or some set missing blocks, and/or missing segments
efficiently. The receivers' NACKs aren't allowed to grow beyond one
session MTU in size
The NACK process is self-limited in that all receivers always NACK
for the _oldest_ missing data ... the sender follows the rule that it
will repair oldest data first (This allows the packing of NACK
content be limited to what will fit in one packet)... Thus, receivers
constrain themselves from NACKing again until they see the sender's
sequence of transmission exceed the point at which they have missing
data (This is how the receiver is implicitly aware that the sender
has failed to fulfill his repair needs whether from lost repair
transmissions or that the receiver's NACK was lost)... The receiver
is also constrained by GRTT timing rules to allow the sender
sufficient time to receive NACKs, aggregate them, and begin
transmitting repairs, etc
The above fields may need some additional generalization ... For
example, in MDP the "NumErasures" field is an 8-bit value assuming
Reed Solomon FEC with 8-bit words ... The erasure count simplifies
sender-side processing ...
The explicit content is important so that there doesn't need to be
synchronization among clients and the sender with respect to multiple
repair cycles ... An erasure count alone isn't sufficient to tell the
sender to which repair round (1st, 2nd, 3rd, etc) the NACK is
applicable ... We found it simplest to have the receivers provide an
indication of explicit repair needs even though FEC is usually used
for repair ... And the bit masks are easy for the server to process
for repair aggregation and receivers (and hopefully eventually
routers) to process for NACK suppression purposes ...
At 2:46 PM -0700 8/29/00, Brian Whetten wrote:
>I would add:
>(5) Being able to efficiently encode as many losses across as many blocks
>as possible. i.e. being able to report a history of outstanding lost
>packets, rather than just the most recent ones.
>(6) Simplicity
>(7) Being stable in the face of very high loss rates, either of data
>packets and/or NACK packets.
>
>I would prioritize 1,2,6,7 as having the highest importance.
>
>Brian
>
>At 12:36 PM 8/29/2000 -0700, Mike Luby wrote:
> >As design goals, it would seem to be desirable:
> >
> >(1) That explicit packets can be NACKed per block.
> >(2) That a count of packets can be NACKed per block.
> >(3) That the mechanisms that achieve (1) and (2) are compatible with each
> >other.
> >(4) That the mechanisms would work relatively efficiently independent of the
> >loss per block or the size of the block.
> > (a) Would be desirable to work with small as well as large blocks (in
> >terms of number of packets per block).
> > (b) Would be desirable that the block size in packets doesn't have to
> >fit any special requirements, e.g., be a power of 2.
> > (c) Would be desirable that the scheme would scale with the number of
> >losses per block, in particular when the report is a count then one should
> >report any number between 0 and the size of the block in packets.
> >
> >Do these goals make sense, and how would people prioritize these goals, and
> >are there other goals that are even more important that are missing? Once
> >the goals and their relative priority are clear, then the design may just
> >fall out as a natural consequence.
> >Mike
> >
Brian
__________________________________
Brian Adamson
<http://manimac.itd.nrl.navy.mil>
<mailto:adamson@itd.nrl.navy.mil>
>From owner-rmt@listserv.lbl.gov Thu Sep 7 12:04:52 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id MAA14434;
Thu, 7 Sep 2000 12:01:23 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id MAA14430
for <rmt@listserv.lbl.gov>; Thu, 7 Sep 2000 12:01:21 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id MAA22007
for <rmt@listserv.lbl.gov>; Thu, 7 Sep 2000 12:01:20 -0700 (PDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id MAA21996
for <rmt@lbl.gov>; Thu, 7 Sep 2000 12:01:19 -0700 (PDT)
Received: from eastmail2.East.Sun.COM ([129.148.1.241])
by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA05488;
Thu, 7 Sep 2000 12:01:17 -0700 (PDT)
Received: from bcn.East.Sun.COM (bcn.East.Sun.COM [129.148.75.4])
by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id PAA13675;
Thu, 7 Sep 2000 15:01:16 -0400 (EDT)
Received: from bridge (bridge [129.148.75.125])
by bcn.East.Sun.COM (8.9.1b+Sun/8.9.1) with SMTP id PAA08321;
Thu, 7 Sep 2000 15:01:15 -0400 (EDT)
Message-Id: <200009071901.PAA08321@bcn.East.Sun.COM>
Date: Thu, 7 Sep 2000 15:01:14 -0400 (EDT)
From: Dah Ming Chiu - Sun Microsystems <Dahming.Chiu@East.Sun.COM>
Reply-To: Dah Ming Chiu - Sun Microsystems <Dahming.Chiu@East.Sun.COM>
Subject: Re: Choices for TRACK/NACK report encoding
To: rmt@lbl.gov
Cc: whetten@talarian.com
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: IqPwktKKWF/+PS9/WA2fiA==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc
Sender: owner-rmt@lbl.gov
Precedence: bulk
I had a brief discussion with Brian Whetten regarding his concerns
on loss packet report encoding.
He seems to be concerned with a scenario where there are a large number,
K, packets in flight (meaning potentially a receiver may report a
loss of any one of them), where K can be as large as many thousands.
A receiver lost the first of the K packets; and due to the fat-long
pipe to its repair head (or sender), it soon is receiving the Kth packet
before the first lost packet is repaired. In this "worse case" example,
the receiver also lost the (K-1)th packet. So this receiver needs an
efficient way to report the status of K packets (received or not received)
to its repair head or the sender.
Based on this, he did a quick analysis of three schemes:
a) listing out the sequence number of each lost packet
b) use a bitmask of size K to indicate which ones are lost
c) use Run Length Encoding to indicate which ones are lost
and concluded that RLE is the best.
In the particular example above, a total of 2 of K packets lost, the rough
encoding overhead is respectively:
a) 2*W
b) W+K
c) W+2*logK
where W is the size of a sequence number (32).
If in additional to the above 2 lost packet, there are an additional (n-2)
lost packets - making it a total of n lost packets, then:
a) n*W
b) W+K
c) W+n*logK
What is wrong with this analysis, I think some other people have also
pointed out, is that it does not take into account the option of sending
multiple ACKs (here an ACK is a general term for a common receipt/lost
reporting message). Of course, there is some overhead in sending each
ACK. But in the case of (b), sending multiple ACKs would be more efficient
than sending a huge bitmask of size K.
It is complicated to do an exact analysis of the different encodings taking
into account of the option of sending multiple ACKs. On the other hand,
I don't think the result differ that much for us to be concerned about it.
I think we should just adopt something simple. Having a sequence number
plus an optional bit mask - where the sequence number indicates receipt
up to, and the mask indicates lost packets - is simple and flexible.
As to whether it makes sense to run a reliability service with K packets
in flight for such large K makes sense or not, that is another debate.
Does this make sense?
Dah Ming
>From owner-rmt@listserv.lbl.gov Fri Sep 8 00:18:22 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id AAA17019;
Fri, 8 Sep 2000 00:15:45 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id AAA17015
for <rmt@listserv.lbl.gov>; Fri, 8 Sep 2000 00:15:43 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id AAA18894
for <rmt@listserv.lbl.gov>; Fri, 8 Sep 2000 00:15:43 -0700 (PDT)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
by SpamWall.lbl.gov (8.9.3/8.9.3) with SMTP id AAA18891
for <rmt@lbl.gov>; Fri, 8 Sep 2000 00:15:41 -0700 (PDT)
Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP
id <g.03053-0@bells.cs.ucl.ac.uk>; Fri, 8 Sep 2000 08:15:26 +0100
To: Dah Ming Chiu - Sun Microsystems <Dahming.Chiu@East.Sun.COM>
cc: rmt@lbl.gov, whetten@talarian.com
Subject: Re: Choices for TRACK/NACK report encoding
In-reply-to: Your message of "Thu, 07 Sep 2000 15:01:14 EDT." <200009071901.PAA08321@bcn.East.Sun.COM>
Date: Fri, 08 Sep 2000 08:15:24 +0100
Message-ID: <1132.968397324@cs.ucl.ac.uk>
From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
Sender: owner-rmt@lbl.gov
Precedence: bulk
analysis
looks ok to me - there was an analysis done for SACK in TCP that is
worth re-reading (look on end2end-interest archive)
its not clear why multicast is so different (theres probably enough
reasons for occasional feedback messages and a hierarchy for very
large groups that within each group the loss feedback packet encdoding
can be similar to SACK or possibly RTCP...
one thing is do we believe in long loss bursts or scattered
bursts...?
In message <200009071901.PAA08321@bcn.East.Sun.COM>, Dah Ming Chiu - Sun Micros
ystems typed:
>>I had a brief discussion with Brian Whetten regarding his concerns
>>on loss packet report encoding.
>>
>>He seems to be concerned with a scenario where there are a large number,
>>K, packets in flight (meaning potentially a receiver may report a
>>loss of any one of them), where K can be as large as many thousands.
>>A receiver lost the first of the K packets; and due to the fat-long
>>pipe to its repair head (or sender), it soon is receiving the Kth packet
>>before the first lost packet is repaired. In this "worse case" example,
>>the receiver also lost the (K-1)th packet. So this receiver needs an
>>efficient way to report the status of K packets (received or not received)
>>to its repair head or the sender.
>>
>>Based on this, he did a quick analysis of three schemes:
>>a) listing out the sequence number of each lost packet
>>b) use a bitmask of size K to indicate which ones are lost
>>c) use Run Length Encoding to indicate which ones are lost
>>and concluded that RLE is the best.
>>
>>In the particular example above, a total of 2 of K packets lost, the rough
>>encoding overhead is respectively:
>>a) 2*W
>>b) W+K
>>c) W+2*logK
>>where W is the size of a sequence number (32).
>>
>>If in additional to the above 2 lost packet, there are an additional (n-2)
>>lost packets - making it a total of n lost packets, then:
>>a) n*W
>>b) W+K
>>c) W+n*logK
>>
>>What is wrong with this analysis, I think some other people have also
>>pointed out, is that it does not take into account the option of sending
>>multiple ACKs (here an ACK is a general term for a common receipt/lost
>>reporting message). Of course, there is some overhead in sending each
>>ACK. But in the case of (b), sending multiple ACKs would be more efficient
>>than sending a huge bitmask of size K.
>>
>>It is complicated to do an exact analysis of the different encodings taking
>>into account of the option of sending multiple ACKs. On the other hand,
>>I don't think the result differ that much for us to be concerned about it.
>>
>>I think we should just adopt something simple. Having a sequence number
>>plus an optional bit mask - where the sequence number indicates receipt
>>up to, and the mask indicates lost packets - is simple and flexible.
>>
>>As to whether it makes sense to run a reliability service with K packets
>>in flight for such large K makes sense or not, that is another debate.
>>
>>Does this make sense?
>>
>>Dah Ming
>>
>>
cheers
jon
>From owner-rmt@listserv.lbl.gov Fri Sep 8 01:35:26 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id BAA17110;
Fri, 8 Sep 2000 01:33:10 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id BAA17106
for <rmt@listserv.lbl.gov>; Fri, 8 Sep 2000 01:33:03 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id BAA24604
for <rmt@listserv.lbl.gov>; Fri, 8 Sep 2000 01:33:02 -0700 (PDT)
Received: from info.iet.unipi.it (info.iet.unipi.it [131.114.9.184])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id BAA24597
for <rmt@lbl.gov>; Fri, 8 Sep 2000 01:33:01 -0700 (PDT)
Received: (from luigi@localhost)
by info.iet.unipi.it (8.9.3/8.9.3) id KAA32615;
Fri, 8 Sep 2000 10:34:37 +0200 (CEST)
(envelope-from luigi)
From: Luigi Rizzo <luigi@info.iet.unipi.it>
Message-Id: <200009080834.KAA32615@info.iet.unipi.it>
Subject: Re: Choices for TRACK/NACK report encoding
In-Reply-To: <1132.968397324@cs.ucl.ac.uk> from Jon Crowcroft at "Sep 8, 2000
08:15:24 am"
To: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
Date: Fri, 8 Sep 2000 10:34:37 +0200 (CEST)
CC: Dah Ming Chiu - Sun Microsystems <Dahming.Chiu@East.Sun.COM>, rmt@lbl.gov,
whetten@talarian.com
X-Mailer: ELM [version 2.4ME+ PL61 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-rmt@lbl.gov
Precedence: bulk
> analysis
> looks ok to me - there was an analysis done for SACK in TCP that is
> worth re-reading (look on end2end-interest archive)
i do not remember the details but the result ("we only need 3
sack blocks") look more driven by available option space than
other considerations. I believe one reason multicast is somewhat different
is that delayed feedback gives you the chance to report slightly higher
amt of losses in a single msg as opposed to what you do in TCP
where you {S|N}AK immediately.
> one thing is do we believe in long loss bursts or scattered
> bursts...?
the experience with mbone sessions is often 30s bursts of silence,
but that can be fixed hopefully...
Seriously speaking, as long as multicast sessions are not as bursty
as TCP, i think that more than long loss bursts (which are usually
due to routing problems) we can see the typical losses due to rate
mismatches, or patterns like this
....x....x....x....x....x....
...x..x..x..x..x..x..x..x..x.
.xxx.xxx.xxx.xxx.xxx.xxx.xxx.
cheers
luigi
>From owner-rmt@listserv.lbl.gov Fri Sep 8 01:39:51 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id BAA17138;
Fri, 8 Sep 2000 01:38:05 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id BAA17134
for <rmt@listserv.lbl.gov>; Fri, 8 Sep 2000 01:38:03 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id BAA25031
for <rmt@listserv.lbl.gov>; Fri, 8 Sep 2000 01:38:03 -0700 (PDT)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
by SpamWall.lbl.gov (8.9.3/8.9.3) with SMTP id BAA25028
for <rmt@lbl.gov>; Fri, 8 Sep 2000 01:38:02 -0700 (PDT)
Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP
id <g.05913-0@bells.cs.ucl.ac.uk>; Fri, 8 Sep 2000 09:37:56 +0100
To: Luigi Rizzo <luigi@info.iet.unipi.it>
cc: Dah Ming Chiu - Sun Microsystems <Dahming.Chiu@East.Sun.COM>, rmt@lbl.gov,
whetten@talarian.com
Subject: Re: Choices for TRACK/NACK report encoding
In-reply-to: Your message of "Fri, 08 Sep 2000 10:34:37 +0200." <200009080834.KAA32615@info.iet.unipi.it>
Date: Fri, 08 Sep 2000 09:37:54 +0100
Message-ID: <2045.968402274@cs.ucl.ac.uk>
From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
Sender: owner-rmt@lbl.gov
Precedence: bulk
In message <200009080834.KAA32615@info.iet.unipi.it>, Luigi Rizzo typed:
>>> analysis
>>> looks ok to me - there was an analysis done for SACK in TCP that is
>>> worth re-reading (look on end2end-interest archive)
>>
>>i do not remember the details but the result ("we only need 3
>>sack blocks") look more driven by available option space than
>>other considerations. I believe one reason multicast is somewhat different
>>is that delayed feedback gives you the chance to report slightly higher
>>amt of losses in a single msg as opposed to what you do in TCP
>>where you {S|N}AK immediately.
>>
>>> one thing is do we believe in long loss bursts or scattered
>>> bursts...?
>>
>>the experience with mbone sessions is often 30s bursts of silence,
>>but that can be fixed hopefully...
>>Seriously speaking, as long as multicast sessions are not as bursty
>>as TCP, i think that more than long loss bursts (which are usually
>>due to routing problems) we can see the typical losses due to rate
>>mismatches, or patterns like this
>>
>> ....x....x....x....x....x....
>> ...x..x..x..x..x..x..x..x..x.
>> .xxx.xxx.xxx.xxx.xxx.xxx.xxx.
luigi
and of course wee might want to consider router or repair server
assist in aggregating the loss patterns...
cheers
jon
>From owner-rmt@listserv.lbl.gov Fri Sep 8 07:54:41 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id HAA18547;
Fri, 8 Sep 2000 07:52:29 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id HAA18543
for <rmt@listserv.lbl.gov>; Fri, 8 Sep 2000 07:52:27 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id HAA01041
for <rmt@listserv.lbl.gov>; Fri, 8 Sep 2000 07:52:27 -0700 (PDT)
Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id HAA01037
for <rmt@lbl.gov>; Fri, 8 Sep 2000 07:52:26 -0700 (PDT)
Received: from [132.250.92.151] (manimac.itd.nrl.navy.mil [132.250.92.151])
by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id KAA06465;
Fri, 8 Sep 2000 10:52:05 -0400 (EDT)
Mime-Version: 1.0
X-Sender: adamson@pop.itd.nrl.navy.mil
Message-Id: <v04210116b5deaab2b516@[132.250.92.151]>
In-Reply-To: <200009080834.KAA32615@info.iet.unipi.it>
References: <200009080834.KAA32615@info.iet.unipi.it>
Date: Fri, 8 Sep 2000 10:52:05 -0400
To: Luigi Rizzo <luigi@info.iet.unipi.it>
From: Brian Adamson <adamson@itd.nrl.navy.mil>
Subject: Re: Choices for TRACK/NACK report encoding
Cc: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>,
Dah Ming Chiu - Sun Microsystems <Dahming.Chiu@East.Sun.COM>,
rmt@lbl.gov, whetten@talarian.com
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-rmt@lbl.gov
Precedence: bulk
At 10:34 AM +0200 9/8/00, Luigi Rizzo wrote:
> > analysis
> > looks ok to me - there was an analysis done for SACK in TCP that is
> > worth re-reading (look on end2end-interest archive)
>
>i do not remember the details but the result ("we only need 3
>sack blocks") look more driven by available option space than
>other considerations. I believe one reason multicast is somewhat different
>is that delayed feedback gives you the chance to report slightly higher
>amt of losses in a single msg as opposed to what you do in TCP
>where you {S|N}AK immediately.
>
> > one thing is do we believe in long loss bursts or scattered
> > bursts...?
>
>the experience with mbone sessions is often 30s bursts of silence,
>but that can be fixed hopefully...
>Seriously speaking, as long as multicast sessions are not as bursty
>as TCP, i think that more than long loss bursts (which are usually
>due to routing problems) we can see the typical losses due to rate
>mismatches, or patterns like this
>
> ....x....x....x....x....x....
> ...x..x..x..x..x..x..x..x..x.
> .xxx.xxx.xxx.xxx.xxx.xxx.xxx.
One of the nice applications of reliable multicast is over satellite
services ... at reasonable data rates (several megabits per second),
outages which are relatively momentary (a few seconds) can span
several FEC coding blocks worth of information and do occur
occasionally ... Also depending upon different application policies
of when/how receivers join & leave groups or discontinuities during
handoff in mobile-wireless systems, there will be times when
receivers need to NACK for large portions of data ... Those are some
of the reasons I would propose a hierarchical scheme for NACK
encoding given that use of FEC blocks (if applicable) provide a
natural boundary ... I suppose this isn't much different from the end
result of a run-length encoding scheme, but alignment of hierarchical
NACKs to coding blocks was easy to implement.
> cheers
> luigi
Brian
__________________________________
Brian Adamson
<http://manimac.itd.nrl.navy.mil>
<mailto:adamson@itd.nrl.navy.mil>
>From owner-rmt@listserv.lbl.gov Fri Sep 8 08:12:53 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id IAA18582;
Fri, 8 Sep 2000 08:11:10 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id IAA18578
for <rmt@listserv.lbl.gov>; Fri, 8 Sep 2000 08:11:08 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id IAA05502
for <rmt@listserv.lbl.gov>; Fri, 8 Sep 2000 08:11:08 -0700 (PDT)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
by SpamWall.lbl.gov (8.9.3/8.9.3) with SMTP id IAA05499
for <rmt@lbl.gov>; Fri, 8 Sep 2000 08:11:07 -0700 (PDT)
Received: from hocus.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP
id <g.01094-0@bells.cs.ucl.ac.uk>; Fri, 8 Sep 2000 16:10:49 +0100
To: Brian Adamson <adamson@itd.nrl.navy.mil>
cc: rmt@lbl.gov
Subject: Re: Choices for TRACK/NACK report encoding
In-reply-to: Your message of "Fri, 08 Sep 2000 10:52:05 EDT." <v04210116b5deaab2b516@[132.250.92.151]>
Date: Fri, 08 Sep 2000 16:10:49 +0100
Message-ID: <2163.968425849@cs.ucl.ac.uk>
From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
Sender: owner-rmt@lbl.gov
Precedence: bulk
so we have a large range+accuracy problem in returning
data to the sender(s) about missing sequence numbers
and so if the ack return path is noisy, then lets subject
the problem to the same attack s we did to data in the forward
path
layered FEC encoded SACK messages...
cheers
jon
>From owner-rmt@listserv.lbl.gov Fri Sep 8 10:42:46 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id KAA19209;
Fri, 8 Sep 2000 10:40:49 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id KAA19205
for <rmt@listserv.lbl.gov>; Fri, 8 Sep 2000 10:40:48 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id KAA23042
for <rmt@listserv.lbl.gov>; Fri, 8 Sep 2000 10:40:47 -0700 (PDT)
Received: from phobos.talarian.com (mailhost.talarian.com [207.5.32.17])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id KAA23038
for <rmt@lbl.gov>; Fri, 8 Sep 2000 10:40:46 -0700 (PDT)
Received: from tahoe (talarian32-66.talarian.com [207.5.32.66]) by phobos.talarian.com (8.9.0/8.9.0) with SMTP id KAA01685; Fri, 8 Sep 2000 10:40:10 -0700 (PDT)
Message-Id: <4.1.20000908100047.021b5eb0@mailhost.talarian.com>
X-Sender: bwhetten@mailhost.talarian.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1
Date: Fri, 08 Sep 2000 10:39:30 -0700
To: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>,
Brian Adamson <adamson@itd.nrl.navy.mil>
From: Brian Whetten <whetten@talarian.com>
Subject: Re: Choices for TRACK/NACK report encoding
Cc: rmt@lbl.gov
In-Reply-To: <2163.968425849@cs.ucl.ac.uk>
References: <Your message of "Fri, 08 Sep 2000 10:52:05 EDT." <v04210116b5deaab2b516@[132.250.92.151]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-rmt@lbl.gov
Precedence: bulk
Hello,
My original concern were that I would like us to come up with ONE form for
NACK encoding, that is the same for both TRACK and NACK, and is as simple
as possible. Also, I would like the mechanism to have enough redundancy
built in that reliable NACKs are not needed.
Jon, RM is different than unicast primarily because optimizing the return
control traffic is one of our primary challenges (i.e. minimizing ACK/NACK
implosion).
Dah Ming, good point. Actually, the biggest problem with bitmaps, that I
forgot about, is how you do the aggregation of FEC counts as you move up a
hierarchy. You can solve this, but only with added complexity. If you are
using one big RLE bitmap, you have to unpack it to make it intelligible by
the intermediary nodes, which is probably too much overhead.
Jon, I think FEC encoded NACK bitmaps is overly complex and unecessary, but
I'm not sure I actually understand what your proposal is.
Brian, my initial reaction to your proposal was that it was too complex,
but now I'm not so sure. One issue though, is that you need to pass up the
most recent congestion information you have in each NACK. If you are not
NACKing the most recent packets, then this has to definitely be explicitly
reported, rather than implicitly derived at the sender. This might cause
problems for PGMCC, for example.
I think that the need to do FEC count aggregation is a good argument
against using a single long RLE bitmap.
So I think we are left with three primary design choices:
1) How to encode each block of packets? i.e. Count, Bitmap, None (for
list NACKs, each block is of size 1)
2) How to encode the series of blocks? Do we assume that they are all
sequential, or do you encode each block with its starting sequence number?
(note that this assumes the length of each block is the same)
3) How much history to put in each NACK? Do we just list the most
immediate packets, or do we have some partial redundancy, or do we always
encode the entire outstanding window? The more information we encode, the
simpler the NACK generation algorithms become, but the harder the encoding
algorithms in order to be able to deal with large windows.
Brian
At 04:10 PM 9/8/2000 +0100, Jon Crowcroft wrote:
>
>so we have a large range+accuracy problem in returning
>data to the sender(s) about missing sequence numbers
>and so if the ack return path is noisy, then lets subject
>the problem to the same attack s we did to data in the forward
>path
>
>layered FEC encoded SACK messages...
>
> cheers
>
> jon
>
>From owner-rmt@listserv.lbl.gov Fri Sep 8 11:24:15 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id LAA19496;
Fri, 8 Sep 2000 11:22:31 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id LAA19492
for <rmt@listserv.lbl.gov>; Fri, 8 Sep 2000 11:22:29 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id LAA07554
for <rmt@listserv.lbl.gov>; Fri, 8 Sep 2000 11:22:28 -0700 (PDT)
Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id LAA07542
for <rmt@lbl.gov>; Fri, 8 Sep 2000 11:22:27 -0700 (PDT)
Received: from [132.250.92.151] (manimac.itd.nrl.navy.mil [132.250.92.151])
by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id OAA13297;
Fri, 8 Sep 2000 14:19:02 -0400 (EDT)
Mime-Version: 1.0
X-Sender: adamson@pop.itd.nrl.navy.mil
Message-Id: <v04210119b5ded71d2562@[132.250.92.151]>
In-Reply-To: <4.1.20000908100047.021b5eb0@mailhost.talarian.com>
References: <Your message of "Fri, 08 Sep 2000 10:52:05 EDT."
<v04210116b5deaab2b516@[132.250.92.151]>
<4.1.20000908100047.021b5eb0@mailhost.talarian.com>
Date: Fri, 8 Sep 2000 14:19:02 -0400
To: Brian Whetten <whetten@talarian.com>
From: Brian Adamson <adamson@itd.nrl.navy.mil>
Subject: Re: Choices for TRACK/NACK report encoding
Cc: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>, rmt@lbl.gov
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-rmt@lbl.gov
Precedence: bulk
At 10:39 AM -0700 9/8/00, Brian Whetten wrote:
>Hello,
>
>My original concern were that I would like us to come up with ONE form for
>NACK encoding, that is the same for both TRACK and NACK, and is as simple
>as possible. Also, I would like the mechanism to have enough redundancy
>built in that reliable NACKs are not needed.
>
>Jon, RM is different than unicast primarily because optimizing the return
>control traffic is one of our primary challenges (i.e. minimizing ACK/NACK
>implosion).
>
>Dah Ming, good point. Actually, the biggest problem with bitmaps, that I
>forgot about, is how you do the aggregation of FEC counts as you move up a
>hierarchy. You can solve this, but only with added complexity. If you are
>using one big RLE bitmap, you have to unpack it to make it intelligible by
>the intermediary nodes, which is probably too much overhead.
>
>Jon, I think FEC encoded NACK bitmaps is overly complex and unecessary, but
>I'm not sure I actually understand what your proposal is.
I haven't grok'd that yet either.
>
>Brian, my initial reaction to your proposal was that it was too complex,
>but now I'm not so sure. One issue though, is that you need to pass up the
>most recent congestion information you have in each NACK. If you are not
>NACKing the most recent packets, then this has to definitely be explicitly
>reported, rather than implicitly derived at the sender. This might cause
>problems for PGMCC, for example.
The congestion control feedback could use different sequence
information than the data content identification ... For example, if
a different sequence number (i.e. different than the data content
identification sequencing) is used to mark packets for loss detection
that could be used in congestion control feedback ... In our MDP
congestion control implementation, we don't insert congestion control
probing information (which is marked with its own sequence number)
separately from transmitted data ... For something like PGMCC which
is doing a TCP-like ACK of the data packets, the "packet loss"
sequence marker on the data packets could perhaps be used? ... I
think data content identification needs to be separate for selective
repair anyway? ...
The "hierarchy" of coding block and segments gives you a degree of
NACK compression analogous to RLE and then aggregation doesn't
require the RLE decompression/re-encoding step you mention above
>
>I think that the need to do FEC count aggregation is a good argument
>against using a single long RLE bitmap.
>
>So I think we are left with three primary design choices:
>1) How to encode each block of packets? i.e. Count, Bitmap, None (for
>list NACKs, each block is of size 1)
>2) How to encode the series of blocks? Do we assume that they are all
>sequential, or do you encode each block with its starting sequence number?
>(note that this assumes the length of each block is the same)
Yes ... my assumption was that the bitmask marked a sequential series
of coding blocks ... in our case, the blocks are uniform in size so
the "offset" or data content sequence identifier of the first segment
of the block serves as the block identifier ... I think non-uniform
blocks could be accommodated, but the block identifier might need to
be interpreted differently ... but that might only be the concern of
the end systems ... intermediate systems (like generic assist
routers) might still be able to perform aggregation/pruning, etc
without needing to know that information ... this would be different
for more tree-based protocols which might wish to perform repair
subcasting, etc.
>3) How much history to put in each NACK? Do we just list the most
>immediate packets, or do we have some partial redundancy, or do we always
>encode the entire outstanding window? The more information we encode, the
>simpler the NACK generation algorithms become, but the harder the encoding
>algorithms in order to be able to deal with large windows.
The policy I have used in the past is to put as much history in the
NACK (only back to the point to where repair is needed) which will
fit into a single NACK message using the multicast session MTU as the
maximum payload size ... For normal circumstances, NACKs tend to be
small ... this limit is only hit when conditions are bad ... In our
protocol, the sender actually sort of nacks NACKs when those repair
requests ask for repairs earlier in history than the server is
willing to repair (for whatever reason, buffer limitations, expired
data, etc) ... In this NACK to the NACK (which we actually call a
SQUELCH command in protocol specification), the sender advertises his
current "window" of data he
is willing to repair ... This "SQUELCH" is multicast so that all
receivers (some of which may be in the same state as the original
NACKer) can "re-sync" to the sender and not generate anymore useless
NACKs ... again this is the _exceptional_ occurrence when conditions
are very bad, and server buffer limits (or other limits) are
otherwise exceeded.
>Brian
Brian
__________________________________
Brian Adamson
<http://manimac.itd.nrl.navy.mil>
<mailto:adamson@itd.nrl.navy.mil>
>From owner-rmt@listserv.lbl.gov Fri Sep 8 13:20:01 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id NAA19869;
Fri, 8 Sep 2000 13:17:17 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id NAA19865
for <rmt@listserv.lbl.gov>; Fri, 8 Sep 2000 13:17:15 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id NAA14174
for <rmt@listserv.lbl.gov>; Fri, 8 Sep 2000 13:17:15 -0700 (PDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id NAA14163
for <rmt@lbl.gov>; Fri, 8 Sep 2000 13:17:14 -0700 (PDT)
Received: from eastmail1.East.Sun.COM ([129.148.1.240])
by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA10058
for <rmt@lbl.gov>; Fri, 8 Sep 2000 13:17:12 -0700 (PDT)
Received: from bcn.East.Sun.COM (bcn.East.Sun.COM [129.148.75.4])
by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id QAA22672
for <rmt@lbl.gov>; Fri, 8 Sep 2000 16:17:11 -0400 (EDT)
Received: from bridge (bridge [129.148.75.125])
by bcn.East.Sun.COM (8.9.1b+Sun/8.9.1) with SMTP id QAA12322
for <rmt@lbl.gov>; Fri, 8 Sep 2000 16:17:11 -0400 (EDT)
Message-Id: <200009082017.QAA12322@bcn.East.Sun.COM>
Date: Fri, 8 Sep 2000 16:17:09 -0400 (EDT)
From: Dah Ming Chiu - Sun Microsystems <Dahming.Chiu@East.Sun.COM>
Reply-To: Dah Ming Chiu - Sun Microsystems <Dahming.Chiu@East.Sun.COM>
Subject: Re: Choices for TRACK/NACK report encoding
To: rmt@lbl.gov
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: ipYhK4dbBjoAN6bKrs/siw==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc
Sender: owner-rmt@lbl.gov
Precedence: bulk
Brian Whetthen wrote:
>My original concern were that I would like us to come up with ONE form for
>NACK encoding, that is the same for both TRACK and NACK, and is as simple
>as possible. Also, I would like the mechanism to have enough redundancy
>built in that reliable NACKs are not needed.
Yes, this is a very good goal.
I am having a little trouble following Brian Adamson's "hierarchical coding
block" proposal. I think the problem is with terminology. If you can
bear with me and explain your needs in simple terms, perhaps we can work
out some common format.
Let me state what I understand, and you can correct me where I err:
In TRACK terminology, regular FEC encoded stream does not require
loss feedback - it is "open loop". In "reactive" FEC usage, the sender
computes "parity" packets but does not send them until losses are reported.
This is the case error reporting is needed. What is needed at the sender
to determine what parity packets to send is a count of lost packets (given
a window of packets), rather than the specific packets lost. This count
determines the number of parity packets needed.
To aggregate the count up the tree to the sender, you need a bitmap to
know which packets are lost by each receiver so you don't count duplicate
packets. This makes the requirement for reporting losses roughly the
same wether it is ACK, NACK or reactive FEC.
I think the common format can be as simple as
<seqnum, bitmask>
plus other flags and identifiers.
If we really have a huge bitmask, the question is whether it should sent as
<track-header><seqnum, bitmask><seqnum, bitmask>...<seqnum, bitmask>
or
<track-header><seqnum, bitmask>
<track-header><seqnum, bitmask>
i.e. separate packets.
Could you explain your proposal in this simple terminology?
Thanks
Dah Ming
>From owner-rmt@listserv.lbl.gov Sun Sep 10 07:03:41 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id GAA25770;
Sun, 10 Sep 2000 06:59:50 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id GAA25766
for <rmt@listserv.lbl.gov>; Sun, 10 Sep 2000 06:59:48 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id GAA17059
for <rmt@listserv.lbl.gov>; Sun, 10 Sep 2000 06:59:47 -0700 (PDT)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
by SpamWall.lbl.gov (8.9.3/8.9.3) with SMTP id GAA17056
for <rmt@lbl.gov>; Sun, 10 Sep 2000 06:59:46 -0700 (PDT)
Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP
id <g.07997-0@bells.cs.ucl.ac.uk>; Sun, 10 Sep 2000 14:58:24 +0100
To: Brian Whetten <whetten@talarian.com>
cc: Brian Adamson <adamson@itd.nrl.navy.mil>, rmt@lbl.gov
Subject: Re: Choices for TRACK/NACK report encoding
In-reply-to: Your message of "Fri, 08 Sep 2000 10:39:30 PDT." <4.1.20000908100047.021b5eb0@mailhost.talarian.com>
Date: Sun, 10 Sep 2000 14:58:22 +0100
Message-ID: <2030.968594302@cs.ucl.ac.uk>
From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
Sender: owner-rmt@lbl.gov
Precedence: bulk
In message <4.1.20000908100047.021b5eb0@mailhost.talarian.com>, Brian Whetten t
yped:
>>Jon, I think FEC encoded NACK bitmaps is overly complex and unecessary, but
>>I'm not sure I actually understand what your proposal is.
the info in the return path does not have to be 100% accurate -we can
err in either direction - not giveing enough detail _can_ result in
excessive retransmits (not necessariyl a big problem for
aggregating/filtering routers or servers), or excessive
stall/congestion back off.....giving too much detail clogs the return
path.....layered fec coding the receive sequence number lists allows the
aggregtion ponts to choose how to err...
>>
>>Brian, my initial reaction to your proposal was that it was too complex,
>>but now I'm not so sure. One issue though, is that you need to pass up the
>>most recent congestion information you have in each NACK. If you are not
>>NACKing the most recent packets, then this has to definitely be explicitly
>>reported, rather than implicitly derived at the sender. This might cause
>>problems for PGMCC, for example.
>>
>>I think that the need to do FEC count aggregation is a good argument
>>against using a single long RLE bitmap.
>>
>>So I think we are left with three primary design choices:
>>1) How to encode each block of packets? i.e. Count, Bitmap, None (for
>>list NACKs, each block is of size 1)
>>2) How to encode the series of blocks? Do we assume that they are all
>>sequential, or do you encode each block with its starting sequence number?
>>(note that this assumes the length of each block is the same)
>>3) How much history to put in each NACK? Do we just list the most
>>immediate packets, or do we have some partial redundancy, or do we always
>>encode the entire outstanding window? The more information we encode, the
>>simpler the NACK generation algorithms become, but the harder the encoding
>>algorithms in order to be able to deal with large windows.
>>
>>Brian
>>
>>At 04:10 PM 9/8/2000 +0100, Jon Crowcroft wrote:
>>>
>>>so we have a large range+accuracy problem in returning
>>>data to the sender(s) about missing sequence numbers
>>>and so if the ack return path is noisy, then lets subject
>>>the problem to the same attack s we did to data in the forward
>>>path
>>>
>>>layered FEC encoded SACK messages...
>>>
>>> cheers
>>>
>>> jon
>>>
>>
>>
cheers
jon
>From owner-rmt@listserv.lbl.gov Tue Sep 12 03:59:10 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id DAA01518;
Tue, 12 Sep 2000 03:55:30 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id DAA01514
for <rmt@listserv.lbl.gov>; Tue, 12 Sep 2000 03:55:27 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id DAA23805
for <rmt@listserv.lbl.gov>; Tue, 12 Sep 2000 03:55:27 -0700 (PDT)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
by SpamWall.lbl.gov (8.9.3/8.9.3) with SMTP id DAA23801
for <rmt@lbl.gov>; Tue, 12 Sep 2000 03:55:26 -0700 (PDT)
Received: from sonic2.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP
id <g.14261-0@bells.cs.ucl.ac.uk>; Tue, 12 Sep 2000 11:55:21 +0100
to: rmt@lbl.gov
Subject: MSc report on multicast and crowded virtual spaces
Date: Tue, 12 Sep 2000 11:55:20 +0100
Message-ID: <969.968756120@cs.ucl.ac.uk>
From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
Sender: owner-rmt@lbl.gov
Precedence: bulk
some relevance to some of this group:
ftp://cs.ucl.ac.uk/darpa/crowded.ps.gz
on mapping large crowded distributed LSVEs into multicast...
part funded by sprintlabs, work by MSc student Roula Abou-Haidar
on our graphics course, has a review of network support for LSVEs etc....
(warning 7M gzipped ps uncompresses to 65M due to color images)
cheers
jon
>From owner-rmt@listserv.lbl.gov Fri Sep 22 08:23:57 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id IAA14821;
Fri, 22 Sep 2000 08:18:24 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id IAA14817
for <rmt@listserv.lbl.gov>; Fri, 22 Sep 2000 08:18:21 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id IAA15576
for <rmt@listserv.lbl.gov>; Fri, 22 Sep 2000 08:18:21 -0700 (PDT)
Received: from mailman.sprintlabs.com (mx.sprintlabs.com [208.30.174.2])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id IAA15573
for <rmt@lbl.gov>; Fri, 22 Sep 2000 08:18:20 -0700 (PDT)
Received: from sprintlabs.com (ip199-2-53-110.sprintlabs.com [199.2.53.110]) by mailman.sprintlabs.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
id R668PN5Y; Fri, 22 Sep 2000 08:17:50 -0700
Message-ID: <39CB77B9.5AE3FD7D@sprintlabs.com>
Date: Fri, 22 Sep 2000 08:16:09 -0700
From: christophe diot <cdiot@sprintlabs.com>
Reply-To: cdiot@sprintlabs.com
Organization: Sprint ATL
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Cost264@lip6.fr, rm@mash.CS.Berkeley.EDU, end2end-interest@ISI.EDU,
tccc@ieee.org, itc@ieee.org, maddogs@ietf.org,
ssm-interest@external.cisco.com, rmt@lbl.gov
Subject: NGC 2000: call for posters
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-rmt@lbl.gov
Precedence: bulk
There will be 2 poster sessions during NGC 2000,
November 8, 9, 10, in Stanford, CA.
http://www.cs.ucsb.edu/ngc2000
Poster sessions are highly interactive sessions that give
posters' authors an opportunity to discuss with workshop
participants early research result or on-going research.
The call for poster available on the NGC 2000 web site
gives more details on how to submit a poster.
>From owner-rmt@listserv.lbl.gov Mon Sep 25 15:22:09 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id PAA28441;
Mon, 25 Sep 2000 15:17:36 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id PAA28437
for <rmt@listserv.lbl.gov>; Mon, 25 Sep 2000 15:17:34 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id PAA07523
for <rmt@listserv.lbl.gov>; Mon, 25 Sep 2000 15:17:32 -0700 (PDT)
Received: from mailman.sprintlabs.com (mx.sprintlabs.com [208.30.174.2])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id PAA07510
for <rmt@lbl.gov>; Mon, 25 Sep 2000 15:17:31 -0700 (PDT)
Received: from sprintlabs.com (ip199-2-54-230.sprintlabs.com [199.2.54.230]) by mailman.sprintlabs.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
id R668PSDF; Mon, 25 Sep 2000 15:17:02 -0700
Message-ID: <39CF829E.A45A14A2@sprintlabs.com>
Date: Mon, 25 Sep 2000 09:51:42 -0700
From: Christophe Diot <cdiot@sprintlabs.com>
Organization: SPRINT ATL
X-Mailer: Mozilla 4.61 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Cost264@lip6.fr, rm@mash.CS.Berkeley.EDU, end2end-interest@ISI.EDU,
tccc@ieee.org, itc@ieee.org, maddogs@ietf.org,
ssm-interest@external.cisco.com, rmt@lbl.gov
Subject: NGC 2000: posters submission extension
References: <39CB77B9.5AE3FD7D@sprintlabs.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-rmt@lbl.gov
Precedence: bulk
Given that we have allocated a week extension to almost all poster
authors, we decided to extend the poster submission deadline until
until next sunday. But there will be no further extension granted :)
NGC 2000 - Networked Group Communication
http://www.cs.ucsb.edu/ngc2000
>From owner-rmt@listserv.lbl.gov Tue Sep 26 15:14:59 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id PAA02375;
Tue, 26 Sep 2000 15:13:53 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id PAA02370
for <rmt@listserv.lbl.gov>; Tue, 26 Sep 2000 15:13:51 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id PAA03438
for <rmt@listserv.lbl.gov>; Tue, 26 Sep 2000 15:13:50 -0700 (PDT)
Received: from mailman.sprintlabs.com (mx.sprintlabs.com [208.30.174.2])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id PAA03435
for <rmt@lbl.gov>; Tue, 26 Sep 2000 15:13:49 -0700 (PDT)
Received: from sprintlabs.com (ip199-2-53-110.sprintlabs.com [199.2.53.110]) by mailman.sprintlabs.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
id R668P42G; Tue, 26 Sep 2000 15:13:19 -0700
Message-ID: <39D11F0B.934908B9@sprintlabs.com>
Date: Tue, 26 Sep 2000 15:11:23 -0700
From: christophe diot <cdiot@sprintlabs.com>
Reply-To: cdiot@sprintlabs.com
Organization: Sprint ATL
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Cost264@lip6.fr, rm@mash.CS.Berkeley.EDU, end2end-interest@ISI.EDU,
tccc@ieee.org, itc@ieee.org, maddogs@ietf.org,
ssm-interest@external.cisco.com, rmt@lbl.gov
Subject: NGC 2000: registration open
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-rmt@lbl.gov
Precedence: bulk
Registration in now open for NGC 2000
www.cs.ucsb.edu/ngc2000
Please notice that workshop participation is limited 100.
>From owner-rmt@listserv.lbl.gov Tue Oct 3 10:09:51 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id KAA14024;
Tue, 3 Oct 2000 10:07:07 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal2.lbl.gov (postal2.lbl.gov [131.243.129.79])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id KAA14020
for <rmt@listserv.lbl.gov>; Tue, 3 Oct 2000 10:07:05 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal2.lbl.gov (8.9.3/8.9.3) with ESMTP id KAA28921
for <rmt@listserv.lbl.gov>; Tue, 3 Oct 2000 10:07:05 -0700 (PDT)
Received: from Pedro (ppp176.197dip.netdial.caribe.net [209.91.197.176])
by SpamWall.lbl.gov (8.9.3/8.9.3) with SMTP id KAA28917
for <rmt@lbl.gov>; Tue, 3 Oct 2000 10:06:46 -0700 (PDT)
Message-Id: <200010031706.KAA28917@SpamWall.lbl.gov>
From: "juan" <dragsterpr@yahoo.com>
To: <rmt@lbl.gov>
Subject:
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Date: Tue, 3 Oct 2000 13:19:24
Sender: owner-rmt@lbl.gov
Precedence: bulk
From: tunes <tunes@coqui.net>
To: tunes <tunes@coqui.net>
Subject: Fw: PLEASE READ! 5 min. of your time for $50,000 in 90 DAYS!
Date: Friday, August 11, 2000 9:38 AM
----- Original Message -----
From: <hpw2@swr3.de>
To: <appli@aol.com>
Sent: Monday, July 24, 2000 2:39 PM
Subject: PLEASE READ! 5 min. of your time for $50,000 in 90 DAYS!
>
>
> Dear Friend,
>
> This really works! Don't miss this opportunity. Get involved and it will
> work for you as it does for us!!!!!
>
> Thank you for your time and interest.
>
> This email contains the ENTIRE PLAN of how YOU can make $50,000 or
> more in the next 90 days simply sending email!
>
> Seem impossible? Just read on and see how easy this is....
>
> Due to the popularity of this letter on the Internet, a major nightly
> news program recently devoted an entire show to the investigation of the
> program described below to see if it really can make people money.
>
> The show also investigated whether or not the program was legal.
> Their findings proved that there are absolutely no laws prohibiting the
> participation in the program. This has helped to show people that
> this is a simple, harmless and fun way to make some extra money at home.
>
> The results have been truly remarkable. So many people are
> participating that those involved are doing much better than ever
> before. Since everyone makes more as more people try it
> out, its been very exciting.
>
> You will understand once you try it yourself!
>
> ********* THE ENTIRE PLAN IS HERE BELOW *********
>
> *** Print This Now For Future Reference ***
>
> $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
>
> If you would like to make at least $50,000 in less than 90 days!
> Please read this program...THEN READ IT AGAIN!!
>
> $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
>
> THIS IS A LEGITIMATE, LEGAL, MONEY MAKING OPPORTUNITY!!
>
> It does NOT require you to come into contact with people or make or
> take any telephone calls. Just follow the instructions, and you
> will make money. This simplified e-mail marketing program works
> perfectly 100% EVERY TIME!
>
> E-mail is the sales tool of the future. Take advantage of this
> virtually free method of advertising NOW!!! The longer you wait,
> the more people will be doing business using email. Get your
> piece of this action!!!
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> Hello - My name is Johnathon Rourke, I'm from Rhode Island.
>
> The enclosed information is something I almost let slip through my
> fingers. Fortunately, sometime later I re-read everything and gave
> some thought and study to it. Two years ago, the corporation I worked
> for the past twelve years down-sized and my position was eliminated.
> After unproductive job interviews, I decided to open my own business.
> Over the past year, I incurred many unforeseen financial problems.
> I owed my family, friends and creditors over $35,000. The economy was
> taking a toll on my business and I just couldn't seem to make ends
> meet. I had to refinance and borrow against my home to support my
> family and struggling business.
>
> AT THAT MOMENT something significant happened in my life. I am
> writing to share the experience in hopes that this could change your
> life FOREVER.
>
> FINANCIALLY$$$!!!
>
> In mid December, I received this program in my e-mail. Six months
> prior to receiving this program I had been sending away for information
> on various business opportunities. All of the programs I received, in my
> opinion, were not cost effective. They were either too difficult for me
> to comprehend or the initial investment was too much for me to risk to
> see if they would work. But as I was saying, in December of 1997 I
received
> this program. I didn't send for it, or ask for it, they just got my name
off
> a mailing list.
>
> THANK GOODNESS FOR THAT!!! After reading it several times, to make sure
> I was reading it correctly. I couldn't believe my eyes! Here was a
> MONEY MAKING MACHINE I could start immediately without any debt.
>
> Like most of you I was still a little skeptical and a little worried
> about the legal aspects of it all. So I checked it out with the U.S.
> Post Office (1-800-725-2161 24-hrs) and they confirmed that it is indeed
>
> legal!
>
> After determining the program was LEGAL I decided "WHY NOT!?!??"
>
> Initially I sent out 10,000 e-mails. It cost me about $15 for my time
> on-line. The great thing about e-mail is that I don't need any for
> printing to send out the program, and because I also send the product
> (reports) by e-mail, my only expense is my time.
>
> In less than one week, I was starting to receive orders for REPORT #1.
> By January 13, I had received 26 orders for REPORT #1. Your goal is to
> "RECEIVE at least 20 ORDERS FOR REPORT #1 WITHIN 2 WEEKS. IF YOU DON'T,
> SEND OUT MORE PROGRAMS UNTIL YOU DO.
>
> My first step in making $50,000 in 90 days was done. By January 30, I
> had received 196 orders for REPORT #2. Your goal is to "RECEIVE AT LEAST
>
> 100+ ORDERS FOR REPORT #2 WITHIN 2 WEEKS. IF NOT, SEND OUT MORE
PROGRAMS
>
> UNTIL YOU DO. ONCE YOU HAVE 100 ORDERS, THE REST IS EASY, RELAX, YOU
> WILL MAKE YOUR $50,000 GOAL."
>
> Well, I had 196 orders for REPORT #2. 96 more than I needed.
> So I sat back and relaxed. By March 1, of my e-mailing of 10,000,
> received $58,000 with more coming in every day. I paid off ALL my debts
> and bought a much needed new car!
>
> Please take your time to read this plan, IT WILL CHANGE YOUR LIFE
> FOREVER$!!! Remember, it won't work if you don't try it.
> This program does work, but you must follow it EXACTLY!
>
> Especially the rules of not trying to place your name in a different
> place. It won't work and you'll lose out on a lot of money! In order
> for this program to work, you must meet your goal of 20+ orders for
> REPORT #1, and 100+ orders for REPORT #2 and you will make $50,000 or
> more in 90 days.
>
> I AM LIVING PROOF THAT IT WORKS!!! If you choose not to participate in
> this program, I am sorry. It really is a great opportunity with little
> cost or risk to you. If you choose to participate, follow the program
> and you will be on your way to financial security. If you are a fellow
> business owner and are in financial trouble like I was, or you want to
> start your own business, consider this a sign. I DID! $$
>
> Sincerely,
>
> Johnathon Rourke
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> A PERSONAL NOTE FROM THE ORIGINATOR OF THIS PROGRAM:
>
> By the time you have read the enclosed program and reports, you should
> have concluded that such a program, and one that is legal, could not
> have been created by an amateur. Let me tell you a little about myself.
> I had a profitable business for 10 years. Then in 1979 my business began
> falling off. I was doing the same things that were previously successful
> for me, but it wasn't working. Finally, I figured it out. It wasn't
> me, it was the economy. Inflation and recession had replaced the stable
> economy that had been with us since 1945.
>
> I don't have to tell you what happened to the unemployment rate...
> because many of you know from first hand experience. There were more
> failures and bankruptcies than ever before. The middle class was
> vanishing. Those who knew what they were doing invested wisely and
> moved up. Those who did not, including those who never had anything to
save or
> invest, were moving down into the ranks of the poor. As the saying goes,
>
> "THE RICH GET RICHER AND THE POOR GET POORER." The traditional methods
> of making money will never allow you to"move up" or "get rich", inflation
> will see to that.
>
> You have just received information that can give you financial
> freedom for the rest of your life, with "NO RISK" and "JUST A LITTLE BIT
> OF EFFORT." You can make more money in the next few months than you
> have ever imagined. I should also point out that I will not see a penny
of
> this money, nor anyone else who has provided a testimonial for this
> program.
>
> I have retired from the program after sending thousands and thousands
> of programs. Follow the program EXACTLY AS INSTRUCTED. Do not change it
> in any way. It works exceedingly well as it is now. Remember to e-mail a
>
> copy of this exciting report to everyone you can think of. One of the
> people you send this to may send out 50,000...and your name will be on
> everyone of them! Remember though, the more you send out, the more
> potential customers you will reach. So my friend, I have given you the
> ideas, information, materials and opportunity to become financially
> independent.
>
> IT IS UP TO YOU!! NOW DO IT!!
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> Before you delete this program from your in box, as I almost did,
> take a little time to read it and REALLY THINK ABOUT IT. Get a pencil
> and figure out what could happen when YOU participate. Figure out the
> worst possible response and no matter how you calculate it, you will
> still make a lot of money! You will definitely get back what you invested.
Any
> doubts you have will vanish when your first orders come in.
>
> $$$ IT WORKS!!! $$$
>
> Jody Jacobs Richmond, VA
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> HERE'S HOW THIS AMAZING PROGRAM WILL MAKE YOU THOUSANDS OF
> DOLLAR$$$$!!!!
>
> This method of raising capital REALLY WORKS 100% EVERY TIME. I am
> sure that you could use up to $50,000 or more in the next 90 days.
> before you say "BULL... ", please read this program carefully. This is
> not a chain letter, but a perfectly legal money making business.
>
> As with all multi-level businesses, we build our business by
> recruiting new partners and selling our products. Every state in the USA
> allows you to recruit new multi-level business partners, and we sell and
> deliver a product for EVERY dollar received.
>
> YOUR ORDERS COME BY MAIL AND ARE FILLED BY E-MAIL, so you are not
> involved in personal selling. You do it privately in your own home,
> store or office. This is the EASIEST marketing plan anywhere! It is
> simply order filling by email!
>
> *******************************************************************
> The product is informational and instructional material, keys to the
> secrets for everyone on how to open the doors to the magic world of
> E-COMMERCE , the information highway, the wave of the future !
>
> PLAN SUMMARY:
>
> (1) You order the 4 reports listed below ($5US each) They come to you
> by email.
>
> (2) Save a copy of this entire letter and put your name after Report
> #1 and move the other names down.
>
> (3) Via the internet, access Yahoo.com or any of the other major
> search engines to locate hundreds of bulk email service companies
> (search for "bulk email") and have them send 25,000 - 50,000 emails for
> you about $49+)
>
> (4) Orders will come to you by postal mail - simply email them the
> Report they ordered. Let me ask you - isn't this about as easy as it
> gets?
>
> *******************************************************************
>
> By the way there are over 50 MILLION email addresses with millions
> more joining the internet each year so don't worry about "running out"
> or "saturation". People are used to seeing and hearing the same
> advertisements every day on radio/TV. How many times have you received
> the same pizza flyers on your door? Then one day you are hungry for
> pizza and you order one. Same thing with this letter. I received this
> letter many times - then one day I decided it was time to try it.
>
> *******************************************************************
>
> YOU CAN START TODAY - JUST DO THESE EASY STEPS:
>
> STEP #1. ORDER THE FOUR REPORTS
>
> Order the four reports shown on the list below (you can't sell
> them if you don't order them). -- For each report, send $5.00US
> CASH, the NAME & NUMBER OF THE REPORT YOU ARE ORDERING,
> YOUR E-MAIL ADDRESS, and YOUR NAME & RETURN ADDRESS (in case of a
> problem) to the person whose name appears on the list next to the
> report. MAKE SURE YOUR RETURN ADDRESS IS ON YOUR ENVELOPE IN CASE
OF ANY
MAIL
> PROBLEMS! Within a few days you will receive, by e-mail, each of the four
> reports. Save them on your computer so you can send them to the 1,000's
> of people who will order them from you.
>
> STEP #2. ADD YOUR MAILING ADDRESS TO THIS LETTER
> a. Look below for the listing of the four reports.
> b. After you've ordered the four reports, delete the name and address
> under REPORT #4. This person has made it through the cycle.
> c. Move the name and address under REPORT #3 down to REPORT #4.
> d. Move the name and address under REPORT #2 down to REPORT #3.
> e. Move the name and address under REPORT #1 down to REPORT #2.
> f. Insert your name/address in the REPORT #1 position.
> Please make sure you COPY ALL INFORMATION, every name and address,
> ACCURATELY!
>
> STEP #3. Take this entire letter, including the modified list of
> names, and save it to your computer. Make NO changes to these
> instructions. Now you are ready to use this entire email to send by
> email to prospects.
>
> Report #1 will tell you how to download bulk email software and email
> addresses so you can send it out to thousands of people while you
> sleep! Remember that 50,000+ new people are joining the internet every
> month.
>
> Your cost to participate in this is practically nothing (surely you
> can afford $20US and initial bulk mailing cost). You obviously already
> have a computer and an Internet connection and e-mail is FREE!
> There are two primary methods of building your downline:
>
> METHOD #1: SENDING BULK E-MAIL Let's say that you decide to start
> small, just to see how it goes, and we'll assume you and all those
> involved email out only 2,000 programs each. Let's also assume that the
> mailing receives a 0.5% response. The response could be much better.
> Also, many people will email outhundreds of thousands of programs instead
of
> 2,000 (Why stop at 2000?). But continuing with this example, you send
> out only 2,000 programs. With a 0.5% response, that is only 10 orders for
> REPORT #1. Those 10 people respond by sending out 2,000 programs each
> for a total of 20,000. Out of those 0.5%, 100 people respond and order
>
> REPORT #2. Those 100 mail out 2,000 programs each for a total of
> 200,000. The 0.5% response to that is 1,000 orders for
>
> REPORT #3. Those 1,000 send out 2,000 programs each for a 2,000,000
> total. The 0.5% response to that is 10,000 orders for
>
> REPORT #4. That's 10,000 $5 bills for you. CASH!!!
> Your total income in this example is $50 + $500 + $5,000 + $50,000
> for a total of $55,550!!!
>
> REMEMBER FRIEND, THIS IS ASSUMING 1,990 OUT OF THE 2,000 PEOPLE YOU
> MAIL TO WILL DO ABSOLUTELY NOTHING AND TRASH THIS PROGRAM!
> DARE TO THINK FOR A MOMENT WHAT WOULD HAPPEN IF EVERYONE, OR
HALF
> SENT OUT 100,000 PROGRAMS INSTEAD OF 2,000. Believe me, many people will
> do just that, and more!
>
> METHOD #2 - PLACING FREE ADS ON THE INTERNET
> Advertising on the internet is very, very inexpensive, and there are
> HUNDREDS of FREE places to advertise. Let's say you decide to start
> small just to see how well it works. Assume your goal is to get ONLY 10
> people to participate on your first level. (Placing a lot of FREE ads on
>
> the Internet will EASILY get a larger response.) Also assume that
> everyone
> else in YOUR ORGANIZATION gets ONLY 10 downline members. Look how this
> small number accumulates to achieve the STAGGERING results below:
>
> 1st level--your first 10 send you
> $5................................$50
>
> 2nd level--10 members from those 10 ($5 x 100).............$500
> 3rd level--10 members from those 100 ($5 x 1,000)........$5,000
> 4th level--10 members from those 1,000 ($5 x 10,000)..$50,000
>
> $$$$$$ THIS TOTALS ----------$55,550 $$$$$$
>
> AMAZING ISN'T IT? Remember friends, this assumes that the people who
> participate only recruit 10 people each. Think for a moment what would
> happen if they got 20 people to participate! Most people get 100's of
> participants and many will continue to work this program, sending out
> programs WITH YOUR NAME ON THEM for years! THINK ABOUT IT!
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> People are going to get emails about this plan from you or somebody
> else and many will work this plan - the question is - Don't you want
> your name to be on the emails they will send out?
>
> * * * DON'T MISS OUT!!! * * * JUST TRY IT ONCE!!! * * *
>
> * * SEE WHAT HAPPENS!!! *** YOU'LL BE AMAZED!!!* *
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> ALWAYS PROVIDE SAME-DAY SERVICE ON ALL ORDERS!
>
> This will guarantee that the e-mail THEY send out with YOUR name and
> address on it will be prompt because they can't advertise until they
> receive the report!
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> GET STARTED TODAY: PLACE YOUR ORDER FOR THE FOUR REPORTS NOW.
>
> Notes: -- ALWAYS SEND $5 CASH (U.S. CURRENCY) FOR EACH REPORT. CHECKS
> NOT ACCEPTED. Make sure the cash is concealed by wrapping it in two
> sheets of paper. On one of those sheets of paper write:
>
> (a) the number & name of the report you are ordering
>
> (b) your e-mail address, and
>
> (c) your name & postal address.
>
> REPORT #1 "The Insider's Guide to Advertising for Free on the Internet"
>
> ORDER REPORT #1 FROM:
>PETER OJEDA
> 1691 JUAN KEPLER URB. TULIPAN
SAN JUAN P.R. 00926
> REPORT #2 "The Insider's Guide to Sending Bulk E-mail on the Internet"
>
> ORDER REPORT #2 FROM:
> KATHY BRONIAK
> 4200-E LYNN POINT LANE
>RALEIGH , NC27613
>
REPORT #3 "The Secrets to Multilevel Marketing on the Internet"
>
> ORDER REPORT #3 FROM:
>JAKE PELLETIER
> 128 E 20TH AVE.
> VANCOUVER B.C.
>V5V 1L9
> REPORT #4 "How to become a Millionaire utilizing the Power of Multilevel
>
> Marketing and the Internet"
>
> ORDER REPORT #4 FROM:
> KEN KNIGHT
> P.O. BOX 535.
> 2208 MAPLE ROAD.N.
> SOOKE B.C.
> VOS 1NO
> ******* TIPS FOR SUCCESS *******
>
> TREAT THIS AS YOUR BUSINESS! Be prompt, professional, and follow the
> directions accurately. -- Send for the four reports IMMEDIATELY so you
> will have them when the orders start coming in because:
> When you receive a $5 order, you MUST send out the requested
> product/report. It is required for this to be a legal business and
> they need the reports to send out their letters (with your name on
> them!)
>
> -- ALWAYS PROVIDE SAME-DAY SERVICE ON THE ORDERS YOU RECEIVE. -- Be
> patient and persistent with this program - If you follow the
> instructions exactly - results WILL FOLLOW. $$$$
>
> ******* YOUR SUCCESS GUIDELINES *******
>
> Follow these guidelines to guarantee your success: If you don't
> receive 20 orders for REPORT #1 within two weeks, continue advertising
> or sending e-mails until you do. Then, a couple of weeks later you
> should receive at least 100 orders for REPORT#2. If you don't, continue
> advertising or sending e-mails until you do. Once you have received 100
> or more orders for REPORT #2, YOU CAN RELAX, because the system is already
> working for you, and the cash will continue to roll in!
>
> THIS IS IMPORTANT TO REMEMBER: Every time your name is moved down on
> the list, you are placed in front of a DIFFERENT report. You can KEEP
> TRACK of your PROGRESS by watching which report people are ordering from
> you.
>
> To generate more income, simply send another batch of e-mails or
> continue placing ads and start the whole process again! There is no
> limit to the income you will generate from this business!
>
> Before you make your decision as to whether or not you participate in
> this program. Please answer one question. ARE YOU HAPPY WITH YOUR
> PRESENT INCOME OR JOB? If the answer is no, then please look at the
> following facts about this super simple MLM program:
>
> 1. NO face to face selling, NO meetings, NO inventory!
> NO Telephone calls, NO big cost to start!, NOthing to learn,
> NO skills needed! (Surely you know how to send email?)
>
> 2. No equipment to buy - you already have a computer and
> internet connection - so you have everything you need to fill
> orders!
>
> 3. You are selling a product which does NOT COST ANYTHING TO PRODUCE OR
> SHIP! (Emailing copies of the reports is FREE!)
>
> 4. All of your customers pay you in CA$H! This program will change
> your LIFE FOREVER!! Look at the potential for you to be able to quit
> your job and live a life of luxury you could only dream about!
> Imagine getting out of debt and buying the car and home of your
> dreams and being able to work a super-high paying leisurely
> easy business from home!
>
> $$$ FINALLY MAKE SOME DREAMS COME TRUE! $$$
>
> ACT NOW! Take your first step toward achieving financial independence.
> Order the reports and follow the program outlined above-- SUCCESS will
> be your reward.
>
> Thank you for your time and consideration.
>
> PLEASE NOTE: If you need help with starting a business, registering a
> business name, learning how income tax is handled, etc., contact your
> local office of the Small Business Administration (a Federal Agency)
> 1-800-827-5722 for free help and answers to questions.
>
> Also, the Internal Revenue Service offers free help via telephone and
> free seminars about business tax reuirements. Your earnings are highly
> dependent on your activities and advertising. The information contained
> on this site and in the report constitutes no guarantees stated nor
> implied. In the event that it is determined that this site or report
> constitutes a guarantee of any kind, that guarantee is now void. The
> earnings amounts listed on this site and in the report are estimates
> only.
> If you have any questions of the legality of this program, contact the
> Office of Associate Director for Marketing Practices, Federal Trade
> Commission, Bureau of Consumer Protection in Washington, DC.
>
> ================================================
>
> Under Bill s.1618 TITLE III passed by the 105th US Congress this
> letter cannot be considered spam as long as the sender includes
> contact information and a method of removal.
>
> This is a one time e-mail transmission. No request for removal is
> necessary.
>
>
>
>From owner-rmt@listserv.lbl.gov Fri Oct 6 01:09:13 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id BAA02307;
Fri, 6 Oct 2000 01:05:34 -0700 (PDT)
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id BAA02303
for <rmt@listserv.lbl.gov>; Fri, 6 Oct 2000 01:05:32 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id BAA23944
for <rmt@listserv.lbl.gov>; Fri, 6 Oct 2000 01:05:32 -0700 (PDT)
Received: from ra.inria.fr (IDENT:root@ra.inria.fr [138.96.32.72])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id BAA23941
for <rmt@lbl.gov>; Fri, 6 Oct 2000 01:05:30 -0700 (PDT)
Received: from sophia.inria.fr by ra.inria.fr (8.10.0/8.10.0) with ESMTP id e9685Rt02383 for <rmt@lbl.gov>; Fri, 6 Oct 2000 10:05:27 +0200
X-Authentication-Warning: ra.inria.fr: Host localhost [127.0.0.1] claimed to be sophia.inria.fr
Message-ID: <39DD87C6.10C58153@sophia.inria.fr>
Date: Fri, 06 Oct 2000 08:05:26 +0000
From: Fethi Filali <Fethi.Filali@sophia.inria.fr>
Organization: INRIA Sophia-Antipolis
X-Mailer: Mozilla 4.5 [en] (X11; I; Linux 2.2.14 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: rmt@lbl.gov
Subject: Multicast and Unicast Flows Fairness
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-rmt@lbl.gov
Precedence: bulk
hi all,
My question is how the internet community define the fairness between
reliable multicast and TCP connections sharing the same communication
link.
Should a reliable multicast flows be treated as a TCP flow ? Or, should
the reliable multicast flows be given more bandwidth than TCP flow
because it is intended to serve more receivers? In the second case, how
much more bandwidth should be given to the multicast flow and how do the
Internet community define this fairness.
Thanks,
Fethi.
>From owner-rmt@listserv.lbl.gov Fri Oct 6 01:23:39 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id BAA02343;
Fri, 6 Oct 2000 01:23:34 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id BAA02339
for <rmt@listserv.lbl.gov>; Fri, 6 Oct 2000 01:23:30 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id BAA25205
for <rmt@listserv.lbl.gov>; Fri, 6 Oct 2000 01:23:29 -0700 (PDT)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
by SpamWall.lbl.gov (8.9.3/8.9.3) with SMTP id BAA25201
for <rmt@lbl.gov>; Fri, 6 Oct 2000 01:23:28 -0700 (PDT)
Received: from hocus.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP
id <g.05810-0@bells.cs.ucl.ac.uk>; Fri, 6 Oct 2000 09:23:22 +0100
To: Fethi Filali <Fethi.Filali@sophia.inria.fr>
cc: rmt@lbl.gov
Subject: Re: Multicast and Unicast Flows Fairness
In-reply-to: Your message of "Fri, 06 Oct 2000 08:05:26 -0000." <39DD87C6.10C58153@sophia.inria.fr>
Date: Fri, 06 Oct 2000 09:23:21 +0100
Message-ID: <1809.970820601@cs.ucl.ac.uk>
From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
Sender: owner-rmt@lbl.gov
Precedence: bulk
In message <39DD87C6.10C58153@sophia.inria.fr>, Fethi Filali typed:
>>My question is how the internet community define the fairness between
>>reliable multicast and TCP connections sharing the same communication
>>link.
jolly good question....
>>Should a reliable multicast flows be treated as a TCP flow ? Or, should
>>the reliable multicast flows be given more bandwidth than TCP flow
>>because it is intended to serve more receivers? In the second case, how
>>much more bandwidth should be given to the multicast flow and how do the
>>Internet community define this fairness.
The problem is that there is no Internet community:-)
its up to a mix of people with different motivations
1/ content distribution
2/ service providers
3/ RMT Product vendors
4/ router vendors
all have potentially different cost/benefit analysis for multicast and
for multicast versus unicast
1/ save capacity at servers
2/ have the headaches of having yet another routing protocol to
operate and maintain, yet another set of traffic to engineer for
3/ have varying applicability
4/ have various cost/benefit analysis for state and packet copy
(e.g. switch router fabric for multicast costs more)...
then there's a pure academicx approach....
now the BIG problem in all this is that the internet is not exactly
fair anyhow - sure TCP-friendliness (see
http://www.psc.edu/networking/tcp_friendly.html
and references therein)
is proportionally fair - some people say that for multicast we should
be max-min fair (and point out that if you have multicast state in
routers, then adding the state necessary for max-min fair policing is
only a constant overhead)....but then comparing a mix of TCP
proportional fair with a set of RMT flows that were max-min would be
weird (would depend _completly_ on the multicast tree topology,since
proporionality includes the _length_ of the path....whereas max-min is
just the cross section of traffic at the bottlenecks)...
maybe a new type of fairness could be introduced.....but what is your
goal?
if its to _promote_ multicast, then you'd want to let it get more
cpaacity, but for a price per source, it already does! if its to
create incentives to deploy, you might want to give multicast _less_
capacity than the equivalent TCP flow to the slowest or other receiver
(c.g. PGMCC and other single rate schemes)
it sure is tricky!
so you can see its not obvious
cheers
jon
>From owner-rmt@listserv.lbl.gov Fri Oct 6 05:45:58 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id FAA02771;
Fri, 6 Oct 2000 05:45:29 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id FAA02763
for <rmt@listserv.lbl.gov>; Fri, 6 Oct 2000 05:45:27 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id FAA15611
for <rmt@listserv.lbl.gov>; Fri, 6 Oct 2000 05:45:26 -0700 (PDT)
Received: from multicasttech.com (IDENT:root@ns2.multicasttech.com [63.105.122.8])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id FAA15595
for <rmt@lbl.gov>; Fri, 6 Oct 2000 05:45:21 -0700 (PDT)
Received: from [206.15.135.60] (HELO 21rst-century.com)
by multicasttech.com (CommuniGate Pro SMTP 3.3)
with ESMTP id 536293; Fri, 06 Oct 2000 08:42:34 -0400
Message-ID: <39DDCAD2.1B8CE037@21rst-century.com>
Date: Fri, 06 Oct 2000 08:51:30 -0400
From: Marshall Eubanks <tme@21rst-century.com>
Reply-To: tme@21rst-century.com
Organization: Multicast Technologies
X-Mailer: Mozilla 4.7C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; I; PPC)
X-Accept-Language: en
MIME-Version: 1.0
To: Fethi Filali <Fethi.Filali@sophia.inria.fr>
CC: rmt@lbl.gov, rem-conf@es.net
Subject: Re: Multicast and Unicast Flows Fairness
References: <39DD87C6.10C58153@sophia.inria.fr>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-rmt@lbl.gov
Precedence: bulk
Fethi Filali wrote:
>
> hi all,
>
> My question is how the internet community define the fairness between
> reliable multicast and TCP connections sharing the same communication
> link.
>
> Should a reliable multicast flows be treated as a TCP flow ? Or, should
> the reliable multicast flows be given more bandwidth than TCP flow
> because it is intended to serve more receivers? In the second case, how
> much more bandwidth should be given to the multicast flow and how do the
> Internet community define this fairness.
>
> Thanks,
>
> Fethi.
Dear Fethi;
This has been discussed at length on the AVT list, because of the
desire to add something about congestion control to the RTP profile. '
The current wording is (from draft-avt-profile, 2000])
If best-effort service is being used, RTP receivers SHOULD
monitor packet loss to ensure that the packet loss rate is
within acceptable parameters. Packet loss is considered
acceptable if a TCP flow across the same network path and
experiencing the same network conditions would achieve an
average throughput that is not less the RTP flow is
achieving. This condition can be satisfied by implementing
congestion control mechanisms to adapt the transmission
rate (or the number of layers subscribed for a layered
multicast session), or by arranging for a receiver to leave
the session if the loss rate is unacceptably high.
I did not like, and still do not like, this wording. TCP is not like
UDP, especially UDP multicast, and I see nothing ^Ófair^Ô about having a
multicast stream sharing the same bandwidth as a host of unicast TCP
sessions. In case of large scale receiver based RTP/UDP congestion
control, it is also very unclear how the receiver is to determine the
amount of TCP traffic. I argued that a scheme based on monitoring of
packet loss rates only was sufficient, and suggested a simple minded
congestion monitoring wording based purely on packet loss rates.
There followed a fair amount of discussion about this point, which has
resurfaced a number of time.
The following points have been made :
1.) UDP flows, without congestion control, can ruin a bandwidth
limited pipe - see [Jeffay, 1999] for an example of congestive collapse
(38% packet
loss) when you try and stuff TCP traffic + a 8 or 9 mbps UDP flow into
a 10 mbps channel.
2.) Conversely, most multicast applications are streaming audio or video,
and these do not respond well to TCP like changes in bandwidth - especially
the slow start / congestion control. It is possible that RMT would help here.
To the extent that there is consensus, I would cautiously say that
people have
focused more on avoiding congestive collapse instead of fairness. I
would also
cautiously claim a VERY rough consensus that multicast streams should be allowed
to take the bandwidth they need as long as there is not signs of serious
congestion, but
that they should throttle back or terminate entirely if there is, and
that this
should be determined by monitoring the rate of packet loss.
I am cc:ing the AVT list, for obvious reasons. I apologize for
those who get this twice.
References :
[draft-avt-profile, 2000] http://www.ietf.org/internet-drafts/draft-ietf-avt-profile-new-09.txt
[Jeffay, 1999] Towards a Better-Than-Best-Effort Forwarding Service for
Multimedia Flows, K. Jeffay, IEEE Multimedia, 6, 84-88, 1999. The
^Ólong^Ô version is available from
http://www.cs.unc.edu/~jeffay/papers/IEEE-MM-99-long.pdf
Regards
Marshall Eubanks
T.M. Eubanks
Multicast Technologies, Inc.
10301 Democracy Lane, Suite 410
Fairfax, Virginia 22030
Phone : 703-293-9624
Fax : 703-293-9609
e-mail : tme@on-the-i.com
http://www.on-the-i.com
>From owner-rmt@listserv.lbl.gov Fri Oct 6 08:57:50 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id IAA04046;
Fri, 6 Oct 2000 08:57:22 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id IAA04042
for <rmt@listserv.lbl.gov>; Fri, 6 Oct 2000 08:57:20 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id IAA18621
for <rmt@listserv.lbl.gov>; Fri, 6 Oct 2000 08:57:19 -0700 (PDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id IAA18597
for <rmt@lbl.gov>; Fri, 6 Oct 2000 08:57:17 -0700 (PDT)
Received: from eastmail1.East.Sun.COM ([129.148.1.240])
by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA24733;
Fri, 6 Oct 2000 08:57:08 -0700 (PDT)
Received: from bcn.East.Sun.COM (bcn.East.Sun.COM [129.148.75.4])
by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id LAA06563;
Fri, 6 Oct 2000 11:57:07 -0400 (EDT)
Received: from bridge (bridge [129.148.75.125])
by bcn.East.Sun.COM (8.9.1b+Sun/8.9.1) with SMTP id LAA26212;
Fri, 6 Oct 2000 11:57:07 -0400 (EDT)
Message-Id: <200010061557.LAA26212@bcn.East.Sun.COM>
Date: Fri, 6 Oct 2000 11:57:05 -0400 (EDT)
From: Dah Ming Chiu - Sun Microsystems <Dahming.Chiu@East.Sun.COM>
Reply-To: Dah Ming Chiu - Sun Microsystems <Dahming.Chiu@East.Sun.COM>
Subject: Re: Multicast and Unicast Flows Fairness
To: Fethi.Filali@sophia.inria.fr
Cc: rmt@lbl.gov
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: BQTohO3D4xFJPWemLKkXHQ==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc
Sender: owner-rmt@lbl.gov
Precedence: bulk
Hi Fethi,
This topic has been discussed by the IRTF Reliable Multicast working
group on numerous occasions. If you are interested in that, you might
go to their mail archive and search.
I wrote an article on this topic which you might find useful, see
http://www.sun.com/research/techrep/1999/abstract-80.html
It is a more "academic" perspective (in Jon's terminology). A slightly
updated version of it was published in the ISCC2000 proceedings.
Regards
Dah Ming Chiu
Sun Labs
X-Authentication-Warning: ra.inria.fr: Host localhost [127.0.0.1]
claimed to be sophia.inria.fr
From: Fethi Filali <Fethi.Filali@sophia.inria.fr>
X-Accept-Language: en
MIME-Version: 1.0
To: rmt@lbl.gov
Subject: Multicast and Unicast Flows Fairness
Content-Transfer-Encoding: 7bit
hi all,
My question is how the internet community define the fairness between
reliable multicast and TCP connections sharing the same communication
link.
Should a reliable multicast flows be treated as a TCP flow ? Or, should
the reliable multicast flows be given more bandwidth than TCP flow
because it is intended to serve more receivers? In the second case, how
much more bandwidth should be given to the multicast flow and how do the
Internet community define this fairness.
Thanks,
Fethi.
>From owner-rmt@listserv.lbl.gov Mon Oct 9 17:41:20 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id RAA15663;
Mon, 9 Oct 2000 17:39:40 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id RAA15659
for <rmt@listserv.lbl.gov>; Mon, 9 Oct 2000 17:39:38 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id RAA13730
for <rmt@listserv.lbl.gov>; Mon, 9 Oct 2000 17:39:37 -0700 (PDT)
Received: from mailman.sprintlabs.com (mx.sprintlabs.com [208.30.174.2])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id RAA13727
for <rmt@lbl.gov>; Mon, 9 Oct 2000 17:39:36 -0700 (PDT)
Received: from sprintlabs.com (ip199-2-53-112.sprintlabs.com [199.2.53.112]) by mailman.sprintlabs.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.78)
id 4GNA7TCP; Mon, 9 Oct 2000 17:38:55 -0700
Message-ID: <39E264B2.B6927993@sprintlabs.com>
Date: Mon, 09 Oct 2000 17:37:06 -0700
From: Christophe Diot <cdiot@sprintlabs.com>
Organization: SPRINT ATL
X-Mailer: Mozilla 4.61 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Cost264@lip6.fr, rm@mash.CS.Berkeley.EDU, end2end-interest@ISI.EDU,
tccc@ieee.org, itc@ieee.org, maddogs@ietf.org,
ssm-interest@external.cisco.com, rmt@lbl.gov
Subject: NGC 2000: register asap !
References: <39D11F0B.934908B9@sprintlabs.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-rmt@lbl.gov
Precedence: bulk
Registration deadline for early rates is tomorrow.
Also, we are going fast to the 100 participants.
so please register shortly. we will accept early rates
for another two days as some people experienced problems
to reach the web site today.
www.cs.ucsb.edu/ngc2000
>From owner-rmt@listserv.lbl.gov Wed Oct 18 03:36:06 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id DAA10888;
Wed, 18 Oct 2000 03:32:29 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id DAA10884
for <rmt@listserv.lbl.gov>; Wed, 18 Oct 2000 03:32:26 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id DAA20959
for <rmt@listserv.lbl.gov>; Wed, 18 Oct 2000 03:32:26 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id DAA20954
for <rmt@lbl.gov>; Wed, 18 Oct 2000 03:32:25 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14670;
Wed, 18 Oct 2000 06:32:24 -0400 (EDT)
Message-Id: <200010181032.GAA14670@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: rmt@lbl.gov
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-rmt-buildingblocks-03.txt
Date: Wed, 18 Oct 2000 06:32:24 -0400
Sender: owner-rmt@lbl.gov
Precedence: bulk
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Reliable Multicast Transport Working Group of the IETF.
Title : Reliable Multicast Transport Building Blocks for
One-to-Many Bulk-Data Transfer
Author(s) : B. Whetten, L. Vicisano, R. Kermode,
M. Handley, S. Floyd, M. Luby
Filename : draft-ietf-rmt-buildingblocks-03.txt
Pages : 22
Date : 17-Oct-00
This document describes a framework for the standardization of bulk-data
reliable multicast transport. It builds upon the experience gained
during the deployment of several classes of contemporary reliable
multicast transport, and attempts to pull out the commonalities between
these classes of protocols into a number of building blocks. To that
end, this document recommends that certain components that are common to
multiple protocol classes be standardized as 'building blocks.' The
remaining parts of the protocols, consisting of highly protocol
specific, tightly intertwined functions, shall be designated as
'protocol cores.' Thus, each protocol can then be constructed by
merging a 'protocol core' with a number of 'building blocks' which can
be re-used across multiple protocols.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rmt-buildingblocks-03.txt
Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-rmt-buildingblocks-03.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.
Send a message to:
mailserv@ietf.org.
In the body type:
"FILE /internet-drafts/draft-ietf-rmt-buildingblocks-03.txt".
NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv@ietf.org"
Content-Type: text/plain
Content-ID: <20001017125924.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-rmt-buildingblocks-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-rmt-buildingblocks-03.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <20001017125924.I-D@ietf.org>
--OtherAccess--
--NextPart--
>From owner-rmt@listserv.lbl.gov Mon Oct 23 14:30:16 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id OAA09629;
Mon, 23 Oct 2000 14:27:58 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id OAA09625
for <rmt@listserv.lbl.gov>; Mon, 23 Oct 2000 14:27:57 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id OAA23808
for <rmt@listserv.lbl.gov>; Mon, 23 Oct 2000 14:27:56 -0700 (PDT)
Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id OAA23788
for <rmt@lbl.gov>; Mon, 23 Oct 2000 14:27:54 -0700 (PDT)
Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id OAA26630 for <rmt@lbl.gov>; Mon, 23 Oct 2000 14:27:53 -0700 (MST)]
Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [217.1.10.38]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id OAA11047 for <rmt@lbl.gov>; Mon, 23 Oct 2000 14:25:50 -0700 (MST)]
Received: from arc.corp.mot.com ([217.2.31.39])
by homer.arc.corp.mot.com (8.10.2/8.10.2) with ESMTP id e9NLRTn15019
for <rmt@lbl.gov>; Tue, 24 Oct 2000 08:27:29 +1100 (EST)
Message-ID: <39F4ACDB.CD598D58@arc.corp.mot.com>
Date: Tue, 24 Oct 2000 08:25:47 +1100
From: Roger Kermode <rkermode@arc.corp.mot.com>
Reply-To: Roger.Kermode@motorola.com
Organization: Motorola
X-Mailer: Mozilla 4.73 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: rmt-list <rmt@lbl.gov>
Subject: Call for RMT Agenda items
Content-Type: multipart/mixed;
boundary="------------8C42FB7D460C9D6DD81796BA"
Sender: owner-rmt@lbl.gov
Precedence: bulk
This is a multi-part message in MIME format.
--------------8C42FB7D460C9D6DD81796BA
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Dear RMT'ers
Please send your requests for RMT agenda items for the next
IETF to me when you get the chance. If we get them early
enough we might even be able to publish an agenda prior
to the meeting (hint hint).
FYI...we've asked for two slots again, which will most likely
be scheduled early in the week.
cheers,
Roger
--------------8C42FB7D460C9D6DD81796BA
Content-Type: text/x-vcard; charset=us-ascii;
name="rkermode.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Roger Kermode
Content-Disposition: attachment;
filename="rkermode.vcf"
begin:vcard
n:Kermode;Roger
tel;cell:+61-408-212-284
tel;fax:+61-2-9666-0501
tel;home:+61-2-9664-8335
tel;work:+61-2-9666-0558
x-mozilla-html:FALSE
url:www.mot.com.au
org:Motorola Australian Research Centre;Communications and Networking Lab
version:2.1
email;internet:Roger.Kermode@motorola.com
title:Principal Research Engineer, Manager
adr;quoted-printable:;;Level 3,=0D=0A12 Lord St.;Botany;NSW;2019;Australia
fn:Roger Kermode
end:vcard
--------------8C42FB7D460C9D6DD81796BA--
>From owner-rmt@listserv.lbl.gov Fri Oct 27 09:20:33 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id JAA09486;
Fri, 27 Oct 2000 09:16:54 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from ertpg14e1.nortelnetworks.com (ertpg14e1.nortelnetworks.com [47.234.0.35])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id JAA09482
for <rmt@listserv.lbl.gov>; Fri, 27 Oct 2000 09:16:52 -0700 (PDT)
Received: from zbl6c016.corpeast.baynetworks.com (actually zbl6c016)
by ertpg14e1.nortelnetworks.com; Fri, 27 Oct 2000 11:54:23 -0400
Received: from zbl6c002.corpeast.baynetworks.com ([132.245.205.52])
by zbl6c016.corpeast.baynetworks.com
with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39)
id VT2NRBP8; Fri, 27 Oct 2000 11:54:17 -0400
Received: from hardjono.nortelnetworks.com (dhcp225-117.engeast.baynetworks.com [192.32.225.117])
by zbl6c002.corpeast.baynetworks.com
with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39)
id VDZZ10HG; Fri, 27 Oct 2000 11:54:16 -0400
Message-Id: <4.3.1.2.20001027111423.00d5cdb0@ZBL6C002.corpeast.baynetworks.com>
X-Sender: hardjono@ZBL6C002.corpeast.baynetworks.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Fri, 27 Oct 2000 12:04:32 -0700
To: smug@cs.umass.edu, smug@baynetworks.com
From: "Thomas Hardjono" <hardjono@nortelnetworks.com>
Subject: MSEC BOF details
Cc: rmt@listserv.lbl.gov
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-rmt@lbl.gov
Precedence: bulk
Folks,
There will be a BOF on Multicast SECurity (MSEC) in the next IETF San Diego.
Date: Tuesday Dec 12
Time: 1300-1400 (Afternoon Sessions I)
(break)
1545-1645 (Afternoon Sessions III)
http://www.ietf.org/meetings/agenda.html
The draft-agenda for the BOF is given below, and an msec mailing list is
being set-up.
Yours,
Thomas
------
---------------------------------------------------------------------------
Multicast Security BOF (msec)
Tuesday 12 Dec, 13:00pm
==============================
CHAIR: Ran Canetti <canetti@watson.ibm.com>
Thomas Hardjono <hardjono@nortelnetworks.com>
DESCRIPTION:
There is significant interest in the networking industry and content
delivery network industry to use IP multicast a vehicle for data
delivery to a large audience. One major hindrance to the successful
deployment of IP multicast and other group-oriented communication
protocols has been the lack of security for both the content and the
content-delivery infrastructure. In particular, there has been
increasing demand for secure solutions for the 1-to-Many type of
group communications, as exemplified by the interest of the cable
television sector in using the Internet for content distribution and
by the recent emergence of the single-source paradigm in IP
multicasting.
To this end, the Secure Multicast (SMuG) research group was formed in
1998 under the umbrella of the IRTF. That group has characterized the
security concerns and problem areas, has come up with a framework for
an overall solution, and has developed protocols for solving much of
the problem space in a satisfactory manner. Several of these protocols
have reached the needed maturity to be considered for standardization
at the IETF.
The proposed WG will further develop and standadize the protocols
developed at the SMuG RG. The focus will be on mature protocols that
are deployable in short term in today's internet. The SMuG RG will
continue to examine issues that need further research, delivering
protocols to McSEC when they are mature. In the immediate future
McSEC will focus on the 1-to-Many group communication, and will
address at least the following issues:
- Developing the transformations to be applied to the multicasted data.
These transformations will provide at least the following
functionalities:
+ Encryption of data using a group key available to all members.
+ Source and Data Authentications even when the data receivers
do not trust each other.
Both functionalities are required for content-authors and
content-distributors. They represent an important element in the
larger digital rights management area.
- Group Security Association and Key Management. Secure protocols are
needed for management of cryptographic keys and Security Associations
for groups. These include techniques for initial key dissemination,
key updates and refreshments, and Group Security Association (Group
SA) management.
Depending on the acceptance and stability of the above two issues, the
following issues will be addressed by the WG in the immediate future:
- Group Security Policies. Different levels of policies exist for a
group, covering a range from member behavior to cryptographic policies.
- Secure group announcements. Information regarding the existence of a
group, its policies, base security mechanisms and methods for joining
needs to be announced in a suitable manner.
Secure multicast touches upon the work of several other working groups.
The proposed WG will take care to coordinate its activities with the
relevant directorates (security, routing, transport) and especially
with the IPSec and RMT working groups.
The WG will not work on:
- Security issues at firewalls and NATs relating to multicast traffic.
- Protection against illegal re-distribution of multicasted data.
AGENDA:
10 mins - Agenda bashing
10 mins - Charter presentation
80 mins - Internet draft presentations:
10 mins - Taxonomy of multicast security concerns
(draft-irtf-smug-taxonomy-01.txt)
10 mins - Framework overview (draft-irtf-smug-framework-01.txt)
- Data transforms:
10 mins - Overall design (draft-irtf-smug-data-transforms-00.txt)
10 mins - Source authentication (draft-irtf-smug-tesla-00.txt)
- Group key and SA management
10 mins - GKM Building Block (draft-irtf-smug-gkmbb-gsadef-00.txt)
10 mins - GSAKMP (draft-harney-sparta-gsakmp-sec-01.txt)
10 mins - Group DOI for ISAKMP (draft-irtf-smug-gdoi-00.txt)
10 mins - Group policy management (draft-mcast-pol-req00.txt)
20 mins - Open Discussion (work descriptions, objectives, goals/milestones)
MAILING LIST
A mailing list is currently being set-up.
The website is www.securemulticast.org, which contains
the drafts (below) and other reading material.
READING MATERIAL
draft-irtf-smug-taxonomy-02.txt
draft-irtf-smug-framework-01.txt
draft-irtf-smug-data-transforms-01.txt
draft-irtf-smug-tesla-00.txt
draft-irtf-smug-gkmbb-gsadef-00.txt
draft-harney-sparta-gsakmp-sec-01.txt
draft-irtf-smug-gdoi-00.txt
draft-irtf-smug-pol-req00.txt
----------------------------------------------------------------------------
>From owner-rmt@listserv.lbl.gov Fri Oct 27 10:13:58 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id KAA09737;
Fri, 27 Oct 2000 10:13:44 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id KAA09733
for <rmt@listserv.lbl.gov>; Fri, 27 Oct 2000 10:13:42 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id KAA05139
for <rmt@listserv.lbl.gov>; Fri, 27 Oct 2000 10:13:42 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id KAA05135
for <rmt@lbl.gov>; Fri, 27 Oct 2000 10:13:41 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01955;
Fri, 27 Oct 2000 13:13:23 -0400 (EDT)
Message-Id: <200010271713.NAA01955@ietf.org>
To: IETF-Announce: ;
Cc: RFC Editor <rfc-editor@ISI.EDU>, IANA <iana@iana.org>
Cc: Internet Architecture Board <iab@ISI.EDU>
Cc: rmt@lbl.gov
From: The IESG <iesg-secretary@ietf.org>
Subject: Document Action: Reliable Multicast Transport Building Blocks
for One-to-Many Bulk-Data Transfer to Informational
Date: Fri, 27 Oct 2000 13:13:23 -0400
Sender: owner-rmt@lbl.gov
Precedence: bulk
The IESG has approved the Internet-Draft 'Reliable Multicast Transport
Building Blocks for One-to-Many Bulk-Data Transfer'
<draft-ietf-rmt-buildingblocks-03.txt> as a Informational RFC. This
document is the product of the Reliable Multicast Transport Working
Group. The IESG contact persons are Allison Mankin and Scott Bradner.
Note to RFC Editor:
Please Rename Section 5 to be Security Considerations.
>From owner-rmt@listserv.lbl.gov Mon Oct 30 10:57:54 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id KAA20840;
Mon, 30 Oct 2000 10:55:12 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id KAA20836
for <rmt@listserv.lbl.gov>; Mon, 30 Oct 2000 10:55:10 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id KAA11531
for <rmt@listserv.lbl.gov>; Mon, 30 Oct 2000 10:55:09 -0800 (PST)
Received: from mailman.sprintlabs.com (mx.sprintlabs.com [208.30.174.2])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id KAA11522
for <rmt@lbl.gov>; Mon, 30 Oct 2000 10:55:09 -0800 (PST)
Received: from sprintlabs.com (ip199-2-53-131.sprintlabs.com [199.2.53.131]) by mailman.sprintlabs.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.78)
id 47VNGG9L; Mon, 30 Oct 2000 10:54:56 -0800
Message-ID: <39FDC3E8.B2CF173@sprintlabs.com>
Date: Mon, 30 Oct 2000 10:54:32 -0800
From: Christophe Diot <cdiot@sprintlabs.com>
Organization: SPRINT ATL
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Cost264@lip6.fr, rm@mash.CS.Berkeley.EDU, end2end-interest@ISI.EDU,
tccc@ieee.org, itc@ieee.org, maddogs@ietf.org,
ssm-interest@external.cisco.com, rmt@lbl.gov,
fred bauer <fred@iprg.nokia.com>
Subject: NGC 2000: next week in stanford
References: <39D11F0B.934908B9@sprintlabs.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-rmt@lbl.gov
Precedence: bulk
NGC is coming soon and only 10 more people can register.
We remind you that there will be no on-site registration.
www.cs.ucsb.edu/ngc2000/
>From owner-rmt@listserv.lbl.gov Wed Nov 1 18:24:27 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id SAA08295;
Wed, 1 Nov 2000 18:20:41 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id SAA08291
for <rmt@listserv.lbl.gov>; Wed, 1 Nov 2000 18:20:39 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id SAA06064
for <rmt@listserv.lbl.gov>; Wed, 1 Nov 2000 18:20:38 -0800 (PST)
Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id SAA06055
for <rmt@lbl.gov>; Wed, 1 Nov 2000 18:20:38 -0800 (PST)
Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id TAA10763 for <rmt@lbl.gov>; Wed, 1 Nov 2000 19:20:37 -0700 (MST)]
Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [217.1.10.38]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id TAA18637 for <rmt@lbl.gov>; Wed, 1 Nov 2000 19:20:35 -0700 (MST)]
Received: from motorola.com (mccoy.arc.corp.mot.com [217.1.10.204])
by homer.arc.corp.mot.com (8.10.2/8.10.2) with ESMTP id eA22K1S16856
for <rmt@lbl.gov>; Thu, 2 Nov 2000 13:20:01 +1100 (EST)
Message-ID: <3A00CEE7.DB675A83@motorola.com>
Date: Thu, 02 Nov 2000 13:18:15 +1100
From: Roger Kermode <Roger.Kermode@motorola.com>
Reply-To: Roger.Kermode@motorola.com
Organization: Motorola
X-Mailer: Mozilla 4.73 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: rmt-list <rmt@lbl.gov>
Subject: Announcment: multicast security BOF at San Diego IETF
Content-Type: multipart/mixed;
boundary="------------608BAF969F4A519981D5B3B0"
Sender: owner-rmt@lbl.gov
Precedence: bulk
This is a multi-part message in MIME format.
--------------608BAF969F4A519981D5B3B0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Dear everyone,
the chairs of the IRTF Secure Multicast Research Group will
be holding a BoF on Secure Multicast at the next IETF.
Please take a moment to read the announcement below
if you're so interested,
cheers,
Roger
---------------------------------------------------------------------------
Multicast Security BOF (msec)
Tuesday, December 12 at 1415-1515
Tuesday, December 12 at 1700-1800
=================================
CHAIR: Ran Canetti <canetti@watson.ibm.com>
Thomas Hardjono <hardjono@nortelnetworks.com>
DESCRIPTION:
There is significant interest in the networking industry and content
delivery network industry to use IP multicast a vehicle for data
delivery to a large audience. One major hindrance to the successful
deployment of IP multicast and other group-oriented communication
protocols has been the lack of security for both the content and the
content-delivery infrastructure. In particular, there has been
increasing demand for secure solutions for the 1-to-Many type of
group communications, as exemplified by the interest of the cable
television sector in using the Internet for content distribution and
by the recent emergence of the single-source paradigm in IP
multicasting.
To this end, the Secure Multicast (SMuG) research group was formed in
1998 under the umbrella of the IRTF. That group has characterized the
security concerns and problem areas, has come up with a framework for
an overall solution, and has developed protocols for solving much of
the problem space in a satisfactory manner. Several of these protocols
have reached the needed maturity to be considered for standardization
at the IETF.
The proposed WG will further develop and standardize the protocols
developed at the SMuG RG. The focus will be on mature protocols that
are deployable in short term in today's internet. The SMuG RG will
continue to examine issues that need further research, delivering
protocols to MSEC when they are mature. In the immediate future
MSEC will focus on the 1-to-Many group communication, and will
address at least the following issues:
- Developing the transformations to be applied to the multicasted data.
These transformations will provide at least the following
functionalities:
+ Encryption of data using a group key available to all members.
+ Source and Data Authentications even when the data receivers
do not trust each other.
Both functionalities are required for content-authors and
content-distributors. They represent an important element in the
larger digital rights management area.
- Group Security Association and Key Management. Secure protocols are
needed for management of cryptographic keys and Security Associations
for groups. These include techniques for initial key dissemination,
key updates and refreshments, and Group Security Association (Group
SA) management.
Depending on the acceptance and stability of the above two issues, the
following issues will be addressed by the WG in the immediate future:
- Group Security Policies. Different levels of policies exist for a
group, covering a range from member behavior to cryptographic
policies.
- Secure group announcements. Information regarding the existence of a
group, its policies, base security mechanisms and methods for joining
needs to be announced in a suitable manner.
Secure multicast touches upon the work of several other working groups.
The proposed WG will take care to coordinate its activities with the
relevant directorates (security, routing, transport) and especially
with the IPSec and RMT working groups.
The WG will not work on:
- Security issues at firewalls and NATs relating to multicast traffic.
- Protection against illegal re-distribution of multicasted data.
AGENDA:
10 mins - Agenda bashing
10 mins - Charter presentation
80 mins - Internet draft presentations:
10 mins - Taxonomy of multicast security concerns
(draft-irtf-smug-taxonomy-01.txt)
10 mins - Framework overview (draft-irtf-smug-framework-01.txt)
- Data transforms:
10 mins - Overall design (draft-irtf-smug-data-transforms-00.txt)
10 mins - Source authentication (draft-irtf-smug-tesla-00.txt)
- Group key and SA management
10 mins - GKM Building Block
(draft-irtf-smug-gkmbb-gsadef-00.txt)
10 mins - GSAKMP (draft-harney-sparta-gsakmp-sec-02.txt)
10 mins - Group DOI for ISAKMP (draft-irtf-smug-gdoi-00.txt)
10 mins - Group policy management (draft-mcast-pol-req00.txt)
20 mins - Open Discussion (work descriptions, objectives,
goals/milestones)
MAILING LIST
The mailing list is at msec-request@securemulticast.org (or email the
chairs).
The website is at www.securemulticast.org
READING MATERIAL
draft-irtf-smug-taxonomy-02.txt
draft-irtf-smug-framework-01.txt
draft-irtf-smug-data-transforms-01.txt
draft-irtf-smug-tesla-00.txt
draft-irtf-smug-gkmbb-gsadef-00.txt
draft-harney-sparta-gsakmp-sec-02.txt
draft-irtf-smug-gdoi-00.txt
draft-irtf-smug-pol-req00.txt
---------------------------------------------------------------------------
--------------608BAF969F4A519981D5B3B0
Content-Type: text/x-vcard; charset=us-ascii;
name="Roger.Kermode.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Roger Kermode
Content-Disposition: attachment;
filename="Roger.Kermode.vcf"
begin:vcard
n:Kermode;Roger
tel;cell:+61-408-212-284
tel;fax:+61-2-9666-0501
tel;home:+61-2-9664-8335
tel;work:+61-2-9666-0558
x-mozilla-html:FALSE
url:www.mot.com.au
org:Motorola Australian Research Centre;Communications and Networking Lab
version:2.1
email;internet:Roger.Kermode@motorola.com
title:Principal Research Engineer, Manager
adr;quoted-printable:;;Level 3,=0D=0A12 Lord St.;Botany;NSW;2019;Australia
fn:Roger Kermode
end:vcard
--------------608BAF969F4A519981D5B3B0--
>From owner-rmt@listserv.lbl.gov Fri Nov 3 16:00:21 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id PAA25494;
Fri, 3 Nov 2000 15:57:44 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id PAA25490
for <rmt@listserv.lbl.gov>; Fri, 3 Nov 2000 15:57:42 -0800 (PST)
From: hv@of-hachetal.de
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id PAA05337
for <rmt@listserv.lbl.gov>; Fri, 3 Nov 2000 15:57:41 -0800 (PST)
Received: from mail.sinet.net.cn ([202.103.190.4])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id PAA05296
for <rmt@lbl.gov>; Fri, 3 Nov 2000 15:57:34 -0800 (PST)
Received: from isd.com.cn ([202.103.148.117])
by mail.sinet.net.cn (8.9.3/8.9.3) with SMTP id HAA12727;
Sat, 4 Nov 2000 07:53:34 +0800 (CST)
Date: Sat, 4 Nov 2000 07:53:34 +0800 (CST)
Message-Id: <200011032353.HAA12727@mail.sinet.net.cn>
Received: from h809 ([63.30.197.239]) by isd.com.cn (Lotus SMTP MTA v4.6.1 (569.2 2-6-1998)) with SMTP id 4825698C.0082E7B4; Wed, 4 Nov 1970 07:51:14 +0800
To: hv@of-hachetal.de
Subject: At last, Herbal V, the all natural alternative to V----A!
Sender: owner-rmt@lbl.gov
Precedence: bulk
Herbal V: An Incredible All-Natural Healthy Alternative
Herbal V is the All Natural Approach to Male Virility,
Vitality and Pleasure.
Available N o w !
Welcome to the New Sexual Revolution.
It's the all natural male potency and pleasure pill that men
everywhere are buzzing about. Herbal V is safe, natural and
specifically formulated to help support male sexual function
and pleasure. You just take two easy-to-swallow tablets
one hour before sex. And there's more great news - you can
get Herbal V for less than $1 a pill.
Amazing word of mouth praise on Herbal V has been spreading
like wildfire-already over 1,500,000 men have chosen
Herbal V. Since it is 100% natural you will never have
to worry about safety. Try doctor-recommended Herbal V
today and have the greatest night of your life!
Herbal V... Bringing Back the Magic!
1,585,000 men can't be wrong. To date over 1 million men
have tried the super supplement Herbal V.
Here is why:
No Doctor Visit Required
Available Over the Counter
Not a Drug
100% Natural
Safe, No Worries
Highest Quality Pharmaceutical-Grade Pure Nutriceuticals
Guaranteed Potency & Purity
Be a Real Man Again!
Questions and Answers
What is Herbal V?
Herbal V is a proprietary blend that was specifically
developed as a safe alternative for men who prefer
an all-natural approach to address impotence and boost
sexual performance. This amazing formula first became
popular with Hollywood insiders and the wealthy elite.
They were maximizing their sex lives, long before it
was available to the general public.
How does Herbal V work?
Developed by a team whose goal was to create the perfect
all-natural aphrodisiac. Herbal V is the result of that
remarkable effort. The Herbal V formula contains a precise
blend of cutting edge pro-sexual nutrients from around
the world that provide nutritional support, making it
possible for a man to have a pleasurable sexual experience.
What can Herbal V do for me?
Herbal V helps support male sexual function and
pleasure in a safe and natural manner. Simply put,
it can make your sex life incredible.
Is Herbal V Safe?
One of the great things about Herbal V is that it is
not a drug. It is an incredible herbal dietary supplement
that provides nutritional support for male sexual function
and pleasure. One of the most comforting features of
Herbal V is that you never have to worry about safety.
Herbal V: Safe - Natural - Exciting
Many have speculated that because Herbal V is so
popular with men, it must contain prescription drugs
or chemical components. Herbal V does not contain any
elements or traces of any prescription drug. Herbal V
is made using the world's most technologically advanced
state-of-the-art cold processing equipment to ensure
maximum purity. Herbal V has been independently analyzed
by the nation's premier testing facility to ensure purity,
quality and to end the rumors that, because it is so
popular, it must somehow be chemical. It is not.
Herbal V is natural - just as it says on the label.
Herbal V is simply fantastic!
Herbal V: Ingredients
Yohimbe, saw palmetto, avena sativa, androstenedione,
guarana, taurine, siberian ginseng, tribulus terrestris.
Tribulus Terrestis is certified to enhanced testosterone
levels by increasing Luteinzing hormone (LH) levels.
Androstenedione which is a precursor to testosterone
unlocks bound testosterone and makes it biologically
active again quickly. This means a dramatic surge in
desire. Avena Sativa Stimulates the neurotransmitter
pleasure centers to maximum capacity. This greatly
intensifies pleasure.
Just listen to what Herbal V has done for the sex lives
of people like you!
^ÓOn a scale of 1 to 10, it's a 15. Electrifying. It's like
a wonder pill!^Ô
^× Justin Q B., New Haven, Texas
^ÓI haven't had sexual relations in 11 years. Then with
Herbal V it was... wow! It works again!^Ô
^× Sid R., Lakeland, Florida
^ÓI had sex four times in one night. It made me feel
like a 19-year-old again.^Ô
^× Chip S, Beech Mountain, North Carolina
^ÓHerbal V has turned my husband into a Sexual Superman!
I like the fact that it's all natural and has no
side effects. It's bringing back the good old days.^Ô
^× Jennifer B, Beverly Hills, California
The above testimonials are from product literature,
and we have not independently verified them.
However, the following testimonial is from a "senior"
gentleman who has purchased his second bottle of
Herbal V. When we heard his words with our own ears,
we asked his permission to print them here.
^ÓMan! I'm wild as I can be! I feel like I'm 25 years old again!
I'm not believing this!^Ô
^× Mr. Murphy, age 64, Lampart, IL.
Risk Free: Double Your Money Back Guarantee
If Herbal V does not give the desired results as stated
above, simply return the unused portion for a
double-your money back refund. No questions asked !
Order Now: Safe, Fast, Secure, Private
Herbal V with its DOUBLE YOUR MONEY BACK GUARANTEE is
available only through this special promotional offer.
Herbal V arrives in plain packaging for your privacy.
Any and all information is kept strictly confidential.
Payment Methods
You may FAX or Postal Mail Checks, MasterCard, Visa,
& American Express.payments. Money Orders
are accepted only by Postal Mail.
Each bottle of Herbal V contains 30 tablets, approximately
a 1 month supply.
Step 1: Place a check by your desired quanity.
______ 1 Bottle of Herbal V $28
______ 2 Bottles of Herbal V $48
______ 3 Bottles of Herbal V $59
Please add $6 shipping and handling for any size order.
[ Total cost including shipping & handling,
1 bottle=$34, 2 bottles=$54, 3 bottles=$65 ]
International Orders
Please add $16 shipping and handling for any size order.
[ Total cost including shipping & handling,
1 bottle=$44, 2 bottles=$64, 3 bottles=$75 ]
We cannot accept foreign checks.
International money orders or credit cards only.
Step 2: Place a check by your desired payment method
and complete fields if necessary.
_____Check or CHECK-BY-FAX [details below]
_____Money Order
_____American Express
Account Number__________________ Exp____/____
_____Visa
Account Number__________________ Exp____/____
_____MasterCard
Account Number__________________ Exp____/____
Please make your check or money order payable to
"Lion Sciences National".
Step 3: Please complete and print the following fields clearly.
Name ___________________________________________________
Address _________________________________________________
City ____________________________________________________
State ___________________________________________________
Zip _____________________________________________________
E-mail __________________________________________________
Signature _________________________________________________
[ required for check and credit card orders]
Toll Free FAX Order Line: 1-800-940-6590
If faxing in your order, please state whether you require
a fax, email, or no confirmation at all.
Allow up to one day for confirmation, if requested.
FAX orders are processed immediately.
Or, print & mail to: LSN
3502 N. Powerline Rd. #525
Pompano Beach, FL 33069
______________________________________________________
*CHECK BY FAX ORDERS: Complete the check as normal. Tape
the check in the area below. Below the check, clearly write
the check number, all numbers at the bottom of the check,
& your name. Tape the check below and fax the check to the
toll free FAX number above. Void the check. Our merchant
will electronically debit your account for the amount of
the check; your reference number for this transaction will
be your check number. Nothing could be safer & easier !
TAPE CHECK BELOW
_____________________________________________________________
This is a one time mailing: Removal is automatic and no further
contact is necessary. Please Note: Herbal V is not intended to
diagnose, treat, cure or prevent any disease. As individuals differ,
so will results. Herbal V helps provide herbal and nutritional support
for male sexual performance. The FDA has not evaluated these
statements. For details about our double your money back guarantee,
please write to the above address, attention consumer affairs
department; enclose a self addressed stamped envelope for this and any
requested contact information.
Thank You.
>From owner-rmt@listserv.lbl.gov Wed Nov 8 15:41:43 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id PAA18292;
Wed, 8 Nov 2000 15:36:47 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id PAA18288
for <rmt@listserv.lbl.gov>; Wed, 8 Nov 2000 15:36:45 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id PAA28441
for <rmt@listserv.lbl.gov>; Wed, 8 Nov 2000 15:36:44 -0800 (PST)
Received: from mailman.sprintlabs.com (mx.sprintlabs.com [208.30.174.2])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id PAA28435
for <rmt@lbl.gov>; Wed, 8 Nov 2000 15:36:43 -0800 (PST)
Received: by mailman.sprintlabs.com with Internet Mail Service (5.5.2652.78)
id <47VNGVPH>; Wed, 8 Nov 2000 15:36:40 -0800
Message-ID: <90B65CE19D3DD411895400805F0DAA7A0BDFF7@mailman.sprintlabs.com>
From: Christophe Diot <cdiot@sprintlabs.com>
To: NGC2000-PC <ngc2000-pc@sprintlabs.com>,
"'Cost264@lip6.fr'"
<Cost264@lip6.fr>,
"'rm@mash.CS.Berkeley.EDU'" <rm@mash.CS.Berkeley.EDU>,
"'maddogs@ietf.org'" <maddogs@ietf.org>,
"'ssm-interest@external.cisco.com'" <ssm-interest@external.cisco.com>,
"'rmt@lbl.gov'" <rmt@lbl.gov>
Subject: NGC 2000 retransmission on SSM
Date: Wed, 8 Nov 2000 15:36:38 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain
Sender: owner-rmt@lbl.gov
Precedence: bulk
8, November, 2000
Thanks to Sprint, Cisco, the University of Oregon, UC-Santa Barbara, and
Stanford University, NGC2000, the Second International Workshop on
Networked Group Communication is being multicast live from the Stanford
University Campus Nov. 8-10. The conference s being transmitted in
real-time via Source Specific Multicast. Sessions are only available by
SSM. For information on joining, see the University of Oregon Videolab
session page at: http://videolab.uoregon.edu/cgi-bin/urd.cgi to join.
This is the first event to be retransmitted over SSM.
The conference is being held at Stanford University in Palo Alto,
California from November 8th to the 10th and the program can be found
at: http://www.cs.ucsb.edu/ngc2000/program/
The aim of the Workshop is to allow researchers and practitioners to
present the design and implementation techniques for networked group
communication. The focus of the Workshop is strictly on multicast and
networked group communication. This Workshop is the second and only
international event in this area (first workshop was in Pisa, Italy, in
November 1999).
>From owner-rmt@listserv.lbl.gov Sun Nov 12 08:03:33 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id HAA00959;
Sun, 12 Nov 2000 07:59:51 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id HAA00955
for <rmt@listserv.lbl.gov>; Sun, 12 Nov 2000 07:59:49 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id HAA04060
for <rmt@listserv.lbl.gov>; Sun, 12 Nov 2000 07:59:48 -0800 (PST)
Received: from davis.bandwiz.com ([212.150.220.34])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id HAA04057
for <rmt@lbl.gov>; Sun, 12 Nov 2000 07:59:46 -0800 (PST)
Received: by davis.bandwiz.com with Internet Mail Service (5.5.2650.21)
id <VTNHY8B6>; Sun, 12 Nov 2000 17:59:10 +0200
Message-ID: <E9DC428883F3D31180F900E081107FF204F1DF@davis.bandwiz.com>
From: Meir Feder <Meir@bandwiz.com>
To: "'rmt@lbl.gov'" <rmt@lbl.gov>,
"'luby@digitalfountain.com'"
<luby@digitalfountain.com>
Cc: Doron Rajwan <Doron@bandwiz.com>, Nadav Shulman <Nadav@bandwiz.com>
Subject: Separating the MRCC from the ALC/FEC
Date: Sun, 12 Nov 2000 17:59:05 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
charset="iso-8859-1"
Sender: owner-rmt@lbl.gov
Precedence: bulk
Dear RMT-er's,
In response to the standardization effort of the RMT working group in the
drafts ALC-01 and MRCC-00, we feel that the ALC draft combines together the
FEC and the congestion control somewhat unnecessarily. Thus, we like to
suggest that the draft will maintain a clear separation of the functionality
between the MRCC and the ALC/FEC part.
We believe that the MRCC will prove itself as a working protocol for
multicast congestion control, that is important for interoperability and for
friendly network behavior. The FEC is the data (maybe the most natural data)
that is transferred via the MRCC transport. Thus, MRCC should essentially be
(and is) for the Transport layer (layer 4), while ALC/FEC should be for the
Application layer (layer 7).
The separation will give the following benefits:
1. MRCC will be able to deliver not only FEC packets but also, e.g., RTP
packets (for continuous real-time viewing). When the payload is ALC/FEC
packets, registering to more MRCC layers will provide a faster download.
When using RTP packets, it can provide higher quality streams, by using
successive refinement payload.
2. Since MRCC and ALC/FEC (implementing different communication layers) will
each have its own header, version number, header size field, extension
fields, and so on, modifications in one should not affect the other.
3. The long-term goal should be the implementation of MRCC at the kernel
level, like TCP today, in order to give true inter-operability, congestion
control, fairness, safety, robustness and so on. Applications will create
MRCC socket, possibly giving only (S,G), and start receiving packets at
varying rates. If MRCC is not implemented at the kernel, there is a danger
that we will see more aggressive MRCC implementations over time.
4. ALC/FEC packets should carry only application-related information, not
transport. Note that, then, the source of ALC/FEC packets can be payload of
MRCC protocol, disk files, caches, broadcast channels (when there is no need
for MRCC...) or any other source.
The separation is clear and simple. The header part of the ALC associated
with congestion control will be in the MRCC, while the ALC/FEC header will
have the code information. In general, in order to know if some information
should be in the header field of MRCC or ALC/FEC, one should ask the
following question: If a packet is cached to the disk, and re-transmitted
later, should it have the original value (ALC/FEC) or a new value (MRCC).
Thus, for example, the time extension mechanism should migrate to MRCC.
Meir Feder and Doron Rajwan
Bandwiz
>From owner-rmt@listserv.lbl.gov Sun Nov 12 11:03:55 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id LAA01115;
Sun, 12 Nov 2000 11:02:05 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id LAA01111
for <rmt@listserv.lbl.gov>; Sun, 12 Nov 2000 11:02:03 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id LAA12365
for <rmt@listserv.lbl.gov>; Sun, 12 Nov 2000 11:02:02 -0800 (PST)
Received: from info.iet.unipi.it (info.iet.unipi.it [131.114.9.184])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id LAA12362
for <rmt@lbl.gov>; Sun, 12 Nov 2000 11:02:00 -0800 (PST)
Received: (from luigi@localhost)
by info.iet.unipi.it (8.9.3/8.9.3) id UAA06380;
Sun, 12 Nov 2000 20:00:18 +0100 (CET)
(envelope-from luigi)
From: Luigi Rizzo <luigi@info.iet.unipi.it>
Message-Id: <200011121900.UAA06380@info.iet.unipi.it>
Subject: Re: Separating the MRCC from the ALC/FEC
In-Reply-To: <E9DC428883F3D31180F900E081107FF204F1DF@davis.bandwiz.com> from
Meir Feder at "Nov 12, 2000 05:59:05 pm"
To: Meir Feder <Meir@bandwiz.com>
Date: Sun, 12 Nov 2000 20:00:18 +0100 (CET)
CC: "'rmt@lbl.gov'" <rmt@lbl.gov>,
"'luby@digitalfountain.com'" <luby@digitalfountain.com>,
Doron Rajwan <Doron@bandwiz.com>, Nadav Shulman <Nadav@bandwiz.com>
X-Mailer: ELM [version 2.4ME+ PL61 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-rmt@lbl.gov
Precedence: bulk
Hi,
...
> drafts ALC-01 and MRCC-00, we feel that the ALC draft combines together the
> FEC and the congestion control somewhat unnecessarily. Thus, we like to
point well taken and in fact we are working on a revised version of
ALC draft mostly along the lines you suggest.
<PERSONAL OPINIONS FOLLOW>
In ALC-01 the MRCC info is already well separated from the ALC
header (the header field is opaque); it is true that ALC-01
still has some FEC-related header fields which do not belong there,
and we are revising the draft and move this info to the payload.
> 2. Since MRCC and ALC/FEC (implementing different communication layers) will
> each have its own header, version number, header size field, extension
> fields, and so on, modifications in one should not affect the other.
I am not too happy in using two different headers for MRCC (or whatever
cong. control protocol is going to be used) and ALC, as you seem to
suggest, as some form of cong.control is an integral part of ALC.
> 3. The long-term goal should be the implementation of MRCC at the kernel
> level, like TCP today, in order to give true inter-operability, congestion
...
> varying rates. If MRCC is not implemented at the kernel, there is a danger
> that we will see more aggressive MRCC implementations over time.
having a protocol implemented in kernel or user space is irrelevant for
most aspects, except perhaps overhead at source/receiver (which i
do not think is a concern here) and ease of deployment (and this is
a double-edged sword).
We can have bad (more aggressive, or buggy, or just initial) kernel
implementations of MRCC and be stuck with them for a long time
because people do not upgrade the OS (there are still IGMPv1 hosta
around). Or we can have good user-space implementations of MRCC
and stand the risk of people using "accelerators" which are more
aggressive than they should (same as it happens with TCP and various
companies offering modified stacks).
> The separation is clear and simple. The header part of the ALC associated
> with congestion control will be in the MRCC, while the ALC/FEC header will
> have the code information. In general, in order to know if some information
> should be in the header field of MRCC or ALC/FEC, one should ask the
> following question: If a packet is cached to the disk, and re-transmitted
> later, should it have the original value (ALC/FEC) or a new value (MRCC).
> Thus, for example, the time extension mechanism should migrate to MRCC.
I partly disagree with the example. CC controls the throughput ("slower",
"faster"), whereas the time extension mechanism operates at a higher
level ("I am not done yet"). It certainly does not belong to MRCC e.g. for
streaming video you do not need it ("sorry, the show is over!").
You might argue that it does not even belong to ALC/FEC, but the
thing is you have to info somewhere.
cheers
luigi rizzo
----------------------------------+-----------------------------------------
Luigi RIZZO, luigi@iet.unipi.it . ACIRI/ICSI (on leave from Univ. di Pisa)
http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704
Phone (510) 666 2927 .
----------------------------------+-----------------------------------------
>From owner-rmt@listserv.lbl.gov Fri Nov 17 00:41:12 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id AAA23006;
Fri, 17 Nov 2000 00:38:59 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id AAA23002
for <rmt@listserv.lbl.gov>; Fri, 17 Nov 2000 00:38:57 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id AAA01981
for <rmt@listserv.lbl.gov>; Fri, 17 Nov 2000 00:38:57 -0800 (PST)
Received: from acm.cs.umn.edu (acm.cs.umn.edu [128.101.32.12])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id AAA01976
for <rmt@lbl.gov>; Fri, 17 Nov 2000 00:38:56 -0800 (PST)
Received: from monopoly.cs.umn.edu (monopoly.cs.umn.edu [128.101.32.5])
by acm.cs.umn.edu (8.11.1/8.11.0) with ESMTP id eAH8e6q09362
for <rmt@lbl.gov>; Fri, 17 Nov 2000 02:40:06 -0600 (CST)
(envelope-from orasis@acm.cs.umn.edu)
Received: (from orasis@localhost)
by monopoly.cs.umn.edu (8.8.8/8.8.8) id CAA25368
for rmt@lbl.gov; Fri, 17 Nov 2000 02:36:38 -0800 (PST)
Date: Fri, 17 Nov 2000 02:36:38 -0800 (PST)
Message-Id: <200011171036.CAA25368@monopoly.cs.umn.edu>
From: Justin Chapweske <orasis@acm.org>
To: rmt@lbl.gov
Subject: Java FEC Library & Java ALC
Sender: owner-rmt@lbl.gov
Precedence: bulk
Hello all, we have just released a Java library for FEC encoding,
decoding, and IO at http://www.sourceforge.net/projects/swarmcast/. We
are committed to having the best Java FEC library out there, so we will be
constantly making minor improvements to this core package and would
greatly appreciate any feedback.
Next we will be doing an ALC/RLC implementation that will be
released under the LGPL. We have not yet started on this and love to
collaborate with anyone else that has started or interested in such an
undertaking.
Release Notes for Java FEC v0.5
This software is a library for performing Forward Error Correction
(FEC) encoding, decoding, and IO in Java.
1 Features
1. A SPI plugin architecture that allows any FEC code that has no inherent
reception innefficiency to be plugged in. Preferences between different
implementations can be expressed via a simple configuration file.
2. A pure Java port of Luigi Rizzo's wonderful C FEC package. The code
for this port is quite solid and provides an acceptible 33/k MB/s
performance on a 500mhz k6-2 for 8 bit codes. This is 4-5 times
faster than the port done by Dan Rubenstein's group, which is to
be expected as they were more focused on adding interesting
encoding/decoding features than speed.
3. A much improved version of Lorenzo Vicisano's JNI wrapper. The JNI
calls now have a negligable overhead for a delightful 160/k MB/s
on a 900mhz Athlon. If a native library for your platform is not
available then it will fall back to the pure Java version.
4. A FEC I/O package that is optimized for decoding speed and low memory
consumption.
5. For the license I've simply included Luigi's original copyright,
so you can basically do whatever you want with this thing. But if
you do use this thing, please let me know what I can do to make
it better for you.
2 Future Work/Open Tasks
1. Implement different IO routines based on Jim Gemmel's very nicely
written paper on FEC performance tuning.
2. Implement more codes (Please let me know if you know of any codes
as I'll implement them myself if they are compelling enough)
3. Tune the 16 bit codes to create the minimum required matrices on
demand, this will allow n values of up to 65536 to be feasible.
4. The shuffling proceedure causes some confusing behavior for decoding,
this will be fixed asap.
5. Have the native implementation automatically deploy itself so that
the user does not have to manually set up their library path.
-Justin
>From owner-rmt@listserv.lbl.gov Fri Nov 24 15:14:44 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id PAA23243;
Fri, 24 Nov 2000 15:12:46 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id PAA23236
for <rmt@listserv.lbl.gov>; Fri, 24 Nov 2000 15:12:43 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id PAA15589
for <rmt@listserv.lbl.gov>; Fri, 24 Nov 2000 15:12:43 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id PAA15583
for <rmt@lbl.gov>; Fri, 24 Nov 2000 15:12:42 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21886;
Fri, 24 Nov 2000 18:12:17 -0500 (EST)
Message-Id: <200011242312.SAA21886@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: rmt@lbl.gov
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-rmt-bb-fec-02.txt
Date: Fri, 24 Nov 2000 18:12:17 -0500
Sender: owner-rmt@lbl.gov
Precedence: bulk
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Reliable Multicast Transport Working Group of the IETF.
Title : RMT BB Forward Error Correction Codes
Author(s) : M. Luby et al.
Filename : draft-ietf-rmt-bb-fec-02.txt
Pages : 12
Date : 22-Nov-00
This memo describes the abstract packet formats and IANA
registration procedures for use of Forward Error Correction
(FEC) codes within the context of reliable IP multicast
transport. This memo should be read in conjunction with and
uses the terminology of the companion memo [1], which
describes the use of Forward Error Correction (FEC) codes
within the context of reliable IP multicast transport and
provides an introduction to some commonly used FEC codes.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rmt-bb-fec-02.txt
Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-rmt-bb-fec-02.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.
Send a message to:
mailserv@ietf.org.
In the body type:
"FILE /internet-drafts/draft-ietf-rmt-bb-fec-02.txt".
NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv@ietf.org"
Content-Type: text/plain
Content-ID: <20001122150120.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-rmt-bb-fec-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-rmt-bb-fec-02.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <20001122150120.I-D@ietf.org>
--OtherAccess--
--NextPart--
>From owner-rmt@listserv.lbl.gov Fri Nov 24 15:14:44 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id PAA23244;
Fri, 24 Nov 2000 15:12:46 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id PAA23234
for <rmt@listserv.lbl.gov>; Fri, 24 Nov 2000 15:12:43 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id PAA15588
for <rmt@listserv.lbl.gov>; Fri, 24 Nov 2000 15:12:43 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id PAA15582
for <rmt@lbl.gov>; Fri, 24 Nov 2000 15:12:42 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21861;
Fri, 24 Nov 2000 18:12:14 -0500 (EST)
Message-Id: <200011242312.SAA21861@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: rmt@lbl.gov
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-rmt-bb-lct-00.txt
Date: Fri, 24 Nov 2000 18:12:13 -0500
Sender: owner-rmt@lbl.gov
Precedence: bulk
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Reliable Multicast Transport Working Group of the IETF.
Title : Layered Coding Transport: A massively scalable
multicast protocol
Author(s) : M. Luby et al.
Filename : draft-ietf-rmt-bb-lct-00.txt
Pages : 28
Date : 22-Nov-00
This document describes Layered Coding Transport, a massively
scalable multicast protocol, hereafter referred to as LCT.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rmt-bb-lct-00.txt
Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-rmt-bb-lct-00.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.
Send a message to:
mailserv@ietf.org.
In the body type:
"FILE /internet-drafts/draft-ietf-rmt-bb-lct-00.txt".
NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv@ietf.org"
Content-Type: text/plain
Content-ID: <20001122150111.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-rmt-bb-lct-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-rmt-bb-lct-00.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <20001122150111.I-D@ietf.org>
--OtherAccess--
--NextPart--
>From owner-rmt@listserv.lbl.gov Fri Nov 24 15:28:17 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id PAA23282;
Fri, 24 Nov 2000 15:28:09 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id PAA23278
for <rmt@listserv.lbl.gov>; Fri, 24 Nov 2000 15:28:07 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id PAA16822
for <rmt@listserv.lbl.gov>; Fri, 24 Nov 2000 15:28:06 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id PAA16819
for <rmt@lbl.gov>; Fri, 24 Nov 2000 15:28:06 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26342;
Fri, 24 Nov 2000 18:28:03 -0500 (EST)
Message-Id: <200011242328.SAA26342@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: rmt@lbl.gov
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-rmt-bb-lcc-00.txt
Date: Fri, 24 Nov 2000 18:28:02 -0500
Sender: owner-rmt@lbl.gov
Precedence: bulk
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Reliable Multicast Transport Working Group of the IETF.
Title : Reliable Multicast Transport Building Block: Layered
Congestion Control
Author(s) : M. Luby et al.
Filename : draft-ietf-rmt-bb-lcc-00.txt
Pages : 20
Date : 22-Nov-00
This document describes LCC, a scalable layered congestion control
building block for multicast. LCC is a combination of approaches that
allow multiple receivers to concurrently receive packets from a single
sender at varying rates depending on individual bandwidth connections
and network conditions. Two basic goals of the approach are to allow
each receiver to obtain the full benefit of the available bandwidth to
the sender and to be fair to other flows in the network.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rmt-bb-lcc-00.txt
Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-rmt-bb-lcc-00.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.
Send a message to:
mailserv@ietf.org.
In the body type:
"FILE /internet-drafts/draft-ietf-rmt-bb-lcc-00.txt".
NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv@ietf.org"
Content-Type: text/plain
Content-ID: <20001122150129.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-rmt-bb-lcc-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-rmt-bb-lcc-00.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <20001122150129.I-D@ietf.org>
--OtherAccess--
--NextPart--
>From owner-rmt@listserv.lbl.gov Fri Nov 24 15:28:19 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id PAA23288;
Fri, 24 Nov 2000 15:28:12 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id PAA23284
for <rmt@listserv.lbl.gov>; Fri, 24 Nov 2000 15:28:10 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id PAA16829
for <rmt@listserv.lbl.gov>; Fri, 24 Nov 2000 15:28:10 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id PAA16826
for <rmt@lbl.gov>; Fri, 24 Nov 2000 15:28:09 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26352;
Fri, 24 Nov 2000 18:28:06 -0500 (EST)
Message-Id: <200011242328.SAA26352@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: rmt@lbl.gov
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-rmt-info-fec-00.txt
Date: Fri, 24 Nov 2000 18:28:06 -0500
Sender: owner-rmt@lbl.gov
Precedence: bulk
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Reliable Multicast Transport Working Group of the IETF.
Title : The use of Forward Error Correction in Reliable
Multicast
Author(s) : M. Luby et al.
Filename : draft-ietf-rmt-info-fec-00.txt
Pages : 18
Date : 22-Nov-00
This memo describes the use of Forward Error Correction (FEC)
codes within the context of reliable IP multicast transport
and provides an introduction to some commonly-used FEC codes.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rmt-info-fec-00.txt
Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-rmt-info-fec-00.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.
Send a message to:
mailserv@ietf.org.
In the body type:
"FILE /internet-drafts/draft-ietf-rmt-info-fec-00.txt".
NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv@ietf.org"
Content-Type: text/plain
Content-ID: <20001122150137.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-rmt-info-fec-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-rmt-info-fec-00.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <20001122150137.I-D@ietf.org>
--OtherAccess--
--NextPart--
>From owner-rmt@listserv.lbl.gov Mon Nov 27 20:26:11 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id UAA05463;
Mon, 27 Nov 2000 20:23:56 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id UAA05459
for <rmt@listserv.lbl.gov>; Mon, 27 Nov 2000 20:23:54 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id UAA29593
for <rmt@listserv.lbl.gov>; Mon, 27 Nov 2000 20:23:53 -0800 (PST)
Received: from acm.cs.umn.edu (acm.cs.umn.edu [128.101.32.12])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id UAA29590
for <rmt@lbl.gov>; Mon, 27 Nov 2000 20:23:52 -0800 (PST)
Received: from monopoly.cs.umn.edu (monopoly.cs.umn.edu [128.101.32.5])
by acm.cs.umn.edu (8.11.1/8.11.0) with ESMTP id eAS4OUq59925
for <rmt@lbl.gov>; Mon, 27 Nov 2000 22:24:30 -0600 (CST)
(envelope-from orasis@acm.cs.umn.edu)
Received: (from orasis@localhost)
by monopoly.cs.umn.edu (8.8.8/8.8.8) id WAA21496
for rmt@lbl.gov; Mon, 27 Nov 2000 22:21:21 -0800 (PST)
Date: Mon, 27 Nov 2000 22:21:21 -0800
From: Justin Chapweske <orasis@acm.cs.umn.edu>
To: rmt@lbl.gov
Subject: Vandermonde FEC name
Message-ID: <20001127222121.G12583@monopoly.cs.umn.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Sender: owner-rmt@lbl.gov
Precedence: bulk
Very nice job on the newest drafts guys, especially on the RMT BB FEC
Codes draft. It is very close to what I implemented against the old ALC
draft.
Now that 128 is specified as the encoding ID for small block
codes, does anyone (Luigi) know what the FEC Encoding Name will be for the
Vandermonde codes?
--
Justin Chapweske, Lead Swarmcast Developer, openCOLA Inc.
http://www.sourceforge.net/projects/swarmcast/
>From owner-rmt@listserv.lbl.gov Mon Nov 27 21:00:22 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id VAA05541;
Mon, 27 Nov 2000 21:00:08 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id VAA05537
for <rmt@listserv.lbl.gov>; Mon, 27 Nov 2000 21:00:06 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id VAA02421
for <rmt@listserv.lbl.gov>; Mon, 27 Nov 2000 21:00:05 -0800 (PST)
Received: from acm.cs.umn.edu (acm.cs.umn.edu [128.101.32.12])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id VAA02417
for <rmt@lbl.gov>; Mon, 27 Nov 2000 21:00:05 -0800 (PST)
Received: from monopoly.cs.umn.edu (monopoly.cs.umn.edu [128.101.32.5])
by acm.cs.umn.edu (8.11.1/8.11.0) with ESMTP id eAS50gq60715
for <rmt@lbl.gov>; Mon, 27 Nov 2000 23:00:42 -0600 (CST)
(envelope-from orasis@acm.cs.umn.edu)
Received: (from orasis@localhost)
by monopoly.cs.umn.edu (8.8.8/8.8.8) id WAA21875
for rmt@lbl.gov; Mon, 27 Nov 2000 22:57:37 -0800 (PST)
Date: Mon, 27 Nov 2000 22:57:37 -0800
From: Justin Chapweske <orasis@acm.cs.umn.edu>
To: rmt@lbl.gov
Subject: test...
Message-ID: <20001127225737.H12583@monopoly.cs.umn.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Sender: owner-rmt@lbl.gov
Precedence: bulk
testing to see if my mail is getting through to the list..
--
Justin Chapweske, Lead Swarmcast Developer, openCOLA Inc.
http://www.sourceforge.net/projects/swarmcast/
>From owner-rmt@listserv.lbl.gov Tue Nov 28 03:23:25 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id DAA05844;
Tue, 28 Nov 2000 03:22:47 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id DAA05840
for <rmt@listserv.lbl.gov>; Tue, 28 Nov 2000 03:22:45 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id DAA10336
for <rmt@listserv.lbl.gov>; Tue, 28 Nov 2000 03:22:44 -0800 (PST)
Received: from info.iet.unipi.it (info.iet.unipi.it [131.114.9.184])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id DAA10325
for <rmt@lbl.gov>; Tue, 28 Nov 2000 03:22:38 -0800 (PST)
Received: (from luigi@localhost)
by info.iet.unipi.it (8.9.3/8.9.3) id MAA18835;
Tue, 28 Nov 2000 12:25:14 +0100 (CET)
(envelope-from luigi)
From: Luigi Rizzo <luigi@info.iet.unipi.it>
Message-Id: <200011281125.MAA18835@info.iet.unipi.it>
Subject: Re: Vandermonde FEC name
In-Reply-To: <20001127222121.G12583@monopoly.cs.umn.edu> from Justin Chapweske
at "Nov 27, 2000 10:21:21 pm"
To: Justin Chapweske <orasis@acm.cs.umn.edu>
Date: Tue, 28 Nov 2000 12:25:14 +0100 (CET)
CC: rmt@lbl.gov
X-Mailer: ELM [version 2.4ME+ PL61 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-rmt@lbl.gov
Precedence: bulk
> Very nice job on the newest drafts guys, especially on the RMT BB FEC
> Codes draft. It is very close to what I implemented against the old ALC
> draft.
>
> Now that 128 is specified as the encoding ID for small block
> codes, does anyone (Luigi) know what the FEC Encoding Name will be for the
> Vandermonde codes?
no idea, sorry.
cheers
luigi
> --
> Justin Chapweske, Lead Swarmcast Developer, openCOLA Inc.
> http://www.sourceforge.net/projects/swarmcast/
>
>From owner-rmt@listserv.lbl.gov Wed Nov 29 03:32:43 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id DAA12846;
Wed, 29 Nov 2000 03:31:26 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id DAA12842
for <rmt@listserv.lbl.gov>; Wed, 29 Nov 2000 03:31:25 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id DAA07749
for <rmt@listserv.lbl.gov>; Wed, 29 Nov 2000 03:31:24 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id DAA07746
for <rmt@lbl.gov>; Wed, 29 Nov 2000 03:31:23 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01933;
Wed, 29 Nov 2000 06:31:22 -0500 (EST)
Message-Id: <200011291131.GAA01933@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: rmt@lbl.gov
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-rmt-bb-track-00.txt
Date: Wed, 29 Nov 2000 06:31:21 -0500
Sender: owner-rmt@lbl.gov
Precedence: bulk
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Reliable Multicast Transport Working Group of the IETF.
Title : Reliable Multicast Transport Building Block for TRACK
Author(s) : B. Whetten, D. Chiu et al.
Filename : draft-ietf-rmt-bb-track-00.txt
Pages : 26
Date : 28-Nov-00
This document describes the TRACK Building Block. It contains
functions relating to positive acknowledgments and hierarchical
tree construction and maintenance. It is primarily meant to be
used as part of the TRACK Protocol Instantiation. It is also
designed to be useful as part of overlay multicast systems that
wish to offer efficient confirmed delivery of multicast messages.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rmt-bb-track-00.txt
Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-rmt-bb-track-00.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.
Send a message to:
mailserv@ietf.org.
In the body type:
"FILE /internet-drafts/draft-ietf-rmt-bb-track-00.txt".
NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv@ietf.org"
Content-Type: text/plain
Content-ID: <20001128134540.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-rmt-bb-track-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-rmt-bb-track-00.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <20001128134540.I-D@ietf.org>
--OtherAccess--
--NextPart--
>From owner-rmt@listserv.lbl.gov Wed Nov 29 03:32:43 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id DAA12853;
Wed, 29 Nov 2000 03:31:30 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id DAA12849
for <rmt@listserv.lbl.gov>; Wed, 29 Nov 2000 03:31:29 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id DAA07764
for <rmt@listserv.lbl.gov>; Wed, 29 Nov 2000 03:31:28 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id DAA07761
for <rmt@lbl.gov>; Wed, 29 Nov 2000 03:31:27 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01967;
Wed, 29 Nov 2000 06:31:26 -0500 (EST)
Message-Id: <200011291131.GAA01967@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: rmt@lbl.gov
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-rmt-bb-tree-config-01.txt
Date: Wed, 29 Nov 2000 06:31:26 -0500
Sender: owner-rmt@lbl.gov
Precedence: bulk
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Reliable Multicast Transport Working Group of the IETF.
Title : Reliable Multicast Transport Building Block: Tree
Auto-Configuration
Author(s) : M. Kadansky, B. Levine, D. Chiu,
B. Whetten, G. Taskale, B. Cain, D. Thaler, S. Koh
Filename : draft-ietf-rmt-bb-tree-config-01.txt
Pages : 21
Date : 28-Nov-00
The Reliable Multicast Transport Working Group has been chartered to
standardize multicast transport services. This working group expects
to initially standardize three protocol instantiations. This draft is
concerned with the requirements of the tree-based ACK protocol. In
particular, it is concerned with defining the building block for
auto-configuration of the logical ACK-tree. According to the charter,
a building block is 'a coarse-grained modular component that is
common to multiple protocols along with abstract APIs that define a
building block's access methods and their arguments.' For more
information, see the Reliable Multicast Transport Building Blocks and
Reliable Multicast Design Space documents [WLKHFL00][HWKFV00].
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rmt-bb-tree-config-01.txt
Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-rmt-bb-tree-config-01.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.
Send a message to:
mailserv@ietf.org.
In the body type:
"FILE /internet-drafts/draft-ietf-rmt-bb-tree-config-01.txt".
NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv@ietf.org"
Content-Type: text/plain
Content-ID: <20001128134550.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-rmt-bb-tree-config-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-rmt-bb-tree-config-01.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <20001128134550.I-D@ietf.org>
--OtherAccess--
--NextPart--
>From owner-rmt@listserv.lbl.gov Wed Nov 29 03:32:44 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id DAA12840;
Wed, 29 Nov 2000 03:31:22 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id DAA12836
for <rmt@listserv.lbl.gov>; Wed, 29 Nov 2000 03:31:20 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id DAA07728
for <rmt@listserv.lbl.gov>; Wed, 29 Nov 2000 03:31:20 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id DAA07718
for <rmt@lbl.gov>; Wed, 29 Nov 2000 03:31:19 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01887;
Wed, 29 Nov 2000 06:31:18 -0500 (EST)
Message-Id: <200011291131.GAA01887@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: rmt@lbl.gov
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-rmt-pi-norm-00.txt
Date: Wed, 29 Nov 2000 06:31:17 -0500
Sender: owner-rmt@lbl.gov
Precedence: bulk
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Reliable Multicast Transport Working Group of the IETF.
Title : NACK-Oriented Reliable Multicast Protocol (NORM)
Author(s) : B. Adamson, C. Bormann, S. Floyd, M. Handley,
J. Macker
Filename : draft-ietf-rmt-pi-norm-00.txt
Pages : 11
Date : 28-Nov-00
This document describes the messages and procedures of the Nega-
tive-acknowledgement (NACK) oriented reliable multicast (NORM).
This revision of the document represents an initial outline of the
protocol description. The document requires refinement in a number
of areas to be considered complete. At this time, the document
describes the high level details of the reliable multicast bulk
transfer service model this protocol hopes to fulfill and the gen-
eral message types and mechanisms which will be used to accomplish
those goals.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rmt-pi-norm-00.txt
Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-rmt-pi-norm-00.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.
Send a message to:
mailserv@ietf.org.
In the body type:
"FILE /internet-drafts/draft-ietf-rmt-pi-norm-00.txt".
NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv@ietf.org"
Content-Type: text/plain
Content-ID: <20001128134529.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-rmt-pi-norm-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-rmt-pi-norm-00.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <20001128134529.I-D@ietf.org>
--OtherAccess--
--NextPart--
>From owner-rmt@listserv.lbl.gov Wed Nov 29 18:00:47 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id RAA18573;
Wed, 29 Nov 2000 17:59:38 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id RAA18565
for <rmt@listserv.lbl.gov>; Wed, 29 Nov 2000 17:59:35 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id RAA17940
for <rmt@listserv.lbl.gov>; Wed, 29 Nov 2000 17:59:35 -0800 (PST)
Received: from mailman.lanl.gov (mailman.lanl.gov [128.165.5.1])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id RAA17935
for <rmt@lbl.gov>; Wed, 29 Nov 2000 17:59:34 -0800 (PST)
Received: (from root@localhost)
by mailman.lanl.gov (8.10.1/8.10.1/(cic-5, 6/12/00)) id eAU1msN25363;
Wed, 29 Nov 2000 18:48:54 -0700
Received: from mailproxy.lanl.gov ([128.165.254.25])
by mailman.lanl.gov (8.10.1/8.10.1/(cic-5, 6/12/00)) with ESMTP id eATM4Hf09303;
Wed, 29 Nov 2000 15:04:17 -0700
Received: from loki.ietf.org (loki.ietf.org [132.151.1.177])
by mailproxy.lanl.gov (8.10.1/8.10.1/(cic-5, 6/12/00)) with ESMTP id eATM4Ff25980;
Wed, 29 Nov 2000 15:04:15 -0700
Received: (from adm@localhost)
by loki.ietf.org (8.9.1b+Sun/8.9.1) id QAA06320
for ietf-123-outbound.07@ietf.org; Wed, 29 Nov 2000 16:45:01 -0500 (EST)
Received: from ietf.org (odin.ietf.org [10.27.2.28])
by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA01521
for <all-ietf@loki.ietf.org>; Wed, 29 Nov 2000 06:31:27 -0500 (EST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01967;
Wed, 29 Nov 2000 06:31:26 -0500 (EST)
Message-Id: <200011291131.GAA01967@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: rmt@lbl.gov
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-rmt-bb-tree-config-01.txt
Date: Wed, 29 Nov 2000 06:31:26 -0500
Sender: owner-rmt@lbl.gov
Precedence: bulk
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Reliable Multicast Transport Working Group of the IETF.
Title : Reliable Multicast Transport Building Block: Tree
Auto-Configuration
Author(s) : M. Kadansky, B. Levine, D. Chiu,
B. Whetten, G. Taskale, B. Cain, D. Thaler, S. Koh
Filename : draft-ietf-rmt-bb-tree-config-01.txt
Pages : 21
Date : 28-Nov-00
The Reliable Multicast Transport Working Group has been chartered to
standardize multicast transport services. This working group expects
to initially standardize three protocol instantiations. This draft is
concerned with the requirements of the tree-based ACK protocol. In
particular, it is concerned with defining the building block for
auto-configuration of the logical ACK-tree. According to the charter,
a building block is 'a coarse-grained modular component that is
common to multiple protocols along with abstract APIs that define a
building block's access methods and their arguments.' For more
information, see the Reliable Multicast Transport Building Blocks and
Reliable Multicast Design Space documents [WLKHFL00][HWKFV00].
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rmt-bb-tree-config-01.txt
Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-rmt-bb-tree-config-01.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.
Send a message to:
mailserv@ietf.org.
In the body type:
"FILE /internet-drafts/draft-ietf-rmt-bb-tree-config-01.txt".
NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv@ietf.org"
Content-Type: text/plain
Content-ID: <20001128134550.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-rmt-bb-tree-config-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-rmt-bb-tree-config-01.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <20001128134550.I-D@ietf.org>
--OtherAccess--
--NextPart--
>From owner-rmt@listserv.lbl.gov Wed Nov 29 18:00:47 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id RAA18572;
Wed, 29 Nov 2000 17:59:38 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id RAA18563
for <rmt@listserv.lbl.gov>; Wed, 29 Nov 2000 17:59:35 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id RAA17937
for <rmt@listserv.lbl.gov>; Wed, 29 Nov 2000 17:59:34 -0800 (PST)
Received: from mailman.lanl.gov (mailman.lanl.gov [128.165.5.1])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id RAA17933
for <rmt@lbl.gov>; Wed, 29 Nov 2000 17:59:34 -0800 (PST)
Received: (from root@localhost)
by mailman.lanl.gov (8.10.1/8.10.1/(cic-5, 6/12/00)) id eAU1teo26146;
Wed, 29 Nov 2000 18:55:40 -0700
Received: from mailproxy.lanl.gov ([128.165.254.25])
by mailman.lanl.gov (8.10.1/8.10.1/(cic-5, 6/12/00)) with ESMTP id eATM4Hf09303;
Wed, 29 Nov 2000 15:04:17 -0700
Received: from loki.ietf.org (loki.ietf.org [132.151.1.177])
by mailproxy.lanl.gov (8.10.1/8.10.1/(cic-5, 6/12/00)) with ESMTP id eATM4Ff25980;
Wed, 29 Nov 2000 15:04:15 -0700
Received: (from adm@localhost)
by loki.ietf.org (8.9.1b+Sun/8.9.1) id QAA06320
for ietf-123-outbound.07@ietf.org; Wed, 29 Nov 2000 16:45:01 -0500 (EST)
Received: from ietf.org (odin.ietf.org [10.27.2.28])
by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA01521
for <all-ietf@loki.ietf.org>; Wed, 29 Nov 2000 06:31:27 -0500 (EST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01967;
Wed, 29 Nov 2000 06:31:26 -0500 (EST)
Message-Id: <200011291131.GAA01967@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: rmt@lbl.gov
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-rmt-bb-tree-config-01.txt
Date: Wed, 29 Nov 2000 06:31:26 -0500
Sender: owner-rmt@lbl.gov
Precedence: bulk
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Reliable Multicast Transport Working Group of the IETF.
Title : Reliable Multicast Transport Building Block: Tree
Auto-Configuration
Author(s) : M. Kadansky, B. Levine, D. Chiu,
B. Whetten, G. Taskale, B. Cain, D. Thaler, S. Koh
Filename : draft-ietf-rmt-bb-tree-config-01.txt
Pages : 21
Date : 28-Nov-00
The Reliable Multicast Transport Working Group has been chartered to
standardize multicast transport services. This working group expects
to initially standardize three protocol instantiations. This draft is
concerned with the requirements of the tree-based ACK protocol. In
particular, it is concerned with defining the building block for
auto-configuration of the logical ACK-tree. According to the charter,
a building block is 'a coarse-grained modular component that is
common to multiple protocols along with abstract APIs that define a
building block's access methods and their arguments.' For more
information, see the Reliable Multicast Transport Building Blocks and
Reliable Multicast Design Space documents [WLKHFL00][HWKFV00].
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rmt-bb-tree-config-01.txt
Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-rmt-bb-tree-config-01.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.
Send a message to:
mailserv@ietf.org.
In the body type:
"FILE /internet-drafts/draft-ietf-rmt-bb-tree-config-01.txt".
NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv@ietf.org"
Content-Type: text/plain
Content-ID: <20001128134550.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-rmt-bb-tree-config-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-rmt-bb-tree-config-01.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <20001128134550.I-D@ietf.org>
--OtherAccess--
--NextPart--
>From owner-rmt@listserv.lbl.gov Wed Nov 29 18:13:43 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id SAA18640;
Wed, 29 Nov 2000 18:13:29 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id SAA18636
for <rmt@listserv.lbl.gov>; Wed, 29 Nov 2000 18:13:27 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id SAA20665
for <rmt@listserv.lbl.gov>; Wed, 29 Nov 2000 18:13:27 -0800 (PST)
Received: from mailman.lanl.gov (mailman.lanl.gov [128.165.5.1])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id SAA20662
for <rmt@lbl.gov>; Wed, 29 Nov 2000 18:13:26 -0800 (PST)
Received: (from root@localhost)
by mailman.lanl.gov (8.10.1/8.10.1/(cic-5, 6/12/00)) id eAU1u2s26542;
Wed, 29 Nov 2000 18:56:02 -0700
Received: from listman.lanl.gov ([128.165.3.62])
by mailman.lanl.gov (8.10.1/8.10.1/(cic-5, 6/12/00)) with ESMTP id eATM5af11545;
Wed, 29 Nov 2000 15:05:36 -0700
Received: (from daemon@localhost)
by listman.lanl.gov (8.9.3/8.9.3/(cic-5, 2/9/99)) id PAA02438
for ietf-outgoing; Wed, 29 Nov 2000 15:05:32 -0700
Message-Id: <200011291131.GAA01933@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: rmt@lbl.gov
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-rmt-bb-track-00.txt
Date: Wed, 29 Nov 2000 06:31:21 -0500
Sender: owner-rmt@lbl.gov
Precedence: bulk
--NextPart--
>From owner-rmt@listserv.lbl.gov Wed Nov 29 19:01:30 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id TAA18770;
Wed, 29 Nov 2000 19:01:12 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id TAA18761
for <rmt@listserv.lbl.gov>; Wed, 29 Nov 2000 19:01:10 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id TAA27710
for <rmt@listserv.lbl.gov>; Wed, 29 Nov 2000 19:01:09 -0800 (PST)
Received: from mailman.lanl.gov (mailman.lanl.gov [128.165.5.1])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id TAA27702
for <rmt@lbl.gov>; Wed, 29 Nov 2000 19:01:08 -0800 (PST)
Received: (from root@localhost)
by mailman.lanl.gov (8.10.1/8.10.1/(cic-5, 6/12/00)) id eAU2TV409186;
Wed, 29 Nov 2000 19:29:31 -0700
Received: from mailproxy.lanl.gov ([128.165.254.25])
by mailman.lanl.gov (8.10.1/8.10.1/(cic-5, 6/12/00)) with ESMTP id eATM4Hf09303;
Wed, 29 Nov 2000 15:04:17 -0700
Received: from loki.ietf.org (loki.ietf.org [132.151.1.177])
by mailproxy.lanl.gov (8.10.1/8.10.1/(cic-5, 6/12/00)) with ESMTP id eATM4Ff25980;
Wed, 29 Nov 2000 15:04:15 -0700
Received: (from adm@localhost)
by loki.ietf.org (8.9.1b+Sun/8.9.1) id QAA06320
for ietf-123-outbound.07@ietf.org; Wed, 29 Nov 2000 16:45:01 -0500 (EST)
Received: from ietf.org (odin.ietf.org [10.27.2.28])
by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA01521
for <all-ietf@loki.ietf.org>; Wed, 29 Nov 2000 06:31:27 -0500 (EST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01967;
Wed, 29 Nov 2000 06:31:26 -0500 (EST)
Message-Id: <200011291131.GAA01967@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: rmt@lbl.gov
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-rmt-bb-tree-config-01.txt
Date: Wed, 29 Nov 2000 06:31:26 -0500
Sender: owner-rmt@lbl.gov
Precedence: bulk
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Reliable Multicast Transport Working Group of the IETF.
Title : Reliable Multicast Transport Building Block: Tree
Auto-Configuration
Author(s) : M. Kadansky, B. Levine, D. Chiu,
B. Whetten, G. Taskale, B. Cain, D. Thaler, S. Koh
Filename : draft-ietf-rmt-bb-tree-config-01.txt
Pages : 21
Date : 28-Nov-00
The Reliable Multicast Transport Working Group has been chartered to
standardize multicast transport services. This working group expects
to initially standardize three protocol instantiations. This draft is
concerned with the requirements of the tree-based ACK protocol. In
particular, it is concerned with defining the building block for
auto-configuration of the logical ACK-tree. According to the charter,
a building block is 'a coarse-grained modular component that is
common to multiple protocols along with abstract APIs that define a
building block's access methods and their arguments.' For more
information, see the Reliable Multicast Transport Building Blocks and
Reliable Multicast Design Space documents [WLKHFL00][HWKFV00].
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rmt-bb-tree-config-01.txt
Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-rmt-bb-tree-config-01.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.
Send a message to:
mailserv@ietf.org.
In the body type:
"FILE /internet-drafts/draft-ietf-rmt-bb-tree-config-01.txt".
NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv@ietf.org"
Content-Type: text/plain
Content-ID: <20001128134550.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-rmt-bb-tree-config-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-rmt-bb-tree-config-01.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <20001128134550.I-D@ietf.org>
--OtherAccess--
--NextPart--
>From owner-rmt@listserv.lbl.gov Wed Nov 29 19:01:30 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id TAA18776;
Wed, 29 Nov 2000 19:01:15 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id TAA18772
for <rmt@listserv.lbl.gov>; Wed, 29 Nov 2000 19:01:13 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id TAA27726
for <rmt@listserv.lbl.gov>; Wed, 29 Nov 2000 19:01:12 -0800 (PST)
Received: from mailman.lanl.gov (mailman.lanl.gov [128.165.5.1])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id TAA27723
for <rmt@lbl.gov>; Wed, 29 Nov 2000 19:01:12 -0800 (PST)
Received: (from root@localhost)
by mailman.lanl.gov (8.10.1/8.10.1/(cic-5, 6/12/00)) id eAU2UcX09784;
Wed, 29 Nov 2000 19:30:38 -0700
Received: from listman.lanl.gov ([128.165.3.62])
by mailman.lanl.gov (8.10.1/8.10.1/(cic-5, 6/12/00)) with ESMTP id eATM5af11545;
Wed, 29 Nov 2000 15:05:36 -0700
Received: (from daemon@localhost)
by listman.lanl.gov (8.9.3/8.9.3/(cic-5, 2/9/99)) id PAA02438
for ietf-outgoing; Wed, 29 Nov 2000 15:05:32 -0700
Message-Id: <200011291131.GAA01933@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: rmt@lbl.gov
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-rmt-bb-track-00.txt
Date: Wed, 29 Nov 2000 06:31:21 -0500
Sender: owner-rmt@lbl.gov
Precedence: bulk
--NextPart--
>From owner-rmt@listserv.lbl.gov Thu Nov 30 14:13:30 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id OAA21466;
Thu, 30 Nov 2000 14:10:39 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id OAA21458
for <rmt@listserv.lbl.gov>; Thu, 30 Nov 2000 14:10:36 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id OAA10987
for <rmt@listserv.lbl.gov>; Thu, 30 Nov 2000 14:10:36 -0800 (PST)
Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id OAA10872
for <rmt@lbl.gov>; Thu, 30 Nov 2000 14:10:20 -0800 (PST)
Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate2.mot.com (motgate2 2.1) with ESMTP id PAA17469; Thu, 30 Nov 2000 15:09:49 -0700 (MST)]
Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [217.1.10.38]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id PAA16741; Thu, 30 Nov 2000 15:09:46 -0700 (MST)]
Received: from arc.corp.mot.com (marcia.arc.corp.mot.com [217.1.10.74])
by homer.arc.corp.mot.com (8.10.2/8.10.2) with ESMTP id eAUM8US05125;
Fri, 1 Dec 2000 09:08:30 +1100 (EST)
Message-ID: <3A26CF70.552047EF@arc.corp.mot.com>
Date: Fri, 01 Dec 2000 09:06:40 +1100
From: Roger Kermode <rkermode@arc.corp.mot.com>
Reply-To: Roger.Kermode@motorola.com
Organization: Motorola
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: rmt-list <rmt@lbl.gov>
CC: Lorenzo Vicisano <lorenzo@cisco.com>, Allison Mankin <mankin@ISI.EDU>
Subject: RMT Tentative Agenda (items only at this stage)
Content-Type: multipart/mixed;
boundary="------------0336CD28CEB2CCF5E1221257"
Sender: owner-rmt@lbl.gov
Precedence: bulk
This is a multi-part message in MIME format.
--------------0336CD28CEB2CCF5E1221257
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Dear RMT'ers,
in preparing the agenda for the San Diego meeting
We've noticed that we have a lot of drafts, some of
which are new and some of which have expired.
In keeping with directives from the ADs we are asking
that presenters assume that people have read the
draft and that their presentations consist of a brief
summary of the draft/updates to the draft followed
by discussion on outstanding issues.
Given this approach we are expecting that there
will only be presentations for the drafts that have
changed since the last meeting, i.e. drafts with *
in front of them.
To date we've only received a couple of explicit
requests for time slots. If you want to present
during the RMT sessions at the IETF please
email the chairs ASAP
regards,
Roger, Lorenzo, and Allison
Outstanding RMT Drafts/Potential Presentations at San Diego
=========================================
Key:
* = updated since last meeting
exp = draft has expired
Agenda Bashing, Roger 5 mins
General Draft Updates
* <draft-ietf-rmt-building-blocks-03.txt>
<draft-ietf-author-guidelines-**.txt>
NORM reorganisation
* <draft-ietf-rmt-pi-norm-00.txt>
ALC drafts
* <draft-ietf-rmt-bb-lct-00.txt>
* <draft-ietf-rmt-info-fec-02.txt>
<draft-ietf-rmt-pi-alc-01.txt>
TRACK
<draft-ietf-rmt-bb-track-00.txt>
* <draft-ietf-rmt-bb-tree-config-01.txt>
<draft-ietf-rmt-track-arch-00.txt>
<draft-ietf-rmt-track-security-00.txt>
CONGESTION CONTROL
* <draft-ietf-rmt-bb-lcc-00.txt> Mike Luby 15 mins?
<draft-ietf-rmt-bb-mrcc-00.txt>
GRA
exp <draft-ietf-rmt-gra-arch-01.txt>
Individual drafts
* <draft-calvert-concast-svc-00.txt> Ken Calvert 15 mins
MIBs
<draft-petrova-pgmmib-00.txt> Michale Garwood 10 mins
msec WG advertisement, Roger, 5 mins
--------------0336CD28CEB2CCF5E1221257
Content-Type: text/x-vcard; charset=us-ascii;
name="rkermode.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Roger Kermode
Content-Disposition: attachment;
filename="rkermode.vcf"
begin:vcard
n:Kermode;Roger
tel;cell:+61-408-212-284
tel;fax:+61-2-9666-0501
tel;home:+61-2-9664-8335
tel;work:+61-2-9666-0558
x-mozilla-html:FALSE
url:www.mot.com.au
org:Motorola Australian Research Centre;Communications and Networking Lab
version:2.1
email;internet:Roger.Kermode@motorola.com
title:Principal Research Engineer, Manager
adr;quoted-printable:;;Level 3,=0D=0A12 Lord St.;Botany;NSW;2019;Australia
fn:Roger Kermode
end:vcard
--------------0336CD28CEB2CCF5E1221257--
>From owner-rmt@listserv.lbl.gov Mon Dec 4 08:39:56 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id IAA09125;
Mon, 4 Dec 2000 08:35:07 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id IAA09121
for <rmt@listserv.lbl.gov>; Mon, 4 Dec 2000 08:35:05 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id IAA28600
for <rmt@listserv.lbl.gov>; Mon, 4 Dec 2000 08:35:04 -0800 (PST)
Received: from east.isi.edu (east.isi.edu [38.245.76.2])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id IAA28589
for <rmt@lbl.gov>; Mon, 4 Dec 2000 08:35:03 -0800 (PST)
Received: from maia.east.isi.edu (maia.east.isi.edu [38.245.76.14])
by east.isi.edu (8.9.2/8.9.2) with SMTP id LAA26743;
Mon, 4 Dec 2000 11:35:11 -0500 (EST)
Posted-Date: Mon, 04 Dec 2000 11:38:48 -0500
Message-Id: <10012041638.AA28386@maia.east.isi.edu>
Received: from LOCALHOST.east.isi.edu by maia.east.isi.edu (4.1/4.0.3-6)
id <AA28386>; Mon, 4 Dec 00 11:38:49 EST
To: agenda@ietf.org
Subject: RMT Draft Agenda
Cc: lorenzo@cisco.com, roger.kermode@motorola.com, mankin@ISI.EDU,
sob@harvard.edu, rmt@lbl.gov
Reply-To: mankin@east.isi.edu
Date: Mon, 04 Dec 2000 11:38:48 -0500
From: Allison Mankin <mankin@ISI.EDU>
Sender: owner-rmt@lbl.gov
Precedence: bulk
RMT Topics at San Diego - Draft Agenda
======================================
Key:
exp = draft has expired
* = updated since last meeting, expected to be
discussed, times to be refined
no star means probably not to be discussed
Agenda Bashing, Roger 5 mins
General Draft Updates
* <draft-ietf-rmt-building-blocks-03.txt>
<draft-ietf-author-guidelines-**.txt>
NORM reorganisation
* <draft-ietf-rmt-pi-norm-00.txt>
ALC drafts
* <draft-ietf-rmt-bb-lct-00.txt>
* <draft-ietf-rmt-info-fec-02.txt>
<draft-ietf-rmt-pi-alc-01.txt>
TRACK
<draft-ietf-rmt-bb-track-00.txt>
* <draft-ietf-rmt-bb-tree-config-01.txt>
<draft-ietf-rmt-track-arch-00.txt>
<draft-ietf-rmt-track-security-00.txt>
CONGESTION CONTROL
* <draft-ietf-rmt-bb-lcc-00.txt> Mike Luby 15 mins?
<draft-ietf-rmt-bb-mrcc-00.txt>
GRA/PGM
exp <draft-ietf-rmt-gra-arch-01.txt>
Newly issued PGM draft - plan?
Individual drafts (not in charter)
* <draft-calvert-concast-svc-00.txt> Ken Calvert 15 mins
MIBs
<draft-petrova-pgmmib-00.txt> Michale Garwood 10 mins
Advertisement of MSEC BOF, Roger, 5 mins
Advertisement of discussion of TFRC in TSVWG, Allison 2 mins
>From owner-rmt@listserv.lbl.gov Mon Dec 4 09:23:24 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id JAA09408;
Mon, 4 Dec 2000 09:20:08 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id JAA09404
for <rmt@listserv.lbl.gov>; Mon, 4 Dec 2000 09:20:07 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id JAA18090
for <rmt@listserv.lbl.gov>; Mon, 4 Dec 2000 09:20:06 -0800 (PST)
Received: from cisco.com (zipper.cisco.com [171.69.25.142])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id JAA18086
for <rmt@lbl.gov>; Mon, 4 Dec 2000 09:20:06 -0800 (PST)
Received: from localhost (speakman@localhost)
by cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with ESMTP id JAA21548;
Mon, 4 Dec 2000 09:18:33 -0800 (PST)
Message-Id: <200012041718.JAA21548@cisco.com>
To: mankin@east.isi.edu
cc: sob@harvard.edu, rmt@lbl.gov
Subject: Re: RMT Draft Agenda
Mime-Version: 1.0 (generated by tm-edit 7.105)
Content-Type: text/plain; charset=US-ASCII
Date: Mon, 04 Dec 2000 09:18:32 -0800
From: Tony Speakman <speakman@cisco.com>
Sender: owner-rmt@lbl.gov
Precedence: bulk
> GRA/PGM
> exp <draft-ietf-rmt-gra-arch-01.txt>
At least one of the authors is no longer active on the draft
while others have expressed interest. I plan to revisit the
thing with Don Towsley and Christos Papadopoulos shortly, but
there's nothing to discuss for the moment.
> Newly issued PGM draft - plan?
On behalf of all the PGM authors, I can say that we have no
plan to discuss the new PGM spec in this forum.
Tony S
>From owner-rmt@listserv.lbl.gov Mon Dec 4 10:20:40 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id KAA09996;
Mon, 4 Dec 2000 10:17:27 -0800 (PST)
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id KAA09992
for <rmt@listserv.lbl.gov>; Mon, 4 Dec 2000 10:17:25 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id KAA12605
for <rmt@listserv.lbl.gov>; Mon, 4 Dec 2000 10:17:24 -0800 (PST)
Received: from mail.webfountain.com (mail.webfountain.com [63.161.54.5])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id KAA12594
for <rmt@lbl.gov>; Mon, 4 Dec 2000 10:17:23 -0800 (PST)
Received: from leningrad (gate.webfountain.com [63.161.54.3])
by mail.webfountain.com (8.9.3/8.9.3) with SMTP id KAA17928;
Mon, 4 Dec 2000 10:16:39 -0800
X-Authentication-Warning: mail.webfountain.com: Host gate.webfountain.com [63.161.54.3] claimed to be leningrad
From: "Mike Luby" <luby@digitalfountain.com>
To: <mankin@east.isi.edu>, <agenda@ietf.org>
Cc: <lorenzo@cisco.com>, <roger.kermode@motorola.com>, <sob@harvard.edu>,
<rmt@lbl.gov>
Subject: RE: RMT Draft Agenda
Date: Mon, 4 Dec 2000 10:16:35 -0800
Message-ID: <NEBBIAPCNKEDCLPNFBNCMEHKCEAA.luby@digitalfountain.com>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Importance: Normal
In-Reply-To: <10012041638.AA28386@maia.east.isi.edu>
Sender: owner-rmt@lbl.gov
Precedence: bulk
Allison et. al.,
Roger sent out a very similar draft agenda recently, and I sent the enclosed
email back to him in response. Please take a look at what this email
proposes before making up the final schedule.
Thanks, Mike
----------------------------------------------------------------------------
--------------
From: Mike Luby [luby@digitalfountain.com]
Sent: Thursday, November 30, 2000 7:53 PM
To: Roger.Kermode@motorola.com
Cc: Michael Luby; Luigi Rizzo; Lorenzo Vicisano; Mark Handley
Subject: RE: RMT Tentative Agenda (items only at this stage)
Roger,
A couple of clarifications and explanations. We submitted four drafts this
time from within what used to be called the ALC track (changing the name,
and not all of the drafts formally belong in whatever the track is called
anyway). The four new drafts are the LCT draft (correctly listed below,
which will subsume the ALC draft), the LCC draft (correctly listed below,
which will subsume the MRCC draft), and two FEC drafts. There is only one
FEC draft listed below. There is a new version draft-ietf-rmt-bb-fec-02.txt
of the previous FEC draft, and then there is a new FEC draft called
draft-ietf-rmt-info-fec-00.txt.
Here is how it all fits together:
It was decided by Mark Handley and Luigi Rizzo that ALC should be renamed
Layered Coding Transport (LCT), and Lorenzo and I agreed with their
proposal. The basic rationale is that the LCT protocol could be used for
more than reliable content delivery of one object in the future, and in
particular it could be used for things like use with layered codecs for
video delivery, or for sequential delivery of many objects, etc.
In conjunction with this I decided that the MRCC name was too general
(multi-rate congestion control can be achieve by a variety of means that
don't involve layering), and thus I thought it would be better to rename
this to Layered Congestion Control (LCC) (which is more in the spirit of the
name LCT).
As we are gaining experience with the building block approach, we decided
that it made sense to split the FEC documents into two parts: one
informational track draft that would describe the available codes and their
uses within the RMT working group (this is the new draft, which largely
contains material taken from the previous building block draft), and another
standards track draft that would specify the abstract packet formats and
IANA registration considerations for some specific codes that can be used in
conjunction with LCT (also containing material largely from the previous
building block draft, and this draft maintained the name of the previous
draft). We didn't do this yet with the LCC building block, but I believe
that in the long term, if this approach work for the FEC building block, the
same model will be adopted by the LCC building block (and perhaps all the
building blocks).
So, given all of this, I think it actually makes sense to have an agenda
item on the schedule for someone to describe all of these structural and
naming changes and the rationales behind them. I nominate Mark Handley for
this general presentation. Then, I think that Luigi Rizzo should do the LCT
presentation and Lorenzo Vicisano should do the two FEC presentations, and I
will do the LCC presentation (assuming that they are all willing to do it,
of course).
Make sense?
Mike
-----Original Message-----
From: owner-rmt@lbl.gov [mailto:owner-rmt@lbl.gov]On Behalf Of Roger
Kermode
Sent: Thursday, November 30, 2000 2:07 PM
To: rmt-list
Cc: Lorenzo Vicisano; Allison Mankin
Subject: RMT Tentative Agenda (items only at this stage)
Dear RMT'ers,
in preparing the agenda for the San Diego meeting
We've noticed that we have a lot of drafts, some of
which are new and some of which have expired.
In keeping with directives from the ADs we are asking
that presenters assume that people have read the
draft and that their presentations consist of a brief
summary of the draft/updates to the draft followed
by discussion on outstanding issues.
Given this approach we are expecting that there
will only be presentations for the drafts that have
changed since the last meeting, i.e. drafts with *
in front of them.
To date we've only received a couple of explicit
requests for time slots. If you want to present
during the RMT sessions at the IETF please
email the chairs ASAP
regards,
Roger, Lorenzo, and Allison
Outstanding RMT Drafts/Potential Presentations at San Diego
=========================================
Key:
* = updated since last meeting
exp = draft has expired
Agenda Bashing, Roger 5 mins
General Draft Updates
* <draft-ietf-rmt-building-blocks-03.txt>
<draft-ietf-author-guidelines-**.txt>
NORM reorganisation
* <draft-ietf-rmt-pi-norm-00.txt>
ALC drafts
* <draft-ietf-rmt-bb-lct-00.txt>
* <draft-ietf-rmt-info-fec-02.txt>
<draft-ietf-rmt-pi-alc-01.txt>
TRACK
<draft-ietf-rmt-bb-track-00.txt>
* <draft-ietf-rmt-bb-tree-config-01.txt>
<draft-ietf-rmt-track-arch-00.txt>
<draft-ietf-rmt-track-security-00.txt>
CONGESTION CONTROL
* <draft-ietf-rmt-bb-lcc-00.txt> Mike Luby 15 mins?
<draft-ietf-rmt-bb-mrcc-00.txt>
GRA
exp <draft-ietf-rmt-gra-arch-01.txt>
Individual drafts
* <draft-calvert-concast-svc-00.txt> Ken Calvert 15 mins
MIBs
<draft-petrova-pgmmib-00.txt> Michale Garwood 10 mins
msec WG advertisement, Roger, 5 mins
----------------------------------------------------------------------------
-------------
-----Original Message-----
From: owner-rmt@lbl.gov [mailto:owner-rmt@lbl.gov]On Behalf Of Allison
Mankin
Sent: Monday, December 04, 2000 8:39 AM
To: agenda@ietf.org
Cc: lorenzo@cisco.com; roger.kermode@motorola.com; mankin@ISI.EDU;
sob@harvard.edu; rmt@lbl.gov
Subject: RMT Draft Agenda
RMT Topics at San Diego - Draft Agenda
======================================
Key:
exp = draft has expired
* = updated since last meeting, expected to be
discussed, times to be refined
no star means probably not to be discussed
Agenda Bashing, Roger 5 mins
General Draft Updates
* <draft-ietf-rmt-building-blocks-03.txt>
<draft-ietf-author-guidelines-**.txt>
NORM reorganisation
* <draft-ietf-rmt-pi-norm-00.txt>
ALC drafts
* <draft-ietf-rmt-bb-lct-00.txt>
* <draft-ietf-rmt-info-fec-02.txt>
<draft-ietf-rmt-pi-alc-01.txt>
TRACK
<draft-ietf-rmt-bb-track-00.txt>
* <draft-ietf-rmt-bb-tree-config-01.txt>
<draft-ietf-rmt-track-arch-00.txt>
<draft-ietf-rmt-track-security-00.txt>
CONGESTION CONTROL
* <draft-ietf-rmt-bb-lcc-00.txt> Mike Luby 15 mins?
<draft-ietf-rmt-bb-mrcc-00.txt>
GRA/PGM
exp <draft-ietf-rmt-gra-arch-01.txt>
Newly issued PGM draft - plan?
Individual drafts (not in charter)
* <draft-calvert-concast-svc-00.txt> Ken Calvert 15 mins
MIBs
<draft-petrova-pgmmib-00.txt> Michale Garwood 10 mins
Advertisement of MSEC BOF, Roger, 5 mins
Advertisement of discussion of TFRC in TSVWG, Allison 2 mins
>From owner-rmt@listserv.lbl.gov Mon Dec 4 10:55:47 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id KAA10198;
Mon, 4 Dec 2000 10:55:36 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id KAA10194
for <rmt@listserv.lbl.gov>; Mon, 4 Dec 2000 10:55:34 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id KAA29088
for <rmt@listserv.lbl.gov>; Mon, 4 Dec 2000 10:55:34 -0800 (PST)
Received: from east.isi.edu (east.isi.edu [38.245.76.2])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id KAA29078
for <rmt@lbl.gov>; Mon, 4 Dec 2000 10:55:33 -0800 (PST)
Received: from maia.east.isi.edu (maia.east.isi.edu [38.245.76.14])
by east.isi.edu (8.9.2/8.9.2) with SMTP id NAA28319;
Mon, 4 Dec 2000 13:55:39 -0500 (EST)
Posted-Date: Mon, 04 Dec 2000 13:59:17 -0500
Message-Id: <10012041859.AA28576@maia.east.isi.edu>
Received: from LOCALHOST.east.isi.edu by maia.east.isi.edu (4.1/4.0.3-6)
id <AA28576>; Mon, 4 Dec 00 13:59:18 EST
To: "Mike Luby" <luby@digitalfountain.com>
Cc: mankin@east.isi.edu, lorenzo@cisco.com, roger.kermode@motorola.com,
sob@harvard.edu, rmt@lbl.gov
Reply-To: mankin@east.isi.edu
Subject: Re: RMT Draft Agenda
In-Reply-To: Your message of Mon, 04 Dec 2000 10:16:35 -0800.
<NEBBIAPCNKEDCLPNFBNCMEHKCEAA.luby@digitalfountain.com>
Date: Mon, 04 Dec 2000 13:59:17 -0500
From: Allison Mankin <mankin@ISI.EDU>
Sender: owner-rmt@lbl.gov
Precedence: bulk
Mike,
I have dropped agenda@ietf.org from the cc list. We can revise
the draft agenda later after we nail down all the details.
I jumped in and sent a slightly cleaned-up of Roger's tentative
agenda to the Secretariat, because of my AD instincts, wanting
RMT very much not to miss today's deadline.
In the likely absence of Mark, it sounds to me like you would be
a good person to speak to the reorg/rename. Please let
us know too how long the several talks you suggest should
be.
Other comments/corrections on the draft agenda are welcome.
Allison
>From owner-rmt@listserv.lbl.gov Mon Dec 4 10:58:00 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id KAA10257;
Mon, 4 Dec 2000 10:57:57 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id KAA10253
for <rmt@listserv.lbl.gov>; Mon, 4 Dec 2000 10:57:55 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id KAA00060
for <rmt@listserv.lbl.gov>; Mon, 4 Dec 2000 10:57:54 -0800 (PST)
Received: from east.isi.edu (east.isi.edu [38.245.76.2])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id KAA00030
for <rmt@lbl.gov>; Mon, 4 Dec 2000 10:57:51 -0800 (PST)
Received: from maia.east.isi.edu (maia.east.isi.edu [38.245.76.14])
by east.isi.edu (8.9.2/8.9.2) with SMTP id NAA28388;
Mon, 4 Dec 2000 13:57:58 -0500 (EST)
Posted-Date: Mon, 04 Dec 2000 14:01:37 -0500
Message-Id: <10012041901.AA28589@maia.east.isi.edu>
Received: from LOCALHOST.east.isi.edu by maia.east.isi.edu (4.1/4.0.3-6)
id <AA28589>; Mon, 4 Dec 00 14:01:37 EST
To: Tony Speakman <speakman@cisco.com>
Cc: mankin@east.isi.edu, sob@harvard.edu, rmt@lbl.gov
Reply-To: mankin@east.isi.edu
Subject: Re: RMT Draft Agenda
In-Reply-To: Your message of Mon, 04 Dec 2000 09:18:32 -0800.
<200012041718.JAA21548@cisco.com>
Date: Mon, 04 Dec 2000 14:01:37 -0500
From: Allison Mankin <mankin@ISI.EDU>
Sender: owner-rmt@lbl.gov
Precedence: bulk
Tony,
Thanks for your response to the agenda trial balloons...
we'll remove those discussions from the agenda, but look
forward to hearing about GRA's revival soon. If anyone
wants to just give a short talk about the plans, the chairs
are receptive...
>From owner-rmt@listserv.lbl.gov Mon Dec 4 11:39:33 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id LAA10911;
Mon, 4 Dec 2000 11:39:08 -0800 (PST)
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id LAA10907
for <rmt@listserv.lbl.gov>; Mon, 4 Dec 2000 11:39:06 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id LAA17351
for <rmt@listserv.lbl.gov>; Mon, 4 Dec 2000 11:39:05 -0800 (PST)
Received: from mail.webfountain.com (mail.webfountain.com [63.161.54.5])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id LAA17338
for <rmt@lbl.gov>; Mon, 4 Dec 2000 11:39:04 -0800 (PST)
Received: from leningrad (gate.webfountain.com [63.161.54.3])
by mail.webfountain.com (8.9.3/8.9.3) with SMTP id LAA24648;
Mon, 4 Dec 2000 11:38:50 -0800
X-Authentication-Warning: mail.webfountain.com: Host gate.webfountain.com [63.161.54.3] claimed to be leningrad
From: "Mike Luby" <luby@digitalfountain.com>
To: <mankin@east.isi.edu>
Cc: <lorenzo@cisco.com>, <roger.kermode@motorola.com>, <sob@harvard.edu>,
<rmt@lbl.gov>, "Mark Handley" <mjh@icsi.berkeley.edu>,
"Michael Luby" <luby@digitalfountain.com>
Subject: Some proposals for RMT Draft Agenda
Date: Mon, 4 Dec 2000 11:38:46 -0800
Message-ID: <NEBBIAPCNKEDCLPNFBNCAEHMCEAA.luby@digitalfountain.com>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Importance: Normal
In-Reply-To: <10012041859.AA28576@maia.east.isi.edu>
Sender: owner-rmt@lbl.gov
Precedence: bulk
Allison,
Yes, I should have figured that you were making sure to do this before some
deadline, and thanks for that.
I would be willing to give the general talk, as long as Luigi, Mark and
Lorenzo will work with me a bit before the meeting to structure the talk.
I'll work with them directly on this if they are willing. Given this, here
is my proposed portion of the agenda. I made estimates of the times for
each part (and I have less confidence in my time estimates for the
presentations with a time interval. Mark, Luigi, Lorenzo, please chip in
with your estimates.)
Presentation I: General overview (Luby, 20 minutes)
(1) Rationale for transition from ALC to LCT
(2) Rationale for FEC partitioned into standard track and information track
(and why this may be the right approach for all building blocks eventually).
(3) Rationale for transition from MRCC to LCC
(4) How all the pieces fit together
Presentation II: LCT00 changes from ALC01 (Rizzo, 15-20 minutes)
Presentation III: FECBB02 and FECInfo00 changes from FECBB01 (Vicisano,
10-15 minutes)
Presentation IV: LCC00 changes from MRCC00 (Luby, 5 minutes)
Mike
-----Original Message-----
From: Allison Mankin [mailto:mankin@isi.edu]
Sent: Monday, December 04, 2000 10:59 AM
To: Mike Luby
Cc: mankin@east.isi.edu; lorenzo@cisco.com; roger.kermode@motorola.com;
sob@harvard.edu; rmt@lbl.gov
Subject: Re: RMT Draft Agenda
Mike,
I have dropped agenda@ietf.org from the cc list. We can revise
the draft agenda later after we nail down all the details.
I jumped in and sent a slightly cleaned-up of Roger's tentative
agenda to the Secretariat, because of my AD instincts, wanting
RMT very much not to miss today's deadline.
In the likely absence of Mark, it sounds to me like you would be
a good person to speak to the reorg/rename. Please let
us know too how long the several talks you suggest should
be.
Other comments/corrections on the draft agenda are welcome.
Allison
>From owner-rmt@listserv.lbl.gov Mon Dec 4 11:55:26 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id LAA11043;
Mon, 4 Dec 2000 11:55:21 -0800 (PST)
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id LAA11039
for <rmt@listserv.lbl.gov>; Mon, 4 Dec 2000 11:55:19 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id LAA23639
for <rmt@listserv.lbl.gov>; Mon, 4 Dec 2000 11:55:18 -0800 (PST)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id LAA23629
for <rmt@lbl.gov>; Mon, 4 Dec 2000 11:55:17 -0800 (PST)
Received: from lorenzo-u10.cisco.com (lorenzo-u10.cisco.com [171.69.65.85])
by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id LAA16421;
Mon, 4 Dec 2000 11:54:17 -0800 (PST)
Received: from localhost (lorenzo@localhost) by lorenzo-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id LAA22188; Mon, 4 Dec 2000 11:54:16 -0800 (PST)
Message-Id: <200012041954.LAA22188@lorenzo-u10.cisco.com>
X-Authentication-Warning: lorenzo-u10.cisco.com: lorenzo owned process doing -bs
X-Mailer: exmh version 2.0.2 2/24/98
To: "Mike Luby" <luby@digitalfountain.com>
cc: mankin@east.isi.edu, roger.kermode@motorola.com, sob@harvard.edu,
rmt@lbl.gov, "Mark Handley" <mjh@icsi.berkeley.edu>
Subject: Re: Some proposals for RMT Draft Agenda
In-Reply-To: Your message of "Mon, 04 Dec 2000 11:38:46 PST."
<NEBBIAPCNKEDCLPNFBNCAEHMCEAA.luby@digitalfountain.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 04 Dec 2000 11:54:16 -0800
From: Lorenzo Vicisano <lorenzo@cisco.com>
Sender: owner-rmt@lbl.gov
Precedence: bulk
> I would be willing to give the general talk, as long as Luigi, Mark and
> Lorenzo will work with me a bit before the meeting to structure the talk.
> I'll work with them directly on this if they are willing. Given this, here
> is my proposed portion of the agenda. I made estimates of the times for
> each part (and I have less confidence in my time estimates for the
> presentations with a time interval. Mark, Luigi, Lorenzo, please chip in
> with your estimates.)
Mike,
your time estimates seem reasonable to me.
Lorenzo
>
> Presentation I: General overview (Luby, 20 minutes)
> (1) Rationale for transition from ALC to LCT
> (2) Rationale for FEC partitioned into standard track and information track
> (and why this may be the right approach for all building blocks eventually).
> (3) Rationale for transition from MRCC to LCC
> (4) How all the pieces fit together
>
> Presentation II: LCT00 changes from ALC01 (Rizzo, 15-20 minutes)
>
> Presentation III: FECBB02 and FECInfo00 changes from FECBB01 (Vicisano,
> 10-15 minutes)
>
> Presentation IV: LCC00 changes from MRCC00 (Luby, 5 minutes)
>
> Mike
>
>
> -----Original Message-----
> From: Allison Mankin [mailto:mankin@isi.edu]
> Sent: Monday, December 04, 2000 10:59 AM
> To: Mike Luby
> Cc: mankin@east.isi.edu; lorenzo@cisco.com; roger.kermode@motorola.com;
> sob@harvard.edu; rmt@lbl.gov
> Subject: Re: RMT Draft Agenda
>
>
> Mike,
>
> I have dropped agenda@ietf.org from the cc list. We can revise
> the draft agenda later after we nail down all the details.
>
> I jumped in and sent a slightly cleaned-up of Roger's tentative
> agenda to the Secretariat, because of my AD instincts, wanting
> RMT very much not to miss today's deadline.
>
> In the likely absence of Mark, it sounds to me like you would be
> a good person to speak to the reorg/rename. Please let
> us know too how long the several talks you suggest should
> be.
>
> Other comments/corrections on the draft agenda are welcome.
>
> Allison
>From owner-rmt@listserv.lbl.gov Sat Dec 9 10:11:38 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id KAA05026;
Sat, 9 Dec 2000 10:08:42 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id KAA05022
for <rmt@listserv.lbl.gov>; Sat, 9 Dec 2000 10:08:39 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id KAA11395
for <rmt@listserv.lbl.gov>; Sat, 9 Dec 2000 10:08:38 -0800 (PST)
Received: from nt1.rocori.k12.mn.us (nt1.rocori.k12.mn.us [207.229.251.2])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id KAA11392;
Sat, 9 Dec 2000 10:08:37 -0800 (PST)
Message-Id: <200012091808.KAA11392@SpamWall.lbl.gov>
From: Mail Sender<postmaster@rusgoods.ru>
To: rms46@geocities.com
CC: rms46@oke.com, rmt@lbl.gov, rmt-request@lbl.gov, rmwj@kc.net,
rmyers@dgexchange.dg.com
Subject: Russian Goods and Service from Moscow
Reply-To: mailsender@mailsender.ru
Date: 09.12.2000
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-rmt@lbl.gov
Precedence: bulk
www.rusgoods.com www.rusgoods.ru
================================================================
We present you the production of the 1-st Moscow Watch Factory "Poljot" (Flying). From the simple mechanical
watch of the series 2609 till unique, composite and precise mechanical o'clock - Marine timer .
It is unique factory in Russia, which makes mechanical hours with the Swiss quality. Factory, which makes
watches for the Russian Air Forces , Russian Naval Forces.
All mechanical watch which we offer to you, will be delivered to you directly from the factory. If it isn't in the
warehouse of the factory, we will place your order directly at the 1-st Moscow Watch Factory without any
middlemans.
The submarine "Kursk" had on board mechanical marine hronometr 6MX.
===============================================================
The "table" of orders. Here you can to order, to find, to know almost everything, than the Russia is rich,
everything
that does not contradict Russian Federation laws.
Here you can receive or order:
The information about any enterprise, firm, organization, or person in Russia
The production or any goods of Russian manufactories, and other things if it is possible.
===============================================================
www.rusgoods.com www.rusgoods.ru
>From owner-rmt@listserv.lbl.gov Sun Dec 10 22:12:14 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id WAA08010;
Sun, 10 Dec 2000 22:10:08 -0800 (PST)
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id WAA08006
for <rmt@listserv.lbl.gov>; Sun, 10 Dec 2000 22:10:03 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id WAA26397
for <rmt@listserv.lbl.gov>; Sun, 10 Dec 2000 22:10:02 -0800 (PST)
Received: from raq3.ndmc.net ([63.140.75.133])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id WAA26394;
Sun, 10 Dec 2000 22:10:01 -0800 (PST)
Received: (from mail@localhost)
by raq3.ndmc.net (8.9.3/8.9.3) id RAA07187
for suscribe2_site123-list; Sun, 10 Dec 2000 17:48:47 -0500
X-Authentication-Warning: raq3.ndmc.net: mail set sender to owner-suscribe2@www.allairporttransport.com using -f
Received: from mail.mailstart.com (mail.mailstart.com [207.231.76.67])
by raq3.ndmc.net (8.9.3/8.9.3) with ESMTP id RAA07173;
Sun, 10 Dec 2000 17:47:14 -0500
Received: from maroon [207.231.76.76] by mail.mailstart.com
(SMTPD32-5.05) id A785DAB500EE; Sun, 10 Dec 2000 14:45:25 -0800
To: suscribe@allairporttransport.com
CC: suscribe2@allairporttransport.com, advert@allairporttransport.com
From: advert@allairporttransport.com
Subject: Get listed on Allairporttransport.com
Message-Id: <101200345.53126@63.194.85.87>
Content-Type: TEXT/PLAIN; charset=US-ASCII
Date: Sun, 10 Dec 2000 14:45:27 -0800
Sender: owner-rmt@lbl.gov
Precedence: bulk
Get listed on Allairporttransport.com
http://www.allairporttransport.com
-----
Sent using MailStart.com ( http://MailStart.Com/welcome.html )
The FREE way to access your mailbox via any web browser, anywhere!
>From owner-rmt@listserv.lbl.gov Mon Dec 11 00:47:37 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id AAA08198;
Mon, 11 Dec 2000 00:47:12 -0800 (PST)
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id AAA08194
for <rmt@listserv.lbl.gov>; Mon, 11 Dec 2000 00:47:10 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id AAA05427
for <rmt@listserv.lbl.gov>; Mon, 11 Dec 2000 00:47:09 -0800 (PST)
Received: from raq3.ndmc.net ([63.140.75.133])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id AAA05421;
Mon, 11 Dec 2000 00:47:07 -0800 (PST)
Received: (from mail@localhost)
by raq3.ndmc.net (8.9.3/8.9.3) id WAA21017
for suscribe2_site123-list; Sun, 10 Dec 2000 22:05:45 -0500
X-Authentication-Warning: raq3.ndmc.net: mail set sender to owner-suscribe2@www.allairporttransport.com using -f
Received: from smartwall.v-one.com (firewall-user@smartwall.v-one.com [206.151.78.11])
by raq3.ndmc.net (8.9.3/8.9.3) with ESMTP id WAA21012;
Sun, 10 Dec 2000 22:04:35 -0500
Received: by smartwall.v-one.com; id WAA08691; Sun, 10 Dec 2000 22:36:27 -0500 (EST)
Received: from mail.v-one.com(198.69.135.122) by smartwall.v-one.com via smap (V4.2)
id xma008689; Sun, 10 Dec 00 22:36:26 -0500
Received: from v-one.com (firewall-user@smartwall.v-one.com [198.69.135.11])
by mail.v-one.com (8.9.3/8.8.7) with ESMTP id WAA24572;
Sun, 10 Dec 2000 22:01:22 -0500
Message-ID: <3A34448B.B4A8F4D0@v-one.com>
Date: Sun, 10 Dec 2000 22:05:48 -0500
From: Keith Young <kyoung@v-one.com>
Organization: V-ONE
X-Mailer: Mozilla 4.76 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
CC: advert@allairporttransport.com, suscribe2@allairporttransport.com
Subject: Re: allairporttransport
References: <101200345.53126@63.194.85.87> <006901c0630f$414257a0$e2ed68d5@laptop>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-rmt@lbl.gov
Precedence: bulk
What I want to know is who is the complete moron who had the reply to
address of a SPAM letter going to a Majordomo mailing list? Damn, I
guess only SPAMmers are *this* dumb.
By the way, if anyone wants to complain, info is below. Make sure to
contact the ISP (register.com). Also, for the sake of stopping this
mailing list, lets end the reply e-mails to the listserver e-mail
address now:
Organization:
American Airport Connection
Christopher Fagbolu
19990 Skywest Dr. Ste. 1121
Hayward, CA 94541
US
Phone: 510-732-6482
Fax..: 510-732-6947
Email: cofagb@airportconnection.net
Registrar Name....: Register.com
Registrar Whois...: whois.register.com
Registrar Homepage: http://www.register.com
> > Get listed on Allairporttransport.com
> >
> > http://www.allairporttransport.com
> >
> > -----
> > Sent using MailStart.com ( http://MailStart.Com/welcome.html )
> > The FREE way to access your mailbox via any web browser, anywhere!
By the way, this e-mail is by no means V-ONE official business and my
personal thoughts are not endorsed by my employer.
>From owner-rmt@listserv.lbl.gov Mon Dec 11 01:04:21 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id BAA08226;
Mon, 11 Dec 2000 01:04:16 -0800 (PST)
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id BAA08222
for <rmt@listserv.lbl.gov>; Mon, 11 Dec 2000 01:04:14 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id BAA06321
for <rmt@listserv.lbl.gov>; Mon, 11 Dec 2000 01:04:13 -0800 (PST)
Received: from raq3.ndmc.net ([63.140.75.133])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id BAA06318;
Mon, 11 Dec 2000 01:04:12 -0800 (PST)
Received: (from mail@localhost)
by raq3.ndmc.net (8.9.3/8.9.3) id VAA20025
for suscribe2_site123-list; Sun, 10 Dec 2000 21:48:29 -0500
X-Authentication-Warning: raq3.ndmc.net: mail set sender to owner-suscribe2@www.allairporttransport.com using -f
Received: from teapot27.domain5.bigpond.com (teapot27.domain5.bigpond.com [139.134.5.174])
by raq3.ndmc.net (8.9.3/8.9.3) with SMTP id VAA20017
for <suscribe2@allairporttransport.com>; Sun, 10 Dec 2000 21:47:17 -0500
Received: from localhost (localhost [127.0.0.1]) by teapot27.domain5.bigpond.com (NTMail 3.02.13) with ESMTP id ja418791 for <suscribe2@allairporttransport.com>; Mon, 11 Dec 2000 12:44:50 +1000
Received: from DC-72-188.bpb.bigpond.com ([203.40.72.188]) by mail5.bigpond.com (Claudes-Volcanic-MailRouter V2.9c 9/310865); 11 Dec 2000 12:44:49
Message-ID: <002701c062b8$69974640$bc4828cb@tim>
Reply-To: " Tim Kleinig - Thrifty Car Rental" <werentcars@bigpond.com>
From: " Tim Kleinig - Thrifty Car Rental" <werentcars@bigpond.com>
To: "Lefkas2000" <mail@lefkas2000.com>, <advert@allairporttransport.com>
Cc: <suscribe2@allairporttransport.com>
References: <101200345.53126@63.194.85.87> <006901c0630f$414257a0$e2ed68d5@laptop>
Subject: Re: UNSUBSCRIBE ME FROM YOUR MAILING LIST
Date: Mon, 11 Dec 2000 00:49:33 +1000
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6600
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Sender: owner-rmt@lbl.gov
Precedence: bulk
>From owner-rmt@listserv.lbl.gov Mon Dec 11 01:48:52 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id BAA08272;
Mon, 11 Dec 2000 01:48:27 -0800 (PST)
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id BAA08268
for <rmt@listserv.lbl.gov>; Mon, 11 Dec 2000 01:48:25 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id BAA08926
for <rmt@listserv.lbl.gov>; Mon, 11 Dec 2000 01:48:25 -0800 (PST)
Received: from raq3.ndmc.net ([63.140.75.133])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id BAA08923;
Mon, 11 Dec 2000 01:48:24 -0800 (PST)
Received: (from mail@localhost)
by raq3.ndmc.net (8.9.3/8.9.3) id WAA21396
for suscribe2_site123-list; Sun, 10 Dec 2000 22:12:19 -0500
X-Authentication-Warning: raq3.ndmc.net: mail set sender to owner-suscribe2@www.allairporttransport.com using -f
Received: from chico.rediris.es (chico.rediris.es [130.206.1.3])
by raq3.ndmc.net (8.9.3/8.9.3) with ESMTP id WAA21392
for <suscribe2@ALLAIRPORTTRANSPORT.COM>; Sun, 10 Dec 2000 22:11:09 -0500
Message-Id: <200012110311.WAA21392@raq3.ndmc.net>
Received: from chico.rediris.es (130.206.1.3) by chico.rediris.es (LSMTP for Solaris v1.1b) with SMTP id <4.000A568F@chico.rediris.es>; Mon, 11 Dec 2000 4:09:21 +0100
Date: Mon, 11 Dec 2000 04:09:21 +0100
From: "L-Soft list server at LISTSERV.REDIRIS.ES (1.8d)" <LISTSERV@LISTSERV.REDIRIS.ES>
Subject: Message ("Your message dated Sun, 10 Dec 2000 17:48:47...")
To: suscribe2@allairporttransport.com
Sender: owner-rmt@lbl.gov
Precedence: bulk
Your message dated Sun, 10 Dec 2000 17:48:47 -0500 with subject "Get listed
on Allairporttransport.com" has been submitted to the moderator of the
MBONE-ES list: Pedro Ruiz <pedro.ruiz@REDIRIS.ES>.
>From owner-rmt@listserv.lbl.gov Mon Dec 11 03:04:29 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id DAA08364;
Mon, 11 Dec 2000 03:04:03 -0800 (PST)
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id DAA08360
for <rmt@listserv.lbl.gov>; Mon, 11 Dec 2000 03:03:57 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id DAA14064
for <rmt@listserv.lbl.gov>; Mon, 11 Dec 2000 03:03:57 -0800 (PST)
Received: from raq3.ndmc.net ([63.140.75.133])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id DAA14054;
Mon, 11 Dec 2000 03:03:48 -0800 (PST)
Received: (from mail@localhost)
by raq3.ndmc.net (8.9.3/8.9.3) id XAA26919
for suscribe2_site123-list; Sun, 10 Dec 2000 23:45:38 -0500
X-Authentication-Warning: raq3.ndmc.net: mail set sender to owner-suscribe2@www.allairporttransport.com using -f
Received: from webzilla.weblife.net ([63.99.222.120])
by raq3.ndmc.net (8.9.3/8.9.3) with ESMTP id XAA26915
for <suscribe2@www.allairporttransport.com>; Sun, 10 Dec 2000 23:44:53 -0500
Received: from [24.17.130.126] by webzilla.weblife.net
(Post.Office MTA v3.1.2 release (PO205-101c)
ID# 0-48626U1000L100S0) with SMTP id AAA2557
for <suscribe2@www.allairporttransport.com>;
Sun, 10 Dec 2000 22:47:46 -0600
Date: 10 Dec 2000 22:43:08 -0600
Message-ID: <-1235634310mellard@weblifepro.com>
From: James Mellard <mellard@weblifepro.com>
Subject: Re: UNSUBSCRIBE ME FROM YOUR MAILING LIST
To: <suscribe2@allairporttransport.com>
X-Mailer: QuickMail Pro 2.0.4 (Mac)
X-Priority: 3
MIME-Version: 1.0
Reply-To: James Mellard <mellard@weblifepro.com>
Content-Type: text/plain; charset="US-Ascii"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by SpamWall.lbl.gov id DAA08361
Sender: owner-rmt@lbl.gov
Precedence: bulk
On Sunday, December 10, 2000, Lefkas2000 <mail@lefkas2000.com> wrote:
>
>
>www.lefkas2000.com
>THE Guide to Lefkas
>----- Original Message -----
>From: <advert@allairporttransport.com>
>To: <suscribe@allairporttransport.com>
>Cc: <suscribe2@allairporttransport.com>; <advert@allairporttransport.com>
>Sent: Sunday, December 10, 2000 10:45 PM
>Subject: Get listed on Allairporttransport.com
>
>
>>
>>
>> Get listed on Allairporttransport.com
>>
>> http://www.allairporttransport.com
>>
>> -----
>> Sent using MailStart.com ( http://MailStart.Com/welcome.html )
>> The FREE way to access your mailbox via any web browser,
>anywhere!
>>
>>
>
>From owner-rmt@listserv.lbl.gov Mon Dec 11 03:38:39 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id DAA08392;
Mon, 11 Dec 2000 03:38:18 -0800 (PST)
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id DAA08388
for <rmt@listserv.lbl.gov>; Mon, 11 Dec 2000 03:38:16 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id DAA15356
for <rmt@listserv.lbl.gov>; Mon, 11 Dec 2000 03:38:15 -0800 (PST)
Received: from raq3.ndmc.net ([63.140.75.133])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id DAA15353;
Mon, 11 Dec 2000 03:38:14 -0800 (PST)
Received: (from mail@localhost)
by raq3.ndmc.net (8.9.3/8.9.3) id AAA28368
for suscribe2_site123-list; Mon, 11 Dec 2000 00:10:01 -0500
X-Authentication-Warning: raq3.ndmc.net: mail set sender to owner-suscribe2@www.allairporttransport.com using -f
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
by raq3.ndmc.net (8.9.3/8.9.3) with ESMTP id AAA28363
for <suscribe2@ALLAIRPORTTRANSPORT.COM>; Mon, 11 Dec 2000 00:08:50 -0500
From: www-lib-request@w3.org
Received: by www19.w3.org (8.9.0/8.9.0) id AAA12045;
Mon, 11 Dec 2000 00:06:48 -0500 (EST)
Date: Mon, 11 Dec 2000 00:06:48 -0500 (EST)
Message-Id: <200012110506.AAA12045@www19.w3.org>
To: suscribe2@allairporttransport.com
Subject: Re: Message ("Your message dated Sun, 10 Dec 2000 17:48:47...")
References: <200012110311.WAA21392@raq3.ndmc.net>
In-Reply-To: <200012110311.WAA21392@raq3.ndmc.net>
X-Loop: www-lib@w3.org
Sender: owner-rmt@lbl.gov
Precedence: bulk
******* www-lib@w3.org *******
This is the public mailing list for discussion about the W3C reference
library of common code (a.k.a. libwww). This is the proper location
for discussing bug reports, patches, enhancements, and public
contributions to libwww.
******* About the W3C Mailing Lists *******
There are many mailing lists provided by the W3C for discussion
and development on the World Wide Web. A full list of them
is available at:
http://www.w3.org/Mail/Lists.html
NOTE that this list is not the place for any of the following:
How do I configure [insert-favorite-software-here]?
I'm new to the web -- what is it?
I tried to ask [insert-company-here] customer support, but
[I didn't get any response / they told me to RTFM]
What does RTFM mean?
Answers to the above are often found in the WWW FAQ maintained
by Thomas Boutell. The FAQ is available from several sites.
Use the mirror closest to you:
Sunsite, eastern United States (North America):
http://sunsite.unc.edu/boutell/faq/
Internex Online, Montreal, eastern Canada (North America):
http://www.io.org/faq/www/index.html
New Software Technologies Service, Austria (Europe):
http://nswt.tuwien.ac.at:8000/htdocs/boutell/
Glocom, Japan (Asia):
http://www1.glocom.ac.jp/mirror/www.boutell.com/faq/index.htm
The FAQ also lists the names of all the USENET newsgroups that are
available regarding the WWW (most under the comp.infosystems.www.*
hierarchy).
******* Administrative Requests *******
The -request mail address should be used for all list administrative
requests. It accepts the following commands (in the Subject of an
e-mail message):
subscribe -- Subscribe to the list. If you want to subscribe
under a different address, use a Reply-To: address
header in the message.
unsubscribe -- Unsubscribe from the list.
help -- Get information about the mailing list.
archive help -- Get information about the list archive(s).
In the event of an address change, it would probably be wisest to first
send an unsubscribe for the old address (this can be done from the new
address), and then a new subscribe from the new address (the order is
important).
Most (un)subscription requests are processed automatically without human
intervention. Do not send multiple (un)subscription or info requests in
one mail. Only one will be processed per mail.
NOTE: The -request server usually does quite a good job in discriminating
between (un)subscribe requests and messages intended for the
maintainer. If you'd like to make sure a human reads your message,
make it look like a reply (i.e. the first word in the Subject: field
should be "Re:", without the quotes of course); the -request server
does not react to replies.
******* Archive Server *******
Every submission sent to this list is archived. Archives of public
lists are available at URL:
http://lists.w3.org/Archives/Public/
If you want to access this archive by e-mail, you have to send mail
to the -request address with the word "archive" as the first word of
your Subject:. To get you started, try sending a mail to the -request
address with the following:
Subject: archive help
Rev. 18/Jul/97 -JK
=================================================================
>From owner-rmt@listserv.lbl.gov Mon Dec 11 04:59:18 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id EAA08446;
Mon, 11 Dec 2000 04:58:23 -0800 (PST)
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id EAA08442
for <rmt@listserv.lbl.gov>; Mon, 11 Dec 2000 04:58:21 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id EAA20295
for <rmt@listserv.lbl.gov>; Mon, 11 Dec 2000 04:58:21 -0800 (PST)
Received: from raq3.ndmc.net ([63.140.75.133])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id EAA20292;
Mon, 11 Dec 2000 04:58:19 -0800 (PST)
Received: (from mail@localhost)
by raq3.ndmc.net (8.9.3/8.9.3) id BAA32270
for suscribe2_site123-list; Mon, 11 Dec 2000 01:15:37 -0500
X-Authentication-Warning: raq3.ndmc.net: mail set sender to owner-suscribe2@www.allairporttransport.com using -f
Received: from chico.rediris.es (chico.rediris.es [130.206.1.3])
by raq3.ndmc.net (8.9.3/8.9.3) with ESMTP id BAA32263
for <suscribe2@ALLAIRPORTTRANSPORT.COM>; Mon, 11 Dec 2000 01:14:42 -0500
Message-Id: <200012110614.BAA32263@raq3.ndmc.net>
Received: from chico.rediris.es (130.206.1.3) by chico.rediris.es (LSMTP for Solaris v1.1b) with SMTP id <1.000A56C1@chico.rediris.es>; Mon, 11 Dec 2000 7:12:56 +0100
Date: Mon, 11 Dec 2000 07:12:56 +0100
From: "L-Soft list server at LISTSERV.REDIRIS.ES (1.8d)" <LISTSERV@LISTSERV.REDIRIS.ES>
Subject: Message ("Your message dated Sun, 10 Dec 2000 22:05:45...")
To: suscribe2@allairporttransport.com
Sender: owner-rmt@lbl.gov
Precedence: bulk
Your message dated Sun, 10 Dec 2000 22:05:45 -0500 with subject "Re:
allairporttransport" has been submitted to the moderator of the MBONE-ES
list: Pedro Ruiz <pedro.ruiz@REDIRIS.ES>.
>From owner-rmt@listserv.lbl.gov Mon Dec 11 09:08:16 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id JAA10012;
Mon, 11 Dec 2000 09:07:41 -0800 (PST)
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id JAA10008
for <rmt@listserv.lbl.gov>; Mon, 11 Dec 2000 09:07:39 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id JAA03982
for <rmt@listserv.lbl.gov>; Mon, 11 Dec 2000 09:07:38 -0800 (PST)
Received: from raq3.ndmc.net ([63.140.75.133])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id JAA03948;
Mon, 11 Dec 2000 09:07:30 -0800 (PST)
Received: (from mail@localhost)
by raq3.ndmc.net (8.9.3/8.9.3) id FAA15770
for suscribe2_site123-list; Mon, 11 Dec 2000 05:47:16 -0500
X-Authentication-Warning: raq3.ndmc.net: mail set sender to owner-suscribe2@www.allairporttransport.com using -f
Received: from fep13-svc.tin.it (mta13-acc.tin.it [212.216.176.44])
by raq3.ndmc.net (8.9.3/8.9.3) with ESMTP id FAA15694;
Mon, 11 Dec 2000 05:44:54 -0500
Received: from exodus ([212.216.163.234]) by fep13-svc.tin.it
(InterMail vM.4.01.02.39 201-229-119-122) with SMTP
id <20001211104238.NTY1148.fep13-svc.tin.it@exodus>;
Mon, 11 Dec 2000 11:42:38 +0100
Message-ID: <00c501c0635f$1046eb20$1556fea9@exodus>
From: "Roman Homes - Dr. Mauro Abate" <info@romanhomes.com>
To: <suscribe@allairporttransport.com>, <advert@allairporttransport.com>
Cc: <suscribe2@allairporttransport.com>, <advert@allairporttransport.com>
References: <101200345.53126@63.194.85.87> <00a201c06358$7c3083c0$1556fea9@exodus>
Subject: Re: REMOVE ME FROM YOUR MAILING LIST Re: Get listed on Allairporttransport.com
Date: Mon, 11 Dec 2000 11:42:23 +0100
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Sender: owner-rmt@lbl.gov
Precedence: bulk
Please reply with the "reply to" button, or by copying/pasting if you are an
AOL user, necessary for us to keep track of the dialogue between us, without
being lost to find it among 1000s messages. Thank you.
_______________
Dear Sir / Madam
Thank you for your consideration and welcome to Roman Homes.
Kind regards,
Dr. Mauro Abate,
Roman Homes®
http://www.romanhomes.com
http://www.romanholidays.com
Your carefree Roman rental
When in Rome, stay in homes as the Romans do!®
----- Original Message -----
From: Roman Homes - Dr. Mauro Abate <info@romanhomes.com>
To: <suscribe@allairporttransport.com>; <advert@allairporttransport.com>
Cc: <suscribe2@allairporttransport.com>; <advert@allairporttransport.com>
Sent: Monday, December 11, 2000 6:54 AM
Subject: REMOVE ME FROM YOUR MAILING LIST Re: Get listed on
Allairporttransport.com
Please reply with the "reply to" button, or by copying/pasting if you are an
AOL user, necessary for us to keep track of the dialogue between us, without
being lost to find it among 1000s messages. Thank you.
_______________
Dear Sir / Madam,
PLEASE REMOVE ME FROM YOUR MAILING LIST.
I AM HAVING STRANGE MESSAGES FROM YOUR OR YOUR CUSTOMERS. MAKE SURE THEY
DON'T ARRIVE ANYMORE. Thank you.
Regards,
Dr. Mauro Abate,
Roman Homes®
http://www.romanhomes.com
http://www.romanholidays.com
Your carefree Roman rental
When in Rome, stay in homes as the Romans do!®
----- Original Message -----
From: <advert@allairporttransport.com>
To: <suscribe@allairporttransport.com>
Cc: <suscribe2@allairporttransport.com>; <advert@allairporttransport.com>
Sent: Sunday, December 10, 2000 11:45 PM
Subject: Get listed on Allairporttransport.com
>
>
> Get listed on Allairporttransport.com
>
> http://www.allairporttransport.com
>
> -----
> Sent using MailStart.com ( http://MailStart.Com/welcome.html )
> The FREE way to access your mailbox via any web browser, anywhere!
>
>
>From owner-rmt@listserv.lbl.gov Mon Dec 11 09:13:09 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id JAA10077;
Mon, 11 Dec 2000 09:12:59 -0800 (PST)
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id JAA10073
for <rmt@listserv.lbl.gov>; Mon, 11 Dec 2000 09:12:57 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id JAA05816
for <rmt@listserv.lbl.gov>; Mon, 11 Dec 2000 09:12:56 -0800 (PST)
Received: from raq3.ndmc.net ([63.140.75.133])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id JAA05806;
Mon, 11 Dec 2000 09:12:54 -0800 (PST)
Received: (from mail@localhost)
by raq3.ndmc.net (8.9.3/8.9.3) id EAA13191
for suscribe2_site123-list; Mon, 11 Dec 2000 04:59:55 -0500
X-Authentication-Warning: raq3.ndmc.net: mail set sender to owner-suscribe2@www.allairporttransport.com using -f
Received: from fep13-svc.tin.it (mta13-acc.tin.it [212.216.176.44])
by raq3.ndmc.net (8.9.3/8.9.3) with ESMTP id EAA13107;
Mon, 11 Dec 2000 04:57:30 -0500
Received: from exodus ([212.216.163.234]) by fep13-svc.tin.it
(InterMail vM.4.01.02.39 201-229-119-122) with SMTP
id <20001211095541.HVM1148.fep13-svc.tin.it@exodus>;
Mon, 11 Dec 2000 10:55:41 +0100
Message-ID: <00a501c06358$8176eae0$1556fea9@exodus>
From: "Roman Homes - Dr. Mauro Abate" <info@romanhomes.com>
To: <suscribe@allairporttransport.com>, <advert@allairporttransport.com>
Cc: <suscribe2@allairporttransport.com>, <advert@allairporttransport.com>
References: <101200345.53126@63.194.85.87>
Subject: REMOVE ME FROM YOUR MAILING LIST Re: Get listed on Allairporttransport.com
Date: Mon, 11 Dec 2000 06:54:22 +0100
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Sender: owner-rmt@lbl.gov
Precedence: bulk
Please reply with the "reply to" button, or by copying/pasting if you are an
AOL user, necessary for us to keep track of the dialogue between us, without
being lost to find it among 1000s messages. Thank you.
_______________
Dear Sir / Madam,
PLEASE REMOVE ME FROM YOUR MAILING LIST.
I AM HAVING STRANGE MESSAGES FROM YOUR OR YOUR CUSTOMERS. MAKE SURE THEY
DON'T ARRIVE ANYMORE. Thank you.
Regards,
Dr. Mauro Abate,
Roman Homes®
http://www.romanhomes.com
http://www.romanholidays.com
Your carefree Roman rental
When in Rome, stay in homes as the Romans do!®
----- Original Message -----
From: <advert@allairporttransport.com>
To: <suscribe@allairporttransport.com>
Cc: <suscribe2@allairporttransport.com>; <advert@allairporttransport.com>
Sent: Sunday, December 10, 2000 11:45 PM
Subject: Get listed on Allairporttransport.com
>
>
> Get listed on Allairporttransport.com
>
> http://www.allairporttransport.com
>
> -----
> Sent using MailStart.com ( http://MailStart.Com/welcome.html )
> The FREE way to access your mailbox via any web browser, anywhere!
>
>
>From owner-rmt@listserv.lbl.gov Mon Dec 11 09:38:11 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id JAA10101;
Mon, 11 Dec 2000 09:37:51 -0800 (PST)
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id JAA10097
for <rmt@listserv.lbl.gov>; Mon, 11 Dec 2000 09:37:49 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id JAA16272
for <rmt@listserv.lbl.gov>; Mon, 11 Dec 2000 09:37:49 -0800 (PST)
Received: from raq3.ndmc.net ([63.140.75.133])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id JAA16269;
Mon, 11 Dec 2000 09:37:48 -0800 (PST)
Received: (from mail@localhost)
by raq3.ndmc.net (8.9.3/8.9.3) id EAA13198
for suscribe2_site123-list; Mon, 11 Dec 2000 04:59:57 -0500
X-Authentication-Warning: raq3.ndmc.net: mail set sender to owner-suscribe2@www.allairporttransport.com using -f
Received: from fep13-svc.tin.it (mta13-acc.tin.it [212.216.176.44])
by raq3.ndmc.net (8.9.3/8.9.3) with ESMTP id EAA13134;
Mon, 11 Dec 2000 04:57:49 -0500
Received: from exodus ([212.216.163.234]) by fep13-svc.tin.it
(InterMail vM.4.01.02.39 201-229-119-122) with SMTP
id <20001211095533.HUX1148.fep13-svc.tin.it@exodus>;
Mon, 11 Dec 2000 10:55:33 +0100
Message-ID: <00a201c06358$7c3083c0$1556fea9@exodus>
From: "Roman Homes - Dr. Mauro Abate" <info@romanhomes.com>
To: <suscribe@allairporttransport.com>, <advert@allairporttransport.com>
Cc: <suscribe2@allairporttransport.com>, <advert@allairporttransport.com>
References: <101200345.53126@63.194.85.87>
Subject: REMOVE ME FROM YOUR MAILING LIST Re: Get listed on Allairporttransport.com
Date: Mon, 11 Dec 2000 06:54:22 +0100
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Sender: owner-rmt@lbl.gov
Precedence: bulk
Please reply with the "reply to" button, or by copying/pasting if you are an
AOL user, necessary for us to keep track of the dialogue between us, without
being lost to find it among 1000s messages. Thank you.
_______________
Dear Sir / Madam,
PLEASE REMOVE ME FROM YOUR MAILING LIST.
I AM HAVING STRANGE MESSAGES FROM YOUR OR YOUR CUSTOMERS. MAKE SURE THEY
DON'T ARRIVE ANYMORE. Thank you.
Regards,
Dr. Mauro Abate,
Roman Homes®
http://www.romanhomes.com
http://www.romanholidays.com
Your carefree Roman rental
When in Rome, stay in homes as the Romans do!®
----- Original Message -----
From: <advert@allairporttransport.com>
To: <suscribe@allairporttransport.com>
Cc: <suscribe2@allairporttransport.com>; <advert@allairporttransport.com>
Sent: Sunday, December 10, 2000 11:45 PM
Subject: Get listed on Allairporttransport.com
>
>
> Get listed on Allairporttransport.com
>
> http://www.allairporttransport.com
>
> -----
> Sent using MailStart.com ( http://MailStart.Com/welcome.html )
> The FREE way to access your mailbox via any web browser, anywhere!
>
>
>From owner-rmt@listserv.lbl.gov Mon Dec 11 09:59:32 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id JAA10180;
Mon, 11 Dec 2000 09:59:05 -0800 (PST)
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id JAA10176
for <rmt@listserv.lbl.gov>; Mon, 11 Dec 2000 09:59:03 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id JAA26396
for <rmt@listserv.lbl.gov>; Mon, 11 Dec 2000 09:59:03 -0800 (PST)
Received: from raq3.ndmc.net ([63.140.75.133])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id JAA26388;
Mon, 11 Dec 2000 09:59:02 -0800 (PST)
Received: (from mail@localhost)
by raq3.ndmc.net (8.9.3/8.9.3) id GAA18042
for suscribe2_site123-list; Mon, 11 Dec 2000 06:28:25 -0500
X-Authentication-Warning: raq3.ndmc.net: mail set sender to owner-suscribe2@www.allairporttransport.com using -f
Received: from cmailg3.svr.pol.co.uk (cmailg3.svr.pol.co.uk [195.92.195.173])
by raq3.ndmc.net (8.9.3/8.9.3) with ESMTP id GAA17985;
Mon, 11 Dec 2000 06:26:16 -0500
Received: from modem-76.beryllium.dialup.pol.co.uk ([62.136.3.76] helo=alan)
by cmailg3.svr.pol.co.uk with smtp (Exim 3.13 #0)
id 145R4H-0002kV-00; Mon, 11 Dec 2000 11:24:30 +0000
Message-ID: <002501c06364$fd5724c0$4c03883e@alan>
From: "Russian Gateway (UK) Limited" <travel@russiangateway.fsnet.co.uk>
To: <suscribe@allairporttransport.com>, <advert@allairporttransport.com>,
<suscribe2@allairporttransport.com>
Subject: REMOVE FROM LIST
Date: Mon, 11 Dec 2000 11:24:53 -0000
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_0022_01C06364.FB8A5400"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.1
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: owner-rmt@lbl.gov
Precedence: bulk
This is a multi-part message in MIME format.
------=_NextPart_000_0022_01C06364.FB8A5400
Content-Type: text/plain;
charset="koi8-r"
Content-Transfer-Encoding: quoted-printable
Remove from mailing list immediately
------=_NextPart_000_0022_01C06364.FB8A5400
Content-Type: text/html;
charset="koi8-r"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Dwindows-1251" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR></HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2>Remove from mailing list=20
immediately</FONT></DIV></BODY></HTML>
------=_NextPart_000_0022_01C06364.FB8A5400--
>From owner-rmt@listserv.lbl.gov Mon Dec 11 09:59:35 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id JAA10186;
Mon, 11 Dec 2000 09:59:27 -0800 (PST)
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id JAA10182
for <rmt@listserv.lbl.gov>; Mon, 11 Dec 2000 09:59:25 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id JAA26486
for <rmt@listserv.lbl.gov>; Mon, 11 Dec 2000 09:59:20 -0800 (PST)
Received: from raq3.ndmc.net ([63.140.75.133])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id JAA26482;
Mon, 11 Dec 2000 09:59:19 -0800 (PST)
Received: (from mail@localhost)
by raq3.ndmc.net (8.9.3/8.9.3) id GAA19583
for suscribe2_site123-list; Mon, 11 Dec 2000 06:56:06 -0500
X-Authentication-Warning: raq3.ndmc.net: mail set sender to owner-suscribe2@www.allairporttransport.com using -f
Received: from mail1.band-x.net (mail1.band-x.net [213.166.0.230])
by raq3.ndmc.net (8.9.3/8.9.3) with ESMTP id GAA19579
for <suscribe2@ALLAIRPORTTRANSPORT.COM>; Mon, 11 Dec 2000 06:54:54 -0500
Received: from chesterton.co.uk (fwuser@[213.166.16.2])
by mail1.band-x.net (8.9.3/8.9.3) with SMTP id LAA05295
for <suscribe2@ALLAIRPORTTRANSPORT.COM>; Mon, 11 Dec 2000 11:53:09 GMT
Received: from London-Message_Server by chesterton.co.uk
with Novell_GroupWise; Mon, 11 Dec 2000 11:52:42 +0000
Message-Id: <sa34c00a.024@chesterton.co.uk>
X-Mailer: Novell GroupWise 5.5
Date: Mon, 11 Dec 2000 11:52:11 +0000
From: "Andrew Hartwright" <Andrew.Hartwright@chesterton.co.uk>
To: <suscribe2@allairporttransport.com>, <LISTSERV@LISTSERV.REDIRIS.ES>
Subject: Re: Message ("Your message dated Sun, 10 Dec 2000
17:48:47...")
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by SpamWall.lbl.gov id JAA10183
Sender: owner-rmt@lbl.gov
Precedence: bulk
I do not know what this about DO NOT include me in future emails
>>> "L-Soft list server at LISTSERV.REDIRIS.ES (1.8d)" <LISTSERV@LISTSERV.REDIRIS.ES> 12/11/00 03:12am >>>
Your message dated Sun, 10 Dec 2000 17:48:47 -0500 with subject "Get listed
on Allairporttransport.com" has been submitted to the moderator of the
MBONE-ES list: Pedro Ruiz <pedro.ruiz@REDIRIS.ES>.
_____________________________________________________________________
This message has been checked for all known viruses by the
MessageLabs Virus Control Centre. For further information visit
http://www.messagelabs.com/stats.asp
>From owner-rmt@listserv.lbl.gov Mon Dec 11 12:45:20 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id MAA10901;
Mon, 11 Dec 2000 12:44:06 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id MAA10897
for <rmt@listserv.lbl.gov>; Mon, 11 Dec 2000 12:44:05 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id MAA01867
for <rmt@listserv.lbl.gov>; Mon, 11 Dec 2000 12:44:04 -0800 (PST)
Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id MAA01864
for <rmt@lbl.gov>; Mon, 11 Dec 2000 12:44:03 -0800 (PST)
Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id NAA06632 for <rmt@lbl.gov>; Mon, 11 Dec 2000 13:44:03 -0700 (MST)]
Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [217.1.10.38]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id NAA25850 for <rmt@lbl.gov>; Mon, 11 Dec 2000 13:44:01 -0700 (MST)]
Received: from motorola.com ([217.2.31.177])
by homer.arc.corp.mot.com (8.10.2/8.10.2) with ESMTP id eBBKgRS28241
for <rmt@lbl.gov>; Tue, 12 Dec 2000 07:42:28 +1100 (EST)
Message-ID: <3A353B81.DD1F651C@motorola.com>
Date: Tue, 12 Dec 2000 07:39:29 +1100
From: Roger Kermode <Roger.Kermode@motorola.com>
Organization: Motorola Australia Research Centre
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: rmt-list <rmt@lbl.gov>
Subject: 49th IETF San Diego RMT Agenda
Content-Type: multipart/mixed;
boundary="------------4EC31ADEE849A429FEBE71F0"
Sender: owner-rmt@lbl.gov
Precedence: bulk
This is a multi-part message in MIME format.
--------------4EC31ADEE849A429FEBE71F0
Content-Type: multipart/alternative;
boundary="------------8384C1389277A83E861463E7"
--------------8384C1389277A83E861463E7
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Here it *finally* is....
Roger
RMT Agenda
49th IETF, San Diego
====================
Monday 19:30 - 22:00
Agenda Bashing [Roger] 19:30 - 09:40 10 mins
Advertisement of MSEC BOF [Roger] 19:40 - 19:42 3 mins
Apology regarding discussion of TFRC in TSVWG
[Roger] 19:42 - 19:45 2 mins
Updates [Kermode] 19:45 - 19:50 5 mins
<draft-ietf-rmt-buildingblocks-03.txt>
<draft-ietf-rmt-author-guidelines-00.txt>
NORM reorganisation [Brain/Joe]
<draft-ietf-rmt-pi-norm-00.txt> 19:50 - 20:20 30 mins
Security Considerations for NORM [Thomas] 20:20 - 20:30 10 mins
Layered Coding Transport (was ALC) drafts
[Lorenzo/Mike/Luigi] 20:30 - 21:20 50 mins
Overview of structural reorganization
<draft-ietf-rmt-bb-lct-00.txt>, <draft-ietf-rmt-info-fec-02.txt>
<draft-ietf-rmt-bb-fec-02.txt>, <draft-ietf-rmt-bb-lcc-00.txt>
TRACK [Whetten/Chiu] 21:20 - 22:00 40 mins
<draft-ietf-rmt-bb-track-00.txt>,
<draft-ietf-rmt-bb-tree-config-01.txt>
Tuesday 13:00 - 14:00
=====================
Building Blocks Registry Discussion [Roger] 13:00 - 13:10 10
mins
TFRC discussion [Sally Floyd/Jitendra Padhye] 13:10 - 13:30 20
mins
GRA/PGM Cattle Prod [Roger/Tony] 13:30 - 13:35 5
mins
Newly issued PGM draft - plan?
Individual drafts (not in charter)
<draft-petrova-pgmmib-00.txt> [Michael Garwood] 13:50 - 14:00 10
mins
<draft-calvert-concast-svc-00.txt> [Ken Calvert] 13:35 - 13:50 15
mins
--------------8384C1389277A83E861463E7
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<tt>Here it *finally* is....</tt><tt></tt>
<p><tt>Roger</tt>
<br><tt></tt> <tt></tt>
<p><tt>RMT Agenda</tt>
<br><tt>49th IETF, San Diego</tt>
<br><tt>====================</tt><tt></tt>
<p><tt>Monday 19:30 - 22:00</tt>
<br><tt> Agenda Bashing [Roger]
19:30 - 09:40 10 mins</tt>
<br><tt> Advertisement of MSEC BOF [Roger]
19:40 - 19:42 3 mins</tt>
<br><tt> Apology regarding discussion of TFRC in TSVWG</tt>
<br><tt>
[Roger] 19:42 - 19:45 2 mins</tt><tt></tt>
<p><tt>Updates [Kermode]
19:45 - 19:50 5 mins</tt>
<br><tt> <draft-ietf-rmt-buildingblocks-03.txt></tt>
<br><tt> <draft-ietf-rmt-author-guidelines-00.txt></tt><tt></tt>
<p><tt>NORM reorganisation [Brain/Joe]</tt>
<br><tt> <draft-ietf-rmt-pi-norm-00.txt>
19:50 - 20:20 30 mins</tt>
<br><tt> Security Considerations for NORM [Thomas] 20:20 - 20:30
10 mins</tt><tt></tt>
<p><tt>Layered Coding Transport (was ALC) drafts</tt>
<br><tt> [Lorenzo/Mike/Luigi]
20:30 - 21:20 50 mins</tt>
<br><tt> Overview of structural reorganization</tt>
<br><tt> <draft-ietf-rmt-bb-lct-00.txt>, <draft-ietf-rmt-info-fec-02.txt></tt>
<br><tt> <draft-ietf-rmt-bb-fec-02.txt>, <draft-ietf-rmt-bb-lcc-00.txt></tt><tt></tt>
<p><tt>TRACK [Whetten/Chiu]
21:20 - 22:00 40 mins</tt>
<br><tt> <draft-ietf-rmt-bb-track-00.txt>,</tt>
<br><tt> <draft-ietf-rmt-bb-tree-config-01.txt></tt>
<br><tt></tt> <tt></tt>
<p><tt>Tuesday 13:00 - 14:00</tt>
<br><tt>=====================</tt>
<br><tt>Building Blocks Registry Discussion [Roger]
13:00 - 13:10 10 mins</tt><tt></tt>
<p><tt>TFRC discussion [Sally Floyd/Jitendra Padhye]
13:10 - 13:30 20 mins</tt><tt></tt>
<p><tt>GRA/PGM Cattle Prod [Roger/Tony]
13:30 - 13:35 5 mins</tt>
<br><tt> Newly issued PGM draft - plan?</tt><tt></tt>
<p><tt>Individual drafts (not in charter)</tt>
<br><tt> <draft-petrova-pgmmib-00.txt> [Michael Garwood]
13:50 - 14:00 10 mins</tt>
<br><tt> <draft-calvert-concast-svc-00.txt> [Ken Calvert] 13:35
- 13:50 15 mins</tt></html>
--------------8384C1389277A83E861463E7--
--------------4EC31ADEE849A429FEBE71F0
Content-Type: text/x-vcard; charset=us-ascii;
name="Roger.Kermode.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Roger Kermode
Content-Disposition: attachment;
filename="Roger.Kermode.vcf"
begin:vcard
n:Kermode;Roger
tel;cell:+61-408-212-284
tel;fax:+61-2-9666-0501
tel;work:+61-2-9666-0558
x-mozilla-html:FALSE
org:Motorola Labs, Motorola Australian Research Centre;Communications and Networks Laboratory
version:2.1
email;internet:Roger.Kermode@motorola.com
title:Principal Research Engineer, Manager
adr;quoted-printable:;;Locked Bag 5028, Botany NSW, 1455=0D=0A=0D=0ALevel 3, 12 Lord St;Botany;NSW;;Australia
fn:Roger Kermode
end:vcard
--------------4EC31ADEE849A429FEBE71F0--
>From owner-rmt@listserv.lbl.gov Mon Dec 11 18:55:25 2000
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id SAA13821;
Mon, 11 Dec 2000 18:54:49 -0800 (PST)
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id SAA13817
for <rmt@listserv.lbl.gov>; Mon, 11 Dec 2000 18:54:47 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id SAA01976
for <rmt@listserv.lbl.gov>; Mon, 11 Dec 2000 18:54:47 -0800 (PST)
Received: from raq3.ndmc.net ([63.140.75.133])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id SAA01973;
Mon, 11 Dec 2000 18:54:36 -0800 (PST)
Received: (from mail@localhost)
by raq3.ndmc.net (8.9.3/8.9.3) id JAA29924
for suscribe2_site123-list; Mon, 11 Dec 2000 09:52:22 -0500
X-Authentication-Warning: raq3.ndmc.net: mail set sender to owner-suscribe2@www.allairporttransport.com using -f
Received: from sgbd.com (ANeuilly-101-2-1-15.abo.wanadoo.fr [193.251.60.15])
by raq3.ndmc.net (8.9.3/8.9.3) with ESMTP id JAA29911
for <suscribe2@www.allairporttransport.com>; Mon, 11 Dec 2000 09:51:09 -0500
Received: from willy (195.154.186.131) by sgbd.com with SMTP (Eudora
Internet Mail Server 3.0.1); Mon, 11 Dec 2000 15:50:28 +0100
From: "willy bouchentouf" <vm@vivamundi.com>
To: "James Mellard" <mellard@weblifepro.com>,
<suscribe2@allairporttransport.com>
Subject: RE: UNSUBSCRIBE ME FROM YOUR MAILING LIST
Date: Mon, 11 Dec 2000 15:48:24 +0100
Message-ID: <NJENIAGEJMEKLIDLOAGGMEMDCEAA.vm@vivamundi.com>
MIME-Version: 1.0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <-1235634310mellard@weblifepro.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-rmt@lbl.gov
Precedence: bulk
??????
-----Message d'origine-----
De : owner-suscribe2@www.allairporttransport.com
[mailto:owner-suscribe2@www.allairporttransport.com]De la part de James
Mellard
Envoye : lundi 11 decembre 2000 05:43
A : suscribe2@www.allairporttransport.com
Objet : Re: UNSUBSCRIBE ME FROM YOUR MAILING LIST
On Sunday, December 10, 2000, Lefkas2000 <mail@lefkas2000.com> wrote:
>
>
>www.lefkas2000.com
>THE Guide to Lefkas
>----- Original Message -----
>From: <advert@allairporttransport.com>
>To: <suscribe@allairporttransport.com>
>Cc: <suscribe2@allairporttransport.com>; <advert@allairporttransport.com>
>Sent: Sunday, December 10, 2000 10:45 PM
>Subject: Get listed on Allairporttransport.com
>
>
>>
>>
>> Get listed on Allairporttransport.com
>>
>> http://www.allairporttransport.com
>>
>> -----
>> Sent using MailStart.com ( http://MailStart.Com/welcome.html )
>> The FREE way to access your mailbox via any web browser,
>anywhere!
>>
>>
>
>From owner-rmt@listserv.lbl.gov Mon Jan 29 02:22:42 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id CAA16987;
Mon, 29 Jan 2001 02:20:07 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id CAA16983
for <rmt@listserv.lbl.gov>; Mon, 29 Jan 2001 02:20:06 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id CAA09405
for <rmt@listserv.lbl.gov>; Mon, 29 Jan 2001 02:20:05 -0800 (PST)
Received: from duns-smtp.duns.wireless.comdev.ca ([212.250.47.4])
by SpamWall.lbl.gov (8.9.3/8.9.3) with SMTP id CAA09400
for <rmt@lbl.gov>; Mon, 29 Jan 2001 02:20:02 -0800 (PST)
Received: from DOM_DMZ_04-Message_Server by duns-smtp.duns.wireless.comdev.ca
with Novell_GroupWise; Mon, 29 Jan 2001 10:25:50 +0000
Message-Id: <sa75452e.028@duns-smtp.duns.wireless.comdev.ca>
X-Mailer: Novell GroupWise Internet Agent 5.5.2.1
Date: Mon, 29 Jan 2001 10:19:32 +0000
From: "Craig Fisher" <Craig.Fisher@wireless.comdev.ca>
To: <rmt@lbl.gov>
Subject: Access to archive
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=_5C071E3E.8DEC8116"
Sender: owner-rmt@lbl.gov
Precedence: bulk
This is a MIME message. If you are reading this text, you may want to
consider changing to a mail reader or gateway that understands how to
properly handle MIME multipart messages.
--=_5C071E3E.8DEC8116
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Hi - Does anyone know the correct address (if there is one) for access to =
the archives for the rmt list?
I've emailed rmt-request@lbl.gov as listed on the webpage (http://www.ietf.=
org/html.charters/rmt-charter.html) but
I get a 550 User unknown....
Many thanks,
-Craig
Craig Fisher - Technical Manager M/Ergy - UK & Europe
COM DEV Wireless
Vox: +44 1582 445061
Fax: +44 1582 445060
Email: Craig.Fisher@wireless.comdev.ca
--=_5C071E3E.8DEC8116
Content-Type: text/x-vcard
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Craig Fisher.vcf"
QkVHSU46VkNBUkQNClZFUlNJT046Mi4xDQpYLUdXVFlQRTpVU0VSDQpGTjpDcmFpZyBGaXNoZXIN
ClRFTDtXT1JLOis0NCAxNTgyIDQ0NTA2MQ0KT1JHOkNPTSBERVYgV2lyZWxlc3MgR3JvdXA7SVQN
ClRFTDtQUkVGO0ZBWDorNDQgMTU4MiA0NDUwNjANCkVNQUlMO1dPUks7UFJFRjpDcmFpZy5GaXNo
ZXJAd2lyZWxlc3MuY29tZGV2LmNhDQpOOkZpc2hlcjtDcmFpZw0KVElUTEU6TWFuYWdlcg0KQURS
O0lOVEw7V09SSztQQVJDRUw7UE9TVEFMOjs7MTIgSHVtcGhyeXMgUm9hZFxuV29vZHNpZGUgRXN0
YXRlXG47RHVuc3RhYmxlO0JlZGZvcmRzaGlyZTtMVTUgNFpIO1VLDQpMQUJFTDtJTlRMO1dPUks7
UEFSQ0VMO1BPU1RBTDtFTkNPRElORz1RVU9URUQtUFJJTlRBQkxFOkNyYWlnIEZpc2hlcj0wQT0N
CjEyIEh1bXBocnlzIFJvYWQ9MEE9DQpXb29kc2lkZSBFc3RhdGU9MEE9DQo9MEE9DQpEdW5zdGFi
bGUsIEJlZGZvcmRzaGlyZSAgTFU1IDRaSD0wQT0NClVLDQpMQUJFTDtET007V09SSztQQVJDRUw7
UE9TVEFMO0VOQ09ESU5HPVFVT1RFRC1QUklOVEFCTEU6Q3JhaWcgRmlzaGVyPTBBPQ0KMTIgSHVt
cGhyeXMgUm9hZD0wQT0NCldvb2RzaWRlIEVzdGF0ZT0wQT0NCj0wQT0NCkR1bnN0YWJsZSwgQmVk
Zm9yZHNoaXJlICBMVTUgNFpIDQpURUw7Q0VMTDorNDQgNzc2OCA1NTI0MTMNClgtR1dVU0VSSUQ6
Q0ZJU0hFUg0KRU5EOlZDQVJEDQoNCg==
--=_5C071E3E.8DEC8116--
>From owner-rmt@listserv.lbl.gov Mon Jan 29 02:34:21 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id CAA17071;
Mon, 29 Jan 2001 02:34:15 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id CAA17067
for <rmt@listserv.lbl.gov>; Mon, 29 Jan 2001 02:34:14 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id CAA11831
for <rmt@listserv.lbl.gov>; Mon, 29 Jan 2001 02:34:13 -0800 (PST)
Received: from daffy.ee.lbl.gov (daffy.ee.lbl.gov [131.243.1.31])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id CAA11828
for <rmt@lbl.gov>; Mon, 29 Jan 2001 02:34:12 -0800 (PST)
Received: (from vern@localhost)
by daffy.ee.lbl.gov (8.10.0/8.10.0) id f0TAY7g21799;
Mon, 29 Jan 2001 02:34:07 -0800 (PST)
Message-Id: <200101291034.f0TAY7g21799@daffy.ee.lbl.gov>
To: "Craig Fisher" <Craig.Fisher@wireless.comdev.ca>
Cc: <rmt@lbl.gov>
Subject: Re: Access to archive
In-reply-to: Your message of Mon, 29 Jan 2001 10:19:32 PST.
Date: Mon, 29 Jan 2001 02:34:07 PST
From: Vern Paxson <vern@ee.lbl.gov>
Sender: owner-rmt@lbl.gov
Precedence: bulk
> Hi - Does anyone know the correct address (if there is one) for access to =
> the archives for the rmt list?
Send mail to majordomo@lbl.gov with
get rmt archive
as the body.
> I've emailed rmt-request@lbl.gov as listed on the webpage (http://www.ietf.=
> org/html.charters/rmt-charter.html) but
> I get a 550 User unknown....
Oops, config-rot, sorry about that. I'll get it updated.
Vern
>From owner-rmt@listserv.lbl.gov Fri Feb 2 09:18:00 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id JAA01568;
Fri, 2 Feb 2001 09:14:46 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id JAA01564
for <rmt@listserv.lbl.gov>; Fri, 2 Feb 2001 09:14:45 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id JAA26506
for <rmt@listserv.lbl.gov>; Fri, 2 Feb 2001 09:14:44 -0800 (PST)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id JAA26496
for <rmt@lbl.gov>; Fri, 2 Feb 2001 09:14:43 -0800 (PST)
Received: from ISI.EDU (jet.isi.edu [128.9.160.87])
by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id JAA05874;
Fri, 2 Feb 2001 09:14:39 -0800 (PST)
Message-Id: <200102021714.JAA05874@boreas.isi.edu>
To: IETF-Announce: ;
Subject: RFC 3048 on RMT Building Blocks
Cc: rfc-ed@ISI.EDU, rmt@lbl.gov
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Fri, 02 Feb 2001 09:14:39 -0800
From: RFC Editor <rfc-ed@ISI.EDU>
Sender: owner-rmt@lbl.gov
Precedence: bulk
--NextPart
A new Request for Comments is now available in online RFC libraries.
RFC 3048
Title: Reliable Multicast Transport Building Blocks for
One-to-Many Bulk-Data Transfer
Author(s): B. Whetten, L. Vicisano, R. Kermode, M. Handley,
S. Floyd, M. Luby
Status: Informational
Date: January 2001
Mailbox: whetten@talarian.com, lorenzo@cisco.com,
Roger.Kermode@motorola.com, mjh@aciri.org,
floyd@aciri.org, luby@digitalfountain.com
Pages: 20
Characters: 48965
Updates/Obsoletes/SeeAlso: None
I-D Tag: draft-ietf-rmt-buildingblocks-03.txt
URL: ftp://ftp.rfc-editor.org/in-notes/rfc3048.txt
This document describes a framework for the standardization of
bulk-data reliable multicast transport. It builds upon the experience
gained during the deployment of several classes of contemporary
reliable multicast transport, and attempts to pull out the
commonalities between these classes of protocols into a number of
building blocks. To that end, this document recommends that certain
components that are common to multiple protocol classes be
standardized as "building blocks". The remaining parts of the
protocols, consisting of highly protocol specific, tightly intertwined
functions, shall be designated as "protocol cores". Thus, each
protocol can then be constructed by merging a "protocol core" with a
number of "building blocks" which can be re-used across multiple
protocols.
This document is a product of the Reliable Multicast Transport Working
Group of the IETF.
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST@IETF.ORG. Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG.
Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body
help: ways_to_get_rfcs. For example:
To: rfc-info@RFC-EDITOR.ORG
Subject: getting rfcs
help: ways_to_get_rfcs
Requests for special distribution should be addressed to either the
author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo
Submissions for Requests for Comments should be sent to
RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC
Authors, for further information.
Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute
...
Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the RFCs.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="RFC-INFO@RFC-EDITOR.ORG"
Content-Type: text/plain
Content-ID: <010202091217.RFC@RFC-EDITOR.ORG>
RETRIEVE: rfc
DOC-ID: rfc3048
--OtherAccess
Content-Type: Message/External-body;
name="rfc3048.txt";
site="ftp.isi.edu";
access-type="anon-ftp";
directory="in-notes"
Content-Type: text/plain
Content-ID: <010202091217.RFC@RFC-EDITOR.ORG>
--OtherAccess--
--NextPart--
>From owner-rmt@listserv.lbl.gov Fri Feb 2 14:10:17 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id OAA03355;
Fri, 2 Feb 2001 14:08:11 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id OAA03351
for <rmt@listserv.lbl.gov>; Fri, 2 Feb 2001 14:08:05 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id OAA17964
for <rmt@listserv.lbl.gov>; Fri, 2 Feb 2001 14:08:05 -0800 (PST)
Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id OAA17960
for <rmt@lbl.gov>; Fri, 2 Feb 2001 14:08:04 -0800 (PST)
Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id PAA23038 for <rmt@lbl.gov>; Fri, 2 Feb 2001 15:08:03 -0700 (MST)]
Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id PAA17006 for <rmt@lbl.gov>; Fri, 2 Feb 2001 15:08:01 -0700 (MST)]
Received: from arc.corp.mot.com ([217.2.31.42])
by homer.arc.corp.mot.com (8.10.2/8.10.2) with ESMTP id f12M7kY14123
for <rmt@lbl.gov>; Sat, 3 Feb 2001 09:07:46 +1100 (EST)
Message-ID: <3A7B2FB4.47590A6@arc.corp.mot.com>
Date: Sat, 03 Feb 2001 09:07:48 +1100
From: Roger Kermode <rkermode@arc.corp.mot.com>
Organization: Motorola Australia Research Centre
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: rmt@lbl.gov
Subject: Re: RFC 3048 on RMT Building Blocks
References: <200102021714.JAA05874@boreas.isi.edu>
Content-Type: multipart/mixed;
boundary="------------ED286C897DF6E11FD3189DDC"
Sender: owner-rmt@lbl.gov
Precedence: bulk
This is a multi-part message in MIME format.
--------------ED286C897DF6E11FD3189DDC
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Dear Everyone,
thanks you to all who contributed to this doc.
Good work!
cheers,
Roger
RFC Editor wrote:
> A new Request for Comments is now available in online RFC libraries.
>
> RFC 3048
>
> Title: Reliable Multicast Transport Building Blocks for
> One-to-Many Bulk-Data Transfer
> Author(s): B. Whetten, L. Vicisano, R. Kermode, M. Handley,
> S. Floyd, M. Luby
> Status: Informational
> Date: January 2001
> Mailbox: whetten@talarian.com, lorenzo@cisco.com,
> Roger.Kermode@motorola.com, mjh@aciri.org,
> floyd@aciri.org, luby@digitalfountain.com
> Pages: 20
> Characters: 48965
> Updates/Obsoletes/SeeAlso: None
>
> I-D Tag: draft-ietf-rmt-buildingblocks-03.txt
>
> URL: ftp://ftp.rfc-editor.org/in-notes/rfc3048.txt
>
> This document describes a framework for the standardization of
> bulk-data reliable multicast transport. It builds upon the experience
> gained during the deployment of several classes of contemporary
> reliable multicast transport, and attempts to pull out the
> commonalities between these classes of protocols into a number of
> building blocks. To that end, this document recommends that certain
> components that are common to multiple protocol classes be
> standardized as "building blocks". The remaining parts of the
> protocols, consisting of highly protocol specific, tightly intertwined
> functions, shall be designated as "protocol cores". Thus, each
> protocol can then be constructed by merging a "protocol core" with a
> number of "building blocks" which can be re-used across multiple
> protocols.
>
> This document is a product of the Reliable Multicast Transport Working
> Group of the IETF.
>
> This memo provides information for the Internet community. It does
> not specify an Internet standard of any kind. Distribution of this
> memo is unlimited.
>
> This announcement is sent to the IETF list and the RFC-DIST list.
> Requests to be added to or deleted from the IETF distribution list
> should be sent to IETF-REQUEST@IETF.ORG. Requests to be
> added to or deleted from the RFC-DIST distribution list should
> be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG.
>
> Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
> an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body
> help: ways_to_get_rfcs. For example:
>
> To: rfc-info@RFC-EDITOR.ORG
> Subject: getting rfcs
>
> help: ways_to_get_rfcs
>
> Requests for special distribution should be addressed to either the
> author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless
> specifically noted otherwise on the RFC itself, all RFCs are for
> unlimited distribution.echo
> Submissions for Requests for Comments should be sent to
> RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC
> Authors, for further information.
>
> Joyce K. Reynolds and Sandy Ginoza
> USC/Information Sciences Institute
>
> ...
>
> Below is the data which will enable a MIME compliant Mail Reader
> implementation to automatically retrieve the ASCII version
> of the RFCs.
>
> ------------------------------------------------------------------------
> Content-Type: text/plain
> Content-ID: <010202091217.RFC@RFC-EDITOR.ORG>
--------------ED286C897DF6E11FD3189DDC
Content-Type: text/x-vcard; charset=us-ascii;
name="rkermode.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Roger Kermode
Content-Disposition: attachment;
filename="rkermode.vcf"
begin:vcard
n:Kermode;Roger
tel;cell:+61-408-212-284
tel;fax:+61-2-9666-0501
tel;work:+61-2-9666-0558
x-mozilla-html:FALSE
org:Motorola Labs, Motorola Australian Research Centre;Communications and Networks Laboratory
version:2.1
email;internet:Roger.Kermode@motorola.com
title:Principal Research Engineer, Manager
adr;quoted-printable:;;Locked Bag 5028, Botany NSW, 1455=0D=0A=0D=0ALevel 3, 12 Lord St;Botany;NSW;;Australia
fn:Roger Kermode
end:vcard
--------------ED286C897DF6E11FD3189DDC--
>From owner-rmt@listserv.lbl.gov Sun Feb 4 17:43:50 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id RAA13230;
Sun, 4 Feb 2001 17:40:11 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id RAA13226
for <rmt@listserv.lbl.gov>; Sun, 4 Feb 2001 17:40:09 -0800 (PST)
From: b4h443@arabia.com
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id RAA18775
for <rmt@listserv.lbl.gov>; Sun, 4 Feb 2001 17:40:08 -0800 (PST)
Received: from email.molcybercafes.com ([202.184.170.42])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id RAA18772
for <rmt@lbl.gov>; Sun, 4 Feb 2001 17:40:07 -0800 (PST)
Received: from mail.mcities.com - 202.184.170.148 by email.molcybercafes.com with Microsoft SMTPSVC(5.5.1774.114.11);
Mon, 5 Feb 2001 05:16:13 +0800
Received: from kwantlen.bc.ca [63.46.223.74] by mail.mcities.com
(SMTPD32-6.05) id A72D2867014A; Mon, 05 Feb 2001 05:18:37 +0800
Message-ID: <00005d975838$00003d1a$0000095e@mailhost.ggtech.com>
To: <umd1fc@mail.hanwhabank.hu>
Subject: Brand New E-Mail pager for FR-EE!
Date: Sun, 04 Feb 2001 15:11:07 -0600
X-Priority: 3
X-MSMail-Priority: Normal
Reply-To: b4h443@arabia.com
Sender: owner-rmt@lbl.gov
Precedence: bulk
Brand New E-Mail pager for FREE!
No long term contract
No activation fee
No big prepayment of airtime
No credit check
PAGING AMERICA is going to give you absolutely Free the Brand new Motorola
Accessmate E-Mail display pager. This is the top of the line PCS technology
pager made today. This side viewable display pager has a retail value of
$189.00and comes with its own e-mail address so you can receive your e-mails
as well as alpha-numeric and numeric messages instantly where ever you are.
Your new e-mail pager has features like 50,000 character memory, message time
stamping, automatic garbled message correction, beeps or vibrates,
incandescent backlight, saved message folder, a unique never out of range
feature that allows your pager to retrieve messages sent earlier when your
pager was out of range or turned completely off. You can also receive
weather, news and sports .The Motorola e-mail pager is very small and uses
only a single double A battery. All we ask before we ship you your Free pager
is for you to allow us to provide the airtime for you. There is no long term
contract or credit check. Airtime is month to month and can be cancelled at
any time. This pager will comes pre-programmed with its own e-mail address as
well as a local telephone number to receive numeric pages. This pager comes
with a complete 30 day money back guarantee, if after receiving this pager
you're not completely happy, send it back and receive a full refund.
For immediate delivery call Paging America at toll free at 877-699-8545
Brand New E-Mail pager for FREE!
>From owner-rmt@listserv.lbl.gov Mon Feb 5 00:24:40 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id AAA13946;
Mon, 5 Feb 2001 00:23:59 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id AAA13942
for <rmt@listserv.lbl.gov>; Mon, 5 Feb 2001 00:23:58 -0800 (PST)
From: b4h443@arabia.com
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id AAA22509
for <rmt@listserv.lbl.gov>; Mon, 5 Feb 2001 00:23:57 -0800 (PST)
Received: from puma.uner.edu.ar (gnome@[170.210.25.10])
by SpamWall.lbl.gov (8.9.3/8.9.3) with SMTP id AAA22498
for <rmt@lbl.gov>; Mon, 5 Feb 2001 00:23:49 -0800 (PST)
Received: from nova.sylvest.co(really [63.38.115.221]) by puma.uner.edu.ar
via sendmail with smtp
id <m14PRnM-000OkVC@puma.uner.edu.ar>
for <rmt@lbl.gov>; Sun, 4 Feb 2001 19:13:44 +0300 (GMT)
(Smail-3.2 1996-Jul-4 #2 built 1996-Aug-16)
Message-ID: <000011605966$00000f09$00001d6c@nova.sylvest.co>
To: <ukz30smta4lb86@euronet.be>
Subject: Brand New E-Mail pager for FR-EE!
Date: Sun, 04 Feb 2001 15:37:19 -0600
X-Priority: 3
X-MSMail-Priority: Normal
Reply-To: b4h443@arabia.com
Sender: owner-rmt@lbl.gov
Precedence: bulk
Brand New E-Mail pager for FREE!
No long term contract
No activation fee
No big prepayment of airtime
No credit check
PAGING AMERICA is going to give you absolutely Free the Brand new Motorola
Accessmate E-Mail display pager. This is the top of the line PCS technology
pager made today. This side viewable display pager has a retail value of
$189.00and comes with its own e-mail address so you can receive your e-mails
as well as alpha-numeric and numeric messages instantly where ever you are.
Your new e-mail pager has features like 50,000 character memory, message time
stamping, automatic garbled message correction, beeps or vibrates,
incandescent backlight, saved message folder, a unique never out of range
feature that allows your pager to retrieve messages sent earlier when your
pager was out of range or turned completely off. You can also receive
weather, news and sports .The Motorola e-mail pager is very small and uses
only a single double A battery. All we ask before we ship you your Free pager
is for you to allow us to provide the airtime for you. There is no long term
contract or credit check. Airtime is month to month and can be cancelled at
any time. This pager will comes pre-programmed with its own e-mail address as
well as a local telephone number to receive numeric pages. This pager comes
with a complete 30 day money back guarantee, if after receiving this pager
you're not completely happy, send it back and receive a full refund.
For immediate delivery call Paging America at toll free at 877-699-8545
Brand New E-Mail pager for FREE!
No long term contract
No activation fee
No big prepayment of airtime
No credit check
>From owner-rmt@listserv.lbl.gov Fri Feb 9 06:38:36 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id GAA19592;
Fri, 9 Feb 2001 06:35:39 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id GAA19588
for <rmt@listserv.lbl.gov>; Fri, 9 Feb 2001 06:35:37 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id GAA23761
for <rmt@listserv.lbl.gov>; Fri, 9 Feb 2001 06:35:36 -0800 (PST)
Received: from letters.cs.ucsb.edu (letters.cs.ucsb.edu [128.111.41.13])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id GAA23758
for <rmt@lbl.gov>; Fri, 9 Feb 2001 06:35:35 -0800 (PST)
Received: from jackson.cs.ucsb.edu (jackson [128.111.52.10])
by letters.cs.ucsb.edu (8.9.3+Sun/8.9.3) with ESMTP id GAA19189;
Fri, 9 Feb 2001 06:35:29 -0800 (PST)
Received: by jackson.cs.ucsb.edu (8.9.3+Sun/SMI-SVR4)
id GAA28803 for ; Fri, 9 Feb 2001 06:35:27 -0800 (PST)
Date: Fri, 9 Feb 2001 06:35:27 -0800 (PST)
From: almeroth@cs.ucsb.edu (Kevin C. Almeroth)
Message-Id: <200102091435.GAA28803@jackson.cs.ucsb.edu>
To: almeroth@cs.ucsb.edu, katia@cse.ucsc.edu
Subject: CFP: Global Internet 2001 (in conjunction with Globecom 2001)
Sender: owner-rmt@lbl.gov
Precedence: bulk
Sixth Global Internet Symposium
in conjunction with
Globecom 2001
San Antonio, Texas, USA
November 25-29, 2001
http://www.cs.ucsb.edu/gi2001/
------------------------------------------------------------------------
Call For Papers
The sixth Global Internet Symposium will be held simultaneously and
co-located with Globecom 2001. Therefore, all of the relevant dates,
location, travel information are derived from the Globecom 2001
(http://www.globecom2001.com/) conference site.
Symposium Topics
Global Internet 2000 solicits technical papers on Internet-related topics.
The Program Committee encourages papers submitted on experimental systems
and emerging technologies. Also encouraged are original submissions
describing promising work in progress, original speculations about the
future of the Internet, and progressive position papers. Topics of interest
include, but are not limited to:
* Novel applications and new paradigms (telephony, streaming media, etc.)
* Distributed Internet applications (file sharing, games, conferencing,
etc.)
* Service provisioning, monitoring, and management
* Privacy and/or security issues
* Charging and billing issues
* Handling Internet dynamics/heterogeneity (by applications and/or the
network)
* Routing (unicast, multicast, anycast, etc.)
* Traffic measurement, analysis, modeling, and visualization
* Flow management (fairness/sharing, differentiated services, etc.)
* The Internet and mobility/mobile devices
* Wireless device access and Internet gateways
Important Dates
Manuscript Submission: March 31, 2001
Acceptance Notification: July 31, 2001
Final Manuscript: September 31, 2000
Submission Instructions
Please see the Global Internet Symposium WWW site at:
http://www.cs.ucsb.edu/gi2001/
Technical Program Chairs
Kevin Almeroth, UC-Santa Barbara (almeroth@cs.ucsb.edu)
Katia Obraczka, UC-Santa Cruz (katia@cse.ucsc.edu)
Program Committee
To be announced.
Sponsorship
The Global Internet Symposium is sponsored by the IEEE Communications
Society InternetTC.
>From owner-rmt@listserv.lbl.gov Sat Feb 10 15:45:03 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id PAA24294;
Sat, 10 Feb 2001 15:42:25 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id PAA24290
for <rmt@listserv.lbl.gov>; Sat, 10 Feb 2001 15:42:23 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id PAA04500
for <rmt@listserv.lbl.gov>; Sat, 10 Feb 2001 15:42:23 -0800 (PST)
Received: from arunapc (patty.levels.unisa.edu.au [130.220.36.156])
by SpamWall.lbl.gov (8.9.3/8.9.3) with SMTP id PAA04486
for <rmt@lbl.gov>; Sat, 10 Feb 2001 15:42:11 -0800 (PST)
Date: Sat, 10 Feb 2001 15:42:11 -0800 (PST)
Message-Id: <200102102342.PAA04486@SpamWall.lbl.gov>
From: Hahaha <hahaha@sexyfun.net>
Subject: Snowhite and the Seven Dwarfs - The REAL story!
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="--VEM34D6FKPQNOP6BCPYVOTAFO1"
Sender: owner-rmt@lbl.gov
Precedence: bulk
----VEM34D6FKPQNOP6BCPYVOTAFO1
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
****************** Virus Warning Message (on the network)
Found virus TROJ_HYBRIS.B in file midgets.scr
The file e/iscan/virus/virDKD0TlMRT is moved to the configured virus directory.
*********************************************************
----VEM34D6FKPQNOP6BCPYVOTAFO1
Content-Type: text/plain; charset="us-ascii"
Today, Snowhite was turning 18. The 7 Dwarfs always where very educated and
polite with Snowhite. When they go out work at mornign, they promissed a
*huge* surprise. Snowhite was anxious. Suddlently, the door open, and the Seven
Dwarfs enter...
----VEM34D6FKPQNOP6BCPYVOTAFO1
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
****************** Virus Warning Message (on the network)
midgets.scr is removed from here because it contains a virus.
*********************************************************
----VEM34D6FKPQNOP6BCPYVOTAFO1--
>From owner-rmt@listserv.lbl.gov Thu Feb 15 14:34:38 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id OAA12518;
Thu, 15 Feb 2001 14:31:45 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id OAA12514
for <rmt@listserv.lbl.gov>; Thu, 15 Feb 2001 14:31:43 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id OAA02381
for <rmt@listserv.lbl.gov>; Thu, 15 Feb 2001 14:31:42 -0800 (PST)
Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id OAA02368
for <rmt@lbl.gov>; Thu, 15 Feb 2001 14:31:41 -0800 (PST)
Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate2.mot.com (motgate2 2.1) with ESMTP id PAA20966 for <rmt@lbl.gov>; Thu, 15 Feb 2001 15:31:40 -0700 (MST)]
Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id PAA05570 for <rmt@lbl.gov>; Thu, 15 Feb 2001 15:31:38 -0700 (MST)]
Received: from arc.corp.mot.com (marcia.arc.corp.mot.com [10.238.80.74])
by homer.arc.corp.mot.com (8.10.2/8.10.2) with ESMTP id f1FMVZn11389
for <rmt@lbl.gov>; Fri, 16 Feb 2001 09:31:36 +1100 (EST)
Message-ID: <3A8C58C5.A63850BB@arc.corp.mot.com>
Date: Fri, 16 Feb 2001 09:31:33 +1100
From: Roger Kermode <rkermode@arc.corp.mot.com>
Organization: Motorola Australia Research Centre
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: rmt-list <rmt@lbl.gov>
Subject: Call for RMT Items
Content-Type: multipart/mixed;
boundary="------------C2D2002D8A28D7B838CF4A98"
Sender: owner-rmt@lbl.gov
Precedence: bulk
This is a multi-part message in MIME format.
--------------C2D2002D8A28D7B838CF4A98
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Dear Everyone,
Lorenzo has organized the following time slots for
the Minneapolis meeting. Please send your agenda
items to me ASAP so we can pre publish the agenda
with a little more notice this time around.
I'd like to emphasize that we will be shooting for
brief updates to drafts and that the bulk of the time
should be spent discussing issues relating to how we
can move towards having real working protocols.
Please use the email list to pre announce any items
for discussion so we can come to the meeting well
informed and ready to make decisions.
cheers,
Roger
Lorenzo
Allison
TENTATIVE SCHEDULE
----------------------------
TUESDAY, March 20, 2001
1300-1400 Afternoon Sessions I
APP webi Web Intermediaries WG
GEN iporpr IP over Resilient Packet Rings WG
INT atommib AToM MIB WG
OPS rap Resource Allocation Protocol WG
SEC pkix Public-Key Infrastructure WG
TSV issll Integrated Services over Specific Link Layers
WG
TSV rmt Reliable Multicast Transport WG
WEDNESDAY, March 21, 2001
0900-1130 Morning Sessions
APP ldapbis LDAP (v3) Revision WG
INT ipngwg IPNG WG
OPS policy Policy Framework WG
SEC idwg Intrusion Detection Exchange Format WG
TSV ips IP Storage WG
TSV rmt Reliable Multicast Transport WG
--------------C2D2002D8A28D7B838CF4A98
Content-Type: text/x-vcard; charset=us-ascii;
name="rkermode.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Roger Kermode
Content-Disposition: attachment;
filename="rkermode.vcf"
begin:vcard
n:Kermode;Roger
tel;cell:+61-408-212-284
tel;fax:+61-2-9666-0501
tel;work:+61-2-9666-0558
x-mozilla-html:FALSE
org:Motorola Labs, Motorola Australian Research Centre;Communications and Networks Laboratory
version:2.1
email;internet:Roger.Kermode@motorola.com
title:Principal Research Engineer, Manager
adr;quoted-printable:;;Locked Bag 5028, Botany NSW, 1455=0D=0A=0D=0ALevel 3, 12 Lord St;Botany;NSW;;Australia
fn:Roger Kermode
end:vcard
--------------C2D2002D8A28D7B838CF4A98--
>From owner-rmt@listserv.lbl.gov Fri Feb 23 06:48:38 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id GAA06823;
Fri, 23 Feb 2001 06:46:20 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id GAA06819
for <rmt@listserv.lbl.gov>; Fri, 23 Feb 2001 06:46:18 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id GAA13209
for <rmt@listserv.lbl.gov>; Fri, 23 Feb 2001 06:46:17 -0800 (PST)
Received: from sm.luth.se (ny.sm.luth.se [130.240.3.1])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id GAA13204
for <rmt@lbl.gov>; Fri, 23 Feb 2001 06:46:15 -0800 (PST)
Received: from fix.cdt.luth.se (fix.cdt.luth.se [130.240.64.20])
by sm.luth.se (8.10.0/8.10.0) with ESMTP id f1NEiQk29689;
Fri, 23 Feb 2001 15:44:41 +0100 (MET)
Date: Fri, 23 Feb 2001 15:44:12 +0100 (MET)
From: Jeremiah Scholl <jeremiah@cdt.luth.se>
X-Sender: jeremiah@fix.cdt.luth.se
To: rmt@lbl.gov
cc: peppar@cdt.luth.se
Subject: reliable multicast congestion control
Message-ID: <Pine.GSO.4.21.0102231313380.8121-100000@fix.cdt.luth.se>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-rmt@lbl.gov
Precedence: bulk
I have recently been looking at the internet drafts available on the web
site for rmt workgroup and have a question regarding the standards that
are currently being developed. Specifically I am interested in
information about congestion control.
I noticed that there is currently one document on the site that describes
a congestion control mechanism. It is titled "Reliable Multicast
Transport Building Block: Layered Congestion Control". This congestion
control mechanism seems to be taylored specifically for the case where
massive scale is the primary concern and seemed to be created to work
along with LTC.
I am wondering if there will be additional congestion control "Building
Blocks" created that focus more on other types of applications (like
collabrative workspaces for example). Does the group plan on creating
one congestion control document for each protocol? Any information on how
congestion control for reliable multicast will fit into the work on
standardization of reliable multicast would be very helpfull.
Thank you very much,
Jeremiah Scholl
>From owner-rmt@listserv.lbl.gov Fri Feb 23 07:10:02 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id HAA06857;
Fri, 23 Feb 2001 07:09:56 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id HAA06853
for <rmt@listserv.lbl.gov>; Fri, 23 Feb 2001 07:09:54 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id HAA16353
for <rmt@listserv.lbl.gov>; Fri, 23 Feb 2001 07:09:54 -0800 (PST)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
by SpamWall.lbl.gov (8.9.3/8.9.3) with SMTP id HAA16350
for <rmt@lbl.gov>; Fri, 23 Feb 2001 07:09:52 -0800 (PST)
Received: from hocus.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP
id <g.04697-0@bells.cs.ucl.ac.uk>; Fri, 23 Feb 2001 15:09:27 +0000
To: Jeremiah Scholl <jeremiah@cdt.luth.se>
cc: rmt@lbl.gov, peppar@cdt.luth.se
Subject: Re: reliable multicast congestion control
In-reply-to: Your message of "Fri, 23 Feb 2001 15:44:12 +0100." <Pine.GSO.4.21.0102231313380.8121-100000@fix.cdt.luth.se>
Date: Fri, 23 Feb 2001 15:09:24 +0000
Message-ID: <21265.982940964@cs.ucl.ac.uk>
From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
Sender: owner-rmt@lbl.gov
Precedence: bulk
In message <Pine.GSO.4.21.0102231313380.8121-100000@fix.cdt.luth.se>, Jeremiah
Scholl typed:
>>I am wondering if there will be additional congestion control "Building
>>Blocks" created that focus more on other types of applications (like
>>collabrative workspaces for example). Does the group plan on creating
>>one congestion control document for each protocol? Any information on how
>>congestion control for reliable multicast will fit into the work on
>>standardization of reliable multicast would be very helpfull.
Jeremiah
we went round this loop several times - the problem with this is that
we could never get people to poin down the applicationrequirements
fir cilaborative workspaces that allowed for congestion control -
looking back at this again, let me try to restate where we got to
(some of this happened in the LSMA working group)
1/ a lot of colalborative applications have lowish message rates and
smallish messages (viz, wb, nte, game traffic) -
2/ they are highly bursty (but not high rate - ) i.e. they are 1
packet or 2, then nothing for ages, per source
3/ many to many: there's no obvious correlation in the rate from one
source and another
4/ there _IS_ a requirement for latency control - this means that
adaption below a minimum rate is not acceptable, and usualy means that
you have to provision, or reserve, for them for them to be usable at
all over any significant distance
5/ when there is a large transfer (e.g. wb loading slides to a new/late
joiner), its 1-many, which is covered by current approaches
6/ in IETF "stakeholder" terms, the recent trend for ISPs technology pull has
been SSM - which mitigates against simple transport protocols for
multiple sender - typically, for smallish groups, though, yo uhave a
coordination server: "clients" runs unicast to it - it runs ssm to
clients - them same rules apply...(actually quite nicely for ALC like
protocols, since yo ucan accomodate heterogeneity and asymetric trees
quite elegantly)
for many-to-many large group, large numebr of senders, the claim has
been there aren't "compelling" application demand (at least yet)....
that may sound negative - i dont mean to be - i think there's also an
element of "oh, we think we can solve this case so lets get it done,
then we can go onto the harder case again"
given the data rates involved, we are fairly conveinced that games for
example will appear that are multiplayer but not server based once the
game engines for this are in place - then some sort of "collective
bargaining" congestion control looks like being vital.....
cheers
jon
>From owner-rmt@listserv.lbl.gov Tue Feb 27 01:07:28 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id BAA16402;
Tue, 27 Feb 2001 01:02:19 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id BAA16398
for <rmt@listserv.lbl.gov>; Tue, 27 Feb 2001 01:02:12 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id BAA05033
for <rmt@listserv.lbl.gov>; Tue, 27 Feb 2001 01:02:12 -0800 (PST)
Received: from sm.luth.se (ny.sm.luth.se [130.240.3.1])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id BAA05030
for <rmt@lbl.gov>; Tue, 27 Feb 2001 01:02:10 -0800 (PST)
Received: from delta1.sm.luth.se (delta1.sm.luth.se [130.240.3.7])
by sm.luth.se (8.10.0/8.10.0) with ESMTP id f1R92Lk27160;
Tue, 27 Feb 2001 10:02:21 +0100 (MET)
Date: Tue, 27 Feb 2001 10:02:06 +0100 (MET)
From: Jeremiah Scholl <jeremiah@cdt.luth.se>
To: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
cc: rmt@lbl.gov, peppar@cdt.luth.se
Subject: Re: reliable multicast congestion control
In-Reply-To: <21265.982940964@cs.ucl.ac.uk>
Message-ID: <Pine.GSO.4.21.0102261712540.15094-100000@delta1.sm.luth.se>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-rmt@lbl.gov
Precedence: bulk
On Fri, 23 Feb 2001, Jon Crowcroft wrote:
>
> In message <Pine.GSO.4.21.0102231313380.8121-100000@fix.cdt.luth.se>, Jeremiah
> Scholl typed:
>
> >>I am wondering if there will be additional congestion control "Building
> >>Blocks" created that focus more on other types of applications (like
> >>collabrative workspaces for example). Does the group plan on creating
> >>one congestion control document for each protocol? Any information on how
> >>congestion control for reliable multicast will fit into the work on
> >>standardization of reliable multicast would be very helpfull.
>
> Jeremiah
>
> we went round this loop several times - the problem with this is that
> we could never get people to poin down the applicationrequirements
> fir cilaborative workspaces that allowed for congestion control -
>
> looking back at this again, let me try to restate where we got to
> (some of this happened in the LSMA working group)
>
> 1/ a lot of colalborative applications have lowish message rates and
> smallish messages (viz, wb, nte, game traffic) -
>
> 2/ they are highly bursty (but not high rate - ) i.e. they are 1
> packet or 2, then nothing for ages, per source
>
> 3/ many to many: there's no obvious correlation in the rate from one
> source and another
>
> 4/ there _IS_ a requirement for latency control - this means that
> adaption below a minimum rate is not acceptable, and usualy means that
> you have to provision, or reserve, for them for them to be usable at
> all over any significant distance
>
> 5/ when there is a large transfer (e.g. wb loading slides to a new/late
> joiner), its 1-many, which is covered by current approaches
>
> 6/ in IETF "stakeholder" terms, the recent trend for ISPs technology pull has
> been SSM - which mitigates against simple transport protocols for
> multiple sender - typically, for smallish groups, though, yo uhave a
> coordination server: "clients" runs unicast to it - it runs ssm to
> clients - them same rules apply...(actually quite nicely for ALC like
> protocols, since yo ucan accomodate heterogeneity and asymetric trees
> quite elegantly)
>
> for many-to-many large group, large numebr of senders, the claim has
> been there aren't "compelling" application demand (at least yet)....
>
> that may sound negative - i dont mean to be - i think there's also an
> element of "oh, we think we can solve this case so lets get it done,
> then we can go onto the harder case again"
>
> given the data rates involved, we are fairly conveinced that games for
> example will appear that are multiplayer but not server based once the
> game engines for this are in place - then some sort of "collective
> bargaining" congestion control looks like being vital.....
>
> cheers
>
> jon
>
>
Jon, thanks for the comments! I agree with what you wrote.
Has any progress at all been made towards forming a consensus on what the
building block will need? Have the most basic requirements been agreed
upon yet and if so what are they?
For example, because of the interactivity of users multiple-rate
congestion control does not lend itself well with collabrative
workspaces. Also, as you mentioned above there is still not "compelling
application demand" for large many -to- many sessions. This would tend to
make tuning the send rate worst-case receiver a realistic option for the
scheme.
So, has there at least been an agreement to create a building block for a
single-rate scheme that tunes its sending rate to the worst-case
receiver?
Any information about this or any other congestion control builing blocks
in the works would be very helpfull.
Thanks again!
Jeremiah
>From owner-rmt@listserv.lbl.gov Tue Feb 27 02:16:19 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id CAA16568;
Tue, 27 Feb 2001 02:13:54 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id CAA16564
for <rmt@listserv.lbl.gov>; Tue, 27 Feb 2001 02:13:52 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id CAA11473
for <rmt@listserv.lbl.gov>; Tue, 27 Feb 2001 02:13:51 -0800 (PST)
Received: from info.iet.unipi.it (info.iet.unipi.it [131.114.9.184])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id CAA11470
for <rmt@lbl.gov>; Tue, 27 Feb 2001 02:13:50 -0800 (PST)
Received: (from luigi@localhost)
by info.iet.unipi.it (8.9.3/8.9.3) id LAA20996;
Tue, 27 Feb 2001 11:14:41 +0100 (CET)
(envelope-from luigi)
From: Luigi Rizzo <luigi@info.iet.unipi.it>
Message-Id: <200102271014.LAA20996@info.iet.unipi.it>
Subject: Re: reliable multicast congestion control
In-Reply-To: <Pine.GSO.4.21.0102261712540.15094-100000@delta1.sm.luth.se> from
Jeremiah Scholl at "Feb 27, 2001 10:02:06 am"
To: Jeremiah Scholl <jeremiah@cdt.luth.se>
Date: Tue, 27 Feb 2001 11:14:40 +0100 (CET)
CC: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>, rmt@lbl.gov, peppar@cdt.luth.se
X-Mailer: ELM [version 2.4ME+ PL61 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-rmt@lbl.gov
Precedence: bulk
> So, has there at least been an agreement to create a building block for a
> single-rate scheme that tunes its sending rate to the worst-case
> receiver?
i just submitted an I-D on pgmcc, which is a single rate cong.control
scheme. You can find more at http://www.iet.unipi.it/~luigi/pgm.html
or on the sigcomm2000 site
cheers
luigi
----------------------------------+-----------------------------------------
Luigi RIZZO, luigi@iet.unipi.it . ACIRI/ICSI (on leave from Univ. di Pisa)
http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704
Phone (510) 666 2927 .
----------------------------------+-----------------------------------------
>From owner-rmt@listserv.lbl.gov Wed Feb 28 04:01:48 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id DAA01247;
Wed, 28 Feb 2001 03:59:20 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id DAA01243
for <rmt@listserv.lbl.gov>; Wed, 28 Feb 2001 03:59:17 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id DAA20524
for <rmt@listserv.lbl.gov>; Wed, 28 Feb 2001 03:59:17 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id DAA20521
for <rmt@lbl.gov>; Wed, 28 Feb 2001 03:59:15 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03109;
Wed, 28 Feb 2001 06:59:15 -0500 (EST)
Message-Id: <200102281159.GAA03109@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: rmt@lbl.gov
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-rmt-bb-pgmcc-00.txt
Date: Wed, 28 Feb 2001 06:59:14 -0500
Sender: owner-rmt@lbl.gov
Precedence: bulk
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Reliable Multicast Transport Working Group of the IETF.
Title : PGMCC single rate multicast congestion control:
Protocol Specification
Author(s) : L. Rizzo, L. Vicisano, M. Handley, G. Iannaccone
Filename : draft-ietf-rmt-bb-pgmcc-00.txt
Pages : 19
Date : 27-Feb-01
This document describes PGMCC, a single rate multicast
congestion control scheme which is TCP-friendly and achieves
scalability, stability and fast response to variations in
network conditions.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rmt-bb-pgmcc-00.txt
Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-rmt-bb-pgmcc-00.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.
Send a message to:
mailserv@ietf.org.
In the body type:
"FILE /internet-drafts/draft-ietf-rmt-bb-pgmcc-00.txt".
NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv@ietf.org"
Content-Type: text/plain
Content-ID: <20010227124130.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-rmt-bb-pgmcc-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-rmt-bb-pgmcc-00.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <20010227124130.I-D@ietf.org>
--OtherAccess--
--NextPart--
>From owner-rmt@listserv.lbl.gov Sat Mar 3 13:36:36 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.9.3/8.9.3) id NAA28948;
Sat, 3 Mar 2001 13:34:19 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id NAA28944
for <rmt@listserv.lbl.gov>; Sat, 3 Mar 2001 13:34:17 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id NAA05797
for <rmt@listserv.lbl.gov>; Sat, 3 Mar 2001 13:34:17 -0800 (PST)
Received: from phx292636 (cpe-66-1-193-50.co.sprintbbd.net [66.1.193.50])
by SpamWall.lbl.gov (8.9.3/8.9.3) with SMTP id NAA05743
for <rmt@lbl.gov>; Sat, 3 Mar 2001 13:33:45 -0800 (PST)
Message-Id: <200103032133.NAA05743@SpamWall.lbl.gov>
From: "Ralph" <1231309@ito.com>
To: <>
Subject:
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Date: Sat, 3 Mar 2001 13:29:21
Sender: owner-rmt@lbl.gov
Precedence: bulk
Dear Friends & Future Millionaire:
AS SEEN ON NATIONAL TV:
Making over half million dollars every 4 to 5 months right from
your home !!
THANK'S TO THE COMPUTER AGE AND THE INTERNET !
==================================================
BE A MILLIONAIRE LIKE OTHERS WITHIN A YEAR!!!
Before you say ''Bull'', please read the following. This is the
letter you have been hearing about on the news lately. Due to the
popularity of this letter on the Internet, a national weekly news
program recently devoted an entire show to the investigation of
this program described below, to see if it really can make people
money. The show also investigated whether or not the program was
legal. Their findings proved once and for all that there are
''absolutely NO Laws prohibiting the participation in the program
and if people can -follow the simple instructions, they are bound
to make some mega bucks with only $25 out of pocket cost''. DUE
TO THE RECENT INCREASE OF POPULARITY & RESPECT THIS PROGRAM HAS
ATTAINED, IT IS CURRENTLY WORKING BETTER THAN EVER.
This is what one had to say: ''Thanks to this profitable
opportunity. I was approached many times before but each time I
passed on it. I am so glad I finally joined just to see what one
could expect in return for the minimal effort and money required.
To my astonishment, I received total $610,470.00 in 21 weeks,
with money still coming in." Pam Hedland, Fort Lee, New Jersey.
===================================================
Here is another testimonial: "This program has been around for a
long time but I never believed in it. But one day when I received
this again in the mail I decided to gamble my $25 on it. I
followed the simple instructions and walaa ..... 3 weeks later
the money started to come in. First month I only made $240.00 but
the next 2 months after that I made a total of $290,000.00. So
far, in the past 8 months by re-entering the program, I have made
over $710,000.00 and I am playing it again. The key to success in
this program is to follow the simple steps and NOT change
anything.'' More testimonials later but first,
===== PRINT THIS NOW FOR YOUR FUTURE REFERENCE ======
$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
If you would like to make at least $500,000 every 4 to 5 months
easily and comfortably, please read the following...THEN READ IT
AGAIN and AGAIN!!!
$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
FOLLOW THE SIMPLE INSTRUCTION BELOW AND YOUR FINANCIAL
DREAMS WILL COME TRUE, GUARANTEED! INSTRUCTIONS:
=====Order all 5 reports shown on the list below =====
For each report, send $5 CASH, THE NAME & NUMBER OF THE REPORT
YOU ARE ORDERING and YOUR E-MAIL ADDRESS to the person whose
name appears ON THAT LIST next to the report. MAKE SURE YOUR
RETURN ADDRESS IS ON YOUR ENVELOPE TOP LEFT CORNER in case of any
mail problems.
=== When you place your order, make sure you order each of the 5
reports. You will need all 5 reports so that you can save them on
your computer and resell them. YOUR TOTAL COST $5 X 5=$25.00.
Within a few days you will receive, vie e-mail, each of the 5
reports from these 5 different individuals. Save them on your
computer so they will be accessible for you to send to the
1,000's of people who will order them from you. Also make a
floppy of these reports and keep it on your desk in
case something happen to your computer.
IMPORTANT - DO NOT alter the names of the people who are listed
next to each report, or their sequence on the list, in any way
other than what is instructed below in step '' 1 through 6 '' or
you will loose out on majority of your profits. Once you
understand the way this works, you will also see
how it does not work if you change it. Remember, this method has
been tested, and if you alter, it will NOT work !!! People have
tried to put their friends/relatives names on all five thinking
they could get all the money. But it does not work this way.
Believe us, we all have tried to be greedy and then
nothing happened. So Do Not try to change anything other than
what is instructed. Because if you do, it will not work for you.
Remember, honesty reaps the reward!!!
1.... After you have ordered all 5 reports, take this
advertisement and REMOVE the name & address of the person in
REPORT # 5. This person has made it through the cycle and is no
doubt counting their fortune.
2.... Move the name & address in REPORT # 4 down TO REPORT # 5.
3.... Move the name & address in REPORT # 3 down TO REPORT # 4.
4.... Move the name & address in REPORT # 2 down TO REPORT # 3.
5.... Move the name & address in REPORT # 1 down TO REPORT # 2
6.... Insert YOUR name & address in the REPORT # 1 Position.
PLEASE MAKE SURE you copy every name & address ACCURATELY!
==========================================================
**** Take this entire letter, with the modified list of names,
and save it on your computer. DO NOT MAKE ANY OTHER CHANGES.
Save this on a disk as well just in case if you loose any data.
To assist you with marketing your business on the Internet, the 5
reports you purchase will provide you with invaluable marketing
information which includes how to send e-mails legally,
where to find thousands of free classified ads and much more.
There are 2 Primary methods to get this venture going:
METHOD # 1: BY SENDING E-MAIL LEGALLY
==========================================================
Let's say that you decide to start small, just to see how it
goes, and we will assume You and those involved send out only
5,000 e-mails each. Let's also assume that the mailing receive
only a 0.2% response (the response could be much better but lets
just say it is only 0.2%. Also many people will send out hundreds
of thousands e-mails instead of only 5,000 each).
Continuing with this example, you send out only 5,000 e-mails.
With a 0.2% response, that is only 10 orders for report # 1.
Those 10 people responded by sending out 5,000 e-mail each for a
total of 50,000. Out of those 50,000 e-mails only 0.2% responded
with orders. That's=100 people responded and ordered Report # 2.
Those 100 people mail out 5,000 e-mails each for a total of
500,000 e-mails. The 0.2% response to that is 1000 orders for
Report # 3. Those 1000 people send out 5,000 e-mails each for a
total of 5 million e-mails sent out. The 0.2% response to that is
10,000 orders for Report # 4. Those 10,000 people send out 5,000
e-mails each for a total of 50,000,000 (50 million) e-mails. The
0.2% response to that is 100,000 orders for Report # 5 THAT'S
100,000 ORDERS TIMES $5 EACH=$500,000.00 (half million).
Your total income in this example is: 1..... $50 + 2..... $500 +
3..... $5,000 + 4 .... $50,000 + 5..... $500,000 ........ Grand
Total=$555,550.00 NUMBERS DO NOT LIE. GET A PENCIL & PAPER AND
FIGURE OUT THE WORST POSSIBLE RESPONSES AND NO MATTER HOW YOU
CALCULATE IT, YOU WILL STILL MAKE A LOT OF MONEY !
=========================================================
REMEMBER FRIEND, THIS IS ASSUMING ONLY 10 PEOPLE
ORDERING OUT OF 5,000 YOU MAILED TO.
Dare to think for a moment what would happen if everyone or half
or even one 4th of those people mailed 100,000e-mails each or
more? There are over 150 million people on the Internet worldwide
and counting. Believe me, many people will do just that, and
more!
METHOD # 2 : BY PLACING FREE ADS ON THE INTERNET
=======================================================
Advertising on the net is very very inexpensive and there are
hundreds of FREE places to advertise. Placing a lot of free ads
on the Internet will easily get a larger response. We strongly
suggest you start with Method # 1 and progress to METHOD # 2 as you go
along. For every $5 you receive, all you must do is e-mail them
the Report they ordered. That's it. Always provide same day
service on all orders. This will guarantee that the e-mail they
send out, with your name and address on it, will be prompt
because they can not advertise until they receive the report.
=========== AVAILABLE REPORTS ====================
ORDER EACH REPORT BY ITS NUMBER & NAME ONLY. Notes:
Always send $5 cash (U.S. CURRENCY) for each Report. Checks NOT
accepted. Make sure the cash is concealed by wrapping it in at
least 2 sheets of paper. On one of those sheets of paper, Write
the NUMBER & the NAME of the Report you are ordering, YOUR E-MAIL
ADDRESS and your name and postal address.
PLACE YOUR ORDER FOR THESE REPORTS NOW :
====================================================
REPORT # 1: "The Insider's Guide to Advertising for Free on the
Net" Order Report #1 from:
J.R.
PMB No. 166
20165 N 67th AVE Ste 122A
Glendale, AZ 85308-7002
USA
___________________________________________________________
REPORT # 2: "The Insider's Guide to Sending e-mail on the
Net" Order Report # 2 from:
S. Cranke
1503-1500 Walkley Rd
Ottawa, ON
K1V 0H8
Canada
____________________________________________________________
REPORT # 3: "Secret to Multilevel Marketing on the Net"
Order Report # 3 from :
T. Richardson
P.O. Box 753
Richland, MO. 65556
USA
____________________________________________________________
REPORT # 4: "How to Become a Millionaire Utilizing MLM & the Net"
Order Report # 4 from:
C.J. Kalata
P.O. Box 130157
Roseville, MN 55113-0002
USA
____________________________________________________________
REPORT #5: "How to Send Out 0ne Million e-mails for Free"
Order Report # 5 from:
R. B.
Box. 21115,
Grande Prairie
Alberta, T8V-6W7
Canada
_____________________________________________________________
$$$$$$$$$ YOUR SUCCESS GUIDELINES $$$$$$$$$$$
Follow these guidelines to guarantee your success:
=== If you do not receive at least 10 orders for Report #1 within
2 weeks, continue sending e-mails until you do.
=== After you have received 10 orders, 2 to 3 weeks after that
you should receive 100 orders or more for REPORT # 2. If you did
not, continue advertising or sending e-mails until you do.
=== Once you have received 100 or more orders for Report # 2, YOU
CAN RELAX, because the system is already working for you, and the
cash will continue to roll in ! THIS IS IMPORTANT TO REMEMBER:
Every time your name is moved down on the list, you are placed in
front of a Different report.
You can KEEP TRACK of your PROGRESS by watching which report
people are ordering from you. IF YOU WANT TO GENERATE MORE
INCOME SEND ANOTHER BATCH OF E-MAILS AND START
THE WHOLE PROCESS AGAIN.
There is NO LIMIT to the income you can generate from this
business !!!
======================================================
FOLLOWING IS A NOTE FROM THE ORIGINATOR OF THIS
PROGRAM: You have just received information that can give you
financial freedom for the rest of your life, with NO RISK and
JUST A LITTLE BIT OF EFFORT. You can make more money in the next
few weeks and months than you have ever imagined. Follow the
program EXACTLY AS INSTRUCTED. Do Not change it in any way. It
works exceedingly well as it is now.
Remember to e-mail a copy of this exciting report after you have
put your name and address in Report #1 and moved others to #2
..........# 5
as instructed above. One of the people you send this to may send
out 100,000 or more e-mails and your name will be on every one of
them. Remember though, the more you send out the more potential
customers you will reach.
So my friend, I have given you the ideas, information, materials
and opportunity to become financially independent. IT IS UP TO
YOU NOW !
============ MORE TESTIMONIALS ================
"My name is Mitchell. My wife, Jody and I live in Chicago. I am
an accountant with a major U.S. Corporation and I make pretty
good money. When I received this program I grumbled to
Jody about receiving ''junk mail''. I made fun of the whole
thing,spouting my knowledge of the population and percentages
involved. I ''knew'' it wouldn't work. Jody totally ignored
my supposed intelligence and few days later she jumped in with
both feet. I made merciless fun of her, and was ready to lay the
old ''I told you so'' on her when the thing didn't work. Well,
the laugh was on me! Within 3 weeks she had received 50
responses. Within the next 45 days she had received total $
147,200.00 ........... all cash! I was shocked. I have joined
Jody in her ''hobby''. Mitchell Wolf, Chicago, Illinois
======================================================
''Not being the gambling type, it took me several weeks to make
up my mind to participate in this plan. But conservative that I
am, I decided that the initial investment was so little that
there was just no way that I wouldn't get enough orders to at
least get my money back''. '' I was surprised when I found my
medium size post office box crammed with orders. I made
$319,210.00in the first 12 weeks. The nice thing about this deal
is that it does not matter where people live. There simply isn't
a better investment with a faster return and so big."
Dan Sondstrom, Alberta, Canada
=======================================================
''I had received this program before. I deleted it, but later I
wondered if I should have given it a try. Of course, I had no
idea who to contact to get another copy, so I had to wait until I
was e-mailed again by someone else.........11 months passed then
it luckily came again...... I did not delete this one! I made
more than $490,000 on my first try and all the money came within
22 weeks." Susan De Suza, New York, N.Y.
=======================================================
''It really is a great opportunity to make relatively easy money
with little cost to you. I followed the simple instructions
carefully and within 10 days the money started to come in. My
first month I made $20,560.00 and by the end of third month my
total cash count was $362,840.00. Life is beautiful, Thanx to
Internet.". Fred Dellaca, Westport, New Zealand
=======================================================
ORDER YOUR REPORTS TODAY AND GET STARTED ON
'YOUR' ROAD TO FINANCIAL FREEDOM !
=======================================================
If you have any questions of the legality of this program,
contact the Office of Associate Director for Marketing Practices,
Federal Trade Commission, Bureau of Consumer Protection,
Washington, D.C.
>From owner-rmt@listserv.lbl.gov Wed Mar 7 04:49:07 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.9.3) id f27CkhP17946;
Wed, 7 Mar 2001 04:46:43 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f27Ckee17942
for <rmt@listserv.lbl.gov>; Wed, 7 Mar 2001 04:46:40 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id EAA27710
for <rmt@listserv.lbl.gov>; Wed, 7 Mar 2001 04:46:40 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id EAA27705
for <rmt@lbl.gov>; Wed, 7 Mar 2001 04:46:39 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01542;
Wed, 7 Mar 2001 07:46:37 -0500 (EST)
Message-Id: <200103071246.HAA01542@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: rmt@lbl.gov
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-rmt-author-guidelines-01.txt
Date: Wed, 07 Mar 2001 07:46:37 -0500
Sender: owner-rmt@lbl.gov
Precedence: bulk
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Reliable Multicast Transport Working Group of the IETF.
Title : Author Guidelines for RMT Building Blocks and Protocol
Instantiation documents
Author(s) : R. Kermode, L. Vicisano
Filename : draft-ietf-rmt-author-guidelines-01.txt
Pages : 13
Date : 06-Mar-01
This document provides general guidelines to assist the authors of
reliable multicast transport (RMT) building block and protocol
instantiation definitions. The purpose of these guidelines is to ensure
that any building block and protocol instantiation definitions produced
contain sufficient information to fully explain their operation and use.
If followed these guidelines will result in clearly defined RMT building
blocks and protocol instantiation definitions that can be refined and
augmented to create new protocols for use in new scenarios for which any
existing protocols were not designed.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rmt-author-guidelines-01.txt
Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-rmt-author-guidelines-01.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.
Send a message to:
mailserv@ietf.org.
In the body type:
"FILE /internet-drafts/draft-ietf-rmt-author-guidelines-01.txt".
NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv@ietf.org"
Content-Type: text/plain
Content-ID: <20010306125914.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-rmt-author-guidelines-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-rmt-author-guidelines-01.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <20010306125914.I-D@ietf.org>
--OtherAccess--
--NextPart--
>From owner-rmt@listserv.lbl.gov Thu Mar 8 03:59:13 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.9.3) id f28BwI524426;
Thu, 8 Mar 2001 03:58:18 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f28BwHe24422
for <rmt@listserv.lbl.gov>; Thu, 8 Mar 2001 03:58:17 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id DAA12281
for <rmt@listserv.lbl.gov>; Thu, 8 Mar 2001 03:58:16 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id DAA12276
for <rmt@lbl.gov>; Thu, 8 Mar 2001 03:58:15 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22543;
Thu, 8 Mar 2001 06:58:13 -0500 (EST)
Message-Id: <200103081158.GAA22543@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: rmt@lbl.gov
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-rmt-bb-tree-config-02.txt
Date: Thu, 08 Mar 2001 06:58:13 -0500
Sender: owner-rmt@lbl.gov
Precedence: bulk
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Reliable Multicast Transport Working Group of the IETF.
Title : Reliable Multicast Transport Building Block: Tree
Auto-Configuration
Author(s) : M. Kadansky, B. Levine, D. Chiu, B. Whetten,
G. Taskale, B. Cain, D. Thaler, S. Koh
Filename : draft-ietf-rmt-bb-tree-config-02.txt
Pages : 25
Date : 07-Mar-01
The Reliable Multicast Transport Working Group has been chartered to
standardize multicast transport services. This working group expects
to initially standardize three protocol instantiations. This draft is
concerned with the requirements of the tree-based ACK protocol. In
particular, it is concerned with defining the building block for
auto-configuration of the logical ACK-tree. According to the charter,
a building block is 'a coarse-grained modular component that is
common to multiple protocols along with abstract APIs that define a
building block's access methods and their arguments.' For more
information, see the Reliable Multicast Transport Building Blocks and
Reliable Multicast Design Space documents [WLKHFL00][HWKFV00].
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rmt-bb-tree-config-02.txt
Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-rmt-bb-tree-config-02.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.
Send a message to:
mailserv@ietf.org.
In the body type:
"FILE /internet-drafts/draft-ietf-rmt-bb-tree-config-02.txt".
NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv@ietf.org"
Content-Type: text/plain
Content-ID: <20010307142942.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-rmt-bb-tree-config-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-rmt-bb-tree-config-02.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <20010307142942.I-D@ietf.org>
--OtherAccess--
--NextPart--
>From owner-rmt@listserv.lbl.gov Thu Mar 8 03:59:14 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.9.3) id f28BwFN24420;
Thu, 8 Mar 2001 03:58:15 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f28BwDe24416
for <rmt@listserv.lbl.gov>; Thu, 8 Mar 2001 03:58:13 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id DAA12268
for <rmt@listserv.lbl.gov>; Thu, 8 Mar 2001 03:58:12 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id DAA12265
for <rmt@lbl.gov>; Thu, 8 Mar 2001 03:58:11 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22526;
Thu, 8 Mar 2001 06:58:09 -0500 (EST)
Message-Id: <200103081158.GAA22526@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: rmt@lbl.gov
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-rmt-bb-track-01.txt
Date: Thu, 08 Mar 2001 06:58:08 -0500
Sender: owner-rmt@lbl.gov
Precedence: bulk
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Reliable Multicast Transport Working Group of the IETF.
Title : Reliable Multicast Transport Building Block for TRACK
Author(s) : B. Whetten, D. Chiu, M. Kadansky, G. Taskale
Filename : draft-ietf-rmt-bb-track-01.txt
Pages : 29
Date : 07-Mar-01
This document describes the TRACK Building Block. It contains
functions relating to positive acknowledgments and hierarchical
tree construction and maintenance. It is primarily meant to be
used as part of the TRACK Protocol Instantiation. It is also
designed to be useful as part of overlay multicast systems that
wish to offer efficient confirmed delivery of multicast messages.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rmt-bb-track-01.txt
Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-rmt-bb-track-01.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.
Send a message to:
mailserv@ietf.org.
In the body type:
"FILE /internet-drafts/draft-ietf-rmt-bb-track-01.txt".
NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv@ietf.org"
Content-Type: text/plain
Content-ID: <20010307142929.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-rmt-bb-track-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-rmt-bb-track-01.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <20010307142929.I-D@ietf.org>
--OtherAccess--
--NextPart--
>From owner-rmt@listserv.lbl.gov Fri Mar 9 04:40:40 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.9.3) id f29CbJp01157;
Fri, 9 Mar 2001 04:37:19 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f29CbHn01153
for <rmt@listserv.lbl.gov>; Fri, 9 Mar 2001 04:37:17 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id EAA13524
for <rmt@listserv.lbl.gov>; Fri, 9 Mar 2001 04:37:16 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id EAA13521
for <rmt@lbl.gov>; Fri, 9 Mar 2001 04:37:15 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11811;
Fri, 9 Mar 2001 07:37:12 -0500 (EST)
Message-Id: <200103091237.HAA11811@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: rmt@lbl.gov
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-rmt-pi-norm-01.txt
Date: Fri, 09 Mar 2001 07:37:12 -0500
Sender: owner-rmt@lbl.gov
Precedence: bulk
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Reliable Multicast Transport Working Group of the IETF.
Title : NACK-Oriented Reliable Multicast Protocol (NORM)
Author(s) : B. Adamson, C. Bormann, S. Floyd, M. Handley,
J. Macker
Filename : draft-ietf-rmt-pi-norm-01.txt
Pages : 27
Date : 08-Mar-01
This document describes the messages and procedures of the Nega-
tive-acknowledgement (NACK) oriented reliable multicast (NORM).
This revision of the document represents an initial outline of the
protocol description. The document requires refinement in a number
of areas to be considered complete. At this time, the document
describes the high level details of the reliable multicast bulk
transfer service model this protocol hopes to fulfill and the gen-
eral message types and mechanisms which will be used to accomplish
those goals.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rmt-pi-norm-01.txt
Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-rmt-pi-norm-01.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.
Send a message to:
mailserv@ietf.org.
In the body type:
"FILE /internet-drafts/draft-ietf-rmt-pi-norm-01.txt".
NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv@ietf.org"
Content-Type: text/plain
Content-ID: <20010308111127.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-rmt-pi-norm-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-rmt-pi-norm-01.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <20010308111127.I-D@ietf.org>
--OtherAccess--
--NextPart--
>From owner-rmt@listserv.lbl.gov Sun Mar 11 07:01:00 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.9.3) id f2BEvRV17321;
Sun, 11 Mar 2001 06:57:28 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f2BEvQn17317
for <rmt@listserv.lbl.gov>; Sun, 11 Mar 2001 06:57:26 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id GAA00841
for <rmt@listserv.lbl.gov>; Sun, 11 Mar 2001 06:57:25 -0800 (PST)
Received: from pop136-mc.mail.com (pop136-mc.mail.com [165.251.48.111])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id GAA00838
for <rmt@lbl.gov>; Sun, 11 Mar 2001 06:57:25 -0800 (PST)
Received: from localhost (cc410790-a.srst1.fl.home.com [24.13.212.54])
by pop136-mc.mail.com (Postfix) with ESMTP id 0467698BA
for <rmt@lbl.gov>; Sun, 11 Mar 2001 09:57:20 -0500 (EST)
X-Sender: res02mg1@gte.net
From: David Dickson <res02mg1@gte.net>
To: rmt@lbl.gov
Date: Sun, 11 Mar 2001 09:52:44 -0500
Subject: Security Training Course Availability - Unix Countermeasures, Intrusion Detection, Network Security - Wash DC area
Reply-To: res02mg1@gte.net
Organization: Market*Access
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Message-Id: <20010311145720.0467698BA@pop136-mc.mail.com>
Sender: owner-rmt@lbl.gov
Precedence: bulk
To: rmt@lbl.gov
PLEASE FORWARD THIS MESSAGE TO YOUR AGENCY PERSONNEL INVOLVED WITH NETWORK and
IT SECURITY TRAINING.
The following THREE courses are available now. See our web site for course dates,
prerequisites and more details on course content. Visit www.marketaccess.org
and the courses will be listed at our home page along with dates available.
Course One: Network Security for Managers - Two day course
Course Outline:
Introduction
Security History (famous attacks)
Security Principles
Common Attacks
Discussion on the most common attacks today and how they relate to each security
principle
Find out what can happen to your network as a result
Demonstration of these attacks - see first-hand how they are executed
Protection
Risk Assessment: in-depth coverage on every aspect of a network
Vulnerability Prevention: common mistakes made by administrators
Discussion on network security tools and their purpose
Steps and recommendations to secure your network
Web Site and Server Protection
Find out what might be compromised and obtain advice on how to prevent such loss
Budget Analysis
Discussion on the "bottom line"
Security Policy
Why you need one and who should be involved
In-depth coverage of the topics which should be addressed in an effective policy
Incident Handling
Detailed discussion on the necessary steps to take if something happens
Network Security for Managers - Fee: $695.00
Course Two: UNIX Countermeasures - 5 Days (Hands-on)
Course Highlights
Identification & Authentication (I&A) -- Learn various methods of I&A including
their weaknesses, if any, to include simple passwords, skey, and strong bind
Discretionary Access Control (DAC) -- Learn what DAC is and how it can be used
to make the operating system more resistant to unauthorized access
Audit -- Learn how to configure UNIX platforms where audit files are meaningful
as well as how to add extra program audit capabilities
Network Services
Gain extensive knowledge about various network services and how to configure
them securely using TCP wrappers or the new super daemon caked XINITD. The following
are some of the services that students will configure in class:
Samba (NT file sharing)
NFS (UNIX file sharing)
HTTP
Secure Shell
Network Time Protocol (NTP)
Unix Countermeasures - Government Fee $2,475.00
Course Three: Intro to Network Security and Intrusion Detection - 5 days - Hands
on
Course Outline
Introduction (Hands-On)
Quick familiarization of Linux
Gain super-user access with a password cracker
Security History (Lecture)
Security, in general
Discussion of significant security events
Definition of terms
Intrusion Detection (Mostly Hands-On)
Discussion of how logs and various tools can be used to detect unauthorized activities
Hands-on experience with three different sniffers
How to read audit files
Hands-on experience with several system commands and various tools to detect
unauthorized activity
Reconnaissance (Hands-On)
Students will learn how to scan and detect scans from several different manual,
as well as automated tools including:
Basic UNIX commands
Nmap
ISS
NetCat
Sendmail Version Scan
Low-Level Access (Hands-On)
Students will run a series of several ^Óattacks and detect labs^Ô to gain low-level
access to various servers. Examples of the exploits include:
HTTP Remote Buffer Overflow
NFS Attack
NIS Attack
X Windows Attack
DNS Spoofing
Privileged Access (Hands-On)
Students will use their low-level access knowledge gained in previous labs to
gain access as a super user. Some exploits they will perform and detect include:
IMAP Buffer Overflow
DIP Buffer Overflow
EUID Buffer Overflow
Covert Access (Hands-On & Discussion)
Although covert access is often difficult to detect, students will learn how
to recognize when someone is using a covert channel. They will also learn how
intruders conceal their real identity and hide in normal network traffic from
being detected by Intrusion Detection Systems and Audit Logs. Following are examples
of which the students will gain hands-on experience:
UNIX Shell Games
NetCat
ICMP Covert Channel
Trojan Horses
NetBus
Back Orifice
Denial of Service (Hands-On & Discussion)
These attacks are commonly executed on today's networks and are often difficult
to trace back to the actual attacker. However, sometimes the evidence needed
can be found in your Audit System. Students will learn how these attacks work
and how to detect them. Examples of some attacks students will learn to perform
and detect include:
Land Attack
UDP Bomb
Smurf Attack
Course Fee - Intro to Network Security and Intrusion Detection - 5 days - Hands
on - Government Rate: $2,475.00
For more information on these courses or to register, call Margo McPhee, Verizon
Federal Network Systems (formerly BBN) at 1-800-334-1553.
>From owner-rmt@listserv.lbl.gov Sun Mar 11 12:18:41 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.9.3) id f2BKHeG17721;
Sun, 11 Mar 2001 12:17:40 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f2BKHbn17717
for <rmt@listserv.lbl.gov>; Sun, 11 Mar 2001 12:17:38 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id MAA16614
for <rmt@listserv.lbl.gov>; Sun, 11 Mar 2001 12:17:36 -0800 (PST)
Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id MAA16601
for <rmt@lbl.gov>; Sun, 11 Mar 2001 12:17:35 -0800 (PST)
Received: (from sob@localhost)
by newdev.harvard.edu (8.9.3/8.9.3) id PAA18813;
Sun, 11 Mar 2001 15:16:44 -0500 (EST)
Date: Sun, 11 Mar 2001 15:16:44 -0500 (EST)
From: Scott Bradner <sob@harvard.edu>
Message-Id: <200103112016.PAA18813@newdev.harvard.edu>
To: ark008@email.mot.com, lorenzo@cisco.com, mankin@east.isi.edu, rmt@lbl.gov
Subject: PGM Reliable Transport Protocol
Sender: owner-rmt@lbl.gov
Precedence: bulk
To the RGT Chairs and Working Group
The IESG has been asked to evaluate the publication of "PGM Reliable
Transport Protocol" <draft-speakman-pgm-spec-06.txt> as an Experimental
RFC. This is clearly in the realm of the RMT working group but it seems as
if the working group has abandoned this genre of RMT technologies. My
feeling is based on the expiration of the Generic Router Assist documents
and their absence from your agenda in recent meetings. Am I
understanding working group's interest accurately?
If that is the case then the right process would seem to be that the
Transport ADs should evaluate this (and possibly other proposals in the
same genre) against the requirements in RFC 2357 and make a recommendation
to the IESG about the suitability of publishing the Internet Draft as an
RFC.
If indeed the working group is interested in doing work in this space this
Internet Draft should be refereed to the Working Group for consideration.
advice please
Scott
Area Director for RMT
>From owner-rmt@listserv.lbl.gov Mon Mar 12 00:14:53 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.9.3) id f2C8Dj619044;
Mon, 12 Mar 2001 00:13:45 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f2C8Dhn19040
for <rmt@listserv.lbl.gov>; Mon, 12 Mar 2001 00:13:43 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id AAA02201
for <rmt@listserv.lbl.gov>; Mon, 12 Mar 2001 00:13:42 -0800 (PST)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
by SpamWall.lbl.gov (8.9.3/8.9.3) with SMTP id AAA02198
for <rmt@lbl.gov>; Mon, 12 Mar 2001 00:13:41 -0800 (PST)
Received: from hocus.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP
id <g.03062-0@bells.cs.ucl.ac.uk>; Mon, 12 Mar 2001 08:13:17 +0000
To: Scott Bradner <sob@harvard.edu>
cc: ark008@email.mot.com, lorenzo@cisco.com, mankin@east.isi.edu, rmt@lbl.gov,
J.Crowcroft@cs.ucl.ac.uk
Subject: Re: PGM Reliable Transport Protocol
In-reply-to: Your message of "Sun, 11 Mar 2001 15:16:44 EST." <200103112016.PAA18813@newdev.harvard.edu>
Date: Mon, 12 Mar 2001 08:13:14 +0000
Message-ID: <791.984384794@cs.ucl.ac.uk>
From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
Sender: owner-rmt@lbl.gov
Precedence: bulk
In message <200103112016.PAA18813@newdev.harvard.edu>, Scott Bradner typed:
>>To the RGT Chairs and Working Group
>>The IESG has been asked to evaluate the publication of "PGM Reliable
>>Transport Protocol" <draft-speakman-pgm-spec-06.txt> as an Experimental
>>RFC. This is clearly in the realm of the RMT working group but it seems as
>>if the working group has abandoned this genre of RMT technologies. My
>>feeling is based on the expiration of the Generic Router Assist documents
>>and their absence from your agenda in recent meetings. Am I
>>understanding working group's interest accurately?
>>If that is the case then the right process would seem to be that the
>>Transport ADs should evaluate this (and possibly other proposals in the
>>same genre) against the requirements in RFC 2357 and make a recommendation
>>to the IESG about the suitability of publishing the Internet Draft as an
>>RFC.
>>If indeed the working group is interested in doing work in this space this
>>Internet Draft should be refereed to the Working Group for consideration.
>>advice please
Scott
i can't speak for anyone except me, but I think you have to divide the
GRA generic work from the PGM specific work - GRA lost some of its
general momentum only because we have plenty else to do first and
specifically because of change of afiliation (i believe) of one
the key designers - my group at UCL would be working on GRA if we
weren't so busy on nearer term things for now...
pgm is live and kicking as an instance of it...
so if you like, its kind of a cart before a horse (examplar before
general building block) but i don't want that to sound negative - i am
positive about pgm (it does congestion control for example) and has a
lot of RMT folks involved.....
but i gess the WG chairs will have more to say...
cheers
jon
>From owner-rmt@listserv.lbl.gov Mon Mar 12 07:31:25 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.9.3) id f2CFShH20622;
Mon, 12 Mar 2001 07:28:43 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f2CFSfn20618
for <rmt@listserv.lbl.gov>; Mon, 12 Mar 2001 07:28:41 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id HAA18948
for <rmt@listserv.lbl.gov>; Mon, 12 Mar 2001 07:28:40 -0800 (PST)
Received: from cisco.com (cypher.cisco.com [171.69.11.18])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id HAA18943
for <rmt@lbl.gov>; Mon, 12 Mar 2001 07:28:39 -0800 (PST)
Received: from localhost (speakman@localhost)
by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id HAA09885;
Mon, 12 Mar 2001 07:27:00 -0800 (PST)
Message-Id: <200103121527.HAA09885@cisco.com>
To: Scott Bradner <sob@harvard.edu>
cc: ark008@email.mot.com, lorenzo@cisco.com, mankin@east.isi.edu, rmt@lbl.gov,
calvert@dcs.uky.edu
Subject: Re: PGM Reliable Transport Protocol
Mime-Version: 1.0 (generated by tm-edit 7.105)
Content-Type: text/plain; charset=US-ASCII
Date: Mon, 12 Mar 2001 07:27:00 -0800
From: Tony Speakman <speakman@cisco.com>
Sender: owner-rmt@lbl.gov
Precedence: bulk
> The IESG has been asked to evaluate the publication of "PGM Reliable
> Transport Protocol" <draft-speakman-pgm-spec-06.txt> as an Experimental
> RFC. This is clearly in the realm of the RMT working group but it seems as
> if the working group has abandoned this genre of RMT technologies. My
> feeling is based on the expiration of the Generic Router Assist documents
> and their absence from your agenda in recent meetings. Am I
> understanding working group's interest accurately?
The GRA work has just been side-lined for a while by the authors'
other priorities. There were multiple references to it (and
inquiries about it) at the last IETF, and the authors will plan
to get together at the Minneapolis IETF to pick up where we
left off. In preparation for that, I have gone over the relevant
RMT documents, the old GRA draft, and Ken Calvert's concast
draft to come up with a document plan for the next set of drafts
we should be working on.
Tony S
> If that is the case then the right process would seem to be that the
> Transport ADs should evaluate this (and possibly other proposals in the
> same genre) against the requirements in RFC 2357 and make a recommendation
> to the IESG about the suitability of publishing the Internet Draft as an
> RFC.
>
> If indeed the working group is interested in doing work in this space this
> Internet Draft should be refereed to the Working Group for consideration.
>
> advice please
>
> Scott
> Area Director for RMT
>From owner-rmt@listserv.lbl.gov Mon Mar 12 11:11:26 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.9.3) id f2CJ8vv22236;
Mon, 12 Mar 2001 11:08:57 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f2CJ8on22232
for <rmt@listserv.lbl.gov>; Mon, 12 Mar 2001 11:08:50 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id LAA12761
for <rmt@listserv.lbl.gov>; Mon, 12 Mar 2001 11:08:43 -0800 (PST)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88])
by SpamWall.lbl.gov (8.9.3/8.9.3) with ESMTP id LAA12757
for <rmt@lbl.gov>; Mon, 12 Mar 2001 11:08:43 -0800 (PST)
Received: from lorenzo-u10.cisco.com (lorenzo-u10.cisco.com [10.34.54.43])
by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id LAA19069;
Mon, 12 Mar 2001 11:08:32 -0800 (PST)
Received: from localhost (lorenzo@localhost) by lorenzo-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id LAA11688; Mon, 12 Mar 2001 11:08:12 -0800 (PST)
Message-Id: <200103121908.LAA11688@lorenzo-u10.cisco.com>
X-Authentication-Warning: lorenzo-u10.cisco.com: lorenzo owned process doing -bs
X-Mailer: exmh version 2.0.2 2/24/98
To: Scott Bradner <sob@harvard.edu>
cc: ark008@email.mot.com, mankin@east.isi.edu, rmt@lbl.gov
Subject: Re: PGM Reliable Transport Protocol
In-Reply-To: Your message of "Sun, 11 Mar 2001 15:16:44 EST."
<200103112016.PAA18813@newdev.harvard.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 12 Mar 2001 11:08:12 -0800
From: Lorenzo Vicisano <lorenzo@cisco.com>
Sender: owner-rmt@lbl.gov
Precedence: bulk
Scott,
The Working Group has not abandoned GRA, however
the work on this is still at a very early stage. Given the challenges
that we will be facing, i.e. mechanism abstraction, hardware constraints,
deployment concerns, I think that coming up with a good solution
will be a hard task that will require more time than we expected.
I don't think that we can consider PGM as a replacement for GRA,
both because it is focused on a single mechanism (NAK aggregation)
and because does not fit the RMT architecture. Hence my opinion is
that the ADs evaluate the PGM draft independently from the WG as a
non-standard track candidate.
Lorenzo
> The IESG has been asked to evaluate the publication of "PGM Reliable
> Transport Protocol" <draft-speakman-pgm-spec-06.txt> as an Experimental
> RFC. This is clearly in the realm of the RMT working group but it seems as
> if the working group has abandoned this genre of RMT technologies. My
> feeling is based on the expiration of the Generic Router Assist documents
> and their absence from your agenda in recent meetings. Am I
> understanding working group's interest accurately?
>
> If that is the case then the right process would seem to be that the
> Transport ADs should evaluate this (and possibly other proposals in the
> same genre) against the requirements in RFC 2357 and make a recommendation
> to the IESG about the suitability of publishing the Internet Draft as an
> RFC.
>
> If indeed the working group is interested in doing work in this space this
> Internet Draft should be refereed to the Working Group for consideration.
>
> advice please
>
> Scott
> Area Director for RMT
>From owner-rmt@listserv.lbl.gov Fri Mar 16 05:18:20 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.9.3) id f2GDFWd26637;
Fri, 16 Mar 2001 05:15:32 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f2GDFUn26633
for <rmt@listserv.lbl.gov>; Fri, 16 Mar 2001 05:15:30 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.9.3) with ESMTP id f2GDFTs23491
for <rmt@listserv.lbl.gov>; Fri, 16 Mar 2001 05:15:29 -0800 (PST)
Received: from pi4.informatik.uni-mannheim.de (root@pi4.informatik.uni-mannheim.de [134.155.48.96])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f2GDFRE23485
for <rmt@lbl.gov>; Fri, 16 Mar 2001 05:15:28 -0800 (PST)
Received: from informatik.uni-mannheim.de (mauve@pi4 [134.155.48.96])
by pi4.informatik.uni-mannheim.de (8.9.3/8.9.3) with ESMTP id OAA04734
for <rmt@lbl.gov>; Fri, 16 Mar 2001 14:15:21 +0100 (MET)
Message-ID: <3AB211E8.7EC89A4C@informatik.uni-mannheim.de>
Date: Fri, 16 Mar 2001 14:15:20 +0100
From: Martin Mauve <mauve@informatik.uni-mannheim.de>
Organization: University of Mannheim
X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: rmt@lbl.gov
Subject: SIG on Networked Computer Games
Content-Type: multipart/mixed;
boundary="------------F5E10FCBA5C9F0B85FDDC3FC"
Sender: owner-rmt@lbl.gov
Precedence: bulk
This is a multi-part message in MIME format.
--------------F5E10FCBA5C9F0B85FDDC3FC
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Hi all,
I'm posting this to rmt since networked computer games have already been
a topic here.
cheers,
Martin
--------------F5E10FCBA5C9F0B85FDDC3FC
Content-Type: text/plain; charset=us-ascii;
name="NetGameNew.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="NetGameNew.txt"
Call for Participation
Special Interest Group on Networked Computer Games (SIG NetGame)
Over the past three to four years networked computer games have been a
tremendous commercial success. Games like Ultima Online, Everquest, Doom,
Quake, Diablo II and others have attracted an audience of several million players,
worldwide. They are one of the few Internet services for which end users are
actually willing to pay money. As the Internet becomes ubiquitous through wireless
and/or cheaper Internet access the the audience for networked computer games will
increase rapidly, creating a mass market with a multi-billion dollar volume.
However, most - if not all - of the successful networked computer games have
encountered a large number of technical challenges that are inherent to this
application area. These range from inadequate support by network and transport
protocols to consistency problems and security breaches (or cheating as players
prefer to call it). At the same time scientists have begun to discover networked
computer games as an extremely challenging and rewarding area of research. What
makes this area of research particularly fascinating is that solutions found for
networked computer games tend to solve related problems in other areas such as
computer supported collaborative work, distance education and telemedicine.
It is the aim of this SIG to bring together developers of commercial and
non-commercial networked computer games, service providers, scientists, and
interested individuals in order to discuss - and possibly solve - technical challenges
of networked computer games. Topics of interest include, but are certainly not
limited to:
- network and transport protocols
- application-level protocol design
- architectures for service providers
- consistency mechanisms
- security / cheating prevention
- middle-ware (e.g. Direct Play)
- billing and charging
... for networked computer games.
You can subscribe to the NetGame mailing list through the NetGame
webpage:
http://www.informatik.uni-mannheim.de/netgame/index.html
or by sending a mail to:
netgame-l-request@pi4.informatik.uni-mannheim.de
with the following line in the BODY of the message:
subscribe
I'm looking forward to interesting discussions on netgame-l.
Sincerely,
Martin Mauve
Disclaimer: This SIG is currently not affiliated with any other
organization.
--------------F5E10FCBA5C9F0B85FDDC3FC--
>From owner-rmt@listserv.lbl.gov Fri Mar 16 09:49:36 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.9.3) id f2GHn1L28104;
Fri, 16 Mar 2001 09:49:01 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f2GHmxn28100
for <rmt@listserv.lbl.gov>; Fri, 16 Mar 2001 09:48:59 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.9.3) with ESMTP id f2GHmwD23244
for <rmt@listserv.lbl.gov>; Fri, 16 Mar 2001 09:48:58 -0800 (PST)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f2GHmwE23239
for <rmt@lbl.gov>; Fri, 16 Mar 2001 09:48:58 -0800 (PST)
Received: from lorenzo-u10.cisco.com (lorenzo-u10.cisco.com [10.34.54.43])
by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id JAA18682
for <rmt@lbl.gov>; Fri, 16 Mar 2001 09:48:56 -0800 (PST)
Received: from localhost (lorenzo@localhost) by lorenzo-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id JAA19118 for <rmt@lbl.gov>; Fri, 16 Mar 2001 09:48:52 -0800 (PST)
Message-Id: <200103161748.JAA19118@lorenzo-u10.cisco.com>
X-Authentication-Warning: lorenzo-u10.cisco.com: lorenzo owned process doing -bs
X-Mailer: exmh version 2.0.2 2/24/98
To: rmt@lbl.gov
Subject: call for agenda items
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 16 Mar 2001 09:48:52 -0800
From: Lorenzo Vicisano <lorenzo@cisco.com>
Sender: owner-rmt@lbl.gov
Precedence: bulk
Although we are late for the official agenda, we still have to
put one together..
The items I'm aware of are:
Updates on draft-ietf-rmt-author-guidelines-01.txt 5 mins
Kermode/Vicisano
draft-ietf-rmt-bb-pgmcc-00.txt, CC proposal for NORM 15 mins
Vicisano
draft-koh-rmt-bb-tsm-01.txt 10 mins
Seok Joo Koh
Please send me request for additions.
Also, we would like to have a representative for each PI + one for
GRA to give a brief report on the status of the works:
- List of BBs identified
- PI document
- Other documents (e.g. architectural docs.)
- status of advancement and responsible editors
... so that we will be able to update the WG milestones.
thanks,
the RMT chairs
>From owner-rmt@listserv.lbl.gov Fri Mar 16 21:24:11 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.9.3) id f2H5NKn29047;
Fri, 16 Mar 2001 21:23:20 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f2H5NIn29043
for <rmt@listserv.lbl.gov>; Fri, 16 Mar 2001 21:23:18 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.9.3) with ESMTP id f2H5NIE15779
for <rmt@listserv.lbl.gov>; Fri, 16 Mar 2001 21:23:18 -0800 (PST)
Received: from pec.etri.re.kr (pec.etri.re.kr [129.254.164.217])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f2H5NFE15776
for <rmt@lbl.gov>; Fri, 16 Mar 2001 21:23:15 -0800 (PST)
Received: from sjkoh (sjkoh.etri.re.kr [129.254.164.46])
by pec.etri.re.kr (8.10.0/8.10.0) with SMTP id f2H5NUT09275;
Sat, 17 Mar 2001 14:23:30 +0900 (KST)
Message-ID: <002101c0aea2$d089ca40$2ea4fe81@etri.re.kr>
Reply-To: "Seok Joo Koh" <sjkoh@pec.etri.re.kr>
From: "Seok Joo Koh" <sjkoh@pec.etri.re.kr>
To: <rmt@lbl.gov>, "Lorenzo Vicisano" <lorenzo@cisco.com>
References: <200103161748.JAA19118@lorenzo-u10.cisco.com>
Subject: draft-koh-rmt-bb-tsm-01.txt
Date: Sat, 17 Mar 2001 14:26:26 +0900
Organization: ETRI/PEC
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="----=_NextPart_000_001E_01C0AEEE.401D85E0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-rmt@lbl.gov
Precedence: bulk
This is a multi-part message in MIME format.
------=_NextPart_000_001E_01C0AEEE.401D85E0
Content-Type: text/plain;
charset="ks_c_5601-1987"
Content-Transfer-Encoding: 7bit
Dear all,
Please see the attached TSM draft, which is going to be discussed in this
RMT meeting.
It can also be obtained from
http://pec.etri.re.kr/~sjkoh/draft-koh-rmt-bb-tsm-01.txt
Best Regards,
Seok Joo Koh
ETRI/PEC
sjkoh@pec.etri.re.kr
----- Original Message -----
From: "Lorenzo Vicisano" <lorenzo@cisco.com>
To: <rmt@lbl.gov>
Sent: Saturday, March 17, 2001 2:48 AM
Subject: call for agenda items
> Although we are late for the official agenda, we still have to
> put one together..
>
> The items I'm aware of are:
>
> Updates on draft-ietf-rmt-author-guidelines-01.txt 5 mins
> Kermode/Vicisano
> draft-ietf-rmt-bb-pgmcc-00.txt, CC proposal for NORM 15 mins
> Vicisano
> draft-koh-rmt-bb-tsm-01.txt 10 mins
> Seok Joo Koh
>
> Please send me request for additions.
>
> Also, we would like to have a representative for each PI + one for
> GRA to give a brief report on the status of the works:
>
> - List of BBs identified
> - PI document
> - Other documents (e.g. architectural docs.)
> - status of advancement and responsible editors
>
> ... so that we will be able to update the WG milestones.
>
> thanks,
> the RMT chairs
>
------=_NextPart_000_001E_01C0AEEE.401D85E0
Content-Type: text/plain;
name="draft-koh-rmt-bb-tsm-01.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
filename="draft-koh-rmt-bb-tsm-01.txt"
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
Internet Draft Seok Joo Koh, ETRI/KOREA=0A=
Document: draft-koh-rmt-bb-tsm-01.txt Shin Gak Kang, ETRI/KOREA=0A=
February 2001 Juyoung Park, ETRI/KOREA=0A=
Expires August 2001 Eunsook Kim, ETRI/KOREA=0A=
=0A=
=0A=
Reliable Multicast Transport Building Blocks:=0A=
Transport Session Management=0A=
<draft-koh-rmt-bb-tsm-01.txt>=0A=
=0A=
=0A=
Status of this Memo=0A=
=0A=
This document is an Internet-Draft and is in full conformance with=0A=
all provisions of Section 10 of RFC2026.=0A=
=0A=
Internet-Drafts are working documents of the Internet Engineering=0A=
Task Force (IETF), its areas, and its working groups. Note that=0A=
other groups may also distribute working documents as Internet-=0A=
Drafts. Internet-Drafts are draft documents valid for a maximum of=0A=
six months and may be updated, replaced, or obsoleted by other=0A=
documents at any time. It is inappropriate to use Internet-Drafts as=0A=
reference material or to cite them other than as "work in progress."=0A=
=0A=
The list of current Internet-Drafts can be accessed at=0A=
http://www.ietf.org/ietf/1id-abstracts.txt.=0A=
=0A=
The list of Internet-Draft Shadow Directories can be accessed at=0A=
http://www.ietf.org/shadow.html.=0A=
=0A=
=0A=
=0A=
Abstract=0A=
=0A=
Transport Session Management (TSM) is designed to support desirable=0A=
management of end-to-end multicast sessions including the membership=0A=
tracking for billing/charging and the group key management, according=0A=
to the application's requirements that are represented as a set of=0A=
TSM parameters including throughput and packet loss rate. TSM=0A=
operations include Session Register, Session Monitoring and Session=0A=
Maintenance. In Session Register, the sender informs authorized=0A=
receivers about the target values of TSM parameters. In Session=0A=
Monitoring, each receiver continues to measure the parameter values=0A=
that have been experienced and to report the status of each parameter=0A=
value to the sender. Based on the status information monitored and=0A=
the target values of TSM parameters, the sender takes Session=0A=
Maintenance actions necessary to maintain the session status=0A=
desirable. Those actions include adjustment of data transmission=0A=
=0A=
=0A=
=0A=
Koh, et al. draft-koh-rmt-bb-tsm-01.txt [Page 1]=0A=
=0C=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
INTERNET-DRAFT Expires: August 2001 February 2001=0A=
=0A=
=0A=
rate, troublemaker ejection, session pause/resume, and session=0A=
termination. TSM mechanisms can be implemented into an API and=0A=
easily adopted by any RMT PIs that wish to tightly control multicast=0A=
sessions.=0A=
=0A=
=0A=
1. Introduction=0A=
=0A=
A multicast transport protocol instantiation may include various=0A=
protocol components such as error recovery, flow and congestion=0A=
control, membership management, and session management [RMT-DS, RMT-=0A=
BB].=0A=
=0A=
This document provides a framework of Transport Session Management=0A=
(TSM) mechanisms, which has been designed to support desirable=0A=
management of end-to-end multicast sessions, according to the=0A=
application's requirements that are represented as a set of TSM=0A=
parameters including throughput and packet loss rate. TSM operations=0A=
include Session Register, Session Monitoring and Session Maintenance.=0A=
In Session Register, the sender informs authorized receivers about=0A=
the target values of TSM parameters. In Session Monitoring, each=0A=
receiver continues to measure the parameter values that have been=0A=
experienced and to report the status of each parameter value to the=0A=
sender. Based on the status information monitored and the target=0A=
values of TSM parameters, the sender takes Session Maintenance=0A=
actions necessary to maintain the session status desirable. Those=0A=
actions include adjustment of data transmission rate, troublemaker=0A=
ejection, session pause/resume, and session termination.=0A=
=0A=
The key feature of TSM is to provide the senders with information on=0A=
membership tracking and current session status in terms of TSM=0A=
parameters. Membership information is crucial for design of=0A=
billing/charging model. Session status needs to be monitored to=0A=
maintain the session desirable.=0A=
=0A=
TSM is a coarsely grained functionality for end-to-end multicast=0A=
transport, and thus can be considered as a Building Block of RMT.=0A=
TSM mechanisms can be implemented into an API and easily adopted by=0A=
any RMT PIs that wish to tightly control multicast sessions.=0A=
=0A=
1.1 Terminology=0A=
=0A=
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=0A=
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this=0A=
document are to be interpreted as described in RFC 2119 [RFC2119].=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
Koh, et al. draft-koh-rmt-bb-tsm-01.txt [Page 2]=0A=
=0C=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
INTERNET-DRAFT Expires: August 2001 February 2001=0A=
=0A=
=0A=
Transport Session=0A=
=0A=
Transport Session refers to a session for multicast data delivery.=0A=
In a one-to-many multicast session, there are a single sender and=0A=
many receivers.=0A=
=0A=
Transport Session Management (TSM)=0A=
=0A=
TSM functionality is provided to maintain a multicast session=0A=
desirable, according to application's requirements. TSM mechanisms=0A=
can be implemented into an API that a multicast transport protocol=0A=
adopts easily.=0A=
=0A=
TSM Parameters=0A=
=0A=
A TSM parameter is a performance metric that represents session=0A=
status and Quality of Services for the multicast data delivery.=0A=
Typical examples of TSM parameters include throughput and packet loss=0A=
rate. According to application's requirements, the sender may=0A=
configure a set of target values of each TSM parameter for desirable=0A=
display of application data. For Session Monitoring, each receiver=0A=
reports the experienced status for each TSM parameter to the sender.=0A=
=0A=
1.2 Motivations for TSM=0A=
=0A=
Some multicast applications have a crucial need to guarantee a=0A=
desired Quality of Service (QoS) in the delivery of multicast data.=0A=
In principal, the QoS for data delivery can be supported with help of=0A=
network-layer resource reservation mechanisms such as RSVP or=0A=
Diffserv. However, in the end-to-end transport level, the sender=0A=
needs to monitor and manage how much desirably the QoS for a=0A=
multicast session is being supported [ECTS, ECTP].=0A=
=0A=
TSM functionality is designed to support a tight control of multicast=0A=
sessions. TSM mechanisms can be used to maintain the transport=0A=
session desirable according to the application's requirements, and=0A=
also to protect the session status from being degraded more severely.=0A=
=0A=
1.3 Rationale of TSM BB=0A=
=0A=
Per the guidelines of RMT BB draft [RMT-Author], this section will be=0A=
filled.=0A=
=0A=
1.4 Applicability Statement=0A=
=0A=
Per the guidelines of RMT BB draft [RMT-Author], this section will be=0A=
filled.=0A=
=0A=
=0A=
=0A=
=0A=
Koh, et al. draft-koh-rmt-bb-tsm-01.txt [Page 3]=0A=
=0C=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
INTERNET-DRAFT Expires: August 2001 February 2001=0A=
=0A=
=0A=
2. TSM Overview=0A=
=0A=
Transport Session Management (TSM) is designed to support a tight=0A=
control of multicast sessions. TSM functionality is accomplished by=0A=
interactions between the sender and receivers. In TSM, the sender is=0A=
responsible for overall TSM operations.=0A=
=0A=
Figure 1 illustrates an overall TSM functionality during a multicast=0A=
session.=0A=
=0A=
=0A=
=0A=
+--------------------------------------------------------------+=0A=
| |=0A=
| +-------------+ +--------------+ |=0A=
| | Data Rate | +-------------+ | Session | |=0A=
| | Adjustment |<--- | Session | ---> | Pause/Resume | |=0A=
| +-------------+ | Monitoring | +--------------+ |=0A=
| | with | |=0A=
| +-------------+ | Membership | +--------------+ |=0A=
| |Troublemaker |<--- | Tracking | ---> | Session | |=0A=
| | Ejection | +-------------+ | Termination | |=0A=
| +-------------+ ^ +--------------+ |=0A=
| | |=0A=
+------------------------------+-------------------------------+=0A=
^ | ^=0A=
| | |=0A=
-----------+---------------------+-------------------+--------------=0A=
| | | TSM API=0A=
v | v=0A=
+---------+ | +-----------+=0A=
| | | | |=0A=
| Sender =
|=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D>| Receivers |=0A=
| | Multicast Data | |=0A=
+---------+ +-----------+=0A=
=0A=
Figure 1. TSM Overview=0A=
=0A=
=0A=
TSM functionality is achieved by the following operations:=0A=
(a) Session Register=0A=
(b) Session Monitoring=0A=
(c) Session Maintenance=0A=
=0A=
In Session Register, the following two events occur:=0A=
- Register Request by a receiver=0A=
- Register Confirm by the sender=0A=
=0A=
=0A=
=0A=
=0A=
Koh, et al. draft-koh-rmt-bb-tsm-01.txt [Page 4]=0A=
=0C=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
INTERNET-DRAFT Expires: August 2001 February 2001=0A=
=0A=
=0A=
Each receiver who wants to participate in the session sends a=0A=
Register Request message to the sender. The sender may make a=0A=
decision whether the Register request should be accepted or not,=0A=
possibly along with an authentication process. When the Register=0A=
request is accepted, the sender will sends a Register Confirm message=0A=
that contains information on the target values of TSM parameters such=0A=
as throughput and packet loss rate.=0A=
=0A=
Session Monitoring is used for sender to diagnose current session=0A=
status for multicast data delivery. Session Monitoring also performs=0A=
'Membership Tracking', by which the sender keeps track of the list of=0A=
active receivers.=0A=
=0A=
For Session Monitoring, each receiver is required to measure a status=0A=
value for each TSM parameter that has been experienced for the=0A=
received multicast data streams. If a status value indicates an=0A=
abnormal status, the receiver reports the status value to the sender=0A=
via a TSM Response message.=0A=
=0A=
TSM Response messages are also generated in response to the periodic=0A=
TSM Request messages of the sender. Through these interactions with=0A=
receivers, the sender can perform the membership tracking.=0A=
=0A=
Session Maintenance is performed based on the reported status values=0A=
and the target values for TSM parameters. Sender continues to=0A=
aggregate the status values that have been reported from the=0A=
receivers. Based on the aggregated information, the sender will take=0A=
one or more of the following Session Maintenance actions:=0A=
- Adjustment of data transmission rate=0A=
- Troublemaker ejection=0A=
- Session pause/resume=0A=
- Session termination=0A=
=0A=
TSM Request messages are also used to indicate a current session=0A=
status, which is classified into one of the following:=0A=
- Session Creation=0A=
- Data Transmission=0A=
- Session Pause=0A=
- Session Termination=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
Koh, et al. draft-koh-rmt-bb-tsm-01.txt [Page 5]=0A=
=0C=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
INTERNET-DRAFT Expires: August 2001 February 2001=0A=
=0A=
=0A=
3. TSM Components=0A=
=0A=
3.1 Sender=0A=
=0A=
Sender transmits multicast data to the receivers in the session. It=0A=
is responsible for the overall TSM operations.=0A=
=0A=
3.2 Receiver=0A=
=0A=
A receiver receives multicast data from the sender. TSM is based on=0A=
interaction between sender and receivers.=0A=
=0A=
3.3 TSM Parameters=0A=
=0A=
TSM parameters are used to diagnose a current session status. This=0A=
document specifies two TSM parameters: throughput and packet loss=0A=
rate. In the future, more TSM parameters may be added, if necessary.=0A=
=0A=
Throughput (THRUPUT) can be represented in units of bytes per second.=0A=
THRUPUT can be interpreted as data transmission rate at the sender=0A=
side and also data reception rate at receiver side. Packet loss rate=0A=
(PLR) is defined as the ratio of lost packets over totally=0A=
transmitted packets. PLR may be represented as an integer number=0A=
ranged from 0 to 100. The sequence numbers of data packets can be=0A=
used to measure the packet loss rate.=0A=
=0A=
In Session Register, the sender announces the authorized receiver=0A=
about the pre-configured target values for each TSM parameter such as=0A=
- MIN: a minimum value=0A=
- ALLOWED_LOW: an allowed low value=0A=
- ALLOWED_HIGH: an allowed high value=0A=
- MAX: a maximum value=0A=
=0A=
These target values MAY be determined by considering application's=0A=
requirements. Among those values, the following inequalities are=0A=
enforced:=0A=
=0A=
MIN <=3D ALLOWED_LOW <=3D ALLOWED_HIGH <=3D MAX=0A=
=0A=
For THRUPUT parameter, the following variables can be defined:=0A=
- MIN_THRUPUT=0A=
- ALLOWED_LOW_THRUPUT=0A=
- ALLOWED_HIGH_THRUPUT=0A=
- MAX_THRUPUT=0A=
=0A=
For PLR parameter, the following variables can be defined:=0A=
- MIN_PLR=0A=
- ALLOWED_LOW_PLR=0A=
=0A=
=0A=
=0A=
Koh, et al. draft-koh-rmt-bb-tsm-01.txt [Page 6]=0A=
=0C=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
INTERNET-DRAFT Expires: August 2001 February 2001=0A=
=0A=
=0A=
- ALLOWED_HIGH_PLR=0A=
- MAX_PLR=0A=
=0A=
In Session Monitoring, each receiver is required to measure the=0A=
parameter values experienced for the received multicast data. By=0A=
comparing the measured values and the target values, the receiver=0A=
sets each of THRUPUT_STATUS and PLR_STATUS to an integer of '0=0A=
through 4' as follows:=0A=
=0A=
0, if ALLOWED_LOW <=3D measured value <=3D ALLOWED_HIGH=0A=
1, if MIN <=3D measured value <=3D ALLOWED_LOW=0A=
2, if ALLOWED_HIGH <=3D measured value <=3D MAX=0A=
3, if measured value <=3D MIN=0A=
4, if MAX <=3D measured value=0A=
=0A=
The STATUS value of '0' represents a normal status, while the non-=0A=
zero values mean that the session possibly goes into abnormal status=0A=
(1 or 2), or is currently being in an abnormal status (3 or 4).=0A=
=0A=
In Session Monitoring, receivers report those STATUS values to the=0A=
sender via TSM Response messages.=0A=
=0A=
3.4 TSM Messages=0A=
=0A=
The following control messages are used for TSM:=0A=
- Register Request=0A=
- Register Confirm=0A=
- Ejection=0A=
- TSM Request=0A=
- TSM Response=0A=
=0A=
Table 1 summarizes the detailed use of those TSM messages.=0A=
=0A=
3.4.1 Register Request=0A=
=0A=
A receiver that wishes to register the session sends a Register=0A=
Request to the sender.=0A=
=0A=
3.4.2 Register Confirm=0A=
=0A=
The sender responds with a Register Confirm message to the Register=0A=
Request. The Register Confirm message contains the following=0A=
information:=0A=
- Whether a Register Request is accepted or not=0A=
- Target values for TSM parameters: MIN, ALLOWED_LOW, ALLOWED_MAX,=0A=
MAX=0A=
- Receiver ID for the corresponding receiver=0A=
=0A=
=0A=
=0A=
=0A=
Koh, et al. draft-koh-rmt-bb-tsm-01.txt [Page 7]=0A=
=0C=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
INTERNET-DRAFT Expires: August 2001 February 2001=0A=
=0A=
=0A=
The receiver ID can be used for membership tracking, and also used in=0A=
generation of a TSM Response message (see Section 5).=0A=
=0A=
Table 1. TSM messages=0A=
=0A=
+------------------+------+-----+-----------+---------------------+=0A=
| Message | From | To | Unicast/ | TSM Operation |=0A=
| Types | | | Multicast | Concerned |=0A=
+------------------+------+-----+-----------+---------------------+=0A=
| Register Request | R | S | Unicast | Session Register |=0A=
+------------------+------+-----+-----------+---------------------+=0A=
| Register Confirm | S | R | Unicast | Session Register |=0A=
+------------------+------+-----+-----------+---------------------+=0A=
| Ejection | S | R | Unicast | Session Maintenance |=0A=
+------------------+------+-----+-----------+---------------------+=0A=
| TSM Request | S | Rs | Multicast | Session Monitoring |=0A=
+------------------+------+-----+-----------+---------------------+=0A=
| TSM Response | R | S | Unicast | Session Monitoring |=0A=
+------------------+------+-----+-----------+---------------------+=0A=
S: Sender, R : Receiver=0A=
=0A=
=0A=
=0A=
3.4.3 Ejection=0A=
=0A=
In Session Maintenance, the sender MAY eject the trouble-making=0A=
receiver by sending an Ejection message.=0A=
=0A=
=0A=
=0A=
3.4.4 TSM Request=0A=
=0A=
The sender transmits periodic TSM Request messages to the receivers.=0A=
The length of periodic time interval MAY vary depending on=0A=
implementations.=0A=
=0A=
Each TSM Request message triggers the corresponding TSM Response=0A=
messages from some or all of the receivers. The TSM Request message=0A=
contains an integer value to indicate the current session status. To=0A=
do this, the current session status is classified into one of the=0A=
following phases, with an integer value:=0A=
- Session Creation (0)=0A=
- Data Transmission (1)=0A=
- Session Pause (2)=0A=
- Session Termination (3)=0A=
=0A=
When a session starts, the sender indicates 'Session Creation'. If=0A=
TSM BB is used in TRACK PI, 'Session Creation' state can be used as=0A=
=0A=
=0A=
=0A=
Koh, et al. draft-koh-rmt-bb-tsm-01.txt [Page 8]=0A=
=0C=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
INTERNET-DRAFT Expires: August 2001 February 2001=0A=
=0A=
=0A=
an indication signal for an initial tree configuration [TREE]. After=0A=
a session is created, the TSM Request messages will indicate 'Data=0A=
Transmission'. 'Session Pause' will be indicated if a sender=0A=
realizes that the session potentially goes into an abnormal status.=0A=
In Session Pause period, the sender is not allowed to send any new=0A=
multicast data. When the session status is perceived to go back to a=0A=
normal status, the sender will again indicate 'Data Transmission',=0A=
and then resumes the multicast data transmission. 'Session=0A=
Termination' is indicated after the sender transmits all the=0A=
multicast data, or if the session is detected to be in the severe=0A=
abnormal status.=0A=
=0A=
=0A=
3.4.5 TSM Response=0A=
=0A=
A TSM Response messages contain the following information:=0A=
- Receiver ID=0A=
- THRUPUT_STATUS (ranged from 0 - 4)=0A=
- PLR_STATUS (ranged from 0 - 4)=0A=
=0A=
Each receiver generates a TSM message if its measured THRUPUT_STATUS=0A=
or PLR_STATUS is a non-zero value. TSM messages can also be=0A=
generated in response to a periodic TSM Request message.=0A=
=0A=
=0A=
=0A=
4. TSM Procedures=0A=
=0A=
4.1 Session Register=0A=
=0A=
A receiver who wants to register a session sends a Register Request=0A=
message to the sender. When the sender receives a Register Request=0A=
message, it MAY check whether the receiver is an authorized user or=0A=
not.=0A=
=0A=
In response to a Register Request, the sender transmits a Register=0A=
Confirm message to the receiver. The Register Confirm message=0A=
contains information on Receiver ID and whether the Register Request=0A=
is accepted or not. The Register Confirm message also contains the=0A=
pre-configured target values of TSM parameters: MIN, ALLOWED_LOW,=0A=
ALLOWED_HIGH, and MAX (see 3.3).=0A=
=0A=
In the networks that support resource reservation mechanisms such as=0A=
RSVP and Diffserv, the receiver SHALL initiate the reservation of the=0A=
required network resources. Then the target parameter values MAY be=0A=
referred to in the reservation process.=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
Koh, et al. draft-koh-rmt-bb-tsm-01.txt [Page 9]=0A=
=0C=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
INTERNET-DRAFT Expires: August 2001 February 2001=0A=
=0A=
=0A=
4.2 Session Monitoring=0A=
=0A=
In Session Monitoring, the sender monitors how well the session=0A=
operates and also which receivers are participating in the session.=0A=
To do this, each receiver is required to measure the THRUPUT and PLR=0A=
values experienced for the received multicast data. Those measured=0A=
THRUPUT and PLR values are compared with the target values for=0A=
THRUPUT and PLR announced in Session Register, and then the receiver=0A=
determines THRUPUT_STATUS and PLR_STATUS values as 0, 1, 2, 3 or 4=0A=
(see 3.3).=0A=
=0A=
If the STATUS value is a non-zero value, the receiver generates a TSM=0A=
Response message. For the STATUS value of '0', the receiver does not=0A=
need to generate a TSM Response message. In other words, the sender=0A=
will realize that a receiver is in the normal status, if it does not=0A=
send any TSM Response messages indicating an abnormal status, where=0A=
an abnormal status indicates that the STATUS value is non-zero.=0A=
=0A=
TSM Response message is also generated responsively to a periodic TSM=0A=
Request message. This feedback mechanism is designed to support=0A=
Membership Tracking and an overall identification of the current=0A=
session status.=0A=
=0A=
In response to the periodic TSM Request message, some or all of=0A=
receivers send TSM Response messages to the sender. To reduce the=0A=
number of simultaneous TSM Response messages from the receivers, a=0A=
specific rule MAY be employed. An example is given in Section 5.=0A=
=0A=
During a session, the sender aggregates the reported THRUPUT_STATUS=0A=
and PLR_STATUS values from the receivers. In the aggregation, the=0A=
following considerations will be taken:=0A=
- Which receivers are in the abnormal status ?=0A=
- How many receivers in a given session are in the abnormal status ?=0A=
=0A=
Based on this aggregated information, the sender takes one or more=0A=
Session Maintenance actions.=0A=
=0A=
4.3. Session Maintenance=0A=
=0A=
Session Maintenance is purposed to maintain the session status=0A=
desirable, and to prevent the session status from being degraded more=0A=
severely.=0A=
=0A=
Based on the THRUPUT_STATUS and PLR_STATUS values reported from the=0A=
receivers, the sender takes one or more of the following Session=0A=
Maintenance actions:=0A=
- Adjustment of data transmission rate=0A=
- Ejection of Troublemaker=0A=
=0A=
=0A=
=0A=
Koh, et al. draft-koh-rmt-bb-tsm-01.txt [Page 10]=0A=
=0C=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
INTERNET-DRAFT Expires: August 2001 February 2001=0A=
=0A=
=0A=
- Session Pause and Resume=0A=
- Session Termination=0A=
=0A=
Depending on application services, some of the actions described=0A=
above MAY NOT be enabled. For example, for a certain multicast=0A=
session, the sender MAY NOT perform Troublemaker Ejection.=0A=
=0A=
4.3.1 Adjustment of data transmission rate=0A=
=0A=
If this option is enabled, the sender will adjust data transmission=0A=
rate based on the monitored STATUS values of the TSM parameters. The=0A=
data transmission rate is bounded as follows:=0A=
=0A=
MIN_THRUPUT <=3D Data Transmission Rate <=3D MAX_THRUPUT=0A=
=0A=
Specific rules to increase or decrease the data transmission rate are=0A=
for further study, which MAY depend on the Congestion Control=0A=
algorithm that will be developed in the RMT WG.=0A=
=0A=
4.3.2 Ejection of Troublemaker=0A=
=0A=
To determine whether a receiver is a troublemaker or not, the sender=0A=
MUST configure a rule to trigger a Troublemaker Ejection. The=0A=
specific rule is an implementation issue. For an example, a receiver=0A=
can be regarded as a troublemaker if the STATUS values for TSM=0A=
parameters have been consecutively in abnormal status more than the=0A=
pre-configured threshold times.=0A=
=0A=
Once a troublemaker is detected, the sender sends an Ejection message=0A=
to the concerned receiver.=0A=
=0A=
4.3.3 Session Pause and Resume=0A=
=0A=
Session Pause is used to suspend the data transmission of the sender=0A=
temporarily and thus to prevent the session from being more severely=0A=
degraded.=0A=
=0A=
The sender announces 'Session Pause' to all the receivers via TSM=0A=
Request message, which has the session status value of '2' (see=0A=
3.4.4). In the Session Pause period, the sender SHALL NOT send any=0A=
new multicast data.=0A=
=0A=
The specific rule to trigger Session Pause can be configured based on=0A=
the STATUS values reported from the receivers. For an example, if=0A=
the number of receivers reporting an abnormal status is greater than=0A=
a pre-configured number, then the sender MAY trigger Session Pause.=0A=
=0A=
After Session Pause is indicated, Session Resume will be activated if=0A=
=0A=
=0A=
=0A=
Koh, et al. draft-koh-rmt-bb-tsm-01.txt [Page 11]=0A=
=0C=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
INTERNET-DRAFT Expires: August 2001 February 2001=0A=
=0A=
=0A=
the session status is perceived to come back into the normal state.=0A=
The specific rule to trigger Session Resume is an implementation=0A=
issue. A simple rule to trigger the Session Resume is to use a=0A=
timer. In this case, if the timer expires after Session Pause is=0A=
indicated, then the sender will automatically resume the session by=0A=
sending a TSM Request message with an indication of 'Data=0A=
Transmission' (see 3.4.4).=0A=
=0A=
4.3.4 Session Termination=0A=
=0A=
The natural option for Session Termination is to terminate a session=0A=
when all the multicast data have been transmitted. Session=0A=
Termination is also triggered if the session is detected to be in the=0A=
severe abnormal state. When Session Termination is indicated, the=0A=
sender terminates the session and sends a TSM Request message with=0A=
indication of Session Termination.=0A=
=0A=
The activation of Session Termination can be performed in various=0A=
ways. One simple way is to trigger Session Termination if the=0A=
Session Pause/Resume operations have been consecutively repeated more=0A=
than a pre-configured times.=0A=
=0A=
=0A=
=0A=
5. Scalability Enhancement for Feedback Implosions of TSM Response=0A=
Messages=0A=
=0A=
Session Monitoring is based on the 'TSM Response' feedback messages=0A=
from the receivers. For the session that consists of a large number=0A=
of receivers, simultaneous responses of TSM Response messages may=0A=
induce an implosion of feedback messages. This is referred to as the=0A=
scalability problem.=0A=
=0A=
If a hierarchical control tree [TREE] is employed along with TSM BB,=0A=
it is clear that we reduce the number of simultaneously generated TSM=0A=
Response messages. In the tree hierarchy, each Repair Head=0A=
aggregates TSM Response messages from its children, and then delivers=0A=
the aggregated information toward the sender [TRACK].=0A=
=0A=
We also propose an alternate scheme to improve the feedback=0A=
implosion, which has benefited from TRACK BB [TRACK]. For this=0A=
purpose, we define the following two new variables:=0A=
- TSM Sequence Number (TSN)=0A=
- Response Generation Number (RGN)=0A=
=0A=
TSN is an integer number sequentially assigned to each periodic TSM=0A=
Request massage. RGN is a scaling factor used to limit the number of=0A=
the simultaneously responding receivers. These variables will be=0A=
=0A=
=0A=
=0A=
Koh, et al. draft-koh-rmt-bb-tsm-01.txt [Page 12]=0A=
=0C=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
INTERNET-DRAFT Expires: August 2001 February 2001=0A=
=0A=
=0A=
contained in the periodic TSM Request message, if they are enabled=0A=
for scalability enhancement.=0A=
=0A=
For a TSM Request message, each receiver responds with a TSM Response=0A=
message, if the following condition holds true:=0A=
=0A=
(TSN % RGN) =3D=3D (Receiver ID % RGN),=0A=
=0A=
where % represents "modulo" operator.=0A=
=0A=
For an example, suppose there are receivers with Receiver ID =3D=0A=
1,..,20. In response to a TSM Request message with TSN =3D 3 and RGN =
=3D=0A=
5, the receivers with Receiver ID =3D 3, 8, 13, 18 will transmit the=0A=
corresponding TSM Response message.=0A=
=0A=
=0A=
=0A=
6. Relationship with the other BBs and PIs=0A=
=0A=
TSM BB does not impose any requirements and modifications on existing=0A=
RMT BBs. The TSM functionality and its mechanisms can be easily=0A=
adopted by any RMT PIs that wish a tight control of multicast=0A=
session.=0A=
=0A=
We note that TSM mechanisms are primarily based on feedbacks from the=0A=
receivers, 'TSM Response' messages. TSM BB is a good-match with=0A=
TRACK PI, in the viewpoint of scalability enhancement of feedback=0A=
messages from receivers to sender.=0A=
=0A=
In NORM PI, the NACK messages can also be used to deliver TSM=0A=
Response messages from receivers to the sender. In this case, we MAY=0A=
configure that a NACK message will be generated at a receiver, if a=0A=
measured parameter value indicates an abnormal status. In addition,=0A=
if NORM PI wishes to support Membership Tracking, the periodic=0A=
exchanges of TSM Request messages with TSM Response messages need to=0A=
be specified in the PI. In this case, we will prefer a larger=0A=
periodic time interval between consecutive TSM Requeste messages and=0A=
a more conservative mechanism for generation of TSM response=0A=
messages.=0A=
=0A=
If the FEC-based LCT PI wants to support TSM BB, we need to define an=0A=
out-of-band control channel for TSM Response messages from receivers=0A=
to sender. The well-known RTP/RTCP scheme is an example scenario to=0A=
use TSM BB in the LCT PI, where RTCP messages will be used to deliver=0A=
TSM Response messages. A more specific scheme is for further study.=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
Koh, et al. draft-koh-rmt-bb-tsm-01.txt [Page 13]=0A=
=0C=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
INTERNET-DRAFT Expires: August 2001 February 2001=0A=
=0A=
=0A=
7. Security Considerations=0A=
=0A=
The Register Confirm messages MAY be used to deliver the group key=0A=
information to the receivers for security purposes, if necessary. In=0A=
this case, an initial group key will be distributed via the Register=0A=
Confirm message, and the changed group key information via the=0A=
subsequent TSM Request messages.=0A=
=0A=
=0A=
=0A=
8. References=0A=
=0A=
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate=0A=
Requirement Levels", BCP 14, RFC 2119, Mar. 1997.=0A=
=0A=
[RFC2026] S. Bradner, "The Internet Standards Process -- Revision 3",=0A=
BCP 9, RFC 2026, Oct. 1996.=0A=
=0A=
[RMT-DS] M. Handley, et al., "The Reliable Multicast Design Space for=0A=
Bulk Data Transfer", RFC 2887, Aug. 2000.=0A=
=0A=
[RMT-BB] B. Whetton, et al., "Reliable Multicast Transport Building=0A=
Blocks for One-to-Many Bulk Data Transfer", RFC 3048, Jan. 2001.=0A=
=0A=
[RMT-Author] R. Kermode and L. Vicisano, "Author Guidelines for RMT=0A=
Building Blocks and Protocol Instantiation documents", draft-ietf-=0A=
rmt-author-guidelines-00.txt, Jun. 2000.=0A=
=0A=
[SAP] M. Handley, et al., "Session Announcement Protocol", RFC 2974,=0A=
Oct. 2000.=0A=
=0A=
[TRACK] B. Whetton, et al., "Reliable Multicast Transport Building=0A=
Block for TRACK", Feb. 2001.=0A=
=0A=
[TREE] M. Kadansky, et al., "Reliable Multicast Transport Building=0A=
Block: Tree Auto-Configuration", Nov. 2000.=0A=
=0A=
[NORM] C. Bormann, et al., "NACK-Oriented Reliable Multicast (NORM)=0A=
Protocol Building Blocks", Jan. 2001.=0A=
=0A=
[LCT] M.Luby, et al., "Layered Coding Transport: A massively scalable=0A=
multicast protocol", Nov. 2000.=0A=
=0A=
[ECTS] ITU-T Recommendation X.605 and ISO/IEC 13252, "Enhanced=0A=
Communication Transport Services", 1999.=0A=
=0A=
[ECTP] ITU-T Draft Recommendation X.ectp and ISO/IEC JTC1/SC6 CD=0A=
14476, "Enhanced Communications Transport Protocol", Work in=0A=
=0A=
=0A=
=0A=
Koh, et al. draft-koh-rmt-bb-tsm-01.txt [Page 14]=0A=
=0C=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
INTERNET-DRAFT Expires: August 2001 February 2001=0A=
=0A=
=0A=
Progress, Feb. 2001.=0A=
=0A=
=0A=
=0A=
9. Acknowledgments=0A=
=0A=
This document is the result of the joint development work on Enhanced=0A=
Communications Transport Protocol (ECTP) which is being undertaken by=0A=
ISO/IEC JTC 1/SC 6 and ITU-T/SG 7. Transmission to the IETF was=0A=
endorsed at the joint ITU-T/SG 7 and by ISO/IEC JTC 1/SC 6 meeting on=0A=
31th Jan. 2001.=0A=
=0A=
We would like to give special thanks to the following individuals.=0A=
Miriam Kadansky, Sun Microsystems=0A=
Dah Ming Chiu, Sun Microsystems=0A=
Jim Long, UK=0A=
Jack Houldsworth, UK=0A=
Dae Young Kim, KOREA=0A=
Hyun Kook Kahng, KOREA=0A=
=0A=
=0A=
=0A=
10. Author's Addresses=0A=
=0A=
Seok Joo Koh=0A=
sjkoh@pec.etri.re.kr=0A=
Shin Gak Kang=0A=
sgkang@etri.re.kr=0A=
Juyoung Park=0A=
jypark@ccl.cnu.ac.kr=0A=
Eun Sook Kim=0A=
eunsook@cs.sookmyung.ac.kr=0A=
=0A=
Protocol Engineering Center=0A=
Electronics Telecommunications Research Institute=0A=
Kajong-Dong, Yusung-Gu, Taejon, 305-350, Korea=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
Koh, et al. draft-koh-rmt-bb-tsm-01.txt [Page 15]=0A=
=0C=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
INTERNET-DRAFT Expires: August 2001 February 2001=0A=
=0A=
=0A=
Full Copyright Statement=0A=
=0A=
"Copyright (C) The Internet Society (2000). All Rights Reserved. =
This=0A=
document and translations of it may be copied and furnished to =
others, and=0A=
derivative works that comment on or otherwise explain it or assist in =
its=0A=
implementation may be prepared, copied, published and distributed, in =
whole=0A=
or in part, without restriction of any kind, provided that the above=0A=
copyright notice and this paragraph are included on all such copies =
and=0A=
derivative works. However, this document itself may not be modified =
in any=0A=
way, such as by removing the copyright notice or references to the =
Internet=0A=
Society or other Internet organizations, except as needed for the =
purpose of=0A=
developing Internet standards in which case the procedures for =
copyrights=0A=
defined in the Internet Standards process must be followed, or as =
required=0A=
to translate it into languages other than English.=0A=
=0A=
The limited permissions granted above are perpetual and will not be=0A=
revoked by the Internet Society or its successors or assigns.=0A=
=0A=
This document and the information contained herein is provided on an =
"AS IS"=0A=
basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE=0A=
DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT =
LIMITED TO=0A=
ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE =
ANY=0A=
RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A=0A=
PARTICULAR PURPOSE."=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
Koh, et al. draft-koh-rmt-bb-tsm-01.txt [Page 16]=0A=
=0C=0A=
=0A=
=0A=
------=_NextPart_000_001E_01C0AEEE.401D85E0--
>From owner-rmt@listserv.lbl.gov Sat Mar 17 22:54:21 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.9.3) id f2I6qMA03132;
Sat, 17 Mar 2001 22:52:22 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f2I6qKn03128
for <rmt@listserv.lbl.gov>; Sat, 17 Mar 2001 22:52:20 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.9.3) with ESMTP id f2I6qJh00975
for <rmt@listserv.lbl.gov>; Sat, 17 Mar 2001 22:52:19 -0800 (PST)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f2I6qIE00972
for <rmt@lbl.gov>; Sat, 17 Mar 2001 22:52:18 -0800 (PST)
Received: from lorenzo-u10.cisco.com (lorenzo-u10.cisco.com [10.34.54.43])
by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id WAA04853;
Sat, 17 Mar 2001 22:52:13 -0800 (PST)
Received: from localhost (lorenzo@localhost) by lorenzo-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id WAA21625; Sat, 17 Mar 2001 22:52:13 -0800 (PST)
Message-Id: <200103180652.WAA21625@lorenzo-u10.cisco.com>
X-Authentication-Warning: lorenzo-u10.cisco.com: lorenzo owned process doing -bs
X-Mailer: exmh version 2.0.2 2/24/98
To: "Seok Joo Koh" <sjkoh@pec.etri.re.kr>
cc: rmt@lbl.gov
Subject: Re: draft-koh-rmt-bb-tsm-01.txt
In-Reply-To: Your message of "Sat, 17 Mar 2001 14:26:26 +0900."
<002101c0aea2$d089ca40$2ea4fe81@etri.re.kr>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sat, 17 Mar 2001 22:52:13 -0800
From: Lorenzo Vicisano <lorenzo@cisco.com>
Sender: owner-rmt@lbl.gov
Precedence: bulk
When I listed this in the agenda I did not notice that
draft-koh-rmt-bb-tsm-01.txt had missed the submission
deadline, hence it cannot be discussed at the meeting.
However draft-koh-rmt-bb-tsm-00.txt can be discussed as
it met the February deadline for initial submission.
Please let me know if this is fine.
Lorenzo
> Dear all,
>
> Please see the attached TSM draft, which is going to be discussed in this
> RMT meeting.
> It can also be obtained from
> http://pec.etri.re.kr/~sjkoh/draft-koh-rmt-bb-tsm-01.txt
>
> Best Regards,
>
> Seok Joo Koh
>From owner-rmt@listserv.lbl.gov Sat Mar 17 23:30:47 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.9.3) id f2I7Ud103200;
Sat, 17 Mar 2001 23:30:39 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f2I7Ucn03196
for <rmt@listserv.lbl.gov>; Sat, 17 Mar 2001 23:30:38 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.9.3) with ESMTP id f2I7UUl03031
for <rmt@listserv.lbl.gov>; Sat, 17 Mar 2001 23:30:31 -0800 (PST)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f2I7URE02977
for <rmt@lbl.gov>; Sat, 17 Mar 2001 23:30:28 -0800 (PST)
Received: from lorenzo-u10.cisco.com (lorenzo-u10.cisco.com [10.34.54.43])
by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id XAA23896;
Sat, 17 Mar 2001 23:29:35 -0800 (PST)
Received: from localhost (lorenzo@localhost) by lorenzo-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id XAA21693; Sat, 17 Mar 2001 23:29:14 -0800 (PST)
Message-Id: <200103180729.XAA21693@lorenzo-u10.cisco.com>
X-Authentication-Warning: lorenzo-u10.cisco.com: lorenzo owned process doing -bs
X-Mailer: exmh version 2.0.2 2/24/98
To: rmt@lbl.gov
cc: sob@harvard.edu, mankin@east.isi.edu, ark008@email.mot.com,
lorenzo@cisco.com
Subject: RMT agenda, 50th IETF
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sat, 17 Mar 2001 23:29:14 -0800
From: Lorenzo Vicisano <lorenzo@cisco.com>
Sender: owner-rmt@lbl.gov
Precedence: bulk
this is what the agenda looks like so far.
Agenda Bashing 5 mins
Kermode/Vicisano
Updates on draft-ietf-rmt-author-guidelines-01.txt 5 mins
Kermode/Vicisano
ALC PI, status of the work 5 mins
Luby
Updates to the TRACK BB and Tree BB 20 mins
Kadansky
A New TRACK PI draft 30 mins
Whetten
draft-ietf-rmt-bb-pgmcc-00.txt, CC proposal for NORM 15 mins
Vicisano
draft-koh-rmt-bb-tsm-00.txt 10 mins
Kang
The chairs would like to remind all the speakers that they should not
give a technical presentation on the full content of the drafts, but they
should assume that the attendees have read them.
As for draft-koh-rmt-bb-tsm-00.txt, given that this was not posted as
WG draft we suggest the speaker to give a very short (5 mins) overview
and defer further discussion to the mailing list to give people the
chance to read the draft.
thanks,
Lorenzo
>From owner-rmt@listserv.lbl.gov Mon Mar 19 06:40:41 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.9.3) id f2JEbcY06796;
Mon, 19 Mar 2001 06:37:38 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f2JEban06792
for <rmt@listserv.lbl.gov>; Mon, 19 Mar 2001 06:37:36 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.9.3) with ESMTP id f2JEbZb24239
for <rmt@listserv.lbl.gov>; Mon, 19 Mar 2001 06:37:35 -0800 (PST)
Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f2JEbYE24236
for <rmt@lbl.gov>; Mon, 19 Mar 2001 06:37:34 -0800 (PST)
Received: from [132.250.92.151] (manimac.itd.nrl.navy.mil [132.250.92.151])
by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id JAA24483;
Mon, 19 Mar 2001 09:37:19 -0500 (EST)
Mime-Version: 1.0
X-Sender: adamson@pop.itd.nrl.navy.mil
Message-Id: <p05010409b6dbc99cc792@[132.250.92.151]>
In-Reply-To: <200103180729.XAA21693@lorenzo-u10.cisco.com>
References: <200103180729.XAA21693@lorenzo-u10.cisco.com>
Date: Mon, 19 Mar 2001 09:37:20 -0500
To: Lorenzo Vicisano <lorenzo@cisco.com>
From: Brian Adamson <adamson@itd.nrl.navy.mil>
Subject: Re: RMT agenda, 50th IETF
Cc: rmt@lbl.gov, sob@harvard.edu, mankin@east.isi.edu, ark008@email.mot.com,
lorenzo@cisco.com
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-rmt@lbl.gov
Precedence: bulk
I will be happy provide an overview of the updates to the NORM PI
document also, if there is a slot available.
At 11:29 PM -0800 3/17/01, Lorenzo Vicisano wrote:
>this is what the agenda looks like so far.
>
> Agenda Bashing 5 mins
> Kermode/Vicisano
> Updates on draft-ietf-rmt-author-guidelines-01.txt 5 mins
> Kermode/Vicisano
> ALC PI, status of the work 5 mins
> Luby
> Updates to the TRACK BB and Tree BB 20 mins
> Kadansky
> A New TRACK PI draft 30 mins
> Whetten
> draft-ietf-rmt-bb-pgmcc-00.txt, CC proposal for NORM 15 mins
> Vicisano
> draft-koh-rmt-bb-tsm-00.txt 10 mins
> Kang
>
>The chairs would like to remind all the speakers that they should not
>give a technical presentation on the full content of the drafts, but they
>should assume that the attendees have read them.
>
>As for draft-koh-rmt-bb-tsm-00.txt, given that this was not posted as
>WG draft we suggest the speaker to give a very short (5 mins) overview
>and defer further discussion to the mailing list to give people the
>chance to read the draft.
>
> thanks,
> Lorenzo
--
Brian
__________________________________
Brian Adamson
<http://manimac.itd.nrl.navy.mil>
<mailto:adamson@itd.nrl.navy.mil>
>From owner-rmt@listserv.lbl.gov Mon Mar 19 08:00:34 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.9.3) id f2JFxvS07223;
Mon, 19 Mar 2001 07:59:58 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f2JFxun07219
for <rmt@listserv.lbl.gov>; Mon, 19 Mar 2001 07:59:56 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.9.3) with ESMTP id f2JFxsS09866
for <rmt@listserv.lbl.gov>; Mon, 19 Mar 2001 07:59:54 -0800 (PST)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f2JFxrE09852
for <rmt@lbl.gov>; Mon, 19 Mar 2001 07:59:53 -0800 (PST)
Received: from lorenzo-u10.cisco.com (lorenzo-u10.cisco.com [10.34.54.43])
by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id HAA13794;
Mon, 19 Mar 2001 07:58:41 -0800 (PST)
Received: from localhost (lorenzo@localhost) by lorenzo-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id HAA22807; Mon, 19 Mar 2001 07:58:40 -0800 (PST)
Message-Id: <200103191558.HAA22807@lorenzo-u10.cisco.com>
X-Authentication-Warning: lorenzo-u10.cisco.com: lorenzo owned process doing -bs
X-Mailer: exmh version 2.0.2 2/24/98
To: Brian Adamson <adamson@itd.nrl.navy.mil>
cc: rmt@lbl.gov, sob@harvard.edu, mankin@east.isi.edu, ark008@email.mot.com
Subject: Re: RMT agenda, 50th IETF
In-Reply-To: Your message of "Mon, 19 Mar 2001 09:37:20 EST."
<p05010409b6dbc99cc792@[132.250.92.151]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 19 Mar 2001 07:58:40 -0800
From: Lorenzo Vicisano <lorenzo@cisco.com>
Sender: owner-rmt@lbl.gov
Precedence: bulk
Brian,
I'll add a short (5/10 mins or you need more ?) slot to the agenda.
thanks,
Lorenzo
> I will be happy provide an overview of the updates to the NORM PI
> document also, if there is a slot available.
>
> At 11:29 PM -0800 3/17/01, Lorenzo Vicisano wrote:
> >this is what the agenda looks like so far.
> >
> > Agenda Bashing 5 mins
> > Kermode/Vicisano
> > Updates on draft-ietf-rmt-author-guidelines-01.txt 5 mins
> > Kermode/Vicisano
> > ALC PI, status of the work 5 mins
> > Luby
> > Updates to the TRACK BB and Tree BB 20 mins
> > Kadansky
> > A New TRACK PI draft 30 mins
> > Whetten
> > draft-ietf-rmt-bb-pgmcc-00.txt, CC proposal for NORM 15 mins
> > Vicisano
> > draft-koh-rmt-bb-tsm-00.txt 10 mins
> > Kang
> >
> >The chairs would like to remind all the speakers that they should not
> >give a technical presentation on the full content of the drafts, but they
> >should assume that the attendees have read them.
> >
> >As for draft-koh-rmt-bb-tsm-00.txt, given that this was not posted as
> >WG draft we suggest the speaker to give a very short (5 mins) overview
> >and defer further discussion to the mailing list to give people the
> >chance to read the draft.
> >
> > thanks,
> > Lorenzo
>
> --
> Brian
> __________________________________
> Brian Adamson
> <http://manimac.itd.nrl.navy.mil>
> <mailto:adamson@itd.nrl.navy.mil>
>From owner-rmt@listserv.lbl.gov Fri Mar 23 07:45:11 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.9.3) id f2NFekU02633;
Fri, 23 Mar 2001 07:40:46 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f2NFeic02629
for <rmt@listserv.lbl.gov>; Fri, 23 Mar 2001 07:40:44 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.9.3) with ESMTP id f2NFehK29650
for <rmt@listserv.lbl.gov>; Fri, 23 Mar 2001 07:40:43 -0800 (PST)
Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f2NFeg429643
for <rmt@lbl.gov>; Fri, 23 Mar 2001 07:40:43 -0800 (PST)
Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate3.mot.com (motgate3 2.1) with ESMTP id IAA08757; Fri, 23 Mar 2001 08:35:26 -0700 (MST)]
Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id IAA28577; Fri, 23 Mar 2001 08:40:39 -0700 (MST)]
Received: from arc.corp.mot.com ([10.238.2.81])
by homer.arc.corp.mot.com (8.11.2/8.11.2) with ESMTP id f2NFead13739;
Sat, 24 Mar 2001 02:40:37 +1100 (EST)
Message-ID: <3ABB6E7F.88E6C101@arc.corp.mot.com>
Date: Sat, 24 Mar 2001 02:40:47 +1100
From: Roger Kermode <rkermode@arc.corp.mot.com>
Organization: Motorola
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: rmt-list <rmt@lbl.gov>
CC: Lorenzo Vicisano <lorenzo@cisco.com>
Subject: raw minutes...
Content-Type: multipart/mixed;
boundary="------------61382CE69D227FE91A78AF8C"
Sender: owner-rmt@lbl.gov
Precedence: bulk
This is a multi-part message in MIME format.
--------------61382CE69D227FE91A78AF8C
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Could the kind person who took the raw minutes for the
second session please send them to Lorenzo and me,
thanks,
Roger
--------------61382CE69D227FE91A78AF8C
Content-Type: text/x-vcard; charset=us-ascii;
name="rkermode.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Roger Kermode
Content-Disposition: attachment;
filename="rkermode.vcf"
begin:vcard
n:Kermode;Roger
tel;cell:+61-408-212-284
tel;fax:+61-2-9666-0501
tel;work:+61-2-9666-0558
x-mozilla-html:FALSE
org:Motorola Labs, Motorola Australia Research Centre;Communications and Networks Laboratory
adr:;;Locked Bag 5028;Botany;NSW;1455;Australia
version:2.1
email;internet:Roger.Kermode@motorola.com
title:Prinicpal Research Engineer / Lab Manager
fn:Roger Kermode
end:vcard
--------------61382CE69D227FE91A78AF8C--
>From owner-rmt@listserv.lbl.gov Fri Mar 23 09:31:10 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.9.3) id f2NHUqM03586;
Fri, 23 Mar 2001 09:30:52 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f2NHUpc03582
for <rmt@listserv.lbl.gov>; Fri, 23 Mar 2001 09:30:51 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.9.3) with ESMTP id f2NHUos03580
for <rmt@listserv.lbl.gov>; Fri, 23 Mar 2001 09:30:50 -0800 (PST)
Received: from daffy.ee.lbl.gov (daffy.ee.lbl.gov [131.243.1.31])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f2NHUo403573
for <rmt@lbl.gov>; Fri, 23 Mar 2001 09:30:50 -0800 (PST)
Received: (from vern@localhost)
by daffy.ee.lbl.gov (8.10.0/8.10.0) id f2NHUo815420;
Fri, 23 Mar 2001 09:30:50 -0800 (PST)
Message-Id: <200103231730.f2NHUo815420@daffy.ee.lbl.gov>
To: rmt@lbl.gov
Subject: Administrative: cleanup of rmt@lbl.gov mailing list
Date: Fri, 23 Mar 2001 09:30:49 PST
From: Vern Paxson <vern@ee.lbl.gov>
Sender: owner-rmt@lbl.gov
Precedence: bulk
FYI, the following usernames have been deleted due to repeated hard bounces:
GK@dial.pipex.com
dli@leland.Stanford.EDU
husson@matra-ms2i.fr
luciana.costa@cselt.it
mike.frietman@icoe.att.com
pjackson@qualcomm.com
yanyu@scf-fs.usc.edu
zhwang@dnrc.bell-labs.com
- Vern
>From owner-rmt@listserv.lbl.gov Sat Mar 24 01:39:14 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.9.3) id f2O9YJ807260;
Sat, 24 Mar 2001 01:34:19 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f2O9YIc07256
for <rmt@listserv.lbl.gov>; Sat, 24 Mar 2001 01:34:18 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.9.3) with ESMTP id f2O9YIk18441
for <rmt@listserv.lbl.gov>; Sat, 24 Mar 2001 01:34:18 -0800 (PST)
Received: from daffy.ee.lbl.gov (daffy.ee.lbl.gov [131.243.1.31])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f2O9YHR18438
for <rmt@lbl.gov>; Sat, 24 Mar 2001 01:34:17 -0800 (PST)
Received: (from vern@localhost)
by daffy.ee.lbl.gov (8.10.0/8.10.0) id f2O9YHL17875;
Sat, 24 Mar 2001 01:34:17 -0800 (PST)
Message-Id: <200103240934.f2O9YHL17875@daffy.ee.lbl.gov>
To: rmt@lbl.gov
Subject: Administrative #2: more cleanup of rmt@lbl.gov mailing list
Date: Sat, 24 Mar 2001 01:34:17 PST
From: Vern Paxson <vern@ee.lbl.gov>
Sender: owner-rmt@lbl.gov
Precedence: bulk
The following usernames have also been deleted due to hard bounces:
bhagatdb@cs.purdue.edu
koyk@cs.purdue.edu
pbilling@nortelnetworks.com
shawn.harris@wcom.com
srikar@ipo.att.com
- Vern
>From owner-rmt@listserv.lbl.gov Wed Mar 28 19:10:04 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.9.3) id f2T37rW10697;
Wed, 28 Mar 2001 19:07:53 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f2T37qc10693
for <rmt@listserv.lbl.gov>; Wed, 28 Mar 2001 19:07:52 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.9.3) with ESMTP id f2T37p825481
for <rmt@listserv.lbl.gov>; Wed, 28 Mar 2001 19:07:51 -0800 (PST)
Received: from uni01du.unity.ncsu.edu (uni01du.unity.ncsu.edu [152.1.2.65])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f2T37o125478
for <rmt@lbl.gov>; Wed, 28 Mar 2001 19:07:51 -0800 (PST)
Received: (from njshah@localhost)
by uni01du.unity.ncsu.edu (8.8.4/EC02Jan97)
id WAA20395; Wed, 28 Mar 2001 22:07:49 -0500 (EST)
Date: Wed, 28 Mar 2001 22:07:49 -0500 (EST)
From: Nipul Jayvant Shah <njshah@unity.ncsu.edu>
To: <rmt@lbl.gov>
Subject: security related concerns
Message-ID: <Pine.GSO.4.33.0103282205020.13867-100000@uni01du.unity.ncsu.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-rmt@lbl.gov
Precedence: bulk
Hi! I am a graduate student at NC State. I wanted to know if the RMT WG
has already conducted some research work related to the security issues of
RMT, especially concerning the denial of service attacks. If so, could
anyone suggest the related drafts?
Regards,
Nipul Shah
NCSU, Raleigh, NC.
>From owner-rmt@listserv.lbl.gov Thu Mar 29 03:14:04 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.9.3) id f2TBDSX11333;
Thu, 29 Mar 2001 03:13:28 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f2TBDRc11329
for <rmt@listserv.lbl.gov>; Thu, 29 Mar 2001 03:13:27 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.9.3) with ESMTP id f2TBDQD14629
for <rmt@listserv.lbl.gov>; Thu, 29 Mar 2001 03:13:26 -0800 (PST)
Received: from sm.luth.se (ny.sm.luth.se [130.240.3.1])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f2TBDP114626
for <rmt@lbl.gov>; Thu, 29 Mar 2001 03:13:25 -0800 (PST)
Received: from delta1.sm.luth.se (delta1.sm.luth.se [130.240.3.7])
by sm.luth.se (8.10.0/8.10.0) with ESMTP id f2TBDQM03983;
Thu, 29 Mar 2001 13:13:26 +0200 (MET DST)
Date: Thu, 29 Mar 2001 13:13:17 +0200 (MET DST)
From: Jeremiah Scholl <jeremiah@cdt.luth.se>
To: rmt@lbl.gov
cc: Peter Parnes <peppar@cdt.luth.se>
Subject: local recovery and NORM
Message-ID: <Pine.GSO.4.21.0103291308200.17188-100000@delta1.sm.luth.se>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-rmt@lbl.gov
Precedence: bulk
Can anyone out there give me information regarding the NORM protocol and
local recovery mechanisms. Is there a plan to add local recovery to NORM
before it is standardized? If so, which type of local recovery scheme
(hop-scoped, group-scoped ect.) will most likley be a part of the
protocol.
Thanks!
Jeremiah Scholl
>From owner-rmt@listserv.lbl.gov Thu Mar 29 03:44:46 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.9.3) id f2TBiUA11349;
Thu, 29 Mar 2001 03:44:30 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f2TBiSc11345
for <rmt@listserv.lbl.gov>; Thu, 29 Mar 2001 03:44:28 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.9.3) with ESMTP id f2TBiRg16357
for <rmt@listserv.lbl.gov>; Thu, 29 Mar 2001 03:44:27 -0800 (PST)
Received: from nmh.informatik.uni-bremen.de (root@nmh.informatik.uni-bremen.de [134.102.224.3])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f2TBiQ116354
for <rmt@lbl.gov>; Thu, 29 Mar 2001 03:44:26 -0800 (PST)
Received: from cabo3 (root@nmh.informatik.uni-bremen.de [134.102.224.3])
by nmh.informatik.uni-bremen.de (8.10.1/8.10.1) with SMTP id f2TBiEG17078;
Thu, 29 Mar 2001 13:44:14 +0200 (MEST)
From: "Dr. Carsten Bormann" <cabo@tzi.org>
To: "Jeremiah Scholl" <jeremiah@cdt.luth.se>, <rmt@lbl.gov>
Cc: "Peter Parnes" <peppar@cdt.luth.se>
Subject: RE: local recovery and NORM
Date: Thu, 29 Mar 2001 13:44:14 +0200
Message-ID: <NEBBJFHFCKHKFCNLJJBPKEIHEOAA.cabo@tzi.org>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
In-Reply-To: <Pine.GSO.4.21.0103291308200.17188-100000@delta1.sm.luth.se>
Importance: Normal
Sender: owner-rmt@lbl.gov
Precedence: bulk
Jeremiah,
one of the main points of NORM is to be simple, so NORM-PI should probably
not try to implement local recovery.
The NORM building block will certainly allow for local receovery, though.
Adding local recovery is probably most useful in cooperation with GRA, which
still is in the process of solidifying.
Gruesse, Carsten
> -----Original Message-----
> From: owner-rmt@lbl.gov [mailto:owner-rmt@lbl.gov]On Behalf Of Jeremiah
> Scholl
> Sent: Thursday, March 29, 2001 13:13
> To: rmt@lbl.gov
> Cc: Peter Parnes
> Subject: local recovery and NORM
>
>
> Can anyone out there give me information regarding the NORM protocol and
> local recovery mechanisms. Is there a plan to add local recovery to NORM
> before it is standardized? If so, which type of local recovery scheme
> (hop-scoped, group-scoped ect.) will most likley be a part of the
> protocol.
>
> Thanks!
>
> Jeremiah Scholl
>
>From owner-rmt@listserv.lbl.gov Thu Mar 29 05:47:39 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.9.3) id f2TDlDw11516;
Thu, 29 Mar 2001 05:47:13 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f2TDl2c11512
for <rmt@listserv.lbl.gov>; Thu, 29 Mar 2001 05:47:02 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.9.3) with ESMTP id f2TDl1m28009
for <rmt@listserv.lbl.gov>; Thu, 29 Mar 2001 05:47:01 -0800 (PST)
Received: from moocow.zweknu.org (128-121-47-185.moocow.ncal.verio.net [128.121.47.185])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f2TDl0127999
for <rmt@lbl.gov>; Thu, 29 Mar 2001 05:47:00 -0800 (PST)
Received: from null.net (cabbie.zweknu.org [192.168.1.102])
by moocow.zweknu.org (Postfix) with ESMTP
id AF2F0236F8; Thu, 29 Mar 2001 07:51:32 -0600 (CST)
Message-ID: <3AC33CF9.E43FFCC4@null.net>
Date: Thu, 29 Mar 2001 07:47:37 -0600
From: "Michael R. Eckhoff" <foobar@null.net>
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.3-pre7 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: rmt@lbl.gov
Cc: michael_eckhoff@afcc.com
Subject: Multicast Recovery with Loaded Links
References: <NEBBJFHFCKHKFCNLJJBPKEIHEOAA.cabo@tzi.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-rmt@lbl.gov
Precedence: bulk
Greetings!
I am new to this list, so please forgive me if I bring up topics that
have already been discussed in great detail.
Currently, I have over 150 multicast locations utilizing distance
education software (including white board, audio, application sharing,
etc.). Most of these locations utilize 256Kbps frame relay. Normally,
all packets are delivered successfully, unless an unexpected TCP file
transfer takes place.
The main issues that I am finding with the "reliable transport protocol"
that is being used with this application (lrmp) is that the recovery
process tends to cause more problems than it is worth.
Here is why:
1) If a station loses multicast packets, chances are, the entire
location lost the packets.
2) It does no good to attempt local recovery on the local segment since
everyone else probably lost it as well.
3) If a location loses multicast packets, chances are, the router
dropped the packets due to bandwidth constraints.
4) Recovery on a loaded line will just cause more packets to be
dropped.
5) If packets are not reliably recovered for, applications that expect
to read a stream from their buffer will time out waiting for the
recovery.
I feel that any sort of multicast recovery should be done through TCP
and to a single upstream source.
How about this scenario:
- Assumption is some sort of RTP header is placed in the multicast
packet which includes a sequence number, a tag as to if this packet
could be lost or MUST be recovered, and a timer value as to how soon
this recovery should take place before a failure should be noted.
- Utilize IGMP, or a similar protocol, to signal to the router that
recovery of a sequence number is necessary. The client would signal on
the group ID in which he lost the packet with a SEQUENCE_RECOVERY
payload type. In the payload data, he would include the sequence number
in which he is requesting.
- Any clients in this group that may have also lost packets would set
back off timers if they hear someone request their sequence. Much like
standard IGMP operation.
- The router would build an upstream TCP connection to it's RPF router
towards the source. It would query the RPF router to see if it has the
sequence number in its cache. If the RPF router does have the packet,
it would pass it down the TCP stream - to "guarantee" delivery of the
packet in the case that the line is still loaded - as to not cause the
recovery cycle to perform multiple recovery requests.
*Note: The router would only have one TCP stream to its upstream
neighbor no matter how many packets are being recovered. Therefore, if
all packets were lost to 5 clients at a remote location, there would
still only be a max. of 1x retransmission on the line since the
recovered packets would be multicast on the wire and only one station
would attempt recovery for the entire group. So if a line was fully
saturated, essentially, the multicast application would switch to a TCP
tunnel and maintain connectivity. This TCP "tunnel" should stay
established for X amount of time to keep from having to go through a
setup/teardown procedure for every missed packet. It may also be
convenient to create the tunnel if the bandwidth on the line crosses a
specified limit.
- If the RPF router does not have the sequence, it would perform the
same process until ultimately the source could be contacted. This
should never happen since the DR for the source should always have a
stable cache if it is connected to the source through a reliable
connection.
- Once the router gets the sequence, it would cache it and multicast it
out to its clients. This caching should be optional if the router is
attached to a single ethernet interface to reduce memory requirements at
the endpoints.
- All clients requesting this sequence would clear it from their
recovery list upon arrival. If they miss it, they would run through the
process again, only retrieve it from their local routers cache.
I think that a procedure such as this would allow for both reliable
packet delivery, as well as a reliable recovery from missed packets,
even under the constraints of a loaded line.
-me
Michael R. Eckhoff
Sr. WAN Comm Analyst
citigroup / The Associates
>From owner-rmt@listserv.lbl.gov Thu Mar 29 06:03:13 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.9.3) id f2TE37i12289;
Thu, 29 Mar 2001 06:03:07 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f2TE36c12285
for <rmt@listserv.lbl.gov>; Thu, 29 Mar 2001 06:03:06 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.9.3) with ESMTP id f2TE35i29715
for <rmt@listserv.lbl.gov>; Thu, 29 Mar 2001 06:03:05 -0800 (PST)
Received: from letters.cs.ucsb.edu (letters.cs.ucsb.edu [128.111.41.13])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f2TE34129709
for <rmt@lbl.gov>; Thu, 29 Mar 2001 06:03:05 -0800 (PST)
Received: from muddy.cs.ucsb.edu (muddy [128.111.49.130])
by letters.cs.ucsb.edu (8.9.3+Sun/8.9.3) with ESMTP id GAA00684;
Thu, 29 Mar 2001 06:02:48 -0800 (PST)
Received: by muddy.cs.ucsb.edu (8.9.3+Sun/SMI-SVR4)
id GAA07375 for ; Thu, 29 Mar 2001 06:02:49 -0800 (PST)
Date: Thu, 29 Mar 2001 06:02:49 -0800 (PST)
From: almeroth@cs.ucsb.edu (Kevin C. Almeroth)
Message-Id: <200103291402.GAA07375@muddy.cs.ucsb.edu>
To: katia@cse.ucsc.edu
Subject: Global Internet 2001 Deadline Extension
Sender: owner-rmt@lbl.gov
Precedence: bulk
Due to the numerous requests, etc. etc. we are extending the
deadline for Global Internet 2001 to April 8, 2001 at 11:59pm.
Another note. The submissions length is five pages. Papers
that are significantly over will NOT be reviewed.
---------------
Sixth Global Internet Symposium
in conjunction with
Globecom 2001
San Antonio, Texas, USA
November 25-29, 2001
http://www.cs.ucsb.edu/gi2001/
------------------------------------------------------------------------
Call For Papers
The sixth Global Internet Symposium will be held simultaneously and
co-located with Globecom 2001. Therefore, all of the relevant dates,
location, travel information are derived from the Globecom 2001
(http://www.globecom2001.com/) conference site.
Symposium Topics
Global Internet 2000 solicits technical papers on Internet-related topics.
The Program Committee encourages papers submitted on experimental systems
and emerging technologies. Also encouraged are original submissions
describing promising work in progress, original speculations about the
future of the Internet, and progressive position papers. Topics of interest
include, but are not limited to:
* Novel applications and new paradigms (telephony, streaming media, etc.)
* Distributed Internet applications (file sharing, games, conferencing, etc.)
* Service provisioning, monitoring, and management
* Privacy and/or security issues
* Charging and billing issues
* Handling Internet dynamics/heterogeneity (by applications and/or network)
* Routing (unicast, multicast, anycast, etc.)
* Traffic measurement, analysis, modeling, and visualization
* Flow management (fairness/sharing, differentiated services, etc.)
* The Internet and mobility/mobile devices
* Wireless device access and Internet gateways
Important Dates
Manuscript Submission: April 8, 2001 at 11:59pm PDT
Acceptance Notification: July 31, 2001
Final Manuscript: September 31, 2000
Submission Instructions
Please see the Global Internet Symposium WWW site at:
http://www.cs.ucsb.edu/gi2001/
Technical Program Chairs
Kevin Almeroth, UC-Santa Barbara (almeroth@cs.ucsb.edu)
Katia Obraczka, UC-Santa Cruz (katia@cse.ucsc.edu)
Program Committee
See the WWW page.
Sponsorship
The Global Internet Symposium is sponsored by the IEEE Communications
Society InternetTC.
>From owner-rmt@listserv.lbl.gov Thu Mar 29 08:38:19 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.9.3) id f2TGblM12629;
Thu, 29 Mar 2001 08:37:47 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f2TGbjc12625
for <rmt@listserv.lbl.gov>; Thu, 29 Mar 2001 08:37:45 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.9.3) with ESMTP id f2TGbjd01340
for <rmt@listserv.lbl.gov>; Thu, 29 Mar 2001 08:37:45 -0800 (PST)
Received: from nmh.informatik.uni-bremen.de (root@nmh.informatik.uni-bremen.de [134.102.224.3])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f2TGbh101332
for <rmt@lbl.gov>; Thu, 29 Mar 2001 08:37:44 -0800 (PST)
Received: from cabo3 (root@nmh.informatik.uni-bremen.de [134.102.224.3])
by nmh.informatik.uni-bremen.de (8.10.1/8.10.1) with SMTP id f2TGbbG02859;
Thu, 29 Mar 2001 18:37:37 +0200 (MEST)
From: "Dr. Carsten Bormann" <cabo@tzi.org>
To: "Michael R. Eckhoff" <foobar@null.net>, <rmt@lbl.gov>
Cc: <michael_eckhoff@AFCC.com>
Subject: RE: Multicast Recovery with Loaded Links
Date: Thu, 29 Mar 2001 18:37:36 +0200
Message-ID: <NEBBJFHFCKHKFCNLJJBPEEJEEOAA.cabo@tzi.org>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
In-Reply-To: <3AC33CF9.E43FFCC4@null.net>
Importance: Normal
Sender: owner-rmt@lbl.gov
Precedence: bulk
> 4) Recovery on a loaded line will just cause more packets to be
> dropped.
This is exactly the reason why RFC2357 ("IETF Criteria for Evaluating
Reliable Multicast Transport and Application Protocols") *requires*
congestion control.
Gruesse, Carsten
>From owner-rmt@listserv.lbl.gov Thu Mar 29 13:59:36 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.9.3) id f2TLx0114140;
Thu, 29 Mar 2001 13:59:00 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f2TLwxc14136
for <rmt@listserv.lbl.gov>; Thu, 29 Mar 2001 13:58:59 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.9.3) with ESMTP id f2TLwwk08188
for <rmt@listserv.lbl.gov>; Thu, 29 Mar 2001 13:58:58 -0800 (PST)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f2TLww108185
for <rmt@lbl.gov>; Thu, 29 Mar 2001 13:58:58 -0800 (PST)
Received: from lorenzo-u10.cisco.com (lorenzo-u10.cisco.com [10.34.54.43])
by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id NAA20530;
Thu, 29 Mar 2001 13:58:53 -0800 (PST)
Received: from localhost (lorenzo@localhost) by lorenzo-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id NAA00829; Thu, 29 Mar 2001 13:58:52 -0800 (PST)
Message-Id: <200103292158.NAA00829@lorenzo-u10.cisco.com>
X-Authentication-Warning: lorenzo-u10.cisco.com: lorenzo owned process doing -bs
X-Mailer: exmh version 2.0.2 2/24/98
To: Nipul Jayvant Shah <njshah@unity.ncsu.edu>
cc: rmt@lbl.gov
Subject: Re: security related concerns
In-Reply-To: Your message of "Wed, 28 Mar 2001 22:07:49 EST."
<Pine.GSO.4.33.0103282205020.13867-100000@uni01du.unity.ncsu.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 29 Mar 2001 13:58:52 -0800
From: Lorenzo Vicisano <lorenzo@cisco.com>
Sender: owner-rmt@lbl.gov
Precedence: bulk
Nipul,
There has been some discussion on this in the context of protocol
instantiations and building blocks, however better places to ask this
this question are smug@cs.umass.edu (secure multicast IRTF group) or
msec@securemulticast.org (IETF group).
Lorenzo
In message <Pine.GSO.4.33.0103282205020.13867-100000@uni01du.unity.ncsu.edu>,
Nipul Jayvant Shah writes:
> Hi! I am a graduate student at NC State. I wanted to know if the RMT WG
> has already conducted some research work related to the security issues of
> RMT, especially concerning the denial of service attacks. If so, could
> anyone suggest the related drafts?
>
> Regards,
>
> Nipul Shah
> NCSU, Raleigh, NC.
>From owner-rmt@listserv.lbl.gov Thu Mar 29 14:07:45 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.9.3) id f2TM7go14191;
Thu, 29 Mar 2001 14:07:42 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f2TM7ec14187
for <rmt@listserv.lbl.gov>; Thu, 29 Mar 2001 14:07:41 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.9.3) with ESMTP id f2TM7e011192
for <rmt@listserv.lbl.gov>; Thu, 29 Mar 2001 14:07:40 -0800 (PST)
Received: from dargo.talarian.com (talarian33-3.talarian.com [207.5.33.3])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f2TM7e111189
for <rmt@lbl.gov>; Thu, 29 Mar 2001 14:07:40 -0800 (PST)
Received: from moya.talarian.com (moya.talarian.com [10.4.10.8])
by dargo.talarian.com (Postfix) with ESMTP
id 7CAC022B05; Thu, 29 Mar 2001 14:07:29 -0800 (PST)
Received: from C1538898-B.talarian.com (unknown [10.7.1.241])
by moya.talarian.com (Postfix) with ESMTP
id 3640D11A; Thu, 29 Mar 2001 14:07:23 -0800 (PST)
Message-Id: <5.0.2.1.2.20010329115232.06ad2e90@mailhost.talarian.com>
X-Sender: bwhetten@mailhost.talarian.com
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
Date: Thu, 29 Mar 2001 11:53:52 -0800
To: "Dr. Carsten Bormann" <cabo@tzi.org>,
"Jeremiah Scholl" <jeremiah@cdt.luth.se>, <rmt@lbl.gov>
From: Brian Whetten <whetten@talarian.com>
Subject: RE: local recovery and NORM
Cc: "Peter Parnes" <peppar@cdt.luth.se>
In-Reply-To: <NEBBJFHFCKHKFCNLJJBPKEIHEOAA.cabo@tzi.org>
References: <Pine.GSO.4.21.0103291308200.17188-100000@delta1.sm.luth.se>
Mime-Version: 1.0
Content-Type: multipart/alternative;
boundary="=====================_92387416==_.ALT"
Sender: owner-rmt@lbl.gov
Precedence: bulk
--=====================_92387416==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed
The other alternative for local recovery is to use TRACK, which will be
hierarchical in nature, but will use a minimum of hard state, so that it
keep much of the flexibility and fault resilience of NORM. TRACK primarily
uses local multicast addresses for repairs.
Brian
At 01:44 PM 3/29/2001 +0200, Dr. Carsten Bormann wrote:
>Jeremiah,
>
>one of the main points of NORM is to be simple, so NORM-PI should probably
>not try to implement local recovery.
>The NORM building block will certainly allow for local receovery, though.
>Adding local recovery is probably most useful in cooperation with GRA, which
>still is in the process of solidifying.
>
>Gruesse, Carsten
>
> > -----Original Message-----
> > From: owner-rmt@lbl.gov [mailto:owner-rmt@lbl.gov]On Behalf Of Jeremiah
> > Scholl
> > Sent: Thursday, March 29, 2001 13:13
> > To: rmt@lbl.gov
> > Cc: Peter Parnes
> > Subject: local recovery and NORM
> >
> >
> > Can anyone out there give me information regarding the NORM protocol and
> > local recovery mechanisms. Is there a plan to add local recovery to NORM
> > before it is standardized? If so, which type of local recovery scheme
> > (hop-scoped, group-scoped ect.) will most likley be a part of the
> > protocol.
> >
> > Thanks!
> >
> > Jeremiah Scholl
> >
--=====================_92387416==_.ALT
Content-Type: text/html; charset="us-ascii"
<html>
<font size=3>The other alternative for local recovery is to use TRACK,
which will be hierarchical in nature, but will use a minimum of hard
state, so that it keep much of the flexibility and fault resilience of
NORM. TRACK primarily uses local multicast addresses for
repairs.<br>
<br>
Brian<br>
<br>
At 01:44 PM 3/29/2001 +0200, Dr. Carsten Bormann wrote:<br>
<blockquote type=cite class=cite cite>Jeremiah,<br>
<br>
one of the main points of NORM is to be simple, so NORM-PI should
probably<br>
not try to implement local recovery.<br>
The NORM building block will certainly allow for local receovery,
though.<br>
Adding local recovery is probably most useful in cooperation with GRA,
which<br>
still is in the process of solidifying.<br>
<br>
Gruesse, Carsten<br>
<br>
> -----Original Message-----<br>
> From: owner-rmt@lbl.gov
[<a href="mailto:owner-rmt@lbl.gov" eudora="autourl">mailto:owner-rmt@lbl.gov</a>]On
Behalf Of Jeremiah<br>
> Scholl<br>
> Sent: Thursday, March 29, 2001 13:13<br>
> To: rmt@lbl.gov<br>
> Cc: Peter Parnes<br>
> Subject: local recovery and NORM<br>
><br>
><br>
> Can anyone out there give me information regarding the NORM protocol
and<br>
> local recovery mechanisms. Is there a plan to add local
recovery to NORM<br>
> before it is standardized? If so, which type of local recovery
scheme<br>
> (hop-scoped, group-scoped ect.) will most likley be a part of
the<br>
> protocol.<br>
><br>
> Thanks!<br>
><br>
> Jeremiah Scholl<br>
></font></blockquote><br>
</html>
--=====================_92387416==_.ALT--
>From owner-rmt@listserv.lbl.gov Thu Mar 29 14:48:49 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.9.3) id f2TMmdK14299;
Thu, 29 Mar 2001 14:48:39 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f2TMmcc14295
for <rmt@listserv.lbl.gov>; Thu, 29 Mar 2001 14:48:38 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.9.3) with ESMTP id f2TMmbH25794
for <rmt@listserv.lbl.gov>; Thu, 29 Mar 2001 14:48:37 -0800 (PST)
Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f2TMmb125791
for <rmt@lbl.gov>; Thu, 29 Mar 2001 14:48:37 -0800 (PST)
Received: from SEXTANT.itd.nrl.navy.mil (sextant.itd.nrl.navy.mil [132.250.92.22])
by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id RAA11279;
Thu, 29 Mar 2001 17:48:29 -0500 (EST)
Message-Id: <5.0.1.4.2.20010329174312.01e043b0@pop.itd.nrl.navy.mil>
X-Sender: macker@pop.itd.nrl.navy.mil
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Thu, 29 Mar 2001 17:50:25 -0500
To: "Dr. Carsten Bormann" <cabo@tzi.org>,
"Jeremiah Scholl" <jeremiah@cdt.luth.se>, <rmt@lbl.gov>
From: Joe Macker <macker@itd.nrl.navy.mil>
Subject: RE: local recovery and NORM
Cc: "Peter Parnes" <peppar@cdt.luth.se>
In-Reply-To: <NEBBJFHFCKHKFCNLJJBPKEIHEOAA.cabo@tzi.org>
References: <Pine.GSO.4.21.0103291308200.17188-100000@delta1.sm.luth.se>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-rmt@lbl.gov
Precedence: bulk
Jeremiah,
I agree with Carsten's observations on the PI.
The NORM-PI to be well-suited for single-source multicast environments.
The building block should not preclude its use.
As mentioned, GRA and TRACK are both potential candidates for adding this.
-Joe
At 01:44 PM 3/29/2001 +0200, Dr. Carsten Bormann wrote:
>Jeremiah,
>
>one of the main points of NORM is to be simple, so NORM-PI should probably
>not try to implement local recovery.
>The NORM building block will certainly allow for local receovery, though.
>Adding local recovery is probably most useful in cooperation with GRA, which
>still is in the process of solidifying.
>
>Gruesse, Carsten
>
> > -----Original Message-----
> > From: owner-rmt@lbl.gov [mailto:owner-rmt@lbl.gov]On Behalf Of Jeremiah
> > Scholl
> > Sent: Thursday, March 29, 2001 13:13
> > To: rmt@lbl.gov
> > Cc: Peter Parnes
> > Subject: local recovery and NORM
> >
> >
> > Can anyone out there give me information regarding the NORM protocol and
> > local recovery mechanisms. Is there a plan to add local recovery to NORM
> > before it is standardized? If so, which type of local recovery scheme
> > (hop-scoped, group-scoped ect.) will most likley be a part of the
> > protocol.
> >
> > Thanks!
> >
> > Jeremiah Scholl
> >
>From owner-rmt@listserv.lbl.gov Thu Mar 29 15:23:13 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.9.3) id f2TNMpP14372;
Thu, 29 Mar 2001 15:22:51 -0800 (PST)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f2TNMnc14368
for <rmt@listserv.lbl.gov>; Thu, 29 Mar 2001 15:22:49 -0800 (PST)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.9.3) with ESMTP id f2TNMmN07598
for <rmt@listserv.lbl.gov>; Thu, 29 Mar 2001 15:22:48 -0800 (PST)
Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f2TNMl107589
for <rmt@lbl.gov>; Thu, 29 Mar 2001 15:22:48 -0800 (PST)
Received: from zcard00m.ca.nortel.com by zcars04f.ca.nortel.com;
Thu, 29 Mar 2001 17:49:12 -0500
Received: from zbl6c002.corpeast.baynetworks.com ([132.245.205.52])
by zcard00m.ca.nortel.com
with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
id HS2D2ZQY; Thu, 29 Mar 2001 17:49:12 -0500
Received: from hardjono.nortelnetworks.com (dhcp137-148.engeast.baynetworks.com [192.32.137.148])
by zbl6c002.corpeast.baynetworks.com
with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
id GPSTFA0T; Thu, 29 Mar 2001 17:49:11 -0500
Message-Id: <4.3.1.2.20010329175512.01a7a210@ZBL6C002.corpeast.baynetworks.com>
X-Sender: hardjono@ZBL6C002.corpeast.baynetworks.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Thu, 29 Mar 2001 17:58:07 -0500
To: Lorenzo Vicisano <lorenzo@cisco.com>,
Nipul Jayvant Shah <njshah@unity.ncsu.edu>
From: "Thomas Hardjono" <hardjono@nortelnetworks.com>
Subject: Re: security related concerns
Cc: rmt@lbl.gov
In-Reply-To: <200103292158.NAA00829@lorenzo-u10.cisco.com>
References: <Your message of "Wed,
28 Mar 2001 22:07:49 EST." <Pine.GSO.4.33.0103282205020.13867-100000@uni01du.unity.ncsu.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Orig: <hardjono@nortelnetworks.com>
Sender: owner-rmt@lbl.gov
Precedence: bulk
Hi,
There is the TRACK security draft, which originated from work
on RMTP-II security.
There should be a NORM Security draft very soon.
cheers,
thomas
------
At 3/29/01||01:58 PM, Lorenzo Vicisano wrote:
>Nipul,
>
>There has been some discussion on this in the context of protocol
>instantiations and building blocks, however better places to ask this
>this question are smug@cs.umass.edu (secure multicast IRTF group) or
>msec@securemulticast.org (IETF group).
>
> Lorenzo
>
>In message <Pine.GSO.4.33.0103282205020.13867-100000@uni01du.unity.ncsu.edu>,
>Nipul Jayvant Shah writes:
> > Hi! I am a graduate student at NC State. I wanted to know if the RMT WG
> > has already conducted some research work related to the security issues of
> > RMT, especially concerning the denial of service attacks. If so, could
> > anyone suggest the related drafts?
> >
> > Regards,
> >
> > Nipul Shah
> > NCSU, Raleigh, NC.
>From owner-rmt@listserv.lbl.gov Mon Apr 2 04:34:18 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.9.3) id f32BVHj22429;
Mon, 2 Apr 2001 04:31:17 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f32BVFc22425
for <rmt@listserv.lbl.gov>; Mon, 2 Apr 2001 04:31:15 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.9.3) with ESMTP id f32BVEK17251
for <rmt@listserv.lbl.gov>; Mon, 2 Apr 2001 04:31:15 -0700 (PDT)
Received: from sm.luth.se (ny.sm.luth.se [130.240.3.1])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f32BVD117248
for <rmt@lbl.gov>; Mon, 2 Apr 2001 04:31:13 -0700 (PDT)
Received: from delta1.sm.luth.se (delta1.sm.luth.se [130.240.3.7])
by sm.luth.se (8.10.0/8.10.0) with ESMTP id f32BVM501096;
Mon, 2 Apr 2001 13:31:23 +0200 (MET DST)
Date: Mon, 2 Apr 2001 13:31:10 +0200 (MET DST)
From: Jeremiah Scholl <jeremiah@cdt.luth.se>
To: rmt@lbl.gov
cc: Peter Parnes <peppar@cdt.luth.se>
Subject: tcp-friendliness
Message-ID: <Pine.GSO.4.21.0104021330360.4777-100000@delta1.sm.luth.se>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-rmt@lbl.gov
Precedence: bulk
Can anyone tell me if there is any generaly accepted definition for
TCP-friendliness regarding reliable multicast. The reason I am asking is
that the PGMCC paper (the version that was presented at SIGCOMM) has the
following statement near the end of section 4.4
"in the presence of multiple receivers, there is no clear definition of a
TCP-fair rate."
Can anyone help clarify this for me? Does the IETF have any plans to
standardize the definitions of TCP-fair or TCP-friendly with regards to
reliable multicast?
Thanks!
Jeremiah
>From owner-rmt@listserv.lbl.gov Mon Apr 2 06:08:18 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.9.3) id f32D7pV23272;
Mon, 2 Apr 2001 06:07:51 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f32D7oc23268
for <rmt@listserv.lbl.gov>; Mon, 2 Apr 2001 06:07:50 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.9.3) with ESMTP id f32D7n625047
for <rmt@listserv.lbl.gov>; Mon, 2 Apr 2001 06:07:49 -0700 (PDT)
Received: from info.iet.unipi.it (info.iet.unipi.it [131.114.9.184])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f32D7m125042
for <rmt@lbl.gov>; Mon, 2 Apr 2001 06:07:48 -0700 (PDT)
Received: (from luigi@localhost)
by info.iet.unipi.it (8.9.3/8.9.3) id PAA51751;
Mon, 2 Apr 2001 15:07:04 +0200 (CEST)
(envelope-from luigi)
From: Luigi Rizzo <luigi@info.iet.unipi.it>
Message-Id: <200104021307.PAA51751@info.iet.unipi.it>
Subject: Re: tcp-friendliness
In-Reply-To: <Pine.GSO.4.21.0104021330360.4777-100000@delta1.sm.luth.se> from
Jeremiah Scholl at "Apr 2, 2001 01:31:10 pm"
To: Jeremiah Scholl <jeremiah@cdt.luth.se>
Date: Mon, 2 Apr 2001 15:07:04 +0200 (CEST)
CC: rmt@lbl.gov, Peter Parnes <peppar@cdt.luth.se>
X-Mailer: ELM [version 2.4ME+ PL61 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-rmt@lbl.gov
Precedence: bulk
> Can anyone tell me if there is any generaly accepted definition for
> TCP-friendliness regarding reliable multicast. The reason I am asking is
> that the PGMCC paper (the version that was presented at SIGCOMM) has the
> following statement near the end of section 4.4
>
> "in the presence of multiple receivers, there is no clear definition of a
> TCP-fair rate."
the issue there is that when you have a bunch of receivers behind
the same bottleneck and different RTTs with the source, you
have different values from the TCP formula for the different
receivers. If only one of the receivers in the set -- any of them
-- was active, then the rate associated with that receiver would
certainly be TCP-friendly (PGMCC with one receiver is just TCP).
The presence of other receivers in the group which do not cause
additional traffic through the bottleneck should reasonably not
change the judgement, but then it means that any rate in the set
is equally good.
cheers
luigi
> Can anyone help clarify this for me? Does the IETF have any plans to
> standardize the definitions of TCP-fair or TCP-friendly with regards to
> reliable multicast?
>
> Thanks!
>
> Jeremiah
>
>
>
>
>From owner-rmt@listserv.lbl.gov Mon Apr 2 06:16:04 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.9.3) id f32DFeR23301;
Mon, 2 Apr 2001 06:15:40 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f32DFdc23297
for <rmt@listserv.lbl.gov>; Mon, 2 Apr 2001 06:15:39 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.9.3) with ESMTP id f32DFcu25685
for <rmt@listserv.lbl.gov>; Mon, 2 Apr 2001 06:15:38 -0700 (PDT)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
by SpamWall.lbl.gov (8.11.2/8.11.2) with SMTP id f32DFb125680
for <rmt@lbl.gov>; Mon, 2 Apr 2001 06:15:38 -0700 (PDT)
Received: from hocus.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP
id <g.24181-0@bells.cs.ucl.ac.uk>; Mon, 2 Apr 2001 14:15:30 +0100
To: Luigi Rizzo <luigi@info.iet.unipi.it>
cc: Jeremiah Scholl <jeremiah@cdt.luth.se>, rmt@lbl.gov,
Peter Parnes <peppar@cdt.luth.se>
Subject: Re: tcp-friendliness
In-reply-to: Your message of "Mon, 02 Apr 2001 15:07:04 +0200." <200104021307.PAA51751@info.iet.unipi.it>
Date: Mon, 02 Apr 2001 14:15:27 +0100
Message-ID: <2723.986217327@cs.ucl.ac.uk>
From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
Sender: owner-rmt@lbl.gov
Precedence: bulk
i thought it was that you have 1 equation in two variables, (
rate as a function of loss average and rtt) so you can
define an infinite number of different fairness models depending
whether you want to be fair to rtt (proportional) or loss (max min)?
In message <200104021307.PAA51751@info.iet.unipi.it>, Luigi Rizzo typed:
>>> Can anyone tell me if there is any generaly accepted definition for
>>> TCP-friendliness regarding reliable multicast. The reason I am asking is
>>> that the PGMCC paper (the version that was presented at SIGCOMM) has the
>>> following statement near the end of section 4.4
>>>
>>> "in the presence of multiple receivers, there is no clear definition of a
>>> TCP-fair rate."
>>
>>the issue there is that when you have a bunch of receivers behind
>>the same bottleneck and different RTTs with the source, you
>>have different values from the TCP formula for the different
>>receivers. If only one of the receivers in the set -- any of them
>>-- was active, then the rate associated with that receiver would
>>certainly be TCP-friendly (PGMCC with one receiver is just TCP).
>>The presence of other receivers in the group which do not cause
>>additional traffic through the bottleneck should reasonably not
>>change the judgement, but then it means that any rate in the set
>>is equally good.
>>
>>
>> cheers
>> luigi
>>
>>> Can anyone help clarify this for me? Does the IETF have any plans to
>>> standardize the definitions of TCP-fair or TCP-friendly with regards to
>>> reliable multicast?
>>>
>>> Thanks!
>>>
>>> Jeremiah
>>>
>>>
>>>
>>>
>>
cheers
jon
>From owner-rmt@listserv.lbl.gov Mon Apr 2 06:50:42 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.9.3) id f32DoPp23539;
Mon, 2 Apr 2001 06:50:25 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f32DoOc23535
for <rmt@listserv.lbl.gov>; Mon, 2 Apr 2001 06:50:24 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.9.3) with ESMTP id f32DoNj29423
for <rmt@listserv.lbl.gov>; Mon, 2 Apr 2001 06:50:23 -0700 (PDT)
Received: from info.iet.unipi.it (info.iet.unipi.it [131.114.9.184])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f32DoM129413
for <rmt@lbl.gov>; Mon, 2 Apr 2001 06:50:22 -0700 (PDT)
Received: (from luigi@localhost)
by info.iet.unipi.it (8.9.3/8.9.3) id PAA51999;
Mon, 2 Apr 2001 15:49:36 +0200 (CEST)
(envelope-from luigi)
From: Luigi Rizzo <luigi@info.iet.unipi.it>
Message-Id: <200104021349.PAA51999@info.iet.unipi.it>
Subject: Re: tcp-friendliness
In-Reply-To: <2723.986217327@cs.ucl.ac.uk> from Jon Crowcroft at "Apr 2, 2001
02:15:27 pm"
To: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
Date: Mon, 2 Apr 2001 15:49:36 +0200 (CEST)
CC: Jeremiah Scholl <jeremiah@cdt.luth.se>, rmt@lbl.gov,
Peter Parnes <peppar@cdt.luth.se>
X-Mailer: ELM [version 2.4ME+ PL61 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-rmt@lbl.gov
Precedence: bulk
> i thought it was that you have 1 equation in two variables, (
> rate as a function of loss average and rtt) so you can
> define an infinite number of different fairness models depending
> whether you want to be fair to rtt (proportional) or loss (max min)?
It is an orthogonal problem. Even if you [can] choose the working
point, you still do not know which receiver's data to
plug in the equation.
cheers
luigi
> In message <200104021307.PAA51751@info.iet.unipi.it>, Luigi Rizzo typed:
>
> >>> Can anyone tell me if there is any generaly accepted definition for
> >>> TCP-friendliness regarding reliable multicast. The reason I am asking is
> >>> that the PGMCC paper (the version that was presented at SIGCOMM) has the
> >>> following statement near the end of section 4.4
> >>>
> >>> "in the presence of multiple receivers, there is no clear definition of a
> >>> TCP-fair rate."
> >>
> >>the issue there is that when you have a bunch of receivers behind
> >>the same bottleneck and different RTTs with the source, you
> >>have different values from the TCP formula for the different
> >>receivers. If only one of the receivers in the set -- any of them
> >>-- was active, then the rate associated with that receiver would
> >>certainly be TCP-friendly (PGMCC with one receiver is just TCP).
> >>The presence of other receivers in the group which do not cause
> >>additional traffic through the bottleneck should reasonably not
> >>change the judgement, but then it means that any rate in the set
> >>is equally good.
> >>
> >>
> >> cheers
> >> luigi
> >>
> >>> Can anyone help clarify this for me? Does the IETF have any plans to
> >>> standardize the definitions of TCP-fair or TCP-friendly with regards to
> >>> reliable multicast?
> >>>
> >>> Thanks!
> >>>
> >>> Jeremiah
> >>>
> >>>
> >>>
> >>>
> >>
>
> cheers
>
> jon
>
>
>From owner-rmt@listserv.lbl.gov Mon Apr 2 08:50:40 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.9.3) id f32FneK23678;
Mon, 2 Apr 2001 08:49:40 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f32Fncc23674
for <rmt@listserv.lbl.gov>; Mon, 2 Apr 2001 08:49:39 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.9.3) with ESMTP id f32FncW26902
for <rmt@listserv.lbl.gov>; Mon, 2 Apr 2001 08:49:38 -0700 (PDT)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
by SpamWall.lbl.gov (8.11.2/8.11.2) with SMTP id f32Fna126876
for <rmt@lbl.gov>; Mon, 2 Apr 2001 08:49:36 -0700 (PDT)
Received: from hocus.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP
id <g.07837-0@bells.cs.ucl.ac.uk>; Mon, 2 Apr 2001 16:49:25 +0100
To: Luigi Rizzo <luigi@info.iet.unipi.it>
cc: Jeremiah Scholl <jeremiah@cdt.luth.se>, rmt@lbl.gov,
Peter Parnes <peppar@cdt.luth.se>, J.Crowcroft@cs.ucl.ac.uk
Subject: Re: tcp-friendliness
In-reply-to: Your message of "Mon, 02 Apr 2001 15:49:36 +0200." <200104021349.PAA51999@info.iet.unipi.it>
Date: Mon, 02 Apr 2001 16:49:22 +0100
Message-ID: <3151.986226562@cs.ucl.ac.uk>
From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
Sender: owner-rmt@lbl.gov
Precedence: bulk
In message <200104021349.PAA51999@info.iet.unipi.it>, Luigi Rizzo typed:
>>> i thought it was that you have 1 equation in two variables, (
>>> rate as a function of loss average and rtt) so you can
>>> define an infinite number of different fairness models depending
>>> whether you want to be fair to rtt (proportional) or loss (max min)?
>>It is an orthogonal problem. Even if you [can] choose the working
>>point, you still do not know which receiver's data to
>>plug in the equation.
luigi
asuming i can solve the insoluble (getting feedback on RTT and loss
rate on all the edges of the tree) then
for proportional fairness, i can define a rule for combining
the edges based on axiomatic tree weighting rules - for max min, i
dont have to since its just the bottleneck that matters
but in practice, you're right (of course
>>> In message <200104021307.PAA51751@info.iet.unipi.it>, Luigi Rizzo typed:
>>>
>>> >>> Can anyone tell me if there is any generaly accepted definition for
>>> >>> TCP-friendliness regarding reliable multicast. The reason I am asking is
>>> >>> that the PGMCC paper (the version that was presented at SIGCOMM) has the
>>> >>> following statement near the end of section 4.4
>>> >>>
>>> >>> "in the presence of multiple receivers, there is no clear definition of a
>>> >>> TCP-fair rate."
>>> >>
>>> >>the issue there is that when you have a bunch of receivers behind
>>> >>the same bottleneck and different RTTs with the source, you
>>> >>have different values from the TCP formula for the different
>>> >>receivers. If only one of the receivers in the set -- any of them
>>> >>-- was active, then the rate associated with that receiver would
>>> >>certainly be TCP-friendly (PGMCC with one receiver is just TCP).
>>> >>The presence of other receivers in the group which do not cause
>>> >>additional traffic through the bottleneck should reasonably not
>>> >>change the judgement, but then it means that any rate in the set
>>> >>is equally good.
>>> >>
>>> >>
>>> >> cheers
>>> >> luigi
>>> >>
>>> >>> Can anyone help clarify this for me? Does the IETF have any plans to
>>> >>> standardize the definitions of TCP-fair or TCP-friendly with regards to
>>> >>> reliable multicast?
>>> >>>
>>> >>> Thanks!
>>> >>>
>>> >>> Jeremiah
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>
>>>
>>> cheers
>>>
>>> jon
>>>
>>>
>>
cheers
jon
>From owner-rmt@listserv.lbl.gov Mon Apr 2 11:27:23 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.9.3) id f32IQkS00759;
Mon, 2 Apr 2001 11:26:46 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f32IQic00755
for <rmt@listserv.lbl.gov>; Mon, 2 Apr 2001 11:26:44 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.9.3) with ESMTP id f32IQhW02475
for <rmt@listserv.lbl.gov>; Mon, 2 Apr 2001 11:26:43 -0700 (PDT)
Received: from usc.edu (root@usc.edu [128.125.253.136])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f32IQg102468
for <rmt@lbl.gov>; Mon, 2 Apr 2001 11:26:42 -0700 (PDT)
Received: from scf-fs.usc.edu (root@scf-fs.usc.edu [128.125.253.183])
by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP
id LAA01184; Mon, 2 Apr 2001 11:26:31 -0700 (PDT)
Received: from protest2 (protest2.usc.edu [128.125.72.115])
by scf-fs.usc.edu (8.9.3.1/8.9.3/usc) with SMTP
id LAA01417; Mon, 2 Apr 2001 11:26:32 -0700 (PDT)
Message-ID: <008101c0bba2$0caf3940$73487d80@protest2>
From: "Karim Seada" <seada@usc.edu>
To: <rmt@lbl.gov>
Cc: "Luigi Rizzo" <luigi@info.iet.unipi.it>, <J.Crowcroft@cs.ucl.ac.uk>,
"Peter Parnes" <peppar@cdt.luth.se>,
"Jeremiah Scholl" <jeremiah@cdt.luth.se>
References: <200104021307.PAA51751@info.iet.unipi.it>
Subject: Re: tcp-friendliness
Date: Mon, 2 Apr 2001 11:23:43 -0700
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-rmt@lbl.gov
Precedence: bulk
But even in the simple case, where all receivers share the same bottleneck link,
but have different RTTs. If the rate is not associated with the receiver with
the highest RTT, it is not clear that TCP-friendliness would be achieved with
other competing TCP flows with high RTT (their rate according to the formula
will be less).
Karim Seada
----- Original Message -----
From: "Luigi Rizzo" <luigi@info.iet.unipi.it>
To: "Jeremiah Scholl" <jeremiah@cdt.luth.se>
Cc: <rmt@lbl.gov>; "Peter Parnes" <peppar@cdt.luth.se>
Sent: Monday, April 02, 2001 6:07 AM
Subject: Re: tcp-friendliness
> > Can anyone tell me if there is any generaly accepted definition for
> > TCP-friendliness regarding reliable multicast. The reason I am asking is
> > that the PGMCC paper (the version that was presented at SIGCOMM) has the
> > following statement near the end of section 4.4
> >
> > "in the presence of multiple receivers, there is no clear definition of a
> > TCP-fair rate."
>
> the issue there is that when you have a bunch of receivers behind
> the same bottleneck and different RTTs with the source, you
> have different values from the TCP formula for the different
> receivers. If only one of the receivers in the set -- any of them
> -- was active, then the rate associated with that receiver would
> certainly be TCP-friendly (PGMCC with one receiver is just TCP).
> The presence of other receivers in the group which do not cause
> additional traffic through the bottleneck should reasonably not
> change the judgement, but then it means that any rate in the set
> is equally good.
>
>
> cheers
> luigi
>
> > Can anyone help clarify this for me? Does the IETF have any plans to
> > standardize the definitions of TCP-fair or TCP-friendly with regards to
> > reliable multicast?
> >
> > Thanks!
> >
> > Jeremiah
> >
> >
> >
> >
>
>From owner-rmt@listserv.lbl.gov Mon Apr 2 11:31:58 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.9.3) id f32IVsA00909;
Mon, 2 Apr 2001 11:31:54 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f32IVqc00905
for <rmt@listserv.lbl.gov>; Mon, 2 Apr 2001 11:31:53 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.9.3) with ESMTP id f32IVq104663
for <rmt@listserv.lbl.gov>; Mon, 2 Apr 2001 11:31:52 -0700 (PDT)
Received: from info.iet.unipi.it (info.iet.unipi.it [131.114.9.184])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f32IVp104653
for <rmt@lbl.gov>; Mon, 2 Apr 2001 11:31:51 -0700 (PDT)
Received: (from luigi@localhost)
by info.iet.unipi.it (8.9.3/8.9.3) id UAA54232;
Mon, 2 Apr 2001 20:31:05 +0200 (CEST)
(envelope-from luigi)
From: Luigi Rizzo <luigi@info.iet.unipi.it>
Message-Id: <200104021831.UAA54232@info.iet.unipi.it>
Subject: Re: tcp-friendliness
In-Reply-To: <008101c0bba2$0caf3940$73487d80@protest2> from Karim Seada at "Apr
2, 2001 11:23:43 am"
To: Karim Seada <seada@usc.edu>
Date: Mon, 2 Apr 2001 20:31:05 +0200 (CEST)
CC: rmt@lbl.gov, J.Crowcroft@cs.ucl.ac.uk, Peter Parnes <peppar@cdt.luth.se>,
Jeremiah Scholl <jeremiah@cdt.luth.se>
X-Mailer: ELM [version 2.4ME+ PL61 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-rmt@lbl.gov
Precedence: bulk
[Charset iso-8859-1 unsupported, filtering to ASCII...]
> But even in the simple case, where all receivers share the same bottleneck link,
> but have different RTTs. If the rate is not associated with the receiver with
> the highest RTT, it is not clear that TCP-friendliness would be achieved with
> other competing TCP flows with high RTT (their rate according to the formula
> will be less).
and vice-versa. However you choose the representative, you make a
mistake when comparing with unicast TCP sessions with a different RTT.
cheers
luigi
> Karim Seada
>
> ----- Original Message -----
> From: "Luigi Rizzo" <luigi@info.iet.unipi.it>
> To: "Jeremiah Scholl" <jeremiah@cdt.luth.se>
> Cc: <rmt@lbl.gov>; "Peter Parnes" <peppar@cdt.luth.se>
> Sent: Monday, April 02, 2001 6:07 AM
> Subject: Re: tcp-friendliness
>
>
> > > Can anyone tell me if there is any generaly accepted definition for
> > > TCP-friendliness regarding reliable multicast. The reason I am asking is
> > > that the PGMCC paper (the version that was presented at SIGCOMM) has the
> > > following statement near the end of section 4.4
> > >
> > > "in the presence of multiple receivers, there is no clear definition of a
> > > TCP-fair rate."
> >
> > the issue there is that when you have a bunch of receivers behind
> > the same bottleneck and different RTTs with the source, you
> > have different values from the TCP formula for the different
> > receivers. If only one of the receivers in the set -- any of them
> > -- was active, then the rate associated with that receiver would
> > certainly be TCP-friendly (PGMCC with one receiver is just TCP).
> > The presence of other receivers in the group which do not cause
> > additional traffic through the bottleneck should reasonably not
> > change the judgement, but then it means that any rate in the set
> > is equally good.
> >
> >
> > cheers
> > luigi
> >
> > > Can anyone help clarify this for me? Does the IETF have any plans to
> > > standardize the definitions of TCP-fair or TCP-friendly with regards to
> > > reliable multicast?
> > >
> > > Thanks!
> > >
> > > Jeremiah
> > >
> > >
> > >
> > >
> >
>
>
>From owner-rmt@listserv.lbl.gov Mon Apr 2 12:00:14 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.9.3) id f32J02A01039;
Mon, 2 Apr 2001 12:00:02 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f32J00c01035
for <rmt@listserv.lbl.gov>; Mon, 2 Apr 2001 12:00:00 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.9.3) with ESMTP id f32J00R15498
for <rmt@listserv.lbl.gov>; Mon, 2 Apr 2001 12:00:00 -0700 (PDT)
Received: from daffy.ee.lbl.gov (daffy.ee.lbl.gov [131.243.1.31])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f32Ixx115478
for <rmt@lbl.gov>; Mon, 2 Apr 2001 11:59:59 -0700 (PDT)
Received: (from vern@localhost)
by daffy.ee.lbl.gov (8.10.0/8.10.0) id f32Ixxn20841;
Mon, 2 Apr 2001 11:59:59 -0700 (PDT)
Message-Id: <200104021859.f32Ixxn20841@daffy.ee.lbl.gov>
To: rmt@lbl.gov
Subject: Administrative: cleanup of rmt@lbl.gov mailing list
In-reply-to: Your message of Sat, 24 Mar 2001 01:34:17 PST.
Date: Mon, 02 Apr 2001 11:59:59 PDT
From: Vern Paxson <vern@ee.lbl.gov>
Sender: owner-rmt@lbl.gov
Precedence: bulk
FYI, the following usernames have been deleted due to hard bounces:
Antoine.Clerget@sophia.inria.fr
markg@entera.com
- Vern
>From owner-rmt@listserv.lbl.gov Mon Apr 2 12:29:55 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.9.3) id f32JTV101085;
Mon, 2 Apr 2001 12:29:31 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f32JTTc01081
for <rmt@listserv.lbl.gov>; Mon, 2 Apr 2001 12:29:29 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.9.3) with ESMTP id f32JTSn26103
for <rmt@listserv.lbl.gov>; Mon, 2 Apr 2001 12:29:28 -0700 (PDT)
Received: from multicasttech.com (IDENT:root@garcia.multicasttech.com [63.105.122.8])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f32JTQ126091
for <rmt@lbl.gov>; Mon, 2 Apr 2001 12:29:27 -0700 (PDT)
Received: from [63.105.122.193] (HELO 21rst-century.com)
by multicasttech.com (CommuniGate Pro SMTP 3.3.2)
with ESMTP id 840780; Mon, 02 Apr 2001 15:27:24 -0400
Message-ID: <3AC8D314.9281DAB4@21rst-century.com>
Date: Mon, 02 Apr 2001 15:29:22 -0400
From: Marshall Eubanks <tme@21rst-century.com>
Reply-To: tme@21rst-century.com
Organization: Multicast Technologies
X-Mailer: Mozilla 4.7C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; I; PPC)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: Jeremiah Scholl <jeremiah@cdt.luth.se>
CC: rmt@lbl.gov, Peter Parnes <peppar@cdt.luth.se>
Subject: Re: tcp-friendliness
References: <Pine.GSO.4.21.0104021330360.4777-100000@delta1.sm.luth.se>
Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353"
Content-Transfer-Encoding: 7bit
Sender: owner-rmt@lbl.gov
Precedence: bulk
Jeremiah Scholl wrote:
> Can anyone tell me if there is any generaly accepted definition for
> TCP-friendliness regarding reliable multicast. The reason I am asking is
> that the PGMCC paper (the version that was presented at SIGCOMM) has the
> following statement near the end of section 4.4
>
> "in the presence of multiple receivers, there is no clear definition of a
> TCP-fair rate."
>
> Can anyone help clarify this for me? Does the IETF have any plans to
> standardize the definitions of TCP-fair or TCP-friendly with regards to
> reliable multicast?
>
> Thanks!
>
> Jeremiah
My personal, and unpopular, opinion is that this is not a well-posed problem.
Regards
Marshall Eubanks
T.M. Eubanks
Multicast Technologies, Inc
10301 Democracy Lane, Suite 410
Fairfax, Virginia 22030
Phone : 703-293-9624
Fax : 703-293-9609
e-mail : tme@on-the-i.com tme@multicasttech.com
http://www.on-the-i.com http://www.buzzwaves.com
>From owner-rmt@listserv.lbl.gov Wed Apr 4 11:02:24 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.9.3) id f34HxNu10429;
Wed, 4 Apr 2001 10:59:23 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f34HxMc10425
for <rmt@listserv.lbl.gov>; Wed, 4 Apr 2001 10:59:22 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.9.3) with ESMTP id f34HxHe14915
for <rmt@listserv.lbl.gov>; Wed, 4 Apr 2001 10:59:17 -0700 (PDT)
Received: from ra.ecse.rpi.edu (ra.ecse.rpi.edu [128.113.61.205])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f34HxF114899
for <rmt@lbl.gov>; Wed, 4 Apr 2001 10:59:15 -0700 (PDT)
Received: from localhost (shivkuma@localhost)
by ra.ecse.rpi.edu (8.9.2/8.9.2) with SMTP id NAA16388;
Wed, 4 Apr 2001 13:57:49 -0400 (EDT)
Date: Wed, 4 Apr 2001 13:57:48 -0400 (EDT)
From: Shivkumar Kalyanaraman <shivkuma@ecse.rpi.edu>
To: Marshall Eubanks <tme@21rst-century.com>
cc: Jeremiah Scholl <jeremiah@cdt.luth.se>, rmt@lbl.gov,
Peter Parnes <peppar@cdt.luth.se>
Subject: Re: tcp-friendliness
In-Reply-To: <3AC8D314.9281DAB4@21rst-century.com>
Message-ID: <Pine.SV4.3.96.1010404135339.15963I-100000@ra.ecse.rpi.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-rmt@lbl.gov
Precedence: bulk
In a recent work, we decouple the measurement and use of loss rate and
RTT. This allows simple source-based implementation assuming
loss-indications are the only thing fed back... It does not seem to be too
bad as it would seem... No drop-to-zero, no beat down of competing TCP
flows+reasonably equivalent rate sharing...
http://www.ecse.rpi.edu/Homepages/shivkuma/research/papers-rpi.html#mult
-Shiv
===
Shivkumar Kalyanaraman
Asst. Professor, Dept of ECSE, Rensselaer Polytechnic Institute (RPI)
110, 8th Street, Room JEC 6003, Troy NY 12180-3590
Ph: 518 276 8979 Fax: 518 276 2433
WWW: http://www.ecse.rpi.edu/Homepages/shivkuma
A goal is a dream with a deadline -C. Knight
>From owner-rmt@listserv.lbl.gov Wed Apr 4 11:44:39 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.9.3) id f34IiVq10560;
Wed, 4 Apr 2001 11:44:31 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f34IiUc10556
for <rmt@listserv.lbl.gov>; Wed, 4 Apr 2001 11:44:30 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.9.3) with ESMTP id f34IiTe01742
for <rmt@listserv.lbl.gov>; Wed, 4 Apr 2001 11:44:29 -0700 (PDT)
Received: from multicasttech.com (IDENT:root@garcia.multicasttech.com [63.105.122.8])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f34IiS101730
for <rmt@lbl.gov>; Wed, 4 Apr 2001 11:44:28 -0700 (PDT)
Received: from [63.105.122.193] (HELO 21rst-century.com)
by multicasttech.com (CommuniGate Pro SMTP 3.3.2)
with ESMTP id 841609; Wed, 04 Apr 2001 14:42:09 -0400
Message-ID: <3ACB6B8A.FB3390D6@21rst-century.com>
Date: Wed, 04 Apr 2001 14:44:19 -0400
From: Marshall Eubanks <tme@21rst-century.com>
Reply-To: tme@21rst-century.com
Organization: Multicast Technologies
X-Mailer: Mozilla 4.7C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; I; PPC)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: Shivkumar Kalyanaraman <shivkuma@ecse.rpi.edu>
CC: Jeremiah Scholl <jeremiah@cdt.luth.se>, rmt@lbl.gov,
Peter Parnes <peppar@cdt.luth.se>
Subject: Re: tcp-friendliness
References: <Pine.SV4.3.96.1010404135339.15963I-100000@ra.ecse.rpi.edu>
Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353"
Content-Transfer-Encoding: 7bit
Sender: owner-rmt@lbl.gov
Precedence: bulk
Shivkumar Kalyanaraman wrote:
> In a recent work, we decouple the measurement and use of loss rate and
> RTT. This allows simple source-based implementation assuming
> loss-indications are the only thing fed back... It does not seem to be too
> bad as it would seem... No drop-to-zero, no beat down of competing TCP
> flows+reasonably equivalent rate sharing...
>
> http://www.ecse.rpi.edu/Homepages/shivkuma/research/papers-rpi.html#mult
>
> -Shiv
> ===
> Shivkumar Kalyanaraman
> Asst. Professor, Dept of ECSE, Rensselaer Polytechnic Institute (RPI)
> 110, 8th Street, Room JEC 6003, Troy NY 12180-3590
> Ph: 518 276 8979 Fax: 518 276 2433
> WWW: http://www.ecse.rpi.edu/Homepages/shivkuma
>
> A goal is a dream with a deadline -C. Knight
Thanks ! I'll read these papers. Have you tried the same thing for receiver based CC ?
BTW, is RPI multicast enabled ?
--
Regards
Marshall Eubanks
T.M. Eubanks
Multicast Technologies, Inc
10301 Democracy Lane, Suite 410
Fairfax, Virginia 22030
Phone : 703-293-9624
Fax : 703-293-9609
e-mail : tme@multicasttech.com
http://www.on-the-i.com
Test your network for multicast : http://www.multicasttech.com/mt/
>From owner-rmt@listserv.lbl.gov Thu Apr 5 03:43:35 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.9.3) id f35AfkH11852;
Thu, 5 Apr 2001 03:41:46 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f35Afic11848
for <rmt@listserv.lbl.gov>; Thu, 5 Apr 2001 03:41:44 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.9.3) with ESMTP id f35AfiY03253
for <rmt@listserv.lbl.gov>; Thu, 5 Apr 2001 03:41:44 -0700 (PDT)
Received: from plmta00.chello.pl (plmta00.chello.pl [213.46.248.62])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f35Afh103250
for <rmt@lbl.gov>; Thu, 5 Apr 2001 03:41:43 -0700 (PDT)
Message-Id: <200104051041.f35Afh103250@SpamWall.lbl.gov>
Received: from hetnet.nl ([213.93.48.181]) by plmta00.chello.pl
(Post.Office MTA v3.5.3 release 223 ID# 0-0U10L2S100V35)
with SMTP id pl for <rmt@lbl.gov>; Thu, 5 Apr 2001 08:03:12 -0100
From: "Rita de Groot" <R.deGroot@hetnet.nl>
To: <rmt@lbl.gov>
Subject: huidziekte
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Date: Thu, 5 Apr 2001 11:00:43 +0200
Content-Transfer-Encoding: 8bit
Sender: owner-rmt@lbl.gov
Precedence: bulk
Vijf jaar voordat deze foto's werden genomen werd bij mij diagnose
reumatische artritis gesteld en als zodanig ook behandeld. Niets hielp.
Toen de ziekte zich zo manifesteerde zoals u hieronder kunt zien..........
http://www.naardedokter.com/testimonials/sys_lup_eryth.htm
>From owner-rmt@listserv.lbl.gov Fri Apr 6 01:42:13 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.9.3) id f368eOo15005;
Fri, 6 Apr 2001 01:40:24 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f368eMc15001
for <rmt@listserv.lbl.gov>; Fri, 6 Apr 2001 01:40:22 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.9.3) with ESMTP id f368eIe20701
for <rmt@listserv.lbl.gov>; Fri, 6 Apr 2001 01:40:18 -0700 (PDT)
Received: from sm.luth.se (ny.sm.luth.se [130.240.3.1])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f368eG120692
for <rmt@lbl.gov>; Fri, 6 Apr 2001 01:40:17 -0700 (PDT)
Received: from delta1.sm.luth.se (delta1.sm.luth.se [130.240.3.7])
by sm.luth.se (8.10.0/8.10.0) with ESMTP id f368eHu01599;
Fri, 6 Apr 2001 10:40:17 +0200 (MET DST)
Date: Fri, 6 Apr 2001 10:40:04 +0200 (MET DST)
From: Jeremiah Scholl <jeremiah@cdt.luth.se>
To: Marshall Eubanks <tme@21rst-century.com>
cc: Jeremiah Scholl <jeremiah@cdt.luth.se>, rmt@lbl.gov,
Peter Parnes <peppar@cdt.luth.se>
Subject: Re: tcp-friendliness
In-Reply-To: <3AC8D314.9281DAB4@21rst-century.com>
Message-ID: <Pine.GSO.4.21.0104061015420.21435-100000@delta1.sm.luth.se>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-rmt@lbl.gov
Precedence: bulk
All the responses I received have clarified the meaning of the
statement in the context of the PGMCC article. However, I am still
curious if there is a standard way to define TCP-friendliness in a
multicast setting. The way I see it there are two possible ways to define
TCP-friendliness for a multicast flow over its liftime.
1)The flow rate if the scheme was adjusted to the TCP-rate of
the worst-case receiver at all times.
2)The flow rate if the scheme was adjusted to the worst-case flow over the
lifetime of the transfer.
Here is a simple example of how these two definitions could give you
different acceptable rates.
Suppose we multicast to two receivers for a period of 1 minute,
receiver X and and receiver Y. For the first 30 seconds receiver X is
in a congested state a has a "TCP-friendly" bandwidth of 5 kb/s. Receiver
Y on the other hand is not congested and can receive 100 kb/s. Half
way through the life of our transfer the situation for the two receivers
is switched and for the final 30 seconds reciever X can recieve 100
kb/s and receiver Y can receive 5 kb/s.
Using definition 1 for TCP-friendliness our acceptable send rate would be
5 kb/s for the first half of the transfer and 5 kb/s for the second half
of the transfer. So, we would be able to transfer:
5 kb/s * 60 s = 300 kb of data and still be TCP friendly.
However, if we use definition 2 for TCP-friendiness from above then our
acceptable send rate would be the TCP-friendly rate for either flow
throughout the entire minute (since in this case there is not a
worst-case flow). So, we would be able to transfer:
(100 kb/s + 5 kb/s)/2 = 52.5 kb/s for 60 seconds which gives us
3150 kb of data and still be TCP friendly.
So, I suppose what I am wondering is if there is in fact a generaly
accepted definition for TCP-friendliness for a multicast flow. If so,
what is it.
Thanks!
Jeremiah
On Mon, 2 Apr 2001, Marshall Eubanks wrote:
> Jeremiah Scholl wrote:
>
> > Can anyone tell me if there is any generaly accepted definition for
> > TCP-friendliness regarding reliable multicast. The reason I am asking is
> > that the PGMCC paper (the version that was presented at SIGCOMM) has the
> > following statement near the end of section 4.4
> >
> > "in the presence of multiple receivers, there is no clear definition of a
> > TCP-fair rate."
> >
> > Can anyone help clarify this for me? Does the IETF have any plans to
> > standardize the definitions of TCP-fair or TCP-friendly with regards to
> > reliable multicast?
> >
> > Thanks!
> >
> > Jeremiah
>
> My personal, and unpopular, opinion is that this is not a well-posed problem.
>
>
> Regards
> Marshall Eubanks
>
>
> T.M. Eubanks
> Multicast Technologies, Inc
> 10301 Democracy Lane, Suite 410
> Fairfax, Virginia 22030
> Phone : 703-293-9624
> Fax : 703-293-9609
> e-mail : tme@on-the-i.com tme@multicasttech.com
>
> http://www.on-the-i.com http://www.buzzwaves.com
>
>
>
>From owner-rmt@listserv.lbl.gov Fri Apr 6 03:55:25 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.9.3) id f36AskB15146;
Fri, 6 Apr 2001 03:54:46 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f36Asic15142
for <rmt@listserv.lbl.gov>; Fri, 6 Apr 2001 03:54:44 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.9.3) with ESMTP id f36AsiJ13398
for <rmt@listserv.lbl.gov>; Fri, 6 Apr 2001 03:54:44 -0700 (PDT)
Received: from cs.rpi.edu (mumble.cs.rpi.edu [128.213.8.16])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f36Ash113394
for <rmt@lbl.gov>; Fri, 6 Apr 2001 03:54:43 -0700 (PDT)
Received: from coffeepot.cs.rpi.edu (thaps@coffeepot.cs.rpi.edu [128.213.8.30])
by cs.rpi.edu (8.9.3/8.9.3) with SMTP id GAA39066;
Fri, 6 Apr 2001 06:53:40 -0400 (EDT)
Date: Fri, 6 Apr 2001 06:53:39 -0400 (EDT)
From: Puneet Thapliyal <thaps@cs.rpi.edu>
Reply-To: Puneet Thapliyal <thaps@cs.rpi.edu>
To: Jeremiah Scholl <jeremiah@cdt.luth.se>
cc: Marshall Eubanks <tme@21rst-century.com>, rmt@lbl.gov,
Peter Parnes <peppar@cdt.luth.se>
Subject: Re: tcp-friendliness
In-Reply-To: <Pine.GSO.4.21.0104061015420.21435-100000@delta1.sm.luth.se>
Message-ID: <Pine.GSO.3.95.1010406064555.2696A-100000@coffeepot.cs.rpi.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-rmt@lbl.gov
Precedence: bulk
On Fri, 6 Apr 2001, Jeremiah Scholl wrote:
> However, if we use definition 2 for TCP-friendiness from above then our
> acceptable send rate would be the TCP-friendly rate for either flow
> throughout the entire minute (since in this case there is not a
> worst-case flow). So, we would be able to transfer:
>
> (100 kb/s + 5 kb/s)/2 = 52.5 kb/s for 60 seconds which gives us
>
> 3150 kb of data and still be TCP friendly.
If the source rate is maintained at 100kbps with the "worst" receiver in
the receiver set having a b/w of 5kbps, it would be doing no good for
congestion control.
Cheers,
Puneet Thapliyal
----------------------
Networks Research Lab,
RPI.
----------------------
>From owner-rmt@listserv.lbl.gov Fri Apr 6 04:27:08 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.9.3) id f36BQpd15172;
Fri, 6 Apr 2001 04:26:51 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f36BQmc15168
for <rmt@listserv.lbl.gov>; Fri, 6 Apr 2001 04:26:49 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.9.3) with ESMTP id f36BQmE18578
for <rmt@listserv.lbl.gov>; Fri, 6 Apr 2001 04:26:48 -0700 (PDT)
Received: from nmh.informatik.uni-bremen.de (root@nmh.informatik.uni-bremen.de [134.102.224.3])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f36BQk118572
for <rmt@lbl.gov>; Fri, 6 Apr 2001 04:26:47 -0700 (PDT)
Received: from cabo3 (root@nmh.informatik.uni-bremen.de [134.102.224.3])
by nmh.informatik.uni-bremen.de (8.10.1/8.10.1) with SMTP id f36BQQG15620;
Fri, 6 Apr 2001 13:26:26 +0200 (MEST)
From: "Dr. Carsten Bormann" <cabo@tzi.org>
To: "Jeremiah Scholl" <jeremiah@cdt.luth.se>,
"Marshall Eubanks" <tme@21rst-century.com>
Cc: <rmt@lbl.gov>, "Peter Parnes" <peppar@cdt.luth.se>
Subject: RE: tcp-friendliness
Date: Fri, 6 Apr 2001 13:26:27 +0200
Message-ID: <NEBBJFHFCKHKFCNLJJBPGECIFAAA.cabo@tzi.org>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <Pine.GSO.4.21.0104061015420.21435-100000@delta1.sm.luth.se>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Importance: Normal
Sender: owner-rmt@lbl.gov
Precedence: bulk
Jeremiah,
the definition of multicast TCP-friendliness definitely is certainly
governed by that famous Douglas Adams quote -- once somebody figures it out,
the universe is replaced by something even more bizarre and unexplicable.
The main problem with any new specific hard definition is that somebody will
immediately come up with
1) a protocol that is clearly TCP-friendly in all aspects but does not fit
the definition,
2) another protocol that manages to comply to the definition while not being
TCP-friendly at all.
On the other hand, the whole thing is really simple:
The whole point of the TCP-friendliness discussion is not to do damage.
In particular, you should not encourage destructive behavior:
If a multicast stream gets better bandwidth than a unicast stream, people
will move unicast traffic to multicast, even if there is only one receiver.
(If a multicast stream does not get better bandwidth than the corresponding
set of unicast streams, you remove a major incentive to move to multicast.)
In your example 2, assuming the bottleneck is a low-statmux link, clearly
you are damaging traffic on the links that are being severely overloaded.
This is not TCP-friendly by any stretch of the imagination.
The situation is slightly more murky on high-statmux links.
There is an argument that one multicast stream is better than the equivalent
multiple unicast streams, so you are entitled to a higher share of the
high-statmux link.
If that is granted, you might be allowed to push back TCP traffic more than
a single TCP stream would, but not more than the equivalent collection of
unicast streams would (note that, until we get infinite-bandwidth links,
this is quite different from saying "n times the throughout of a single
unicast stream").
Unfortunately, this borders on discussions of ISP business models, so there
is no *technical* argument that can bring this discussion to a conclusion.
Also, of course, the endpoints have a hard time finding out whether the
losses they see are from low-statmux bottlenecks or not.
The restricted-worst-edge model championed by Brian Whetten is an example
that has been influenced by this kind of thinking.
Gruesse, Carsten
PS.: And we are cheating by treating Multicast Congestion Control as an L3
problem.
With today's L2 networks, you may be severely overloading L2 links although
all receivers are happy.
This is a real-world problem!
Also, there are failure modes where a receiver does get the multicast
packets but does not manage to return congestion information.
In a world full of middleboxes, this is becoming more prevalent every day.
>From owner-rmt@listserv.lbl.gov Fri Apr 6 04:58:47 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.9.3) id f36BwBj15190;
Fri, 6 Apr 2001 04:58:11 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f36Bw9c15186
for <rmt@listserv.lbl.gov>; Fri, 6 Apr 2001 04:58:09 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.9.3) with ESMTP id f36Bw9123907
for <rmt@listserv.lbl.gov>; Fri, 6 Apr 2001 04:58:09 -0700 (PDT)
Received: from pi4.informatik.uni-mannheim.de (root@pi4.informatik.uni-mannheim.de [134.155.48.96])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f36Bw7123896
for <rmt@lbl.gov>; Fri, 6 Apr 2001 04:58:07 -0700 (PDT)
Received: from informatik.uni-mannheim.de (IDENT:widmer@meton [134.155.48.2])
by pi4.informatik.uni-mannheim.de (8.9.3/8.9.3) with ESMTP id NAA08632;
Fri, 6 Apr 2001 13:57:51 +0200 (MET DST)
Message-ID: <3ACDAF3F.FF9A9D32@informatik.uni-mannheim.de>
Date: Fri, 06 Apr 2001 13:57:51 +0200
From: Joerg Widmer <widmer@informatik.uni-mannheim.de>
Organization: University of Mannheim
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.17-14 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Jeremiah Scholl <jeremiah@cdt.luth.se>
CC: Marshall Eubanks <tme@21rst-century.com>, rmt@lbl.gov,
Peter Parnes <peppar@cdt.luth.se>
Subject: Re: tcp-friendliness
References: <Pine.GSO.4.21.0104061015420.21435-100000@delta1.sm.luth.se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-rmt@lbl.gov
Precedence: bulk
Jeremiah Scholl wrote:
>
> All the responses I received have clarified the meaning of the
> statement in the context of the PGMCC article. However, I am still
> curious if there is a standard way to define TCP-friendliness in a
> multicast setting. The way I see it there are two possible ways to define
> TCP-friendliness for a multicast flow over its liftime.
>
> 1)The flow rate if the scheme was adjusted to the TCP-rate of
> the worst-case receiver at all times.
>
> 2)The flow rate if the scheme was adjusted to the worst-case flow over the
> lifetime of the transfer.
>
To me this seems to be directly related to the form of multicast
transmission. If it is a single-rate multicast distribution, only 1)
will ensure that competing TCP traffic is treated fairly, while
multi-rate multicast transmission can get away with an average rate of
2) and still be TCP-friendly. (So 1) is ok in either case.)
Joerg
--
Joerg Widmer
Praktische Informatik IV, University of Mannheim
L15,16, 68131 Mannheim, Germany
Tel: +49 621 181 2605, Fax: +49 621 181 2601
http://www.informatik.uni-mannheim.de/informatik/pi4/people/widmer.html
>From owner-rmt@listserv.lbl.gov Fri Apr 6 06:11:07 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.9.3) id f36DAh116022;
Fri, 6 Apr 2001 06:10:43 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f36DAgc16018
for <rmt@listserv.lbl.gov>; Fri, 6 Apr 2001 06:10:42 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.9.3) with ESMTP id f36DAfU08182
for <rmt@listserv.lbl.gov>; Fri, 6 Apr 2001 06:10:41 -0700 (PDT)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
by SpamWall.lbl.gov (8.11.2/8.11.2) with SMTP id f36DAe108177
for <rmt@lbl.gov>; Fri, 6 Apr 2001 06:10:40 -0700 (PDT)
Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP
id <g.21897-0@bells.cs.ucl.ac.uk>; Fri, 6 Apr 2001 14:10:22 +0100
To: Jeremiah Scholl <jeremiah@cdt.luth.se>
cc: Marshall Eubanks <tme@21rst-century.com>, rmt@lbl.gov,
Peter Parnes <peppar@cdt.luth.se>, J.Crowcroft@cs.ucl.ac.uk
Subject: Re: tcp-friendliness
In-reply-to: Your message of "Fri, 06 Apr 2001 10:40:04 +0200." <Pine.GSO.4.21.0104061015420.21435-100000@delta1.sm.luth.se>
Date: Fri, 06 Apr 2001 14:10:22 +0100
Message-ID: <8210.986562622@cs.ucl.ac.uk>
From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
Sender: owner-rmt@lbl.gov
Precedence: bulk
In message <Pine.GSO.4.21.0104061015420.21435-100000@delta1.sm.luth.se>, Jere
miah Scholl typed:
>>1)The flow rate if the scheme was adjusted to the TCP-rate of
>>the worst-case receiver at all times.
>>2)The flow rate if the scheme was adjusted to the worst-case flow over the
>>lifetime of the transfer.
the problem with "TCP friendliness" is that there are several levels
of "friendly" and usually peopel start to talk about fairness and
the whole area is bound up with a range of dilemmas ranging from
i) the specifics of implementation of a given TCP (and a given RMT)
and
ii) ideas of utility
and
iii) ideas of network efficiency (e.g. user v. provider optimality)
the definitons abouve are cute, but while 1/ is elegant its not
achievable - an instantaenous equivalent to the TCP rate of a
"worst-case" receiver (we.g. on a packet or single RTT timescale) is
not scalable, and usually ends up being covergent to zero rate
anyhow
2/ is subject to weird games peopel can play esp. aroudn the phase
shif at the diurnal (9am/5pm) times....
I would prefer we move to some sort of symptomatic (measurable.verifiable)
definiton of TCP co-existence behaviour and do it o na case by case
basis - e.g. define the timescales over which an RMT adapts to a
set of TCPs that share a set of bottlnecks define the goal seeking
model it uses and the asymptotic behaviour maybe only a some sort of
last resrt....
the reason i would say thuis is that i beleive the jury is STILL OUT
on what users and providers actually WANT in terms of utility (and
relative utility of an RMT and a TCP) so we dont want to define any
single operating regime, but rather, just set some broad rules (e.g.
Asimov's 3 laws of Robotic multicast:
i) an RMT mustnt drive TCP to zero on any given bottleneck, over any
reasonable (RTT raealted?, or TCP lifetimes) timescale
ii) an RMT or let itself be driven to zero by any reasonable mix with TCP
over any comparable timescale (e.g. to TCP flow lifes)
iii) the feedback or other contrl traffic (igmp for multirate)
for an RMT will always be bounded to some reasonable fraction of the
actual data traffic
for example..
cheers
jon
>From owner-rmt@listserv.lbl.gov Fri Apr 6 06:42:44 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.9.3) id f36DgMx16176;
Fri, 6 Apr 2001 06:42:22 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f36DgKc16172
for <rmt@listserv.lbl.gov>; Fri, 6 Apr 2001 06:42:21 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.9.3) with ESMTP id f36DgKA14622
for <rmt@listserv.lbl.gov>; Fri, 6 Apr 2001 06:42:20 -0700 (PDT)
Received: from multicasttech.com (IDENT:root@garcia.multicasttech.com [63.105.122.8])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f36DgJ114618
for <rmt@lbl.gov>; Fri, 6 Apr 2001 06:42:19 -0700 (PDT)
Received: from [63.105.122.193] (HELO 21rst-century.com)
by multicasttech.com (CommuniGate Pro SMTP 3.3.2)
with ESMTP id 842419; Fri, 06 Apr 2001 09:39:45 -0400
Message-ID: <3ACDC7B5.4FE1E56@21rst-century.com>
Date: Fri, 06 Apr 2001 09:42:12 -0400
From: Marshall Eubanks <tme@21rst-century.com>
Reply-To: tme@21rst-century.com
Organization: Multicast Technologies
X-Mailer: Mozilla 4.7C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; I; PPC)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
CC: Jeremiah Scholl <jeremiah@cdt.luth.se>, rmt@lbl.gov,
Peter Parnes <peppar@cdt.luth.se>
Subject: Re: tcp-friendliness
References: <8210.986562622@cs.ucl.ac.uk>
Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353"
Content-Transfer-Encoding: 7bit
Sender: owner-rmt@lbl.gov
Precedence: bulk
Jon Crowcroft wrote:
> In message <Pine.GSO.4.21.0104061015420.21435-100000@delta1.sm.luth.se>, Jere
> miah Scholl typed:
>
> >>1)The flow rate if the scheme was adjusted to the TCP-rate of
> >>the worst-case receiver at all times.
>
> >>2)The flow rate if the scheme was adjusted to the worst-case flow over the
> >>lifetime of the transfer.
>
> the problem with "TCP friendliness" is that there are several levels
> of "friendly" and usually peopel start to talk about fairness and
> the whole area is bound up with a range of dilemmas ranging from
> i) the specifics of implementation of a given TCP (and a given RMT)
> and
> ii) ideas of utility
> and
> iii) ideas of network efficiency (e.g. user v. provider optimality)
>
> the definitons abouve are cute, but while 1/ is elegant its not
> achievable - an instantaenous equivalent to the TCP rate of a
> "worst-case" receiver (we.g. on a packet or single RTT timescale) is
> not scalable, and usually ends up being covergent to zero rate
> anyhow
>
> 2/ is subject to weird games peopel can play esp. aroudn the phase
> shif at the diurnal (9am/5pm) times....
>
> I would prefer we move to some sort of symptomatic (measurable.verifiable)
> definiton of TCP co-existence behaviour and do it o na case by case
> basis - e.g. define the timescales over which an RMT adapts to a
> set of TCPs that share a set of bottlnecks define the goal seeking
> model it uses and the asymptotic behaviour maybe only a some sort of
> last resrt....
>
> the reason i would say thuis is that i beleive the jury is STILL OUT
> on what users and providers actually WANT in terms of utility (and
> relative utility of an RMT and a TCP) so we dont want to define any
> single operating regime, but rather, just set some broad rules (e.g.
> Asimov's 3 laws of Robotic multicast:
>
> i) an RMT mustnt drive TCP to zero on any given bottleneck, over any
> reasonable (RTT raealted?, or TCP lifetimes) timescale
> ii) an RMT or let itself be driven to zero by any reasonable mix with TCP
> over any comparable timescale (e.g. to TCP flow lifes)
Jon;
ii) seems to be garbled - did you mean to say
an RMT must NOT let itself be driven to zero... ?
Or something else ?
If that's what you meant, I think that these 3 guidelines are
a good starting point.
Marshall
>
> iii) the feedback or other contrl traffic (igmp for multirate)
> for an RMT will always be bounded to some reasonable fraction of the
> actual data traffic
>
> for example..
>
> cheers
> jon
T.M. Eubanks
Multicast Technologies, Inc
10301 Democracy Lane, Suite 410
Fairfax, Virginia 22030
Phone : 703-293-9624
Fax : 703-293-9609
e-mail : tme@multicasttech.com
http://www.on-the-i.com
Test your network for multicast : http://www.multicasttech.com/mt/
>From owner-rmt@listserv.lbl.gov Fri Apr 6 08:39:42 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.9.3) id f36FdCE16503;
Fri, 6 Apr 2001 08:39:12 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f36FdAc16499
for <rmt@listserv.lbl.gov>; Fri, 6 Apr 2001 08:39:11 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.9.3) with ESMTP id f36FdAl19148
for <rmt@listserv.lbl.gov>; Fri, 6 Apr 2001 08:39:10 -0700 (PDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f36FdA119145
for <rmt@lbl.gov>; Fri, 6 Apr 2001 08:39:10 -0700 (PDT)
Received: from bcn.East.Sun.COM ([129.148.75.4])
by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA26802;
Fri, 6 Apr 2001 08:39:07 -0700 (PDT)
Received: from bridge (bridge [129.148.75.125])
by bcn.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id LAA14153;
Fri, 6 Apr 2001 11:39:05 -0400 (EDT)
Message-Id: <200104061539.LAA14153@bcn.East.Sun.COM>
Date: Fri, 6 Apr 2001 11:39:02 -0400 (EDT)
From: Dah Ming Chiu - Sun Microsystems <Dahming.Chiu@sun.com>
Reply-To: Dah Ming Chiu - Sun Microsystems <Dahming.Chiu@sun.com>
Subject: Re: tcp-friendliness
To: jeremiah@cdt.luth.se
Cc: rmt@lbl.gov
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: 5EOvOf2VjYB+gacvTCKJjg==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc
Sender: owner-rmt@lbl.gov
Precedence: bulk
We had a lot of discussion on this topic (in the RMRG) a couple of
years ago. I think there was a lot of support of using your first
definition as a guideline. Of course in reality, "at all times"
is subject to interpretation. There is also limits as to how fast
each flow can react to congestion, and thus how strict fairness
can be maintained dynamically.
I agree with Jon Crowcroft's last email. Requiring RMT to be TCP
friendly is dictating certain way of allocating network resources
between unicast and multicast traffic. This is a rather complex
issue. In the long run, the correct solution may very well be
governed by the economics/pricing models of the Internet, rather
than purely by the transport mechanisms. In the mean time, we
should concentrate on the effectiveness of controlling/avoiding
congestion, and be more liberal with how we mandate fairness.
In thinking about these issues, we have written a couple of papers
you might find useful:
1) "Some observations on Fairness of Bandwidth Sharing"
http://research.sun.com/techrep/1999/abstract-80.html
We discuss the meaning of different fairness criteria, and some
issues when applying them to multicast
2) "Pruning Algorithms for Multicast Flow Control"
http://www.cs.ucsb.edu/ngc2000/program/117.ps
This paper deal with the case when you have n receivers who can
receive at 100KB/s and one at 5KB/s, how you might want to "prune"
the slow receiver. It also discusses the TCP-friendliness issue
with doing that.
Regards
Dah Ming Chiu
Sun Labs
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to
owner-rmt@listserv.lbl.gov using -f
From: Jeremiah Scholl <jeremiah@cdt.luth.se>
To: Marshall Eubanks <tme@21rst-century.com>
cc: Jeremiah Scholl <jeremiah@cdt.luth.se>, rmt@lbl.gov, Peter Parnes
<peppar@cdt.luth.se>
Subject: Re: tcp-friendliness
MIME-Version: 1.0
All the responses I received have clarified the meaning of the
statement in the context of the PGMCC article. However, I am still
curious if there is a standard way to define TCP-friendliness in a
multicast setting. The way I see it there are two possible ways to
define
TCP-friendliness for a multicast flow over its liftime.
1)The flow rate if the scheme was adjusted to the TCP-rate of
the worst-case receiver at all times.
2)The flow rate if the scheme was adjusted to the worst-case flow over
the
lifetime of the transfer.
Here is a simple example of how these two definitions could give you
different acceptable rates.
Suppose we multicast to two receivers for a period of 1 minute,
receiver X and and receiver Y. For the first 30 seconds receiver X is
in a congested state a has a "TCP-friendly" bandwidth of 5 kb/s.
Receiver
Y on the other hand is not congested and can receive 100 kb/s. Half
way through the life of our transfer the situation for the two receivers
is switched and for the final 30 seconds reciever X can recieve 100
kb/s and receiver Y can receive 5 kb/s.
Using definition 1 for TCP-friendliness our acceptable send rate would
be
5 kb/s for the first half of the transfer and 5 kb/s for the second half
of the transfer. So, we would be able to transfer:
5 kb/s * 60 s = 300 kb of data and still be TCP friendly.
However, if we use definition 2 for TCP-friendiness from above then our
acceptable send rate would be the TCP-friendly rate for either flow
throughout the entire minute (since in this case there is not a
worst-case flow). So, we would be able to transfer:
(100 kb/s + 5 kb/s)/2 = 52.5 kb/s for 60 seconds which gives us
3150 kb of data and still be TCP friendly.
So, I suppose what I am wondering is if there is in fact a generaly
accepted definition for TCP-friendliness for a multicast flow. If so,
what is it.
Thanks!
Jeremiah
On Mon, 2 Apr 2001, Marshall Eubanks wrote:
> Jeremiah Scholl wrote:
>
> > Can anyone tell me if there is any generaly accepted definition for
> > TCP-friendliness regarding reliable multicast. The reason I am
asking is
> > that the PGMCC paper (the version that was presented at SIGCOMM) has
the
> > following statement near the end of section 4.4
> >
> > "in the presence of multiple receivers, there is no clear definition
of a
> > TCP-fair rate."
> >
> > Can anyone help clarify this for me? Does the IETF have any plans
to
> > standardize the definitions of TCP-fair or TCP-friendly with regards
to
> > reliable multicast?
> >
> > Thanks!
> >
> > Jeremiah
>
> My personal, and unpopular, opinion is that this is not a well-posed
problem.
>
>
> Regards
> Marshall Eubanks
>
>
> T.M. Eubanks
> Multicast Technologies, Inc
> 10301 Democracy Lane, Suite 410
> Fairfax, Virginia 22030
> Phone : 703-293-9624
> Fax : 703-293-9609
> e-mail : tme@on-the-i.com tme@multicasttech.com
>
> http://www.on-the-i.com http://www.buzzwaves.com
>
>
>
>From owner-rmt@listserv.lbl.gov Mon Apr 9 03:52:52 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.9.3) id f39AoSa22654;
Mon, 9 Apr 2001 03:50:28 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f39AoQc22650
for <rmt@listserv.lbl.gov>; Mon, 9 Apr 2001 03:50:26 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.9.3) with ESMTP id f39AoOp12788
for <rmt@listserv.lbl.gov>; Mon, 9 Apr 2001 03:50:24 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f39AoJ112708
for <rmt@lbl.gov>; Mon, 9 Apr 2001 03:50:21 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02566;
Mon, 9 Apr 2001 06:50:18 -0400 (EDT)
Message-Id: <200104091050.GAA02566@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: rmt@lbl.gov
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-rmt-pi-track-security-01.txt
Date: Mon, 09 Apr 2001 06:50:18 -0400
Sender: owner-rmt@lbl.gov
Precedence: bulk
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Reliable Multicast Transport Working Group of the IETF.
Title : Security Requirements For TRACK
Author(s) : T. Hardjono, B. Whetten
Filename : draft-ietf-rmt-pi-track-security-01.txt
Pages :
Date : 06-Apr-01
This document discusses the security issues within the TRee-based
ACKnowledgement (TRACK) reliable multicast protocol instantiation, and
identifies some constraints and requirements for security provisions for
this protocol. Based on the constraints and requirements, the document
proposes a separation of data packet confidentiality and authentication,
from transport layer protection. It proposes that TRACK be primarily
concerned with group authentication of control and data packets, to
protect against attacks on the transport infrastructure. It proposes
that data confidentiality and source authentication be provided
separately from this low level group authentication, ideally at the
application level. We show that this is particularly important for
TRACK, because of the requirement that the interior control nodes only
OPTIONALLY have access to the data packet payload.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rmt-pi-track-security-01.txt
Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-rmt-pi-track-security-01.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.
Send a message to:
mailserv@ietf.org.
In the body type:
"FILE /internet-drafts/draft-ietf-rmt-pi-track-security-01.txt".
NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv@ietf.org"
Content-Type: text/plain
Content-ID: <20010406125122.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-rmt-pi-track-security-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-rmt-pi-track-security-01.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <20010406125122.I-D@ietf.org>
--OtherAccess--
--NextPart--
>From owner-rmt@listserv.lbl.gov Sat Apr 14 08:05:33 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f3EEvXu14497;
Sat, 14 Apr 2001 07:57:33 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f3EEvVg14493
for <rmt@listserv.lbl.gov>; Sat, 14 Apr 2001 07:57:32 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f3EEvUU21791
for <rmt@listserv.lbl.gov>; Sat, 14 Apr 2001 07:57:31 -0700 (PDT)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
by SpamWall.lbl.gov (8.11.2/8.11.2) with SMTP id f3EEvTL21786
for <rmt@lbl.gov>; Sat, 14 Apr 2001 07:57:29 -0700 (PDT)
Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP
id <g.08022-0@bells.cs.ucl.ac.uk>; Sat, 14 Apr 2001 15:57:25 +0100
To: rmt@lbl.gov, rm@mash.cs.berkeley.edu
cc: Cost264.official@lip6.fr
cc: mbone@ISI.EDU
cfp: "rem-conf@es.net" <rem-conf@es.net>, jon
Subject: NGC2001 CfP - call for papers, networked group communications workshop
Date: Sat, 14 Apr 2001 15:57:24 +0100
Message-ID: <1851.987260244@cs.ucl.ac.uk>
From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
Sender: owner-rmt@lbl.gov
Precedence: bulk
apols for x-posting, but i think this is relevant and of interest to
many on these lists and we dont have a tool to remove duplicates at
send time:-(
C A L L F O R P A P E R S
The 3rd International Workshop on
Networked Group Communication (NGC 2001)
November 7-9, 2001
UCL
London, England
Organized by UCL and COST 264
in cooperation with ACM Sigcomm
---------------------------------
Scope of the Conference
-----------------------
The aim of the Workshop is to allow researchers and practioners to
present the design and implementation techniques for networked group
communication, as well as performance analysis and evaluation of such
mechanisms. The focus of the Workshop is on multicast and networked group
communication, right up to session and application level control
mechanisms and services. This Workshop is the third and only
international event in this area (first workshop was in Pisa, Italy,
in November 1999; the second was at Stanford, USA, in November 2000).
The workshop will start with half day tutorials on the 7th. The
technical program will include two keynotes and invited talks on the
8th and the 9th of November 2001. There may also be a panel discussion
as well as a poster session.
Authors are invited to submit papers on any issue related to
networked group communication, including:
application layer multicast and content distribution
multipeer applications (distributed interactive applications, games, DIS)
applications and services enabled through multicast
use of group communication mechanisms to support control plane tasks
scalability: overheads, stability, analysis, experiments
economic models
novel group communication architectures
routing, naming, address allocation
group and session management techniques
QoS and network engineering
reliable and semi-reliable protocols
wireless and mobile multicast
security
adaption and congestion control for group communication
heterogeneous group communication
deployment related issues
The Proceedings of the Workshop will be published by ACM and papers will
be available on-line prior to the workshop.
Paper Submission Guidelines
---------------------------
Papers must be less than 20 double-spaced pages long, have an abstract
of 100-150 words, and be original material that has not been previously
published nor is currently under review by another conference or journal.
Authors must submit papers electronically, using the instructions at
http://www.cs.ucl.ac.uk/research/ngc2001/
Important Dates
---------------
Paper Submission: June 4, 2001
Author Notification: August 10, 2001
Camera Ready: September 10, 2001
-----------------------------------------------
For more information, visit the workshop WWW page at:
http://www.cs.ucl.ac.uk/research/ngc2001/
>From owner-rmt@listserv.lbl.gov Sun Apr 15 19:01:27 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f3G1vrG16589;
Sun, 15 Apr 2001 18:57:53 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f3G1vpg16585
for <rmt@listserv.lbl.gov>; Sun, 15 Apr 2001 18:57:51 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f3G1vpY12702
for <rmt@listserv.lbl.gov>; Sun, 15 Apr 2001 18:57:51 -0700 (PDT)
Received: from kegparty.com (cm20816625250.coralsprings.ispchannel.com [208.166.25.250])
by SpamWall.lbl.gov (8.11.2/8.11.2) with SMTP id f3G1vfL12638;
Sun, 15 Apr 2001 18:57:42 -0700 (PDT)
Subject: Biz To Business Database Disc
X-Mailer: ALPHA_XMR75_00001SLBL
To: mydeez@kukamail.com
Message-Id: <3pr6am61yw6p15.80uw4d7gqk3u@kegparty.com>
Reply-To: terrywhite@acmemail.net
Content-Type: text/plain;
charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Sun, 15 Apr 2001 22:02:10 -0500
From: billyp@grabmail.com
Sender: owner-rmt@lbl.gov
Precedence: bulk
As a dot.com professional you know that it is essential to your teams'
success to advertise your web site, business, product, service, or your
organizations' cause to the masses. You also know that your marketing and
advertising budget limits your options.
If you are a Fortune 500 corporation, you have the advantage of being able to
book 30 second TV spots during the SuperBowl. Most of us are not in that
position though. Besides, did you know that something on the order of 92% of
TV viewers run to the washroom at commercial breaks during the program,
thereby missing the expensive commercial spot.
Q: Of all the various advertising mediums which do you feel is most effective,
in cases when you require your prospect to remember your telephone number or
web address?
Let's outline and agree on a list of the main advertising and marketing
mediums first:
- Television Commercial
- Television Infomercial
- Internet Banner Ads (paid for on a click-through basis)
- Internet Banner Ads (paid for on an impression basis)
- So-Called opted-in email list rental and broadcast
- Radio Commercial
- Print Media (Newspapers, Magazines)
- Print Media (Hand-Outs)
- Trade Shows
- News or Media organization story or profile on your project
- Affiliate Links
- Signage
- Telemarketing
- Direct Mail
- Broadcast Fax (not personalized to its recipients)
- Broadcast Fax (personalized and to the Attention of its recipients)
- Targeted Broadcast Email (personalized or not)
Now consider the effectiveness of each advertising choice, remembering that
in many cases your audience must still remember a telephone number in order to
contact you.
Q: Which is the least costly and most effective?
E-mail marketing works! Why? There are many reasons, but primarily because
people are focused on their monitors while checking their e-mail. Totally
focused. In addition, they have a hard copy of your ad on their hard drive,
and it is simple for them to forward the ad to their friends and
associates as well.
You can tell your story with more words and target your list to particular
types of recipients or geographical areas. We offer some of the best delivery
and bulk e-mail prices on the Internet. Bulk e-mail can get you the best
exposure on the net. What makes this kind of advertising so effective is the
fact that you go to the potential customer. Not like search engines or print
ads that the potential customer has to do all the searching. Dollar for
dollar bulk e-mailing is also the most economical. We do all the mailing for
you. You just provide us with the ad! It's that simple!
What we offer is simple:
*General Lists or other ISPs
#100,000 Emails $495.00
#250,000 Emails $995.00
#500,000 Emails $1,495.00
#1,000,000 Emails $2,495.00
#2,500,000 Emails $4,995.00
#5,000,000+ Emails (Call for Quote)
WE ALSO HAVE LARGER PACKAGES!
*Targeted Lists (Starting @):
#100,000 Emails $995.00
#250,000 Emails $1,495.00
#500,000 Emails $2,995.00
#1,000,000 Emails (Call for Quote)
METHOD OF PAYMENT, CASHIERS CHECK MONEY ORDER OR BANK WIRE.
$$$GET AN ADDITIONAL FREE 25% ON TOP OF EVERY ORDER...
IF YOU ORDER WITHIN 5 DAYS OF RECIEVING THIS MESSAGE!
Call for bigger packages! ORDER NOW!!! AND GET THE RIGHT EXPOSURE!
For more details on Email Services, please call:
#954.340.1628 (US & International)
IF YOU ARE THE DO IT YOURSLF TYPE OR ARE STILL USING TRADITONAL MARKETING
TECHNICS, YOU MUST TAKE A LOOK AT THE 8 1/2 MILLION BUSINESS TO BUSINESS
DATABASE!!
Our 3.0 Version B2B Database Will Go Online and Sell For 2.5 to 25 Cents Per
Record in early July! (Extended Due to Delays From The 1st)
You can now access contact data for over 8.5 Million Records. All of them
have their own .com .org or .net domain name, making them serious prospects
for Internet business.
Our data base readily accessible on CD-Rom, list the Names, Contact
Information, Physical Address, Phone #, Fax #, SIC Industry Code, URL (Domain
Name), and Contact Email Address which you can use to efficiently target
companies worldwide.
Over 8.5 Million Physical Addresses let you target businesses by Country,
State, City, Province, Zip Code, Area Code or by using the SIC Industry Code.
The data comes in a Comma-Delimited ASCII format which makes it easy to
manipulate and Import/Export records to your Contact-Management, Spreadsheet,
analysis and Broadcasting Applications.
We^Òd be happy to give you rough counts for your industry target market. We
also build databases to order and carry more than a dozen other data bases
both Domestic and International ( B2B and B2C).
Please send me more info about:
[ ] Master Disc 2000 8.5 Million Records, Cost US$799.00
[ ] Online Updates & Download Access Cost US$199.00 (Annually)
[ ] Commercial Email Services & Products
Note: Not all records contain complete data, call for breakdowns.
For more details on Database, please call:
#954.340.1628 (US & International)
or fax form below to:
#954.753.2846
(Make Sure To Mention Reseller Id #1789 When Calling)
Company name: ___________________________________________
Web Site Url: ___________________________________________
Contact name: ___________________________________________
Email: __________________________________________________
Phone: __________________________________________________
Fax: ___________________________________________________
Street address: _________________________________________
City, Zip, State: _______________________________________
Country: ________________________________________________
Check the following that apply:
_____ Please Notify Me Of Online Web Site & Register Me For Access Using The
Information Above.
Also Please, Send Additional Information on:
_____ Online Adult & Gaming Owner/Operaters
_____ Online Adult Subscribers & Online Gamers Databases
_____ Online Billing/Credit Card Processing
_____ Emailing Services and Databases
_____ Search Engine Positioning
_____ International Contact Lists
_____ Buying / Selling Traffic
_____ Web Site Hosting Services
_____ Internet Bandwidth Services (T-1's Starting at $999.00)
_____ Other:_______________________________
##############################################################################
#############################################
THIS MESSAGE IS BEING SENT IN COMPLIANCE OF THE EMAIL BILL: SECTION 301. PER
SECTION, PARAGRAPH (a) (2) (c) of S. 1618.
To discontinue receipt of further notice at not cost and to be removed from
our database, please reply with the word "Remove" in subject. Or call us at
#954.340.1628 leave your email address for removal from the database and
future mailings.
Any attempts to disrupt the removal email address etc., will not allow us to
be able to retrieve and process the remove requests.
##############################################################################
#############################################
.0401601
>From owner-rmt@listserv.lbl.gov Tue Apr 24 14:08:56 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f3OL6i512277;
Tue, 24 Apr 2001 14:06:44 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f3OL6gg12273
for <rmt@listserv.lbl.gov>; Tue, 24 Apr 2001 14:06:42 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f3OL6f416216
for <rmt@listserv.lbl.gov>; Tue, 24 Apr 2001 14:06:41 -0700 (PDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f3OL6eL16205
for <rmt@lbl.gov>; Tue, 24 Apr 2001 14:06:40 -0700 (PDT)
Received: from eastmail1.East.Sun.COM ([129.148.1.240])
by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA16470;
Tue, 24 Apr 2001 14:06:38 -0700 (PDT)
Received: from maple.East.Sun.COM (maple.East.Sun.COM [129.148.75.29])
by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA13194;
Tue, 24 Apr 2001 17:06:36 -0400 (EDT)
Received: from maple (maple [129.148.75.29])
by maple.East.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id RAA14030;
Tue, 24 Apr 2001 17:06:34 -0400 (EDT)
Message-Id: <200104242106.RAA14030@maple.East.Sun.COM>
Date: Tue, 24 Apr 2001 17:06:34 -0400 (EDT)
From: Miriam Kadansky - SUN Microsystems <miriamk@maple.East.Sun.COM>
Reply-To: Miriam Kadansky - SUN Microsystems <miriamk@maple.East.Sun.COM>
Subject: Java Reliable Multicast website now available
To: rm@mash.CS.Berkeley.EDU, rmt@lbl.gov
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: LdUSWtU9g7zcrQDnx7931Q==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc
Sender: owner-rmt@lbl.gov
Precedence: bulk
We are very pleased to announce that the Java Reliable Multicast
Service is now downloadable from Sun Microsystems Laboratories.
Please visit the web site at
http://www.experimentalstuff.com/Technologies/JRMS/
And check out this article about JRMS at javaworld.com:
http://www.javaworld.com/javaworld/jw-04-2001/jw-0420-javadev.html
We will continue to work on standards for Reliable Multicast within
the IETF. Also, Sun is hosting a mailing list for JRMS users, and
we will participate as our other commitments allow. However, we
have no plans to make additional enhancements to JRMS.
Thank you for your support and encouragement over the years.
We hope the work we've done will be of value to you.
Dah Ming Chiu, Miriam Kadansky, and Joe Provino
[apologies for multiple copies]
>From owner-rmt@listserv.lbl.gov Fri Apr 27 09:46:12 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f3RGfgj13590;
Fri, 27 Apr 2001 09:41:42 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f3RGffg13586
for <rmt@listserv.lbl.gov>; Fri, 27 Apr 2001 09:41:41 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f3RGffP17671
for <rmt@listserv.lbl.gov>; Fri, 27 Apr 2001 09:41:41 -0700 (PDT)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
by SpamWall.lbl.gov (8.11.2/8.11.2) with SMTP id f3RGfaL17651
for <rmt@lbl.gov>; Fri, 27 Apr 2001 09:41:40 -0700 (PDT)
Received: from sporty.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP
id <g.10683-0@bells.cs.ucl.ac.uk>; Fri, 27 Apr 2001 17:41:20 +0100
to: rm@mash.cs.berkeley.edu, rmt@lbl.gov
Subject: couple of infocom papers really need everyones attention
Date: Fri, 27 Apr 2001 17:41:18 +0100
Message-ID: <3418.988389678@cs.ucl.ac.uk>
From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
Sender: owner-rmt@lbl.gov
Precedence: bulk
at
http://www.ieee-infocom.org/2001/
see tech. program, for
Fine-Grained Layered Multicast
John Byers (Boston University), Michael Luby (Digital
Fountain), Michael Mitzenmacher (Harvard University)
and
Impact of Network Delay Variation on Multicast Session Performance With
TCP-like Congestion Control
Augustin Chaintreau (Ecole Normale Superieure), Francois Baccelli (INRIA), Christophe Diot (Sprint)
cheers
jon
>From owner-rmt@listserv.lbl.gov Thu May 10 08:26:19 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f4AFMbk05597;
Thu, 10 May 2001 08:22:37 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f4AFMag05593
for <rmt@listserv.lbl.gov>; Thu, 10 May 2001 08:22:36 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f4AFMaG11633
for <rmt@listserv.lbl.gov>; Thu, 10 May 2001 08:22:36 -0700 (PDT)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
by SpamWall.lbl.gov (8.11.2/8.11.2) with SMTP id f4AFMZF11628
for <rmt@lbl.gov>; Thu, 10 May 2001 08:22:35 -0700 (PDT)
Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP
id <g.05311-0@bells.cs.ucl.ac.uk>; Thu, 10 May 2001 16:22:31 +0100
To: rmt@lbl.gov, rm@mash.cs.berkeley.edu
Subject: RTT estimation paper of relevance
Date: Thu, 10 May 2001 16:22:30 +0100
Message-ID: <13493.989508150@cs.ucl.ac.uk>
From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
Sender: owner-rmt@lbl.gov
Precedence: bulk
tristan notied a neat paper at infocom this yaer - could be useful in
RMT work (e.g. retransmission and congestion control/rate estimation)
------- Forwarded Message
Measuring delays without needing synchronised clocks:
Estimating One-way Delays from Cyclic-Path Delay Measurements, Omer Gurew=
itz =
(Technion), Moshe Sidi (Technion), INFOCOM 2001
http://infocom.ucsd.edu/papers/232.ps
Cheers,
Tristan
------- End of Forwarded Message
>From owner-rmt@listserv.lbl.gov Fri May 25 03:19:56 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f4PADnF17369;
Fri, 25 May 2001 03:13:49 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f4PADlg17356
for <rmt@listserv.lbl.gov>; Fri, 25 May 2001 03:13:47 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f4PADk127009
for <rmt@listserv.lbl.gov>; Fri, 25 May 2001 03:13:46 -0700 (PDT)
Received: from mx0.gmx.net (mx0.gmx.net [213.165.64.100])
by SpamWall.lbl.gov (8.11.2/8.11.2) with SMTP id f4PADjF27003
for <rmt@lbl.gov>; Fri, 25 May 2001 03:13:45 -0700 (PDT)
Received: (qmail 16450 invoked by alias); 25 May 2001 10:13:38 -0000
Delivered-To: GMX delivery to claudia%carmendorn@gmx.de
Received: (qmail 16441 invoked by uid 0); 25 May 2001 10:13:38 -0000
Date: Fri, 25 May 2001 12:13:38 +0200 (MEST)
From: Carmen Dornbach <CarmenDorn@gmx.de>
MIME-Version: 1.0
X-Priority: 3 (Normal)
X-Authenticated-Sender: #0010896236@gmx.net
X-Authenticated-IP: [195.93.64.171]
Message-ID: <29063.990785618@www31.gmx.net>
X-Mailer: WWW-Mail 1.5 (Global Message Exchange)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
To: claudia%CarmenDorn@gmx.de
Sender: owner-rmt@lbl.gov
Precedence: bulk
Hallo,
wir sind 9 heiße und hemmungslose Girls, nämlich Babette, Moni, Carola,
Angelique, Michelle, Jessica, Melissa, Iris und Sandra, die ein geiles tabuloses
Telefonat, oder bei gefallen einen heißen Seitensprung suchen. Ganz wie Du
willst :o)
Erreichen kannst Du uns direkt unter Telefonnummer: 019085/4794*
Am Telefon können wir uns gleich ein Date ausmachen. Oder hast Du etwa keine
Lust auf einen wilden One Night Stand ? Wir schon :o) ... also beeil Dich
.... fg
Wenn Du uns vorher sehen möchtest, dann schau einfach mal auf unserer
Homepage vorbei ... dort erfährst Du einiges mehr über uns ... www.datingfon.de
Unsere intimsten Geheimnisse verraten wir Dir natürlich nur direkt ... wir
können sie Dir ja am Telefon ins Ohr flüstern ...
Also alles ist möglich weil wir auf alles Lust haben und noch so vieles
ausprobieren wollen .... hoffentlich mit Dir. ... 019085/4794*
Lass uns nicht so lange warten ....
Bussi bis gleich Deine süssen Girls
(* E.p. DM 3,63/min.)
--
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net
--
U2 Konzertreisen inkl. VIP-Package
Hier Eventreisen zur U2-Tour bei Getgo.de online buchen!
http://www.getgo.de/cgi-bin/TDoc.dll?doc=reisen/rei_kon_sta&affiliate=GMX
>From owner-rmt@listserv.lbl.gov Thu May 31 09:23:21 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f4VGINx23845;
Thu, 31 May 2001 09:18:23 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f4VGIMg23841
for <rmt@listserv.lbl.gov>; Thu, 31 May 2001 09:18:22 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f4VGILY01103
for <rmt@listserv.lbl.gov>; Thu, 31 May 2001 09:18:21 -0700 (PDT)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
by SpamWall.lbl.gov (8.11.2/8.11.2) with SMTP id f4VGIKF01089
for <rmt@lbl.gov>; Thu, 31 May 2001 09:18:20 -0700 (PDT)
Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP
id <g.07030-0@bells.cs.ucl.ac.uk>; Thu, 31 May 2001 17:18:16 +0100
To: rm@mash.CS.Berkeley.EDU, rmt@lbl.gov
Subject: 2 week extensions for ETT and NGC2001
Date: Thu, 31 May 2001 17:18:12 +0100
Message-ID: <1012.991325892@cs.ucl.ac.uk>
From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
Sender: owner-rmt@lbl.gov
Precedence: bulk
due to many requests (no, not because we havnt had any submissions)
BOTH the CfPs for the European Transactions on Telecommunications
special issue on From Monitoring to Provisioning: towards closing the
loop on Internet Traffic Engineering
see
http://www.cs.ucl.ac.uk/staff/jon/cfp.txt
and the Network Group Communications Workshop
see
http://www-mice.cs.ucl.ac.uk/ngc2001/
have 2 week extensions - i.e. til jun 14th or so.
sorry if you see this more than once!
cheers
jon
p.s. for those not familiar with ETT, see
http://www.aei.it/ett.html
for more details
>From owner-rmt@listserv.lbl.gov Fri Jun 1 09:26:22 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f51GKT328266;
Fri, 1 Jun 2001 09:20:29 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f51GKSg28262
for <rmt@listserv.lbl.gov>; Fri, 1 Jun 2001 09:20:28 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f51GKRv13958
for <rmt@listserv.lbl.gov>; Fri, 1 Jun 2001 09:20:27 -0700 (PDT)
Received: from wgs.steeple.plc.uk ([195.188.28.11])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f51GKPF13951
for <rmt@lbl.gov>; Fri, 1 Jun 2001 09:20:25 -0700 (PDT)
Received: from home.com ([195.188.28.55]) by wgs.steeple.plc.uk with Microsoft SMTPSVC(5.0.2195.1600);
Fri, 1 Jun 2001 17:13:26 +0100
From: "L@@K dont throw away!" <jimbobuk@home.com>
To: <rmt@lbl.gov>
Subject: Have you been hacked by f*ck PoizonBOx?
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Date: Fri, 1 Jun 2001 17:20:43 +0100
X-Priority: 1 (Highest)
Content-Transfer-Encoding: 8bit
Message-ID: <WGSx3Vp20N39x6HHGNZ00001a46@wgs.steeple.plc.uk>
X-OriginalArrivalTime: 01 Jun 2001 16:13:26.0343 (UTC) FILETIME=[C9E2AD70:01C0EAB5]
Sender: owner-rmt@lbl.gov
Precedence: bulk
I've created an online community called "Have you been hacked by f*ck
PoizonBOx?".
http://www.delphi.com/PoizonBOx/start/
Please join the discussion!
With the message board, you can view discussion folders quickly in the
left-hand column and read up to 20 messages at a time. You can even attach
files (such as pictures and programs) directly to messages -- just like
e-mail. It's fast, easy, and efficient.
As the Forum "Host," I control the specific features of the Forum. The
other options include real-time Chat, voice chat, and polls. I can also
choose to make it public or private.
I've chosen to make this Forum public so anyone can participate, so feel
free to tell your friends.
The best way into my Forum is at the following URL:
http://www.delphi.com/PoizonBOx/start/
I'm eager to hear comments and suggestions. Let's get the conversation
started!
Best regards,
>From owner-rmt@listserv.lbl.gov Thu Jun 7 18:37:11 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f581XZq00978;
Thu, 7 Jun 2001 18:33:35 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f581XY100974
for <rmt@listserv.lbl.gov>; Thu, 7 Jun 2001 18:33:34 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f581XXv08852
for <rmt@listserv.lbl.gov>; Thu, 7 Jun 2001 18:33:33 -0700 (PDT)
Received: from mail.eecis.udel.edu (louie.udel.edu [128.175.2.33])
by SpamWall.lbl.gov (8.11.2/8.11.2) with SMTP id f581XX608849
for <rmt@lbl.gov>; Thu, 7 Jun 2001 18:33:33 -0700 (PDT)
Received: from ren.eecis.udel.edu by mail.eecis.udel.edu id aa16170;
7 Jun 2001 21:33 EDT
Date: Thu, 7 Jun 2001 21:33:08 -0400 (EDT)
From: Xinming He <xinming@mail.eecis.udel.edu>
To: rmt@lbl.gov
MMDF-Warning: Parse error in original version of preceding line at mail.eecis.udel.edu
Subject: a quick questions about NCF in PGM
Message-ID: <Pine.GSO.4.31.0106072123350.18516-100000@ren.eecis.udel.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-rmt@lbl.gov
Precedence: bulk
When a network element(PGM capable) receives a NCF from its upstream
parent, will it forward the NCF to its downstream nodes, or discard the
NCF after establishing the neccessary state in itself? In the PGM
sepcification, it just says the NCF will be multicasted the group. Should
the network element really forward it to its downstream nodes when
receiving one from its parent? If yes, there seems to be too much control
traffic as a result of packet loss?
>From owner-rmt@listserv.lbl.gov Thu Jun 7 18:55:48 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f581sMg01009;
Thu, 7 Jun 2001 18:54:22 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f581sL101005
for <rmt@listserv.lbl.gov>; Thu, 7 Jun 2001 18:54:21 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f581sKA11152
for <rmt@listserv.lbl.gov>; Thu, 7 Jun 2001 18:54:20 -0700 (PDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f581sK611147
for <rmt@lbl.gov>; Thu, 7 Jun 2001 18:54:20 -0700 (PDT)
Received: from cypher.cisco.com (cypher.cisco.com [171.69.11.18])
by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f581s2906522;
Thu, 7 Jun 2001 18:54:02 -0700 (PDT)
Date: Thu, 7 Jun 2001 18:53:58 -0700 (PDT)
From: Nidhi Bhaskar <nbhaskar@cisco.com>
Reply-To: Nidhi Bhaskar <nidhi@cisco.com>
To: Xinming He <xinming@mail.eecis.udel.edu>
cc: <rmt@lbl.gov>
Subject: Re: a quick questions about NCF in PGM
In-Reply-To: <Pine.GSO.4.31.0106072123350.18516-100000@ren.eecis.udel.edu>
Message-ID: <Pine.GSO.4.33.0106071846490.11388-100000@cypher.cisco.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-rmt@lbl.gov
Precedence: bulk
On Thu, 7 Jun 2001, Xinming He wrote:
> When a network element(PGM capable) receives a NCF from its upstream
> parent, will it forward the NCF to its downstream nodes, or discard the
> NCF after establishing the neccessary state in itself? In the PGM
NCFs travel only 1 PGM hop.
> sepcification, it just says the NCF will be multicasted the group. Should
> the network element really forward it to its downstream nodes when
> receiving one from its parent? If yes, there seems to be too much control
> traffic as a result of packet loss?
They are multicast to the group address so that they can traverse any
non-PGM capable routers in the tree to reach downstream PGM nodes.
They carry the router alert option which causes each router to examine
them hop-by-hop and a PGM capable router to stop them from being
forwarded further than a single PGM hop.
Thanks,
Nidhi.
>
>
>
>
>
>From owner-rmt@listserv.lbl.gov Fri Jun 8 07:31:58 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f58ESOe02650;
Fri, 8 Jun 2001 07:28:24 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f58ESM102646
for <rmt@listserv.lbl.gov>; Fri, 8 Jun 2001 07:28:23 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f58ESM421893
for <rmt@listserv.lbl.gov>; Fri, 8 Jun 2001 07:28:22 -0700 (PDT)
Received: from issaspam-ny01.ssmb.com (mail1.ssmb.COM [199.67.139.25])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f58ESK621871
for <rmt@lbl.gov>; Fri, 8 Jun 2001 07:28:21 -0700 (PDT)
Received: from imbcorp-ny02.ny.ssmb.com (imbcorp-ny02-qfe0 [162.124.152.39])
by issaspam-ny01.ssmb.com (8.11.0/8.11.0/SSMB_EXT/1.2) with ESMTP id f58ERtV05603
for <rmt@lbl.gov>; Fri, 8 Jun 2001 10:27:55 -0400 (EDT)
Received: from imbicmr-ny01.sbi.com (imbicmr-ny01.ny.ssmb.com [162.124.154.48])
by imbcorp-ny02.ny.ssmb.com (8.11.0/8.11.0/SSMB_QQQ_IN/1.1) with ESMTP id f58EQMH04704
for <rmt@lbl.gov>; Fri, 8 Jun 2001 10:26:22 -0400 (EDT)
Received: (from uucp@localhost)
by imbicmr-ny01.sbi.com (8.11.0/8.11.0/SSMB_ICMR/1.1) id f58EQMo13575
for <rmt@lbl.gov>; Fri, 8 Jun 2001 10:26:22 -0400 (EDT)
X-Authentication-Warning: imbicmr-ny01.sbi.com: uucp set sender to <Michael_Eckhoff@AFCC.com> using -f
Received: from nodnsquery(10.96.1.10) by imbicmr-ny01.sbi.com via smap (V4.0)
id xma013510; Fri, 8 Jun 01 10:26:10 -0400
Received: by Z1111141.core.afcc.com with Internet Mail Service (5.5.2651.58)
id <MCVVGHF8>; Fri, 8 Jun 2001 09:26:10 -0500
Message-ID: <6EF6F5B5843ED211A4800060083FFC750A2D6DBF@Z1111221.core.afcc.com>
From: "Eckhoff, Michael" <Michael_Eckhoff@AFCC.com>
To: "'rmt@lbl.gov'" <rmt@lbl.gov>
Subject: Multicast and Cisco 6500 switches
Date: Fri, 8 Jun 2001 09:26:08 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2651.58)
Content-Type: text/plain
Sender: owner-rmt@lbl.gov
Precedence: bulk
If this question is way out of line for this group, please advise.
We are noticing significant problems with multicast on Cisco 6500 series
layer 3 switches (with dual MSFCs). I am going to do additional testing at
one of Cisco's labs this weekend, but if anyone has any input beforehand,
I'd greatly appreciate it. Also, if you have this working well, if you can
forward any configs/IOS versions/etc. I'd appreciate it.
What I am expecting to find is duplicate packets or dropped packets under
high utilization. I have found that this is more than what just LRMP can
handle. The end application ends up totally unusable.
With this problem, what is an "acceptable" amount of loss (and possible
packet duplication) for reliable multicast to remain reliable?
Thanks
Michael R. Eckhoff
citigroup/Associates
>From owner-rmt@listserv.lbl.gov Fri Jun 8 11:11:50 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f58IAvP03583;
Fri, 8 Jun 2001 11:10:57 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f58IAu103579
for <rmt@listserv.lbl.gov>; Fri, 8 Jun 2001 11:10:56 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f58IAtG06619
for <rmt@listserv.lbl.gov>; Fri, 8 Jun 2001 11:10:56 -0700 (PDT)
Received: from mx.webfountain.com (mx.digitalfountain.com [209.219.233.39])
by SpamWall.lbl.gov (8.11.2/8.11.2) with SMTP id f58IAs606607
for <rmt@lbl.gov>; Fri, 8 Jun 2001 11:10:54 -0700 (PDT)
Received: (qmail 16275 invoked from network); 8 Jun 2001 18:10:45 -0000
Received: from mail.intranet (10.1.1.37)
by mx.digitalfountain.com with SMTP; 8 Jun 2001 18:10:45 -0000
Received: from nui (dhcp-10-1-3-239.intranet [10.1.3.239])
by mail.intranet (8.9.3/8.9.3) with SMTP id LAA08920
for <rmt@lbl.gov>; Fri, 8 Jun 2001 11:10:19 -0700
X-Authentication-Warning: mail.intranet: Host dhcp-10-1-3-239.intranet [10.1.3.239] claimed to be nui
From: "Gavin Vess" <vess@digitalfountain.com>
To: <rmt@lbl.gov>
Subject: RE: Multicast and Cisco 6500 switches
Date: Fri, 8 Jun 2001 11:10:18 -0700
Message-ID: <EPEDJHFNLLCHDMBLONDAEEPCCCAA.vess@digitalfountain.com>
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="----=_NextPart_000_000A_01C0F00B.99EFF400"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Importance: Normal
In-Reply-To: <NEBBLAIAFKIGGKHIOBHCIEOHCCAA.gavin@dfountain.com>
Sender: owner-rmt@lbl.gov
Precedence: bulk
This is a multi-part message in MIME format.
------=_NextPart_000_000A_01C0F00B.99EFF400
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: base64
SGksDQoNCkEgZnJpZW5kIGZvcndhcmQgbWUgYSBjb3B5IG9mIHlvdXIgZW1haWwuICBJIGp1c3Qg
c2F3IHNvbWV0aGluZyBlbHNlIHRoYXQgbWlnaHQgaW50ZXJlc3QgeW91IChhdHRhY2hlZCBiZWxv
dykuICBJIGFtIHF1aXRlIGludGVyZXN0ZWQgaW4geW91ciBmaW5kaW5ncyB0aGlzIHdlZWtlbmQg
cmVsYXRpbmcgdG8gTXVsdGljYXN0IGFuZCBDaXNjbyBzd2l0Y2hlcy4NCg0KUGVyaGFwcyB0aGUg
YXR0YWNoZWQgbWF0cml4IG9mIHdoYXQgQ2lzY28gbW9kZWxzIGFuZCBJT1MncyBzdXBwb3J0IGZv
ciBtdWx0aWNhc3Qgd2lsbCBiZSBvZiBpbnRlcmVzdCB0byB5b3U/DQoNCg0KPiBCdWcgcmVwb3J0
IG9uIHRoZSBPTlMgMTU0NTQgYW5kIDE1MzI3Og0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLQ0KPg0KPiBPTlMgMTU0NTQgYW5kIE9OUyAxNTMyNzogRXRoZXJuZXQgTGlu
ZSBDYXJkIFBhY2tldCBGb3J3YXJkaW5nIExpbWl0YXRpb25zDQo+ID09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQo+IGNhbiBjYXVz
ZSBwcm9ibGVtcyB3aXRoIG11bHRpY2FzdCB0cmFmZmljDQo+IFVuaWNhc3QgcGFja2V0IGxvc3Mg
Y2FuIG9jY3VyIHdoZW4gRmxvb2QNCj4gPC91bml2ZXJjZC9jYy90ZC9kb2MvY2lzaW50d2svaWNz
L2NzMDA2Lmh0bT4gb3IgTXVsdGljYXN0IHRyYWZmaWMgaXMNCj4gcHJlc2VudC4NCj4NCj4gSWYg
TXVsdGljYXN0IGlzIHVzZWQgZm9yIHN1Y2ggYXBwbGljYXRpb25zIGFzIHZpZGVvIGRpc3RyaWJ1
dGlvbiwNCj4gc2lnbmlmaWNhbnQgbG9zcyBvZiBVbmljYXN0IGFuZCBNdWx0aWNhc3QgdHJhZmZp
YyB3aWxsIHJlc3VsdC4gVGhlc2UgY2FyZHMNCj4gd2VyZSBub3QgZGVzaWduZWQgZm9yIGFuZCBz
aG91bGQgbm90IGJlIHVzZWQgZm9yIHN1Y2ggYXBwbGljYXRpb25zLg0KPg0KPiBJZiB0aGUgTXVs
dGljYXN0IGFuZCBGbG9vZCB0cmFmZmljIGlzIHJhcmUgYW5kIGxvdy1yYXRlLCBhcyBvY2N1cnMg
aW4gbW9zdA0KPiBuZXR3b3JrcyBkdWUgdG8gY2VydGFpbiBjb250cm9sIHByb3RvY29scyBhbmQg
b2NjYXNpb25hbCBsZWFybmluZyBvZiBuZXcNCk1BQw0KPiBhZGRyZXNzZXMsIHRoZSBsb3NzIG9m
IHVuaWNhc3QgZnJhbWVzIHdpbGwgYmUgcmFyZSBhbmQgbGlrZWx5IHVubm90aWNlYWJsZQ0KPiBo
dHRwOi8vd3d3LmNpc2NvLmNvbS93YXJwL3B1YmxpYy83NzAvZm4xMzE3MS5zaHRtbA0KPg0KPiBN
eSB1bmRlcnN0YW5kaW5nIGlzIHRoaXMgd2lsbCBiZSBmaXggd2l0aCBhIG5ldyByZWxlYXNlIG9m
IHRoZSBFdGhlcm5ldA0KbGluZQ0KPiBjYXJkLg0KPg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn
ZS0tLS0tDQo+IEZyb206IG93bmVyLXJtdEBsYmwuZ292IFttYWlsdG86b3duZXItcm10QGxibC5n
b3ZdT24gQmVoYWxmIE9mIEVja2hvZmYsDQo+IE1pY2hhZWwNCj4gU2VudDogRnJpZGF5LCBKdW5l
IDA4LCAyMDAxIDc6MjYgQU0NCj4gVG86ICdybXRAbGJsLmdvdicNCj4gU3ViamVjdDogTXVsdGlj
YXN0IGFuZCBDaXNjbyA2NTAwIHN3aXRjaGVzDQo+IA0KPiANCj4gDQo+IElmIHRoaXMgcXVlc3Rp
b24gaXMgd2F5IG91dCBvZiBsaW5lIGZvciB0aGlzIGdyb3VwLCBwbGVhc2UgYWR2aXNlLg0KPiAN
Cj4gV2UgYXJlIG5vdGljaW5nIHNpZ25pZmljYW50IHByb2JsZW1zIHdpdGggbXVsdGljYXN0IG9u
IENpc2NvIDY1MDAgc2VyaWVzDQo+IGxheWVyIDMgc3dpdGNoZXMgKHdpdGggZHVhbCBNU0ZDcyku
ICBJIGFtIGdvaW5nIHRvIGRvIGFkZGl0aW9uYWwgDQo+IHRlc3RpbmcgYXQNCj4gb25lIG9mIENp
c2NvJ3MgbGFicyB0aGlzIHdlZWtlbmQsIGJ1dCBpZiBhbnlvbmUgaGFzIGFueSBpbnB1dCBiZWZv
cmVoYW5kLA0KPiBJJ2QgZ3JlYXRseSBhcHByZWNpYXRlIGl0LiAgQWxzbywgaWYgeW91IGhhdmUg
dGhpcyB3b3JraW5nIHdlbGwsIA0KPiBpZiB5b3UgY2FuDQo+IGZvcndhcmQgYW55IGNvbmZpZ3Mv
SU9TIHZlcnNpb25zL2V0Yy4gSSdkIGFwcHJlY2lhdGUgaXQuDQo+IA0KPiBXaGF0IEkgYW0gZXhw
ZWN0aW5nIHRvIGZpbmQgaXMgZHVwbGljYXRlIHBhY2tldHMgb3IgZHJvcHBlZCBwYWNrZXRzIHVu
ZGVyDQo+IGhpZ2ggdXRpbGl6YXRpb24uICBJIGhhdmUgZm91bmQgdGhhdCB0aGlzIGlzIG1vcmUg
dGhhbiB3aGF0IGp1c3QgTFJNUCBjYW4NCj4gaGFuZGxlLiAgVGhlIGVuZCBhcHBsaWNhdGlvbiBl
bmRzIHVwIHRvdGFsbHkgdW51c2FibGUuDQo+IA0KPiBXaXRoIHRoaXMgcHJvYmxlbSwgd2hhdCBp
cyBhbiAiYWNjZXB0YWJsZSIgYW1vdW50IG9mIGxvc3MgKGFuZCBwb3NzaWJsZQ0KPiBwYWNrZXQg
ZHVwbGljYXRpb24pIGZvciByZWxpYWJsZSBtdWx0aWNhc3QgdG8gcmVtYWluIHJlbGlhYmxlPw0K
PiANCj4gVGhhbmtzDQo+IA0KPiBNaWNoYWVsIFIuIEVja2hvZmYNCj4gY2l0aWdyb3VwL0Fzc29j
aWF0ZXMNCj4gDQo+IA==
------=_NextPart_000_000A_01C0F00B.99EFF400
Content-Type: text/html;
name="Cisco Multicast Support Matrix.htm"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
filename="Cisco Multicast Support Matrix.htm"
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<!-- saved from =
url=3D(0073)http://www.cisco.com/warp/partner/synchronicd/cc/pd/iosw/tech=
/mcmm_rg.htm -->
<HTML><HEAD><TITLE>Cisco Multicast Support Matrix</TITLE>
<META content=3D"text/html; charset=3Dwindows-1252" =
http-equiv=3DContent-Type><!-- FileName =3D mcmm_rg.fm --><!-- Folder =
=3D /EP/SOLUTION/AGENERAL --><!-- Object_ID =3D 090019e9806f9410 --><!-- =
Chronicle ID =3D 090019e9806f9410 --><!-- Revision =3D 1.0 --><!-- =
DocType =3D Reference Guides --><!-- ProdType =3D cc/pd/iosw/tech =
--><!-- Sector =3D Enterprise/CiscoPro --><!-- RelState =3D Released =
--><!-- PubDate =3D 08/20/2000 --><!-- PushDate =3D Mon Aug 21 14:34:09 =
PDT 2000 --><!-- Competitors =3D --><!-- ParentTree =3D =
cc/pd/iosw/tech, cc/so/cuso/sp, cc/so/neso/axso/rmax --><!-- Parents =3D =
cc/pd/iosw/tech --><!-- IsCategory =3D --><!-- EncodeDesc =3D =
IP+Multicast+quick+reference+matrix%2e --><!-- Language =3D English =
--><!-- CCO Not Searchable =3D 0 --><!-- Category =3D Technical =
Marketing Information --><!-- Keyword =3D Technical Marketing =
Information -->
<META content=3Dmcmm_rg.fm name=3DFileName>
<META content=3D/EP/SOLUTION/AGENERAL name=3DFolder>
<META content=3D090019e9806f9410 name=3DObject_ID>
<META content=3D090019e9806f9410 name=3D"Chronicle ID">
<META content=3D1.0 name=3DRevision>
<META content=3D"Reference Guides" name=3DDocType>
<META content=3Dcc/pd/iosw/tech name=3DProdType>
<META content=3DEnterprise/CiscoPro name=3DSector>
<META content=3DReleased name=3DRelState>
<META content=3D08/20/2000 name=3DPubDate>
<META content=3D"Mon Aug 21 14:34:09 PDT 2000" name=3DPushDate>
<META content=3D"" name=3DCompetitors>
<META content=3D"cc/pd/iosw/tech, cc/so/cuso/sp, cc/so/neso/axso/rmax"=20
name=3DParentTree>
<META content=3Dcc/pd/iosw/tech name=3DParents>
<META content=3D"" name=3DIsCategory>
<META content=3DIP+Multicast+quick+reference+matrix%2e =
name=3DEncodeDesc>
<META content=3DEnglish name=3DLanguage>
<META content=3D0 name=3D"CCO Not Searchable">
<META content=3D"Technical Marketing Information" name=3DCategory>
<META content=3D"Technical Marketing Information" name=3DKeyword>
<META content=3D"MSHTML 5.00.3018.900" name=3DGENERATOR></HEAD>
<BODY bgColor=3D#ffffff>
<TABLE>
<TBODY>
<TR>
<TD><IMG alt=3Dcc/pd/iosw border=3D0 height=3D21=20
src=3D"Cisco Multicast Support Matrix_files/docstrip.gif" =
width=3D504><BR><A=20
=
href=3D"http://www.cisco.com/warp/partner/synchronicd/home/home.htm"><IMG=
=20
alt=3Dhome border=3D0 height=3D21=20
src=3D"Cisco Multicast Support Matrix_files/home.gif" =
width=3D72></A><A=20
=
href=3D"http://www.cisco.com/warp/partner/synchronicd/cc/pd/iosw/tech/ind=
ex.htm"><IMG=20
alt=3Dtoc border=3D0 height=3D21=20
src=3D"Cisco Multicast Support Matrix_files/toc.gif" =
width=3D72></A><A=20
=
href=3D"http://www.cisco.com/warp/partner/synchronicd/cc/pd/iosw/tech/tel=
cs_ds.htm"><IMG=20
alt=3Dprev border=3D0 height=3D21=20
src=3D"Cisco Multicast Support Matrix_files/prev.gif" =
width=3D72></A><A=20
=
href=3D"http://www.cisco.com/warp/partner/synchronicd/cc/pd/iosw/tech/ted=
cn_wp.htm"><IMG=20
alt=3Dnext border=3D0 height=3D21=20
src=3D"Cisco Multicast Support Matrix_files/next.gif" =
width=3D72></A><A=20
=
href=3D"http://www.cisco.com/warp/partner/synchronicd/cc/pd/iosw/tech/mcm=
m_rg.pdf"><IMG=20
alt=3Dpdf border=3D0 height=3D21=20
src=3D"Cisco Multicast Support Matrix_files/pdf.gif" =
width=3D72></A><A=20
=
href=3D"http://www.cisco.com/warp/partner/synchronicd/home/search.htm"><I=
MG=20
alt=3Dsearch border=3D0 height=3D21=20
src=3D"Cisco Multicast Support Matrix_files/search.gif" =
width=3D72></A><A=20
=
href=3D"http://www.cisco.com/warp/partner/synchronicd/cc/lib/help.htm"><I=
MG=20
alt=3Dhelp border=3D0 height=3D21=20
src=3D"Cisco Multicast Support Matrix_files/help.gif" =
width=3D72></A>=20
<BR></TD></TR></TBODY></TABLE><I></I>
<H2>Table of Contents</H2><A=20
href=3D"http://www.cisco.com/warp/partner/synchronicd/cc/pd/iosw/tech/mcm=
m_rg.htm#xtocid480">
<H3>Reference Guide</H3></A><A=20
href=3D"http://www.cisco.com/warp/partner/synchronicd/cc/pd/iosw/tech/mcm=
m_rg.htm#xtocid481">
<H3>Cisco Multicast Support Matrix</H3></A>
<UL><A=20
=
href=3D"http://www.cisco.com/warp/partner/synchronicd/cc/pd/iosw/tech/mcm=
m_rg.htm#xtocid482"><B>Part=20
1--Table of Switch features related to IP Multicast</B><BR></A><A=20
=
href=3D"http://www.cisco.com/warp/partner/synchronicd/cc/pd/iosw/tech/mcm=
m_rg.htm#xtocid483"><B>Part=20
2--Cisco IOS Multicast Features</B><BR></A>
<UL><A=20
=
href=3D"http://www.cisco.com/warp/partner/synchronicd/cc/pd/iosw/tech/mcm=
m_rg.htm#xtocid484"><FONTSIZE=3D4>Bi-Dir=20
12.1(2)T</FONT><BR></A><A=20
=
href=3D"http://www.cisco.com/warp/partner/synchronicd/cc/pd/iosw/tech/mcm=
m_rg.htm#xtocid485"><FONTSIZE=3D4>MBGP=20
12.0(7)T</FONT><BR></A><A=20
=
href=3D"http://www.cisco.com/warp/partner/synchronicd/cc/pd/iosw/tech/mcm=
m_rg.htm#xtocid486"><FONTSIZE=3D4>MDS/MDFS</FONT><BR></A><A=20
=
href=3D"http://www.cisco.com/warp/partner/synchronicd/cc/pd/iosw/tech/mcm=
m_rg.htm#xtocid487"><FONTSIZE=3D4>MMLS=20
12.0(5)T or 5.3 of C6K or 5.1 of C5K</FONT><BR></A><A=20
=
href=3D"http://www.cisco.com/warp/partner/synchronicd/cc/pd/iosw/tech/mcm=
m_rg.htm#xtocid488"><FONTSIZE=3D4>MRM=20
12.0(5)T and 12.0(5)S</FONT><BR></A><A=20
=
href=3D"http://www.cisco.com/warp/partner/synchronicd/cc/pd/iosw/tech/mcm=
m_rg.htm#xtocid489"><FONTSIZE=3D4>MSDP=20
12.0(7)T</FONT><BR></A><A=20
=
href=3D"http://www.cisco.com/warp/partner/synchronicd/cc/pd/iosw/tech/mcm=
m_rg.htm#xtocid4810"><FONTSIZE=3D4>MvoIP=20
12.1(3)T</FONT><BR></A><A=20
=
href=3D"http://www.cisco.com/warp/partner/synchronicd/cc/pd/iosw/tech/mcm=
m_rg.htm#xtocid4811"><FONTSIZE=3D4>PGM=20
Features</FONT><BR></A>
<UL><A=20
=
href=3D"http://www.cisco.com/warp/partner/synchronicd/cc/pd/iosw/tech/mcm=
m_rg.htm#xtocid4812"><FONTSIZE=3D4>PGM=20
Router Assist 12.0(5)T</FONT><BR></A><A=20
=
href=3D"http://www.cisco.com/warp/partner/synchronicd/cc/pd/iosw/tech/mcm=
m_rg.htm#xtocid4813"><FONTSIZE=3D4>PGM=20
Host 12.1(1)T</FONT><BR></A></UL><A=20
=
href=3D"http://www.cisco.com/warp/partner/synchronicd/cc/pd/iosw/tech/mcm=
m_rg.htm#xtocid4814"><FONTSIZE=3D4>SSM=20
12.1(3)T</FONT><BR></A><A=20
=
href=3D"http://www.cisco.com/warp/partner/synchronicd/cc/pd/iosw/tech/mcm=
m_rg.htm#xtocid4815"><FONTSIZE=3D4>UDLR=20
12.0(3)T.</FONT><BR></A><A=20
=
href=3D"http://www.cisco.com/warp/partner/synchronicd/cc/pd/iosw/tech/mcm=
m_rg.htm#xtocid4816"><FONTSIZE=3D4>CBOS=20
commands</FONT><BR></A>
<UL><A=20
=
href=3D"http://www.cisco.com/warp/partner/synchronicd/cc/pd/iosw/tech/mcm=
m_rg.htm#xtocid4817"><FONTSIZE=3D4>Multicast=20
proxy support (IGMP Proxy) Release =
2.1.0</FONT><BR></A></UL></UL><A=20
=
href=3D"http://www.cisco.com/warp/partner/synchronicd/cc/pd/iosw/tech/mcm=
m_rg.htm#xtocid4818"><B>Part=20
3--Multicast Documentation by Switch:</B><BR></A>
<UL><A=20
=
href=3D"http://www.cisco.com/warp/partner/synchronicd/cc/pd/iosw/tech/mcm=
m_rg.htm#xtocid4819"><FONTSIZE=3D4>1200:=20
Not Mentioned</FONT><BR></A><A=20
=
href=3D"http://www.cisco.com/warp/partner/synchronicd/cc/pd/iosw/tech/mcm=
m_rg.htm#xtocid4820"><FONTSIZE=3D4>1420/1220:=20
Manual configuration</FONT><BR></A><A=20
=
href=3D"http://www.cisco.com/warp/partner/synchronicd/cc/pd/iosw/tech/mcm=
m_rg.htm#xtocid4821"><FONTSIZE=3D4>1548:=20
Not mentioned</FONT><BR></A><A=20
=
href=3D"http://www.cisco.com/warp/partner/synchronicd/cc/pd/iosw/tech/mcm=
m_rg.htm#xtocid4822"><FONTSIZE=3D4>1900/2820:=20
CGMP</FONT><BR></A><A=20
=
href=3D"http://www.cisco.com/warp/partner/synchronicd/cc/pd/iosw/tech/mcm=
m_rg.htm#xtocid4823"><FONTSIZE=3D4>2100:=20
Manual configuration</FONT><BR></A><A=20
=
href=3D"http://www.cisco.com/warp/partner/synchronicd/cc/pd/iosw/tech/mcm=
m_rg.htm#xtocid4824"><FONTSIZE=3D4>2800:=20
Manual configuration</FONT><BR></A><A=20
=
href=3D"http://www.cisco.com/warp/partner/synchronicd/cc/pd/iosw/tech/mcm=
m_rg.htm#xtocid4825"><FONTSIZE=3D4>2900XL/3500XL:=20
CGMP</FONT><BR></A><A=20
=
href=3D"http://www.cisco.com/warp/partner/synchronicd/cc/pd/iosw/tech/mcm=
m_rg.htm#xtocid4826"><FONTSIZE=3D4>2948G-L3:=20
CGMP server and Constrained Multicast Flooding =
(CMF)</FONT><BR></A><A=20
=
href=3D"http://www.cisco.com/warp/partner/synchronicd/cc/pd/iosw/tech/mcm=
m_rg.htm#xtocid4827"><FONTSIZE=3D4>5000,4000,2926G,2948G=20
and 2980G: CGMP, IGMP-Snooping, RGMP, GMRP</FONT><BR></A><A=20
=
href=3D"http://www.cisco.com/warp/partner/synchronicd/cc/pd/iosw/tech/mcm=
m_rg.htm#xtocid4828"><FONTSIZE=3D4>6000:=20
IGMP-Snooping, RGMP, GMRP</FONT><BR></A><A=20
=
href=3D"http://www.cisco.com/warp/partner/synchronicd/cc/pd/iosw/tech/mcm=
m_rg.htm#xtocid4829"><FONTSIZE=3D4>8500:=20
CMF</FONT><BR></A></UL><A=20
=
href=3D"http://www.cisco.com/warp/partner/synchronicd/cc/pd/iosw/tech/mcm=
m_rg.htm#xtocid4830"><B>Part=20
4--Glossary</B><BR></A></UL>
<UL></UL>
<P>
<H1><A name=3Dxtocid480>Reference Guide</A></H1>
<H1><A name=3Dxtocid481>Cisco Multicast Support Matrix</A></H1>
<P>This document is intended as a quick reference for IP Multicast =
features=20
supported by both Cisco IOS and Cisco Switching products.</P>
<P>Part 1 is a table of IPmc features supported per Catalyst switch =
family. </P>
<P>Part 2 is a list of Cisco IOS IPmc features and their supported =
release. </P>
<P>Part 3 is a list of Catalyst documentation links.</P>
<P>Part 4 is a glossary.</P>
<H2><A name=3Dxtocid482>Part 1--Table of Switch features related to IP =
Multicast=20
</A></H2>
<TABLE border=3D1 cellPadding=3D10>
<TBODY>
<TR vAlign=3Dtop>
<TH align=3Dleft><B><STRONG> </STRONG></B></TH>
<TH align=3Dleft><B>IGMP-Snooping</B> </TH>
<TH align=3Dleft><B>CGMP</B> </TH>
<TH align=3Dleft><B>RGMP****</B> </TH>
<TH align=3Dleft><B>CMF**</B> </TH>
<TH align=3Dleft><B>GMRP***</B> </TH></TR>
<TR vAlign=3Dtop>
<TD align=3Dleft><B>C85xx</B> </TD>
<TD align=3Dleft>
<P>No</P></TD>
<TD align=3Dleft>
<P>No</P></TD>
<TD align=3Dleft>
<P>No</P></TD>
<TD align=3Dleft>
<P>Yes</P></TD>
<TD align=3Dleft>
<P>No</P></TD></TR>
<TR vAlign=3Dtop>
<TD align=3Dleft><B>C6K</B> </TD>
<TD align=3Dleft>
<P>Yes</P></TD>
<TD align=3Dleft>
<P>No</P></TD>
<TD align=3Dleft>
<P>Yes</P></TD>
<TD align=3Dleft>
<P>No</P></TD>
<TD align=3Dleft>
<P>Yes</P></TD></TR>
<TR vAlign=3Dtop>
<TD align=3Dleft><B>C5K</B> </TD>
<TD align=3Dleft>
<P>Yes*</P></TD>
<TD align=3Dleft>
<P>Yes</P></TD>
<TD align=3Dleft>
<P>Yes</P></TD>
<TD align=3Dleft>
<P>No</P></TD>
<TD align=3Dleft>
<P>Yes</P></TD></TR>
<TR vAlign=3Dtop>
<TD align=3Dleft><B>C4K</B> </TD>
<TD align=3Dleft>
<P>No</P></TD>
<TD align=3Dleft>
<P>Yes</P></TD>
<TD align=3Dleft>
<P>No</P></TD>
<TD align=3Dleft>
<P>No</P></TD>
<TD align=3Dleft>
<P>Yes</P></TD></TR>
<TR vAlign=3Dtop>
<TD align=3Dleft><B>C29xxG</B> </TD>
<TD align=3Dleft>
<P>No</P></TD>
<TD align=3Dleft>
<P>Yes</P></TD>
<TD align=3Dleft>
<P>No</P></TD>
<TD align=3Dleft>
<P>No</P></TD>
<TD align=3Dleft>
<P>Yes</P></TD></TR>
<TR vAlign=3Dtop>
<TD align=3Dleft><B>C29xx-L3</B> </TD>
<TD align=3Dleft>
<P>No</P></TD>
<TD align=3Dleft>
<P>No</P></TD>
<TD align=3Dleft>
<P>No</P></TD>
<TD align=3Dleft>
<P>Yes</P></TD>
<TD align=3Dleft>
<P>No</P></TD></TR>
<TR vAlign=3Dtop>
<TD align=3Dleft><B>C29/35 XL</B> </TD>
<TD align=3Dleft>
<P>No</P></TD>
<TD align=3Dleft>
<P>Yes</P></TD>
<TD align=3Dleft>
<P>No</P></TD>
<TD align=3Dleft>
<P>No</P></TD>
<TD align=3Dleft>
<P>No</P></TD></TR>
<TR vAlign=3Dtop>
<TD align=3Dleft><B>1900/2800</B> </TD>
<TD align=3Dleft>
<P>No</P></TD>
<TD align=3Dleft>
<P>Yes</P></TD>
<TD align=3Dleft>
<P>No</P></TD>
<TD align=3Dleft>
<P>No</P></TD>
<TD align=3Dleft>
<P>No</P></TD></TR></TBODY></TABLE>
<TABLE cellPadding=3D10>
<TBODY>
<TR>
<TD></TR></TBODY></TABLE><A name=3D18738></A>* Requires NFFC II =
<BR><A=20
name=3D18739></A>** CMF is IOS's Router code performing IGMP snooping=20
function.<BR><A name=3D18740></A>*** GMRP requires Host NIC =
support.<BR><A=20
name=3D17739></A>**** RGMP inter-operates with RGMP capable routers<BR>
<H2><A name=3Dxtocid483>Part 2--Cisco IOS Multicast Features</A></H2>
<P>Cisco IOS has supported IP multicast since version 10.2 released in =
1995.=20
Cisco IOS 12.0 is the recommended version for all IP multicast =
implementations.=20
This is because it supports PIM-SM v2. This is the recommended version =
of PIM if=20
interoperability with other vendors is required.</P>
<P>There are minor incompatibilities when versions 1 and 2 of PIM-SM=20
inter-operate Cisco recommend to use PIM version 2.</P>
<P>Please visit the IP Multicast Groups external home page. This page is =
supported directly by the engineers in the Multicast group, so you can =
always be=20
assured of the latest information. The URL is=20
ftp://ftpeng.cisco.com/ipmulticast/index.html </P>
<H3><A name=3Dxtocid484>Bi-Dir 12.1(2)T</A></H3>
<P><A=20
href=3D"http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/1=
21newft/121t/121t2/dtbipim.htm">http://www.cisco.com/univercd/cc/td/doc/p=
roduct/software/ios121/121newft/121t/121t2/dtbipim.htm</P></A>
<H3><A name=3Dxtocid485>MBGP 12.0(7)T</A></H3>
<P><A=20
href=3D"http://www/univercd/cc/td/doc/product/software/ios120/120newft/12=
0t/120t7/mbgp.htm">http://www/univercd/cc/td/doc/product/software/ios120/=
120newft/120t/120t7/mbgp.htm</P></A>
<H3><A name=3Dxtocid486>MDS/MDFS</A></H3>
<P>Cisco IOS versions 11.1(25.2)CC, 12.0(3.7)S3, and 12.0(4.0.4)S</P>
<P><A=20
href=3D"http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/1=
2cgcr/switch_c/xcprt6/xcmds.htm">http://www.cisco.com/univercd/cc/td/doc/=
product/software/ios120/12cgcr/switch_c/xcprt6/xcmds.htm</P></A>
<H3><A name=3Dxtocid487>MMLS 12.0(5)T or 5.3 of C6K or 5.1 of =
C5K</A></H3>
<P><A=20
href=3D"http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/1=
20newft/120t/120t5/ipmctmls.htm">http://www.cisco.com/univercd/cc/td/doc/=
product/software/ios120/120newft/120t/120t5/ipmctmls.htm</P></A>
<P><A=20
href=3D"http://www.cisco.com/univercd/cc/td/doc/product/lan/cat6000/sw_5_=
3/msfc/mcastmls.htm">http://www.cisco.com/univercd/cc/td/doc/product/lan/=
cat6000/sw_5_3/msfc/mcastmls.htm</P></A>
<P><A=20
href=3D"http://www.cisco.com/univercd/cc/td/doc/product/lan/cat5000/rel_5=
_1/config/mcastmls.htm">http://www.cisco.com/univercd/cc/td/doc/product/l=
an/cat5000/rel_5_1/config/mcastmls.htm</P></A>
<H3><A name=3Dxtocid488>MRM 12.0(5)T and 12.0(5)S</A></H3>
<P><A=20
href=3D"http://www/univercd/cc/td/doc/product/software/ios120/120newft/12=
0limit/120s/120s5/mrm.htm">http://www/univercd/cc/td/doc/product/software=
/ios120/120newft/120limit/120s/120s5/mrm.htm</P></A>
<P><A=20
href=3D"http://www/univercd/cc/td/doc/product/software/ios120/120newft/12=
0t/120t5/mrm.htm">http://www/univercd/cc/td/doc/product/software/ios120/1=
20newft/120t/120t5/mrm.htm</P></A>
<H3><A name=3Dxtocid489>MSDP 12.0(7)T</A></H3>
<P><A=20
href=3D"http://www/univercd/cc/td/doc/product/software/ios120/120newft/12=
0t/120t7/msdp.htm">http://www/univercd/cc/td/doc/product/software/ios120/=
120newft/120t/120t7/msdp.htm</P></A>
<H3><A name=3Dxtocid4810>MvoIP 12.1(3)T</A></H3>
<P><A=20
href=3D"http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/1=
21newft/121t/121t3/dtvmult3.htm">http://www.cisco.com/univercd/cc/td/doc/=
product/software/ios121/121newft/121t/121t3/dtvmult3.htm</P></A>
<H3><A name=3Dxtocid4811>PGM Features</A></H3>
<H4><A name=3Dxtocid4812>PGM Router Assist 12.0(5)T</A></H4>
<P><A=20
href=3D"http://www/univercd/cc/td/doc/product/software/ios120/120newft/12=
0t/120t5/pgmscale.htm">http://www/univercd/cc/td/doc/product/software/ios=
120/120newft/120t/120t5/pgmscale.htm</P></A>
<H4><A name=3Dxtocid4813>PGM Host 12.1(1)T</A></H4>
<P><A=20
href=3D"http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/1=
21newft/121t/121t1/dtpgmhst.htm">http://www.cisco.com/univercd/cc/td/doc/=
product/software/ios121/121newft/121t/121t1/dtpgmhst.htm</P></A>
<H3><A name=3Dxtocid4814>SSM 12.1(3)T</A></H3>
<P><A=20
href=3D"http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/1=
21newft/121t/121t3/dtssm.htm">http://www.cisco.com/univercd/cc/td/doc/pro=
duct/software/ios121/121newft/121t/121t3/dtssm.htm</P></A>
<H3><A name=3Dxtocid4815>UDLR 12.0(3)T.</A></H3>
<P><A=20
href=3D"http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/1=
20newft/120t/120t3/igmpudlr.htm">http://www.cisco.com/univercd/cc/td/doc/=
product/software/ios120/120newft/120t/120t3/igmpudlr.htm</P></A>
<H3><A name=3Dxtocid4816>CBOS commands</A></H3>
<P>The Cisco Broadband Operating System is modelled after Cisco's=20
Internetworking Operating System (IOS) and features a similar command =
syntax and=20
format.</P>
<H4><A name=3Dxtocid4817>Multicast proxy support (IGMP Proxy) Release=20
2.1.0</A></H4>
<P>This ability is also available in regular routers. As "ip igmp=20
helper-address"</P>
<P><A=20
href=3D"http://www.cisco.com/univercd/cc/td/doc/product/dsl_prod/c600s/cb=
os/cbo210rn.htm#xtocid54014">http://www.cisco.com/univercd/cc/td/doc/prod=
uct/dsl_prod/c600s/cbos/cbo210rn.htm#xtocid54014</P></A>
<P><A=20
href=3D"http://www.cisco.com/univercd/cc/td/doc/pcat/675.htm#BABIGDDF">ht=
tp://www.cisco.com/univercd/cc/td/doc/pcat/675.htm#BABIGDDF</P></A>
<P><A=20
href=3D"http://www.cisco.com/univercd/cc/td/doc/pcat/673.htm#BABJFAEJ">ht=
tp://www.cisco.com/univercd/cc/td/doc/pcat/673.htm#BABJFAEJ</P></A>
<H2><A name=3Dxtocid4818>Part 3--Multicast Documentation by =
Switch:</A></H2>
<H3><A name=3Dxtocid4819>1200: Not Mentioned</A></H3>
<P><A=20
href=3D"http://www/univercd/cc/td/doc/product/lan/catalyst/cat12icg/78656=
.htm#xtocid1019923">http://www/univercd/cc/td/doc/product/lan/catalyst/ca=
t12icg/78656.htm#xtocid1019923</P></A>
<H3><A name=3Dxtocid4820>1420/1220: Manual configuration</A></H3>
<P><A=20
href=3D"http://www/univercd/cc/td/doc/product/lan/14201220/14_1220u/csout=
b.htm#xtocid1901516">http://www/univercd/cc/td/doc/product/lan/14201220/1=
4_1220u/csoutb.htm#xtocid1901516</P></A>
<H3><A name=3Dxtocid4821>1548: Not mentioned</A></H3>
<P><A=20
href=3D"http://www/univercd/cc/td/doc/product/lan/ms1548m/cli/1548_cli.ht=
m">http://www/univercd/cc/td/doc/product/lan/ms1548m/cli/1548_cli.htm</P>=
</A>
<H3><A name=3Dxtocid4822>1900/2820: CGMP</A></H3>
<P><A=20
href=3D"http://www/univercd/cc/td/doc/product/lan/28201900/1928v9x/19icg9=
x/19icweb.htm#xtocid1273983">http://www/univercd/cc/td/doc/product/lan/28=
201900/1928v9x/19icg9x/19icweb.htm#xtocid1273983</P></A>
<P><A=20
href=3D"http://www/univercd/cc/td/doc/product/lan/28201900/1928v9x/28icg9=
x/28icoutb.htm#xtocid1786322">http://www/univercd/cc/td/doc/product/lan/2=
8201900/1928v9x/28icg9x/28icoutb.htm#xtocid1786322</P></A>
<H3><A name=3Dxtocid4823>2100: Manual configuration </A></H3>
<P><A=20
href=3D"http://www/univercd/cc/td/doc/product/lan/cat2100/c2100ug/csfo_bn=
d.htm#xtocid467915">http://www/univercd/cc/td/doc/product/lan/cat2100/c21=
00ug/csfo_bnd.htm#xtocid467915</P></A>
<H3><A name=3Dxtocid4824>2800: Manual configuration</A></H3>
<P><A=20
href=3D"http://www/univercd/cc/td/doc/product/lan/cat2800/fs28/fs28outb.h=
tm#xtocid2576515">http://www/univercd/cc/td/doc/product/lan/cat2800/fs28/=
fs28outb.htm#xtocid2576515</P></A>
<H3><A name=3Dxtocid4825>2900XL/3500XL: CGMP </A></H3>
<P><A=20
href=3D"http://www/univercd/cc/td/doc/product/lan/c2900xl/29_35xp/scg/kic=
onfig.htm#xtocid109398">http://www/univercd/cc/td/doc/product/lan/c2900xl=
/29_35xp/scg/kiconfig.htm#xtocid109398</P></A>
<H3><A name=3Dxtocid4826>2948G-L3: CGMP server and Constrained Multicast =
Flooding=20
(CMF) </A></H3>
<P><A=20
href=3D"http://www/univercd/cc/td/doc/product/l3sw/2948g-l3/rel_12_0/conf=
ig/net_prot.htm#xtocid224329">http://www/univercd/cc/td/doc/product/l3sw/=
2948g-l3/rel_12_0/config/net_prot.htm#xtocid224329</P></A>
<P>Note: Only 128 Multicast groups </P>
<H3><A name=3Dxtocid4827>5000,4000,2926G,2948G and 2980G: CGMP, =
IGMP-Snooping,=20
RGMP, GMRP</A></H3>
<P><A=20
href=3D"http://www/univercd/cc/td/doc/product/lan/cat5000/rel_5_4/config/=
multi.htm">http://www/univercd/cc/td/doc/product/lan/cat5000/rel_5_4/conf=
ig/multi.htm</P></A>
<P>Note: CGMP SW version 2.2, IGMP-snooping requires NFFC, GMRP requires =
SW=20
5.1</P>
<H3><A name=3Dxtocid4828>6000: IGMP-Snooping, RGMP, GMRP</A></H3>
<P><A=20
href=3D"http://www/univercd/cc/td/doc/product/lan/cat6000/sw_5_4/config/m=
ulti.htm">http://www/univercd/cc/td/doc/product/lan/cat6000/sw_5_4/config=
/multi.htm</P></A>
<H3><A name=3Dxtocid4829>8500: CMF</A></H3>
<P><A=20
href=3D"http://www/univercd/cc/td/doc/product/l3sw/8540/rel_12_0/w5_6e/so=
ftcnfg/4cfg8500.htm#xtocid612722">http://www/univercd/cc/td/doc/product/l=
3sw/8540/rel_12_0/w5_6e/softcnfg/4cfg8500.htm#xtocid612722</P></A>
<H2><A name=3Dxtocid4830>Part 4--Glossary</A></H2>
<P>Bi-Dir PIM:</P>
<P>Bi-directional PIM creates a single forwarding tree that allows data =
to flow=20
both up and down the tree. This is useful for reducing state in =
routers.</P>
<P>CGMP:</P>
<P>Cisco Group Management Protocol. This is a Cisco proprietary =
protocol. It was=20
designed to enable a Router to inform a Switch that a port associated =
with a=20
particular Unicast MAC address requires a Multicast MAC address to be =
added.=20
CGMP enables switches without the hardware to support IGMP-snooping to =
constrain=20
Multicast data.</P>
<P>CMF:</P>
<P>Constrained Multicast Flooding is a CISCO IOS method to perform =
IGMP-snooping=20
This was created for Cisco IOS L3 Switches.</P>
<P>GMRP:</P>
<P>GARP Multicast Registration Protocol. This is a extension to the GARP =
protocol and requires that the Host NIC card inform the GMRP enabled =
Switch=20
which group it requires data from. GARP is a layer 2 protocol and so =
only=20
implemented on Switches and Host NIC cards. </P>
<P>IGMP:</P>
<P>Internet Group management Protocol as defined in RFC 1112 and 2236. =
At=20
present there are two version of IGMP. IGMP version 2 incorporates fast =
leave=20
capability.</P>
<P>IGMP-snooping:</P>
<P>This is not a standard, it is a methodology for switches to intercept =
IGMP=20
host reports. If this is implemented In hardware it has no impact on=20
performance. However if this is implemented in Software then performance =
of the=20
switch can be expected to decrease.</P>
<P>MBGP:</P>
<P>Multi-protocol BGP This enables BGP to carry routing information for =
multiple=20
Network Layer protocols EG IPv6, IPX, etc. It can also carry routing =
information=20
for Multicast Data. This Allows the use non-congruent multicast and =
unicast=20
topologies.</P>
<P>MDS/MDFS:</P>
<P>Multicast Distributed Fast Switching. This provides support for =
distributed=20
switching of multicast packets on VIPs in Cisco-75xx and on line cards =
in the=20
Cisco-12xx.</P>
<P>Multicast proxy/IGMP Proxy:</P>
<P>This feature is also available in regular routers as "ip igmp=20
helper-address."</P>
<P>MMLS:</P>
<P>Multicast Multi Layer Switching. This is hardware based ASIC, Layer 3 =
switching of IP multicast traffic.</P>
<P>MRM:</P>
<P>The Multicast Reach-ability Monitor. This feature provides a Traffic=20
Generator, Receiver and Management function. MRM utilizes RTCP data to =
verify IP=20
Multicast data delivery throughout the network.</P>
<P>MSDP:</P>
<P>Multicast Source Discovery Protocol. This is a protocol to enable =
RP's to=20
inform each other of active sources (SA) they are aware of. </P>
<P>MVoip:</P>
<P>Cisco MVoIP (Multicast Voice over IP), is used as a replacement for =
the=20
traditional `Hoot and Holler' networks used in brokerage firms. Hoot and =
Holler=20
systems provide continuous voice conference functionality between remote =
sites.=20
</P>
<P>PGM:</P>
<P>Pragmatic General Multicast. This is a reliable multicast transport =
protocol.=20
Routers with the router assist function enabled become involved in the =
efficient=20
re-delivery of PGM data. The router only keeps track of which interfaces =
need to=20
receive re-transmitted data, they do NOT cache data.</P>
<P>RGMP:</P>
<P>RouterPort Group Management Protocol This Protocol is designed to =
prevent=20
unwanted IP Multicast traffic from being sent to Multicast routers who =
have no=20
requirement for it. It operates with PIM-SM only and requires both the =
Switch=20
and the router to Support RGMP.</P>
<P>SSM:</P>
<P>Source Specific Multicast allows a hosts to explicitly define which =
sources=20
it is interested in when joining a multicast group. IGMP v3, URL =
Rendezvous=20
Directory (URD) and IGMP v3lite can all be used with SSM.</P>
<P>UDLR:</P>
<P>Unidirectional link routing. This provides a way to forward multicast =
packets=20
over a physical unidirectional interface (such as a satellite link of =
high=20
bandwidth) to stub networks that have a back channel. </P>
<P>UDLR-Tunnels:</P>
<P>Applies to unicast and multicast has limited scalability.</P>
<P></P>
<P>IGMP-UDLR:</P>
<P>Applies to multicast only, the preferred method.</P><BR>
<P><A =
href=3D"http://www.cisco.com/warp/partner/synchronicd/home/home.htm"><IMG=
=20
alt=3Dhome border=3D0 height=3D21 src=3D"Cisco Multicast Support =
Matrix_files/home.gif"=20
width=3D72></A><A=20
href=3D"http://www.cisco.com/warp/partner/synchronicd/cc/pd/iosw/tech/ind=
ex.htm"><IMG=20
alt=3Dtoc border=3D0 height=3D21 src=3D"Cisco Multicast Support =
Matrix_files/toc.gif"=20
width=3D72></A><A=20
href=3D"http://www.cisco.com/warp/partner/synchronicd/cc/pd/iosw/tech/tel=
cs_ds.htm"><IMG=20
alt=3Dprev border=3D0 height=3D21 src=3D"Cisco Multicast Support =
Matrix_files/prev.gif"=20
width=3D72></A><A=20
href=3D"http://www.cisco.com/warp/partner/synchronicd/cc/pd/iosw/tech/ted=
cn_wp.htm"><IMG=20
alt=3Dnext border=3D0 height=3D21 src=3D"Cisco Multicast Support =
Matrix_files/next.gif"=20
width=3D72></A><A=20
href=3D"http://www.cisco.com/warp/partner/synchronicd/cc/pd/iosw/tech/mcm=
m_rg.pdf"><IMG=20
alt=3Dpdf border=3D0 height=3D21 src=3D"Cisco Multicast Support =
Matrix_files/pdf.gif"=20
width=3D72></A><A=20
href=3D"http://www.cisco.com/warp/partner/synchronicd/home/search.htm"><I=
MG=20
alt=3Dsearch border=3D0 height=3D21=20
src=3D"Cisco Multicast Support Matrix_files/search.gif" =
width=3D72></A><A=20
href=3D"http://www.cisco.com/warp/partner/synchronicd/cc/lib/help.htm"><I=
MG=20
alt=3Dhelp border=3D0 height=3D21 src=3D"Cisco Multicast Support =
Matrix_files/help.gif"=20
width=3D72></A><BR><BR>Posted: Mon Aug 21 14:34:09 PDT 2000 <BR><A=20
href=3D"http://www.cisco.com/warp/partner/synchronicd/cc/lib/copyrght.htm=
">Copyright=20
1989-2000</A>=A9<A href=3D"http://www.cisco.com/">Cisco Systems Inc.</A> =
</P></BODY></HTML>
------=_NextPart_000_000A_01C0F00B.99EFF400--
>From owner-rmt@listserv.lbl.gov Mon Jun 11 03:55:09 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f5BAk0q07147;
Mon, 11 Jun 2001 03:46:00 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f5BAjx107143
for <rmt@listserv.lbl.gov>; Mon, 11 Jun 2001 03:45:59 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f5BAjw526088
for <rmt@listserv.lbl.gov>; Mon, 11 Jun 2001 03:45:58 -0700 (PDT)
Received: from marratech.com (habanero.marratech.com [195.196.47.9] (may be forged))
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f5BAjv626085
for <rmt@lbl.gov>; Mon, 11 Jun 2001 03:45:57 -0700 (PDT)
Received: from cdt.luth.se (dhcp025.lulea.marratech.com [195.196.47.25])
by marratech.com (8.9.3/8.9.3) with ESMTP id MAA31587;
Mon, 11 Jun 2001 12:45:39 +0200 (CEST)
Message-ID: <3B24A210.5276F01F@cdt.luth.se>
Date: Mon, 11 Jun 2001 12:48:48 +0200
From: Jeremiah Scholl <Jeremiah@cdt.luth.se>
Reply-To: jeremiah@cdt.luth.se
X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: rmt@lbl.gov, peppar@cdt.luth.se
Subject: PGMCC and unicast
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-rmt@lbl.gov
Precedence: bulk
I have a question for the group regarding the Internet-Draft for PGMCC
that you has submitted for standardization. In PGMCC "the acker"
(worst-case receiver) sends out an ack for each data packet received and
the sender uses this information to adjust its send rate. The
internet-draft for PGMCC does not specify if acks are unicast to the
sender or if it is acceptable to multicast them to the entire group.
This question is in regards to a joint project between Luleå Techinical
University and Marratech AB. Marratech is an emeetings software company
and the engineers here feel that due to the use of firewalls, it is not
realistic to assume that unicast connections will be available when
deploying their products on the Internet. Some clarification on this
point would be helpfull.
Thanks,
Jeremiah
>From owner-rmt@listserv.lbl.gov Mon Jun 11 14:48:07 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f5BLl9A10873;
Mon, 11 Jun 2001 14:47:09 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f5BLl7110869
for <rmt@listserv.lbl.gov>; Mon, 11 Jun 2001 14:47:07 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f5BLl7W02297
for <rmt@listserv.lbl.gov>; Mon, 11 Jun 2001 14:47:07 -0700 (PDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f5BLl5602290
for <rmt@lbl.gov>; Mon, 11 Jun 2001 14:47:05 -0700 (PDT)
Received: from lorenzo-u10.cisco.com (lorenzo-u10.cisco.com [128.107.162.143])
by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5BLko915722;
Mon, 11 Jun 2001 14:46:50 -0700 (PDT)
Received: from localhost (lorenzo@localhost) by lorenzo-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id OAA01182; Mon, 11 Jun 2001 14:46:50 -0700 (PDT)
Message-Id: <200106112146.OAA01182@lorenzo-u10.cisco.com>
X-Authentication-Warning: lorenzo-u10.cisco.com: lorenzo owned process doing -bs
X-Mailer: exmh version 2.3.1 01/18/2001 with version: MH 6.8.4 #29[UCI]
To: jeremiah@cdt.luth.se
cc: rmt@lbl.gov, peppar@cdt.luth.se, luigi@iet.inipi.it
Subject: Re: PGMCC and unicast
In-Reply-To: Your message of "Mon, 11 Jun 2001 12:48:48 +0200."
<3B24A210.5276F01F@cdt.luth.se>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Date: Mon, 11 Jun 2001 14:46:50 -0700
From: Lorenzo Vicisano <lorenzo@cisco.com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by SpamWall.lbl.gov id f5BLl8110870
Sender: owner-rmt@lbl.gov
Precedence: bulk
Jeremiah,
In message <3B24A210.5276F01F@cdt.luth.se>,
Jeremiah Scholl writes:
> I have a question for the group regarding the Internet-Draft for PGMCC
> that you has submitted for standardization. In PGMCC "the acker"
> (worst-case receiver) sends out an ack for each data packet received and
> the sender uses this information to adjust its send rate. The
> internet-draft for PGMCC does not specify if acks are unicast to the
> sender or if it is acceptable to multicast them to the entire group.
the assumption in the draft is that ACKs are sent unicast and
we should make it clear if it currently isn't.
Although there might be potential advantages in multicasting
them to the entire session, I don't think that these pay off
for the added overhead (i.e. significant amount of added traffic).
Furthermore, a criteria defined in RMT is that protocols should
work without multicast feedback, if possible. This requirement
comes from network infrastructure consideration (e.g. some
IP multicast protocol, like SSM, are asymmetric).
>
> This question is in regards to a joint project between Luleå Techinical
> University and Marratech AB. Marratech is an emeetings software company
> and the engineers here feel that due to the use of firewalls, it is not
> realistic to assume that unicast connections will be available when
> deploying their products on the Internet. Some clarification on this
> point would be helpfull.
Are you suggesting that potential PGM-receivers will be able to source
multicast but will not be able to send unicast, or are you talking about
the source-side ?
thanks,
Lorenzo
>From owner-rmt@listserv.lbl.gov Mon Jun 11 15:18:43 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f5BMISX10940;
Mon, 11 Jun 2001 15:18:28 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f5BMIR110936
for <rmt@listserv.lbl.gov>; Mon, 11 Jun 2001 15:18:27 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f5BMIQG14291
for <rmt@listserv.lbl.gov>; Mon, 11 Jun 2001 15:18:26 -0700 (PDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f5BMIO614283
for <rmt@lbl.gov>; Mon, 11 Jun 2001 15:18:24 -0700 (PDT)
Received: from lorenzo-u10.cisco.com (lorenzo-u10.cisco.com [128.107.162.143])
by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5BMHe910934;
Mon, 11 Jun 2001 15:17:40 -0700 (PDT)
Received: from localhost (lorenzo@localhost) by lorenzo-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id PAA01273; Mon, 11 Jun 2001 15:17:35 -0700 (PDT)
Message-Id: <200106112217.PAA01273@lorenzo-u10.cisco.com>
X-Authentication-Warning: lorenzo-u10.cisco.com: lorenzo owned process doing -bs
X-Mailer: exmh version 2.3.1 01/18/2001 with version: MH 6.8.4 #29[UCI]
to: jeremiah@cdt.luth.se
cc: rmt@lbl.gov, peppar@cdt.luth.se, luigi@iet.unipi.it
Subject: Re: PGMCC and unicast
In-Reply-To: Your message of "Mon, 11 Jun 2001 14:46:50 PDT."
<200106112146.OAA01182@lorenzo-u10.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Date: Mon, 11 Jun 2001 15:17:35 -0700
From: Lorenzo Vicisano <lorenzo@cisco.com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by SpamWall.lbl.gov id f5BMIR110937
Sender: owner-rmt@lbl.gov
Precedence: bulk
[resending with correct address list]
In message <200106112146.OAA01182@lorenzo-u10.cisco.com>,
Lorenzo Vicisano writes:
> Jeremiah,
>
> In message <3B24A210.5276F01F@cdt.luth.se>,
> Jeremiah Scholl writes:
> > I have a question for the group regarding the Internet-Draft for PGMCC
> > that you has submitted for standardization. In PGMCC "the acker"
> > (worst-case receiver) sends out an ack for each data packet received and
> > the sender uses this information to adjust its send rate. The
> > internet-draft for PGMCC does not specify if acks are unicast to the
> > sender or if it is acceptable to multicast them to the entire group.
>
> the assumption in the draft is that ACKs are sent unicast and
> we should make it clear if it currently isn't.
> Although there might be potential advantages in multicasting
> them to the entire session, I don't think that these pay off
> for the added overhead (i.e. significant amount of added traffic).
> Furthermore, a criteria defined in RMT is that protocols should
> work without multicast feedback, if possible. This requirement
> comes from network infrastructure consideration (e.g. some
> IP multicast protocol, like SSM, are asymmetric).
>
> >
> > This question is in regards to a joint project between Luleå Techinical
> > University and Marratech AB. Marratech is an emeetings software company
> > and the engineers here feel that due to the use of firewalls, it is not
> > realistic to assume that unicast connections will be available when
> > deploying their products on the Internet. Some clarification on this
> > point would be helpfull.
>
> Are you suggesting that potential PGM-receivers will be able to source
> multicast but will not be able to send unicast, or are you talking about
> the source-side ?
>
> thanks,
> Lorenzo
>From owner-rmt@listserv.lbl.gov Mon Jun 11 15:33:23 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f5BMXGt10968;
Mon, 11 Jun 2001 15:33:16 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f5BMXF110964
for <rmt@listserv.lbl.gov>; Mon, 11 Jun 2001 15:33:15 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f5BMXEA18947
for <rmt@listserv.lbl.gov>; Mon, 11 Jun 2001 15:33:14 -0700 (PDT)
Received: from info.iet.unipi.it (info.iet.unipi.it [131.114.9.184])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f5BMXD618942
for <rmt@lbl.gov>; Mon, 11 Jun 2001 15:33:13 -0700 (PDT)
Received: (from luigi@localhost)
by info.iet.unipi.it (8.9.3/8.9.3) id AAA79639;
Tue, 12 Jun 2001 00:28:56 +0200 (CEST)
(envelope-from luigi)
From: Luigi Rizzo <luigi@info.iet.unipi.it>
Message-Id: <200106112228.AAA79639@info.iet.unipi.it>
Subject: Re: PGMCC and unicast
In-Reply-To: <200106112217.PAA01273@lorenzo-u10.cisco.com> from Lorenzo Vicisano
at "Jun 11, 2001 03:17:35 pm"
To: Lorenzo Vicisano <lorenzo@cisco.com>
Date: Tue, 12 Jun 2001 00:28:56 +0200 (CEST)
CC: jeremiah@cdt.luth.se, rmt@lbl.gov, peppar@cdt.luth.se, luigi@iet.unipi.it
X-Mailer: ELM [version 2.4ME+ PL61 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-rmt@lbl.gov
Precedence: bulk
As Lorenzo said, ACKs are supposed to be unicast to the sender.
I cannot see any advantage in multicasting them to the session
(they cannot be used to elicit feedback from potential ackets,
because in PGMCC the receivers do not have an RTT estimate).
As for the firewall issue: I am unclear on what is your point when you say
> and the engineers here feel that due to the use of firewalls, it is not
> realistic to assume that unicast connections will be available when
> deploying their products on the Internet.
do you really mean unicast ?
If you are afraid that netadmins are blindly blocking traffic and you
have no input on what services to let through, then your
only option is probably to encapsulate everything into
UDP packets on port 53 (DNS) ...
But if you want to use PGM, you need to tell the netadmin "listen,
i need protocol 113 to get through, and bidirectional connectivity
(for NAKs), at which point asking unicast is the least of your
worries.
cheers
luigi
> > In message <3B24A210.5276F01F@cdt.luth.se>,
> > Jeremiah Scholl writes:
> > > I have a question for the group regarding the Internet-Draft for PGMCC
> > > that you has submitted for standardization. In PGMCC "the acker"
-----------------------------------+-------------------------------------
Luigi RIZZO, luigi@iet.unipi.it . Dip. di Ing. dell'Informazione
http://www.iet.unipi.it/~luigi/ . Universita` di Pisa
TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy)
Mobile +39-347-0373137
-----------------------------------+-------------------------------------
>From owner-rmt@listserv.lbl.gov Tue Jun 12 01:12:19 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f5C8B6i11849;
Tue, 12 Jun 2001 01:11:06 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f5C8B4111845
for <rmt@listserv.lbl.gov>; Tue, 12 Jun 2001 01:11:04 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f5C8B4k17369
for <rmt@listserv.lbl.gov>; Tue, 12 Jun 2001 01:11:04 -0700 (PDT)
Received: from marratech.com (habanero.marratech.com [195.196.47.9] (may be forged))
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f5C8B2617361
for <rmt@lbl.gov>; Tue, 12 Jun 2001 01:11:03 -0700 (PDT)
Received: from cdt.luth.se (dhcp025.lulea.marratech.com [195.196.47.25])
by marratech.com (8.9.3/8.9.3) with ESMTP id KAA42745
for <rmt@lbl.gov>; Tue, 12 Jun 2001 10:10:55 +0200 (CEST)
Message-ID: <3B25CF4F.6F930370@cdt.luth.se>
Date: Tue, 12 Jun 2001 10:14:07 +0200
From: Jeremiah Scholl <jeremiah@cdt.luth.se>
X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: rmt@lbl.gov
Subject: Re: PGMCC and unicast
References: <200106112228.AAA79639@info.iet.unipi.it>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-rmt@lbl.gov
Precedence: bulk
I am asking these questions in regard to using PGMCC with SRM like protocols or
more specifically NORM once it is standardized, not for use in conjunction with
PGM. Marratech would like to make sure that it will be able to use the
standardized NACK based protocol and standardized congestion control scheme that
will accompany it.
I proposed my question to the group because if PGMCC uses unicast we feel that
it will not be compatible with Marratech's products. This is due to hosts often
being on different networks with firewalls inbetween them. So, we will need an
additional congestion control scheme to be standardized for use with NORM.
I do have an idea for a solution to this problem and would really like some
feedback from the group regarding it. PGMCC has the receiver unicast acks in
order to get a more complete set of which packets are lost by the worst-case
receiver. This information is not available in SRM due to the use of
suppression timers. However, this same information can be made available to the
sender in SRM by having the designated worst-case receiver stop using these
suppression timers. All other receivers would still use suppression timers like
normal and would have their NACKs suppressed.
This solution has the benifit that it is low-weight and will also lead to faster
recovery times for packets that are lost by the worst-case receiver. Since
there will only be one worst-case receiver at any given time it should not lead
to more redundant NACKs than SRM does. I realize that the solution does require
us to wonder a bit away from the origional SRM framework so I would really like
some comments on it.
Can anyone give me a reason why this solution would not work? Some thoughts
would be nice.
Jeremiah
Luigi Rizzo wrote:
> As Lorenzo said, ACKs are supposed to be unicast to the sender.
> I cannot see any advantage in multicasting them to the session
> (they cannot be used to elicit feedback from potential ackets,
> because in PGMCC the receivers do not have an RTT estimate).
>
> As for the firewall issue: I am unclear on what is your point when you say
>
> > and the engineers here feel that due to the use of firewalls, it is not
> > realistic to assume that unicast connections will be available when
> > deploying their products on the Internet.
>
> do you really mean unicast ?
>
> If you are afraid that netadmins are blindly blocking traffic and you
> have no input on what services to let through, then your
> only option is probably to encapsulate everything into
> UDP packets on port 53 (DNS) ...
>
> But if you want to use PGM, you need to tell the netadmin "listen,
> i need protocol 113 to get through, and bidirectional connectivity
> (for NAKs), at which point asking unicast is the least of your
> worries.
>
> cheers
> luigi
>
> > > In message <3B24A210.5276F01F@cdt.luth.se>,
> > > Jeremiah Scholl writes:
> > > > I have a question for the group regarding the Internet-Draft for PGMCC
> > > > that you has submitted for standardization. In PGMCC "the acker"
>
> -----------------------------------+-------------------------------------
> Luigi RIZZO, luigi@iet.unipi.it . Dip. di Ing. dell'Informazione
> http://www.iet.unipi.it/~luigi/ . Universita` di Pisa
> TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy)
> Mobile +39-347-0373137
> -----------------------------------+-------------------------------------
>From owner-rmt@listserv.lbl.gov Tue Jun 12 04:04:53 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f5CB21l12025;
Tue, 12 Jun 2001 04:02:01 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f5CB1x112021
for <rmt@listserv.lbl.gov>; Tue, 12 Jun 2001 04:01:59 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f5CB1w600073
for <rmt@listserv.lbl.gov>; Tue, 12 Jun 2001 04:01:58 -0700 (PDT)
Received: from info.iet.unipi.it (info.iet.unipi.it [131.114.9.184])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f5CB1v600070
for <rmt@lbl.gov>; Tue, 12 Jun 2001 04:01:57 -0700 (PDT)
Received: (from luigi@localhost)
by info.iet.unipi.it (8.9.3/8.9.3) id MAA83432;
Tue, 12 Jun 2001 12:57:42 +0200 (CEST)
(envelope-from luigi)
From: Luigi Rizzo <luigi@info.iet.unipi.it>
Message-Id: <200106121057.MAA83432@info.iet.unipi.it>
Subject: Re: PGMCC and unicast
In-Reply-To: <3B25CF4F.6F930370@cdt.luth.se> from Jeremiah Scholl at "Jun 12,
2001 10:14:07 am"
To: Jeremiah Scholl <jeremiah@cdt.luth.se>
Date: Tue, 12 Jun 2001 12:57:42 +0200 (CEST)
CC: rmt@lbl.gov
X-Mailer: ELM [version 2.4ME+ PL61 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-rmt@lbl.gov
Precedence: bulk
Jeremiah,
i think you are addressing a few different issues in this msg.
First one is "what kind of connectivity should we assume between
source(s) and receiver(s) in NORM protocols."
The (hidden) assumption in PGMCC is to have multicast downstream, and
unicast upstream (plus optional multicast on the LAN, but only for nak
suppression purposes).
I think this is one of the least restrictive assumption you can
make on availability of service. My feeling is that over time it
will be less likely to have multicast in both directions (e.g.
because of SSM, or asymmetric nets with satellite downlink and
phone uplink, etc.).
Of course you can tunnel your ACKs using whatever transport you
have available, including multicast -- basically this is what you
propose in the second part of your msg. You might lose some efficiency
in the process, and put a lot more state in the net, but if you
have no better alternative, what else you can do.
Second issue is your proposal of using immediate feedback to trigger
retransmissions. I think in some cases it might be better to wait
a bit (which is a side effect of sending repairs in response to
delayed NAKs).
Examples:
+ in a context (such as PGM) where you have nodes doing selective
forwarding, you want to retransmit only after receivers have had a
chance to send out their NAKs (and install state in the filtering nodes).
+ if you use FEC-based repairs, you might want to count the amount of
lost packets to select the most appropriate FEC parameters (block
size, number of repair blocks, etc);
+ you still need to handle reordering in packet arrivals; using delayed
NAKs frees you from counting N dup-acks for retransmission purposes.
Third one: you say
> PGMCC has the receiver unicast acks in
> order to get a more complete set of which packets are lost by the worst-case
> receiver.
not exactly. Those acks really carry throughput estimates, and
"tokens" to trigger the transmission of new traffic. They are not
(meant to be) used at all for data integrity purposes.
cheers
luigi
-----------------------------------+-------------------------------------
Luigi RIZZO, luigi@iet.unipi.it . Dip. di Ing. dell'Informazione
http://www.iet.unipi.it/~luigi/ . Universita` di Pisa
TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy)
Mobile +39-347-0373137
-----------------------------------+-------------------------------------
>From owner-rmt@listserv.lbl.gov Tue Jun 12 04:20:15 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f5CBJns12104;
Tue, 12 Jun 2001 04:19:49 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f5CBJl112100
for <rmt@listserv.lbl.gov>; Tue, 12 Jun 2001 04:19:47 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f5CBJlO01754
for <rmt@listserv.lbl.gov>; Tue, 12 Jun 2001 04:19:47 -0700 (PDT)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
by SpamWall.lbl.gov (8.11.2/8.11.2) with SMTP id f5CBJj601750
for <rmt@lbl.gov>; Tue, 12 Jun 2001 04:19:46 -0700 (PDT)
Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP
id <g.17190-0@bells.cs.ucl.ac.uk>; Tue, 12 Jun 2001 12:19:22 +0100
To: Luigi Rizzo <luigi@info.iet.unipi.it>
cc: Jeremiah Scholl <jeremiah@cdt.luth.se>, rmt@lbl.gov,
J.Crowcroft@cs.ucl.ac.uk
Subject: Re: PGMCC and unicast
In-reply-to: Your message of "Tue, 12 Jun 2001 12:57:42 +0200." <200106121057.MAA83432@info.iet.unipi.it>
Date: Tue, 12 Jun 2001 12:19:22 +0100
Message-ID: <17309.992344762@cs.ucl.ac.uk>
From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
Sender: owner-rmt@lbl.gov
Precedence: bulk
In message <200106121057.MAA83432@info.iet.unipi.it>, Luigi Rizzo typed:
>>i think you are addressing a few different issues in this msg.
>>First one is "what kind of connectivity should we assume between
>>source(s) and receiver(s) in NORM protocols."
>>The (hidden) assumption in PGMCC is to have multicast downstream, and
>>unicast upstream (plus optional multicast on the LAN, but only for nak
>>suppression purposes).
>>I think this is one of the least restrictive assumption you can
>>make on availability of service. My feeling is that over time it
>>will be less likely to have multicast in both directions (e.g.
>>because of SSM, or asymmetric nets with satellite downlink and
>>phone uplink, etc.).
>>Of course you can tunnel your ACKs using whatever transport you
>>have available, including multicast -- basically this is what you
>>propose in the second part of your msg. You might lose some efficiency
>>in the process, and put a lot more state in the net, but if you
>>have no better alternative, what else you can do.
of course, in a genuine shared media net, it might make a lot of sense
to multicast acks - it seems like it ought to be an option, but i
agree 100% it is likely to be the exception
jeremiah:
also, in the case of firewalls, NATs etc, the chances are that
multicast is MORE likely to be blocked first, and let through latest,
rather than unicast, so i dont see the marratech objection here really
finally, all the RMT work has moved away from SRM, temporarily, since
we couldn't figure out congestion control for multiple sources, and
several people of "importance" claimed that "there were'nt any
compelling multiple source applications anyhow" :-)
its not clear why having the PGMCC acker send data to all sources
means much for a multiple sender session- if each source independantly
adjusts its rate in a TCP-friendly way, you get the right effect, and
given most delivery trees for steady traffic are going to be source based,
they wont necessarily share bottlenecks very often
(except perhaps at the receivers themselves)
if you want to devise some applicatio nlayer rule about how to
_couple_ the sending rates for a multi-sender applciation, then thats
fine, but i dont see that it should be wired into the transport layer
congestion control in anyway - it can easily be done as a higher layer
policy, distributed in a session management protocol,
and weighted into the rate computaton of PGMCC at each source
>>Second issue is your proposal of using immediate feedback to trigger
>>retransmissions. I think in some cases it might be better to wait
>>a bit (which is a side effect of sending repairs in response to
>>delayed NAKs).
>>
>>Examples:
>> + in a context (such as PGM) where you have nodes doing selective
>> forwarding, you want to retransmit only after receivers have had a
>> chance to send out their NAKs (and install state in the filtering nodes).
>>
>> + if you use FEC-based repairs, you might want to count the amount of
>> lost packets to select the most appropriate FEC parameters (block
>> size, number of repair blocks, etc);
>>
>> + you still need to handle reordering in packet arrivals; using delayed
>> NAKs frees you from counting N dup-acks for retransmission purposes.
>>
>>Third one: you say
>>
>>> PGMCC has the receiver unicast acks in
>>> order to get a more complete set of which packets are lost by the worst-case
>>> receiver.
>>
>>not exactly. Those acks really carry throughput estimates, and
>>"tokens" to trigger the transmission of new traffic. They are not
>>(meant to be) used at all for data integrity purposes.
>>
>> cheers
>> luigi
>>-----------------------------------+-------------------------------------
>> Luigi RIZZO, luigi@iet.unipi.it . Dip. di Ing. dell'Informazione
>> http://www.iet.unipi.it/~luigi/ . Universita` di Pisa
>> TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy)
>> Mobile +39-347-0373137
>>-----------------------------------+-------------------------------------
cheers
jon
>From owner-rmt@listserv.lbl.gov Tue Jun 12 08:12:53 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f5CFBJM13718;
Tue, 12 Jun 2001 08:11:20 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f5CFBI113714
for <rmt@listserv.lbl.gov>; Tue, 12 Jun 2001 08:11:18 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f5CFBI303345
for <rmt@listserv.lbl.gov>; Tue, 12 Jun 2001 08:11:18 -0700 (PDT)
Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f5CFBH603342
for <rmt@lbl.gov>; Tue, 12 Jun 2001 08:11:17 -0700 (PDT)
Received: from [132.250.92.151] (manimac.itd.nrl.navy.mil [132.250.92.151])
by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id LAA05871;
Tue, 12 Jun 2001 11:10:56 -0400 (EDT)
Mime-Version: 1.0
X-Sender: adamson@pop.itd.nrl.navy.mil
Message-Id: <p0501041db74bce150274@[132.250.92.151]>
In-Reply-To: <3B25CF4F.6F930370@cdt.luth.se>
References: <200106112228.AAA79639@info.iet.unipi.it>
<3B25CF4F.6F930370@cdt.luth.se>
Date: Tue, 12 Jun 2001 11:10:57 -0400
To: Jeremiah Scholl <jeremiah@cdt.luth.se>
From: Brian Adamson <adamson@itd.nrl.navy.mil>
Subject: Re: PGMCC and unicast
Cc: rmt@lbl.gov
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-rmt@lbl.gov
Precedence: bulk
With MDP, we have had networks where _only_ unicast feedback was
possible _and_ we have had networks where _only_ multicast feedback
has been possible so options exist to force all-unicast or
all-multicast feedback from receivers ... By default, ACKS are
unicast and NACKs tend to be multicast ... Although we _have_ now
implemented NACK suppression for unicast feedback with suppression
performance comparable to multicast NACK feedback suppression at the
cost of an additional RTT delay (and for some topologies or multicast
routing protocols (e.g. shared-tree) there may not be much difference
at all)
In the TFRC-like congestion control we have implemented in MDP, we do
something like what you describe below ... A small subset of
candidate worst-case receivers provide feedback (to congestion
control probes interlaced with the senders' data transmissions) with
no suppression timing ... (The sender adjusts its rate according to
_the_ worst case receiver - we're still investigation the value of
keeping congestion control state for multiple representatives instead
of one as per PGMCC) ... As Luigi note for PGMCC, this does work
independently of the reliability process although we do also
piggy-back congestion control feedback (RTT, loss estimation
feedback) on NACK messages ...
I have considered NACK suppression schemes where the receivers'
history of NACKing may weight their probability of NACKing to a
shorter backoff time (or possibly none at all as you describe below)
... There is some danger in this (though some may be mitigated by the
sender advertising the current designated zero-delay "nackers) ...
However, in our experience on the MBONE, the statistics of loss don't
appear to be stationary ... i.e. there doesn't seem to be much
correlation between being the worst-case NACKer from one time period
to the next ... this is probably not well understood for networks
with lots of dynamic congestion-controlled flows either ... in
congestion-control simulations we have done over topologies with
multiple possible bottleneck and ongoing background flows and
dynamically starting/stopping TCP/MDP flows, we tend to see dynamics
in where the worst-case loss is occurring at any moment in time ...
but we've had luck with the congestion-control being relatively
stable I think since the loss interval is averaged over multiple
intervals, each being multiple RTT in general ...
At 10:14 AM +0200 6/12/01, Jeremiah Scholl wrote:
>I am asking these questions in regard to using PGMCC with SRM like
>protocols or
>more specifically NORM once it is standardized, not for use in
>conjunction with
>PGM. Marratech would like to make sure that it will be able to use the
>standardized NACK based protocol and standardized congestion control
>scheme that
>will accompany it.
>
>I proposed my question to the group because if PGMCC uses unicast we feel that
>it will not be compatible with Marratech's products. This is due to
>hosts often
>being on different networks with firewalls inbetween them. So, we
>will need an
>additional congestion control scheme to be standardized for use with NORM.
>
>I do have an idea for a solution to this problem and would really like some
>feedback from the group regarding it. PGMCC has the receiver unicast acks in
>order to get a more complete set of which packets are lost by the worst-case
>receiver. This information is not available in SRM due to the use of
>suppression timers. However, this same information can be made
>available to the
>sender in SRM by having the designated worst-case receiver stop using these
>suppression timers. All other receivers would still use suppression
>timers like
>normal and would have their NACKs suppressed.
>
>This solution has the benifit that it is low-weight and will also
>lead to faster
>recovery times for packets that are lost by the worst-case receiver. Since
>there will only be one worst-case receiver at any given time it
>should not lead
>to more redundant NACKs than SRM does. I realize that the solution
>does require
>us to wonder a bit away from the origional SRM framework so I would
>really like
>some comments on it.
>
>Can anyone give me a reason why this solution would not work? Some thoughts
>would be nice.
>
>Jeremiah
>
>Luigi Rizzo wrote:
>
>> As Lorenzo said, ACKs are supposed to be unicast to the sender.
>> I cannot see any advantage in multicasting them to the session
>> (they cannot be used to elicit feedback from potential ackets,
>> because in PGMCC the receivers do not have an RTT estimate).
>>
>> As for the firewall issue: I am unclear on what is your point when you say
>>
>> > and the engineers here feel that due to the use of firewalls, it is not
>> > realistic to assume that unicast connections will be available when
>> > deploying their products on the Internet.
>>
>> do you really mean unicast ?
>>
>> If you are afraid that netadmins are blindly blocking traffic and you
>> have no input on what services to let through, then your
>> only option is probably to encapsulate everything into
>> UDP packets on port 53 (DNS) ...
>>
>> But if you want to use PGM, you need to tell the netadmin "listen,
>> i need protocol 113 to get through, and bidirectional connectivity
>> (for NAKs), at which point asking unicast is the least of your
>> worries.
>>
>> cheers
>> luigi
>>
>> > > In message <3B24A210.5276F01F@cdt.luth.se>,
>> > > Jeremiah Scholl writes:
>> > > > I have a question for the group regarding the Internet-Draft for PGMCC
>> > > > that you has submitted for standardization. In PGMCC "the acker"
>>
>> -----------------------------------+-------------------------------------
>> Luigi RIZZO, luigi@iet.unipi.it . Dip. di Ing. dell'Informazione
>> http://www.iet.unipi.it/~luigi/ . Universita` di Pisa
>> TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy)
>> Mobile +39-347-0373137
>> -----------------------------------+-------------------------------------
--
Brian
__________________________________
Brian Adamson
<http://manimac.itd.nrl.navy.mil>
<mailto:adamson@itd.nrl.navy.mil>
>From owner-rmt@listserv.lbl.gov Tue Jun 12 15:51:32 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f5CMokL16724;
Tue, 12 Jun 2001 15:50:46 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f5CMoj116720
for <rmt@listserv.lbl.gov>; Tue, 12 Jun 2001 15:50:45 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f5CMoid02829
for <rmt@listserv.lbl.gov>; Tue, 12 Jun 2001 15:50:44 -0700 (PDT)
Received: from info.iet.unipi.it (info.iet.unipi.it [131.114.9.184])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f5CMoh602821
for <rmt@lbl.gov>; Tue, 12 Jun 2001 15:50:43 -0700 (PDT)
Received: (from luigi@localhost)
by info.iet.unipi.it (8.9.3/8.9.3) id AAA87649;
Wed, 13 Jun 2001 00:46:25 +0200 (CEST)
(envelope-from luigi)
From: Luigi Rizzo <luigi@info.iet.unipi.it>
Message-Id: <200106122246.AAA87649@info.iet.unipi.it>
Subject: Re: PGMCC and unicast
In-Reply-To: <17309.992344762@cs.ucl.ac.uk> from Jon Crowcroft at "Jun 12, 2001
12:19:22 pm"
To: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
Date: Wed, 13 Jun 2001 00:46:25 +0200 (CEST)
CC: Jeremiah Scholl <jeremiah@cdt.luth.se>, rmt@lbl.gov
X-Mailer: ELM [version 2.4ME+ PL61 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-rmt@lbl.gov
Precedence: bulk
> of course, in a genuine shared media net, it might make a lot of sense
> to multicast acks
it really depends on the protocol. TFMCC "acks" (or whatever they are
called) might be useful to other receivers too (as they contain a
throughput estimate, so can be used for suppression etc.), but
pgmcc acks are almost meaningless for other receivers, they only
mean something (for CC purposes) for the one sender they are
addressed to.
cheers
luigi
>From owner-rmt@listserv.lbl.gov Wed Jun 13 12:47:16 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f5DJiDL23593;
Wed, 13 Jun 2001 12:44:13 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f5DJiC123589
for <rmt@listserv.lbl.gov>; Wed, 13 Jun 2001 12:44:12 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f5DJiB619856
for <rmt@listserv.lbl.gov>; Wed, 13 Jun 2001 12:44:12 -0700 (PDT)
Received: from typhoon.ocis.temple.edu (jmulik@typhoon.ocis.temple.edu [155.247.166.103])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f5DJiA619841
for <rmt@lbl.gov>; Wed, 13 Jun 2001 12:44:11 -0700 (PDT)
Received: from localhost (jmulik@localhost)
by typhoon.ocis.temple.edu (8.11.0/8.11.0) with ESMTP id f5DJi4112027
for <rmt@lbl.gov>; Wed, 13 Jun 2001 15:44:04 -0400 (EDT)
Date: Wed, 13 Jun 2001 15:44:04 -0400 (EDT)
From: Jaiwant Mulik <jmulik@unix.temple.edu>
X-X-Sender: <jmulik@typhoon.ocis.temple.edu>
To: RMT Mailing List <rmt@lbl.gov>
Subject: Status of the GRA draft.
Message-ID: <Pine.OSF.4.32.0106131529220.20317-100000@typhoon.ocis.temple.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-rmt@lbl.gov
Precedence: bulk
Hi all,
Has anyone head about any latest developments on the GRA draft ? The
lastest draft has expired and I have hear it mentioned on the list that
Tony Speakman wanted to revist it with new author(s).
I am doing some research related to GRA, and would like to cite a
reference.
Any update on the status of the draft or reference to publication based on
that draft would be highly welcome.
bye,
Jaiwant Mulik
-----------------------------------------------------------------------
Email : jmulik@temple.edu (preferred), jmulik@acm.org
Home page : http://unix.temple.edu/~jmulik
Office hours : Wednesday, 1:30pm to 3:30pm
Location : Room 1043/1044, Wachman Hall.
Phones : (215) 204-3197 (o), (215) 777-4828 (r)
-----------------------------------------------------------------------
Lekin woh zindagi he kya, jisme koi namumkin sapna na ho ?
I have not failed. I've just found 10,000 ways that won't work.
- Thomas Alva Edison
>From owner-rmt@listserv.lbl.gov Wed Jun 13 16:47:21 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f5DNkZR24577;
Wed, 13 Jun 2001 16:46:35 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f5DNkX124573
for <rmt@listserv.lbl.gov>; Wed, 13 Jun 2001 16:46:33 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f5DNkXm16220
for <rmt@listserv.lbl.gov>; Wed, 13 Jun 2001 16:46:33 -0700 (PDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f5DNkW616212
for <rmt@lbl.gov>; Wed, 13 Jun 2001 16:46:32 -0700 (PDT)
Received: from lorenzo-u10.cisco.com (lorenzo-u10.cisco.com [128.107.162.143])
by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5DNkV900734
for <rmt@lbl.gov>; Wed, 13 Jun 2001 16:46:31 -0700 (PDT)
Received: from localhost (lorenzo@localhost) by lorenzo-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id QAA09885 for <rmt@lbl.gov>; Wed, 13 Jun 2001 16:46:26 -0700 (PDT)
Message-Id: <200106132346.QAA09885@lorenzo-u10.cisco.com>
X-Authentication-Warning: lorenzo-u10.cisco.com: lorenzo owned process doing -bs
X-Mailer: exmh version 2.3.1 01/18/2001 with version: MH 6.8.4 #29[UCI]
To: rmt@lbl.gov
Subject: Congestion Control BBs
Mime-Version: 1.0
Content-Type: multipart/mixed ;
boundary="==_Exmh_14195296130"
Date: Wed, 13 Jun 2001 16:46:26 -0700
From: Lorenzo Vicisano <lorenzo@cisco.com>
Sender: owner-rmt@lbl.gov
Precedence: bulk
This is a multipart MIME message.
--==_Exmh_14195296130
Content-Type: text/plain; charset=us-ascii
Hi,
given the progress made on the CC BBs and the need to
move forward with them, I'd like to reopen the discussion
on the process to do this.
At the last IETF I proposed to try and reach consensus on a
"reference simulations" document to be used as a base for
discussion in the evaluation of CC algorithms. I also proposed
to submit CC BBs as Experimental RFC *first* and move them to
standard track only after we have acquired some deployment
experience in the network.
Anyone has any opinion about this?
As for the "reference simulations" document, we could
use the attached document as a starting point. It comes
from the notes of a meeting attended by some of us and its based on
Mark's original notes. The document was edited by John Byers.
thanks,
Lorenzo
--==_Exmh_14195296130
Content-Type: application/postscript ; name="mcc.ps"
Content-Description: mcc.ps
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="mcc.ps"
%!PS-Adobe-2.0
%%Creator: dvips(k) 5.86 Copyright 1999 Radical Eye Software
%%Title: mcc.dvi
%%Pages: 7
%%PageOrder: Ascend
%%BoundingBox: 0 0 596 842
%%DocumentFonts: Times-Roman Times-Bold Times-Italic
%%EndComments
%DVIPSWebPage: (www.radicaleye.com)
%DVIPSCommandLine: dvips mcc -o
%DVIPSParameters: dpi=3D600, compressed
%DVIPSSource: TeX output 2001.06.13:1443
%%BeginProcSet: texc.pro
%!
/TeXDict 300 dict def TeXDict begin/N{def}def/B{bind def}N/S{exch}N/X{S
N}B/A{dup}B/TR{translate}N/isls false N/vsize 11 72 mul N/hsize 8.5 72
mul N/landplus90{false}def/@rigin{isls{[0 landplus90{1 -1}{-1 1}ifelse 0
0 0]concat}if 72 Resolution div 72 VResolution div neg scale isls{
landplus90{VResolution 72 div vsize mul 0 exch}{Resolution -72 div hsize
mul 0}ifelse TR}if Resolution VResolution vsize -72 div 1 add mul TR[
matrix currentmatrix{A A round sub abs 0.00001 lt{round}if}forall round
exch round exch]setmatrix}N/@landscape{/isls true N}B/@manualfeed{
statusdict/manualfeed true put}B/@copies{/#copies X}B/FMat[1 0 0 -1 0 0]
N/FBB[0 0 0 0]N/nn 0 N/IEn 0 N/ctr 0 N/df-tail{/nn 8 dict N nn begin
/FontType 3 N/FontMatrix fntrx N/FontBBox FBB N string/base X array
/BitMaps X/BuildChar{CharBuilder}N/Encoding IEn N end A{/foo setfont}2
array copy cvx N load 0 nn put/ctr 0 N[}B/sf 0 N/df{/sf 1 N/fntrx FMat N
df-tail}B/dfs{div/sf X/fntrx[sf 0 0 sf neg 0 0]N df-tail}B/E{pop nn A
definefont setfont}B/Cw{Cd A length 5 sub get}B/Ch{Cd A length 4 sub get
}B/Cx{128 Cd A length 3 sub get sub}B/Cy{Cd A length 2 sub get 127 sub}
B/Cdx{Cd A length 1 sub get}B/Ci{Cd A type/stringtype ne{ctr get/ctr ctr
1 add N}if}B/id 0 N/rw 0 N/rc 0 N/gp 0 N/cp 0 N/G 0 N/CharBuilder{save 3
1 roll S A/base get 2 index get S/BitMaps get S get/Cd X pop/ctr 0 N Cdx
0 Cx Cy Ch sub Cx Cw add Cy setcachedevice Cw Ch true[1 0 0 -1 -.1 Cx
sub Cy .1 sub]/id Ci N/rw Cw 7 add 8 idiv string N/rc 0 N/gp 0 N/cp 0 N{
rc 0 ne{rc 1 sub/rc X rw}{G}ifelse}imagemask restore}B/G{{id gp get/gp
gp 1 add N A 18 mod S 18 idiv pl S get exec}loop}B/adv{cp add/cp X}B
/chg{rw cp id gp 4 index getinterval putinterval A gp add/gp X adv}B/nd{
/cp 0 N rw exit}B/lsh{rw cp 2 copy get A 0 eq{pop 1}{A 255 eq{pop 254}{
A A add 255 and S 1 and or}ifelse}ifelse put 1 adv}B/rsh{rw cp 2 copy
get A 0 eq{pop 128}{A 255 eq{pop 127}{A 2 idiv S 128 and or}ifelse}
ifelse put 1 adv}B/clr{rw cp 2 index string putinterval adv}B/set{rw cp
fillstr 0 4 index getinterval putinterval adv}B/fillstr 18 string 0 1 17
{2 copy 255 put pop}for N/pl[{adv 1 chg}{adv 1 chg nd}{1 add chg}{1 add
chg nd}{adv lsh}{adv lsh nd}{adv rsh}{adv rsh nd}{1 add adv}{/rc X nd}{
1 add set}{1 add clr}{adv 2 chg}{adv 2 chg nd}{pop nd}]A{bind pop}
forall N/D{/cc X A type/stringtype ne{]}if nn/base get cc ctr put nn
/BitMaps get S ctr S sf 1 ne{A A length 1 sub A 2 index S get sf div put
}if put/ctr ctr 1 add N}B/I{cc 1 add D}B/bop{userdict/bop-hook known{
bop-hook}if/SI save N @rigin 0 0 moveto/V matrix currentmatrix A 1 get A
mul exch 0 get A mul add .99 lt{/QV}{/RV}ifelse load def pop pop}N/eop{
SI restore userdict/eop-hook known{eop-hook}if showpage}N/@start{
userdict/start-hook known{start-hook}if pop/VResolution X/Resolution X
1000 div/DVImag X/IEn 256 array N 2 string 0 1 255{IEn S A 360 add 36 4
index cvrs cvn put}for pop 65781.76 div/vsize X 65781.76 div/hsize X}N
/p{show}N/RMat[1 0 0 -1 0 0]N/BDot 260 string N/Rx 0 N/Ry 0 N/V{}B/RV/v{
/Ry X/Rx X V}B statusdict begin/product where{pop false[(Display)(NeXT)
(LaserWriter 16/600)]{A length product length le{A length product exch 0
exch getinterval eq{pop true exit}if}{pop}ifelse}forall}{false}ifelse
end{{gsave TR -.1 .1 TR 1 1 scale Rx Ry false RMat{BDot}imagemask
grestore}}{{gsave TR -.1 .1 TR Rx Ry scale 1 1 false RMat{BDot}
imagemask grestore}}ifelse B/QV{gsave newpath transform round exch round
exch itransform moveto Rx 0 rlineto 0 Ry neg rlineto Rx neg 0 rlineto
fill grestore}B/a{moveto}B/delta 0 N/tail{A/delta X 0 rmoveto}B/M{S p
delta add tail}B/b{S p tail}B/c{-4 M}B/d{-3 M}B/e{-2 M}B/f{-1 M}B/g{0 M}
B/h{1 M}B/i{2 M}B/j{3 M}B/k{4 M}B/w{0 rmoveto}B/l{p -4 w}B/m{p -3 w}B/n{
p -2 w}B/o{p -1 w}B/q{p 1 w}B/r{p 2 w}B/s{p 3 w}B/t{p 4 w}B/x{0 S
rmoveto}B/y{3 2 roll p a}B/bos{/SS save N}B/eos{SS restore}B end
%%EndProcSet
%%BeginProcSet: 8r.enc
% @@psencodingfile@{
% author =3D "S. Rahtz, P. MacKay, Alan Jeffrey, B. Horn, K. Berry",
% version =3D "0.6",
% date =3D "1 July 1998",
% filename =3D "8r.enc",
% email =3D "tex-fonts@@tug.org",
% docstring =3D "Encoding for TrueType or Type 1 fonts
% to be used with TeX."
% @}
% =
% Idea is to have all the characters normally included in Type 1 fonts
% available for typesetting. This is effectively the characters in Adobe
% Standard Encoding + ISO Latin 1 + extra characters from Lucida.
% =
% Character code assignments were made as follows:
% =
% (1) the Windows ANSI characters are almost all in their Windows ANSI
% positions, because some Windows users cannot easily reencode the
% fonts, and it makes no difference on other systems. The only Windows
% ANSI characters not available are those that make no sense for
% typesetting -- rubout (127 decimal), nobreakspace (160), softhyphen
% (173). quotesingle and grave are moved just because it's such an
% irritation not having them in TeX positions.
% =
% (2) Remaining characters are assigned arbitrarily to the lower part
% of the range, avoiding 0, 10 and 13 in case we meet dumb software.
% =
% (3) Y&Y Lucida Bright includes some extra text characters; in the
% hopes that other PostScript fonts, perhaps created for public
% consumption, will include them, they are included starting at 0x12.
% =
% (4) Remaining positions left undefined are for use in (hopefully)
% upward-compatible revisions, if someday more characters are generally
% available.
% =
% (5) hyphen appears twice for compatibility with both =
% ASCII and Windows.
% =
/TeXBase1Encoding [
% 0x00 (encoded characters from Adobe Standard not in Windows 3.1)
/.notdef /dotaccent /fi /fl
/fraction /hungarumlaut /Lslash /lslash
/ogonek /ring /.notdef
/breve /minus /.notdef =
% These are the only two remaining unencoded characters, so may as
% well include them.
/Zcaron /zcaron =
% 0x10
/caron /dotlessi =
% (unusual TeX characters available in, e.g., Lucida Bright)
/dotlessj /ff /ffi /ffl =
/.notdef /.notdef /.notdef /.notdef
/.notdef /.notdef /.notdef /.notdef
% very contentious; it's so painful not having quoteleft and quoteright
% at 96 and 145 that we move the things normally found there to here.
/grave /quotesingle =
% 0x20 (ASCII begins)
/space /exclam /quotedbl /numbersign
/dollar /percent /ampersand /quoteright
/parenleft /parenright /asterisk /plus /comma /hyphen /period /slash
% 0x30
/zero /one /two /three /four /five /six /seven
/eight /nine /colon /semicolon /less /equal /greater /question
% 0x40
/at /A /B /C /D /E /F /G /H /I /J /K /L /M /N /O
% 0x50
/P /Q /R /S /T /U /V /W
/X /Y /Z /bracketleft /backslash /bracketright /asciicircum /underscore
% 0x60
/quoteleft /a /b /c /d /e /f /g /h /i /j /k /l /m /n /o
% 0x70
/p /q /r /s /t /u /v /w
/x /y /z /braceleft /bar /braceright /asciitilde
/.notdef % rubout; ASCII ends
% 0x80
/.notdef /.notdef /quotesinglbase /florin
/quotedblbase /ellipsis /dagger /daggerdbl
/circumflex /perthousand /Scaron /guilsinglleft
/OE /.notdef /.notdef /.notdef
% 0x90
/.notdef /.notdef /.notdef /quotedblleft
/quotedblright /bullet /endash /emdash
/tilde /trademark /scaron /guilsinglright
/oe /.notdef /.notdef /Ydieresis
% 0xA0
/.notdef % nobreakspace
/exclamdown /cent /sterling
/currency /yen /brokenbar /section
/dieresis /copyright /ordfeminine /guillemotleft
/logicalnot
/hyphen % Y&Y (also at 45); Windows' softhyphen
/registered
/macron
% 0xD0
/degree /plusminus /twosuperior /threesuperior
/acute /mu /paragraph /periodcentered
/cedilla /onesuperior /ordmasculine /guillemotright
/onequarter /onehalf /threequarters /questiondown
% 0xC0
/Agrave /Aacute /Acircumflex /Atilde /Adieresis /Aring /AE /Ccedilla
/Egrave /Eacute /Ecircumflex /Edieresis
/Igrave /Iacute /Icircumflex /Idieresis
% 0xD0
/Eth /Ntilde /Ograve /Oacute
/Ocircumflex /Otilde /Odieresis /multiply
/Oslash /Ugrave /Uacute /Ucircumflex
/Udieresis /Yacute /Thorn /germandbls
% 0xE0
/agrave /aacute /acircumflex /atilde
/adieresis /aring /ae /ccedilla
/egrave /eacute /ecircumflex /edieresis
/igrave /iacute /icircumflex /idieresis
% 0xF0
/eth /ntilde /ograve /oacute
/ocircumflex /otilde /odieresis /divide
/oslash /ugrave /uacute /ucircumflex
/udieresis /yacute /thorn /ydieresis
] def
%%EndProcSet
%%BeginProcSet: texps.pro
%!
TeXDict begin/rf{findfont dup length 1 add dict begin{1 index/FID ne 2
index/UniqueID ne and{def}{pop pop}ifelse}forall[1 index 0 6 -1 roll
exec 0 exch 5 -1 roll VResolution Resolution div mul neg 0 0]/Metrics
exch def dict begin Encoding{exch dup type/integertype ne{pop pop 1 sub
dup 0 le{pop}{[}ifelse}{FontMatrix 0 get div Metrics 0 get div def}
ifelse}forall Metrics/Metrics currentdict end def[2 index currentdict
end definefont 3 -1 roll makefont/setfont cvx]cvx def}def/ObliqueSlant{
dup sin S cos div neg}B/SlantFont{4 index mul add}def/ExtendFont{3 -1
roll mul exch}def/ReEncodeFont{CharStrings rcheck{/Encoding false def
dup[exch{dup CharStrings exch known not{pop/.notdef/Encoding true def}
if}forall Encoding{]exch pop}{cleartomark}ifelse}if/Encoding exch def}
def end
%%EndProcSet
%%BeginProcSet: special.pro
%!
TeXDict begin/SDict 200 dict N SDict begin/@SpecialDefaults{/hs 612 N
/vs 792 N/ho 0 N/vo 0 N/hsc 1 N/vsc 1 N/ang 0 N/CLIP 0 N/rwiSeen false N
/rhiSeen false N/letter{}N/note{}N/a4{}N/legal{}N}B/@scaleunit 100 N
/@hscale{@scaleunit div/hsc X}B/@vscale{@scaleunit div/vsc X}B/@hsize{
/hs X/CLIP 1 N}B/@vsize{/vs X/CLIP 1 N}B/@clip{/CLIP 2 N}B/@hoffset{/ho
X}B/@voffset{/vo X}B/@angle{/ang X}B/@rwi{10 div/rwi X/rwiSeen true N}B
/@rhi{10 div/rhi X/rhiSeen true N}B/@llx{/llx X}B/@lly{/lly X}B/@urx{
/urx X}B/@ury{/ury X}B/magscale true def end/@MacSetUp{userdict/md known
{userdict/md get type/dicttype eq{userdict begin md length 10 add md
maxlength ge{/md md dup length 20 add dict copy def}if end md begin
/letter{}N/note{}N/legal{}N/od{txpose 1 0 mtx defaultmatrix dtransform S
atan/pa X newpath clippath mark{transform{itransform moveto}}{transform{
itransform lineto}}{6 -2 roll transform 6 -2 roll transform 6 -2 roll
transform{itransform 6 2 roll itransform 6 2 roll itransform 6 2 roll
curveto}}{{closepath}}pathforall newpath counttomark array astore/gc xdf
pop ct 39 0 put 10 fz 0 fs 2 F/|______Courier fnt invertflag{PaintBlack}
if}N/txpose{pxs pys scale ppr aload pop por{noflips{pop S neg S TR pop 1
-1 scale}if xflip yflip and{pop S neg S TR 180 rotate 1 -1 scale ppr 3
get ppr 1 get neg sub neg ppr 2 get ppr 0 get neg sub neg TR}if xflip
yflip not and{pop S neg S TR pop 180 rotate ppr 3 get ppr 1 get neg sub
neg 0 TR}if yflip xflip not and{ppr 1 get neg ppr 0 get neg TR}if}{
noflips{TR pop pop 270 rotate 1 -1 scale}if xflip yflip and{TR pop pop
90 rotate 1 -1 scale ppr 3 get ppr 1 get neg sub neg ppr 2 get ppr 0 get
neg sub neg TR}if xflip yflip not and{TR pop pop 90 rotate ppr 3 get ppr
1 get neg sub neg 0 TR}if yflip xflip not and{TR pop pop 270 rotate ppr
2 get ppr 0 get neg sub neg 0 S TR}if}ifelse scaleby96{ppr aload pop 4
-1 roll add 2 div 3 1 roll add 2 div 2 copy TR .96 dup scale neg S neg S
TR}if}N/cp{pop pop showpage pm restore}N end}if}if}N/normalscale{
Resolution 72 div VResolution 72 div neg scale magscale{DVImag dup scale
}if 0 setgray}N/psfts{S 65781.76 div N}N/startTexFig{/psf$SavedState
save N userdict maxlength dict begin/magscale true def normalscale
currentpoint TR/psf$ury psfts/psf$urx psfts/psf$lly psfts/psf$llx psfts
/psf$y psfts/psf$x psfts currentpoint/psf$cy X/psf$cx X/psf$sx psf$x
psf$urx psf$llx sub div N/psf$sy psf$y psf$ury psf$lly sub div N psf$sx
psf$sy scale psf$cx psf$sx div psf$llx sub psf$cy psf$sy div psf$ury sub
TR/showpage{}N/erasepage{}N/copypage{}N/p 3 def @MacSetUp}N/doclip{
psf$llx psf$lly psf$urx psf$ury currentpoint 6 2 roll newpath 4 copy 4 2
roll moveto 6 -1 roll S lineto S lineto S lineto closepath clip newpath
moveto}N/endTexFig{end psf$SavedState restore}N/@beginspecial{SDict
begin/SpecialSave save N gsave normalscale currentpoint TR
@SpecialDefaults count/ocount X/dcount countdictstack N}N/@setspecial{
CLIP 1 eq{newpath 0 0 moveto hs 0 rlineto 0 vs rlineto hs neg 0 rlineto
closepath clip}if ho vo TR hsc vsc scale ang rotate rwiSeen{rwi urx llx
sub div rhiSeen{rhi ury lly sub div}{dup}ifelse scale llx neg lly neg TR
}{rhiSeen{rhi ury lly sub div dup scale llx neg lly neg TR}if}ifelse
CLIP 2 eq{newpath llx lly moveto urx lly lineto urx ury lineto llx ury
lineto closepath clip}if/showpage{}N/erasepage{}N/copypage{}N newpath}N
/@endspecial{count ocount sub{pop}repeat countdictstack dcount sub{end}
repeat grestore SpecialSave restore end}N/@defspecial{SDict begin}N
/@fedspecial{end}B/li{lineto}B/rl{rlineto}B/rc{rcurveto}B/np{/SaveX
currentpoint/SaveY X N 1 setlinecap newpath}N/st{stroke SaveX SaveY
moveto}N/fil{fill SaveX SaveY moveto}N/ellipse{/endangle X/startangle X
/yrad X/xrad X/savematrix matrix currentmatrix N TR xrad yrad scale 0 0
1 startangle endangle arc savematrix setmatrix}N end
%%EndProcSet
TeXDict begin 39158280 55380996 1000 600 600 (mcc.dvi)
@start
%DVIPSBitmapFont: Fa cmmi10 10.95 1
/Fa 1 108 df<EB01FC13FF5CA21303A25CA21307A25CA2130FA25CA2131FA25CA2133F
A291C9FC16FC49EB03FE92380F0780017EEB3C0FED703F01FE13E0913801C07F9038FC03
80EC07000001010E14004A131C494890C7FC5C00035BEBF9C0495A01FFC9FC5A14F0EBE3
FE9038E07F80000FEB1FC06E7EEBC00781001F1303160E1380A2003F151E0207131C0100
13E0A2485DA2007E01031378167000FE01015B15F1489038007F800038023EC7FC29407C
BE2F>107 D E
%EndDVIPSBitmapFont
/Fb 136[54 37 37 21 29 25 37 37 37 37 1[21 37 1[21 37
37 25 33 37 33 37 33 18[54 66 27[37 37 1[19 1[19 44[{
TeXBase1Encoding ReEncodeFont}27 74.7198 /Times-Roman
rf /Fc 206[25 49[{TeXBase1Encoding ReEncodeFont}1 49.8132
/Times-Roman rf /Fd 206[33 49[{TeXBase1Encoding ReEncodeFont}1
66.4176 /Times-Roman rf /Fe 139[30 4[45 6[51 5[51 98[{
TeXBase1Encoding ReEncodeFont}4 90.9091 /Times-Bold rf
%DVIPSBitmapFont: Ff cmsy10 10.95 1
/Ff 1 16 df<EB0FFCEB3FFF90B512C0000314F04880488048804880A2481580A3B712C0
AA6C1580A36C1500A26C5C6C5C6C5C6C5CC614C0013F90C7FCEB0FFC22227BA72D>15
D E
%EndDVIPSBitmapFont
/Fg 135[40 3[25 35 35 1[45 45 45 66 3[25 45 2[40 3[45
97[{TeXBase1Encoding ReEncodeFont}12 90.9091 /Times-Italic
rf /Fh 133[40 45 45 66 45 45 25 35 30 45 45 45 45 71
25 45 25 25 45 45 30 40 45 40 45 40 9[86 66 66 56 51
61 66 51 1[66 81 56 66 1[30 66 66 51 56 66 61 61 66 5[25
25 45 45 45 45 45 45 45 45 45 45 25 23 30 23 51 1[30
30 30 1[76 33[51 51 2[{TeXBase1Encoding ReEncodeFont}70
90.9091 /Times-Roman rf /Fi 135[60 1[60 66 40 47 53 1[66
60 66 100 33 2[33 66 60 1[53 66 53 1[60 9[120 2[80 4[93
1[113 7[80 86 86 15[60 60 60 9[40 39[{TeXBase1Encoding ReEncodeFont}29
119.552 /Times-Bold rf /Fj 140[32 4[42 110[{
TeXBase1Encoding ReEncodeFont}2 83.022 /Times-Italic
rf /Fk 133[37 42 42 60 42 42 23 32 28 1[42 42 42 65 23
42 1[23 42 42 28 37 42 37 42 37 3[28 1[28 3[78 60 1[51
46 2[46 2[74 51 1[32 28 60 60 46 1[60 1[55 60 5[23 1[42
42 3[42 42 42 1[42 1[21 28 21 44[{TeXBase1Encoding ReEncodeFont}51
83.022 /Times-Roman rf /Fl 139[28 32 37 14[37 46 42 31[60
65[{TeXBase1Encoding ReEncodeFont}7 83.022 /Times-Bold
rf /Fm 138[50 28 39 33 2[50 50 78 28 2[28 1[50 33 44
3[44 18[72 7[55 1[72 2[72 8[50 5[50 1[50 3[25 44[{
TeXBase1Encoding ReEncodeFont}21 99.6264 /Times-Roman
rf /Fn 138[72 40 56 48 2[72 72 112 40 2[40 72 72 48 64
1[64 72 64 12[88 80 96 4[128 9[96 67[{TeXBase1Encoding ReEncodeFont}21
143.462 /Times-Roman rf end
%%EndProlog
%%BeginSetup
%%Feature: *Resolution 600dpi
TeXDict begin
%%PaperSize: A4
%%EndSetup
%%Page: 1 1
1 0 bop 99 456 a Fn(More)35 b(Thoughts)f(on)h(Reference)e(Simulations)h
(for)h(Reliable)f(Multicast)1113 638 y(Congestion)g(Control)g(Schemes)
748 891 y Fm(Notes)25 b(from)f(a)h(meeting)f(at)h(Digital)f(F)o
(ountain)f(on)i(August)f(8,)g(2000)1796 1202 y Fl(Abstract)352
1335 y Fk(This)c(document)e(summarizes)h(the)i(output)d(of)i(a)h
(meeting)e(held)h(at)g(Digital)h(F)o(ountain,)d(Inc.)24
b(on)c(August)g(8,)g(2000)227 1435 y(to)26 b(e)o(xpand)d(upon)h(the)i
(w)o(ork)e(initiated)h(by)g(Mark)g(Handle)o(y)f(to)i(de)n(v)o(elop)d(a)
j(set)g(of)f(reference)f(simulations)h(for)f(reli-)227
1535 y(able)f(multicast)f(congestion)f(control)g(schemes)h([H99].)31
b(P)o(articipants)22 b(included)f(John)h(Byers,)h(Ga)n(vin)f(Horn,)g
(Mark)227 1634 y(Handle)o(y)-5 b(,)28 b(Michael)f(Luby)-5
b(,)28 b(W)m(ill)g(Sha)n(v)o(er)f(and)g(Lorenzo)f(V)-5
b(icisano.)47 b(This)28 b(outline)f(sk)o(etches)h(a)g(set)g(of)g
(additional)227 1734 y(e)o(xperiments)17 b(which)g(the)i(meeting)e
(participants)g(generally)g(deemed)g(useful,)h(and)g(pro)o(vides)e
(guidelines)i(for)f(setting)227 1833 y(up)29 b(appropriate)d
Fj(ns)j Fk(simulations)f(in)h(which)f(to)h(perform)e(these)i(e)o
(xperiments.)48 b(This)29 b(w)o(ork)f(is)i(not)e(a)i(standalone)227
1933 y(document;)d(our)e(plan)h(is)h(to)f(inte)o(grate)f(the)h
(suggestions)f(it)h(contains)g(into)f(an)h(updated)f(v)o(ersion)f(of)i
(the)g(reference)227 2033 y(simulations)20 b(draft.)0
2321 y Fi(1)119 b(Methodological)31 b(Considerations)0
2528 y Fh(Before)19 b(a)e(successful)k(e)o(xperiment)f(can)f(be)f
(undertak)o(en)j(in)d Fg(ns)g Fh(to)g(measure)i(the)e(performance)j(of)
d(a)f(multicast)j(congestion)0 2641 y(control)26 b(strate)o(gy)-6
b(,)26 b(there)f(are)g(a)f(substantial)j(number)f(of)e(parameters)i
(which)f(must)f(be)h(set)f(carefully)j(to)d(ensure)i(that)f(the)0
2754 y(e)o(xperiment)j(is)e(measuring)j(something)f(useful.)39
b(W)-7 b(e)26 b(enumerate)i(these)f(here,)h(be)o(ginning)h(with)d
(principles)j(that)e(apply)0 2867 y(to)c(congestion)k(control)e
(studies)h(in)d(general,)i(then)f(continuing)j(with)c(principles)k
(speci\002c)d(to)g(multicast:)136 3055 y Ff(\017)46 b
Fh(Correct)24 b(queue)h(sizing.)k(The)23 b(minimum)g(queue)h(size)g
(for)f(which)h(TCP)d(congestion)26 b(control)f(beha)n(v)o(es)g
(according)227 3168 y(to)34 b(ideal)h(sa)o(wtooth)g(beha)n(vior)i(is)c
(one)i(in)f(which)g(the)g(bottleneck)j(gate)n(w)o(ay)e(has)f(a)g(queue)
h(sized)g(equal)g(to)f(the)227 3281 y(bandwidth-delay)j(product)d(of)e
(the)g(connection.)58 b(F)o(or)31 b(drop-tail)j(gate)n(w)o(ays,)h(we)c
(recommend)j(testing)g(at)e(that)227 3394 y(setting,)h(and)d(with)g(a)f
(queue)i(size)g(four)f(times)g(lar)n(ger)l(,)j(i.e.)47
b(four)31 b(times)f(the)g(bandwidth-delay)k(product.)49
b(RED)227 3507 y(gate)n(w)o(ay)24 b(settings)i(are)e(discussed)i(in)d
(more)h(detail)g(belo)n(w)136 3686 y Ff(\017)46 b Fh(TCP)29
b(type)i(and)g(settings.)51 b(In)30 b(order)i(of)e(importance,)k(we)29
b(recommend)j(running)h(tests)e(with)f(TCP)e(SA)l(CK)h(and)227
3799 y(TCP)c(Reno;)k(the)e(former)h(pro)o(viding)h(rob)n(ustness)h(to)d
(multiple)h(losses)g(per)f(windo)n(w)-6 b(,)28 b(the)f(latter)h(being)g
(the)f(most)227 3912 y(widely)37 b(deplo)o(yed)h(v)o(ersion)f(of)f(TCP)
e(today)-6 b(.)67 b(The)35 b(clock)i(granularity)i(of)d(TCP)e(must)i
(be)f(set)h(appropriately)-6 b(.)227 4025 y(The)32 b(TCP)e(recei)n(v)o
(er)j(windo)n(w)f(should)h(be)f(set)g(to)g(be)g(lar)n(ge)h(enough)h(to)
e(a)n(v)n(oid)i(impacting)f(congestion)i(control)227
4138 y(algorithms)g(\(10000)g(pack)o(ets\).)59 b(Unless)33
b(the)g(goal)h(of)e(the)h(e)o(xperiment)i(is)e(to)g(e)o(xplore)h
(interaction)i(with)c(TCP)227 4251 y(slo)n(w)24 b(start)i(dynamics,)g
(suf)n(\002cient)f(time)g(\(15)g(seconds\))h(should)h(elapse)e(after)h
(a)e(TCP)e(connection)28 b(is)c(established)227 4364
y(before)h(measurements)h(are)e(tak)o(en.)136 4543 y
Ff(\017)46 b Fh(Bottleneck)39 b(bandwidth.)68 b(It)36
b(is)h(imperati)n(v)o(e)g(to)f(test)h(congestion)i(control)f(strate)o
(gies)h(o)o(v)o(er)d(a)g(wide)g(range)h(of)227 4656 y(bottleneck)d
(bandwidths.)54 b(W)-7 b(e)30 b(recommend)i(testing)h(with)e
(bottleneck)j(bandwidths)f(of)e(200Kbps,)j(500Kbps,)227
4769 y(1Mbps,)24 b(8Mbps)h(and)f(64Mbps.)136 4948 y Ff(\017)46
b Fh(Randomization.)c Fg(ns)27 b Fh(and)g(other)h(e)n(v)o(ent-dri)n(v)o
(en)h(simulators)g(are)e(prone)h(to)f(simulation)i(artif)o(acts)g(such)
e(as)g(phase)227 5061 y(ef)n(fects)i(that)f(may)f(not)h(be)f(present)i
(in)e(the)h(real)g(w)o(orld.)40 b(W)-7 b(e)27 b(recommend)h(the)g(use)g
(of)f(randomization)k(in)c(simu-)227 5174 y(lations)f(to)e(remo)o(v)o
(e)g(these)i(ef)n(fects.)31 b(Some)24 b(tactics)i(for)e(doing)h(so)g
(include)h(the)e(use)h(of)f(RED)e(gate)n(w)o(ays,)j(adding)h(a)227
5287 y(random)j(error)f(term)g(to)f(pack)o(et)i(transmission)i(times,)d
(or)g(injecting)i(a)d(small)h(amount)g(of)g(random)g(cross-traf)n
(\002c)227 5400 y(on)c(the)g(forw)o(ard)g(path.)1927
5649 y(1)p eop
%%Page: 2 2
2 1 bop 136 91 a Ff(\017)46 b Fh(Queueing)21 b(policies.)30
b(The)19 b(impact)h(of)g(both)g(drop-tail)i(and)e(RED)d(gate)n(w)o(ays)
k(on)e(the)h(congestion)j(control)e(protocol)227 204
y(should)26 b(be)e(studied,)i(compliance)g(with)e(drop-tail)j(being)e
(the)f(more)h(important)g(gi)n(v)o(en)g(its)f(wider)h(deplo)o(yment)h
(at)227 317 y(present.)50 b(When)30 b(RED)e(gate)n(w)o(ays)j(are)f
(used,)i(a)e(number)h(of)f(parameters)i(must)e(be)g(set)g(carefully)i
(to)e(pro)o(vide)i(a)227 430 y(meaningful)c(simulation.)36
b(Recommended)27 b(settings)h(include:)35 b(sizing)27
b(the)e(queue)i(to)e(be)h(twice)f(the)h(bandwidth-)227
543 y(delay)31 b(product,)h(setting)f Fg(minthr)m(esh)g
Fh(to)e(be)h(5\045)f(of)g(the)h(queue)g(size)g(and)g
Fg(maxthr)m(esh)h Fh(to)e(be)h(50\045)f(of)g(the)h(queue)227
656 y(size,)38 b(setting)f Fg(maxp)e Fh(to)f(be)h(approximately)j
(equal)e(to)f(the)g(standing)i(queue)f(size,)i(or)d(roughly)i
(\(minthresh)g(+)227 769 y(maxthresh\))26 b(/)d(2,)g(and)h(turning)h
(the)f(gentle)h(setting)g(on.)136 956 y Ff(\017)46 b
Fh(Multicast)26 b(routing)f(protocol)h(setup.)k Fg(ns)24
b Fh(pro)o(vides)h(a)f(number)g(of)g(possible)i(multicast)f(routing)g
(options,)h(none)e(of)227 1069 y(which)g(f)o(aithfully)j(reproduce)f
(the)e(beha)n(vior)j(of)c(these)i(protocols)i(on)d(real)g(netw)o(orks.)
31 b(P)o(articularly)26 b(problematic)227 1182 y(is)d(the)g(f)o(ailure)
i(of)e Fg(ns)g Fh(to)g(simulate)h(control)h(traf)n(\002c)e(correctly)-6
b(.)31 b(W)-7 b(e)22 b(recommend)i(using)g(the)g(PIM-SM)d(centralized)
227 1295 y(routing)26 b(setup,)e(on)g(top)g(of)f(which)h(control)h
(message)g(latenc)o(y)g(is)e(simulated)i(\(see)g(ne)o(xt)e(item\).)136
1483 y Ff(\017)46 b Fh(Correct)27 b(modeling)g(of)f(join)g(and)g(lea)n
(v)o(e)h(latencies.)37 b Fg(ns)26 b Fh(does)g(not)h(pro)o(vide)g(an)e
(accurate)j(model)e(for)g(propagation)227 1596 y(of)i(IGMP)f(join)i
(and)g(lea)n(v)o(e)g(requests,)i(nor)e(does)g(it)f(pro)o(vide)i(an)e
(accurate)j(model)d(of)h(latencies)h(of)e(PIM)f(control)227
1709 y(messages.)59 b(Lea)n(v)o(e)33 b(latencies)i(can)f(be)e
(especially)k(substantial)g(and)e(must)f(be)g(tested.)58
b(W)-7 b(e)32 b(recommend)i(tests)227 1822 y(which)e(in)l(v)n(olv)o(e)h
(a)e(four)h(to)g(six)f(second)i(IGMP)d(lea)n(v)o(e)i(latenc)o(y)h(and)f
(PIM)e(prune)j(messages)f(which)g(tak)o(e)g(three)227
1934 y(seconds)26 b(to)d(tra)n(v)o(erse)j(a)d(LAN.)e(These)j(latencies)
i(are)d(in)h(addition)h(to)f(hop-by-hop)j(propagation)f(delay)-6
b(.)136 2122 y Ff(\017)46 b Fh(Pruning)29 b(traf)n(\002c)f(back)h(to)f
(the)g(source.)44 b(Protocols)30 b(using)f(layered)h(multicast)f(for)f
(congestion)j(control)f(must)e(be)227 2235 y(careful)i(to)d(prune)j
(unw)o(anted)f(traf)n(\002c)f(all)g(the)g(w)o(ay)g(back)g(to)g(the)g
(source)i(to)d(a)n(v)n(oid)j(unintended)h(side)d(ef)n(fects.)43
b(In)227 2348 y(some)24 b(situations,)i(co-locating)h(a)c(router)i
(with)e(the)h(source)h(is)e(a)g(simple)h(w)o(ay)g(to)f(perform)i(this)f
(pruning)h(step.)0 2640 y Fi(2)119 b(Experiments)0 2847
y Fh(W)-7 b(e)34 b(no)n(w)g(pro)o(vide)i(a)e(list)h(of)f(potentially)k
(interesting)f(and)e(useful)h(e)o(xperiments)g(with)f(which)g(to)f
(test)h(a)f(congestion)0 2960 y(control)28 b(strate)o(gy)-6
b(.)37 b(There)27 b(are)f(se)n(v)o(eral)h(principles)h(which)f(loosely)
g(guided)h(the)e(mak)o(eup)h(and)g(ordering)h(of)e(these)h(tests.)0
3073 y(First,)h(we)f(intended)i(the)f(test)g(suite)g(to)g(be)o(gin)g
(with)f(tests)h(of)g(v)o(ery)f(basic)i(principles,)i(and)d(to)f(ha)n(v)
o(e)h(later)g(tests)g(become)0 3186 y(richer)38 b(in)e(scope,)k(often)e
(with)e(the)h(assumption)h(that)f(earlier)h(tests)f(had)g(completed)h
(correctly)-6 b(.)70 b(Second,)40 b(virtually)0 3299
y(e)n(v)o(ery)23 b(e)o(xperiment)i(w)o(as)e(designed)i(with)e(a)g
(speci\002c)g(point)h(in)f(mind,)g(and)h(the)f(names)g(we)g(attrib)n
(ute)i(to)e(the)g(e)o(xperiments)0 3412 y(attempt)33
b(to)f(re\003ect)h(this.)55 b(Finally)-6 b(,)35 b(for)d(the)h(adv)n
(anced)h(tests,)h(we)c(made)h(some)h(ef)n(fort)g(to)f(classify)i(them)e
(into)h(coarse)0 3525 y(classi\002cations,)27 b(which)c(were)h(tests)g
(of)g(1\))f(scaling)i(beha)n(vior)l(,)h(2\))e(heterogeneity)j(and)d
(3\))g(f)o(airness.)141 3638 y(In)36 b(most)h(cases,)j(the)c(tests)h
(are)g(equally)h(v)n(alid)f(for)f(single-rate)j(and)e(multi-rate)h
(congestion)h(control)f(schemes,)0 3751 y(although)25
b(the)f(e)o(xpected)h(outcomes)f(of)f(the)h(e)o(xperiments)h(in)e
(those)h(tw)o(o)f(domains)h(may)f(v)n(ary)-6 b(.)29 b(Unless)24
b(otherwise)g(spec-)0 3864 y(i\002ed,)h(all)f(of)h(the)g
(methodological)k(considerations)g(described)e(in)e(the)g(pre)n(vious)h
(section)h(apply)-6 b(.)33 b(When)25 b(not)h(otherwise)0
3977 y(speci\002ed,)38 b(we)c(use)g(a)g(def)o(ault)i(setting)g(of)f
(10ms)f(latenc)o(y)i(on)e(all)h(links,)j(1KB)33 b(pack)o(et)j(size)f
(including)i(headers)f(and)0 4089 y(100Mbps)25 b(bandwidth)h(on)d
(links)i(which)f(are)g(not)f(bottleneck)k(links.)141
4202 y(The)h(e)o(xperiments)j(we)d(emplo)o(y)h(ha)n(v)o(e)h(tw)o(o)e(v)
o(ery)h(dif)n(ferent)h(sources)h(of)d(pack)o(et)i(loss.)45
b(In)29 b(some)f(e)o(xperiments,)k(we)0 4315 y(ha)n(v)o(e)24
b(a)f(lar)n(ge)i(amount)f(of)f(a)n(v)n(ailable)j(bandwidth)f(to)e
(support)j(the)d(\003o)n(ws)g(and)g(emplo)o(y)i(random)f(dropping)i(of)
d(pack)o(ets)i(at)0 4428 y(links)h(to)f(achie)n(v)o(e)i(loss.)34
b(In)25 b(other)i(e)o(xperiments,)g(we)e(study)h(the)g(queuing)h(beha)n
(vior)h(of)d(the)g(system,)i(dropping)g(pack)o(ets)0
4541 y(only)d(when)g(queues)h(o)o(v)o(er\003o)n(w)e(\(or)h(in)f(the)h
(case)g(of)g(RED,)d(only)j(when)g(queues)h(elect)g(to)e(drop)h(pack)o
(ets\).)114 4754 y(1.)45 b(Sanity)29 b(check)g(\(Figure)g(1\).)42
b(A)27 b(single)j(multicast)f(sender)h(and)e(a)g(single)h(multicast)h
(recei)n(v)o(er)f(be)o(gin)g(to)f(commu-)227 4867 y(nicate)f(o)o(v)o
(er)f(a)g(three)g(hop)h(path)f(with)g(bottleneck)i(bandwidth)g(1Mbps.)
37 b(After)25 b(30)h(seconds,)i(a)e(CBR)e(\003o)n(w)g(emits)227
4979 y(cross)29 b(traf)n(\002c)f(o)o(v)o(er)g(the)g(bottleneck)j(link)d
(at)g(rate)g(500Kbps.)44 b(After)28 b(60)g(seconds,)i(the)e(CBR)e
(\003o)n(w)h(decreases)j(its)227 5092 y(rate)35 b(to)f(250Kbps.)62
b(Expected)36 b(beha)n(vior:)53 b(The)34 b(multicast)h(\003o)n(w)e
(should)j(adapt)f(to)f(the)h(a)n(v)n(ailable)h(bottleneck)227
5205 y(bandwidth)26 b(smoothly)f(and)f(ef)n(\002ciently)-6
b(.)1927 5649 y(2)p eop
%%Page: 3 3
3 2 bop 114 91 a Fh(2.)45 b(Correlated)24 b(loss.)29
b(Referring)24 b(to)d(Figure)i(2,)f(a)f(sender)j(transmits)f(to)f
(three)h(recei)n(v)o(ers)h(o)o(v)o(er)e(a)f(binary)j(tree)e(of)g(depth)
227 204 y(3)27 b(\(the)h(link)g(nearest)g(the)g(sender)g(is)f(shared)i
(by)e(all)g(three)h(paths\).)41 b(Then)27 b(we)g(run)g(three)h(dif)n
(ferent)h(e)o(xperiments.)227 317 y(In)c(e)o(xperiment)h(A,)d(the)h
(shared)i(link)f(e)o(xperiences)i(random)f(loss)e(of)h(10\045.)31
b(In)24 b(e)o(xperiment)i(B,)d(the)i(shared)g(e)o(xpe-)227
430 y(riences)h(0\045)d(pack)o(et)i(loss,)f(b)n(ut)g(the)h(binary)g
(branches)h(at)d(the)h(ne)o(xt)g(le)n(v)o(el)g Fe(both)f
Fh(e)o(xperience)j(10\045)e(pack)o(et)h(loss.)30 b(In)227
543 y(e)o(xperiment)22 b(C,)d(the)i(three)g(links)h(closest)g(to)e(the)
h(recei)n(v)o(ers)h(e)o(xperience)h(10\045)d(pack)o(et)i(loss)3112
510 y Fd(1)3151 543 y Fh(.)27 b(Expected)21 b(beha)n(vior:)227
656 y(The)h(multicast)i(\003o)n(ws)e(should)i(produce)g(similar)f(mean)
g(bandwidth)h(in)f(all)f(three)i(e)o(xperiments)g(whether)g(the)f(loss)
227 769 y(is)k(correlated)j(\(A\))c(or)h(uncorrelated)k(\(B)26
b(and)h(C\).)f(This)h(mean)g(bandwidth)i(should)g(be)e(approximately)j
(equal)e(to)227 882 y(that)c(of)g(a)f(TCP)e(connection)27
b(along)e(the)f(same)f(path)h(\(tested)h(later\).)114
1065 y(3.)45 b(Heterogeneous)33 b(loss.)48 b(Referring)31
b(Figure)f(2,)h(reproduce)h(e)o(xperiment)g(\(B\))d(from)g(the)h(loss)g
(correlation)j(e)o(xper)n(-)227 1178 y(iment,)h(b)n(ut)e(reduce)h(the)e
(link)h(loss)h(rate)e(en)h(route)g(to)g(recei)n(v)o(er)h(3)e(to)g
(5\045.)52 b(Then,)33 b(rerun)f(the)g(e)o(xperiment)h(after)227
1291 y(separating)d(the)e(remaining)h(10\045)d(loss)i(se)o(gment)g
(into)g(tw)o(o)f(5\045)f(loss)i(se)o(gments,)h(the)e(second)i(of)e
(which)g(is)g(used)227 1404 y(only)k(by)f(recei)n(v)o(er)h(1.)47
b(In)29 b(the)h(latter)h(con\002guration,)j(recei)n(v)o(er)d(1)e(has)h
(tw)o(o)g(5\045)f(loss)h(se)o(gments,)i(recei)n(v)o(er)f(2)f(has)227
1517 y(a)d(single)i(5\045)d(loss)i(se)o(gment)g(shared)g(with)f(recei)n
(v)o(er)i(1,)e(and)h(recei)n(v)o(er)g(3)f(has)h(an)f(uncorrelated)j
(loss)e(se)o(gment)g(of)227 1630 y(5\045.)j(Expected)26
b(beha)n(vior:)34 b(F)o(or)23 b(single-rate)k(multicast)f(congestion)i
(control,)e(the)f(mean)f(throughput)k(should)e(be)227
1742 y(similar)k(to)e(that)h(of)g(a)f(TCP)f(connection)32
b(to)c(the)h(recei)n(v)o(er)h(e)o(xperiencing)i(10\045)c(loss)i(in)e
(both)i(e)o(xperiments.)46 b(F)o(or)227 1855 y(multi-rate)25
b(congestion)g(control,)g(paths)e(to)g(recei)n(v)o(ers)h(with)f(5\045)f
(loss)h(rates)h(should)g(ideally)g(recei)n(v)o(e)g(commensu-)227
1968 y(rately)h(better)g(throughput)h(than)f(paths)f(to)g(those)g
(recei)n(v)o(ers)i(e)o(xperiencing)h(10\045)c(loss)h(rates.)114
2151 y(4.)45 b(Heterogeneous)32 b(latenc)o(y)e(\(hard\).)44
b(T)-7 b(ak)o(e)28 b(a)g(topology)j(with)d(a)g(single)h(multicast)h
(sender)g(and)f(tw)o(o)f(recei)n(v)o(ers.)44 b(A)227
2264 y(100)25 b(Mbps)f(link)h(with)f(10\045)f(pack)o(et)j(loss)e(is)g
(placed)i(along)f(the)f(shared)i(se)o(gment)e(of)g(the)h(tree.)30
b(The)24 b(independent)227 2377 y(se)o(gments)30 b(of)e(the)g(tree)g
(each)h(ha)n(v)o(e)g(100Mbps)h(bandwidth,)h(1\045)c(pack)o(et)j(loss)e
(rates,)i(b)n(ut)f(ha)n(v)o(e)f(latencies)j(which)227
2490 y(dif)n(fer)24 b(by)f(an)f(order)i(of)f(magnitude.)30
b(The)23 b(link)g(to)g(recei)n(v)o(er)h(1)e(has)h(20ms)g(latenc)o(y)h
(and)f(the)g(link)h(to)e(recei)n(v)o(er)i(2)f(has)227
2603 y(200ms)e(latenc)o(y)-6 b(.)30 b(Measure)21 b(scenarios)i(in)d
(which)h(recei)n(v)o(er)h(1)e(arri)n(v)o(es)h(\002rst)g(and)f(in)h
(which)g(recei)n(v)o(er)g(2)f(arri)n(v)o(es)i(\002rst.)227
2716 y(Desired)k(beha)n(vior:)34 b(Deli)n(v)o(er)24 b(mean)h
(throughput)j(to)c(both)i(recei)n(v)o(ers)g(which)f(is)f(approximately)
k(equal)e(to)e(that)h(of)227 2829 y(a)30 b(TCP)e(connection)33
b(along)f(the)e(higher)i(latenc)o(y)f(path.)50 b(F)o(or)29
b(multi-rate)j(congestion)h(control,)g(simultaneously)227
2942 y(deli)n(v)o(er)25 b(better)g(performance)h(to)d(recei)n(v)o(er)i
(1.)114 3125 y(5.)45 b(Simple)19 b(TCP)d(f)o(airness)k(\(Figure)g(3\).)
27 b(Construct)20 b(a)e(double)i(star)f(topology)i(with)d(senders)i(on)
f(the)g(left)g(and)g(recei)n(v)o(ers)227 3238 y(on)27
b(the)g(right)h(sharing)h(a)d(bottleneck)k(link.)39 b(F)o(or)26
b(each)h(of)g(the)g(bottleneck)j(bandwidths)f(suggested,)h(initiate)f
(tw)o(o)227 3351 y(TCP)f(\003o)n(ws)h(and)i(ten)f(seconds)i(later)l(,)h
(initiate)e(a)f(multicast)i(\003o)n(w)c(to)i(tw)o(o)g(recei)n(v)o(ers.)
50 b(Expected)31 b(beha)n(vior:)45 b(An)227 3464 y(equilibrium)30
b(should)f(quickly)g(be)e(reached)i(in)e(which)g(the)g(multicast)i
(\003o)n(w)d(recei)n(v)o(es)i(approximately)j(one-third)227
3577 y(of)24 b(the)g(a)n(v)n(ailable)h(bandwidth.)114
3760 y(6.)45 b(TCP)18 b(f)o(airness)j(with)f(high)g(multiple)o(xing.)30
b(Same)18 b(topology)k(and)e(general)i(set-up)f(as)e(in)g(the)h(pre)n
(vious)i(e)o(xperiment,)227 3873 y(b)n(ut)36 b(scale)h(up)f(the)g
(number)g(of)g(TCP)d(\003o)n(ws)i(as)g(the)h(bottleneck)j(bandwidth)e
(increases,)k(and)36 b(v)o(erify)h(that)f(the)227 3986
y(multicast)25 b(session)h(still)e(recei)n(v)o(es)h(\(only\))g(its)e(f)
o(air)h(share.)114 4169 y(7.)45 b(Inter)n(-session)23
b(f)o(airness.)29 b(Same)18 b(topology)j(and)e(general)i(set-up)f(as)f
(in)f(the)h(pre)n(vious)i(tw)o(o)d(e)o(xperiments,)k(b)n(ut)d(1\))g
(use)227 4282 y(multicast)j(\003o)n(ws)e(e)o(xclusi)n(v)o(ely)i(and)f
(2\))g(scale)g(up)f(the)h(number)g(of)g(multicast)h(\003o)n(ws)d(and)i
(TCP)d(\003o)n(ws)i(concurrently)-6 b(.)114 4465 y(8.)45
b(Heterogeneous)30 b(f)o(airness.)38 b(Be)o(gin)26 b(with)g(the)g
(double)i(star)f(topology)h(used)f(in)f(the)g(simple)h(TCP)d(f)o
(airness)k(e)o(xper)n(-)227 4578 y(iment.)39 b(No)n(w)26
b(mak)o(e)h(the)g(round-trip)j(times)d(that)h(\003o)n(ws)d(e)o
(xperience)30 b(heterogeneous)h(by)c(v)n(arying)i(the)e(latencies)227
4691 y(on)k(the)h(last)f(hops)h(to)f(the)g(recei)n(v)o(ers.)52
b(W)l(ith)32 b(tw)o(o)e(TCP)f(\003o)n(ws)h(and)h(one)h(multicast)g
(\003o)n(w)e(to)g(tw)o(o)h(recei)n(v)o(ers,)j(al-)227
4804 y(lo)n(w)f(one)i(of)f(each)g(type)h(of)f(recei)n(v)o(er)h(to)f(ha)
n(v)o(e)h(a)e(short)i(last)g(hop)f(\(10ms\))h(and)f(one)h(to)e(ha)n(v)o
(e)i(a)e(long)i(last)g(hop)227 4917 y(\(100ms\).)41 b(Expected)29
b(beha)n(vior:)39 b(F)o(or)26 b(single-rate)k(congestion)g(control,)g
(the)d(multicast)i(throughput)h(should)f(be)227 5030
y(comparable)g(to)d(the)h(mean)f(throughput)k(achie)n(v)o(ed)e(by)e
(the)h(TCP)d(\003o)n(w)h(with)h(the)h(long)g(last)g(hop.)38
b(F)o(or)25 b(multi-rate)227 5143 y(congestion)h(control,)d(the)g(tw)o
(o)f(short)h(recei)n(v)o(ers)h(and)e(the)h(tw)o(o)f(long)h(recei)n(v)o
(ers)g(should)h(ideally)g(ha)n(v)o(e)f(comparable)227
5256 y(mean)h(throughput)j(v)n(alues.)p 0 5313 1560 4
v 105 5368 a Fc(1)134 5400 y Fb(Note)19 b(that)g(the)g(link)g
(bandwidths)h(should)g(be)f(set)g(to)g(be)g(lar)o(ge)g(enough)i(to)d(a)
o(v)o(oid)h(queuing)i(ef)n(fects,)d(i.e.)23 b(100Mbps)1927
5649 y Fh(3)p eop
%%Page: 4 4
4 3 bop 114 91 a Fh(9.)45 b(Augmented)27 b(sanity)f(check)g
(\(scalability\).)37 b(Build)25 b(a)g(binary)h(tree)g(with)f(recei)n(v)
o(ers)h(at)f(the)h(lea)n(v)o(es,)g(scaling)h(the)e(set)227
204 y(of)h(recei)n(v)o(ers)h(up)f(to)g(hundreds)i(of)e(recei)n(v)o
(ers.)37 b(Place)26 b(the)g(source)h(one)f(hop)g(a)o(w)o(ay)g(from)f
(the)i(root)f(of)g(this)g(tree)g(on)227 317 y(a)h(1Mbps)h(link.)41
b(No)n(w)26 b(initiate)j(a)e(multicast)h(session)h(to)f(these)g(recei)n
(v)o(ers.)42 b(After)27 b(30)g(seconds,)j(inject)f(500Kbps)227
430 y(CBR)20 b(cross)i(traf)n(\002c)f(on)g(the)h(shared)h(link)f
(adjoining)h(the)f(source.)29 b(After)22 b(60)f(seconds,)i(reduce)g
(this)f(cross)g(traf)n(\002c)f(to)227 543 y(250Kbps.)37
b(Expected)28 b(beha)n(vior:)36 b(Ideally)28 b(the)e(mean)g(throughput)
j(seen)d(by)g(the)g(recei)n(v)o(ers)i(should)f(be)f(the)g(same)227
656 y(as)c(in)g(the)h(basic)g(sanity)g(check.)30 b(Be)21
b(sure)i(to)f(measure)h(the)g(dif)n(ference)h(in)e(responsi)n(v)o
(eness)k(from)c(the)h(basic)g(sanity)227 769 y(check,)i(and)f
(demonstrate)i(the)e(scalability)i(of)e(the)f(re)n(v)o(erse)i(path)f
(traf)n(\002c)g(\(A)l(CKs,)e(N)m(AKs,)g(etc.\).)68 956
y(10.)46 b(Throughput-loss)32 b(curv)o(e.)43 b(W)l(ith)29
b(a)e(single)j(sender)f(and)f(recei)n(v)o(er)i(setup)f(as)f(in)g(the)g
(basic)h(sanity)g(check)g(\(Figure)227 1069 y(1\),)36
b(set)d(the)h(bottleneck)i(bandwidth)g(to)d(be)g(lar)n(ge)i(\(100)f
(Mbps\).)59 b(Then)33 b(v)n(ary)h(the)g(random)g(loss)g(rate)g(and)g
(the)227 1182 y(round-trip)g(time)e(on)f(the)h(bottleneck)i(link)e(and)
f(plot)h(the)g(throughput-loss)k(curv)o(e)c(of)f(the)h(congestion)i
(control)227 1295 y(protocol.)68 1483 y(11.)46 b(Bandwidth)35
b(absorption.)63 b(Ne)n(v)o(er)33 b(fully)i(speci\002ed.)61
b(W)-7 b(e)33 b(had)h(a)f(half-bak)o(ed)k(idea)d(of)g(using)h(the)f
(basic)h(sanity)227 1596 y(check)28 b(set-up)g(and)f(measuring)h(the)f
(mean)g(throughput)i(achie)n(v)o(ed)g(by)d(a)g(multicast)i(session)h
(vs.)37 b(an)27 b(unspeci\002ed)227 1709 y(deterministic)40
b(VBR)34 b(\003o)n(w)-6 b(.)66 b(The)36 b(main)h(point)g(of)f(this)h(e)
o(xperiment)i(w)o(ould)e(be)f(to)g(demonstrate)j(reasonable)227
1822 y(responsi)n(v)o(eness)28 b(to)23 b(changing)j(netw)o(ork)f
(circumstances.)68 2009 y(12.)46 b(Correct)23 b(loss)f(aggre)o(gation)j
(\(Figure)e(4\).)28 b(Build)22 b(a)f(tree)i(with)e(a)h(sequence)i(of)e
(lossy)h(links)g(f)o(alling)g(from)f(5\045)f(to)h(1\045)227
2122 y(at)k(1\045)g(interv)n(als.)38 b(Place)26 b(a)g(single)h(client)h
(do)n(wnstream)f(of)f(each)h(lossy)g(link)g(\(\002)n(v)o(e)e(in)h
(all\).)37 b(Expected)27 b(beha)n(vior:)227 2235 y(The)21
b(w)o(orst-case)h(client)g(e)o(xperiences)i(15\045)d(pack)o(et)h(loss)g
(and)f(should)h(be)f(accorded)i(an)e(appropriate)j(throughput.)68
2423 y(13.)46 b(Drop-to-zero.)c(Build)28 b(a)e(star)i(topology)h(for)e
(a)g(multicast)i(session)f(with)f(50)g(recei)n(v)o(ers,)j(each)d(e)o
(xperiencing)k(5\045)227 2535 y(pack)o(et)24 b(loss)f(o)o(v)o(er)g
(uncorrelated)j(links.)j(In)22 b(a)g(second)i(e)o(xperiment,)g(let)f
(the)g(50th)g(recei)n(v)o(er)g(e)o(xperience)i(20\045)e(loss)227
2648 y(rather)33 b(than)f(5\045.)52 b(Compare)33 b(the)e(throughput)k
(to)d(the)f(throughput)k(that)d(a)f(TCP)f(\003o)n(w)g(e)o(xperiencing)
35 b(identical)227 2761 y(conditions)k(w)o(ould)d(recei)n(v)o(e.)66
b(Expected)38 b(beha)n(vior:)56 b(The)35 b(session)i(rate)g(should)g
(not)f(drop)g(to)g(zero)g(in)g(either)227 2874 y(case;)j(in)33
b(the)g(second)i(e)o(xperiment,)h(single-rate)g(congestion)g(control)f
(schemes)f(should)h(reduce)f(their)g(rate)f(to)227 2987
y(compensate)26 b(for)e(the)g(lossy)g(recei)n(v)o(er)-5
b(.)68 3175 y(14.)46 b(Anticorrelated)29 b(loss.)35 b(Build)25
b(a)g(star)h(topology)i(for)d(a)g(multicast)i(session)g(with)e(20)h
(recei)n(v)o(ers.)35 b(At)25 b(an)o(y)g(instant)i(in)227
3288 y(time,)e(19)f(of)h(the)f(recei)n(v)o(ers)j(will)d(e)o(xperience)j
(1\045)d(pack)o(et)i(loss,)f(while)g(the)g(twentieth)h(recei)n(v)o(er)f
(will)g(e)o(xperience)227 3401 y(5\045)32 b(pack)o(et)j(loss.)57
b(The)32 b(location)j(of)e(the)g(lossy)h(recei)n(v)o(er)g
Fg(r)l(otates)g Fh(e)n(v)o(ery)g Fa(k)h Fh(seconds,)i(where)c
Fa(k)i Fh(is)e(either)h(0.5,)227 3513 y(5,)28 b(or)f(15.)40
b(This)27 b(particular)i(protocol)h(must)d(be)g(tested)h(with)f
(accurate)j(modeling)e(of)g(IGMP)d(lea)n(v)o(e)j(latenc)o(y)h(and)227
3626 y(throughput)34 b(should)e(again)f(be)g(compared)h(with)e(TCP)f
(\003o)n(ws)g(e)o(xperiencing)34 b(identical)f(conditions.)53
b(Expected)227 3739 y(beha)n(vior:)40 b(W)l(ith)28 b(single-rate)i
(congestion)h(control,)f(the)e(session)h(rate)f(must)g(cater)g(to)g
(the)g(lossy)g(recei)n(v)o(er;)j(with)227 3852 y(multi-rate,)25
b(the)f(e)o(xperiment)h(tests)g(tolerance)h(to)d(IGMP)f(lea)n(v)o(e)j
(latenc)o(y)-6 b(.)68 4040 y(15.)46 b(Multiple)37 b(bottlenecks)i
(\(Figure)d(5\).)65 b(Build)35 b(a)g(binary)i(tree)f(with)f(8)g(lea)n
(v)o(es)i(and)f(label)g(the)g(links)h(of)e(the)h(tree)227
4153 y(with)27 b(their)g(loss)g(rates.)39 b(The)26 b(four)i(lossy)f
(links)h(include)g(the)f(tw)o(o)g(links)g(adjoining)i(the)e(root,)h
(with)e(loss)i(rate)f(4\045)227 4266 y(and)j(1\045)e(respecti)n(v)o
(ely)-6 b(,)34 b(a)28 b(link)i(with)f(2\045)g(loss)g(immediately)i
(belo)n(w)f(the)f(link)h(with)f(4\045)f(loss,)j(and)f(a)f(link)g(with)
227 4379 y(9\045)e(adjoining)j(a)e(client)g(under)h(the)f(1\045)f
(subtree.)43 b(Initiate)29 b(a)e(multicast)i(session)h(with)d(recei)n
(v)o(ers)i(located)h(at)d(all)227 4491 y(eight)k(lea)n(v)o(es,)h(and)f
(run)f(four)g(TCP)e(sessions)k(from)e(the)g(source)h(to)f(a)f(client)i
(in)f(each)h(of)e(the)h(four)h(distinct)h(loss)227 4604
y(re)o(gions)k(\(totaling)g(4\045,)g(6\045,)g(1\045,)f(and)g(10\045\).)
60 b(Expected)36 b(beha)n(vior)g(for)f(multi-rate)g(sessions:)53
b(comparable)227 4717 y(mean)24 b(throughput)j(at)c(each)h(recei)n(v)o
(er)h(for)f(their)g(multicast)h(session)h(and)e(their)g(TCP)d(\003o)n
(w)-6 b(.)68 4905 y(16.)46 b(PIM/IGMP)30 b(issues.)55
b(W)-7 b(e)31 b(suggested)j(a)d(topology)j(which)e(is)g(be)o(yond)h
(the)f(scope)h(of)e(a)h(te)o(xtual)h(writeup.)54 b(The)227
5018 y(main)29 b(point)h(of)e(this)i(comple)o(x)f(scenario)i(w)o(as)d
(to)h(v)o(erify)g(TCP-friendliness)i(e)n(v)o(en)e(when)g(issues)h(of)f
(IGMP)e(and)227 5131 y(PIM)g(latenc)o(y)i(are)g(apparent.)44
b(The)27 b(topology)k(we)c(considered)k(included)f(three)f(nasty)g
(beasts)h(in)d(succession:)42 b(a)227 5244 y(LAN)30 b(which)i(PIM)e
(messages)j(needed)g(to)f(tra)n(v)o(erse)h(\(3)f(seconds\),)j(a)c(high)
i(latenc)o(y)f(link)h(\(100ms\))f(and)g(a)f(last-)227
5357 y(hop)22 b(router)g(which)f(processed)j(IGMP)c(messages)i(\(3-9)g
(seconds\).)30 b(W)-7 b(e)20 b(adv)n(ocated)k(putting)f(a)d(multicast)j
(recei)n(v)o(er)1927 5649 y(4)p eop
%%Page: 5 5
5 4 bop 585 1534 a @beginspecial 0 @llx 0 @lly 452 @urx
254 @ury 3276 @rwi @setspecial
%%BeginDocument: topo1.eps
%!PS-Adobe-2.0 EPSF-2.0
%%Title: topo1.eps
%%Creator: fig2dev Version 3.2 Patchlevel 3c
%%CreationDate: Wed Jun 13 13:51:26 2001
%%For: lorenzo@adsl-64-169-54-2.dsl.snfc21.pacbell.net (Lorenzo Vicisano)=
%%BoundingBox: 0 0 452 254
%%Magnification: 1.0000
%%EndComments
/$F2psDict 200 dict def
$F2psDict begin
$F2psDict /mtrx matrix put
/col-1 {0 setgray} bind def
/col0 {0.000 0.000 0.000 srgb} bind def
/col1 {0.000 0.000 1.000 srgb} bind def
/col2 {0.000 1.000 0.000 srgb} bind def
/col3 {0.000 1.000 1.000 srgb} bind def
/col4 {1.000 0.000 0.000 srgb} bind def
/col5 {1.000 0.000 1.000 srgb} bind def
/col6 {1.000 1.000 0.000 srgb} bind def
/col7 {1.000 1.000 1.000 srgb} bind def
/col8 {0.000 0.000 0.560 srgb} bind def
/col9 {0.000 0.000 0.690 srgb} bind def
/col10 {0.000 0.000 0.820 srgb} bind def
/col11 {0.530 0.810 1.000 srgb} bind def
/col12 {0.000 0.560 0.000 srgb} bind def
/col13 {0.000 0.690 0.000 srgb} bind def
/col14 {0.000 0.820 0.000 srgb} bind def
/col15 {0.000 0.560 0.560 srgb} bind def
/col16 {0.000 0.690 0.690 srgb} bind def
/col17 {0.000 0.820 0.820 srgb} bind def
/col18 {0.560 0.000 0.000 srgb} bind def
/col19 {0.690 0.000 0.000 srgb} bind def
/col20 {0.820 0.000 0.000 srgb} bind def
/col21 {0.560 0.000 0.560 srgb} bind def
/col22 {0.690 0.000 0.690 srgb} bind def
/col23 {0.820 0.000 0.820 srgb} bind def
/col24 {0.500 0.190 0.000 srgb} bind def
/col25 {0.630 0.250 0.000 srgb} bind def
/col26 {0.750 0.380 0.000 srgb} bind def
/col27 {1.000 0.500 0.500 srgb} bind def
/col28 {1.000 0.630 0.630 srgb} bind def
/col29 {1.000 0.750 0.750 srgb} bind def
/col30 {1.000 0.880 0.880 srgb} bind def
/col31 {1.000 0.840 0.000 srgb} bind def
end
save
newpath 0 254 moveto 0 0 lineto 452 0 lineto 452 254 lineto closepath cli=
p newpath
-35.0 253.0 translate
1 -1 scale
/cp {closepath} bind def
/ef {eofill} bind def
/gr {grestore} bind def
/gs {gsave} bind def
/sa {save} bind def
/rs {restore} bind def
/l {lineto} bind def
/m {moveto} bind def
/rm {rmoveto} bind def
/n {newpath} bind def
/s {stroke} bind def
/sh {show} bind def
/slc {setlinecap} bind def
/slj {setlinejoin} bind def
/slw {setlinewidth} bind def
/srgb {setrgbcolor} bind def
/rot {rotate} bind def
/sc {scale} bind def
/sd {setdash} bind def
/ff {findfont} bind def
/sf {setfont} bind def
/scf {scalefont} bind def
/sw {stringwidth} bind def
/tr {translate} bind def
/tnt {dup dup currentrgbcolor
4 -2 roll dup 1 exch sub 3 -1 roll mul add
4 -2 roll dup 1 exch sub 3 -1 roll mul add
4 -2 roll dup 1 exch sub 3 -1 roll mul add srgb}
bind def
/shd {dup dup currentrgbcolor 4 -2 roll mul 4 -2 roll mul
4 -2 roll mul srgb} bind def
/DrawEllipse {
/endangle exch def
/startangle exch def
/yrad exch def
/xrad exch def
/y exch def
/x exch def
/savematrix mtrx currentmatrix def
x y tr xrad yrad sc 0 0 1 startangle endangle arc
closepath
savematrix setmatrix
} def
/$F2psBegin {$F2psDict begin /$F2psEnteredState save def} def
/$F2psEnd {$F2psEnteredState restore end} def
$F2psBegin
%%Page: 1 1
10 setmiterlimit
0.06000 0.06000 sc
%
% Fig objects follow
%
/Courier ff 270.00 scf sf
2625 1890 m
gs 1 -1 sc (1) col0 sh gr
/Courier ff 270.00 scf sf
1725 2115 m
gs 1 -1 sc (1) col0 sh gr
/Courier ff 360.00 scf sf
7050 2025 m
gs 1 -1 sc (r) col0 sh gr
/Courier ff 270.00 scf sf
7275 2115 m
gs 1 -1 sc (1) col0 sh gr
30.000 slw
% Ellipse
n 3546 1954 404 404 0 360 DrawEllipse gs col0 s gr
% Ellipse
n 5496 1954 404 404 0 360 DrawEllipse gs col0 s gr
% Polyline
n 7500 2325 m 7712 1943 l 7487 1568 l 7050 1575 l 6838 1957 l 7063 2332 l=
cp gs col0 s gr =
% Polyline
15.000 slw
n 2175 1950 m
3150 1950 l gs col0 s gr =
% Polyline
n 3975 1950 m
5100 1950 l gs col0 s gr =
% Polyline
n 5925 1950 m
6825 1950 l gs col0 s gr =
% Polyline
30.000 slw
n 1937 2318 m 2149 1936 l 1924 1561 l 1487 1568 l 1275 1950 l 1500 2325 l=
cp gs col0 s gr =
% Polyline
0.000 slw
n 600 0 m 8100 0 l 8100 4200 l 600 4200 l
cp =
/Courier ff 360.00 scf sf
4275 1800 m
gs 1 -1 sc (L) col0 sh gr
/Courier ff 270.00 scf sf
4500 1890 m
gs 1 -1 sc (2) col0 sh gr
/Courier ff 360.00 scf sf
6225 1800 m
gs 1 -1 sc (L) col0 sh gr
/Courier ff 270.00 scf sf
6450 1890 m
gs 1 -1 sc (3) col0 sh gr
/Courier ff 360.00 scf sf
2400 1800 m
gs 1 -1 sc (L) col0 sh gr
/Courier ff 360.00 scf sf
1500 2025 m
gs 1 -1 sc (s) col0 sh gr
$F2psEnd
rs
%%EndDocument
@endspecial 1488 1830 a Fh(Figure)24 b(1:)29 b Fk(single)20
b(bottleneck)p 0 1943 3900 5 v 227 2200 a Fh(behind)i(each)e(of)g
(these)h(obstacles,)i(then)d(running)i(a)e(multicast)h(session)h(to)e
(these)h(recei)n(v)o(ers)g(alongside)i(indi)n(vidual)227
2313 y(TCP)f(\003o)n(ws.)29 b(It)23 b(is)h(of)g(course)h(necessary)h
(to)e(perform)h(hop-by-hop)i(modeling)f(of)e(control)h(messages)h(to)d
(run)i(this)227 2426 y(simulation.)31 b(Expected)25 b(beha)n(vior:)32
b(good)24 b(luck.)0 2818 y Fi(3)119 b(Outcomes)30 b(and)g(T)-11
b(opics)30 b(W)-8 b(e)30 b(Didn't)h(Co)o(v)o(er)0 3025
y Fh(In)20 b(most)f(cases,)i(the)f(e)o(xperiments)i(we)d(ha)n(v)o(e)h
(enumerated)i(here)e(ha)n(v)o(e)g(been)h(designed)h(with)d(a)g(primary)
i(goal)f(of)g(attaining)0 3138 y(an)34 b(appropriate)i(mean)e
(throughput)j(v)n(alue)d(o)o(v)o(er)g(reasonable)j(time)c(scales)i(at)e
(each)i(recei)n(v)o(er)-5 b(.)60 b(W)-7 b(e)33 b(often)h(implicitly)0
3251 y(mak)o(e)29 b(the)h(assumption)i(that)d(compatibility)k(with)c(a)
g(TCP)e(\003o)n(w)h(operating)j(in)f(the)f(same)g(en)l(vironment)k(is)c
(equi)n(v)n(alent)0 3364 y(to)j(a)g(successful)i(outcome.)56
b(Ho)n(we)n(v)o(er)l(,)34 b(we)d(emphasize)j(that)e(we)g(do)g(not)g
(intend)i(for)e(this)g(objecti)n(v)o(e)i(to)e(be)g(attained)0
3477 y(by)d(incurring)i(performance)g(penalties)g(which)f(were)e(not)h
(e)o(xplicitly)i(mentioned)g(in)e(the)g(writeup.)45 b(When)29
b(e)n(v)n(aluating)0 3590 y(a)f(multicast)i(congestion)h(control)f
(protocol,)i(it)c(is)g(essential)j(to)d(measure)i(its)e(other)i
(impacts,)g(such)f(as)f(the)h(amount)g(of)0 3702 y(traf)n(\002c)i(it)f
(generates)k(on)d(the)g(re)n(v)o(erse)h(path,)h(or)e(the)g(amount)g(of)
g(control)i(traf)n(\002c)e(it)f(generates.)53 b(W)-7
b(e)30 b(also)i(recommend)0 3815 y(quantifying)27 b(the)d(protocol')-5
b(s)26 b(responsi)n(v)o(eness,)h(especially)g(the)c(time)h(it)f(tak)o
(es)i(to)e(react)h(to)g(congestion.)141 3928 y(While)g(this)f(list)h
(of)f(e)o(xperiments)i(is)e(incomplete)j(and)e(should)g(be)g(vie)n(wed)
f(as)g(a)g(w)o(ork)g(in)g(progress,)j(there)e(are)f(some)0
4041 y(omissions)k(which)f(are)g(intentional.)38 b(W)-7
b(e)24 b(did)i(not)g(consider)i(simulations)g(which)e(co)o(v)o(er)g(f)o
(ailure)h(cases,)f(including)j(link)0 4154 y(f)o(ailure,)i(recei)n(v)o
(er)f(f)o(ailure)g(and)f(aggre)o(gation)i(node)f(f)o(ailure.)46
b(W)-7 b(e)27 b(also)j(did)f(not)f(consider)j(simulations)g(which)e
(include)0 4267 y(changes)36 b(in)e(the)g(topology)i(during)g
(simulation.)62 b(Finally)-6 b(,)37 b(we)c(did)h(not)g(consider)i
(simulations)h(which)d(studied)i(rich)0 4380 y(netw)o(ork)29
b(topologies.)45 b(An)o(y)27 b(successful)k(multicast)e(congestion)i
(control)f(protocols)g(will)e(be)g(e)o(xpected)i(to)d(address)j(all)0
4493 y(of)23 b(these)i(cases.)1927 5649 y(5)p eop
%%Page: 6 6
6 5 bop 585 1896 a @beginspecial 0 @llx 0 @lly 452 @urx
254 @ury 3276 @rwi @setspecial
%%BeginDocument: topo2.eps
%!PS-Adobe-2.0 EPSF-2.0
%%Title: topo2.eps
%%Creator: fig2dev Version 3.2 Patchlevel 3c
%%CreationDate: Wed Jun 13 13:50:49 2001
%%For: lorenzo@adsl-64-169-54-2.dsl.snfc21.pacbell.net (Lorenzo Vicisano)=
%%BoundingBox: 0 0 452 254
%%Magnification: 1.0000
%%EndComments
/$F2psDict 200 dict def
$F2psDict begin
$F2psDict /mtrx matrix put
/col-1 {0 setgray} bind def
/col0 {0.000 0.000 0.000 srgb} bind def
/col1 {0.000 0.000 1.000 srgb} bind def
/col2 {0.000 1.000 0.000 srgb} bind def
/col3 {0.000 1.000 1.000 srgb} bind def
/col4 {1.000 0.000 0.000 srgb} bind def
/col5 {1.000 0.000 1.000 srgb} bind def
/col6 {1.000 1.000 0.000 srgb} bind def
/col7 {1.000 1.000 1.000 srgb} bind def
/col8 {0.000 0.000 0.560 srgb} bind def
/col9 {0.000 0.000 0.690 srgb} bind def
/col10 {0.000 0.000 0.820 srgb} bind def
/col11 {0.530 0.810 1.000 srgb} bind def
/col12 {0.000 0.560 0.000 srgb} bind def
/col13 {0.000 0.690 0.000 srgb} bind def
/col14 {0.000 0.820 0.000 srgb} bind def
/col15 {0.000 0.560 0.560 srgb} bind def
/col16 {0.000 0.690 0.690 srgb} bind def
/col17 {0.000 0.820 0.820 srgb} bind def
/col18 {0.560 0.000 0.000 srgb} bind def
/col19 {0.690 0.000 0.000 srgb} bind def
/col20 {0.820 0.000 0.000 srgb} bind def
/col21 {0.560 0.000 0.560 srgb} bind def
/col22 {0.690 0.000 0.690 srgb} bind def
/col23 {0.820 0.000 0.820 srgb} bind def
/col24 {0.500 0.190 0.000 srgb} bind def
/col25 {0.630 0.250 0.000 srgb} bind def
/col26 {0.750 0.380 0.000 srgb} bind def
/col27 {1.000 0.500 0.500 srgb} bind def
/col28 {1.000 0.630 0.630 srgb} bind def
/col29 {1.000 0.750 0.750 srgb} bind def
/col30 {1.000 0.880 0.880 srgb} bind def
/col31 {1.000 0.840 0.000 srgb} bind def
end
save
newpath 0 254 moveto 0 0 lineto 452 0 lineto 452 254 lineto closepath cli=
p newpath
-35.0 253.0 translate
1 -1 scale
/cp {closepath} bind def
/ef {eofill} bind def
/gr {grestore} bind def
/gs {gsave} bind def
/sa {save} bind def
/rs {restore} bind def
/l {lineto} bind def
/m {moveto} bind def
/rm {rmoveto} bind def
/n {newpath} bind def
/s {stroke} bind def
/sh {show} bind def
/slc {setlinecap} bind def
/slj {setlinejoin} bind def
/slw {setlinewidth} bind def
/srgb {setrgbcolor} bind def
/rot {rotate} bind def
/sc {scale} bind def
/sd {setdash} bind def
/ff {findfont} bind def
/sf {setfont} bind def
/scf {scalefont} bind def
/sw {stringwidth} bind def
/tr {translate} bind def
/tnt {dup dup currentrgbcolor
4 -2 roll dup 1 exch sub 3 -1 roll mul add
4 -2 roll dup 1 exch sub 3 -1 roll mul add
4 -2 roll dup 1 exch sub 3 -1 roll mul add srgb}
bind def
/shd {dup dup currentrgbcolor 4 -2 roll mul 4 -2 roll mul
4 -2 roll mul srgb} bind def
/DrawEllipse {
/endangle exch def
/startangle exch def
/yrad exch def
/xrad exch def
/y exch def
/x exch def
/savematrix mtrx currentmatrix def
x y tr xrad yrad sc 0 0 1 startangle endangle arc
closepath
savematrix setmatrix
} def
/$F2psBegin {$F2psDict begin /$F2psEnteredState save def} def
/$F2psEnd {$F2psEnteredState restore end} def
$F2psBegin
%%Page: 1 1
10 setmiterlimit
0.06000 0.06000 sc
%
% Fig objects follow
%
/Courier ff 270.00 scf sf
6825 3615 m
gs 1 -1 sc (3) col0 sh gr
/Courier ff 270.00 scf sf
1425 2115 m
gs 1 -1 sc (1) col0 sh gr
% Polyline
30.000 slw
n 1637 2318 m 1849 1936 l 1624 1561 l 1187 1568 l 975 1950 l 1200 2325 l
cp gs col0 s gr =
/Courier ff 360.00 scf sf
2025 1725 m
gs 1 -1 sc (L) col0 sh gr
/Courier ff 270.00 scf sf
2250 1815 m
gs 1 -1 sc (1) col0 sh gr
% Ellipse
n 3171 1954 404 404 0 360 DrawEllipse gs col0 s gr
% Ellipse
n 4971 1054 404 404 0 360 DrawEllipse gs col0 s gr
% Ellipse
n 4971 2854 404 404 0 360 DrawEllipse gs col0 s gr
% Polyline
0.000 slw
n 600 0 m 8100 0 l 8100 4200 l 600 4200 l
cp =
% Polyline
15.000 slw
n 1875 1950 m
2775 1950 l gs col0 s gr =
% Polyline
n 3450 1650 m
4575 1200 l gs col0 s gr =
% Polyline
n 3525 2250 m
4575 2700 l gs col0 s gr =
% Polyline
n 5325 825 m
6375 450 l gs col0 s gr =
% Polyline
n 5325 1275 m
6375 1650 l gs col0 s gr =
% Polyline
n 5325 3075 m
6375 3450 l gs col0 s gr =
% Polyline
30.000 slw
n 7037 2018 m 7249 1636 l 7024 1261 l 6587 1268 l 6375 1650 l 6600 2025 l=
cp gs col0 s gr =
% Polyline
n 7037 818 m 7249 436 l 7024 61 l 6587 68 l 6375 450 l 6600 825 l
cp gs col0 s gr =
% Polyline
n 7037 3818 m 7249 3436 l 7024 3061 l 6587 3068 l 6375 3450 l 6600 3825 l=
cp gs col0 s gr =
/Courier ff 360.00 scf sf
3825 1050 m
gs 1 -1 sc (L) col0 sh gr
/Courier ff 270.00 scf sf
4050 1140 m
gs 1 -1 sc (2) col0 sh gr
/Courier ff 360.00 scf sf
3825 2175 m
gs 1 -1 sc (L) col0 sh gr
/Courier ff 270.00 scf sf
4050 2265 m
gs 1 -1 sc (3) col0 sh gr
/Courier ff 360.00 scf sf
5550 375 m
gs 1 -1 sc (L) col0 sh gr
/Courier ff 270.00 scf sf
5775 465 m
gs 1 -1 sc (4) col0 sh gr
/Courier ff 360.00 scf sf
5550 1125 m
gs 1 -1 sc (L) col0 sh gr
/Courier ff 270.00 scf sf
5775 1215 m
gs 1 -1 sc (5) col0 sh gr
/Courier ff 360.00 scf sf
5550 2925 m
gs 1 -1 sc (L) col0 sh gr
/Courier ff 270.00 scf sf
5775 3015 m
gs 1 -1 sc (6) col0 sh gr
/Courier ff 360.00 scf sf
6600 1725 m
gs 1 -1 sc (r) col0 sh gr
/Courier ff 270.00 scf sf
6825 1815 m
gs 1 -1 sc (2) col0 sh gr
/Courier ff 360.00 scf sf
6600 525 m
gs 1 -1 sc (r) col0 sh gr
/Courier ff 270.00 scf sf
6825 615 m
gs 1 -1 sc (1) col0 sh gr
/Courier ff 360.00 scf sf
6600 3525 m
gs 1 -1 sc (r) col0 sh gr
/Courier ff 360.00 scf sf
1200 2025 m
gs 1 -1 sc (s) col0 sh gr
$F2psEnd
rs
%%EndDocument
@endspecial 1530 2192 a Fh(Figure)24 b(2:)29 b Fk(tree)20
b(of)g(depth)f(3)p 0 2305 3900 5 v 585 4629 a @beginspecial
0 @llx 0 @lly 452 @urx 254 @ury 3276 @rwi @setspecial
%%BeginDocument: topo3.eps
%!PS-Adobe-2.0 EPSF-2.0
%%Title: topo3.eps
%%Creator: fig2dev Version 3.2 Patchlevel 3c
%%CreationDate: Wed Jun 13 14:19:27 2001
%%For: lorenzo@adsl-64-169-54-2.dsl.snfc21.pacbell.net (Lorenzo Vicisano)=
%%BoundingBox: 0 0 452 254
%%Magnification: 1.0000
%%EndComments
/$F2psDict 200 dict def
$F2psDict begin
$F2psDict /mtrx matrix put
/col-1 {0 setgray} bind def
/col0 {0.000 0.000 0.000 srgb} bind def
/col1 {0.000 0.000 1.000 srgb} bind def
/col2 {0.000 1.000 0.000 srgb} bind def
/col3 {0.000 1.000 1.000 srgb} bind def
/col4 {1.000 0.000 0.000 srgb} bind def
/col5 {1.000 0.000 1.000 srgb} bind def
/col6 {1.000 1.000 0.000 srgb} bind def
/col7 {1.000 1.000 1.000 srgb} bind def
/col8 {0.000 0.000 0.560 srgb} bind def
/col9 {0.000 0.000 0.690 srgb} bind def
/col10 {0.000 0.000 0.820 srgb} bind def
/col11 {0.530 0.810 1.000 srgb} bind def
/col12 {0.000 0.560 0.000 srgb} bind def
/col13 {0.000 0.690 0.000 srgb} bind def
/col14 {0.000 0.820 0.000 srgb} bind def
/col15 {0.000 0.560 0.560 srgb} bind def
/col16 {0.000 0.690 0.690 srgb} bind def
/col17 {0.000 0.820 0.820 srgb} bind def
/col18 {0.560 0.000 0.000 srgb} bind def
/col19 {0.690 0.000 0.000 srgb} bind def
/col20 {0.820 0.000 0.000 srgb} bind def
/col21 {0.560 0.000 0.560 srgb} bind def
/col22 {0.690 0.000 0.690 srgb} bind def
/col23 {0.820 0.000 0.820 srgb} bind def
/col24 {0.500 0.190 0.000 srgb} bind def
/col25 {0.630 0.250 0.000 srgb} bind def
/col26 {0.750 0.380 0.000 srgb} bind def
/col27 {1.000 0.500 0.500 srgb} bind def
/col28 {1.000 0.630 0.630 srgb} bind def
/col29 {1.000 0.750 0.750 srgb} bind def
/col30 {1.000 0.880 0.880 srgb} bind def
/col31 {1.000 0.840 0.000 srgb} bind def
end
save
newpath 0 254 moveto 0 0 lineto 452 0 lineto 452 254 lineto closepath cli=
p newpath
-35.0 253.0 translate
1 -1 scale
/cp {closepath} bind def
/ef {eofill} bind def
/gr {grestore} bind def
/gs {gsave} bind def
/sa {save} bind def
/rs {restore} bind def
/l {lineto} bind def
/m {moveto} bind def
/rm {rmoveto} bind def
/n {newpath} bind def
/s {stroke} bind def
/sh {show} bind def
/slc {setlinecap} bind def
/slj {setlinejoin} bind def
/slw {setlinewidth} bind def
/srgb {setrgbcolor} bind def
/rot {rotate} bind def
/sc {scale} bind def
/sd {setdash} bind def
/ff {findfont} bind def
/sf {setfont} bind def
/scf {scalefont} bind def
/sw {stringwidth} bind def
/tr {translate} bind def
/tnt {dup dup currentrgbcolor
4 -2 roll dup 1 exch sub 3 -1 roll mul add
4 -2 roll dup 1 exch sub 3 -1 roll mul add
4 -2 roll dup 1 exch sub 3 -1 roll mul add srgb}
bind def
/shd {dup dup currentrgbcolor 4 -2 roll mul 4 -2 roll mul
4 -2 roll mul srgb} bind def
/DrawEllipse {
/endangle exch def
/startangle exch def
/yrad exch def
/xrad exch def
/y exch def
/x exch def
/savematrix mtrx currentmatrix def
x y tr xrad yrad sc 0 0 1 startangle endangle arc
closepath
savematrix setmatrix
} def
/$F2psBegin {$F2psDict begin /$F2psEnteredState save def} def
/$F2psEnd {$F2psEnteredState restore end} def
$F2psBegin
%%Page: 1 1
10 setmiterlimit
0.06000 0.06000 sc
%
% Fig objects follow
%
/Courier ff 270.00 scf sf
7275 1740 m
gs 1 -1 sc (2) col0 sh gr
/Courier ff 270.00 scf sf
1800 765 m
gs 1 -1 sc (1) col0 sh gr
% Polyline
30.000 slw
n 2012 968 m 2224 586 l 1999 211 l 1562 218 l 1350 600 l 1575 975 l
cp gs col0 s gr =
/Courier ff 360.00 scf sf
7050 675 m
gs 1 -1 sc (r) col0 sh gr
/Courier ff 270.00 scf sf
7275 765 m
gs 1 -1 sc (1) col0 sh gr
% Polyline
n 7500 975 m 7712 593 l 7487 218 l 7050 225 l 6838 607 l 7063 982 l
cp gs col0 s gr =
% Ellipse
n 3546 1954 404 404 0 360 DrawEllipse gs col0 s gr
% Ellipse
n 5496 1954 404 404 0 360 DrawEllipse gs col0 s gr
% Polyline
15.000 slw
n 3975 1950 m
5100 1950 l gs col0 s gr =
% Polyline
0.000 slw
n 600 0 m 8100 0 l 8100 4200 l 600 4200 l
cp =
% Polyline
30.000 slw
n 2012 1943 m 2224 1561 l 1999 1186 l 1562 1193 l 1350 1575 l 1575 1950 l=
cp gs col0 s gr =
% Polyline
n 2012 3743 m 2224 3361 l 1999 2986 l 1562 2993 l 1350 3375 l 1575 3750 l=
cp gs col0 s gr =
% Polyline
n 7500 3750 m 7712 3368 l 7487 2993 l 7050 3000 l 6838 3382 l 7063 3757 l=
cp gs col0 s gr =
% Polyline
n 7500 1950 m 7712 1568 l 7487 1193 l 7050 1200 l 6838 1582 l 7063 1957 l=
cp gs col0 s gr =
% Polyline
15.000 slw
n 2250 600 m
3300 1650 l gs col0 s gr =
% Polyline
n 2250 1575 m
3150 1800 l gs col0 s gr =
% Polyline
n 2250 3375 m
3300 2250 l gs col0 s gr =
% Polyline
n 6900 3375 m
5775 2250 l gs col0 s gr =
% Polyline
n 6825 1575 m
5850 1800 l gs col0 s gr =
% Polyline
n 6825 600 m
5775 1650 l gs col0 s gr =
% Polyline
[90] 0 sd
n 3150 2025 m
2175 2100 l gs col0 s gr [] 0 sd
% Polyline
[90] 0 sd
n 3150 2175 m
2100 2625 l gs col0 s gr [] 0 sd
% Polyline
[90] 0 sd
n 5925 2025 m
6900 2250 l gs col0 s gr [] 0 sd
% Polyline
[90] 0 sd
n 5850 2175 m
6825 2700 l gs col0 s gr [] 0 sd
/Courier ff 360.00 scf sf
1575 1650 m
gs 1 -1 sc (s) col0 sh gr
/Courier ff 270.00 scf sf
1800 1740 m
gs 1 -1 sc (2) col0 sh gr
/Courier ff 360.00 scf sf
1575 3450 m
gs 1 -1 sc (s) col0 sh gr
/Courier ff 270.00 scf sf
1800 3540 m
gs 1 -1 sc (n) col0 sh gr
/Courier ff 360.00 scf sf
7050 3450 m
gs 1 -1 sc (r) col0 sh gr
/Courier ff 270.00 scf sf
7275 3540 m
gs 1 -1 sc (n) col0 sh gr
/Courier ff 360.00 scf sf
7050 1650 m
gs 1 -1 sc (r) col0 sh gr
/Courier ff 360.00 scf sf
1575 675 m
gs 1 -1 sc (s) col0 sh gr
$F2psEnd
rs
%%EndDocument
@endspecial 1587 4925 a Fh(Figure)24 b(3:)29 b Fk(double)19
b(star)p 0 5038 V 1927 5649 a Fh(6)p eop
%%Page: 7 7
7 6 bop 585 1453 a @beginspecial 0 @llx 0 @lly 556 @urx
254 @ury 3276 @rwi @setspecial
%%BeginDocument: topo4.eps
%!PS-Adobe-2.0 EPSF-2.0
%%Title: topo3.eps
%%Creator: fig2dev Version 3.2 Patchlevel 3c
%%CreationDate: Wed Jun 13 13:57:20 2001
%%For: lorenzo@adsl-64-169-54-2.dsl.snfc21.pacbell.net (Lorenzo Vicisano)=
%%BoundingBox: 0 0 556 254
%%Magnification: 1.0000
%%EndComments
/$F2psDict 200 dict def
$F2psDict begin
$F2psDict /mtrx matrix put
/col-1 {0 setgray} bind def
/col0 {0.000 0.000 0.000 srgb} bind def
/col1 {0.000 0.000 1.000 srgb} bind def
/col2 {0.000 1.000 0.000 srgb} bind def
/col3 {0.000 1.000 1.000 srgb} bind def
/col4 {1.000 0.000 0.000 srgb} bind def
/col5 {1.000 0.000 1.000 srgb} bind def
/col6 {1.000 1.000 0.000 srgb} bind def
/col7 {1.000 1.000 1.000 srgb} bind def
/col8 {0.000 0.000 0.560 srgb} bind def
/col9 {0.000 0.000 0.690 srgb} bind def
/col10 {0.000 0.000 0.820 srgb} bind def
/col11 {0.530 0.810 1.000 srgb} bind def
/col12 {0.000 0.560 0.000 srgb} bind def
/col13 {0.000 0.690 0.000 srgb} bind def
/col14 {0.000 0.820 0.000 srgb} bind def
/col15 {0.000 0.560 0.560 srgb} bind def
/col16 {0.000 0.690 0.690 srgb} bind def
/col17 {0.000 0.820 0.820 srgb} bind def
/col18 {0.560 0.000 0.000 srgb} bind def
/col19 {0.690 0.000 0.000 srgb} bind def
/col20 {0.820 0.000 0.000 srgb} bind def
/col21 {0.560 0.000 0.560 srgb} bind def
/col22 {0.690 0.000 0.690 srgb} bind def
/col23 {0.820 0.000 0.820 srgb} bind def
/col24 {0.500 0.190 0.000 srgb} bind def
/col25 {0.630 0.250 0.000 srgb} bind def
/col26 {0.750 0.380 0.000 srgb} bind def
/col27 {1.000 0.500 0.500 srgb} bind def
/col28 {1.000 0.630 0.630 srgb} bind def
/col29 {1.000 0.750 0.750 srgb} bind def
/col30 {1.000 0.880 0.880 srgb} bind def
/col31 {1.000 0.840 0.000 srgb} bind def
end
save
newpath 0 254 moveto 0 0 lineto 556 0 lineto 556 254 lineto closepath cli=
p newpath
-35.0 253.0 translate
1 -1 scale
/cp {closepath} bind def
/ef {eofill} bind def
/gr {grestore} bind def
/gs {gsave} bind def
/sa {save} bind def
/rs {restore} bind def
/l {lineto} bind def
/m {moveto} bind def
/rm {rmoveto} bind def
/n {newpath} bind def
/s {stroke} bind def
/sh {show} bind def
/slc {setlinecap} bind def
/slj {setlinejoin} bind def
/slw {setlinewidth} bind def
/srgb {setrgbcolor} bind def
/rot {rotate} bind def
/sc {scale} bind def
/sd {setdash} bind def
/ff {findfont} bind def
/sf {setfont} bind def
/scf {scalefont} bind def
/sw {stringwidth} bind def
/tr {translate} bind def
/tnt {dup dup currentrgbcolor
4 -2 roll dup 1 exch sub 3 -1 roll mul add
4 -2 roll dup 1 exch sub 3 -1 roll mul add
4 -2 roll dup 1 exch sub 3 -1 roll mul add srgb}
bind def
/shd {dup dup currentrgbcolor 4 -2 roll mul 4 -2 roll mul
4 -2 roll mul srgb} bind def
/DrawEllipse {
/endangle exch def
/startangle exch def
/yrad exch def
/xrad exch def
/y exch def
/x exch def
/savematrix mtrx currentmatrix def
x y tr xrad yrad sc 0 0 1 startangle endangle arc
closepath
savematrix setmatrix
} def
/$F2psBegin {$F2psDict begin /$F2psEnteredState save def} def
/$F2psEnd {$F2psEnteredState restore end} def
$F2psBegin
%%Page: 1 1
10 setmiterlimit
0.06000 0.06000 sc
%
% Fig objects follow
%
/Courier ff 270.00 scf sf
9375 2115 m
gs 1 -1 sc (5) col0 sh gr
/Courier ff 270.00 scf sf
1725 2115 m
gs 1 -1 sc (1) col0 sh gr
/Courier ff 360.00 scf sf
3075 3375 m
gs 1 -1 sc (r) col0 sh gr
/Courier ff 270.00 scf sf
3300 3465 m
gs 1 -1 sc (1) col0 sh gr
30.000 slw
% Ellipse
n 3300 1950 404 404 0 360 DrawEllipse gs col0 s gr
% Ellipse
n 4800 1950 404 404 0 360 DrawEllipse gs col0 s gr
% Ellipse
n 6300 1950 404 404 0 360 DrawEllipse gs col0 s gr
% Ellipse
n 7800 1950 404 404 0 360 DrawEllipse gs col0 s gr
% Polyline
n 1937 2318 m 2149 1936 l 1924 1561 l 1487 1568 l 1275 1950 l 1500 2325 l=
cp gs col0 s gr =
% Polyline
0.000 slw
n 600 0 m 8100 0 l 8100 4200 l 600 4200 l
cp =
% Polyline
15.000 slw
n 2175 1950 m
2925 1950 l gs col0 s gr =
% Polyline
n 3750 1950 m
4425 1950 l gs col0 s gr =
% Polyline
n 5250 1950 m
5850 1950 l gs col0 s gr =
% Polyline
n 6750 1950 m
7425 1950 l gs col0 s gr =
% Polyline
n 8250 1950 m
8925 1950 l gs col0 s gr =
% Polyline
30.000 slw
n 3525 3675 m 3737 3293 l 3512 2918 l 3075 2925 l 2863 3307 l 3088 3682 l=
cp gs col0 s gr =
% Polyline
n 5025 3675 m 5237 3293 l 5012 2918 l 4575 2925 l 4363 3307 l 4588 3682 l=
cp gs col0 s gr =
% Polyline
n 6525 3675 m 6737 3293 l 6512 2918 l 6075 2925 l 5863 3307 l 6088 3682 l=
cp gs col0 s gr =
% Polyline
n 8025 3675 m 8237 3293 l 8012 2918 l 7575 2925 l 7363 3307 l 7588 3682 l=
cp gs col0 s gr =
% Polyline
n 9600 2325 m 9812 1943 l 9587 1568 l 9150 1575 l 8938 1957 l 9163 2332 l=
cp gs col0 s gr =
% Polyline
15.000 slw
n 3300 2400 m
3300 2925 l gs col0 s gr =
% Polyline
n 4800 2400 m
4800 2925 l gs col0 s gr =
% Polyline
n 6300 2400 m
6300 2925 l gs col0 s gr =
% Polyline
n 7800 2400 m
7800 2925 l gs col0 s gr =
/Courier ff 360.00 scf sf
2325 1725 m
gs 1 -1 sc (5%) col0 sh gr
/Courier ff 360.00 scf sf
3825 1800 m
gs 1 -1 sc (4%) col0 sh gr
/Courier ff 360.00 scf sf
5400 1800 m
gs 1 -1 sc (3%) col0 sh gr
/Courier ff 360.00 scf sf
6900 1800 m
gs 1 -1 sc (2%) col0 sh gr
/Courier ff 360.00 scf sf
8400 1800 m
gs 1 -1 sc (1%) col0 sh gr
/Courier ff 360.00 scf sf
4575 3375 m
gs 1 -1 sc (r) col0 sh gr
/Courier ff 270.00 scf sf
4800 3465 m
gs 1 -1 sc (2) col0 sh gr
/Courier ff 360.00 scf sf
6075 3375 m
gs 1 -1 sc (r) col0 sh gr
/Courier ff 270.00 scf sf
6300 3465 m
gs 1 -1 sc (3) col0 sh gr
/Courier ff 360.00 scf sf
7575 3375 m
gs 1 -1 sc (r) col0 sh gr
/Courier ff 270.00 scf sf
7800 3465 m
gs 1 -1 sc (4) col0 sh gr
/Courier ff 360.00 scf sf
9150 2025 m
gs 1 -1 sc (r) col0 sh gr
/Courier ff 360.00 scf sf
1500 2025 m
gs 1 -1 sc (s) col0 sh gr
$F2psEnd
rs
%%EndDocument
@endspecial 1397 1749 a Fh(Figure)24 b(4:)29 b Fk(cascade)20
b(of)g(bottlenecks)p 0 1862 3900 5 v 585 4785 a @beginspecial
0 @llx 0 @lly 479 @urx 429 @ury 3276 @rwi @setspecial
%%BeginDocument: topo5.eps
%!PS-Adobe-2.0 EPSF-2.0
%%Title: topo4.eps
%%Creator: fig2dev Version 3.2 Patchlevel 3c
%%CreationDate: Wed Jun 13 13:49:56 2001
%%For: lorenzo@adsl-64-169-54-2.dsl.snfc21.pacbell.net (Lorenzo Vicisano)=
%%BoundingBox: 0 0 479 429
%%Magnification: 1.0000
%%EndComments
/$F2psDict 200 dict def
$F2psDict begin
$F2psDict /mtrx matrix put
/col-1 {0 setgray} bind def
/col0 {0.000 0.000 0.000 srgb} bind def
/col1 {0.000 0.000 1.000 srgb} bind def
/col2 {0.000 1.000 0.000 srgb} bind def
/col3 {0.000 1.000 1.000 srgb} bind def
/col4 {1.000 0.000 0.000 srgb} bind def
/col5 {1.000 0.000 1.000 srgb} bind def
/col6 {1.000 1.000 0.000 srgb} bind def
/col7 {1.000 1.000 1.000 srgb} bind def
/col8 {0.000 0.000 0.560 srgb} bind def
/col9 {0.000 0.000 0.690 srgb} bind def
/col10 {0.000 0.000 0.820 srgb} bind def
/col11 {0.530 0.810 1.000 srgb} bind def
/col12 {0.000 0.560 0.000 srgb} bind def
/col13 {0.000 0.690 0.000 srgb} bind def
/col14 {0.000 0.820 0.000 srgb} bind def
/col15 {0.000 0.560 0.560 srgb} bind def
/col16 {0.000 0.690 0.690 srgb} bind def
/col17 {0.000 0.820 0.820 srgb} bind def
/col18 {0.560 0.000 0.000 srgb} bind def
/col19 {0.690 0.000 0.000 srgb} bind def
/col20 {0.820 0.000 0.000 srgb} bind def
/col21 {0.560 0.000 0.560 srgb} bind def
/col22 {0.690 0.000 0.690 srgb} bind def
/col23 {0.820 0.000 0.820 srgb} bind def
/col24 {0.500 0.190 0.000 srgb} bind def
/col25 {0.630 0.250 0.000 srgb} bind def
/col26 {0.750 0.380 0.000 srgb} bind def
/col27 {1.000 0.500 0.500 srgb} bind def
/col28 {1.000 0.630 0.630 srgb} bind def
/col29 {1.000 0.750 0.750 srgb} bind def
/col30 {1.000 0.880 0.880 srgb} bind def
/col31 {1.000 0.840 0.000 srgb} bind def
end
save
newpath 0 429 moveto 0 0 lineto 479 0 lineto 479 429 lineto closepath cli=
p newpath
-80.0 484.0 translate
1 -1 scale
/cp {closepath} bind def
/ef {eofill} bind def
/gr {grestore} bind def
/gs {gsave} bind def
/sa {save} bind def
/rs {restore} bind def
/l {lineto} bind def
/m {moveto} bind def
/rm {rmoveto} bind def
/n {newpath} bind def
/s {stroke} bind def
/sh {show} bind def
/slc {setlinecap} bind def
/slj {setlinejoin} bind def
/slw {setlinewidth} bind def
/srgb {setrgbcolor} bind def
/rot {rotate} bind def
/sc {scale} bind def
/sd {setdash} bind def
/ff {findfont} bind def
/sf {setfont} bind def
/scf {scalefont} bind def
/sw {stringwidth} bind def
/tr {translate} bind def
/tnt {dup dup currentrgbcolor
4 -2 roll dup 1 exch sub 3 -1 roll mul add
4 -2 roll dup 1 exch sub 3 -1 roll mul add
4 -2 roll dup 1 exch sub 3 -1 roll mul add srgb}
bind def
/shd {dup dup currentrgbcolor 4 -2 roll mul 4 -2 roll mul
4 -2 roll mul srgb} bind def
/DrawEllipse {
/endangle exch def
/startangle exch def
/yrad exch def
/xrad exch def
/y exch def
/x exch def
/savematrix mtrx currentmatrix def
x y tr xrad yrad sc 0 0 1 startangle endangle arc
closepath
savematrix setmatrix
} def
/$F2psBegin {$F2psDict begin /$F2psEnteredState save def} def
/$F2psEnd {$F2psEnteredState restore end} def
$F2psBegin
%%Page: 1 1
10 setmiterlimit
0.06000 0.06000 sc
%
% Fig objects follow
%
/Courier ff 270.00 scf sf
8850 7815 m
gs 1 -1 sc (8) col0 sh gr
/Courier ff 270.00 scf sf
2100 4665 m
gs 1 -1 sc (1) col0 sh gr
% Polyline
30.000 slw
n 2312 4868 m 2524 4486 l 2299 4111 l 1862 4118 l 1650 4500 l 1875 4875 l=
cp gs col0 s gr =
% Ellipse
n 5721 6304 404 404 0 360 DrawEllipse gs col0 s gr
% Ellipse
n 7221 7204 404 404 0 360 DrawEllipse gs col0 s gr
% Ellipse
n 7221 5404 404 404 0 360 DrawEllipse gs col0 s gr
% Ellipse
n 7221 3604 404 404 0 360 DrawEllipse gs col0 s gr
% Ellipse
n 7221 1804 404 404 0 360 DrawEllipse gs col0 s gr
% Ellipse
n 3846 4504 404 404 0 360 DrawEllipse gs col0 s gr
% Ellipse
n 5721 2779 404 404 0 360 DrawEllipse gs col0 s gr
% Polyline
15.000 slw
n 8400 1350 m
7575 1575 l gs col0 s gr =
% Polyline
n 7575 2025 m
8400 2250 l gs col0 s gr =
% Polyline
n 7575 3375 m
8400 3150 l gs col0 s gr =
% Polyline
n 7575 3825 m
8400 4050 l gs col0 s gr =
% Polyline
n 7575 5175 m
8400 4950 l gs col0 s gr =
% Polyline
n 7575 5625 m
8400 5850 l gs col0 s gr =
% Polyline
n 7575 6975 m
8400 6750 l gs col0 s gr =
% Polyline
n 7575 7425 m
8400 7650 l gs col0 s gr =
% Polyline
n 4125 4200 m
5400 3000 l gs col0 s gr =
% Polyline
n 4125 4800 m
5400 6000 l gs col0 s gr =
% Polyline
n 6000 2475 m
6825 1950 l gs col0 s gr =
% Polyline
n 6000 3075 m
6825 3450 l gs col0 s gr =
% Polyline
n 6075 6075 m
6825 5625 l gs col0 s gr =
% Polyline
n 6000 6600 m
6900 7050 l gs col0 s gr =
% Polyline
n 2550 4500 m
3450 4500 l gs col0 s gr =
% Polyline
30.000 slw
n 9062 1718 m 9274 1336 l 9049 961 l 8612 968 l 8400 1350 l 8625 1725 l
cp gs col0 s gr =
% Polyline
n 9062 2618 m 9274 2236 l 9049 1861 l 8612 1868 l 8400 2250 l 8625 2625 l=
cp gs col0 s gr =
% Polyline
n 9062 3518 m 9274 3136 l 9049 2761 l 8612 2768 l 8400 3150 l 8625 3525 l=
cp gs col0 s gr =
% Polyline
n 9062 4418 m 9274 4036 l 9049 3661 l 8612 3668 l 8400 4050 l 8625 4425 l=
cp gs col0 s gr =
% Polyline
n 9062 5318 m 9274 4936 l 9049 4561 l 8612 4568 l 8400 4950 l 8625 5325 l=
cp gs col0 s gr =
% Polyline
n 9062 6218 m 9274 5836 l 9049 5461 l 8612 5468 l 8400 5850 l 8625 6225 l=
cp gs col0 s gr =
% Polyline
n 9062 7118 m 9274 6736 l 9049 6361 l 8612 6368 l 8400 6750 l 8625 7125 l=
cp gs col0 s gr =
% Polyline
n 9062 8018 m 9274 7636 l 9049 7261 l 8612 7268 l 8400 7650 l 8625 8025 l=
cp gs col0 s gr =
% Polyline
0.000 slw
n 1350 1725 m 8850 1725 l 8850 5925 l 1350 5925 l
cp =
/Courier ff 360.00 scf sf
4800 5250 m
gs 1 -1 sc (1%) col0 sh gr
/Courier ff 360.00 scf sf
4800 3975 m
gs 1 -1 sc (4%) col0 sh gr
/Courier ff 360.00 scf sf
6375 2625 m
gs 1 -1 sc (2%) col0 sh gr
/Courier ff 360.00 scf sf
7725 4875 m
gs 1 -1 sc (9%) col0 sh gr
/Courier ff 360.00 scf sf
8625 1425 m
gs 1 -1 sc (r) col0 sh gr
/Courier ff 270.00 scf sf
8850 1515 m
gs 1 -1 sc (1) col0 sh gr
/Courier ff 360.00 scf sf
8625 2325 m
gs 1 -1 sc (r) col0 sh gr
/Courier ff 270.00 scf sf
8850 2415 m
gs 1 -1 sc (2) col0 sh gr
/Courier ff 360.00 scf sf
8625 3225 m
gs 1 -1 sc (r) col0 sh gr
/Courier ff 270.00 scf sf
8850 3315 m
gs 1 -1 sc (3) col0 sh gr
/Courier ff 360.00 scf sf
8625 4125 m
gs 1 -1 sc (r) col0 sh gr
/Courier ff 270.00 scf sf
8850 4215 m
gs 1 -1 sc (4) col0 sh gr
/Courier ff 360.00 scf sf
8625 5025 m
gs 1 -1 sc (r) col0 sh gr
/Courier ff 270.00 scf sf
8850 5115 m
gs 1 -1 sc (5) col0 sh gr
/Courier ff 360.00 scf sf
8625 5925 m
gs 1 -1 sc (r) col0 sh gr
/Courier ff 270.00 scf sf
8850 6015 m
gs 1 -1 sc (6) col0 sh gr
/Courier ff 360.00 scf sf
8625 6825 m
gs 1 -1 sc (r) col0 sh gr
/Courier ff 270.00 scf sf
8850 6915 m
gs 1 -1 sc (7) col0 sh gr
/Courier ff 360.00 scf sf
8625 7725 m
gs 1 -1 sc (r) col0 sh gr
/Courier ff 360.00 scf sf
1875 4575 m
gs 1 -1 sc (s) col0 sh gr
$F2psEnd
rs
%%EndDocument
@endspecial 1530 5081 a Fh(Figure)k(5:)29 b Fk(tree)20
b(of)g(depth)f(4)p 0 5194 V 1927 5649 a Fh(7)p eop
%%Trailer
end
userdict /end-hook known{end-hook}if
%%EOF
--==_Exmh_14195296130--
>From owner-rmt@listserv.lbl.gov Wed Jun 13 18:30:56 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f5E1UPH24723;
Wed, 13 Jun 2001 18:30:25 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f5E1UN124719
for <rmt@listserv.lbl.gov>; Wed, 13 Jun 2001 18:30:24 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f5E1UN707859
for <rmt@listserv.lbl.gov>; Wed, 13 Jun 2001 18:30:23 -0700 (PDT)
Received: from cisco.com (cypher.cisco.com [171.69.11.18])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f5E1UM607856
for <rmt@lbl.gov>; Wed, 13 Jun 2001 18:30:23 -0700 (PDT)
Received: from localhost (speakman@localhost)
by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id SAA03290;
Wed, 13 Jun 2001 18:30:11 -0700 (PDT)
Message-Id: <200106140130.SAA03290@cisco.com>
To: Jaiwant Mulik <jmulik@unix.temple.edu>
cc: RMT Mailing List <rmt@lbl.gov>
Subject: Re: Status of the GRA draft.
Mime-Version: 1.0 (generated by tm-edit 7.105)
Content-Type: text/plain; charset=US-ASCII
Date: Wed, 13 Jun 2001 18:30:11 -0700
From: Tony Speakman <speakman@cisco.com>
Sender: owner-rmt@lbl.gov
Precedence: bulk
> Has anyone head about any latest developments on the GRA draft ? The
> lastest draft has expired and I have hear it mentioned on the list that
> Tony Speakman wanted to revist it with new author(s).
Yep, we'll re-submit a revision by the London IETF deadline at
the latest, and if it's reviewable any earlier, I'll let
you know.
Tony S
>
> I am doing some research related to GRA, and would like to cite a
> reference.
>
> Any update on the status of the draft or reference to publication based on
> that draft would be highly welcome.
>
> bye,
>
> Jaiwant Mulik
> -----------------------------------------------------------------------
> Email : jmulik@temple.edu (preferred), jmulik@acm.org
> Home page : http://unix.temple.edu/~jmulik
> Office hours : Wednesday, 1:30pm to 3:30pm
> Location : Room 1043/1044, Wachman Hall.
> Phones : (215) 204-3197 (o), (215) 777-4828 (r)
> -----------------------------------------------------------------------
> Lekin woh zindagi he kya, jisme koi namumkin sapna na ho ?
>
> I have not failed. I've just found 10,000 ways that won't work.
> - Thomas Alva Edison
>From owner-rmt@listserv.lbl.gov Wed Jun 13 23:18:40 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f5E6IFS25010;
Wed, 13 Jun 2001 23:18:15 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f5E6ID125006
for <rmt@listserv.lbl.gov>; Wed, 13 Jun 2001 23:18:13 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f5E6IDa04713
for <rmt@listserv.lbl.gov>; Wed, 13 Jun 2001 23:18:13 -0700 (PDT)
Received: from mail.eecis.udel.edu (louie.udel.edu [128.175.2.33])
by SpamWall.lbl.gov (8.11.2/8.11.2) with SMTP id f5E6IC604710
for <rmt@lbl.gov>; Wed, 13 Jun 2001 23:18:12 -0700 (PDT)
Received: from ren.eecis.udel.edu by mail.eecis.udel.edu id aa02889;
14 Jun 2001 02:17 EDT
Date: Thu, 14 Jun 2001 02:17:56 -0400 (EDT)
From: Xinming He <xinming@mail.eecis.udel.edu>
To: rmt@lbl.gov
MMDF-Warning: Parse error in original version of preceding line at mail.eecis.udel.edu
Subject: a question about NCF in PGM
Message-ID: <Pine.GSO.4.31.0106140211570.7924-100000@ren.eecis.udel.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-rmt@lbl.gov
Precedence: bulk
When a network element receives a NAK on the same interface on which it
has previously received a NAK for the same packet, what should it do?
Should it ignore this NAK and not multicast a NCF out (as it has
already sent out a NCF before as a result of the previous NAK) for
optimization, at least for a certain time period? Thanks.
>From owner-rmt@listserv.lbl.gov Thu Jun 14 01:33:50 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f5E8VmI25074;
Thu, 14 Jun 2001 01:31:48 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f5E8Vk125070
for <rmt@listserv.lbl.gov>; Thu, 14 Jun 2001 01:31:47 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f5E8Vkr14919
for <rmt@listserv.lbl.gov>; Thu, 14 Jun 2001 01:31:46 -0700 (PDT)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
by SpamWall.lbl.gov (8.11.2/8.11.2) with SMTP id f5E8Vj614913
for <rmt@lbl.gov>; Thu, 14 Jun 2001 01:31:45 -0700 (PDT)
Received: from hocus.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP
id <g.05757-0@bells.cs.ucl.ac.uk>; Thu, 14 Jun 2001 09:31:39 +0100
To: Lorenzo Vicisano <lorenzo@cisco.com>
cc: rmt@lbl.gov
Subject: Re: Congestion Control BBs
In-reply-to: Your message of "Wed, 13 Jun 2001 16:46:26 PDT." <200106132346.QAA09885@lorenzo-u10.cisco.com>
Date: Thu, 14 Jun 2001 09:31:38 +0100
Message-ID: <11019.992507498@cs.ucl.ac.uk>
From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
Sender: owner-rmt@lbl.gov
Precedence: bulk
a LOT of problems exist in the inter-domain groups
i think we should also specifiy what an CC BB does in the case of
receivers in other domains and broken or poorly behaving inter-domain
multicast (because it is actually an unfortuantell common case.
In message <200106132346.QAA09885@lorenzo-u10.cisco.com>, Lorenzo Vicisano type
d:
>>given the progress made on the CC BBs and the need to
>>move forward with them, I'd like to reopen the discussion
>>on the process to do this.
>>
>>At the last IETF I proposed to try and reach consensus on a
>>"reference simulations" document to be used as a base for
>>discussion in the evaluation of CC algorithms. I also proposed
>>to submit CC BBs as Experimental RFC *first* and move them to
>>standard track only after we have acquired some deployment
>>experience in the network.
>>
>>Anyone has any opinion about this?
>>
>>As for the "reference simulations" document, we could
>>use the attached document as a starting point. It comes
>>from the notes of a meeting attended by some of us and its based on
>>Mark's original notes. The document was edited by John Byers.
>>
>> thanks,
>> Lorenzo
>>
cheers
jon
>From owner-rmt@listserv.lbl.gov Thu Jun 14 02:14:54 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f5E9DRF25203;
Thu, 14 Jun 2001 02:13:27 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f5E9DP125199
for <rmt@listserv.lbl.gov>; Thu, 14 Jun 2001 02:13:25 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f5E9DPc18686
for <rmt@listserv.lbl.gov>; Thu, 14 Jun 2001 02:13:25 -0700 (PDT)
Received: from info.iet.unipi.it (info.iet.unipi.it [131.114.9.184])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f5E9DN618683
for <rmt@lbl.gov>; Thu, 14 Jun 2001 02:13:24 -0700 (PDT)
Received: (from luigi@localhost)
by info.iet.unipi.it (8.9.3/8.9.3) id LAA00663;
Thu, 14 Jun 2001 11:08:57 +0200 (CEST)
(envelope-from luigi)
From: Luigi Rizzo <luigi@info.iet.unipi.it>
Message-Id: <200106140908.LAA00663@info.iet.unipi.it>
Subject: Re: Congestion Control BBs
In-Reply-To: <11019.992507498@cs.ucl.ac.uk> from Jon Crowcroft at "Jun 14, 2001
09:31:38 am"
To: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
Date: Thu, 14 Jun 2001 11:08:57 +0200 (CEST)
CC: Lorenzo Vicisano <lorenzo@cisco.com>, rmt@lbl.gov
X-Mailer: ELM [version 2.4ME+ PL61 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-rmt@lbl.gov
Precedence: bulk
>
> a LOT of problems exist in the inter-domain groups
>
> i think we should also specifiy what an CC BB does in the case of
> receivers in other domains and broken or poorly behaving inter-domain
> multicast (because it is actually an unfortuantell common case.
but... isn't this the wrong layer to approach the problem ?
broken interdomain routing requiring patches in the transport
protocol ?
[that reminds me... in the PicoBSD floppy image for
pgmcc, i rate-limited the sender to avoid ethernet capture
effect that you could see on some hardware...]
cheers
luigi
> In message <200106132346.QAA09885@lorenzo-u10.cisco.com>, Lorenzo Vicisano type
> d:
>
> >>given the progress made on the CC BBs and the need to
> >>move forward with them, I'd like to reopen the discussion
> >>on the process to do this.
> >>
> >>At the last IETF I proposed to try and reach consensus on a
> >>"reference simulations" document to be used as a base for
> >>discussion in the evaluation of CC algorithms. I also proposed
> >>to submit CC BBs as Experimental RFC *first* and move them to
> >>standard track only after we have acquired some deployment
> >>experience in the network.
> >>
> >>Anyone has any opinion about this?
> >>
> >>As for the "reference simulations" document, we could
> >>use the attached document as a starting point. It comes
> >>from the notes of a meeting attended by some of us and its based on
> >>Mark's original notes. The document was edited by John Byers.
> >>
> >> thanks,
> >> Lorenzo
> >>
>
> cheers
>
> jon
>
>
>From owner-rmt@listserv.lbl.gov Thu Jun 14 02:16:58 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f5E9FLg25215;
Thu, 14 Jun 2001 02:15:21 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f5E9FJ125211
for <rmt@listserv.lbl.gov>; Thu, 14 Jun 2001 02:15:19 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f5E9FJL18752
for <rmt@listserv.lbl.gov>; Thu, 14 Jun 2001 02:15:19 -0700 (PDT)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
by SpamWall.lbl.gov (8.11.2/8.11.2) with SMTP id f5E9FI618749
for <rmt@lbl.gov>; Thu, 14 Jun 2001 02:15:18 -0700 (PDT)
Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP
id <g.08358-0@bells.cs.ucl.ac.uk>; Thu, 14 Jun 2001 10:14:56 +0100
To: Luigi Rizzo <luigi@info.iet.unipi.it>
cc: rmt@lbl.gov
Subject: Re: Congestion Control BBs
In-reply-to: Your message of "Thu, 14 Jun 2001 11:08:57 +0200." <200106140908.LAA00663@info.iet.unipi.it>
Date: Thu, 14 Jun 2001 10:14:57 +0100
Message-ID: <9607.992510097@cs.ucl.ac.uk>
From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
Sender: owner-rmt@lbl.gov
Precedence: bulk
In message <200106140908.LAA00663@info.iet.unipi.it>, Luigi Rizzo typed:
>>> a LOT of problems exist in the inter-domain groups
>>> i think we should also specifiy what an CC BB does in the case of
>>> receivers in other domains and broken or poorly behaving inter-domain
>>> multicast (because it is actually an unfortuantell common case.
>>but... isn't this the wrong layer to approach the problem ?
>>broken interdomain routing requiring patches in the transport
>>protocol ?
well, TCP works in the presence of BGP poor convergence, so....
>>[that reminds me... in the PicoBSD floppy image for
>>pgmcc, i rate-limited the sender to avoid ethernet capture
>>effect that you could see on some hardware...]
cool
>>
>>> In message <200106132346.QAA09885@lorenzo-u10.cisco.com>, Lorenzo Vicisano type
>>> d:
>>>
>>> >>given the progress made on the CC BBs and the need to
>>> >>move forward with them, I'd like to reopen the discussion
>>> >>on the process to do this.
>>> >>
>>> >>At the last IETF I proposed to try and reach consensus on a
>>> >>"reference simulations" document to be used as a base for
>>> >>discussion in the evaluation of CC algorithms. I also proposed
>>> >>to submit CC BBs as Experimental RFC *first* and move them to
>>> >>standard track only after we have acquired some deployment
>>> >>experience in the network.
>>> >>
>>> >>Anyone has any opinion about this?
>>> >>
>>> >>As for the "reference simulations" document, we could
>>> >>use the attached document as a starting point. It comes
>>> >>from the notes of a meeting attended by some of us and its based on
>>> >>Mark's original notes. The document was edited by John Byers.
>>> >>
>>> >> thanks,
>>> >> Lorenzo
>>> >>
>>>
>>> cheers
>>>
>>> jon
>>>
>>>
>>
cheers
jon
>From owner-rmt@listserv.lbl.gov Thu Jun 14 02:42:27 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f5E9ekw25298;
Thu, 14 Jun 2001 02:40:46 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f5E9ej125294
for <rmt@listserv.lbl.gov>; Thu, 14 Jun 2001 02:40:45 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f5E9eiM21461
for <rmt@listserv.lbl.gov>; Thu, 14 Jun 2001 02:40:44 -0700 (PDT)
Received: from info.iet.unipi.it (info.iet.unipi.it [131.114.9.184])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f5E9eh621458
for <rmt@lbl.gov>; Thu, 14 Jun 2001 02:40:43 -0700 (PDT)
Received: (from luigi@localhost)
by info.iet.unipi.it (8.9.3/8.9.3) id LAA00749;
Thu, 14 Jun 2001 11:36:23 +0200 (CEST)
(envelope-from luigi)
From: Luigi Rizzo <luigi@info.iet.unipi.it>
Message-Id: <200106140936.LAA00749@info.iet.unipi.it>
Subject: Re: Congestion Control BBs
In-Reply-To: <9607.992510097@cs.ucl.ac.uk> from Jon Crowcroft at "Jun 14, 2001
10:14:57 am"
To: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
Date: Thu, 14 Jun 2001 11:36:23 +0200 (CEST)
CC: rmt@lbl.gov
X-Mailer: ELM [version 2.4ME+ PL61 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-rmt@lbl.gov
Precedence: bulk
> >>but... isn't this the wrong layer to approach the problem ?
> >>broken interdomain routing requiring patches in the transport
> >>protocol ?
>
> well, TCP works in the presence of BGP poor convergence, so....
i would say "happens to work", not because of specific countermeasures,
but because with only one receiver, any breakage is going to hit in
the right place.
But in absence of group membership info, you cannot do much anywyas.
cheers
luigi
-----------------------------------+-------------------------------------
Luigi RIZZO, luigi@iet.unipi.it . Dip. di Ing. dell'Informazione
http://www.iet.unipi.it/~luigi/ . Universita` di Pisa
TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy)
Mobile +39-347-0373137
-----------------------------------+-------------------------------------
>From owner-rmt@listserv.lbl.gov Thu Jun 14 03:11:51 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f5EAANH25353;
Thu, 14 Jun 2001 03:10:23 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f5EAAM125349
for <rmt@listserv.lbl.gov>; Thu, 14 Jun 2001 03:10:22 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f5EAAMC22868
for <rmt@listserv.lbl.gov>; Thu, 14 Jun 2001 03:10:22 -0700 (PDT)
Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31])
by SpamWall.lbl.gov (8.11.2/8.11.2) with SMTP id f5EAAL622865
for <rmt@lbl.gov>; Thu, 14 Jun 2001 03:10:21 -0700 (PDT)
Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP
id <g.12308-0@bells.cs.ucl.ac.uk>; Thu, 14 Jun 2001 11:10:14 +0100
To: Luigi Rizzo <luigi@info.iet.unipi.it>
cc: rmt@lbl.gov
Subject: Re: Congestion Control BBs
In-reply-to: Your message of "Thu, 14 Jun 2001 11:36:23 +0200." <200106140936.LAA00749@info.iet.unipi.it>
Date: Thu, 14 Jun 2001 11:10:15 +0100
Message-ID: <12873.992513415@cs.ucl.ac.uk>
From: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
Sender: owner-rmt@lbl.gov
Precedence: bulk
In message <200106140936.LAA00749@info.iet.unipi.it>, Luigi Rizzo typed:
>>> >>but... isn't this the wrong layer to approach the problem ?
>>> >>broken interdomain routing requiring patches in the transport
>>> >>protocol ?
>>> well, TCP works in the presence of BGP poor convergence, so....
>>i would say "happens to work", not because of specific countermeasures,
>>but because with only one receiver, any breakage is going to hit in
>>the right place.
>>But in absence of group membership info, you cannot do much anywyas.
i guess what i am after is the fact that some of the itner-domain
routes lead to big steps in delays for some receivers and possibly big
steps in reported loss every now and then - we may wany yo specify
smart filters at single rate based senders, or in layer joins in
receivers, in the same way that TCP has all the dupack threshold type
mechanisms...
cheers
jon
>From owner-rmt@listserv.lbl.gov Thu Jun 14 10:58:56 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f5EHvxh26973;
Thu, 14 Jun 2001 10:57:59 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f5EHvv126969
for <rmt@listserv.lbl.gov>; Thu, 14 Jun 2001 10:57:58 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f5EHvv700765
for <rmt@listserv.lbl.gov>; Thu, 14 Jun 2001 10:57:57 -0700 (PDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f5EHrG628770
for <rmt@lbl.gov>; Thu, 14 Jun 2001 10:53:17 -0700 (PDT)
Received: from lorenzo-u10.cisco.com (lorenzo-u10.cisco.com [128.107.162.143])
by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5EHr9922525;
Thu, 14 Jun 2001 10:53:09 -0700 (PDT)
Received: from localhost (lorenzo@localhost) by lorenzo-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id KAA12708; Thu, 14 Jun 2001 10:53:09 -0700 (PDT)
Message-Id: <200106141753.KAA12708@lorenzo-u10.cisco.com>
X-Authentication-Warning: lorenzo-u10.cisco.com: lorenzo owned process doing -bs
X-Mailer: exmh version 2.3.1 01/18/2001 with version: MH 6.8.4 #29[UCI]
To: Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>
cc: Luigi Rizzo <luigi@info.iet.unipi.it>, rmt@lbl.gov
Subject: Re: Congestion Control BBs
In-Reply-To: Your message of "Thu, 14 Jun 2001 11:10:15 BST."
<12873.992513415@cs.ucl.ac.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 14 Jun 2001 10:53:09 -0700
From: Lorenzo Vicisano <lorenzo@cisco.com>
Sender: owner-rmt@lbl.gov
Precedence: bulk
An important point seemed to have emerged from this thread
(and from some private emails): simulations will not be able
to test many issues present in real-networks.
My suggestion of proceeding by steps (first experimental and then
standard track) addresses this somewhat.. however it does not seem
sufficient. Other possible actions are:
a) add a disclaimer in the simulation document
b) add recommendations for designers, to cope with known real-network
issues (we could start making a list by putting together our experiences)
c) encourage real-network tests.. (large scale test are always hard
to setup, 'though).
My opinion about the specific inter-domain issue, is that it
would probably be very hard to design for some current inter-domain
pathologies (e.g. those caused by msdp). I'm not sure if we should
ignore the problem --and hope they will disappear when RMT protocols
start being deployed inter-domain (SSM should help)-- or spend a lot
of efforts in trying to cope with this. For sure I would *not mandate*
that CC algorithms work in the presence of these inter-domain anomalies.
Lorenzo
In message <12873.992513415@cs.ucl.ac.uk>,
Jon Crowcroft writes:
>
> In message <200106140936.LAA00749@info.iet.unipi.it>, Luigi Rizzo typed:
>
> >>> >>but... isn't this the wrong layer to approach the problem ?
> >>> >>broken interdomain routing requiring patches in the transport
> >>> >>protocol ?
>
> >>> well, TCP works in the presence of BGP poor convergence, so....
>
> >>i would say "happens to work", not because of specific countermeasures,
> >>but because with only one receiver, any breakage is going to hit in
> >>the right place.
>
> >>But in absence of group membership info, you cannot do much anywyas.
>
> i guess what i am after is the fact that some of the itner-domain
> routes lead to big steps in delays for some receivers and possibly big
> steps in reported loss every now and then - we may wany yo specify
> smart filters at single rate based senders, or in layer joins in
> receivers, in the same way that TCP has all the dupack threshold type
> mechanisms...
>
> cheers
>
> jon
>From owner-rmt@listserv.lbl.gov Thu Jun 14 11:43:41 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f5EIhTq27200;
Thu, 14 Jun 2001 11:43:29 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f5EIhS127196
for <rmt@listserv.lbl.gov>; Thu, 14 Jun 2001 11:43:28 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f5EIhRX19397
for <rmt@listserv.lbl.gov>; Thu, 14 Jun 2001 11:43:27 -0700 (PDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f5EIhQ619386
for <rmt@lbl.gov>; Thu, 14 Jun 2001 11:43:26 -0700 (PDT)
Received: from lorenzo-u10.cisco.com (lorenzo-u10.cisco.com [128.107.162.143])
by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f5EIhK904693;
Thu, 14 Jun 2001 11:43:20 -0700 (PDT)
Received: from localhost (lorenzo@localhost) by lorenzo-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id LAA12830; Thu, 14 Jun 2001 11:43:20 -0700 (PDT)
Message-Id: <200106141843.LAA12830@lorenzo-u10.cisco.com>
X-Authentication-Warning: lorenzo-u10.cisco.com: lorenzo owned process doing -bs
X-Mailer: exmh version 2.3.1 01/18/2001 with version: MH 6.8.4 #29[UCI]
To: "terry martin" <tmartin@gvnw.com>
cc: rmt@lbl.gov
Subject: Re: Congestion Control BBs
In-Reply-To: Your message of "Thu, 14 Jun 2001 09:00:38 PDT."
<001501c0f4eb$29827000$8f3918ac@talent>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 14 Jun 2001 11:43:20 -0700
From: Lorenzo Vicisano <lorenzo@cisco.com>
Sender: owner-rmt@lbl.gov
Precedence: bulk
In message <001501c0f4eb$29827000$8f3918ac@talent>, "terry martin" writes:
> Can you convert to HTTP?
http://www.employees.org/~lorenzo/mcc/
Lorenzo
>
> Terry Martin
>
> ----- Original Message -----
> From: "Lorenzo Vicisano" <lorenzo@cisco.com>
> To: <rmt@lbl.gov>
> Sent: Wednesday, June 13, 2001 4:46 PM
> Subject: Congestion Control BBs
>
>
> > Hi,
> >
> > given the progress made on the CC BBs and the need to
> > move forward with them, I'd like to reopen the discussion
> > on the process to do this.
> >
> > At the last IETF I proposed to try and reach consensus on a
> > "reference simulations" document to be used as a base for
> > discussion in the evaluation of CC algorithms. I also proposed
> > to submit CC BBs as Experimental RFC *first* and move them to
> > standard track only after we have acquired some deployment
> > experience in the network.
> >
> > Anyone has any opinion about this?
> >
> > As for the "reference simulations" document, we could
> > use the attached document as a starting point. It comes
> > from the notes of a meeting attended by some of us and its based on
> > Mark's original notes. The document was edited by John Byers.
> >
> > thanks,
> > Lorenzo
> >
> >
>From owner-rmt@listserv.lbl.gov Fri Jul 6 04:54:42 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f66BqqJ05110;
Fri, 6 Jul 2001 04:52:52 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f66BqoT05106
for <rmt@listserv.lbl.gov>; Fri, 6 Jul 2001 04:52:50 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f66BqoU19170
for <rmt@listserv.lbl.gov>; Fri, 6 Jul 2001 04:52:50 -0700 (PDT)
Received: from smtp-hub.mrf.mail.rcn.net (smtp-hub.mrf.mail.rcn.net [207.172.4.107])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f66Bqn919165
for <RMT@lbl.gov>; Fri, 6 Jul 2001 04:52:49 -0700 (PDT)
Received: from smtp01.mrf.mail.rcn.net ([207.172.4.60])
by smtp-hub.mrf.mail.rcn.net with esmtp (Exim 3.30 #2)
id 15IUAC-00046e-00
for RMT@lbl.gov; Fri, 06 Jul 2001 07:52:48 -0400
Received: from 66-44-60-143.s143.tnt4.lnhva.md.dialup.rcn.com ([66.44.60.143] helo=eagle)
by smtp01.mrf.mail.rcn.net with esmtp (Exim 3.30 #2)
id 15IUAA-00047S-00
for RMT@LBL.GOV; Fri, 06 Jul 2001 07:52:47 -0400
Message-ID: <261122001756114422270@eagle>
X-EM-Version: 5, 0, 0, 19
X-EM-Registration: #01B0530810E603002D00
X-Priority: 3
Reply-To: res02mg1@gte.net
X-MSMail-Priority: Normal
From: "David C. Dickson" <res02mg1@gte.net>
To: RMT@lbl.gov
Subject: NETWORK AND INFO SYSTEMS SECURITY TRAINING CONFERENCE - WASH DC, 16 JULY 2001
Date: Fri, 6 Jul 2001 07:44:22 -0400
MIME-Version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by SpamWall.lbl.gov id f66BqpT05107
Sender: owner-rmt@lbl.gov
Precedence: bulk
To: RMT@LBL.GOV
NEW SPEAKERS ADDED
PLEASE FORWARD THIS TO YOUR MANAGER OF SYSTEMS SECURITY AND SECURITY TECHNOLOGIES GROUP.
Market*Access International is proud to present ....
NETWORK AND INFORMATION SYSTEMS SECURITY - TRAINING CONFERENCE
AGENCY INTRUSION DETECTION REQUIREMENTS and TECHNOLOGY SOLUTIONS
Date: July 16, 2001
Ronald Reagan Building and International Trade Center
1300 Pennsylvania Avenue
Washington D.C.
Atrium Ballroom
Time: 7:30 AM Registration and Continental Breakfast
Program Starts: 8:30 AM
Wrap-up: 4:15 PM
About this Conference:
As government becomes more dependent on e-business, databases, information storehouses, mission critical information storage and information sharing, new risks are posed. These risks may come from student hackers, foreign governments or foreign military, terrorist organizations or even internal users.
With the new e-Government applications and communications, computer security has emerged as a top issue and challenge. This conference will highlight the risks, opportunities and innovative management and technical approaches to the detection and response to unauthorized intrusions into agency data. The conference will focus on business and military applications and agency plans and programs for securing these applications.
A highlight of this conference will be a section on AGENCY REQUIREMENTS AND NEW TECHNOLOGIES and strategies of coping with unauthorized attempts to compromise agency and DoD systems and data.
SPEAKERS WILL REPRESENT THE FOLLOWING AGENCIES/COMPANIES:
Navy NMCI ^Ö Mark Lavoie ^Ö Communications Officer, CDR, USNR PEO IT (Program Executive Office of Information Technology).
Department of Transportation - Bonnie Fisher ^Ö Director, TASC Millennium Solutions Center
National Science Foundation - Dara Murry ^Ö Director, ADP Security
FBI - James Burrell ^Ö Acting Unit Chief, Computer Investigation Unit
DARPA - Jim Webster ^Ö Manager, Information Assurance Office
GSA/FedCIRC - Larry Hale ^Ö Liaison Director, Federal Computer Incident Response Center
DOJ ^Ö TBD
DISA ^Ö TBD
Gartner ^Ö Keynote ^Ö TBD
Guardant ^Ö Robert Lee ^Ö Director, Senior Principal Consultant
Global Integrity - Errol Weiss, Bill Morgan
Verizon, Federal Network Systems - Char Sample ^Ö
Raytheon ^Ö Barton Abbott ^Ö Director, Information Assurance, Navy /USMC Intranet, Information Strike Force
Symantec - TBD
For more information on speakers and the conference agenda, please visit our web site at www.marketaccess.org.
Who should attend:
* Agency IT Executives, Managers, and Staff
* Agency Security Executives, Managers and Staff
* Agency information systems program managers
* Agency Telecommunications Executives, Managers and Staff
* Tele-work and Telecomm Directors, Managers, and Staff
* Functional area managers
* Systems integrators that support federal agency security requirements
* Hardware and software solutions providers
What you will learn:
* Agency plans, programs and priorities
* Successes and Lessons learned
* Innovative government intrusion detection security approaches and applications
* New technologies and strategies - what is on the drawing boards
* How the military approaches network security and intrusion detection
* Security of remote database management
* How to structure intrusion detection solutions
* Risks, sources of attacks... the internal risk
* Commercial and government best practices
Corporate Sponsors:
* Symantec
* Verizon
* Market*Access
.... others to be announced
Organizational Sponsors:
* Department of Transportation
* INPUT Government
....other sponsors to be announced.
Please register early. The conference area has limited seating available and we anticipate a sell out.
Points of Contact:
* For technical support with this web site, please contact Mr. Parrish Knight, 703/807-2748
* For general information about this event, please contact Ms. Kristen Brooks, 703/807-2745
* For information on sponsorship opportunities & exhibitor arrangements, please contact Ms. Cara Lombardi at 703/807-2743
The registration fee for this important training conference is:
* Government Credit Card or Check in Advance: $395
* Government Training Forms/Invoice: $445
* Industry and Federal Contractors, Payment in Advance: $595
* Industry and Federal Contractors/Invoice: $645
We accept government training forms and government and commercial credit cards (VISA, MC, American Express).
Options:
[1] Phone: 703-807-2745 and speak with Ms. Kristen Brooks.
[2] Email: kbrooks@marketaccess.org
[3] Register online: Use our online booking form to register and pay by credit card electronically. To register, go to www.marketaccess.org.
[4] Fax: registration form to 301-652-0914.
[5] Mail: registration form to:
Market*Access International, Inc.
4301 Wilson Blvd. #1003
Arlington, VA 22203
Sponsorships Available! For sponsorship information, please contact:
Cara Lombardi
Market*Access International
4301 Wilson Blvd. #1003
Arlington, VA 22203
Phone (703) 807-2743
Fax (703) 807-2728
clombardi@marketaccess.org
If you wish to be REMOVED from this list, please REPLY and place REMOVE in the SUBJECT line.
Thank you
>From owner-rmt@listserv.lbl.gov Sat Jul 7 20:28:10 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f683Q1Y25503;
Sat, 7 Jul 2001 20:26:01 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal2.lbl.gov (postal2.lbl.gov [131.243.248.26])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f683Q0T25499
for <rmt@listserv.lbl.gov>; Sat, 7 Jul 2001 20:26:00 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal2.lbl.gov (8.11.2/8.11.2) with ESMTP id f683Px002962
for <rmt@listserv.lbl.gov>; Sat, 7 Jul 2001 20:25:59 -0700 (PDT)
Received: from yourwebsite.com (cd-179-62.ra30.dc.capu.net [64.50.179.62])
by SpamWall.lbl.gov (8.11.2/8.11.2) with SMTP id f683Pv602959
for <rmt@lbl.gov>; Sat, 7 Jul 2001 20:25:58 -0700 (PDT)
Message-Id: <200107080325.f683Pv602959@SpamWall.lbl.gov>
Reply-To: lprice@capu.net
From: lprice@capu.net
To: rmt@lbl.gov
Subject: Ride the Wave of Success!!/FREE MEMBERSHIP!!!
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Date: Sat, 7 Jul 2001 23:21:46 -0400
Sender: owner-rmt@lbl.gov
Precedence: bulk
JOIN NOW FOR FREE!!!
SERIOUS ONLINE INCOME:
NO PRODUCTS TO SELL, NO MEETING TO ATTEND, NO MONTHLY QUOTAS
We are a FOUR 4 YEAR OLD INTERNET BUSINESS AND GROWING VERY FAST. WE HAD OVER
60,000 VIPS SIGNUP COMPANY WIDE IN THE MONTH OF JUNE 2001. SEE WHY THOUSANDS OF
PEOPLE FROM ALL OVER THE WORLD ARE JOINING US AT RECORD RATES.;
THE MEMBERSHIP IS FREE at.
http://onlineprofits.50megs.com. . Enter your first and last name and email address.
Afterwards you will start recieving various emails about company and the business opportunity. Also, you will
become a FREE MEMBER and you can START SHOPPING from at least 70 brand name online stores and
BE ENTERED in our monthly $100 shopping spree!. Take your time and review our company's benefits and
opportunities.
. GUARANTEED minimum commission every month
. you can get 200 members a month added to you downline
. Free Software
. and a strong team support
Now remember anybody that signs up after you will be in your downline. This is very important if you want join
our company and get a monthly check. Don't pass this one up.
GET YOUR FREE MEMBERSHIP AT:
http://onlineprofits.50megs.com --- type in your name and email address and hit the submit botton.
We will talk soon,
GIVIE IT A TRY, YOU HAVE NOTHING TO LOSE AND POSSIBLE A LOT TO GAIN.
>From owner-rmt@listserv.lbl.gov Wed Jul 11 18:47:28 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f6C1iq910783;
Wed, 11 Jul 2001 18:44:52 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f6C1io410779
for <rmt@listserv.lbl.gov>; Wed, 11 Jul 2001 18:44:50 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f6C1ioU23145
for <rmt@listserv.lbl.gov>; Wed, 11 Jul 2001 18:44:50 -0700 (PDT)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f6C1in923140
for <rmt@lbl.gov>; Wed, 11 Jul 2001 18:44:49 -0700 (PDT)
Received: from lorenzo-u10.cisco.com (lorenzo-u10.cisco.com [128.107.162.143])
by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f6C1irj02234;
Wed, 11 Jul 2001 18:44:53 -0700 (PDT)
Received: from localhost (lorenzo@localhost) by lorenzo-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id SAA28759; Wed, 11 Jul 2001 18:44:43 -0700 (PDT)
Message-Id: <200107120144.SAA28759@lorenzo-u10.cisco.com>
X-Authentication-Warning: lorenzo-u10.cisco.com: lorenzo owned process doing -bs
X-Mailer: exmh version 2.3.1 01/18/2001 with version: MH 6.8.4 #29[UCI]
To: rmt@lbl.gov
cc: roger.kermode@motorola.com, lorenzo@cisco.com
Subject: RMT: call for agenda items
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 11 Jul 2001 18:44:43 -0700
From: Lorenzo Vicisano <lorenzo@cisco.com>
Sender: owner-rmt@lbl.gov
Precedence: bulk
The London IETF is approaching and we have requested
two RMT meeting slots. We are now accepting requests
for items to be included in the agenda.
Please remind the usual guidelines when planning your
presentations (provide update and limit technical presentations
to core points of general interest and/or controversial issues).
thanks,
the RMT chairs.
>From owner-rmt@listserv.lbl.gov Tue Jul 17 13:52:31 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f6HKl3327530;
Tue, 17 Jul 2001 13:47:03 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f6HKl2R27526
for <rmt@listserv.lbl.gov>; Tue, 17 Jul 2001 13:47:02 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f6HKl1J00349
for <rmt@listserv.lbl.gov>; Tue, 17 Jul 2001 13:47:01 -0700 (PDT)
Received: from daffy.ee.lbl.gov (daffy.ee.lbl.gov [131.243.1.31])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f6HKl0A00340
for <rmt@lbl.gov>; Tue, 17 Jul 2001 13:47:00 -0700 (PDT)
Received: (from vern@localhost)
by daffy.ee.lbl.gov (8.10.0/8.10.0) id f6HKl0b02414;
Tue, 17 Jul 2001 13:47:00 -0700 (PDT)
Message-Id: <200107172047.f6HKl0b02414@daffy.ee.lbl.gov>
To: rmt@lbl.gov
Subject: Fwd: Note Well
Date: Tue, 17 Jul 2001 13:47:00 PDT
From: Vern Paxson <vern@ee.lbl.gov>
Sender: owner-rmt@lbl.gov
Precedence: bulk
[manually forwarded, since the mailbot decided to bounce it due to
the huge To: field]
------- Forwarded Message
>From owner-rmt Tue Jul 17 10:46:49 2001
From: The IESG <iesg-secretary@ietf.org>
To: AAA Working Group <aaa-wg@merit.edu>,
ACAP Working Group <ietf-acap+@andrew.cmu.edu>,
ADSLMIB Working Group <XDSLMIB@LISTSERV.ECIRALEIGH.COM>,
AFT Working Group <aft@socks.nec.com>,
AGENTX Working Group <agentx@dorothy.bmc.com>,
APEX Working Group <apexwg@invisible.net>,
ATOMMIB Working Group <atommib@research.telcordia.com>,
AVT Working Group <rem-conf@es.net>,
BEEP Working Group <bxxpwg@invisible.net>,
BGMP Working Group <bgmp@catarina.usc.edu>,
BMWG Working Group <bmwg@ietf.org>,
BRIDGE Working Group <bridge-mib@ietf.org>,
CALSCH Working Group <ietf-calendar@imc.org>,
CAT Working Group <ietf-cat-wg@lists.stanford.edu>,
CCAMP Working Group <ccamp@ops.ietf.org>,
CNRP Working Group <cnrp-ietf@lists.netsol.com>,
DELTAV Working Group <ietf-dav-versioning@w3.org>,
DHC Working Group <dhcp-v4@bucknell.edu>,
DIFFSERV Working Group <diffserv@ietf.org>,
DISMAN Working Group <disman@dorothy.bmc.com>,
DNSEXT Working Group <namedroppers@ops.ietf.org>,
DNSOP Working Group <dnsop@cafax.se>, ECM Working Group <ecm@aciri.org>,
EDIINT Working Group <ietf-ediint@imc.org>,
ENTMIB Working Group <entmib@ietf.org>, ENUM Working Group <enum@ietf.org>,
EOS Working Group <eos@ops.ietf.org>, FAX Working Group <ietf-fax@imc.org>,
FRNETMIB Working Group <frnetmib@sunroof.eng.sun.com>,
FTPEXT Working Group <ftp-wg@hethmon.com>,
GEOPRIV Working Group <geopriv@mail.apps.ietf.org>,
GRIP Working Group <grip-wg@uu.net>,
GSMP Working Group <gsmp@revnetworks.com>,
HUBMIB Working Group <hubmib@ietf.org>,
IDMR Working Group <idmr@cs.ucl.ac.uk>,
IDN Working Group <idn@ops.ietf.org>, IDR Working Group <idr@merit.edu>,
IDWG Working Group <idwg-public@zurich.ibm.com>,
IFMIB Working Group <ifmib@ietf.org>,
IMAPEXT Working Group <ietf-imapext@imc.org>,
IMPP Working Group <impp@iastate.edu>, IPCDN Working Group <ipcdn@ietf.org>,
IPFC Working Group <ipfc@standards.gadzoox.com>,
IPNGWG Working Group <ipng@sunroof.eng.sun.com>,
IPO Working Group <ip-optical@lists.bell-labs.com>,
IPORPR Working Group <iporpr@external.cisco.com>,
IPP Working Group <ipp@pwg.org>, IPPM Working Group <ippm@advanced.org>,
IPS Working Group <ips@ece.cmu.edu>,
IPSEC Working Group <ipsec@lists.tislabs.com>,
IPSP Working Group <ipsec-policy@vpnc.org>,
IPSRA Working Group <ietf-ipsra@vpnc.org>,
IPTEL Working Group <iptel@lists.bell-labs.com>,
ISIS Working Group <isis-wg@juniper.net>,
ISSLL Working Group <issll@mercury.lcs.mit.edu>,
ITRACE Working Group <ietf-itrace@research.att.com>,
KINK Working Group <ietf-kink@vpnc.org>,
KRB-WG Working Group <ietf-krb-wg@anl.gov>,
L2TPEXT Working Group <l2tp@l2tp.net>,
LDAPBIS Working Group <ietf-ldapbis@openldap.org>,
LDAPEXT Working Group <ietf-ldapext@netscape.com>,
LDUP Working Group <ietf-ldup@imc.org>,
MALLOC Working Group <malloc@catarina.usc.edu>,
MANET Working Group <manet@itd.nrl.navy.mil>,
MBONED Working Group <mboned@network-services.uoregon.edu>,
MEGACO Working Group <megaco@fore.com>,
MIDCOM Working Group <midcom@ietf.org>,
MMUSIC Working Group <confctrl@isi.edu>,
MOBILEIP Working Group <mobile-ip@sunroof.eng.sun.com>,
MPLS Working Group <mpls@uu.net>,
MSDP Working Group <msdp@antc.uoregon.edu>,
MSEC Working Group <msec@securemulticast.org>,
MSGTRK Working Group <ietf-msgtrk@imc.org>,
MULTI6 Working Group <multi6@ops.ietf.org>,
NASREQ Working Group <nasreq@tdmx.rutgers.edu>,
NAT Working Group <nat@ietf.org>,
NFSV4 Working Group <nfsv4-wg@sunroof.eng.sun.com>,
NGTRANS Working Group <ngtrans@sunroof.eng.sun.com>,
NNTPEXT Working Group <ietf-nntp@academ.com>,
OPENPGP Working Group <ietf-openpgp@imc.org>,
OSPF Working Group <ospf@discuss.microsoft.com>,
OTP Working Group <ietf-otp@research.telcordia.com>,
PILC Working Group <pilc@grc.nasa.gov>,
PIM Working Group <pim@catarina.usc.edu>,
PKIX Working Group <ietf-pkix@imc.org>,
POISSON Working Group <poised@lists.tislabs.com>,
POLICY Working Group <policy@raleigh.ibm.com>,
PPPEXT Working Group <ietf-ppp@merit.edu>,
PPVPN Working Group <ppvpn@zephion.net>,
PROVREG Working Group <ietf-provreg@cafax.se>,
PWE3 Working Group <pwe3@ietf.org>, RAP Working Group <rap@ops.ietf.org>,
RESCAP Working Group <rescap@cs.utk.edu>,
RIP Working Group <ietf-rip@baynetworks.com>,
RMONMIB Working Group <rmonmib@ietf.org>, RMT Working Group <rmt@lbl.gov>,
ROHC Working Group <rohc@cdt.luth.se>,
RSERPOOL Working Group <rserpool@ietf.org>,
RUN Working Group <ietf-run@mailbag.cps.intel.com>,
SACRED Working Group <ietf-sacred@imc.org>,
SEAMOBY Working Group <seamoby@cdma-2000.org>,
SECSH Working Group <ietf-ssh@netbsd.org>,
SIGTRAN Working Group <sigtran@standards.nortelnetworks.com>,
SIMPLE Working Group <simple@mailman.dynamicsoft.com>,
SIP Working Group <sip@ietf.org>, SMIME Working Group <ietf-smime@imc.org>,
SMING Working Group <sming@ops.ietf.org>,
SNMPCONF Working Group <snmpconf@snmp.com>,
SNMPV3 Working Group <snmpv3@lists.tislabs.com>,
SPIRITS Working Group <spirits@lists.bell-lab.com>,
SSM Working Group <ssm-interest@external.cisco.com>,
STIME Working Group <authtime@nist.gov>,
SYSLOG Working Group <syslog-sec@employees.org>,
TEWG Working Group <te-wg@ops.ietf.org>,
TLS Working Group <ietf-tls@lists.certicom.com>,
TN3270E Working Group <tn3270e@list.nih.gov>,
TRADE Working Group <ietf-trade@lists.eListX.com>,
TSVWG Working Group <tsvwg@ietf.org>,
UDLR Working Group <udlr@sophia.inria.fr>,
URN Working Group <urn-ietf@lists.netsol.com>,
USEFOR Working Group <usenet-format@rkive.landfield.com>,
USWG Working Group <uswg@isc.org>,
VPIM Working Group <vpim@lists.neystadt.org>,
VRRP Working Group <vrrp@drcoffsite.com>,
WEBDAV Working Group <w3c-dist-auth@w3.org>,
WEBI Working Group <webi@equinix.com>,
WTS Working Group <www-security@ns2.rutgers.edu>,
XMLDSIG Working Group <w3c-ietf-xmldsig@w3.org>,
ZEROCONF Working Group <zeroconf@merit.edu>
cc: iesg@ietf.org
Subject: Note Well
Message-Id: <E15MYb7-0000LK-00@roam.psg.com>
Sender: Randy Bush <randy@psg.com>
Date: Tue, 17 Jul 2001 13:25:25 -0400
Greetings,
This is the revised text of the NOTE WELL statement.
- ------------------------------------------------------
NOTE WELL
All statements related to the activities of the IETF and addressed to
the IETF are subject to all provisions of Section 10 of RFC 2026, which
grants to the IETF and its participants certain licenses and rights in
such statements.
Such statements include verbal statements in IETF meetings, as well as
written and electronic communications made at any time or place, which
are addressed to:
- the IETF plenary session,
- any IETF working group or portion thereof,
- the IESG, or any member thereof on behalf of the IESG,
- the IAB or any member thereof on behalf of the IAB,
- any IETF mailing list, including the IETF list itself,
any working group or design team list, or any other list
functioning under IETF auspices,
- the RFC Editor or the Internet-Drafts function
Statements made outside of an IETF meeting, mailing list or other
function, that are clearly not intended to be input to an IETF
activity, group or function, are not subject to these provisions.
------- End of Forwarded Message
>From owner-rmt@listserv.lbl.gov Wed Jul 18 04:06:34 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f6IB2sJ20388;
Wed, 18 Jul 2001 04:02:54 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f6IB2qR20384
for <rmt@listserv.lbl.gov>; Wed, 18 Jul 2001 04:02:52 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f6IB2on05378
for <rmt@listserv.lbl.gov>; Wed, 18 Jul 2001 04:02:50 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f6IB2nA05364
for <rmt@lbl.gov>; Wed, 18 Jul 2001 04:02:49 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26996;
Wed, 18 Jul 2001 07:01:54 -0400 (EDT)
Message-Id: <200107181101.HAA26996@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: rmt@lbl.gov
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-rmt-gra-fspec-00.txt,.ps
Date: Wed, 18 Jul 2001 07:01:53 -0400
Sender: owner-rmt@lbl.gov
Precedence: bulk
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Reliable Multicast Transport Working Group of the IETF.
Title : Generic Router Assist - Functional Specification
Author(s) : K. Calvert et al.
Filename : draft-ietf-rmt-gra-fspec-00.txt,.ps
Pages : 15
Date : 17-Jul-01
This draft specifies the functional requirements which any
implementation of GRA must meet. It broadly describes the
context in which GRA operates, and it specifies the contents
of GRA headers and GRA filter specifications. In the process,
it specifies some principles of operation for GRA in the
context of a router.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rmt-gra-fspec-00.txt
Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-rmt-gra-fspec-00.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.
Send a message to:
mailserv@ietf.org.
In the body type:
"FILE /internet-drafts/draft-ietf-rmt-gra-fspec-00.txt".
NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv@ietf.org"
Content-Type: text/plain
Content-ID: <20010717134012.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-rmt-gra-fspec-00.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-rmt-gra-fspec-00.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <20010717134012.I-D@ietf.org>
--OtherAccess--
--NextPart--
>From owner-rmt@listserv.lbl.gov Thu Jul 19 17:10:56 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f6K08Vo28840;
Thu, 19 Jul 2001 17:08:31 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f6K08TR28836
for <rmt@listserv.lbl.gov>; Thu, 19 Jul 2001 17:08:29 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f6K08Sw20581
for <rmt@listserv.lbl.gov>; Thu, 19 Jul 2001 17:08:28 -0700 (PDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f6K08RA20578
for <rmt@lbl.gov>; Thu, 19 Jul 2001 17:08:27 -0700 (PDT)
Received: from lorenzo-u10.cisco.com (lorenzo-u10.cisco.com [128.107.162.143])
by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f6K08DX15867;
Thu, 19 Jul 2001 17:08:14 -0700 (PDT)
Received: from localhost (lorenzo@localhost) by lorenzo-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id RAA01799; Thu, 19 Jul 2001 17:07:44 -0700 (PDT)
Message-Id: <200107200007.RAA01799@lorenzo-u10.cisco.com>
X-Authentication-Warning: lorenzo-u10.cisco.com: lorenzo owned process doing -bs
X-Mailer: exmh version 2.3.1 01/18/2001 with version: MH 6.8.4 #29[UCI]
To: internet-drafts@ietf.org
cc: luby@digitalfountain.com, jgemmell@MICROSOFT.com, luigi@iet.unipi.it,
mjh@aciri.org, J.Crowcroft@cs.ucl.ac.uk, lorenzo@cisco.com, rmt@lbl.gov
Subject: draft-ietf-rmt-bb-lct-01.txt
Mime-Version: 1.0
Content-Type: multipart/mixed ;
boundary="==_Exmh_5195028970"
Date: Thu, 19 Jul 2001 17:07:44 -0700
From: Lorenzo Vicisano <lorenzo@cisco.com>
Sender: owner-rmt@lbl.gov
Precedence: bulk
This is a multipart MIME message.
--==_Exmh_5195028970
Content-Type: text/plain; charset=us-ascii
Please post this draft on the IETF Internet Drafts archive.
This is an update of an existing WG draft (RMT).
Thank you,
Lorenzo Vicisano
--==_Exmh_5195028970
Content-Type: text/plain ; name="draft-ietf-rmt-bb-lct-01.txt"; charset=us-ascii
Content-Description: draft-ietf-rmt-bb-lct-01.txt
Content-Disposition: attachment; filename="draft-ietf-rmt-bb-lct-01.txt"
Internet Engineering Task Force RMT WG
INTERNET-DRAFT M.Luby/Digital Fountain
draft-ietf-rmt-bb-lct-01.txt J.Gemmell/Microsoft
L.Vicisano/Cisco
L.Rizzo/ACIRI and Univ. Pisa
M.Handley/ACIRI
J. Crowcroft/UCL
19 July 2001
Expires: January 2002
Layered Coding Transport:
A massively scalable content delivery transport
Status of this Document
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts.
Internet-Drafts are valid for a maximum of six months and MAY be
updated, replaced, or obsoleted by other documents at any time. It is
inappropriate to use Internet-Drafts as reference material or to cite
them other than as a "work in progress".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html.
This document is a product of the IETF RMT WG. Comments should be
addressed to the authors, or the WG's mailing list at rmt@lbl.gov.
Abstract
This document describes Layered Coding Transport, a massively
scalable reliable content delivery and stream delivery
Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft [Page 1]
^L
INTERNET-DRAFT Expires: January 2002 July 2001
transport, hereafter referred to as LCT. LCT can be used for
multi-rate delivery to large sets of receivers. In LCT,
scalability and congestion control are supported through the
use of layered coding techniques. Coding techniques can be
combined with LCT to provide support for reliability.
Congestion control is receiver driven, and is achieved by
sending packets in the session to multiple ``LCT channels'',
and having receivers join and leave LCT channels (thus
adjusting their reception rate) in reaction to network
conditions in a manner that is network friendly.
Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft [Page 2]
^L
INTERNET-DRAFT Expires: January 2002 July 2001
Table of Contents
1. Introduction. . . . . . . . . . . . . . . . . . . . . . 4
1.1. Related Documents. . . . . . . . . . . . . . . . . . 6
1.2. Environmental Requirements and Considerations. . . . 6
2. General Architecture. . . . . . . . . . . . . . . . . . 8
2.1. Delivery service models. . . . . . . . . . . . . . . 10
2.2. Congestion Control . . . . . . . . . . . . . . . . . 11
3. LCT packets . . . . . . . . . . . . . . . . . . . . . . 11
3.1. LCT packet format. . . . . . . . . . . . . . . . . . 12
3.2. LCT packet header fields . . . . . . . . . . . . . . 13
3.3. Header-Extension Fields. . . . . . . . . . . . . . . 16
4. Procedures. . . . . . . . . . . . . . . . . . . . . . . 19
4.1. Sender Operation . . . . . . . . . . . . . . . . . . 19
4.2. Receiver Operation . . . . . . . . . . . . . . . . . 21
5. Security Considerations . . . . . . . . . . . . . . . . 22
6. IANA Considerations . . . . . . . . . . . . . . . . . . 22
7. Intellectual Property Issues. . . . . . . . . . . . . . 22
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . 23
9. Authors' Addresses. . . . . . . . . . . . . . . . . . . 24
10. Full Copyright Statement . . . . . . . . . . . . . . . 26
Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft [Page 3]
^L
INTERNET-DRAFT Expires: January 2002 July 2001
1. Introduction
This document describes a massively scalable reliable content delivery
and stream delivery transport, Layered Coding Transport (LCT), for
multi-rate content delivery primarily designed to be used with the IP
multicast network service, but MAY also be used with other basic
underlying network or transport services such as unicast UDP. LCT
supports both reliable and unreliable delivery, and supports congestion
control mechanisms which conform to RFC2357.
LCT is a building block as defined in RFC3048. Complete protocol
instantiations MAY be built by combining the LCT framework with other
components. A complete protocol instantiation that uses LCT MUST
include a congestion control protocol that is compatible with LCT and
that conforms to RFC2357. A complete protocol instantiation that uses
LCT MAY include a scalable reliability protocol that is compatible with
LCT, it MAY include an session control protocol that is compatible with
LCT, and it MAY include other protocols such as security protocols.
LCT is presumed to be used with an underlying network or transport
service that is a "best effort" service that does not guarantee packet
reception, packet reception order, and which does not have any support
for flow or congestion control. For example, the Any-Source Multicast
(ASM) model of IP multicast as defined in RFC1112 is such a "best
effort" network service. While the basic service provided by RFC1112 is
largely scalable, providing congestion control or reliability should be
done carefully to avoid severe scalability limitations, especially in
presence of heterogeneous sets of receivers.
Scalability refers to the behavior of the protocol in relation to the
number of receivers and network paths, their heterogeneity, and the
ability to accommodate dynamically variable sets of receivers.
Scalability limitations can come from memory or processing requirements,
or from the amount of packet traffic generated by the protocol. In
turn, such limitations may be a consequence of the features that a
complete reliable content delivery or stream delivery protocol is
expected to provide.
Congestion control refers to the ability of the protocol to adapt its
throughput to the available bandwidth on the path to the receivers, and
to share bandwidth fairly with competing flows such as TCP. It is
REQUIRED that protocols implement some form of congestion control on
each session so that they not compete unfairly with existing and
adaptive protocols such as TCP.
For multi-rate protocols, the sender typically sends packets at a
constant aggregate rate to multiple channels, but individual receivers
adjust which portion of these packets they attempt to receive by
Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft Section 1. [Page 4]
^L
INTERNET-DRAFT Expires: January 2002 July 2001
adjusting which set of channels they are joined to at each point in time
depending on the available bandwidth between the receiver and the
sender, but independent of all other receivers. Thus, for multi-rate
protocols, the packet reception rate of each receiver may vary
dynamically according to the available bandwidth between each receiver
and the sender, independent of the other receivers. For single-rate
protocols, the sender typically sends packets to one channel at variable
rates over time depending on feedback from receivers, and all receivers
attempt to receive all packets transmitted by the sender at all points
in time. Thus, for single-rate protocols, the packet reception rate of
all receivers may vary dynamically over time in exactly the same way
dependent on the feedback of other receivers to the sender. Generally,
a multi-rate protocol is preferable to a single-rate protocol in a
heterogeneous receiver environment, but only if it can be achieved
without sacrificing scalability.
Layered coding refers to the ability to produce a coded stream that can
be split into multiple layers that can be sent to different channels.
The coded stream can be generated either from a fixed piece of content,
or from an ongoing data stream, and has the property that the quality
experienced by a receiver (in terms of quality of playout, or overall
transfer speed) is proportional to how many of the layers the receiver
is joined to. LCT MAY be combined with a reliability protocol such as
the general class of protocols described in [7]. LCT MUST be combined
with a congestion control protocol that is compliant with RFC2357, and
this MAY be either single-rate or multi-rate congestion control over the
entire session. It is most compelling to use LCT in conjunction with a
layered congestion control protocol such as the class of protocols
described in [9], and specified in [9], which are multi-rate congestion
control protocols.
The concept of layered coding was first introduced with reference to
audio and video streams. For example, the information associated with a
TV broadcast can be partitioned into three layers, corresponding to
black and white, color, and HDTV quality. Receivers can experience
different quality without the need for the sender to replicate
information in the different layers.
The concept of layered coding can be naturally extended to reliable
content delivery protocols when Forward Error Correction (FEC)
techniques are used for coding the data stream [12] [10] [3] [14] [15]
[1]. By using FEC, the data stream is transformed in such a way that
reconstruction of a data object does not depend on the reception of
specific data packets, but only on the number of different packets
received. As a result, by increasing the number of layers a receiver is
receiving from, the receiver can reduce the transfer time accordingly.
More details on the use of FEC for reliable content delivery can be
found in [6]. Reliable protocols aim at giving guarantees on the
Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft Section 1. [Page 5]
^L
INTERNET-DRAFT Expires: January 2002 July 2001
reliable delivery of data from the sender to the intended recipients.
Guarantees vary from simple packet data integrity to reliable delivery
of a precise copy of a data object to all intended recipients. Several
reliable content delivery protocols have been built on top of IP
multicast, but scalability was not a design goal for many of them. In
some cases, scalability is achieved by introducing changes to routers or
other infrastructure (see for example [13] ), an approach which has an
impact on near term deployment across the Internet.
Two of the key difficulties in scaling reliable content delivery using
IP multicast are dealing with the amount of data that flows from
receivers back to the sender, and the associated response (generally
data retransmissions) from the sender. Protocols that avoid any such
feedback, and minimize the amount of retransmissions, can be massively
scalable. LCT relies on the availability of FEC codes or a layered
codec to achieve reliability with little or no feedback.
In this document we present the architecture and abstract LCT packet
structure, and illustrate its support for multi-rate layered congestion
control.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119.
1.1. Related Documents
A more in-depth description of the use of FEC in Reliable Multicast
Transport (RMT) protocols is given in [6]. Some of the FEC codecs that
MAY be used by LCT for reliable content delivery are specified in [7].
LCT reserves opaque header fields that can be used to transport
information related to the payload encoding.
Implementors of LCT MUST also implement congestion control in accordance
to RFC2357, where the congestion control is over the entire session.
Some possible schemes are specified in [9]. LCT reserves opaque header
fields that can be used by the congestion control scheme to transport
information related to congestion control.
It is RECOMMENDED that LCT implementors use some authentication scheme
to protect the protocol from attacks. An example of a possibly suitable
scheme is described in [11].
1.2. Environmental Requirements and Considerations
LCT is intended for congestion controlled, multi-rate delivery of
objects and streams (both reliable content delivery and streaming of
Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft Section 1.2. [Page 6]
^L
INTERNET-DRAFT Expires: January 2002 July 2001
multimedia information).
LCT is most applicable for delivery of objects or streams of substantial
length, i.e., objects or streams that range in length from hundreds of
kilobytes to many gigabytes, and whose transfer time is in the order of
tens of seconds or more.
LCT is directly applicable to all multicast enabled networks, including
asymmetric networks, wireless networks, and satellite networks. Thus,
the inherent raw scalability of LCT is unlimited. However, when other
specific applications are built on top of LCT, then these applications
by their very nature may limit scalability. For example, if an
application requires receivers to retrieve out of band information in
order to join a session, or an application allows receivers to send
requests back to the sender in order to extend an ongoing session, then
the scalability of the application is limited by the ability to send,
receive, and process this additional data.
LCT requires that the underlying network or transport layer can deliver
and demultiplex LCT packets for a given LCT session, and supply packet
length information to the LCT receiver. In IP networks, this is often
achieved by using UDP, or any protocol that can provide an equivalent
service, as the underlying transport protocol.
In this document, we refer to the original multicast service model
defined in RFC1112 as Any-Source Multicast, or ASM for short. We refer
to the multicast service model defined in [5] as Source-Specific
Multicast, or SSM for short. LCT does not require reverse multicast
connectivity, i.e. LCT receivers do not send multicast traffic. As
such, LCT works with both ASM and SSM.
The definition of an LCT channel used throughout this document is
slightly different with ASM and with SSM. When using ASM, a sender S
sends LCT packets to a multicast group G, and the LCT channel address
consists of the pair (S,G), where S is the IP address of the sender and
G is a multicast group address. When using SSM, a sender S sends LCT
packets to an SSM channel (S,G), and the LCT channel address coincides
with the SSM channel address.
SSM is more attractive to deployment of LCT than ASM for several
reasons. First, a sender may allocate and use several LCT channels in a
session, sessions may come and go dynamically. A sender can locally
allocate unique SSM channel addresses, and this makes allocation of LCT
channel addresses easy with SSM. To allocate LCT channel addresses
using ASM, the sender must uniquely chose the ASM multicast group
address across the scope of the group, and this makes allocation of LCT
channel addresses more difficult with ASM.
Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft Section 1.2. [Page 7]
^L
INTERNET-DRAFT Expires: January 2002 July 2001
In general SSM performs well even in presence of very large and
dynamically changing receiver sets. Changes in the multicast tree
topology with SSM are light weight operations (a new branch from the
receiver towards S grows when a receiver joins, and the branch is
deleted when the receiver leaves), whereas with ASM changes can be
heavier weight (involving transitions from a (*,G)-tree rooted at an RP
to the tree rooted at S). This efficiency is important when a
congestion control protocol is used with LCT that relies upon joining
and leaving channels to nimbly increase and decrease reception rate.
LCT channels and SSM channels coincide, and thus the receiver will only
receive packets sent to the requested LCT channel. With ASM, the
receiver joins an LCT channel by joining a multicast group G, and all
packets sent to G, regardless of the sender, may be received by the
receiver. In either case, receivers should use mechanisms to filter out
packets from unwanted sources. Thus, SSM has compelling security
advantages over ASM for prevention of denial of service attacks.
LCT also requires receivers to obtain Session Description Information
before joining a session, as described in Section 4.1. The session
description could be in a form such as SDP as defined in RFC2327, or XML
metadata, or HTTP/Mime headers as defined in RFC2068, and distributed
with SAP [4], using RCCP [8], HTTP, or in other ways.
The particular layered encoder and congestion control protocols used
with LCT have an impact on the performance and applicability of LCT.
For example, some layered encoders used for video and audio streams can
produce a very limited number of substreams, thus providing a very
coarse control in the reception rate of packets by receivers in a
session. When LCT is used for reliable data transfer, some FEC codecs
are inherently limited in the size of the object they can encode, and
for objects larger than this size the reception overhead on the
receivers can grow substantially.
As another example, some networks are not amenable to some congestion
control protocols that could be used with LCT. In particular, for a
satellite or wireless network, there may be no mechanism for receivers
to effectively reduce their reception rate since there may be a fixed
transmission rate allocated to the session.
2. General Architecture
An LCT session comprises all LCT packets sent to one or more LCT
channels from a single sender, and pertaining to the transmission of one
or more objects that can be of interest for the receivers.
For example, an LCT session could be used to deliver a TV channel using
Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft Section 2. [Page 8]
^L
INTERNET-DRAFT Expires: January 2002 July 2001
three channels. Receiving the first channel could allow black and white
reception, receiving the first two channels would permit color
reception, whereas receiving the set of three channels delivers HDTV
quality images. Objects in this example could correspond to individual
programs (movies, news, commercial) being transmitted.
As another example, a reliable LCT session could be used to reliably
deliver hourly-updated weather maps (objects) using ten LCT channels at
different rates, using FEC coding. A receiver MAY join and concurrently
receive LCT packets from subsets of these channels, until it has enough
packets in total to recover the object, then leave the session (or
remain there listening to control information only) until it is time to
receive the next object. In this case, the quality metric is the time
required to receive each object.
Before joining a session, the receivers MUST obtain a session
description, which MUST include the relevant session parameters needed
by a receiver to participate in the session. The session description is
determined and agreed upon by the senders, and typically communicated to
the receivers out of band. In some cases, part of the session
description MAY be included in the LCT packet.
An encoder MAY be used to generate the data that is placed in the LCT
packet payload in order to provide reliability. A suitable decoder is
used to reproduce the original information from the payload. There MAY
be a reliability packet header that follows the LCT packet header if
such an encoder and decoder is used. The reliability packet header
helps to describe the encoding data carried in the payload of the
packet. The format of the reliability packet header depends on the
coding used, and this is negotiated out-of-band. As an example, one of
the FEC packet headers described in [7] could be used.
For LCT, when layered congestion control is used, congestion control is
achieved by sending LCT packets associated with a given session to
several LCT channels. Individual receivers dynamically join one or more
of these channels, according to the network congestion as seen by the
receiver. LCT packet headers include an opaque field which MUST be used
to convey congestion control information to the receivers. The actual
congestion control scheme to use with LCT is negotiated out-of-band.
Some examples of congestion control protocols that MAY be suitable for
content delivery are described in [9]. Other congestion controls MAY be
suitable when LCT is used for a streaming application.
LCT can be used with other congestion control protocols such as the one
described in [14], or router-assisted schemes where the selection of
which packets to forward is performed by routers. This latter approach
potentially allows for finer grain congestion control and a faster
reaction to network congestion, but requires changes to the router
Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft Section 2. [Page 9]
^L
INTERNET-DRAFT Expires: January 2002 July 2001
infrastructure. See [2] for a preliminary design description. We do
not discuss this approach further in this document.
2.1. Delivery service models
LCT can support several different delivery service models. Two examples
are briefly described here.
Push service model.
One way a push service model can be used for reliable content delivery
is to deliver a series of objects. For example, a receiver could join
the session and dynamically adapt the number of LCT channels the
receiver is joined to until enough packets have been received to
reconstruct an object. After reconstructing the object the receiver may
stay in the session and wait for the transmission of the next object.
The push model is particularly attractive in satellite networks and
wireless networks. In these cases, a session may consist of one fixed
rate LCT channel.
On-demand content delivery model.
For an on-demand content delivery service model, senders typically
transmit for some given time period selected to be long enough to allow
all the intended receivers to join the session and recover the object.
For example a popular software update might be transmitted using LCT for
several days, even though a receiver may be able to complete the
download in one hour total of connection time, perhaps spread over
several intervals of time.
In this case the receivers join the session, and dynamically adapt the
number of LCT channels they subscribe to (and the reception quality)
according to the available bandwidth. Receivers then drop from the
session when they have received enough packets to recover the object.
As an example, assume that an object is 50 MB. The sender could set the
data rate on the lowest LCT channel to 50 1KB packets per second, so
that receivers using just this LCT channel could complete reception of
the object in 1,000 seconds in absence of loss, and would be able to
complete reception even in presence of some substantial amount of losses
with the use of coding for reliability. Furthermore, the sender could
use a number of LCT channels such that the aggregate data rate when
using all LCT channels is 1,000 1KB packets per second, so that a
receiver could be able to complete reception of the object in as little
Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft Section 2.1. [Page 10]
^L
INTERNET-DRAFT Expires: January 2002 July 2001
50 seconds (assuming no loss and that the congestion control mechanism
immediately converges to the use of all LCT channels).
Other service models.
There are many other delivery service models that LCT can be used for
that are not covered above. As examples, a live streaming or an on-
demand archival content streaming service model. The description of the
many potential applications, the appropriate delivery service model, and
the additional mechanisms to support such functionalities when combined
with LCT is beyond the scope of this document. This document only
attempts to describe the minimal common scalable elements to these
diverse applications using LCT as the delivery transport.
2.2. Congestion Control
The specific congestion control protocol to be used for LCT sessions
depends on the type of content to be delivered. While the general
behavior of the congestion control protocol is to reduce the throughput
in presence of congestion and gradually increase it in the absence of
congestion, the actual dynamic behavior (e.g. response to single losses)
can vary.
Some possible congestion control protocols for reliable content delivery
using LCT are described in [9]. Different delivery service models might
require a different congestion control protocols.
3. LCT packets
The type of packet used by LCT sessions is "LCT Packet". LCT packets
are sent by senders to LCT channels.
Some instances of LCT sessions MAY require the generation of feedback
from the receivers to the sender. However, the mechanism for doing this
is outside the scope of LCT.
The LCT packet format described in this document is intended to be used
in conjunction with the UDP transport protocol as defined in RFC768 or
other transport protocols that satisfy the requirements stated in
Section 1.2, specifically about demultiplexing and delivery of packet
size information.
LCT packets consist of an LCT packet header and an OPTIONAL LCT packet
payload, as shown in Figure 1. When present, the LCT packet payload
Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft Section 3. [Page 11]
^L
INTERNET-DRAFT Expires: January 2002 July 2001
immediately follows the LCT packet header. The LCT packet payload MAY
contain headers for other protocols, such as reliability protocols.
LCT packet headers have variable size, which is specified by a length
field in the third byte of the header. In the LCT packet header, all
integer fields are carried in "big-endian" or "network order" format,
that is, most significant byte (octet) first. Bits designated as
"padding" or "reserved" (r) MUST by set to 0 by senders and ignored by
receivers. Unless otherwise noted, numeric constants in this
specification are in decimal (base 10).
3.1. LCT packet format
The format of LCT packets is depicted in Figure 1.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V | r | I |S|E|X|A|B| HDR_LEN | Codepoint (CP)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Congestion Control Information (CCI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transport Object Identifier (TOI, if I >= 1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TOI continued (if I >= 2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TOI continued (if I = 3) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TOI continued (if I = 3) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Current Time (SCT, if S = 1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Expected Residual Time (ERT, if E = 1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Header Extensions (if X = 1 ) |
| |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| |
| Payload |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 - LCT packet format
Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft Section 3.1. [Page 12]
^L
INTERNET-DRAFT Expires: January 2002 July 2001
3.2. LCT packet header fields
The function each field in LCT packet headers is the following. Fields
marked as "1" mean that the corresponding bits MUST be set to "1" by the
generating agent. Fields marked as "r" or "0" mean that the
corresponding bits MUST be set to "0" by the generating agent.
LCT version number (V): 4 bits
Indicates the LCT protocol version. The LCT version number for
this specification is 0.
Reserved (r): 5 bits
Reserved for future use. A sender MUST set these bits to zero and
a receiver MUST ignore these bits.
Transport Object Identifier flag (I): 2 bits
I=0 indicates no Transport Object Identifier (TOI) field is
present.
I=1 indicates that a 32-bit TOI field is present.
I=2 indicates that a 64-bit TOI field is present.
I=3 indicates that a 128-bit TOI field is present.
The TOI field indicates which object within the session this LCT
packet pertains to.
Sender Current Time present flag (S): 1 bit
S = 0 indicates that the Sender Current Time (SCT) field is not
present.
S = 1 indicates that the SCT field is present.
The SCT is inserted by senders to indicate to receivers how long
the session has been in progress.
Expected Residual Time present flag (E): 1 bit
E = 0 indicates that the Expected Residual Time (ERT) field is not
present.
E = 1 indicates that the ERT field is present.
The ERT is inserted by senders to indicate to receivers how much
longer the session will continue.
Senders MUST NOT set E = 1 when the ERT for the session is more
Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft Section 3.2. [Page 13]
^L
INTERNET-DRAFT Expires: January 2002 July 2001
than 2^32-1 time units (approximately 49 days), where time is
measured in units of milliseconds.
Header extension present flag (X): 1 bit
X = 0 indicates no Header Extensions are present.
X = 1 indicates that Header Extensions are present.
Header Extensions are used in LCT to accommodate OPTIONAL header
fields which are not always used or have variable size.
Close TOI flag (A): 1 bit
Normally, the Close TOI flag is set to 0. The sender MAY set the
Close TOI flag to 1 when termination of transmission of LCT
packets for the object identified by the TOI is imminent. The
Close TOI flag MAY be set to 1 in just the last LCT packet
transmitted for the object, or it MAY be set to 1 in the last
couple of seconds LCT packets transmitted for the object. Once
the sender sets the Close TOI flag to 1 in one packet for a
particular object, the sender SHOULD set the Close TOI flag to 1
in all subsequent packets for the object until termination of
transmission of LCT packets for the object. A received packet
with the Close TOI flag set to 1 indicates to a receiver that the
sender will immediately stop sending LCT packets for the object
identified by the TOI. When a receiver receives a packet with the
Close TOI flag set to 1 then it should assume that no more LCT
packets will be sent to the session for this object.
Close Session flag (B): 1 bit
Normally, the Close Session flag is set to 0. The sender MAY set
the Close Session flag to 1 when termination of transmission of
LCT packets for the session is imminent. The Close Session flag
MAY be set to 1 in just the last LCT packet transmitted for the
session, or it MAY be set to 1 in the last couple of seconds LCT
packets transmitted for the session. Once the sender sets the
Close Session flag to 1 in one packet, the sender SHOULD set the
Close Session flag to 1 in all subsequent packets until
termination of transmission of LCT packets for the session. A
received packet with the Close Session flag set to 1 indicates to
a receiver that the sender will immediately stop sending LCT
packets for the session. When a receiver receives a packet with
the Close Session flag set to 1 then it should assume that no more
LCT packets will be sent to the session.
Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft Section 3.2. [Page 14]
^L
INTERNET-DRAFT Expires: January 2002 July 2001
LCT packet header length (HDR_LEN): 8 bits
Length of the LCT packet header in units of 32-bit words
(excluding IP or UDP headers).
This field can be used for direct access to the beginning of the
LCT packet payload.
Codepoint (CP): 8 bits
An opaque identifier which is passed to the payload decoder to
convey information on the codec being used for the payload. The
mapping between the codepoint and the actual codec is defined on a
per session basis and communicated out-of-band as part of the
session description information. The use of the CP field is
similar to the Payload Type (PT) field in RTP headers as described
in RFC1889.
Congestion Control Information (CCI): 32 bits
Used to carry congestion control information, e.g. for the
congestion control specified in [9] or other congestion control
schemes. This field is opaque for the purpose of this
specification.
Transport Object Identifier (TOI): 32, 64 or 128 bits (OPTIONAL)
This field indicates which object within the session this LCT
packet pertains to. For example, a sender might send a number of
files in the same session, using TOI=0 for the first file, TOI=1
for the second one, etc. The mapping of TOI field values to
objects MUST be done out of band.
This field MUST NOT be present if I=0.
This field MUST be 32 bits if I=1.
This field MUST be 64 bits if I=2.
This field MUST be 128 bits if I=3.
Sender Current Time (SCT): 32 bits (OPTIONAL)
This field represents the current clock at the sender at the time
this packet was transmitted, measured in units of 1ms and computed
modulo 2^32 units from the start of the session.
This field MUST NOT be present if S=0 and MUST be present if S=1.
Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft Section 3.2. [Page 15]
^L
INTERNET-DRAFT Expires: January 2002 July 2001
Expected Residual Time (ERT): 32 bits (OPTIONAL)
This field represents the sender expected residual transmission
time for the current session, measured in units of 1ms.
This field MUST NOT be present if E=0 and MUST be present if E=1.
3.3. Header-Extension Fields
To allow for additional header fields and to extend the size of some of
the predefined fields, the LCT packet header contains an additional
header field flag, "X". If "X" is set to 0 then no additional header
fields are included within the LCT packet header beyond the predefined
fields. When additional headers beyond the predefined fields are used,
the value of "X" within the LCT packet header MUST be set to 1.
Examples of use of Header Extensions include:
o Extended-size version of already existing header fields.
o Sender and Receiver authentication information.
If present, Header Extensions MUST be processed to ensure that they are
recognized before performing any congestion control procedure or
otherwise accepting an LCT packet. LCT packets with unrecognised Header
Extensions MUST be discarded by the receiving agent, hence the expected
use of extensions SHOULD be signaled out-of-band before session startup.
There are two formats for Header Extension fields, as depicted below.
The first format is used for variable-length extensions, with Header
Extension Type (HET) values between 0 and 63. The second format is used
for fixed length (one word) extension, using HET values from 64 to 127.
Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft Section 3.3. [Page 16]
^L
INTERNET-DRAFT Expires: January 2002 July 2001
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| HET (<=63) | HEL | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
. .
. Header Extension Content (HEC) .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| HET (>=64) | Header Extension Content (HEC) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5 - Format of additional headers
The explanation of each sub-field is the following.
Last Header Extension (L): 1 bit
MUST be set to 1 in the last Header Extension field present in an
LCT packet header, MUST be set to 0 in all the others.
Header Extension Type (HET): 7 bits
The type of the Header Extension. This document defines a number
of possible types. Additional types may be defined in future
version of this specification. HET values from 0 to 63 are used
for variable-length Header Extensions. HET values from 64 to 127
are used for fixed-length Header Extensions.
Header Extension Length (HEL): 8 bits
The length of the whole Header Extension field, expressed in
multiples of 32-bit words. This field MUST be present for
variable-length extensions (HET between 0 and 63) and MUST NOT be
present for fixed-length extensions (HET between 64 and 127).
Header Extension Content (HEC): variable length
Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft Section 3.3. [Page 17]
^L
INTERNET-DRAFT Expires: January 2002 July 2001
The content of the Header Extension. The format of this sub-field
depends on the Header Extension type. For fixed-length Header
Extensions, the HEC is 24 bits. For variable-length Header
Extensions, the HEC field has variable size, as specified by the
HEL field. Note that the length of each Header Extension field
MUST be a multiple of 32 bits. Also note that the total size of
the LCT packet header, including all Header Extensions and all
OPTIONAL header fields, cannot exceed 255 32-bit words.
An LCT packet with Header Extensions MUST NOT have space between the end
of the last Header Extension and the beginning of the LCT packet
payload.
All senders and receivers of LCT packets MUST support the EXT_NOP Header
Extension.
The following Header Extension types are defined:
EXT_NOP=0 No-Operation extension.
The information present in this extension field MUST be
ignored by receivers.
EXT_CCI_V=1 Congestion Control Information extension, variable length.
This extension field extends the CCI field present in the
fixed part of the header. It is used when the congestion
control information does not fit in the 32-bit CCI field.
When this option is present, the concatenation of the
32-bit CCI field in the fixed part of the header together
with the variable length value provided in this option is
used as the congestion control information. The
interpretation of the data contained in EXT_CCI_V MUST be
negotiated out-of-band. The use of EXT_CCI_V and
EXT_CCI_F is mutually exclusive.
EXT_AUTH=2 Authentication extension
Information used to authenticate the sender of the LCT
packet. If present, the format of this Header Extension
and its processing MUST be communicated out-of-band as
part of the session description.
It is RECOMMENDED that senders provide some form of
authentication on the LCT packets they transmit. If
EXT_AUTH is present, whatever authentication checks that
can be performed immediately upon reception of the packet
MUST be performed before accepting the packet and
Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft Section 3.3. [Page 18]
^L
INTERNET-DRAFT Expires: January 2002 July 2001
performing any congestion control-related action on it.
Some authentication schemes impose a delay of several
seconds between when a packet is received and when the
packet is fully authenticated. Any congestion control
related action that is appropriate MUST NOT be delayed by
any such full authentication delay.
EXT_CCI_F=65 Congestion Control Information extension, fixed length.
This extension field extends the CCI field present in the
fixed part of the header. It is used when the congestion
control information does not fit in the 32-bit CCI field.
When this option is present, the concatenation of the
32-bit CCI field in the fixed part of the header together
with the 24-bit fixed length value provided in this option
is used as the congestion control information. The
interpretation of the data contained in EXT_CCI_F MUST be
negotiated out-of-band. The use of EXT_CCI_V and
EXT_CCI_F is mutually exclusive.
4. Procedures
4.1. Sender Operation
Before a session starts, an LCT sender MUST make available all
applicable information regarding the session. This information could
include, but is not limited to:
o The number of LCT channels;
o The addresses, port numbers and data rates used for each LCT
channel;
o The format of the payload. For example, the payload could contain
other protocol headers such as an FEC header. Then for example the
information could include the mapping of codepoints used in the
session to FEC codec types and parameters;
o The congestion control scheme being used;
o The possible Header Extensions that could be used in the session;
o The mapping of TOI value(s) to objects for the session;
o The authentication scheme being used, and all relevant information
which is necessary for sender authentication purposes;
Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft Section 4.1. [Page 19]
^L
INTERNET-DRAFT Expires: January 2002 July 2001
The session description could be in a form such as SDP as defined in
RFC2327, XML metadata, HTTP/Mime headers, etc. It might be carried in a
session announcement protocol such as SAP [4], obtained using RCCP
session control as described in [8], located on a Web page with
scheduling information, or conveyed via E-mail or other out of band
methods. Discussion of session description format, and distribution of
session descriptions is beyond the scope of this document.
Within an LCT session, an LCT sender transmits a sequence of LCT packets
each containing a payload encoded according to one of the codecs defined
in the session description. LCT packets are sent over one or more LCT
channels which together constitute a session. Transmission rates MAY be
different in different channels. This document does not specify the LCT
packet payload, nor the order in which LCT packets are transmitted, nor
the organization of a session into multiple channels. Although these
issues affect the efficiency of the protocol, they do not affect the
correctness nor the inter-operability between senders and receivers.
Multiple objects can be carried within the same LCT session. In this
case, each object is identified by a unique TOI. Objects MAY be
transmitted sequentially, or they MAY be transmitted concurrently.
Typically, the sender(s) continues to send LCT packets in a session
until the transmission is considered complete. The transmission MAY be
considered complete when some time has expired, a certain number of
packets have been sent, or some out of band signal (possibly from a
higher level protocol) has indicated completion by a sufficient number
of receivers.
The specification of the processing of the payload carried in LCT
packets is beyond the scope of this document. LCT will act as a
transport layer and convey payload and associated information (Codepoint
and TOI) to the receivers and any complete protocol using LCT will
implement congestion control .
For the reasons mentioned above, this document does not pose any
restriction on LCT packet sizes. However, network efficiency
considerations recommend that the sender uses as large as possible
payload size, but in such a way that LCT packets do not exceed the
network's maximum transmission unit size (MTU), or fragmentation coupled
with packet loss might introduce severe inefficiency in the
transmission.
It is also RECOMMENDED that all LCT packets have the same or very
similar sizes, as this can have a severe impact on the effectiveness of
congestion control schemes such as the ones described in [9]. A sender
of LCT packets MUST implement the sender-side part of one of the
congestion control schemes that is in accordance with RFC2357, and the
Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft Section 4.1. [Page 20]
^L
INTERNET-DRAFT Expires: January 2002 July 2001
corresponding receiver congestion control scheme MUST be communicated
out of band and implemented by any receivers participating in the
session.
4.2. Receiver Operation
Receivers can operate differently depending on the delivery service
model. For example, for an on demand service model receivers MAY join a
session, obtain the necessary encoding symbols to reproduce the object,
and then leave the session. As another example, for a streaming service
model a receiver MAY be continuously joined to a set of LCT channels to
download all objects in a session.
To be able to participate in a session, a receiver MUST first obtain the
relevant session description information as listed in Section 4.1.
To be able to participate in a session, a receiver MUST implement the
congestion control protocol specified in the session description. If a
receiver is not able to implement the congestion control protocol used
in the session, it MUST NOT join the session.
If sender authentication information is present in an LCT packet header,
it MUST be used as specified in Section 3.3. If a receiver is unable to
implement the authentication mechanism used by the session, it MUST NOT
join the session.
To be able to be a receiver in a session, the receiver MUST be able to
process the LCT packet header. The receiver MUST be able to discard,
forward, store or process the LCT packet payload. If a receiver is not
able to process a LCT packet header, it MUST either drop from the
session, or reduce the receive bandwidth to the minimum value allowed by
the congestion control protocol being used.
When the session is transmitted on multiple LCT channels, receivers MUST
do it according to the specified startup behavior of the congestion
control protocol itself. For a layered transmission on multiple
channels, this typically means that a receiver will initially join only
a minimal set of LCT channels, possibly a single one. This rule has the
purpose of preventing receivers from starting at high data rates.
Multiple objects can be carried within the same LCT session. In this
case, each object is identified by a unique TOI. Note that even if a
server stops sending LCT packets for an old object before starting to
transmit LCT packets for a new object, both the network and the
underlying protocol layers can cause some reordering of packets,
especially when sent over different LCT channels, and thus receivers
Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft Section 4.2. [Page 21]
^L
INTERNET-DRAFT Expires: January 2002 July 2001
MUST NOT assume that the reception of an LCT packet for a new object
means that there are no more LCT packets in transit for the previous
one, at least for some amount of time.
A receiver MAY be concurrently joined to multiple LCT sessions. The
receiver MUST perform congestion control on each such LCT session. If
the congestion control protocol allows the receiver some flexibility in
terms of its actions within a session then the receiver MAY make choices
to optimize the packet flow performance across the multiple LCT
sessions, as long as the receiver still adheres to the congestion
control rules for each LCT session individually.
5. Security Considerations
LCT can be subject to denial-of-service attacks by attackers which try
to confuse the congestion control mechanism, or send forged packets to
the session which would prevent successful reconstruction of large
portions of the data stream.
The same exact problems are present in TCP, where an attacker can forge
packets and either slow down or increase the throughput of the session,
or replace parts of the data stream with forged data. If the stream is
carrying compressed or otherwise coded data, even a single forged packet
could also cause incorrect reconstruction of the rest of the data
stream.
It is therefore RECOMMENDED that LCT agents implement some form of
authentication to protect themselves against such attacks.
6. IANA Considerations
No information in this specification is subject to IANA registration.
Building blocks components used by LCT may introduce additional IANA
considerations.
7. Intellectual Property Issues
No specific reliability protocol or congestion control protocol is
specified or referenced as mandatory in this document.
LCT MAY be used with congestion control protocols and other protocols
which are proprietary, or have pending or granted patents.
Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft Section 7. [Page 22]
^L
INTERNET-DRAFT Expires: January 2002 July 2001
8. Acknowledgments
Thanks to Vincent Roca, Bruce Lueckenhoff and Hayder Radha for detailed
comments on this document.
[1] Byers, J.W., Luby, M., Mitzenmacher, M., and Rege, A., "A Digital
Fountain Approach to Reliable Distribution of Bulk Data", Proceedings
ACM SIGCOMM '98, Vancouver, Canada, Sept 1998.
[2] Cain, B., Speakman, T., and Towsley, D., "Generic Router Assist
(GRA) Building Block, Motivation and Architecture", Internet Draft
draft-ietf-rmt-gra-arch-00.txt, a work in progress.
[3] Gemmell, J., Schooler, E., and Gray, J., "FCast Scalable Multicast
File Distribution: Caching and Parameters Optimizations", Technical
Report MSR-TR-99-14, Microsoft Research, Redmond, WA, April, 1999.
[4] Handley, M., "SAP: Session Announcement Protocol", Internet Draft,
IETF MMUSIC Working Group, Nov 1996, a work in progress.
[5] Holbrook, H., Cain, B., "Source-Specific Multicast for IP", Internet
Draft, SSM Working Group, March 2001, draft-holbrook-ssm-arch-02.txt, a
work in progress.
[6] Luby, M., Gemmell, Vicisano, L., J., Rizzo, L., Handley, M.,
Crowcroft, J., "The use of Forward Error Correction in Reliable
Multicast", Internet Draft draft-ietf-rmt-info-fec-00.txt, November
2000, a work in progress.
[7] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M.,
Crowcroft, J., "RMT BB Forward Error Correction Codes", Internet Draft
draft-ietf-rmt-bb-fec-03.txt, July 2001.
[8] Luby, M., Hernek, D., Kushi, D., Rasmussen, L., Simu, S., Vainish,
R., "Rich Content Control Protocol: A session control protocol
instantiation", Digital Fountain document, a work in progress.
[9] Luby, M., Vicisano, L., Haken, A., "RMT BB Layered congestion
control", draft-ietf-rmt-bb-lcc-00.txt, November 2000, a work in
progress.
[10] Rizzo, L., "Effective Erasure Codes for Reliable Computer
Communication Protocols", ACM SIGCOMM Computer Communication Review,
Vol.27, No.2, pp.24-36, Apr 1997.
Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft Section 8. [Page 23]
^L
INTERNET-DRAFT Expires: January 2002 July 2001
[11] Perrig, A., Canetti, R., Briscoe, B., Tygar, D., Song, D., "TESLA:
Multicast Source Authentication Transform", draft-irtf-smug-
tesla-00.txt, November, 2000, a work in progress.
[12] Rizzo, L, and Vicisano, L., "Reliable Multicast Data Distribution
protocol based on software FEC techniques", Proceedings of the Fourth
IEEES Workshop on the Architecture and Implementation of High
Performance Communication Systems, HPCS'97, Chalkidiki, Greece, June
1997.
[13] Speakman, T., Farinacci, D., Crowcroft, J., Gemmell, J., Lin, S.,
Tweedly, A., Leshchiner, D., Luby, M., Bhaskar, N., Edmonstone, R.,
Johnson, K., Montgomery, T., Rizzo, L., Sumanasekera, R., Vicisano, L.,
"PGM Reliable Transport Protocol", draft-speakman-pgm-spec-06.txt, a
work in progress.
[14] Vicisano, L., Rizzo, L., Crowcroft, J., "TCP-like Congestion
Control for Layered Multicast Data Transfer", IEEE Infocom '98, San
Francisco, CA, Mar.28-Apr.1 1998.
[15] Vicisano, L., "Notes On a Cumulative Layered Organization of Data
Packets Across Multiple groups with Different Rates", University College
London Computer Science Research Note RN/98/25, Work in Progress (May
1998).
9. Authors' Addresses
Michael Luby
luby@digitalfountain.com
Digital Fountain
39141 Civic Center Drive
Suite 300
Fremont, CA, USA, 94538
Jim Gemmell
jgemmell@microsoft.com
Microsoft Research
301 Howard St., #830
San Francisco, CA, USA, 94105
Lorenzo Vicisano
lorenzo@cisco.com
cisco Systems, Inc.
170 West Tasman Dr.,
San Jose, CA, USA, 95134
Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft Section 9. [Page 24]
^L
INTERNET-DRAFT Expires: January 2002 July 2001
Luigi Rizzo
luigi@iet.unipi.it
ACIRI/ICSI,
1947 Center St, Berkeley, CA, USA, 94704
and
Dip. Ing. dell'Informazione,
Univ. di Pisa
via Diotisalvi 2, 56126 Pisa, Italy
Mark Handley
mjh@aciri.org
ACIRI,
1947 Center St,
Berkeley, CA, USA, 94704
Jon Crowcroft
J.Crowcroft@cs.ucl.ac.uk
Department of Computer Science
University College London
Gower Street,
London WC1E 6BT, UK
Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft Section 9. [Page 25]
^L
INTERNET-DRAFT Expires: January 2002 July 2001
10. Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are included
on all such copies and derivative works. However, this document itself
may not be modified in any way, such as by removing the copyright notice
or references to the Internet Society or other Internet organizations,
except as needed for the purpose of developing Internet standards in
which case the procedures for copyrights defined in the Internet
languages other than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE."
Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft Section 10. [Page 26]
^L
INTERNET-DRAFT Expires: January 2002 July 2001
Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft Section 10. [Page 27]
--==_Exmh_5195028970
Content-Type: application/postscript ; name="draft-ietf-rmt-bb-lct-01.ps"
Content-Description: draft-ietf-rmt-bb-lct-01.ps
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="draft-ietf-rmt-bb-lct-01.ps"
JSFQUy1BZG9iZS0zLjAKJSVDcmVhdG9yOiBncm9mZiB2ZXJzaW9uIDEuMTYuMQolJUNyZWF0
aW9uRGF0ZTogVGh1IEp1bCAxOSAxNzowODoxNiAyMDAxCiUlRG9jdW1lbnROZWVkZWRSZXNv
dXJjZXM6IGZvbnQgQ291cmllci1Cb2xkCiUlKyBmb250IFRpbWVzLUJvbGQKJSUrIGZvbnQg
VGltZXMtUm9tYW4KJSUrIGZvbnQgQ291cmllcgolJURvY3VtZW50U3VwcGxpZWRSZXNvdXJj
ZXM6IHByb2NzZXQgZ3JvcHMgMS4xNiAxCiUlUGFnZXM6IDIxCiUlUGFnZU9yZGVyOiBBc2Nl
bmQKJSVPcmllbnRhdGlvbjogUG9ydHJhaXQKJSVFbmRDb21tZW50cwolJUJlZ2luUHJvbG9n
CiUlQmVnaW5SZXNvdXJjZTogcHJvY3NldCBncm9wcyAxLjE2IDEKL3NldHBhY2tpbmcgd2hl
cmV7CnBvcApjdXJyZW50cGFja2luZwp0cnVlIHNldHBhY2tpbmcKfWlmCi9ncm9wcyAxMjAg
ZGljdCBkdXAgYmVnaW4KL1NDIDMyIGRlZgovQS9zaG93IGxvYWQgZGVmCi9CezAgU0MgMyAt
MSByb2xsIHdpZHRoc2hvd31iaW5kIGRlZgovQ3swIGV4Y2ggYXNob3d9YmluZCBkZWYKL0R7
MCBleGNoIDAgU0MgNSAyIHJvbGwgYXdpZHRoc2hvd31iaW5kIGRlZgovRXswIHJtb3ZldG8g
c2hvd31iaW5kIGRlZgovRnswIHJtb3ZldG8gMCBTQyAzIC0xIHJvbGwgd2lkdGhzaG93fWJp
bmQgZGVmCi9HezAgcm1vdmV0byAwIGV4Y2ggYXNob3d9YmluZCBkZWYKL0h7MCBybW92ZXRv
IDAgZXhjaCAwIFNDIDUgMiByb2xsIGF3aWR0aHNob3d9YmluZCBkZWYKL0l7MCBleGNoIHJt
b3ZldG8gc2hvd31iaW5kIGRlZgovSnswIGV4Y2ggcm1vdmV0byAwIFNDIDMgLTEgcm9sbCB3
aWR0aHNob3d9YmluZCBkZWYKL0t7MCBleGNoIHJtb3ZldG8gMCBleGNoIGFzaG93fWJpbmQg
ZGVmCi9MezAgZXhjaCBybW92ZXRvIDAgZXhjaCAwIFNDIDUgMiByb2xsIGF3aWR0aHNob3d9
YmluZCBkZWYKL017cm1vdmV0byBzaG93fWJpbmQgZGVmCi9Oe3Jtb3ZldG8gMCBTQyAzIC0x
IHJvbGwgd2lkdGhzaG93fWJpbmQgZGVmCi9Pe3Jtb3ZldG8gMCBleGNoIGFzaG93fWJpbmQg
ZGVmCi9Qe3Jtb3ZldG8gMCBleGNoIDAgU0MgNSAyIHJvbGwgYXdpZHRoc2hvd31iaW5kIGRl
ZgovUXttb3ZldG8gc2hvd31iaW5kIGRlZgovUnttb3ZldG8gMCBTQyAzIC0xIHJvbGwgd2lk
dGhzaG93fWJpbmQgZGVmCi9Te21vdmV0byAwIGV4Y2ggYXNob3d9YmluZCBkZWYKL1R7bW92
ZXRvIDAgZXhjaCAwIFNDIDUgMiByb2xsIGF3aWR0aHNob3d9YmluZCBkZWYKL1NGewpmaW5k
Zm9udCBleGNoCltleGNoIGR1cCAwIGV4Y2ggMCBleGNoIG5lZyAwIDBdbWFrZWZvbnQKZHVw
IHNldGZvbnQKW2V4Y2gvc2V0Zm9udCBjdnhdY3Z4IGJpbmQgZGVmCn1iaW5kIGRlZgovTUZ7
CmZpbmRmb250Cls1IDIgcm9sbAowIDMgMSByb2xsCm5lZyAwIDBdbWFrZWZvbnQKZHVwIHNl
dGZvbnQKW2V4Y2gvc2V0Zm9udCBjdnhdY3Z4IGJpbmQgZGVmCn1iaW5kIGRlZgovbGV2ZWww
IDAgZGVmCi9SRVMgMCBkZWYKL1BMIDAgZGVmCi9MUyAwIGRlZgovTUFOVUFMewpzdGF0dXNk
aWN0IGJlZ2luL21hbnVhbGZlZWQgdHJ1ZSBzdG9yZSBlbmQKfWJpbmQgZGVmCi9QTEd7Cmdz
YXZlIG5ld3BhdGggY2xpcHBhdGggcGF0aGJib3ggZ3Jlc3RvcmUKZXhjaCBwb3AgYWRkIGV4
Y2ggcG9wCn1iaW5kIGRlZgovQlB7Ci9sZXZlbDAgc2F2ZSBkZWYKMSBzZXRsaW5lY2FwCjEg
c2V0bGluZWpvaW4KNzIgUkVTIGRpdiBkdXAgc2NhbGUKTFN7CjkwIHJvdGF0ZQp9ewowIFBM
IHRyYW5zbGF0ZQp9aWZlbHNlCjEgLTEgc2NhbGUKfWJpbmQgZGVmCi9FUHsKbGV2ZWwwIHJl
c3RvcmUKc2hvd3BhZ2UKfWJpbmQgZGVmCi9EQXsKbmV3cGF0aCBhcmNuIHN0cm9rZQp9Ymlu
ZCBkZWYKL1NOewp0cmFuc2Zvcm0KLjI1IHN1YiBleGNoIC4yNSBzdWIgZXhjaApyb3VuZCAu
MjUgYWRkIGV4Y2ggcm91bmQgLjI1IGFkZCBleGNoCml0cmFuc2Zvcm0KfWJpbmQgZGVmCi9E
THsKU04KbW92ZXRvClNOCmxpbmV0byBzdHJva2UKfWJpbmQgZGVmCi9EQ3sKbmV3cGF0aCAw
IDM2MCBhcmMgY2xvc2VwYXRoCn1iaW5kIGRlZgovVE0gbWF0cml4IGRlZgovREV7ClRNIGN1
cnJlbnRtYXRyaXggcG9wCnRyYW5zbGF0ZSBzY2FsZSBuZXdwYXRoIDAgMCAuNSAwIDM2MCBh
cmMgY2xvc2VwYXRoClRNIHNldG1hdHJpeAp9YmluZCBkZWYKL1JDL3JjdXJ2ZXRvIGxvYWQg
ZGVmCi9STC9ybGluZXRvIGxvYWQgZGVmCi9TVC9zdHJva2UgbG9hZCBkZWYKL01UL21vdmV0
byBsb2FkIGRlZgovQ0wvY2xvc2VwYXRoIGxvYWQgZGVmCi9GTHsKY3VycmVudGdyYXkgZXhj
aCBzZXRncmF5IGZpbGwgc2V0Z3JheQp9YmluZCBkZWYKL0JML2ZpbGwgbG9hZCBkZWYKL0xX
L3NldGxpbmV3aWR0aCBsb2FkIGRlZgovUkV7CmZpbmRmb250CmR1cCBtYXhsZW5ndGggMSBp
bmRleC9Gb250TmFtZSBrbm93biBub3R7MSBhZGR9aWYgZGljdCBiZWdpbgp7CjEgaW5kZXgv
RklEIG5le2RlZn17cG9wIHBvcH1pZmVsc2UKfWZvcmFsbAovRW5jb2RpbmcgZXhjaCBkZWYK
ZHVwL0ZvbnROYW1lIGV4Y2ggZGVmCmN1cnJlbnRkaWN0IGVuZCBkZWZpbmVmb250IHBvcAp9
YmluZCBkZWYKL0RFRlMgMCBkZWYKL0VCRUdJTnsKbW92ZXRvCkRFRlMgYmVnaW4KfWJpbmQg
ZGVmCi9FRU5EL2VuZCBsb2FkIGRlZgovQ05UIDAgZGVmCi9sZXZlbDEgMCBkZWYKL1BCRUdJ
TnsKL2xldmVsMSBzYXZlIGRlZgp0cmFuc2xhdGUKZGl2IDMgMSByb2xsIGRpdiBleGNoIHNj
YWxlCm5lZyBleGNoIG5lZyBleGNoIHRyYW5zbGF0ZQowIHNldGdyYXkKMCBzZXRsaW5lY2Fw
CjEgc2V0bGluZXdpZHRoCjAgc2V0bGluZWpvaW4KMTAgc2V0bWl0ZXJsaW1pdApbXTAgc2V0
ZGFzaAovc2V0c3Ryb2tlYWRqdXN0IHdoZXJlewpwb3AKZmFsc2Ugc2V0c3Ryb2tlYWRqdXN0
Cn1pZgovc2V0b3ZlcnByaW50IHdoZXJlewpwb3AKZmFsc2Ugc2V0b3ZlcnByaW50Cn1pZgpu
ZXdwYXRoCi9DTlQgY291bnRkaWN0c3RhY2sgZGVmCnVzZXJkaWN0IGJlZ2luCi9zaG93cGFn
ZXt9ZGVmCn1iaW5kIGRlZgovUEVORHsKY2xlYXIKY291bnRkaWN0c3RhY2sgQ05UIHN1Yntl
bmR9cmVwZWF0CmxldmVsMSByZXN0b3JlCn1iaW5kIGRlZgplbmQgZGVmCi9zZXRwYWNraW5n
IHdoZXJlewpwb3AKc2V0cGFja2luZwp9aWYKJSVFbmRSZXNvdXJjZQolJUluY2x1ZGVSZXNv
dXJjZTogZm9udCBDb3VyaWVyLUJvbGQKJSVJbmNsdWRlUmVzb3VyY2U6IGZvbnQgVGltZXMt
Qm9sZAolJUluY2x1ZGVSZXNvdXJjZTogZm9udCBUaW1lcy1Sb21hbgolJUluY2x1ZGVSZXNv
dXJjZTogZm9udCBDb3VyaWVyCmdyb3BzIGJlZ2luL0RFRlMgMSBkaWN0IGRlZiBERUZTIGJl
Z2luL3V7LjAwMSBtdWx9YmluZCBkZWYgZW5kL1JFUyA3MgpkZWYvUEwgNzkyIGRlZi9MUyBm
YWxzZSBkZWYvRU5DMFsvYXNjaWljaXJjdW0vYXNjaWl0aWxkZS9TY2Fyb24vWmNhcm9uCi9z
Y2Fyb24vemNhcm9uL1lkaWVyZXNpcy90cmFkZW1hcmsvcXVvdGVzaW5nbGUvLm5vdGRlZi8u
bm90ZGVmLy5ub3RkZWYKLy5ub3RkZWYvLm5vdGRlZi8ubm90ZGVmLy5ub3RkZWYvLm5vdGRl
Zi8ubm90ZGVmLy5ub3RkZWYvLm5vdGRlZi8ubm90ZGVmCi8ubm90ZGVmLy5ub3RkZWYvLm5v
dGRlZi8ubm90ZGVmLy5ub3RkZWYvLm5vdGRlZi8ubm90ZGVmLy5ub3RkZWYvLm5vdGRlZgov
Lm5vdGRlZi8ubm90ZGVmL3NwYWNlL2V4Y2xhbS9xdW90ZWRibC9udW1iZXJzaWduL2RvbGxh
ci9wZXJjZW50Ci9hbXBlcnNhbmQvcXVvdGVyaWdodC9wYXJlbmxlZnQvcGFyZW5yaWdodC9h
c3Rlcmlzay9wbHVzL2NvbW1hL2h5cGhlbgovcGVyaW9kL3NsYXNoL3plcm8vb25lL3R3by90
aHJlZS9mb3VyL2ZpdmUvc2l4L3NldmVuL2VpZ2h0L25pbmUvY29sb24KL3NlbWljb2xvbi9s
ZXNzL2VxdWFsL2dyZWF0ZXIvcXVlc3Rpb24vYXQvQS9CL0MvRC9FL0YvRy9IL0kvSi9LL0wv
TS9OL08KL1AvUS9SL1MvVC9VL1YvVy9YL1kvWi9icmFja2V0bGVmdC9iYWNrc2xhc2gvYnJh
Y2tldHJpZ2h0L2NpcmN1bWZsZXgKL3VuZGVyc2NvcmUvcXVvdGVsZWZ0L2EvYi9jL2QvZS9m
L2cvaC9pL2ovay9sL20vbi9vL3AvcS9yL3MvdC91L3Yvdy94L3kKL3ovYnJhY2VsZWZ0L2Jh
ci9icmFjZXJpZ2h0L3RpbGRlLy5ub3RkZWYvcXVvdGVzaW5nbGJhc2UvZ3VpbGxlbW90bGVm
dAovZ3VpbGxlbW90cmlnaHQvYnVsbGV0L2Zsb3Jpbi9mcmFjdGlvbi9wZXJ0aG91c2FuZC9k
YWdnZXIvZGFnZ2VyZGJsCi9lbmRhc2gvZW1kYXNoL2ZmL2ZpL2ZsL2ZmaS9mZmwvZG90bGVz
c2kvZG90bGVzc2ovZ3JhdmUvaHVuZ2FydW1sYXV0Ci9kb3RhY2NlbnQvYnJldmUvY2Fyb24v
cmluZy9vZ29uZWsvcXVvdGVkYmxsZWZ0L3F1b3RlZGJscmlnaHQvb2UvbHNsYXNoCi9xdW90
ZWRibGJhc2UvT0UvTHNsYXNoLy5ub3RkZWYvZXhjbGFtZG93bi9jZW50L3N0ZXJsaW5nL2N1
cnJlbmN5L3llbgovYnJva2VuYmFyL3NlY3Rpb24vZGllcmVzaXMvY29weXJpZ2h0L29yZGZl
bWluaW5lL2d1aWxzaW5nbGxlZnQKL2xvZ2ljYWxub3QvbWludXMvcmVnaXN0ZXJlZC9tYWNy
b24vZGVncmVlL3BsdXNtaW51cy90d29zdXBlcmlvcgovdGhyZWVzdXBlcmlvci9hY3V0ZS9t
dS9wYXJhZ3JhcGgvcGVyaW9kY2VudGVyZWQvY2VkaWxsYS9vbmVzdXBlcmlvcgovb3JkbWFz
Y3VsaW5lL2d1aWxzaW5nbHJpZ2h0L29uZXF1YXJ0ZXIvb25laGFsZi90aHJlZXF1YXJ0ZXJz
Ci9xdWVzdGlvbmRvd24vQWdyYXZlL0FhY3V0ZS9BY2lyY3VtZmxleC9BdGlsZGUvQWRpZXJl
c2lzL0FyaW5nL0FFCi9DY2VkaWxsYS9FZ3JhdmUvRWFjdXRlL0VjaXJjdW1mbGV4L0VkaWVy
ZXNpcy9JZ3JhdmUvSWFjdXRlL0ljaXJjdW1mbGV4Ci9JZGllcmVzaXMvRXRoL050aWxkZS9P
Z3JhdmUvT2FjdXRlL09jaXJjdW1mbGV4L090aWxkZS9PZGllcmVzaXMKL211bHRpcGx5L09z
bGFzaC9VZ3JhdmUvVWFjdXRlL1VjaXJjdW1mbGV4L1VkaWVyZXNpcy9ZYWN1dGUvVGhvcm4K
L2dlcm1hbmRibHMvYWdyYXZlL2FhY3V0ZS9hY2lyY3VtZmxleC9hdGlsZGUvYWRpZXJlc2lz
L2FyaW5nL2FlL2NjZWRpbGxhCi9lZ3JhdmUvZWFjdXRlL2VjaXJjdW1mbGV4L2VkaWVyZXNp
cy9pZ3JhdmUvaWFjdXRlL2ljaXJjdW1mbGV4L2lkaWVyZXNpcwovZXRoL250aWxkZS9vZ3Jh
dmUvb2FjdXRlL29jaXJjdW1mbGV4L290aWxkZS9vZGllcmVzaXMvZGl2aWRlL29zbGFzaAov
dWdyYXZlL3VhY3V0ZS91Y2lyY3VtZmxleC91ZGllcmVzaXMveWFjdXRlL3Rob3JuL3lkaWVy
ZXNpc11kZWYKL0NvdXJpZXJAMCBFTkMwL0NvdXJpZXIgUkUvVGltZXMtUm9tYW5AMCBFTkMw
L1RpbWVzLVJvbWFuIFJFCi9UaW1lcy1Cb2xkQDAgRU5DMC9UaW1lcy1Cb2xkIFJFL0NvdXJp
ZXItQm9sZEAwIEVOQzAvQ291cmllci1Cb2xkIFJFCiUlRW5kUHJvbG9nCiUlUGFnZTogMSAx
CiUlQmVnaW5QYWdlU2V0dXAKQlAKJSVFbmRQYWdlU2V0dXAKL0YwIDEwL0NvdXJpZXItQm9s
ZEAwIFNGKEludGVybmV0IEVuZ2luZWVyaW5nIFRhc2sgRm9yY2UpNzIgODUgUShSTVQgV0cp
CjIwOS45OTkgRSAyMDMuOTk5KElOVEVSTkVULURSQUZUIE0uTHVieS9EaWdpdGFsKTcyIDk4
IFIoRm91bnRhaW4pNiBFCjE0OS45OTkoZHJhZnQtaWV0Zi1ybXQtYmItbGN0LTAxLnBzIEou
R2VtbWVsbC9NaWNyb3NvZnQpNzIgMTExIFIKKEwuVmljaXNhbm8vQ2lzY28pNDA3Ljk5OSAx
MjQgUShMLlJpenpvL0FDSVJJIGFuZCBVbml2LiBQaXNhKTMzNS45OTkgMTM3ClEoTS5IYW5k
bGV5L0FDSVJJKTQxMy45OTkgMTUwIFEoSi4gQ3Jvd2Nyb2Z0L1VDTCk0MDcuOTk5IDE2MyBR
CigxOSBKdWx5IDIwMDEpNDMxLjk5OSAxNzYgUShFeHBpcmVzOiBKYW51YXJ5IDIwMDIpMzc3
Ljk5OSAxODkgUS9GMSAxNAovVGltZXMtQm9sZEAwIFNGKExheSkyMDUuNDkxIDIxNCBRKGVy
KS0uMTQgRShlZCBDb2RpbmcgVCktLjI1MiBFCihyYW5zcG9ydDopLTEuMDM2IEUgMy41KEFt
KTE0Ny4zMjEgMjI3IFMoYXNzaSktMy41IEUgLS4xNCh2ZSktLjE0IEcKKGx5IHNjYWxhYmxl
IGNvbnRlbnQgZGVsaSkuMTQgRSAtLjE0KHZlKS0uMTQgRyhyeSB0cmFuc3BvcnQpLjE0IEUv
RjIgMTEKL1RpbWVzLUJvbGRAMCBTRihTdGF0dXMgb2YgdGhpcyBEb2N1bWVudCk3MiAyNzIg
US9GMyAxMS9UaW1lcy1Sb21hbkAwIFNGCihUaGlzIGRvY3VtZW50IGlzIGFuIEludGVybmV0
LURyYWZ0IGFuZCBpcyBpbiBmdWxsIGNvbmZvcm1hbmNlIHdpdGggYWxsXAogcHJvKTcyIDI4
OC42IFEodmlzaW9ucyBvZiBTZWN0aW9uIDEwIG9mKS0uMTY1IEUoUkZDMjAyNi4pNzIgMzAx
LjYgUQooSW50ZXJuZXQtRHJhZnRzIGFyZSB3KTcyIDMyNy42IFEKKG9ya2luZyBkb2N1bWVu
dHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5nIFQpLS4xMSBFKGFzayBGKS0uODggRQoo
b3JjZSBcKElFVEZcKSwgaXRzIGFyZWFzLCktLjE2NSBFKGFuZCBpdHMgdyk3MiAzNDAuNiBR
KG9ya2luZyBncm91cHMuKQotLjExIEUoTm90ZSB0aGF0IG90aGVyIGdyb3VwcyBtYXkgYWxz
byBkaXN0cmliKTUuNSBFKHV0ZSB3KS0uMjIgRQoob3JraW5nIGRvY3VtZW50cyBhcyktLjEx
IEUoSW50ZXJuZXQtRHJhZnRzLik3MiAzNTMuNiBRCihJbnRlcm5ldC1EcmFmdHMgYXJlIHYp
NzIgMzc5LjYgUQooYWxpZCBmb3IgYSBtYXhpbXVtIG9mIHNpeCBtb250aHMgYW5kIE1BKS0u
Mjc1IEUgMi43NShZYiktMS4xNTUgRyAyLjc1CihldSktMi43NSBHKHBkYXRlZCwgcmVwbGFj
ZWQsIG9yKS0yLjc1IEUKKG9ic29sZXRlZCBieSBvdGhlciBkb2N1bWVudHMgYXQgYW4pNzIg
MzkyLjYgUSAyLjc1KHl0KS0uMTY1IEcgMi43NQooaW1lLiBJdCktMi43NSBGKGlzIGluYXBw
cm9wcmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBhcyByZWZlcmVuY2UpCjIuNzUgRSht
YXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyBhICJ3KTcyIDQwNS42IFEK
KG9yayBpbiBwcm9ncmVzcyIuKS0uMTEgRQooVGhlIGxpc3Qgb2YgY3VycmVudCBJbnRlcm5l
dC1EcmFmdHMgY2FuIGJlIGFjY2Vzc2VkIGF0IGh0dHA6Ly93d3cpNzIKNDMxLjYgUSguaWV0
Zi5vciktLjcxNSBFKGcvaWV0Zi8xaWQtYWJzdHJhY3RzLnR4dCktLjE5OCBFIDEuNzYgLS44
OAooVG8gdik3MiA0NTcuNiBUKGllKS44OCBFIDIuNzUod3QpLS4yNzUgRyhoZSBsaXN0IElu
dGVybmV0LURyYWZ0IFNoYWRvKQotMi43NSBFIDIuNzUod0QpLS4yNzUgRyhpcmVjdG9yaWVz
LCBzZWUgaHR0cDovL3d3dyktMi43NSBFKC5pZXRmLm9yKQotLjcxNSBFKGcvc2hhZG8pLS4x
OTggRSAtLjcxNSh3LiktLjI3NSBHKGh0bWwuKS43MTUgRQooVGhpcyBkb2N1bWVudCBpcyBh
IHByb2R1Y3Qgb2YgdGhlIElFVEYgUk1UIFdHLik3MiA0ODMuNiBRCihDb21tZW50cyBzaG91
bGQgYmUgYWRkcmVzc2VkIHRvIHRoZSk1LjUgRShhdXRob3JzLCBvciB0aGUgV0cnKTcyIDQ5
Ni42ClEgMi43NShzbSktLjYwNSBHKGFpbGluZyBsaXN0IGF0IHJtdEBsYmwuZ28pLTIuNzUg
RSAtLjcxNSh2LiktLjE2NSBHIEYyCihBYnN0cmFjdCkyNjcuNTM0IDUyOC42IFEgRjMoVGhp
cyBkb2N1bWVudCBkZXNjcmliZXMgTGF5ZXJlZCBDb2RpbmcgVCk5Nwo1NTEuMiBRKHJhbnNw
b3J0LCBhIG1hc3NpKS0uMzg1IEUgLS4xNjUodmUpLS4yNzUgRyhseSBzY2FsYWJsZSByZWxp
YWJsZSkKLjE2NSBFKGNvbnRlbnQgZGVsaSk5NyA1NjQuMiBRIC0uMTY1KHZlKS0uMjc1IEco
cnkgYW5kIHN0cmVhbSBkZWxpKS4xNjUKRSAtLjE2NSh2ZSktLjI3NSBHKHJ5IHRyYW5zcG9y
dCwgaGVyZWFmdGVyIHJlZmVycmVkIHRvIGFzIExDVCkuMTY1IEUgNS41CiguTCktLjgxNCBH
KENUIGNhbiktNS41IEUoYmUgdXNlZCBmb3IgbXVsdGktcmF0ZSBkZWxpKTk3IDU3Ny4yIFEg
LS4xNjUKKHZlKS0uMjc1IEcocnkgdG8gbGFyKS4xNjUgRShnZSBzZXRzIG9mIHJlY2VpKS0u
MTk4IEUgLS4xNjUodmUpLS4yNzUgRwoocnMuIEluIExDVCkuMTY1IEUgMi43NSgscyktLjgx
NCBHKGNhbGFiaWxpdHkgYW5kKS0yLjc1IEUoY29uZ2VzdGlvbiBjb1wKbnRyb2wgYXJlIHN1
cHBvcnRlZCB0aHJvdWdoIHRoZSB1c2Ugb2YgbGF5ZXJlZCBjb2RpbmcgdGVjaG5pcXVlcy4g
Q29kaW5cCmcpOTcgNTkwLjIgUSh0ZWNobmlxdWVzIGNhbiBiZSBjb21iaW5lZCB3aXRoIExD
VCB0byBwcm8pOTcgNjAzLjIgUQoodmlkZSBzdXBwb3J0IGZvciByZWxpYWJpbGl0eSktLjE2
NSBFKC4pLS43MTUgRQooQ29uZ2VzdGlvbiBjb250cm9sIGlzIHJlY2VpKTk3IDYyOS4yIFEg
LS4xNjUodmUpLS4yNzUgRyAyLjc1KHJkKS4xNjUgRwoocmkpLTIuNzUgRSAtLjE2NSh2ZSkt
LjI3NSBHKG4sIGFuZCBpcyBhY2hpZSkuMTY1IEUgLS4xNjUodmUpLS4yNzUgRwoyLjc1KGRi
KS4xNjUgRyAyLjc1KHlzKS0yLjc1IEcoZW5kaW5nIHBhY2spLTIuNzUgRShldHMgaW4gdGhl
KS0uMTEgRQooc2Vzc2lvbiB0byBtdWx0aXBsZSBgKTk3IDY0Mi4yIFEoYExDVCBjaGFubmVs
cycpLS44MTQgRSgnLCBhbmQgaGEpLS44MTQKRSh2aW5nIHJlY2VpKS0uMjIgRSAtLjE2NSh2
ZSktLjI3NSBHKHJzIGpvaW4gYW5kIGxlYSkuMTY1IEUgLjMzIC0uMTY1Cih2ZSBMKS0uMjIg
SChDVCkuMTY1IEUKKGNoYW5uZWxzIFwodGh1cyBhZGp1c3RpbmcgdGhlaXIgcmVjZXB0aW9u
IHJhdGVcKSBpbiByZWFjdGlvbiB0byBuZXR3KTk3CjY1NS4yIFEob3JrIGNvbmRpdGlvbnMg
aW4gYSktLjExIEUobWFubmVyIHRoYXQgaXMgbmV0dyk5NyA2NjguMiBRCihvcmsgZnJpZW5k
bHkpLS4xMSBFKC4pLS43MTUgRShMdWJ5L0dlbW1lbGwvVik3MiA3NjkgUQooaWNpc2Fuby9S
aXp6by9IYW5kbGUpLS42NiBFKHkvQ3JvKS0uMTY1IEUgMTY2Ljg1Nih3Y3JvZnQgW1ApLS4y
NzUgRgooYWdlIDFdKS0uMTY1IEUgRVAKJSVQYWdlOiAyIDIKJSVCZWdpblBhZ2VTZXR1cApC
UAolJUVuZFBhZ2VTZXR1cAovRjAgMTEvVGltZXMtUm9tYW5AMCBTRihJTlRFUk5FVCk3MiA0
OSBRIDcxLjU4NygtRFJBRlQgRXhwaXJlczopLTEuMDEyIEYKKEphbnVhcnkgMjAwMikyLjc1
IEUoSnVseSAyMDAxKTEyMy43MjYgRS9GMSAxMy9UaW1lcy1Cb2xkQDAgU0YgLTEuMTk2CihU
YSkyMzkuMTI2IDg1IFMoYmxlIG9mIENvbnRlbnRzKTEuMTk2IEUvRjIgMTAvVGltZXMtUm9t
YW5AMCBTRgooMS4gSW50cm9kdWN0aW9uKTk3IDEyMyBRIEYwIDExKC4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4pMy41NiBHIEYyKDMpMTEuNQpFKDEuMS4gUmVsYXRlZCBEb2N1bWVudHMpMTA3
IDEzNSBRIEYwIDExKC4uLi4uLi4uLi4uLi4uLi4uLikxMS45IEcgRjIoNCkKMTEuNSBFKDEu
Mi4gRW4pMTA3IDE0NyBRKHZpcm9ubWVudGFsIFJlcXVpcmVtZW50cyBhbmQgQ29uc2lkZXJh
dGlvbnMpLS40CkUgRjAgMTEoLi4uLi4uLi4uLikzLjk3IEcgRjIoNSkxMS41IEUoMi4gR2Vu
ZXJhbCBBcmNoaXRlY3R1cmUpOTcgMTU5IFEKRjAgMTEoLi4uLi4uLi4uLi4uLi4uLi4uLikx
MC4xMiBHIEYyKDYpMTEuNSBFKDIuMS4gRGVsaSkxMDcgMTcxIFEgLS4xNQoodmUpLS4yNSBH
KHJ5IHNlcnZpY2UgbW9kZWxzKS4xNSBFIEYwIDExKC4uLi4uLi4uLi4uLi4uLi4uKTcuNDUg
RyBGMig3KQoxMS41IEUoMi4yLiBDb25nZXN0aW9uIENvbnRyb2wpMTA3IDE4MyBRIEYwIDEx
KC4uLi4uLi4uLi4uLi4uLi4uLikxMS44OApHIEYyKDgpMTEuNSBFKDMuIExDVCBwYWNrKTk3
IDE5NSBRKGV0cyktLjEgRSBGMCAxMQooLi4uLi4uLi4uLi4uLi4uLi4uLi4uLikxLjcyIEcg
RjIoOCkxMS41IEUoMy4xLiBMQ1QgcGFjaykxMDcgMjA3IFEKKGV0IGZvcm1hdCktLjEgRSBG
MCAxMSguLi4uLi4uLi4uLi4uLi4uLi4uKS4yIEcgRjIoOSkxMS41IEUKKDMuMi4gTENUIHBh
Y2spMTA3IDIxOSBRKGV0IGhlYWRlciBcMjE0ZWxkcyktLjEgRSBGMCAxMQooLi4uLi4uLi4u
Li4uLi4uLi4pMy41NCBHIEYyKDkpMTEuNSBFKDMuMy4gSGVhZGVyKTEwNyAyMzEgUQooLUV4
dGVuc2lvbiBGaWVsZHMpLS4yIEUgRjAgMTEoLi4uLi4uLi4uLi4uLi4uLi4pNS4zIEcgRjIo
MTIpNi41IEUKKDQuIFByb2NlZHVyZXMpOTcgMjQzIFEgRjAgMTEoLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLik4LjU3IEcgRjIoMTQpNi41IEUKKDQuMS4gU2VuZGVyIE9wZXJhdGlvbikxMDcg
MjU1IFEgRjAgMTEoLi4uLi4uLi4uLi4uLi4uLi4uLik2LjQ5IEcgRjIoMTQpCjYuNSBFKDQu
Mi4gUmVjZWkpMTA3IDI2NyBRIC0uMTUodmUpLS4yNSBHIDIuNShyTykuMTUgRyhwZXJhdGlv
biktMi41IEUKRjAgMTEoLi4uLi4uLi4uLi4uLi4uLi4uKTEyLjg3IEcgRjIoMTUpNi41IEUo
NS4gU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMpCjk3IDI3OSBRIEYwIDExKC4uLi4uLi4uLi4u
Li4uLi4uLikxMi4xNyBHIEYyKDE2KTYuNSBFKDYuIElBTik5NyAyOTEgUQoyLjUoQUMpLS4z
NSBHKG9uc2lkZXJhdGlvbnMpLTIuNSBFIEYwIDExKC4uLi4uLi4uLi4uLi4uLi4uLi4pNy4x
MSBHIEYyCigxNik2LjUgRSg3LiBJbnRlbGxlY3R1YWwgUHJvcGVydHkgSXNzdWVzKTk3IDMw
MyBRIEYwIDExCiguLi4uLi4uLi4uLi4uLi4uLikxMi44OCBHIEYyKDE2KTYuNSBFKDguIEFj
a25vKTk3IDMxNSBRKHdsZWRnbWVudHMpLS4yNQpFIEYwIDExKC4uLi4uLi4uLi4uLi4uLi4u
Li4uKTUuNzYgRyBGMigxNyk2LjUgRSg5LiBBdXRob3JzJyBBZGRyZXNzZXMpOTcKMzI3IFEg
RjAgMTEoLi4uLi4uLi4uLi4uLi4uLi4uLi4pMS4zNSBHIEYyKDE4KTYuNSBFKDEwLiBGdWxs
IENvcCk5NyAzMzkKUSh5cmlnaHQgU3RhdGVtZW50KS0uMSBFIEYwIDExKC4uLi4uLi4uLi4u
Li4uLi4uLikxLjQyIEcgRjIoMjApNi41IEUgRjAKKEx1YnkvR2VtbWVsbC9WKTcyIDc2OSBR
KGljaXNhbm8vUml6em8vSGFuZGxlKS0uNjYgRSh5L0NybyktLjE2NSBFCjE2Ni44NTYod2Ny
b2Z0IFtQKS0uMjc1IEYoYWdlIDJdKS0uMTY1IEUgRVAKJSVQYWdlOiAzIDMKJSVCZWdpblBh
Z2VTZXR1cApCUAolJUVuZFBhZ2VTZXR1cAovRjAgMTEvVGltZXMtUm9tYW5AMCBTRihJTlRF
Uk5FVCk3MiA0OSBRIDcxLjU4NygtRFJBRlQgRXhwaXJlczopLTEuMDEyIEYKKEphbnVhcnkg
MjAwMikyLjc1IEUoSnVseSAyMDAxKTEyMy43MjYgRS9GMSAxMS9UaW1lcy1Cb2xkQDAgU0Yo
MS4pNzIgODUKUS9GMiAxNC9UaW1lcy1Cb2xkQDAgU0YoSW50cik1LjUgRShvZHVjdGlvbikt
LjI1MiBFIEYwCihUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhIG1hc3NpKTcyIDEwMS42IFEg
LS4xNjUodmUpLS4yNzUgRwoobHkgc2NhbGFibGUgcmVsaWFibGUgY29udGVudCBkZWxpKS4x
NjUgRSAtLjE2NSh2ZSktLjI3NSBHCihyeSBhbmQgc3RyZWFtIGRlbGkpLjE2NSBFIC0uMTY1
KHZlKS0uMjc1IEcocnkpLjE2NSBFCih0cmFuc3BvcnQsIExheWVyZWQgQ29kaW5nIFQpNzIg
MTE0LjYgUQoocmFuc3BvcnQgXChMQ1RcKSwgZm9yIG11bHRpLXJhdGUgY29udGVudCBkZWxp
KS0uMzg1IEUgLS4xNjUodmUpLS4yNzUgRwoocnkgcHJpbWFyaWx5IGRlc2lnbmVkIHRvKS4x
NjUgRShiZSB1c2VkIHdpdGggdGhlIElQIG11bHRpY2FzdCBuZXR3KTcyCjEyNy42IFEob3Jr
IHNlcnZpY2UsIGIpLS4xMSBFKHV0IE1BKS0uMjIgRSAyLjc1KFlhKS0xLjE1NSBHCihsc28g
YmUgdXNlZCB3aXRoIG90aGVyIGJhc2ljIHVuZGVybHlpbmcpLTIuNzUgRShuZXR3KTcyIDE0
MC42IFEKKG9yayBvciB0cmFuc3BvcnQgc2VydmljZXMgc3VjaCBhcyB1bmljYXN0IFVEUCkt
LjExIEUgNS41KC5MKS0xLjIyMSBHCihDVCBzdXBwb3J0cyBib3RoIHJlbGlhYmxlIGFuZCB1
bnJlbGlhYmxlKS01LjUgRShkZWxpKTcyIDE1My42IFEgLS4xNjUKKHZlKS0uMjc1IEcocnkp
LjE2NSBFIDIuNzUoLGEpLS43MTUgRwoobmQgc3VwcG9ydHMgY29uZ2VzdGlvbiBjb250cm9s
IG1lY2hhbmlzbXMgd2hpY2ggY29uZm9ybSB0byBSRkMyMzU3LikKLTIuNzUgRShMQ1QgaXMg
YSBiKTcyIDE3OS42IFEodWlsZGluZyBibG9jayBhcyBkZVwyMTRuZWQgaW4gUkZDMzA0OC4p
Ci0uMjIgRShDb21wbGV0ZSBwcm90b2NvbCBpbnN0YW50aWF0aW9ucyBNQSk1LjUgRSAyLjc1
KFliKS0xLjE1NSBHIDIuNzUKKGViKS0yLjc1IEcodWlsdCktMi45NyBFKGJ5IGNvbWJpbmlu
ZyB0aGUgTENUIGZyYW1lKTcyIDE5Mi42IFEgLS4xMSh3bykKLS4yNzUgRyhyayB3aXRoIG90
aGVyIGNvbXBvbmVudHMuKS4xMSBFIDIuNzUoQWMpNS41IEcKKG9tcGxldGUgcHJvdG9jb2wg
aW5zdGFudGlhdGlvbiB0aGF0KS0yLjc1IEUodXNlcyBMQ1QgTVVTVCBpbmNsdWRlIGEgY29c
Cm5nZXN0aW9uIGNvbnRyb2wgcHJvdG9jb2wgdGhhdCBpcyBjb21wYXRpYmxlIHdpdGggTENU
IGFuZCB0aGF0KTcyIDIwNS42ClEoY29uZm9ybXMgdG8gUkZDMjM1Ny4pNzIgMjE4LjYgUSAy
Ljc1KEFjKTUuNSBHCihvbXBsZXRlIHByb3RvY29sIGluc3RhbnRpYXRpb24gdGhhdCB1c2Vz
IExDVCBNQSktMi43NSBFIDIuNzUoWWkpLTEuMTU1CkcobmNsdWRlIGEgc2NhbGFibGUpLTIu
NzUgRQoocmVsaWFiaWxpdHkgcHJvdG9jb2wgdGhhdCBpcyBjb21wYXRpYmxlIHdpdGggTENU
KTcyIDIzMS42IFEgMi43NSgsaSkKLS44MTQgRyAyLjc1KHRNKS0yLjc1IEcgMi4zMSAtMS4x
NTUoQVkgaSktMi43NSBICihuY2x1ZGUgYW4gc2Vzc2lvbiBjb250cm9sIHByb3RvY29sIHRo
YXQpMS4xNTUgRShpcyBjb21wYXRpYmxlIHdpdGggTENUKQo3MiAyNDQuNiBRIDIuNzUoLGEp
LS44MTQgRyhuZCBpdCBNQSktMi43NSBFIDIuNzUoWWkpLTEuMTU1IEcKKG5jbHVkZSBvdGhl
ciBwcm90b2NvbHMgc3VjaCBhcyBzZWN1cml0eSBwcm90b2NvbHMuKS0yLjc1IEUKKExDVCBp
cyBwcmVzdW1lZCB0byBiZSB1c2VkIHdpdGggYW4gdW5kZXJseWluZyBuZXR3KTcyIDI3MC42
IFEKKG9yayBvciB0cmFuc3BvcnQgc2VydmljZSB0aGF0IGlzIGEgImJlc3QgZWYpLS4xMSBF
KGZvcnQiKS0uMjc1IEUKKHNlcnZpY2UgdGhhdCBkb2VzIG5vdCBndWFyYW50ZWUgcGFjayk3
MiAyODMuNiBRKGV0IHJlY2VwdGlvbiwgcGFjayktLjExCkUoZXQgcmVjZXB0aW9uIG9yZGVy
KS0uMTEgRSAyLjc1KCxhKS0uNDQgRyhuZCB3aGljaCBkb2VzIG5vdCBoYSktMi43NSBFCi0u
MTY1KHZlKS0uMjIgRyhhbik3MiAyOTYuNiBRIDIuNzUoeXMpLS4xNjUgRyh1cHBvcnQgZm9y
IFwyMTVvKS0yLjc1IEUKMi43NSh3byktLjI3NSBHIDIuNzUocmMpLTIuNzUgRyhvbmdlc3Rp
b24gY29udHJvbC4pLTIuNzUgRSAtLjE2NShGbyk1LjUKRyAyLjc1KHJlKS4xNjUgRyh4YW1w
bGUsIHRoZSBBbiktMi45MTUgRQooeS1Tb3VyY2UgTXVsdGljYXN0IFwoQVNNXCkgbW9kZWwp
LS4xNjUgRQoob2YgSVAgbXVsdGljYXN0IGFzIGRlXDIxNG5lZCBpbiBSRkMxMTEyIGlzIHN1
Y2ggYSAiYmVzdCBlZik3MiAzMDkuNiBRCihmb3J0IiBuZXR3KS0uMjc1IEUob3JrIHNlcnZp
Y2UuKS0uMTEgRShXaGlsZSB0aGUgYmFzaWMpNS41IEUKKHNlcnZpY2UgcHJvKTcyIDMyMi42
IFEodmlkZWQgYnkgUkZDMTExMiBpcyBsYXIpLS4xNjUgRQooZ2VseSBzY2FsYWJsZSwgcHJv
KS0uMTk4IEUodmlkaW5nIGNvbmdlc3Rpb24gY29udHJvbCBvciByZWxpYWJpbGl0eSkKLS4x
NjUgRShzaG91bGQgYmUgZG9uZSBjYXJlZnVsbHkgdG8gYSk3MiAzMzUuNiBRIC0uMjIodm8p
LS4yMiBHKGlkIHNlKQouMjIgRSAtLjE2NSh2ZSktLjI3NSBHCihyZSBzY2FsYWJpbGl0eSBs
aW1pdGF0aW9ucywgZXNwZWNpYWxseSBpbiBwcmVzZW5jZSBvZikuMTY1IEUKKGhldGVyb2dl
bmVvdXMgc2V0cyBvZiByZWNlaSk3MiAzNDguNiBRIC0uMTY1KHZlKS0uMjc1IEcocnMuKS4x
NjUgRQooU2NhbGFiaWxpdHkgcmVmZXJzIHRvIHRoZSBiZWhhKTcyIDM3NC42IFEKKHZpb3Ig
b2YgdGhlIHByb3RvY29sIGluIHJlbGF0aW9uIHRvIHRoZSBudW1iZXIgb2YgcmVjZWkpLS4y
MiBFIC0uMTY1Cih2ZSktLjI3NSBHKHJzIGFuZCkuMTY1IEUobmV0dyk3MiAzODcuNiBRCihv
cmsgcGF0aHMsIHRoZWlyIGhldGVyb2dlbmVpdHkpLS4xMSBFIDIuNzUoLGEpLS43MTUgRwoo
bmQgdGhlIGFiaWxpdHkgdG8gYWNjb21tb2RhdGUgZHluYW1pY2FsbHkgdiktMi43NSBFKGFy
aWFibGUgc2V0cyBvZikKLS4yNzUgRShyZWNlaSk3MiA0MDAuNiBRIC0uMTY1KHZlKS0uMjc1
IEcgMi43NShycy4gU2NhbGFiaWxpdHkpLjE2NSBGKGxcCmltaXRhdGlvbnMgY2FuIGNvbWUg
ZnJvbSBtZW1vcnkgb3IgcHJvY2Vzc2luZyByZXF1aXJlbWVudHMsIG9yIGZyb20gdGhlKQoy
Ljc1IEUoYW1vdW50IG9mIHBhY2spNzIgNDEzLjYgUShldCB0cmFmKS0uMTEgRQooXDIxNGMg
Z2VuZXJhdGVkIGJ5IHRoZSBwcm90b2NvbC4pLS4yNzUgRQooSW4gdHVybiwgc3VjaCBsaW1p
dGF0aW9ucyBtYXkgYmUgYSk1LjUgRQooY29uc2VxdWVuY2Ugb2YgdGhlIGZlYXR1cmVzIHRo
YXQgYSBjb21wbGV0ZSByZWxpYWJsZSBjb250ZW50IGRlbGkpNzIKNDI2LjYgUSAtLjE2NSh2
ZSktLjI3NSBHKHJ5IG9yIHN0cmVhbSBkZWxpKS4xNjUgRSAtLjE2NSh2ZSktLjI3NSBHCihy
eSBwcm90b2NvbCkuMTY1IEUoaXMgZSk3MiA0MzkuNiBRKHhwZWN0ZWQgdG8gcHJvKS0uMTY1
IEUodmlkZS4pLS4xNjUgRQooQ29uZ2VzdGlvbiBjb250cm9sIHJlZmVycyB0byB0aGUgYWJp
bGl0eSBvZiB0aGUgcHJvdG9jb2wgdG8gYWRhcHQgaXRzIFwKdGhyb3VnaHB1dCB0byB0aGUg
YSk3MiA0NjUuNiBRIC0uMjc1KHZhKS0uMjIgRyhpbGFibGUpLjI3NSBFCihiYW5kd2lkdGgg
b24gdGhlIHBhdGggdG8gdGhlIHJlY2VpKTcyIDQ3OC42IFEgLS4xNjUodmUpLS4yNzUgRwoo
cnMsIGFuZCB0byBzaGFyZSBiYW5kd2lkdGggZikuMTY1IEUoYWlybHkgd2l0aCBjb21wZXRp
bmcgXDIxNW8pLS4xMSBFCih3cyBzdWNoKS0uMjc1IEUoYXMgVENQKTcyIDQ5MS42IFEgMi43
NSguSSktMS4yMjEgRyAyLjc1KHRpKS0yLjc1IEcgMi43NQooc1IpLTIuNzUgRyhFUSktMi43
NSBFCihVSVJFRCB0aGF0IHByb3RvY29scyBpbXBsZW1lbnQgc29tZSBmb3JtIG9mIGNvbmdl
c3Rpb24gY29udHJvbCBvbiBlYWNoKQotLjExIEUoc2Vzc2lvbiBzbyB0aGF0IHRoZSk3MiA1
MDQuNiBRIDIuNzUoeW4pLS4xNjUgRyhvdCBjb21wZXRlIHVuZikKLTIuNzUgRShhaXJseSB3
aXRoIGUpLS4xMSBFKHhpc3RpbmcgYW5kIGFkYXB0aSktLjE2NSBFIC4zMyAtLjE2NSh2ZSBw
KQotLjI3NSBIKHJvdG9jb2xzIHN1Y2ggYXMgVENQKS4xNjUgRSguKS0xLjIyMSBFIC0uMTY1
KEZvKTcyIDUzMC42IFMgMi43NQoocm0pLjE2NSBHKHVsdGktcmF0ZSBwcm90b2NvbHMsIHRo
ZSBzZW5kZXIgdHlwaWNhbGx5IHNlbmRzIHBhY2spLTIuNzUgRQooZXRzIGF0IGEgY29uc3Rh
bnQgYWdncmUpLS4xMSBFIC0uMDU1KGdhKS0uMTY1IEcodGUgcmF0ZSB0bykuMDU1IEUKKG11
bHRpcGxlIGNoYW5uZWxzLCBiKTcyIDU0My42IFEodXQgaW5kaSktLjIyIEUodmlkdWFsIHJl
Y2VpKS0uMjc1IEUKLS4xNjUodmUpLS4yNzUgRyhycyBhZGp1c3Qgd2hpY2ggcG9ydGlvbiBv
ZiB0aGVzZSBwYWNrKS4xNjUgRShldHMgdGhlKQotLjExIEUgMi43NSh5YSktLjE2NSBHKHR0
ZW1wdCB0byktMi43NSBFKHJlY2VpKTcyIDU1Ni42IFEgLjMzIC0uMTY1Cih2ZSBiKS0uMjc1
IEggMi43NSh5YSkuMTY1IEcoZGp1c3Rpbmcgd2hpY2ggc2V0IG9mIGNoYW5uZWxzIHRoZSkt
Mi43NSBFCjIuNzUoeWEpLS4xNjUgRyhyZSBqb2luZWQgdG8gYXQgZWFjaCBwb2ludCBpbiB0
aW1lIGRlcGVuZGluZyBvbiktMi43NSBFCih0aGUgYSk3MiA1NjkuNiBRIC0uMjc1KHZhKS0u
MjIgRyhpbGFibGUgYmFuZHdpZHRoIGJldHdlZW4gdGhlIHJlY2VpKQouMjc1IEUgLS4xNjUo
dmUpLS4yNzUgRyAyLjc1KHJhKS4xNjUgRyhuZCB0aGUgc2VuZGVyKS0yLjc1IEUgMi43NSgs
YikKLS40NCBHKHV0IGluZGVwZW5kZW50IG9mIGFsbCBvdGhlciktMi45NyBFKHJlY2VpKTcy
IDU4Mi42IFEgLS4xNjUodmUpCi0uMjc1IEcgMi43NShycy4gVGh1cywpLjE2NSBGKGZvciBt
dWx0aS1yYXRlIHByb3RvY29scywgdGhlIHBhY2spMi43NSBFCihldCByZWNlcHRpb24gcmF0
ZSBvZiBlYWNoIHJlY2VpKS0uMTEgRSAtLjE2NSh2ZSktLjI3NSBHIDIuNzUocm0pLjE2NSBH
CihheSB2KS0yLjc1IEUoYXJ5KS0uMjc1IEUoZHluYW1pY2FsbHkgYWNjb3JkaW5nIHRvIHRo
ZSBhKTcyIDU5NS42IFEKLS4yNzUodmEpLS4yMiBHKGlsYWJsZSBiYW5kd2lkdGggYmV0d2Vl
biBlYWNoIHJlY2VpKS4yNzUgRSAtLjE2NSh2ZSkKLS4yNzUgRyAyLjc1KHJhKS4xNjUgRyhu
ZCB0aGUgc2VuZGVyKS0yLjc1IEUoLCktLjQ0IEUKKGluZGVwZW5kZW50IG9mIHRoZSBvdGhl
ciByZWNlaSk3MiA2MDguNiBRIC0uMTY1KHZlKS0uMjc1IEcgMi43NShycy4gRikKLjE2NSBG
KG9yIHNpbmdsZS1yYXRlIHByb3RvY29scywgdGhlIHNlbmRlciB0eXBpY2FsbHkgc2VuZHMg
cGFjayktLjE2NSBFCihldHMgdG8pLS4xMSBFKG9uZSBjaGFubmVsIGF0IHYpNzIgNjIxLjYg
UShhcmlhYmxlIHJhdGVzIG8pLS4yNzUgRSAtLjE2NQoodmUpLS4xNjUgRyAyLjc1KHJ0KS4x
NjUgRyhpbWUgZGVwZW5kaW5nIG9uIGZlZWRiYWNrIGZyb20gcmVjZWkpLTIuNzUgRQotLjE2
NSh2ZSktLjI3NSBHKHJzLCBhbmQgYWxsIHJlY2VpKS4xNjUgRSAtLjE2NSh2ZSktLjI3NSBH
KHJzKS4xNjUgRQooYXR0ZW1wdCB0byByZWNlaSk3MiA2MzQuNiBRIC4zMyAtLjE2NSh2ZSBh
KS0uMjc1IEgobGwgcGFjaykuMTY1IEUKKGV0cyB0cmFuc21pdHRlZCBieSB0aGUgc2VuZGVy
IGF0IGFsbCBwb2ludHMgaW4gdGltZS4pLS4xMSBFCihUaHVzLCBmb3Igc2luZ2xlLXJhdGUp
OC4yNSBFKHByb3RvY29scywgdGhlIHBhY2spNzIgNjQ3LjYgUQooZXQgcmVjZXB0aW9uIHJh
dGUgb2YgYWxsIHJlY2VpKS0uMTEgRSAtLjE2NSh2ZSktLjI3NSBHKHJzIG1heSB2KS4xNjUg
RQooYXJ5IGR5bmFtaWNhbGx5IG8pLS4yNzUgRSAtLjE2NSh2ZSktLjE2NSBHIDIuNzUocnQp
LjE2NSBHKGltZSBpbiBlKQotMi43NSBFKHhhY3RseSB0aGUpLS4xNjUgRShzYW1lIHcpNzIg
NjYwLjYgUQooYXkgZGVwZW5kZW50IG9uIHRoZSBmZWVkYmFjayBvZiBvdGhlciByZWNlaSkt
LjExIEUgLS4xNjUodmUpLS4yNzUgRwoocnMgdG8gdGhlIHNlbmRlcikuMTY1IEUgNS41KC5H
KS0uNjA1IEcoZW5lcmFsbHkpLTUuNSBFIDIuNzUoLGFtKS0uNzE1IEcKKHVsdGktcmF0ZSkt
Mi43NSBFKHByb3RvY29sIGlzIHByZWZlcmFibGUgdG8gYSBzaW5nbGUtcmF0ZSBwcm90b2Nv
bCBpbiBcCmEgaGV0ZXJvZ2VuZW91cyByZWNlaSk3MiA2NzMuNiBRIC0uMTY1KHZlKS0uMjc1
IEcgMi43NShyZSkuMTY1IEcgLS40NAoobnYpLTIuNzUgRyhpcm9ubWVudCwgYikuNDQgRSh1
dCBvbmx5KS0uMjIgRShpZiBpdCBjYW4gYmUgYWNoaWUpNzIgNjg2LjYKUSAtLjE2NSh2ZSkt
LjI3NSBHIDIuNzUoZHcpLjE2NSBHKGl0aG91dCBzYWNyaVwyMTRjaW5nIHNjYWxhYmlsaXR5
KS0yLjc1CkUoLiktLjcxNSBFKExheWVyZWQgY29kaW5nIHJlZmVycyB0byB0aGUgYWJpbGl0
eSB0byBwcm9kdWNlIGEgY29kZWQgc3RyXAplYW0gdGhhdCBjYW4gYmUgc3BsaXQgaW50byBt
dWx0aXBsZSk3MiA3MTIuNiBRCihsYXllcnMgdGhhdCBjYW4gYmUgc2VudCB0byBkaWYpNzIg
NzI1LjYgUQooZmVyZW50IGNoYW5uZWxzLiBUaGUgY29kZWQgc3RyZWFtIGNhbiBiZSBnZW5l
cmF0ZWQgZWl0aGVyIGZyb20gYSktLjI3NQpFKEx1YnkvR2VtbWVsbC9WKTcyIDc2OSBRKGlj
aXNhbm8vUml6em8vSGFuZGxlKS0uNjYgRSh5L0NybyktLjE2NSBFCjExNy4zNTYod2Nyb2Z0
IFNlY3Rpb24pLS4yNzUgRiAyLjc1KDEuIFtQKTIuNzUgRihhZ2UgM10pLS4xNjUgRSBFUAol
JVBhZ2U6IDQgNAolJUJlZ2luUGFnZVNldHVwCkJQCiUlRW5kUGFnZVNldHVwCi9GMCAxMS9U
aW1lcy1Sb21hbkAwIFNGKElOVEVSTkVUKTcyIDQ5IFEgNzEuNTg3KC1EUkFGVCBFeHBpcmVz
OiktMS4wMTIgRgooSmFudWFyeSAyMDAyKTIuNzUgRShKdWx5IDIwMDEpMTIzLjcyNiBFPDhj
Nzg+NzIgODUgUShlZCBwaWVjZSBvZiBjb250ZVwKbnQsIG9yIGZyb20gYW4gb25nb2luZyBk
YXRhIHN0cmVhbSwgYW5kIGhhcyB0aGUgcHJvcGVydHkgdGhhdCB0aGUgcXVhbGlcCnR5KS0u
MTY1IEUgLS4xNjUoZXgpNzIgOTggUyhwZXJpZW5jZWQgYnkgYSByZWNlaSkuMTY1IEUgLS4x
NjUodmUpLS4yNzUgRwoyLjc1KHJcKCkuMTY1IEcoaW4gdGVybXMgb2YgcXVhbGl0eSBvZiBw
bGF5b3V0LCBvciBvKS0yLjc1IEUgLS4xNjUodmUpCi0uMTY1IEcocmFsbCB0cmFuc2ZlciBz
cGVlZFwpIGlzIHByb3BvcnRpb25hbCkuMTY1IEUodG8gaG8pNzIgMTExIFEgMi43NQood20p
LS4yNzUgRyhhbiktMi43NSBFIDIuNzUoeW8pLS4xNjUgRyAyLjc1KGZ0KS0yLjc1IEcKKGhl
IGxheWVycyB0aGUgcmVjZWkpLTIuNzUgRSAtLjE2NSh2ZSktLjI3NSBHIDIuNzUocmkpLjE2
NSBHIDIuNzUoc2opCi0yLjc1IEcob2luZWQgdG8uKS0yLjc1IEUoTENUIE1BKTUuNSBFIDIu
NzUoWWIpLTEuMTU1IEcgMi43NShlYyktMi43NSBHCihvbWJpbmVkIHdpdGggYSByZWxpYWJp
bGl0eSktMi43NSBFKHByb3RvY29sIHN1Y2ggYXMgdGhlIGdlbmVyYWwgY2xhc3MgXApvZiBw
cm90b2NvbHMgZGVzY3JpYmVkIGluIFs3XS4gTENUIE1VU1QgYmUgY29tYmluZWQgd2l0aCBh
KTcyIDEyNCBRKGNvblwKZ2VzdGlvbiBjb250cm9sIHByb3RvY29sIHRoYXQgaXMgY29tcGxp
YW50IHdpdGggUkZDMjM1NywgYW5kIHRoaXMgTUEpNzIKMTM3IFEgMi43NShZYiktMS4xNTUg
RyAyLjc1KGVlKS0yLjc1IEcoaXRoZXIgc2luZ2xlLXJhdGUpLTIuNzUgRQoob3IgbXVsdGkt
cmF0ZSBjb25nZXN0aW9uIGNvbnRyb2wgbyk3MiAxNTAgUSAtLjE2NSh2ZSktLjE2NSBHIDIu
NzUocnQpCi4xNjUgRyhoZSBlbnRpcmUgc2Vzc2lvbi4pLTIuNzUgRShJdCBpcyBtb3N0IGNv
bXBlbGxpbmcgdG8gdXNlIExDVCBpbikKNS41IEUoY29uanVuY3Rpb24gd2l0aCBhIGxheWVy
ZWQgY29uZ2VzdGlvbiBjb250cm9sIHByb3RvY29sIHN1Y2ggYXMgdGhcCmUgY2xhc3Mgb2Yg
cHJvdG9jb2xzIGRlc2NyaWJlZCBpbik3MiAxNjMgUShbOV0sIGFuZCBzcGVjaVwyMTRlZCBp
biBbOV0sXAogd2hpY2ggYXJlIG11bHRpLXJhdGUgY29uZ2VzdGlvbiBjb250cm9sIHByb3Rv
Y29scy4pNzIgMTc2IFEKKFRoZSBjb25jZXB0IG9mIGxheWVyZWQgY29kaW5nIHcpNzIgMjAy
IFEKKGFzIFwyMTRyc3QgaW50cm9kdWNlZCB3aXRoIHJlZmVyZW5jZSB0byBhdWRpbyBhbmQg
dmlkZW8gc3RyZWFtcy4pLS4xMSBFCi0uMTY1KEZvKTcyIDIxNSBTIDIuNzUocmUpLjE2NSBH
KHhhbXBsZSwgdGhlIGluZm9ybWF0aW9uIGFzc29jaWF0ZWQgd2l0XApoIGEgVFYgYnJvYWRj
YXN0IGNhbiBiZSBwYXJ0aXRpb25lZCBpbnRvIHRocmVlIGxheWVycywpLTIuOTE1IEUKKGNv
cnJlc3BvbmRpbmcgdG8gYmxhY2sgYW5kIHdoaXRlLCBjb2xvcik3MiAyMjggUSAyLjc1KCxh
KS0uNDQgRwoobmQgSERUViBxdWFsaXR5KS0yLjc1IEUgMi43NSguUiktLjcxNSBHKGVjZWkp
LTIuNzUgRSAtLjE2NSh2ZSktLjI3NSBHCihycyBjYW4gZSkuMTY1IEUoeHBlcmllbmNlIGRp
ZiktLjE2NSBFKGZlcmVudCktLjI3NSBFKHF1YWxpdHkgd2l0aG91dCB0XApoZSBuZWVkIGZv
ciB0aGUgc2VuZGVyIHRvIHJlcGxpY2F0ZSBpbmZvcm1hdGlvbiBpbiB0aGUgZGlmKTcyIDI0
MSBRCihmZXJlbnQgbGF5ZXJzLiktLjI3NSBFCihUaGUgY29uY2VwdCBvZiBsYXllcmVkIGNv
ZGluZyBjYW4gYmUgbmF0dXJhbGx5IGUpNzIgMjY3IFEKKHh0ZW5kZWQgdG8gcmVsaWFibGUg
Y29udGVudCBkZWxpKS0uMTY1IEUgLS4xNjUodmUpLS4yNzUgRyhyeSBwcm90b2NvbHMpCi4x
NjUgRSh3aGVuIEYpNzIgMjgwIFEob3J3KS0uMTY1IEUoYXJkIEVycm9yIENvcnJlY3Rpb24g
XChGRUNcKSB0ZWNobmlxXAp1ZXMgYXJlIHVzZWQgZm9yIGNvZGluZyB0aGUgZGF0YSBzdHJl
YW0gWzEyXSBbMTBdKS0uMTEgRShbM10gWzE0XSBbMTVdIFwKWzFdLiBCeSB1c2luZyBGRUMs
IHRoZSBkYXRhIHN0cmVhbSBpcyB0cmFuc2Zvcm1lZCBpbiBzdWNoIGEgdyk3MiAyOTMgUQoo
YXkgdGhhdCByZWNvbnN0cnVjdGlvbiktLjExIEUob2YgYSBkYXRhIG9iamVjdCBkb2VzIG5v
dCBkZXBlbmQgb24gdGhlIFwKcmVjZXB0aW9uIG9mIHNwZWNpXDIxNGMgZGF0YSBwYWNrKTcy
IDMwNiBRKGV0cywgYiktLjExIEUKKHV0IG9ubHkgb24gdGhlIG51bWJlciktLjIyIEUob2Yg
ZGlmKTcyIDMxOSBRKGZlcmVudCBwYWNrKS0uMjc1IEUKKGV0cyByZWNlaSktLjExIEUgLS4x
NjUodmUpLS4yNzUgRyAyLjc1KGQuIEFzKS4xNjUgRiAyLjc1KGFyKTIuNzUgRwooZXN1bHQs
IGJ5IGluY3JlYXNpbmcgdGhlIG51bWJlciBvZiBsYXllcnMgYSByZWNlaSktMi43NSBFIC0u
MTY1KHZlKQotLjI3NSBHIDIuNzUocmkpLjE2NSBHKHMpLTIuNzUgRShyZWNlaSk3MiAzMzIg
USh2aW5nIGZyb20sIHRoZSByZWNlaSkKLS4yNzUgRSAtLjE2NSh2ZSktLjI3NSBHIDIuNzUo
cmMpLjE2NSBHCihhbiByZWR1Y2UgdGhlIHRyYW5zZmVyIHRpbWUgYWNjb3JkaW5nbHkpLTIu
NzUgRSA1LjUoLk0pLS43MTUgRwoob3JlIGRldGFpbHMgb24gdGhlIHVzZSBvZiktNS41IEUo
RkVDIGZvciByZWxpYWJsZSBjb250ZW50IGRlbGkpNzIgMzQ1IFEKLS4xNjUodmUpLS4yNzUg
RyhyeSBjYW4gYmUgZm91bmQgaW4gWzZdLikuMTY1IEUKKFJlbGlhYmxlIHByb3RvY29scyBh
aW0gYXQgZ2kpNS41IEUodmluZyBndWFyYW50ZWVzKS0uMjc1IEUKKG9uIHRoZSByZWxpYWJs
ZSBkZWxpKTcyIDM1OCBRIC0uMTY1KHZlKS0uMjc1IEcKKHJ5IG9mIGRhdGEgZnJvbSB0aGUg
c2VuZGVyIHRvIHRoZSBpbnRlbmRlZCByZWNpcGllbnRzLikuMTY1IEUKKEd1YXJhbnRlZXMg
dik1LjUgRShhcnkgZnJvbSktLjI3NSBFKHNpbXBsZSBwYWNrKTcyIDM3MSBRKGV0IGRhdGEg
aW50ZSkKLS4xMSBFKGdyaXR5IHRvIHJlbGlhYmxlIGRlbGkpLS4xNjUgRSAtLjE2NSh2ZSkt
LjI3NSBHCihyeSBvZiBhIHByZWNpc2UgY29wKS4xNjUgRSAyLjc1KHlvKS0uMTEgRyAyLjc1
KGZhZCktMi43NSBHCihhdGEgb2JqZWN0IHRvIGFsbCBpbnRlbmRlZCktMi43NSBFIDIuNzUo
cmVjaXBpZW50cy4gU2UpNzIgMzg0IFIgLS4xNjUKKHZlKS0uMjc1IEcocmFsIHJlbGlhYmxl
IGNvbnRlbnQgZGVsaSkuMTY1IEUgLS4xNjUodmUpLS4yNzUgRwoocnkgcHJvdG9jb2xzIGhh
KS4xNjUgRSAuMzMgLS4xNjUodmUgYiktLjIyIEgoZWVuIGIpLjE2NSBFCih1aWx0IG9uIHRv
cCBvZiBJUCBtdWx0aWNhc3QsIGIpLS4yMiBFKHV0KS0uMjIgRShzY2FsYWJpbGl0eSB3KTcy
IDM5NyBRCihhcyBub3QgYSBkZXNpZ24gZ29hbCBmb3IgbWFuKS0uMTEgRSAyLjc1KHlvKS0u
MTY1IEcgMi43NShmdCktMi43NSBHCjIuNzUoaGVtLiBJbiktMi43NSBGKHNvbWUgY2FzZXMs
IHNjYWxhYmlsaXR5IGlzIGFjaGllKTIuNzUgRSAtLjE2NSh2ZSkKLS4yNzUgRyAyLjc1KGRi
KS4xNjUgRyh5KS0yLjc1IEUKKGludHJvZHVjaW5nIGNoYW5nZXMgdG8gcm91dGVycyBvciBv
dGhlciBpbmZyYXN0cnVjdHVyZSBcKHNlZSBmb3IgZSk3Mgo0MTAgUSh4YW1wbGUgWzEzXSBc
KSwgYW4gYXBwcm9hY2ggd2hpY2gpLS4xNjUgRQooaGFzIGFuIGltcGFjdCBvbiBuZWFyIHRl
cm0gZGVwbG8pNzIgNDIzIFEoeW1lbnQgYWNyb3NzIHRoZSBJbnRlcm5ldC4pCi0uMTEgRSAt
MS4xIC0uODgoVHcgbyk3MiA0NDkgVChvZiB0aGUgaykzLjYzIEUgLjMzIC0uMTY1KGV5IGQp
LS4xMSBIKGlmKQouMTY1IEUoXDIxNGN1bHRpZXMgaW4gc2NhbGluZyByZWxpYWJsZSBjb250
ZW50IGRlbGkpLS4yNzUgRSAtLjE2NSh2ZSkKLS4yNzUgRyhyeSB1c2luZyBJUCBtdWx0aWNh
c3QgYXJlIGRlYWxpbmcgd2l0aCkuMTY1IEUKKHRoZSBhbW91bnQgb2YgZGF0YSB0aGF0IFwy
MTVvKTcyIDQ2MiBRKHdzIGZyb20gcmVjZWkpLS4yNzUgRSAtLjE2NSh2ZSkKLS4yNzUgRyhy
cyBiYWNrIHRvIHRoZSBzZW5kZXIpLjE2NSBFIDIuNzUoLGEpLS40NCBHCihuZCB0aGUgYXNz
b2NpYXRlZCByZXNwb25zZSktMi43NSBFCihcKGdlbmVyYWxseSBkYXRhIHJldHJhbnNtaXNz
aW9uc1wpIGZyb20gdGhlIHNlbmRlcik3MiA0NzUgUSA1LjUoLlApCi0uNjA1IEcocm90b2Nv
bHMgdGhhdCBhKS01LjUgRSAtLjIyKHZvKS0uMjIgRyhpZCBhbikuMjIgRSAyLjc1KHlzKS0u
MTY1CkcodWNoIGZlZWRiYWNrLCBhbmQpLTIuNzUgRQoobWluaW1pemUgdGhlIGFtb3VudCBv
ZiByZXRyYW5zbWlzc2lvbnMsIGNhbiBiZSBtYXNzaSk3MiA0ODggUSAtLjE2NSh2ZSkKLS4y
NzUgRyhseSBzY2FsYWJsZS4pLjE2NSBFKExDVCByZWxpZXMgb24gdGhlKTUuNSBFIC0uMjIo
YXYpNzIgNTAxIFMKKGFpbGFiaWxpdHkgb2YgRkVDIGNvZGVzIG9yIGEgbGF5ZXJlZCBjb2Rl
YyB0byBhY2hpZSktLjA1NSBFIC4zMyAtLjE2NQoodmUgciktLjI3NSBIKGVsaWFiaWxpdHkg
d2l0aCBsaXR0bGUgb3Igbm8gZmVlZGJhY2suKS4xNjUgRQooSW4gdGhpcyBkb2N1bWVudCB3
ZSBwcmVzZW50IHRoZSBhcmNoaXRlY3R1cmUgYW5kIGFic3RyYWN0IExDVCBwYWNrKTcyCjUy
NyBRKGV0IHN0cnVjdHVyZSwgYW5kIGlsbHVzdHJhdGUgaXRzKS0uMTEgRQooc3VwcG9ydCBm
b3IgbXVsdGktcmF0ZSBsYXllcmVkIGNvbmdlc3Rpb24gY29udHJvbC4pNzIgNTQwIFEoVGhl
IGspNzIKNTY2IFEgLjMzIC0uMTY1KGV5IHcpLS4xMSBIKG9yZHMgIk1VU1QiLCAiTVVTVCBO
TykuMDU1IEUoVCIsICJSRVEpLS40NCBFCihVSVJFRCIsICJTSEFMTCIsICJTSEFMTCBOTykt
LjExIEUoVCIsKS0uNDQgRSgiU0hPVUxEIiwgIlNIT1VMRCBOTyk3Mgo1NzkgUShUIiwgIlJF
Q09NTUVOREVEIiwgIk1BKS0uNDQgRShZIiwgYW5kICJPUFRJT04pLTEuMTU1IEUKKEFMIiBp
biB0aGlzKS0uMzg1IEUKKGRvY3VtZW50IGFyZSB0byBiZSBpbnRlcnByZXRlZCBhcyBkZXNj
cmliZWQgaW4gUkZDMjExOS4pNzIgNTkyIFEvRjEgMTEKL1RpbWVzLUJvbGRAMCBTRigxLjEu
KTcyIDYzMSBRL0YyIDEzL1RpbWVzLUJvbGRAMCBTRihSZWxhdGVkIERvY3VtZW50cykKNS41
IEUgRjAgMi43NShBbSk3MiA2NDcuNiBTCihvcmUgaW4tZGVwdGggZGVzY3JpcHRpb24gb2Yg
dGhlIHVzZSBvZiBGRUMgaW4gUmVsaWFibGUgTXVsdGljYXN0IFQpCi0yLjc1IEUocmFuc3Bv
cnQgXChSTVRcKSBwcm90b2NvbHMpLS4zODUgRShpcyBnaSk3MiA2NjAuNiBRIC0uMTY1KHZl
KQotLjI3NSBHIDIuNzUobmkpLjE2NSBHIDIuNzUoblspLTIuNzUgRwooNl0uIFNvbWUgb2Yg
dGhlIEZFQyBjb2RlY3MgdGhhdCBNQSktMi43NSBFIDIuNzUoWWIpLTEuMTU1IEcgMi43NShl
dSkKLTIuNzUgRyhzZWQgYnkgTENUIGZvciByZWxpYWJsZSBjb250ZW50IGRlbGkpLTIuNzUg
RSAtLjE2NSh2ZSktLjI3NSBHCihyeSkuMTY1IEUoYXJlIHNwZWNpXDIxNGVkIGluIFs3XS4g
TENUIHJlc2Vydik3MiA2NzMuNiBRCihlcyBvcGFxdWUgaGVhZGVyIFwyMTRlbGRzIHRoYXQg
Y2FuIGJlIHVzZWQgdG8gdHJhbnNwb3J0IGluZm9ybWF0aW9uKQotLjE2NSBFKHJlbGF0ZWQg
dG8gdGhlIHBheWxvYWQgZW5jb2RpbmcuKTcyIDY4Ni42IFEoSW1wbGVtZW50b3JzIG9mIExD
VFwKIE1VU1QgYWxzbyBpbXBsZW1lbnQgY29uZ2VzdGlvbiBjb250cm9sIGluIGFjY29yZGFu
Y2UgdG8gUkZDMjM1NywpNzIKNzEyLjYgUSh3aGVyZSB0aGUgY29uZ2VzdGlvbiBjb250cm9s
IGlzIG8pNzIgNzI1LjYgUSAtLjE2NSh2ZSktLjE2NSBHCjIuNzUocnQpLjE2NSBHKGhlIGVu
dGlyZSBzZXNzaW9uLiktMi43NSBFCihTb21lIHBvc3NpYmxlIHNjaGVtZXMgYXJlIHNwZWNp
XDIxNGVkIGluKTUuNSBFKEx1YnkvR2VtbWVsbC9WKTcyIDc2OSBRCihpY2lzYW5vL1Jpenpv
L0hhbmRsZSktLjY2IEUoeS9Dcm8pLS4xNjUgRSAxMDkuMTA2KHdjcm9mdCBTZWN0aW9uKS0u
Mjc1CkYgMi43NSgxLjEuIFtQKTIuNzUgRihhZ2UgNF0pLS4xNjUgRSBFUAolJVBhZ2U6IDUg
NQolJUJlZ2luUGFnZVNldHVwCkJQCiUlRW5kUGFnZVNldHVwCi9GMCAxMS9UaW1lcy1Sb21h
bkAwIFNGKElOVEVSTkVUKTcyIDQ5IFEgNzEuNTg3KC1EUkFGVCBFeHBpcmVzOiktMS4wMTIg
RgooSmFudWFyeSAyMDAyKTIuNzUgRShKdWx5IDIwMDEpMTIzLjcyNiBFKFs5XS4gTENUIHJl
c2Vydik3MiA4NSBRKGVzIG9wYVwKcXVlIGhlYWRlciBcMjE0ZWxkcyB0aGF0IGNhbiBiZSB1
c2VkIGJ5IHRoZSBjb25nZXN0aW9uIGNvbnRyb2wgc2NoZW1lIHRcCm8pLS4xNjUgRSh0cmFu
c3BvcnQgaW5mb3JtYXRpb24gcmVsYXRlZCB0byBjb25nZXN0aW9uIGNvbnRyb2wuKTcyIDk4
IFEoXApJdCBpcyBSRUNPTU1FTkRFRCB0aGF0IExDVCBpbXBsZW1lbnRvcnMgdXNlIHNvbWUg
YXV0aGVudGljYXRpb24gc2NoZW1lIFwKdG8gcHJvdGVjdCB0aGUpNzIgMTI0IFEocHJvdG9j
b2wgZnJvbSBhdHRhY2tzLiBBbiBlKTcyIDEzNyBRCih4YW1wbGUgb2YgYSBwb3NzaWJseSBz
dWl0YWJsZSBzY2hlbWUgaXMgZGVzY3JpYmVkIGluIFsxMV0uKS0uMTY1IEUvRjEKMTEvVGlt
ZXMtQm9sZEAwIFNGKDEuMi4pNzIgMTYzIFEvRjIgMTMvVGltZXMtQm9sZEAwIFNGKEVuKTUu
NSBFKHZpciktLjUyCkUob25tZW50YWwgUmVxdWlyKS0uMjM0IEUoZW1lbnRzIGFuZCBDb25z
aWRlcmF0aW9ucyktLjIzNCBFIEYwCihMQ1QgaXMgaW50ZW5kZWQgZm9yIGNvbmdlc3Rpb24g
Y29udHJvbGxlZCwgbXVsdGktcmF0ZSBkZWxpKTcyIDE3OS42IFEKLS4xNjUodmUpLS4yNzUg
RyhyeSBvZiBvYmplY3RzIGFuZCBzdHJlYW1zIFwoYm90aCkuMTY1IEUKKHJlbGlhYmxlIGNv
bnRlbnQgZGVsaSk3MiAxOTIuNiBRIC0uMTY1KHZlKS0uMjc1IEcKKHJ5IGFuZCBzdHJlYW1p
bmcgb2YgbXVsdGltZWRpYSBpbmZvcm1hdGlvblwpLikuMTY1IEUKKExDVCBpcyBtb3N0IGFw
cGxpY2FibGUgZm9yIGRlbGkpNzIgMjE4LjYgUSAtLjE2NSh2ZSktLjI3NSBHCihyeSBvZiBv
YmplY3RzIG9yIHN0cmVhbXMgb2Ygc3Vic3RhbnRpYWwgbGVuZ3RoLCBpLmUuLCBvYmplY3Rz
IG9yKS4xNjUgRQooc3RyZWFtcyB0aGF0IHJhbmdlIGluIGxlbmd0aCBmcm9tIGh1bmRyZWRz
IG9mIGtpbG9ieXRlcyB0byBtYW4pNzIgMjMxLjYKUSAyLjc1KHlnKS0uMTY1IEcoaWcpLTIu
NzUgRShhYnl0ZXMsIGFuZCB3aG9zZSB0cmFuc2ZlciktLjA1NSBFCih0aW1lIGlzIGluIHRo
ZSBvcmRlciBvZiB0ZW5zIG9mIHNlY29uZHMgb3IgbW9yZS4pNzIgMjQ0LjYgUQooTENUIGlz
IGRpcmVjdGx5IGFwcGxpY2FibGUgdG8gYWxsIG11bHRpY2FzdCBlbmFibGVkIG5ldHcpNzIg
MjcwLjYgUQoob3JrcywgaW5jbHVkaW5nIGFzeW1tZXRyaWMgbmV0dyktLjExIEUob3Jrcywp
LS4xMSBFKHdpcmVsZXNzIG5ldHcpNzIKMjgzLjYgUShvcmtzLCBhbmQgc2F0ZWxsaXRlIG5l
dHcpLS4xMSBFIDIuNzUob3Jrcy4gVGh1cywpLS4xMSBGCih0aGUgaW5oZXJlbnQgcmEpMi43
NSBFIDIuNzUod3MpLS4xNjUgRyhjYWxhYmlsaXR5IG9mIExDVCBpcyB1bmxpbWl0ZWQuKQot
Mi43NSBFKEhvKTcyIDI5Ni42IFEod2UpLS4yNzUgRSAtLjE2NSh2ZSktLjI3NSBHIC44OCAt
LjQ0KHIsIHcpLjE2NSBICihoZW4gb3RoZXIgc3BlY2lcMjE0YyBhcHBsaWNhdGlvbnMgYXJl
IGIpLjQ0IEUodWlsdCBvbiB0b3Agb2YgTENUKS0uMjIgRQoyLjc1KCx0KS0uODE0IEcoaGVu
IHRoZXNlIGFwcGxpY2F0aW9ucyBieSktMi43NSBFKHRoZWlyIHYpNzIgMzA5LjYgUQooZXJ5
IG5hdHVyZSBtYXkgbGltaXQgc2NhbGFiaWxpdHkpLS4xNjUgRSA1LjUoLkYpLS43MTUgRyhv
ciBlKS01LjY2NSBFCih4YW1wbGUsIGlmIGFuIGFwcGxpY2F0aW9uIHJlcXVpcmVzIHJlY2Vp
KS0uMTY1IEUgLS4xNjUodmUpLS4yNzUgRwoocnMgdG8pLjE2NSBFKHJldHJpZSk3MiAzMjIu
NiBRIC4zMyAtLjE2NSh2ZSBvKS0uMjc1IEgodXQgb2YgYmFuZCBpbmZvclwKbWF0aW9uIGlu
IG9yZGVyIHRvIGpvaW4gYSBzZXNzaW9uLCBvciBhbiBhcHBsaWNhdGlvbiBhbGxvKS4xNjUg
RQood3MgcmVjZWkpLS4yNzUgRSAtLjE2NSh2ZSktLjI3NSBHKHJzIHRvKS4xNjUgRQooc2Vu
ZCByZXF1ZXN0cyBiYWNrIHRvIHRoZSBzZW5kZXIgaW4gb3JkZXIgdG8gZSk3MiAzMzUuNiBR
Cih4dGVuZCBhbiBvbmdvaW5nIHNlc3Npb24sIHRoZW4gdGhlIHNjYWxhYmlsaXR5IG9mIHRo
ZSktLjE2NSBFCihhcHBsaWNhdGlvbiBpcyBsaW1pdGVkIGJ5IHRoZSBhYmlsaXR5IHRvIHNl
bmQsIHJlY2VpKTcyIDM0OC42IFEgLS4xNjUKKHZlKS0uMjc1IEcgMi43NSgsYSkuMTY1IEco
bmQgcHJvY2VzcyB0aGlzIGFkZGl0aW9uYWwgZGF0YS4pLTIuNzUgRQooTENUIHJlcXVpcmVz
IHRoYXQgdGhlIHVuZGVybHlpbmcgbmV0dyk3MiAzNzQuNiBRCihvcmsgb3IgdHJhbnNwb3J0
IGxheWVyIGNhbiBkZWxpKS0uMTEgRSAtLjE2NSh2ZSktLjI3NSBHIDIuNzUocmEpLjE2NSBH
CihuZCBkZW11bHRpcGxlKS0yLjc1IEUgMi43NSh4TCktLjE2NSBHKENUKS0yLjc1IEUocGFj
ayk3MiAzODcuNiBRCihldHMgZm9yIGEgZ2kpLS4xMSBFIC0uMTY1KHZlKS0uMjc1IEcgMi43
NShuTCkuMTY1IEcKKENUIHNlc3Npb24sIGFuZCBzdXBwbHkgcGFjayktMi43NSBFCihldCBs
ZW5ndGggaW5mb3JtYXRpb24gdG8gdGhlIExDVCByZWNlaSktLjExIEUgLS4xNjUodmUpLS4y
NzUgRyAxLjIxCi0uNjA1KHIuIEkpLjE2NSBIIDIuNzUobkkpLjYwNSBHKFApLTIuNzUgRShu
ZXR3KTcyIDQwMC42IFEKKG9ya3MsIHRoaXMgaXMgb2Z0ZW4gYWNoaWUpLS4xMSBFIC0uMTY1
KHZlKS0uMjc1IEcgMi43NShkYikuMTY1IEcgMi43NQooeXUpLTIuNzUgRyhzaW5nIFVEUCkt
Mi43NSBFIDIuNzUoLG8pLTEuMjIxIEcgMi43NShyYSktMi43NSBHIC4zMyAtLjE2NQoobnkg
cCktMi43NSBIKHJvdG9jb2wgdGhhdCBjYW4gcHJvKS4xNjUgRSh2aWRlIGFuIGVxdWkpLS4x
NjUgRSAtLjI3NSh2YSkKLS4yNzUgRyhsZW50KS4yNzUgRShzZXJ2aWNlLCBhcyB0aGUgdW5k
ZXJseWluZyB0cmFuc3BvcnQgcHJvdG9jb2wuKTcyCjQxMy42IFEoSW4gdGhpcyBkb2N1bWVu
dCwgd2UgcmVmZXIgdG8gdGhlIG9yaWdpbmFsIG11bHRpY2FzdCBzZXJ2aWNlIG1vXApkZWwg
ZGVcMjE0bmVkIGluIFJGQzExMTIgYXMgQW4pNzIgNDM5LjYgUSh5LSktLjE2NSBFCihTb3Vy
Y2UgTXVsdGljYXN0LCBvciBBU00gZm9yIHNob3J0Lik3MiA0NTIuNiBRIDEuNzYgLS44OChX
ZSByKTUuNSBICihlZmVyIHRvIHRoZSBtdWx0aWNhc3Qgc2VydmljZSBtb2RlbCBkZVwyMTRu
ZWQgaW4gWzVdIGFzKS44OCBFCihTb3VyY2UtU3BlY2lcMjE0YyBNdWx0aWNhc3QsIG9yIFNT
TSBmb3Igc2hvcnQuKTcyIDQ2NS42IFEKKExDVCBkb2VzIG5vdCByZXF1aXJlIHJlKTUuNSBF
IC0uMTY1KHZlKS0uMjc1IEcocnNlIG11bHRpY2FzdCkuMTY1IEUKKGNvbm5lY3RpKTcyIDQ3
OC42IFEodml0eSktLjI3NSBFIDIuNzUoLGkpLS43MTUgRyguZS4gTENUIHJlY2VpKS0yLjc1
IEUKLS4xNjUodmUpLS4yNzUgRyhycyBkbyBub3Qgc2VuZCBtdWx0aWNhc3QgdHJhZikuMTY1
IEUgMi43NShcMjE0Yy4gQXMpCi0uMjc1IEYoc3VjaCwgTENUIHcpMi43NSBFKG9ya3Mgd2l0
aCBib3RoKS0uMTEgRShBU00gYW5kIFNTTS4pNzIgNDkxLjYgUQooVGhlIGRlXDIxNG5pdGlv
biBvZiBhbiBMQ1QgY2hhbm5lbCB1c2VkIHRocm91Z2hvdXQgdGhpcyBkb2N1bWVudCBpcyBz
bFwKaWdodGx5IGRpZik3MiA1MTcuNiBRKGZlcmVudCB3aXRoIEFTTSktLjI3NSBFKGFuZCB3
aXRoIFNTTS4pNzIgNTMwLjYgUQooV2hlbiB1c2luZyBBU00sIGEgc2VuZGVyIFMgc2VuZHMg
TENUIHBhY2spNS41IEUKKGV0cyB0byBhIG11bHRpY2FzdCBncm91cCBHLCBhbmQgdGhlKS0u
MTEgRShMQ1QgY2hhbm5lbCBhZGRyZXNzIGNvbnNpc3RcCnMgb2YgdGhlIHBhaXIgXChTLEdc
KSwgd2hlcmUgUyBpcyB0aGUgSVAgYWRkcmVzcyBvZiB0aGUgc2VuZGVyIGFuZCBHIGlzXAog
YSk3MiA1NDMuNiBRKG11bHRpY2FzdCBncm91cCBhZGRyZXNzLik3MiA1NTYuNiBRCihXaGVu
IHVzaW5nIFNTTSwgYSBzZW5kZXIgUyBzZW5kcyBMQ1QgcGFjayk1LjUgRShldHMgdG8gYW4g
U1NNIGNoYW5uZWwpCi0uMTEgRShcKFMsR1wpLCBhbmQgdGhlIExDVCBjaGFubmVsIGFkZHJl
c3MgY29pbmNpZGVzIHdpdGggdGhlIFNTTSBjaGFuXApuZWwgYWRkcmVzcy4pNzIgNTY5LjYg
UShTU00gaXMgbW9yZSBhdHRyYWN0aSk3MiA1OTUuNiBRIC4zMyAtLjE2NSh2ZSB0KQotLjI3
NSBIIDIuNzUob2QpLjE2NSBHKGVwbG8pLTIuNzUgRSh5bWVudCBvZiBMQ1QgdGhhbiBBU00g
Zm9yIHNlKS0uMTEgRQotLjE2NSh2ZSktLjI3NSBHKHJhbCByZWFzb25zLikuMTY1IEUoRmly
c3QsIGEgc2VuZGVyIG1heSk1LjUgRQooYWxsb2NhdGUgYW5kIHVzZSBzZSk3MiA2MDguNiBR
IC0uMTY1KHZlKS0uMjc1IEcKKHJhbCBMQ1QgY2hhbm5lbHMgaW4gYSBzZXNzaW9uLCBzZXNz
aW9ucyBtYXkgY29tZSBhbmQgZ28gZHluYW1pY2FsbHkpCi4xNjUgRSAyLjc1KC5BKS0uNzE1
IEcKKHNlbmRlciBjYW4gbG9jYWxseSBhbGxvY2F0ZSB1bmlxdWUgU1NNIGNoYW5uZWwgYWRk
cmVzc2VzLCBhbmQgdGhpcyBtYWspCjcyIDYyMS42IFEoZXMgYWxsb2NhdGlvbiBvZiBMQ1Qp
LS4xMSBFKGNoYW5uZWwgYWRkcmVzc2VzIGVhc3kgd2l0aCBTU00uKQo3MiA2MzQuNiBRIDEu
NzYgLS44OChUbyBhKTUuNSBICihsbG9jYXRlIExDVCBjaGFubmVsIGFkZHJlc3NlcyB1c2lu
ZyBBU00sIHRoZSBzZW5kZXIpLjg4IEUobXVzdCB1bmlxdWVsXAp5IGNob3NlIHRoZSBBU00g
bXVsdGljYXN0IGdyb3VwIGFkZHJlc3MgYWNyb3NzIHRoZSBzY29wZSBvZiB0aGUgZ3JvdXAs
IFwKYW5kIHRoaXMpNzIgNjQ3LjYgUShtYWspNzIgNjYwLjYgUQooZXMgYWxsb2NhdGlvbiBv
ZiBMQ1QgY2hhbm5lbCBhZGRyZXNzZXMgbW9yZSBkaWYpLS4xMSBFCihcMjE0Y3VsdCB3aXRo
IEFTTS4pLS4yNzUgRShJbiBnZW5lcmFsIFNTTSBwZXJmb3JtcyB3ZWxsIGUpNzIgNjg2LjYg
UQotLjE2NSh2ZSktLjI3NSBHIDIuNzUobmkpLjE2NSBHIDIuNzUobnApLTIuNzUgRyhyZXNl
bmNlIG9mIHYpLTIuNzUgRQooZXJ5IGxhciktLjE2NSBFKGdlIGFuZCBkeW5hbWljYWxseSBj
aGFuZ2luZyByZWNlaSktLjE5OCBFIC0uMTY1KHZlKQotLjI3NSBHKHIpLjE2NSBFIDIuNzUo
c2V0cy4gQ2hhbmdlcyk3MiA2OTkuNiBSKGluIHRoZSBtdWx0aWNhc3QgdHJlZSB0b1wKcG9s
b2d5IHdpdGggU1NNIGFyZSBsaWdodCB3ZWlnaHQgb3BlcmF0aW9ucyBcKGEgbmUpMi43NSBF
IDIuNzUod2IpLS4yNzUKRyhyYW5jaCktMi43NSBFKGZyb20gdGhlIHJlY2VpKTcyIDcxMi42
IFEgLS4xNjUodmUpLS4yNzUgRyAyLjc1KHJ0KS4xNjUKRyAtMi4zMSAtLjI3NShvdyBhKS0y
Ljc1IEgocmRzIFMgZ3JvKS4yNzUgRSh3cyB3aGVuIGEgcmVjZWkpLS4yNzUgRQotLjE2NSh2
ZSktLjI3NSBHIDIuNzUocmopLjE2NSBHCihvaW5zLCBhbmQgdGhlIGJyYW5jaCBpcyBkZWxl
dGVkIHdoZW4gdGhlKS0yLjc1IEUocmVjZWkpNzIgNzI1LjYgUSAtLjE2NQoodmUpLS4yNzUg
RyAyLjc1KHJsKS4xNjUgRyhlYSktMi43NSBFIC0uMTY1KHZlKS0uMjIgRwooc1wpLCB3aGVy
ZWFzIHdpdGggQVNNIGNoYW5nZXMgY2FuIGJlIGhlYSkuMTY1IEUodmllciB3ZWlnaHQgXChp
biktLjIyIEUKLS4yMih2byktLjQ0IEcobHZpbmcgdHJhbnNpdGlvbnMgZnJvbSBhKS4yMiBF
KEx1YnkvR2VtbWVsbC9WKTcyIDc2OSBRCihpY2lzYW5vL1JpenpvL0hhbmRsZSktLjY2IEUo
eS9Dcm8pLS4xNjUgRSAxMDkuMTA2KHdjcm9mdCBTZWN0aW9uKS0uMjc1CkYgMi43NSgxLjIu
IFtQKTIuNzUgRihhZ2UgNV0pLS4xNjUgRSBFUAolJVBhZ2U6IDYgNgolJUJlZ2luUGFnZVNl
dHVwCkJQCiUlRW5kUGFnZVNldHVwCi9GMCAxMS9UaW1lcy1Sb21hbkAwIFNGKElOVEVSTkVU
KTcyIDQ5IFEgNzEuNTg3KC1EUkFGVCBFeHBpcmVzOiktMS4wMTIgRgooSmFudWFyeSAyMDAy
KTIuNzUgRShKdWx5IDIwMDEpMTIzLjcyNiBFCihcKCosR1wpLXRyZWUgcm9vdGVkIGF0IGFu
IFJQIHRvIHRoZSB0cmVlIHJvb3RlZCBhdCBTXCkuKTcyIDg1IFEKKFRoaXMgZWYpNS41IEUo
XDIxNGNpZW5jKS0uMjc1IEUgMi43NSh5aSktLjE2NSBHIDIuNzUoc2kpLTIuNzUgRwoobXBv
cnRhbnQgd2hlbiBhIGNvbmdlc3Rpb24pLTIuNzUgRQooY29udHJvbCBwcm90b2NvbCBpcyB1
c2VkIHdpdGggTENUIHRoYXQgcmVsaWVzIHVwb24gam9pbmluZyBhbmQgbGVhKTcyCjk4IFEo
dmluZyBjaGFubmVscyB0byBuaW1ibHkpLS4yMiBFCihpbmNyZWFzZSBhbmQgZGVjcmVhc2Ug
cmVjZXB0aW9uIHJhdGUuKTcyIDExMSBRCihMQ1QgY2hhbm5lbHMgYW5kIFNTTSBjaGFubmVs
cyBjb2luY2lkZSwgYW5kIHRodXMgdGhlIHJlY2VpKTcyIDEzNyBRCi0uMTY1KHZlKS0uMjc1
IEcgMi43NShydykuMTY1IEcoaWxsIG9ubHkgcmVjZWkpLTIuNzUgRSAuMzMgLS4xNjUodmUg
cCkKLS4yNzUgSChhY2spLjE2NSBFKGV0cyBzZW50IHRvKS0uMTEgRSh0aGUgcmVxdWVzdGVk
IExDVCBjaGFubmVsLik3MiAxNTAKUSAtLjQ0KFdpKTUuNSBHKHRoIEFTTSwgdGhlIHJlY2Vp
KS40NCBFIC0uMTY1KHZlKS0uMjc1IEcgMi43NShyaikuMTY1IEcKKG9pbnMgYW4gTENUIGNo
YW5uZWwgYnkgam9pbmluZyBhIG11bHRpY2FzdCktMi43NSBFCihncm91cCBHLCBhbmQgYWxs
IHBhY2spNzIgMTYzIFEoZXRzIHNlbnQgdG8gRywgcmUpLS4xMSBFIC0uMDU1KGdhKS0uMTY1
CkcocmRsZXNzIG9mIHRoZSBzZW5kZXIpLjA1NSBFIDIuNzUoLG0pLS40NCBHKGF5IGJlIHJl
Y2VpKS0yLjc1IEUgLS4xNjUKKHZlKS0uMjc1IEcgMi43NShkYikuMTY1IEcgMi43NSh5dCkt
Mi43NSBHKGhlIHJlY2VpKS0yLjc1IEUgLS4xNjUodmUpCi0uMjc1IEcgMy45NiAtLjYwNShy
LiBJKS4xNjUgSChuKS42MDUgRShlaXRoZXIgY2FzZSwgcmVjZWkpNzIgMTc2IFEKLS4xNjUo
dmUpLS4yNzUgRyhycyBzaG91bGQgdXNlIG1lY2hhbmlzbXMgdG8gXDIxNGx0ZXIgb3V0IHBh
Y2spLjE2NSBFCihldHMgZnJvbSB1bncpLS4xMSBFKGFudGVkIHNvdXJjZXMuKS0uMTEgRShU
aHVzLCk1LjUgRQooU1NNIGhhcyBjb21wZWxsaW5nIHNlY3VyaXR5IGFkdik3MiAxODkgUShh
bnRhZ2VzIG8pLS4yNzUgRSAtLjE2NSh2ZSkKLS4xNjUgRyAyLjc1KHJBKS4xNjUgRyhTTSBm
b3IgcHJlKS0yLjc1IEUgLS4xNjUodmUpLS4yNzUgRwoobnRpb24gb2YgZGVuaWFsIG9mIHNl
cnZpY2UgYXR0YWNrcy4pLjE2NSBFKExDVCBhbHNvIHJlcXVpcmVzIHJlY2VpKTcyCjIxNSBR
IC0uMTY1KHZlKS0uMjc1IEcocnMgdG8gb2J0YWluIFNlc3Npb24gRGVzY3JpcHRpb24gSW5m
b3JtYXRpb24gYmVmXApvcmUgam9pbmluZyBhIHNlc3Npb24sIGFzKS4xNjUgRShkZXNjcmli
ZWQgaW4gU2VjdGlvbiA0LjEuKTcyIDIyOCBRCihUaGUgc2Vzc2lvbiBkZXNjcmlwdGlvbiBj
b3VsZCBiZSBpbiBhIGZvcm0gc3VjaCBhcyBTRFAgYXMgZGVcMjE0bmVkIGluKQo1LjUgRShS
RkMyMzI3LCBvciBYTUwgbWV0YWRhdGEsIG9yIEhUVFAvTWltZSBoZWFkZXJzIGFzIGRlXDIx
NG5lZCBpbiBSRlwKQzIwNjgsIGFuZCBkaXN0cmliKTcyIDI0MSBRKHV0ZWQpLS4yMiBFCih3
aXRoIFNBUCBbNF0sIHVzaW5nIFJDQ1AgWzhdLCBIVFRQKTcyIDI1NCBRIDIuNzUoLG8pLTEu
MjIxIEcgMi43NShyaSkKLTIuNzUgRyAyLjc1KG5vKS0yLjc1IEcodGhlciB3KS0yLjc1IEUo
YXlzLiktLjExIEUoVGhlIHBhcnRpY3VsYXIgbGF5ZXJcCmVkIGVuY29kZXIgYW5kIGNvbmdl
c3Rpb24gY29udHJvbCBwcm90b2NvbHMgdXNlZCB3aXRoIExDVCBoYSk3MiAyODAgUQouMzMg
LS4xNjUodmUgYSktLjIyIEggMi43NShuaSkuMTY1IEcobXBhY3QpLTIuNzUgRQoob24gdGhl
IHBlcmZvcm1hbmNlIGFuZCBhcHBsaWNhYmlsaXR5IG9mIExDVCk3MiAyOTMgUSA1LjUoLkYp
LS44MTQgRwoob3IgZSktNS42NjUgRSh4YW1wbGUsIHNvbWUgbGF5ZXJlZCBlbmNvZGVycyB1
c2VkIGZvciB2aWRlbyktLjE2NSBFCihhbmQgYXVkaW8gc3RyZWFtcyBjYW4gcHJvZHVjZSBh
IHYpNzIgMzA2IFEKKGVyeSBsaW1pdGVkIG51bWJlciBvZiBzdWJzdHJlYW1zLCB0aHVzIHBy
byktLjE2NSBFKHZpZGluZyBhIHYpLS4xNjUgRQooZXJ5IGNvYXJzZSktLjE2NSBFKGNvbnRy
b2wgaW4gdGhlIHJlY2VwdGlvbiByYXRlIG9mIHBhY2spNzIgMzE5IFEKKGV0cyBieSByZWNl
aSktLjExIEUgLS4xNjUodmUpLS4yNzUgRyhycyBpbiBhIHNlc3Npb24uKS4xNjUgRQooV2hl
biBMQ1QgaXMgdXNlZCBmb3IgcmVsaWFibGUpNS41IEUoZGF0YSB0cmFuc2Zlcik3MiAzMzIg
USAyLjc1KCxzKS0uNDQKRyhvbWUgRkVDIGNvZGVjcyBhcmUgaW5oZXJlbnRseSBsaW1pdGVk
IGluIHRoZSBzaXplIG9mIHRoZSBvYmplY3QgdGhlKQotMi43NSBFIDIuNzUoeWMpLS4xNjUg
RyhhbiBlbmNvZGUsKS0yLjc1IEUoYW5kIGZvciBvYmplY3RzIGxhcik3MiAzNDUgUQooZ2Vy
IHRoYW4gdGhpcyBzaXplIHRoZSByZWNlcHRpb24gbyktLjE5OCBFIC0uMTY1KHZlKS0uMTY1
IEcKKHJoZWFkIG9uIHRoZSByZWNlaSkuMTY1IEUgLS4xNjUodmUpLS4yNzUgRyhycyBjYW4g
Z3JvKS4xNjUgRSAyLjc1KHdzKQotLjI3NSBHKHVic3RhbnRpYWxseSktMi43NSBFKC4pLS43
MTUgRShBcyBhbm90aGVyIGUpNzIgMzcxIFEKKHhhbXBsZSwgc29tZSBuZXR3KS0uMTY1IEUK
KG9ya3MgYXJlIG5vdCBhbWVuYWJsZSB0byBzb21lIGNvbmdlc3Rpb24gY29udHJvbCBwcm90
b2NvbHMgdGhhdCktLjExIEUKKGNvdWxkIGJlIHVzZWQgd2l0aCBMQ1QpNzIgMzg0IFEgNS41
KC5JKS0uODE0IEcgMi43NShucCktNS41IEcKKGFydGljdWxhciktMi43NSBFIDIuNzUoLGYp
LS40NCBHKG9yIGEgc2F0ZWxsaXRlIG9yIHdpcmVsZXNzIG5ldHcpLTIuNzUKRShvcmssIHRo
ZXJlIG1heSBiZSBubyktLjExIEUobWVjaGFuaXNtIGZvciByZWNlaSk3MiAzOTcgUSAtLjE2
NSh2ZSkKLS4yNzUgRyhycyB0byBlZikuMTY1IEUoZmVjdGkpLS4yNzUgRSAtLjE2NSh2ZSkt
LjI3NSBHCihseSByZWR1Y2UgdGhlaXIgcmVjZXB0aW9uIHJhdGUgc2luY2UgdGhlcmUgbWF5
IGJlIGEgXDIxNHgpLjE2NSBFKGVkKQotLjE2NSBFKHRyYW5zbWlzc2lvbiByYXRlIGFsbG9j
YXRlZCB0byB0aGUgc2Vzc2lvbi4pNzIgNDEwIFEvRjEgMTEKL1RpbWVzLUJvbGRAMCBTRigy
Lik3MiA0NDkgUS9GMiAxNC9UaW1lcy1Cb2xkQDAgU0YoR2VuZXJhbCBBcik1LjUgRQooY2hp
dGVjdHVyKS0uMjUyIEUoZSktLjI1MiBFIEYwKEFuIExDVCBzZXNzaW9uIGNvbXByaXNlcyBh
bGwgTENUIHBhY2spNzIKNDY1LjYgUShldHMgc2VudCB0byBvbmUgb3IgbW9yZSBMQ1QgY2hh
bm5lbHMgZnJvbSBhIHNpbmdsZSktLjExIEUKKHNlbmRlcik3MiA0NzguNiBRIDIuNzUoLGEp
LS40NCBHKG5kIHBlcnRhaW5pbmcgdG8gdGhlIHRyYW5zbWlzc2lvbiBvZiBcCm9uZSBvciBt
b3JlIG9iamVjdHMgdGhhdCBjYW4gYmUgb2YgaW50ZXJlc3QgZm9yIHRoZSktMi43NSBFKHJl
Y2VpKTcyCjQ5MS42IFEgLS4xNjUodmUpLS4yNzUgRyhycy4pLjE2NSBFIC0uMTY1KEZvKTcy
IDUxNy42IFMgMi43NShyZSkuMTY1IEcKKHhhbXBsZSwgYW4gTENUIHNlc3Npb24gY291bGQg
YmUgdXNlZCB0byBkZWxpKS0yLjkxNSBFIC0uMTY1KHZlKS0uMjc1IEcKMi43NShyYVQpLjE2
NSBHIDIuNzUoVmMpLTIuNzUgRyhoYW5uZWwgdXNpbmcgdGhyZWUgY2hhbm5lbHMuKS0yLjc1
IEUKKFJlY2VpKTcyIDUzMC42IFEodmluZyB0aGUgXDIxNHJzdCBjaGFubmVsIGNvdWxkIGFs
bG8pLS4yNzUgRSAyLjc1KHdiKQotLjI3NSBHKGxhY2sgYW5kIHdoaXRlIHJlY2VwdGlvbiwg
cmVjZWkpLTIuNzUgRSh2aW5nIHRoZSBcMjE0cnN0IHR3KQotLjI3NSBFIDIuNzUob2MpLS4x
MSBHKGhhbm5lbHMpLTIuNzUgRSAtLjExKHdvKTcyIDU0My42IFMKKHVsZCBwZXJtaXQgY29s
b3IgcmVjZXB0aW9uLCB3aGVyZWFzIHJlY2VpKS4xMSBFCih2aW5nIHRoZSBzZXQgb2YgdGhy
ZWUgY2hhbm5lbHMgZGVsaSktLjI3NSBFIC0uMTY1KHZlKS0uMjc1IEcKKHJzIEhEVFYgcXVh
bGl0eSkuMTY1IEUgMi43NShpbWFnZXMuIE9iamVjdHMpNzIgNTU2LjYgUihpbiB0aGlzIGUp
Mi43NSBFCih4YW1wbGUgY291bGQgY29ycmVzcG9uZCB0byBpbmRpKS0uMTY1IEUodmlkdWFs
IHByb2dyYW1zIFwobW8pLS4yNzUgRQoodmllcywgbmUpLS4xNjUgRSh3cywpLS4yNzUgRShj
b21tZXJjaWFsXCkgYmVpbmcgdHJhbnNtaXR0ZWQuKTcyIDU2OS42IFEKKEFzIGFub3RoZXIg
ZSk3MiA1OTUuNiBRCih4YW1wbGUsIGEgcmVsaWFibGUgTENUIHNlc3Npb24gY291bGQgYmUg
dXNlZCB0byByZWxpYWJseSBkZWxpKS0uMTY1IEUKLS4xNjUodmUpLS4yNzUgRyAyLjc1KHJo
KS4xNjUgRyhvdXJseS11cGRhdGVkKS0yLjc1IEUKKHdlYXRoZXIgbWFwcyBcKG9iamVjdHNc
KSB1c2luZyB0ZW4gTENUIGNoYW5uZWxzIGF0IGRpZik3MiA2MDguNiBRCihmZXJlbnQgcmF0
ZXMsIHVzaW5nIEZFQyBjb2RpbmcuKS0uMjc1IEUgMi43NShBcik1LjUgRyhlY2VpKS0yLjc1
IEUKLS4xNjUodmUpLS4yNzUgRyhyKS4xNjUgRShNQSk3MiA2MjEuNiBRIDIuNzUoWWopLTEu
MTU1IEcKKG9pbiBhbmQgY29uY3VycmVudGx5IHJlY2VpKS0yLjc1IEUgLjMzIC0uMTY1KHZl
IEwpLS4yNzUgSChDVCBwYWNrKS4xNjUKRShldHMgZnJvbSBzdWJzZXRzIG9mIHRoZXNlIGNo
YW5uZWxzLCB1bnRpbCBpdCBoYXMpLS4xMSBFKGVub3VnaCBwYWNrKTcyCjYzNC42IFEoZXRz
IGluIHRvdGFsIHRvIHJlY28pLS4xMSBFIC0uMTY1KHZlKS0uMTY1IEcgMi43NShydCkuMTY1
IEcKKGhlIG9iamVjdCwgdGhlbiBsZWEpLTIuNzUgRSAuMzMgLS4xNjUodmUgdCktLjIyIEgK
KGhlIHNlc3Npb24gXChvciByZW1haW4gdGhlcmUgbGlzdGVuaW5nIHRvKS4xNjUgRQooY29u
dHJvbCBpbmZvcm1hdGlvbiBvbmx5XCkgdW50aWwgaXQgaXMgdGltZSB0byByZWNlaSk3MiA2
NDcuNiBRIC4zMwotLjE2NSh2ZSB0KS0uMjc1IEgoaGUgbmUpLjE2NSBFKHh0IG9iamVjdC4p
LS4xNjUgRQooSW4gdGhpcyBjYXNlLCB0aGUgcXVhbGl0eSBtZXRyaWMpNS41IEUoaXMgdGhl
IHRpbWUgcmVxdWlyZWQgdG8gcmVjZWkpNzIKNjYwLjYgUSAuMzMgLS4xNjUodmUgZSktLjI3
NSBIKGFjaCBvYmplY3QuKS4xNjUgRQooQmVmb3JlIGpvaW5pbmcgYSBzZXNzaW9uLCB0aGUg
cmVjZWkpNzIgNjg2LjYgUSAtLjE2NSh2ZSktLjI3NSBHCihycyBNVVNUIG9idGFpbiBhIHNl
c3Npb24gZGVzY3JpcHRpb24sIHdoaWNoIE1VU1QgaW5jbHVkZSkuMTY1IEUKKHRoZSByZWxl
KTcyIDY5OS42IFEgLS4yNzUodmEpLS4yNzUgRwoobnQgc2Vzc2lvbiBwYXJhbWV0ZXJzIG5l
ZWRlZCBieSBhIHJlY2VpKS4yNzUgRSAtLjE2NSh2ZSktLjI3NSBHIDIuNzUKKHJ0KS4xNjUg
RyAyLjc1KG9wKS0yLjc1IEcoYXJ0aWNpcGF0ZSBpbiB0aGUgc2Vzc2lvbi4pLTIuNzUgRQoo
VGhlIHNlc3Npb24pNS41IEUoZGVzY3JpcHRpb24gaXMgZGV0ZXJtaW5lZCBhbmQgYWdyZWVk
IHVwb24gYnkgdGhlIHNlblwKZGVycywgYW5kIHR5cGljYWxseSBjb21tdW5pY2F0ZWQgdG8g
dGhlKTcyIDcxMi42IFEocmVjZWkpNzIgNzI1LjYgUQotLjE2NSh2ZSktLjI3NSBHCihycyBv
dXQgb2YgYmFuZC4gSW4gc29tZSBjYXNlcywgcGFydCBvZiB0aGUgc2Vzc2lvbiBkZXNjcmlw
dGlvbiBNQSkuMTY1CkUgMi43NShZYiktMS4xNTUgRyAyLjc1KGVpKS0yLjc1IEcobmNsdWRl
ZCBpbiB0aGUgTENUKS0yLjc1IEUKKEx1YnkvR2VtbWVsbC9WKTcyIDc2OSBRKGljaXNhbm8v
Uml6em8vSGFuZGxlKS0uNjYgRSh5L0NybyktLjE2NSBFCjExNy4zNTYod2Nyb2Z0IFNlY3Rp
b24pLS4yNzUgRiAyLjc1KDIuIFtQKTIuNzUgRihhZ2UgNl0pLS4xNjUgRSBFUAolJVBhZ2U6
IDcgNwolJUJlZ2luUGFnZVNldHVwCkJQCiUlRW5kUGFnZVNldHVwCi9GMCAxMS9UaW1lcy1S
b21hbkAwIFNGKElOVEVSTkVUKTcyIDQ5IFEgNzEuNTg3KC1EUkFGVCBFeHBpcmVzOiktMS4w
MTIgRgooSmFudWFyeSAyMDAyKTIuNzUgRShKdWx5IDIwMDEpMTIzLjcyNiBFKHBhY2spNzIg
ODUgUShldC4pLS4xMSBFCihBbiBlbmNvZGVyIE1BKTcyIDExMSBRIDIuNzUoWWIpLTEuMTU1
IEcgMi43NShldSktMi43NSBHCihzZWQgdG8gZ2VuZXJhdGUgdGhlIGRhdGEgdGhhdCBpcyBw
bGFjZWQgaW4gdGhlIExDVCBwYWNrKS0yLjc1IEUKKGV0IHBheWxvYWQgaW4gb3JkZXIpLS4x
MSBFKHRvIHBybyk3MiAxMjQgUSh2aWRlIHJlbGlhYmlsaXR5KS0uMTY1IEUgNS41CiguQSkt
LjcxNSBHKHN1aXRhYmxlIGRlY29kZXIgaXMgdXNlZCB0byByZXByb2R1Y2UgdGhlIG9yaWdp
bmFsIGluZm9ybWF0XAppb24gZnJvbSB0aGUpLTIuNzUgRSAyLjc1KHBheWxvYWQuIFRoZXJl
KTcyIDEzNyBSKE1BKTIuNzUgRSAyLjc1KFliKQotMS4xNTUgRyAyLjc1KGVhciktMi43NSBH
KGVsaWFiaWxpdHkgcGFjayktMi43NSBFKGV0IGhlYWRlciB0aGF0IGZvbGxvKQotLjExIEUo
d3MgdGhlIExDVCBwYWNrKS0uMjc1IEUoZXQgaGVhZGVyIGlmIHN1Y2ggYW4pLS4xMSBFCihl
bmNvZGVyIGFuZCBkZWNvZGVyIGlzIHVzZWQuKTcyIDE1MCBRKFRoZSByZWxpYWJpbGl0eSBw
YWNrKTUuNSBFCihldCBoZWFkZXIgaGVscHMgdG8gZGVzY3JpYmUgdGhlIGVuY29kaW5nIGRh
dGEpLS4xMSBFCihjYXJyaWVkIGluIHRoZSBwYXlsb2FkIG9mIHRoZSBwYWNrKTcyIDE2MyBR
IDIuNzUoZXQuIFRoZSktLjExIEYKKGZvcm1hdCBvZiB0aGUgcmVsaWFiaWxpdHkgcGFjayky
Ljc1IEUoZXQgaGVhZGVyIGRlcGVuZHMgb24gdGhlKS0uMTEgRQooY29kaW5nIHVzZWQsIGFu
ZCB0aGlzIGlzIG5lKTcyIDE3NiBRKGdvdGlhdGVkIG91dC1vZi1iYW5kLiktLjE2NSBFCihB
cyBhbiBlKTUuNSBFKHhhbXBsZSwgb25lIG9mIHRoZSBGRUMgcGFjayktLjE2NSBFKGV0IGhl
YWRlcnMpLS4xMSBFCihkZXNjcmliZWQgaW4gWzddIGNvdWxkIGJlIHVzZWQuKTcyIDE4OSBR
IC0uMTY1KEZvKTcyIDIxNSBTIDIuNzUockwpLjE2NQpHKENUKS0yLjc1IEUgMi43NSgsdykt
LjgxNCBHCihoZW4gbGF5ZXJlZCBjb25nZXN0aW9uIGNvbnRyb2wgaXMgdXNlZCwgY29uZ2Vz
dGlvbiBjb250cm9sIGlzIGFjaGllKQotMi43NSBFIC0uMTY1KHZlKS0uMjc1IEcgMi43NShk
YikuMTY1IEcgMi43NSh5cyktMi43NSBHKGVuZGluZyktMi43NSBFCihMQ1QgcGFjayk3MiAy
MjggUShldHMgYXNzb2NpYXRlZCB3aXRoIGEgZ2kpLS4xMSBFIC0uMTY1KHZlKS0uMjc1IEcg
Mi43NQoobnMpLjE2NSBHKGVzc2lvbiB0byBzZSktMi43NSBFIC0uMTY1KHZlKS0uMjc1IEco
cmFsIExDVCBjaGFubmVscy4pLjE2NQpFKEluZGkpNS41IEUodmlkdWFsIHJlY2VpKS0uMjc1
IEUgLS4xNjUodmUpLS4yNzUgRyhycykuMTY1IEUKKGR5bmFtaWNhbGx5IGpvaW4gb25lIG9y
IG1vcmUgb2YgdGhlc2UgY2hhbm5lbHMsIGFjY29yZGluZyB0byB0aGUgbmV0dykKNzIgMjQx
IFEob3JrIGNvbmdlc3Rpb24gYXMgc2VlbiBieSktLjExIEUodGhlIHJlY2VpKTcyIDI1NCBR
IC0uMTY1KHZlKQotLjI3NSBHIDMuOTYgLS42MDUoci4gTCkuMTY1IEgoQ1QgcGFjaykuNjA1
IEUKKGV0IGhlYWRlcnMgaW5jbHVkZSBhbiBvcGFxdWUgXDIxNGVsZCB3aGljaCBNVVNUIGJl
IHVzZWQgdG8gY29uKS0uMTEgRQotLjE2NSh2ZXkpLS40NCBHKGNvbmdlc3Rpb24gY29udHJv
bCBpbmZvcm1hdGlvbiB0byB0aGUgcmVjZWkpNzIgMjY3IFEKLS4xNjUodmUpLS4yNzUgRyAy
Ljc1KHJzLiBUaGUpLjE2NSBGCihhY3R1YWwgY29uZ2VzdGlvbiBjb250cm9sIHNjaGVtZSB0
byB1c2Ugd2l0aCkyLjc1IEUoTENUIGlzIG5lKTcyIDI4MCBRCihnb3RpYXRlZCBvdXQtb2Yt
YmFuZC4pLS4xNjUgRShTb21lIGUpNS41IEUKKHhhbXBsZXMgb2YgY29uZ2VzdGlvbiBjb250
cm9sIHByb3RvY29scyB0aGF0IE1BKS0uMTY1IEUgMi43NShZYiktMS4xNTUKRyhlKS0yLjc1
IEUoc3VpdGFibGUgZm9yIGNvbnRlbnQgZGVsaSk3MiAyOTMgUSAtLjE2NSh2ZSktLjI3NSBH
CihyeSBhcmUgZGVzY3JpYmVkIGluIFs5XS4gT3RoZXIgY29uZ2VzdGlvbiBjb250cm9scyBN
QSkuMTY1IEUgMi43NShZYikKLTEuMTU1IEcgMi43NShlcyktMi43NSBHKHVpdGFibGUpLTIu
NzUgRQood2hlbiBMQ1QgaXMgdXNlZCBmb3IgYSBzdHJlYW1pbmcgYXBwbGljYXRpb24uKTcy
IDMwNiBRKExDVCBjYW4gYmUgdXNlZFwKIHdpdGggb3RoZXIgY29uZ2VzdGlvbiBjb250cm9s
IHByb3RvY29scyBzdWNoIGFzIHRoZSBvbmUgZGVzY3JpYmVkIGluIFtcCjE0XSwgb3IpNzIg
MzMyIFEocm91dGVyKTcyIDM0NSBRCigtYXNzaXN0ZWQgc2NoZW1lcyB3aGVyZSB0aGUgc2Vs
ZWN0aW9uIG9mIHdoaWNoIHBhY2spLS4yMiBFKGV0cyB0byBmb3J3KQotLjExIEUoYXJkIGlz
IHBlcmZvcm1lZCBieSByb3V0ZXJzLiktLjExIEUKKFRoaXMgbGF0dGVyIGFwcHJvYWNoIHBv
dGVudGlhbGx5IGFsbG8pNzIgMzU4IFEKKHdzIGZvciBcMjE0bmVyIGdyYWluIGNvbmdlc3Rp
b24gY29udHJvbCBhbmQgYSBmKS0uMjc1IEUKKGFzdGVyIHJlYWN0aW9uIHRvKS0uMTEgRShu
ZXR3KTcyIDM3MSBRKG9yayBjb25nZXN0aW9uLCBiKS0uMTEgRQoodXQgcmVxdWlyZXMgY2hh
bmdlcyB0byB0aGUgcm91dGVyIGluZnJhc3RydWN0dXJlLiktLjIyIEUKKFNlZSBbMl0gZm9y
IGEgcHJlbGltaW5hcnkpNS41IEUoZGVzaWduIGRlc2NyaXB0aW9uLik3MiAzODQgUSAxLjc2
IC0uODgKKFdlIGQpNS41IEggMi43NShvbikuODggRwoob3QgZGlzY3VzcyB0aGlzIGFwcHJv
YWNoIGZ1cnRoZXIgaW4gdGhpcyBkb2N1bWVudC4pLTIuNzUgRS9GMSAxMQovVGltZXMtQm9s
ZEAwIFNGKDIuMS4pNzIgNDIzIFEvRjIgMTMvVGltZXMtQm9sZEAwIFNGKERlbGkpNS41IEUg
LS4xMyh2ZSkKLS4xMyBHKHJ5IHNlcikuMTMgRSh2aWNlIG1vZGVscyktLjEzIEUgRjAoTENU
IGNhbiBzdXBwb3J0IHNlKTcyIDQzOS42IFEKLS4xNjUodmUpLS4yNzUgRyhyYWwgZGlmKS4x
NjUgRShmZXJlbnQgZGVsaSktLjI3NSBFIC0uMTY1KHZlKS0uMjc1IEcKKHJ5IHNlcnZpY2Ug
bW9kZWxzLiBUKS4xNjUgRSAuMjIgLS4xMSh3byBlKS0uODggSAooeGFtcGxlcyBhcmUgYnJp
ZVwyMTV5IGRlc2NyaWJlZCktLjA1NSBFKGhlcmUuKTcyIDQ1Mi42IFEgRjEoUHVzaCBzZXIp
NzIKNDkxLjYgUSh2aWNlIG1vZGVsLiktLjExIEUgRjAoT25lIHcpNzIgNTA4LjIgUQooYXkg
YSBwdXNoIHNlcnZpY2UgbW9kZWwgY2FuIGJlIHVzZWQgZm9yIHJlbGlhYmxlIGNvbnRlbnQg
ZGVsaSktLjExIEUKLS4xNjUodmUpLS4yNzUgRyhyeSBpcyB0byBkZWxpKS4xNjUgRSAtLjE2
NSh2ZSktLjI3NSBHIDIuNzUocmFzKS4xNjUgRwooZXJpZXMgb2YpLTIuNzUgRSAyLjc1KG9i
amVjdHMuIEYpNzIgNTIxLjIgUihvciBlKS0uMTY1IEUKKHhhbXBsZSwgYSByZWNlaSktLjE2
NSBFIC0uMTY1KHZlKS0uMjc1IEcgMi43NShyYykuMTY1IEcKKG91bGQgam9pbiB0aGUgc2Vz
c2lvbiBhbmQgZHluYW1pY2FsbHkgYWRhcHQgdGhlIG51bWJlciBvZiBMQ1QpLTIuNzUgRQoo
Y2hhbm5lbHMgdGhlIHJlY2VpKTcyIDUzNC4yIFEgLS4xNjUodmUpLS4yNzUgRyAyLjc1KHJp
KS4xNjUgRyAyLjc1KHNqKQotMi43NSBHKG9pbmVkIHRvIHVudGlsIGVub3VnaCBwYWNrKS0y
Ljc1IEUoZXRzIGhhKS0uMTEgRSAuMzMgLS4xNjUodmUgYikKLS4yMiBIKGVlbiByZWNlaSku
MTY1IEUgLS4xNjUodmUpLS4yNzUgRyAyLjc1KGR0KS4xNjUgRyAyLjc1KG9yKS0yLjc1IEcK
KGVjb25zdHJ1Y3QgYW4pLTIuNzUgRQoob2JqZWN0LiBBZnRlciByZWNvbnN0cnVjdGluZyB0
aGUgb2JqZWN0IHRoZSByZWNlaSk3MiA1NDcuMiBRIC0uMTY1KHZlKQotLjI3NSBHIDIuNzUo
cm0pLjE2NSBHKGF5IHN0YXkgaW4gdGhlIHNlc3Npb24gYW5kIHcpLTIuNzUgRShhaXQgZm9y
IHRoZSkKLS4xMSBFKHRyYW5zbWlzc2lvbiBvZiB0aGUgbmUpNzIgNTYwLjIgUSh4dCBvYmpl
Y3QuKS0uMTY1IEUKKFRoZSBwdXNoIG1vZGVsIGlzIHBhcnRpY3VsYXJseSBhdHRyYWN0aSk3
MiA1ODYuMiBRIC4zMyAtLjE2NSh2ZSBpKS0uMjc1CkggMi43NShucykuMTY1IEcoYXRlbGxp
dGUgbmV0dyktMi43NSBFKG9ya3MgYW5kIHdpcmVsZXNzIG5ldHcpLS4xMSBFCjIuNzUob3Jr
cy4gSW4pLS4xMSBGKHRoZXNlKTIuNzUgRQooY2FzZXMsIGEgc2Vzc2lvbiBtYXkgY29uc2lz
dCBvZiBvbmUgXDIxNHgpNzIgNTk5LjIgUQooZWQgcmF0ZSBMQ1QgY2hhbm5lbC4pLS4xNjUg
RSBGMShPbi1kZW1hbmQgY29udGVudCBkZWxpKTcyIDYzOC4yIFEgLS4xMQoodmUpLS4xMSBH
KHJ5IG1vZGVsLikuMTEgRSBGMCAtLjE2NShGbyk3MiA2NTQuOCBTIDIuNzUocmEpLjE2NSBH
IDIuNzUKKG5vKS0yLjc1IEcobi1kZW1hbmQgY29udGVudCBkZWxpKS0yLjc1IEUgLS4xNjUo
dmUpLS4yNzUgRwoocnkgc2VydmljZSBtb2RlbCwgc2VuZGVycyB0eXBpY2FsbHkgdHJhbnNt
aXQgZm9yIHNvbWUgZ2kpLjE2NSBFIC0uMTY1Cih2ZSktLjI3NSBHIDIuNzUobnQpLjE2NSBH
KGltZSktMi43NSBFCihwZXJpb2Qgc2VsZWN0ZWQgdG8gYmUgbG9uZyBlbm91Z2ggdG8gYWxs
byk3MiA2NjcuOCBRIDIuNzUod2EpLS4yNzUgRwoobGwgdGhlIGludGVuZGVkIHJlY2VpKS0y
Ljc1IEUgLS4xNjUodmUpLS4yNzUgRwoocnMgdG8gam9pbiB0aGUgc2Vzc2lvbiBhbmQpLjE2
NSBFKHJlY28pNzIgNjgwLjggUSAtLjE2NSh2ZSktLjE2NSBHIDIuNzUKKHJ0KS4xNjUgRyho
ZSBvYmplY3QuKS0yLjc1IEUgLS4xNjUoRm8pNS41IEcgMi43NShyZSkuMTY1IEcKKHhhbXBs
ZSBhIHBvcHVsYXIgc29mdHcpLTIuOTE1IEUKKGFyZSB1cGRhdGUgbWlnaHQgYmUgdHJhbnNt
aXR0ZWQgdXNpbmcgTENUIGZvciktLjExIEUoc2UpNzIgNjkzLjggUQotLjE2NSh2ZSktLjI3
NSBHKHJhbCBkYXlzLCBlKS4xNjUgRSAtLjE2NSh2ZSktLjI3NSBHIDIuNzUobnQpLjE2NSBH
Cihob3VnaCBhIHJlY2VpKS0yLjc1IEUgLS4xNjUodmUpLS4yNzUgRyAyLjc1KHJtKS4xNjUg
RwooYXkgYmUgYWJsZSB0byBjb21wbGV0ZSB0aGUgZG8pLTIuNzUgRSh3bmxvYWQgaW4gb25l
IGhvdXIgdG90YWwgb2YpLS4yNzUKRShjb25uZWN0aW9uIHRpbWUsIHBlcmhhcHMgc3ByZWFk
IG8pNzIgNzA2LjggUSAtLjE2NSh2ZSktLjE2NSBHIDIuNzUocnMpCi4xNjUgRyAtMi4zNjUg
LS4yNzUoZXYgZSktMi43NSBIKHJhbCBpbnRlcnYpLjI3NSBFKGFscyBvZiB0aW1lLiktLjI3
NSBFCihMdWJ5L0dlbW1lbGwvVik3MiA3NjkgUShpY2lzYW5vL1JpenpvL0hhbmRsZSktLjY2
IEUoeS9Dcm8pLS4xNjUgRQoxMDkuMTA2KHdjcm9mdCBTZWN0aW9uKS0uMjc1IEYgMi43NSgy
LjEuIFtQKTIuNzUgRihhZ2UgN10pLS4xNjUgRSBFUAolJVBhZ2U6IDggOAolJUJlZ2luUGFn
ZVNldHVwCkJQCiUlRW5kUGFnZVNldHVwCi9GMCAxMS9UaW1lcy1Sb21hbkAwIFNGKElOVEVS
TkVUKTcyIDQ5IFEgNzEuNTg3KC1EUkFGVCBFeHBpcmVzOiktMS4wMTIgRgooSmFudWFyeSAy
MDAyKTIuNzUgRShKdWx5IDIwMDEpMTIzLjcyNiBFKEluIHRoaXMgY2FzZSB0aGUgcmVjZWkp
NzIgODUgUQotLjE2NSh2ZSktLjI3NSBHCihycyBqb2luIHRoZSBzZXNzaW9uLCBhbmQgZHlu
YW1pY2FsbHkgYWRhcHQgdGhlIG51bWJlciBvZiBMQ1QgY2hhbm5lbHMpCi4xNjUgRSh0aGUp
NzIgOTggUSAyLjc1KHlzKS0uMTY1IEcKKHVic2NyaWJlIHRvIFwoYW5kIHRoZSByZWNlcHRp
b24gcXVhbGl0eVwpIGFjY29yZGluZyB0byB0aGUgYSktMi43NSBFCi0uMjc1KHZhKS0uMjIg
RyhpbGFibGUgYmFuZHdpZHRoLiBSZWNlaSkuMjc1IEUgLS4xNjUodmUpLS4yNzUgRyhycyB0
aGVuKQouMTY1IEUoZHJvcCBmcm9tIHRoZSBzZXNzaW9uIHdoZW4gdGhlKTcyIDExMSBRIDIu
NzUoeWgpLS4xNjUgRyAtMi40NzUKLS4yMihhdiBlKS0yLjc1IEgocmVjZWkpMi45NyBFIC0u
MTY1KHZlKS0uMjc1IEcgMi43NShkZSkuMTY1IEcKKG5vdWdoIHBhY2spLTIuNzUgRShldHMg
dG8gcmVjbyktLjExIEUgLS4xNjUodmUpLS4xNjUgRyAyLjc1KHJ0KS4xNjUgRwooaGUgb2Jq
ZWN0LiktMi43NSBFKEFzIGFuIGUpNzIgMTM3IFEKKHhhbXBsZSwgYXNzdW1lIHRoYXQgYW4g
b2JqZWN0IGlzIDUwIE1CLiktLjE2NSBFCihUaGUgc2VuZGVyIGNvdWxkIHNldCB0aGUgZGF0
YSByYXRlIG9uIHRoZSBsbyk1LjUgRSh3ZXN0KS0uMjc1IEUKKExDVCBjaGFubmVsIHRvIDUw
IDFLQiBwYWNrKTcyIDE1MCBRKGV0cyBwZXIgc2Vjb25kLCBzbyB0aGF0IHJlY2VpKS0uMTEK
RSAtLjE2NSh2ZSktLjI3NSBHKHJzIHVzaW5nIGp1c3QgdGhpcyBMQ1QgY2hhbm5lbCBjb3Vs
ZCkuMTY1IEUoY29tcGxldGVcCiByZWNlcHRpb24gb2YgdGhlIG9iamVjdCBpbiAxLDAwMCBz
ZWNvbmRzIGluIGFic2VuY2Ugb2YgbG9zcywgYW5kIHcpNzIKMTYzIFEob3VsZCBiZSBhYmxl
IHRvKS0uMTEgRShjb21wbGV0ZSByZWNlcHRpb24gZSk3MiAxNzYgUSAtLjE2NSh2ZSkKLS4y
NzUgRyAyLjc1KG5pKS4xNjUgRyAyLjc1KG5wKS0yLjc1IEcKKHJlc2VuY2Ugb2Ygc29tZSBz
dWJzdGFudGlhbCBhbW91bnQgb2YgbG9zc2VzIHdpdGggdGhlIHVzZSBvZiBjb2RpbmcpCi0y
Ljc1IEUoZm9yIHJlbGlhYmlsaXR5KTcyIDE4OSBRIDUuNSguRiktLjcxNSBHKHVydGhlcm1v
cmUsIHRoZSBzZW5kZXIgXApjb3VsZCB1c2UgYSBudW1iZXIgb2YgTENUIGNoYW5uZWxzIHN1
Y2ggdGhhdCB0aGUpLTUuNSBFKGFnZ3JlKTcyIDIwMiBRCi0uMDU1KGdhKS0uMTY1IEcKKHRl
IGRhdGEgcmF0ZSB3aGVuIHVzaW5nIGFsbCBMQ1QgY2hhbm5lbHMgaXMgMSwwMDAgMUtCIHBh
Y2spLjA1NSBFCihldHMgcGVyIHNlY29uZCwgc28gdGhhdCBhKS0uMTEgRShyZWNlaSk3MiAy
MTUgUSAtLjE2NSh2ZSktLjI3NSBHIDIuNzUKKHJjKS4xNjUgRyhvdWxkIGJlIGFibGUgdG8g
Y29tcGxldGUgcmVjZXB0aW9uIG9mIHRoZSBvYmplY3QgaW4gYXMgbGl0dGxcCmUgNTAgc2Vj
b25kcyBcKGFzc3VtaW5nIG5vIGxvc3MpLTIuNzUgRQooYW5kIHRoYXQgdGhlIGNvbmdlc3Rp
b24gY29udHJvbCBtZWNoYW5pc20gaW1tZWRpYXRlbHkgY29uKTcyIDIyOCBRCi0uMTY1KHZl
KS0uNDQgRyAtLjE5OChyZykuMTY1IEcoZXMgdG8gdGhlIHVzZSBvZiBhbGwgTENUKS4xOTgg
RQooY2hhbm5lbHNcKS4pNzIgMjQxIFEvRjEgMTEvVGltZXMtQm9sZEAwIFNGKE90aGVyIHNl
cik3MiAyODAgUQoodmljZSBtb2RlbHMuKS0uMTEgRSBGMChUaGVyZSBhcmUgbWFuKTcyIDMw
OS42IFEgMi43NSh5byktLjE2NSBHCih0aGVyIGRlbGkpLTIuNzUgRSAtLjE2NSh2ZSktLjI3
NSBHCihyeSBzZXJ2aWNlIG1vZGVscyB0aGF0IExDVCBjYW4gYmUgdXNlZCBmb3IgdGhhdCBh
cmUgbm90IGNvKS4xNjUgRSAtLjE2NQoodmUpLS4xNjUgRyhyZWQpLjE2NSBFKGFibyk3MiAz
MjIuNiBRIC0uMTY1KHZlKS0uMTY1IEcgNS41KC5BKS4xNjUgRwoyLjc1KHNlKS01LjUgRyh4
YW1wbGVzLCBhIGxpKS0yLjkxNSBFIC4zMyAtLjE2NSh2ZSBzKS0uMjc1IEgKKHRyZWFtaW5n
IG9yIGFuIG9uLWRlbWFuZCBhcmNoaSkuMTY1IEUgLS4yNzUodmEpLS4yNzUgRyAyLjc1KGxj
KS4yNzUgRwoob250ZW50IHN0cmVhbWluZyBzZXJ2aWNlIG1vZGVsLiktMi43NSBFKFRoZSBk
ZXNjcmlwdGlvbiBvZiB0aGUgbWFuKTcyCjMzNS42IFEgMi43NSh5cCktLjE2NSBHKG90ZW50
aWFsIGFwcGxpY2F0aW9ucywgdGhlIGFwcHJvcHJpYXRlIGRlbGkpCi0yLjc1IEUgLS4xNjUo
dmUpLS4yNzUgRyhyeSBzZXJ2aWNlIG1vZGVsLCBhbmQpLjE2NSBFKHRoZSBhZGRpdGlvbmFs
IG1lXApjaGFuaXNtcyB0byBzdXBwb3J0IHN1Y2ggZnVuY3Rpb25hbGl0aWVzIHdoZW4gY29t
YmluZWQgd2l0aCBMQ1QgaXMgYmUpNzIKMzQ4LjYgUSh5b25kKS0uMTY1IEUodGhlIHNjb3Bl
IG9mIHRoaXMgZG9jdW1lbnQuKTcyIDM2MS42IFEKKFRoaXMgZG9jdW1lbnQgb25seSBhdHRl
bXB0cyB0byBkZXNjcmliZSB0aGUgbWluaW1hbCBjb21tb24pNS41IEUKKHNjYWxhYmxlIGVs
ZW1lbnRzIHRvIHRoZXNlIGRpKTcyIDM3NC42IFEgLS4xNjUodmUpLS4yNzUgRwoocnNlIGFw
cGxpY2F0aW9ucyB1c2luZyBMQ1QgYXMgdGhlIGRlbGkpLjE2NSBFIC0uMTY1KHZlKS0uMjc1
IEcKKHJ5IHRyYW5zcG9ydC4pLjE2NSBFIEYxKDIuMi4pNzIgNDEzLjYgUS9GMiAxMy9UaW1l
cy1Cb2xkQDAgU0YKKENvbmdlc3Rpb24gQ29udHIpNS41IEUob2wpLS4yMzQgRSBGMChUaGUg
c3BlY2lcMjE0YyBjb25nZXN0aW9uIGNvbnRyb2xcCiBwcm90b2NvbCB0byBiZSB1c2VkIGZv
ciBMQ1Qgc2Vzc2lvbnMgZGVwZW5kcyBvbiB0aGUgdHlwZSBvZik3MiA0MzAuMiBRCihjb250
ZW50IHRvIGJlIGRlbGkpNzIgNDQzLjIgUSAtLjE2NSh2ZSktLjI3NSBHCihyZWQuIFdoaWxl
IHRoZSBnZW5lcmFsIGJlaGEpLjE2NSBFCih2aW9yIG9mIHRoZSBjb25nZXN0aW9uIGNvbnRy
b2wgcHJvdG9jb2wgaXMgdG8gcmVkdWNlKS0uMjIgRSh0aGUgdGhyb3VnXApocHV0IGluIHBy
ZXNlbmNlIG9mIGNvbmdlc3Rpb24gYW5kIGdyYWR1YWxseSBpbmNyZWFzZSBpdCBpbiB0aGUg
YWJzZW5jZVwKIG9mIGNvbmdlc3Rpb24sKTcyIDQ1Ni4yIFEodGhlIGFjdHVhbCBkeW5hbWlj
IGJlaGEpNzIgNDY5LjIgUQoodmlvciBcKGUuZy4gcmVzcG9uc2UgdG8gc2luZ2xlIGxvc3Nl
c1wpIGNhbiB2KS0uMjIgRShhcnkpLS4yNzUgRSguKQotLjcxNSBFCihTb21lIHBvc3NpYmxl
IGNvbmdlc3Rpb24gY29udHJvbCBwcm90b2NvbHMgZm9yIHJlbGlhYmxlIGNvbnRlbnQgZGVs
aSk3Mgo0OTUuMiBRIC0uMTY1KHZlKS0uMjc1IEcocnkgdXNpbmcgTENUIGFyZSBkZXNjcmli
ZWQpLjE2NSBFKGluIFs5XS4gRGlmKQo3MiA1MDguMiBRKGZlcmVudCBkZWxpKS0uMjc1IEUg
LS4xNjUodmUpLS4yNzUgRwoocnkgc2VydmljZSBtb2RlbHMgbWlnaHQgcmVxdWlyZSBhIGRp
ZikuMTY1IEUKKGZlcmVudCBjb25nZXN0aW9uIGNvbnRyb2wgcHJvdG9jb2xzLiktLjI3NSBF
IEYxKDMuKTcyIDU0Ny4yIFEvRjMgMTQKL1RpbWVzLUJvbGRAMCBTRihMQ1QgcGFjayk1LjUg
RShldHMpLS4xNCBFIEYwKFRoZSB0eXBlIG9mIHBhY2spNzIgNTYzLjgKUShldCB1c2VkIGJ5
IExDVCBzZXNzaW9ucyBpcyAiTENUIFApLS4xMSBFKGFjayktLjE2NSBFIDIuNzUoZXQiLiBM
Q1QpCi0uMTEgRihwYWNrKTIuNzUgRShldHMgYXJlIHNlbnQgYnkgc2VuZGVycyB0byktLjEx
IEUoTENUIGNoYW5uZWxzLik3Mgo1NzYuOCBRKFNvbWUgaW5zdGFuY2VzIG9mIExDVCBzZXNz
aW9ucyBNQSk3MiA2MDIuOCBRIDIuNzUoWXIpLTEuMTU1IEcKKGVxdWlyZSB0aGUgZ2VuZXJh
dGlvbiBvZiBmZWVkYmFjayBmcm9tIHRoZSByZWNlaSktMi43NSBFIC0uMTY1KHZlKS0uMjc1
CkcocnMgdG8pLjE2NSBFKHRoZSBzZW5kZXIpNzIgNjE1LjggUSA1LjUoLkgpLS42MDUgRyAt
LjI3NShvdyktNS41IEcKLTIuMzY1IC0uMjc1KGV2IGUpLjI3NSBIIC44OCAtLjQ0KHIsIHQp
LjI3NSBICihoZSBtZWNoYW5pc20gZm9yIGRvaW5nIHRoaXMgaXMgb3V0c2lkZSB0aGUgc2Nv
cGUgb2YgTENUKS40NCBFKC4pLS44MTQgRQooVGhlIExDVCBwYWNrKTcyIDY0MS44IFEoZXQg
Zm9ybWF0IGRlc2NyaWJlZCBpbiB0aGlzIGRvY3VtZW50IGlzIGludGVuZFwKZWQgdG8gYmUg
dXNlZCBpbiBjb25qdW5jdGlvbiB3aXRoIHRoZSktLjExIEUoVURQIHRyYW5zcG9ydCBwcm90
b2NvbCBhcyBcCmRlXDIxNG5lZCBpbiBSRkM3Njggb3Igb3RoZXIgdHJhbnNwb3J0IHByb3Rv
Y29scyB0aGF0IHNhdGlzZnkgdGhlKTcyCjY1NC44IFEKKHJlcXVpcmVtZW50cyBzdGF0ZWQg
aW4gU2VjdGlvbiAxLjIsIHNwZWNpXDIxNGNhbGx5IGFib3V0IGRlbXVsdGlwbGUpNzIKNjY3
LjggUSh4aW5nIGFuZCBkZWxpKS0uMTY1IEUgLS4xNjUodmUpLS4yNzUgRyhyeSBvZiBwYWNr
KS4xNjUgRQooZXQgc2l6ZSktLjExIEUoaW5mb3JtYXRpb24uKTcyIDY4MC44IFEoTENUIHBh
Y2spNzIgNzA2LjggUQooZXRzIGNvbnNpc3Qgb2YgYW4gTENUIHBhY2spLS4xMSBFKGV0IGhl
YWRlciBhbmQgYW4gT1BUSU9OKS0uMTEgRQooQUwgTENUIHBhY2spLS4zODUgRShldCBwYXls
b2FkLCBhcyBzaG8pLS4xMSBFKHduKS0uMjc1IEUoaW4gRmlndXJlIDEuKQo3MiA3MTkuOCBR
KFdoZW4gcHJlc2VudCwgdGhlIExDVCBwYWNrKTUuNSBFCihldCBwYXlsb2FkIGltbWVkaWF0
ZWx5IGZvbGxvKS0uMTEgRSh3cyB0aGUgTENUIHBhY2spLS4yNzUgRShldCBoZWFkZXIpCi0u
MTEgRSguKS0uNjA1IEUoTHVieS9HZW1tZWxsL1YpNzIgNzY5IFEoaWNpc2Fuby9SaXp6by9I
YW5kbGUpLS42NiBFCih5L0NybyktLjE2NSBFIDExNy4zNTYod2Nyb2Z0IFNlY3Rpb24pLS4y
NzUgRiAyLjc1KDMuIFtQKTIuNzUgRihhZ2UgOF0pCi0uMTY1IEUgRVAKJSVQYWdlOiA5IDkK
JSVCZWdpblBhZ2VTZXR1cApCUAolJUVuZFBhZ2VTZXR1cAovRjAgMTEvVGltZXMtUm9tYW5A
MCBTRihJTlRFUk5FVCk3MiA0OSBRIDcxLjU4NygtRFJBRlQgRXhwaXJlczopLTEuMDEyIEYK
KEphbnVhcnkgMjAwMikyLjc1IEUoSnVseSAyMDAxKTEyMy43MjYgRShUaGUgTENUIHBhY2sp
NzIgODUgUQooZXQgcGF5bG9hZCBNQSktLjExIEUgMi43NShZYyktMS4xNTUgRwoob250YWlu
IGhlYWRlcnMgZm9yIG90aGVyIHByb3RvY29scywgc3VjaCBhcyByZWxpYWJpbGl0eSBwcm90
b2NvbHMuKQotMi43NSBFKExDVCBwYWNrKTcyIDExMSBRKGV0IGhlYWRlcnMgaGEpLS4xMSBF
IC4zMyAtLjE2NSh2ZSB2KS0uMjIgSChhclwKaWFibGUgc2l6ZSwgd2hpY2ggaXMgc3BlY2lc
MjE0ZWQgYnkgYSBsZW5ndGggXDIxNGVsZCBpbiB0aGUgdGhpcmQgYnl0ZSBcCm9mIHRoZSkt
LjExIEUoaGVhZGVyKTcyIDEyNCBRIDUuNSguSSktLjYwNSBHIDIuNzUobnQpLTUuNSBHKGhl
IExDVCBwYWNrKQotMi43NSBFKGV0IGhlYWRlciktLjExIEUgMi43NSgsYSktLjQ0IEcobGwg
aW50ZSktMi43NSBFCihnZXIgXDIxNGVsZHMgYXJlIGNhcnJpZWQgaW4gImJpZy1lbmRpYW4i
IG9yICJuZXR3KS0uMTY1IEUob3JrIG9yZGVyIikKLS4xMSBFKGZvcm1hdCwgdGhhdCBpcywg
bW9zdCBzaWduaVwyMTRjYW50IGJ5dGUgXChvY3RldFwpIFwyMTRyc3QuKTcyCjEzNyBRKEJp
dHMgZGVzaWduYXRlZCBhcyAicGFkZGluZyIgb3IgInJlc2Vydik1LjUgRShlZCIgXChyXCkp
LS4xNjUgRQooTVVTVCBieSBzZXQgdG8gMCBieSBzZW5kZXJzIGFuZCBpZ25vcmVkIGJ5IHJl
Y2VpKTcyIDE1MCBRIC0uMTY1KHZlKQotLjI3NSBHIDIuNzUocnMuIFVubGVzcykuMTY1IEYo
b3RoZXJ3aXNlIG5vdGVkLCBudW1lcmljKTIuNzUgRQooY29uc3RhbnRzIGluIHRoaXMgc3Bl
Y2lcMjE0Y2F0aW9uIGFyZSBpbiBkZWNpbWFsIFwoYmFzZSAxMFwpLik3MiAxNjMgUQovRjEg
MTEvVGltZXMtQm9sZEAwIFNGKDMuMS4pNzIgMjAyIFEvRjIgMTMvVGltZXMtQm9sZEAwIFNG
KExDVCBwYWNrKTUuNQpFKGV0IGYpLS4xMyBFKG9ybWF0KS0uMzI1IEUgRjAoVGhlIGZvcm1h
dCBvZiBMQ1QgcGFjayk3MiAyMTguNiBRCihldHMgaXMgZGVwaWN0ZWQgaW4gRmlndXJlIDEu
KS0uMTEgRS9GMyA4L0NvdXJpZXJAMCBTRiA5MS4yKDAxMjMpODEuNgoyNTcuNiBTIDQuOCgw
MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMSk4MS42IDI3MC42IFMKKCstKy0rLSst
Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst
Ky0rKTc2LjgKMjgzLjYgUSAtMTQuNCAxNC40KHxWfCByIHwpNzYuOCAyOTYuNiBUIDQuOChJ
fCktOS42IEcgOS42CihTfEV8WHxBfEJ8IEhEUl9MRU4pLTQuOCBGIDQuOCh8QykyNCBHKG9k
ZXBvaW50IFwoQ1BcKXwpLTQuOCBFCigrLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r
LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKyk3Ni44CjMwOS42IFEgNjIuNCh8
Qyk3Ni44IDMyMi42IFMob25nZXN0aW9uIENvbnRyb2wgSW5mb3JtYXRpb24gXChDQ0lcKSkt
NjIuNApFKHwpNjcuMiBFCigrLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r
LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKyk3Ni44CjMzNS42IFEgMzguNCh8VCk3Ni44
IDM0OC42IFMKKHJhbnNwb3J0IE9iamVjdCBJZGVudGlmaWVyIFwoVE9JLCBpZiBJID49IDFc
KSktMzguNCBFKHwpNTIuOCBFCigrLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst
Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKyk3Ni44CjM2MS42IFEgNzYuOCh8VCk3
Ni44IDM3NC42IFMoT0kgY29udGludWVkKS03Ni44IEUoXChpZiBJID49IDJcKSk5LjYgRSh8
KQoxMDAuOCBFCigrLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r
LSstKy0rLSstKy0rLSstKy0rLSstKyk3Ni44CjM4Ny42IFEgNzYuOCh8VCk3Ni44IDQwMC42
IFMoT0kgY29udGludWVkKS03Ni44IEUoXChpZiBJID0gM1wpKTkuNiBFKHwpCjEwNS42IEUK
KCstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r
LSstKy0rLSstKy0rKTc2LjgKNDEzLjYgUSA3Ni44KHxUKTc2LjggNDI2LjYgUyhPSSBjb250
aW51ZWQpLTc2LjggRShcKGlmIEkgPSAzXCkpOS42IEUofCkKMTA1LjYgRQooKy0rLSstKy0r
LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r
LSspNzYuOAo0MzkuNiBRIDcyKHxTKTc2LjggNDUyLjYgUyhlbmRlciBDdXJyZW50IFRpbWUg
XChTQ1QsIGlmIFMgPSAxXCkpLTcyIEUofCkKNjIuNCBFCigrLSstKy0rLSstKy0rLSstKy0r
LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKyk3Ni44CjQ2
NS42IFEgNjcuMih8RSk3Ni44IDQ3OC42IFMoeHBlY3RlZCBSZXNpZHVhbCBUaW1lIFwoRVJU
LCBpZiBFID0gMVwpKQotNjcuMiBFKHwpNTIuOCBFCigrLSstKy0rLSstKy0rLSstKy0rLSst
Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKyk3Ni44CjQ5MS42
IFEgNzYuOCh8SCk3Ni44IDUwNC42IFMoZWFkZXIgRXh0ZW5zaW9ucyBcKGlmIFggPSAxIFwp
KS03Ni44IEUofCkKODYuNCBFIDMwMi40KHx8KTc2LjggNTE3LjYgUwooKz0rPSs9Kz0rPSs9
Kz0rPSs9Kz0rPSs9Kz0rPSs9Kz0rPSs9Kz0rPSs9Kz0rPSs9Kz0rPSs9Kz0rPSs9Kz0rPSsp
NzYuOAo1MzAuNiBRIDMwMi40KHx8KTc2LjggNTQzLjYgUyAxMjQuOCh8UCk3Ni44IDU1Ni42
IFMgMTM5LjIoYXlsb2FkIHwpCi0xMjQuOCBGIDMwMi40KHx8KTc2LjggNTY5LjYgUwooKy0r
LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r
LSstKy0rLSspNzYuOAo1ODIuNiBRL0Y0IDEwL1RpbWVzLVJvbWFuQDAgU0YoRmlndXJlIDEg
LSBMQ1QgcGFjayk3MiA2MjEuNiBRKGV0IGZvcm1hdCkKLS4xIEUgRjEoMy4yLik3MiA2NjAu
NiBRIEYyKExDVCBwYWNrKTUuNSBFKGV0IGhlYWRlciBcMjE0ZWxkcyktLjEzIEUgRjAKKFRo
ZSBmdW5jdGlvbiBlYWNoIFwyMTRlbGQgaW4gTENUIHBhY2spNzIgNjc3LjIgUQooZXQgaGVh
ZGVycyBpcyB0aGUgZm9sbG8pLS4xMSBFIDIuNzUod2luZy4gRmllbGRzKS0uMjc1IEYobWFy
aykyLjc1IEUKKGVkIGFzICIxIiBtZWFuIHRoYXQpLS4xMSBFCih0aGUgY29ycmVzcG9uZGlu
ZyBiaXRzIE1VU1QgYmUgc2V0IHRvICIxIiBieSB0aGUgZ2VuZXJhdGluZyBhZ2VudC4pNzIK
NjkwLjIgUShGaWVsZHMgbWFyayk1LjUgRShlZCBhcyAiciIgb3IgIjAiKS0uMTEgRShtZWFu
IHRoYXQgdGhlIGNvcnJlc3BcCm9uZGluZyBiaXRzIE1VU1QgYmUgc2V0IHRvICIwIiBieSB0
aGUgZ2VuZXJhdGluZyBhZ2VudC4pNzIgNzAzLjIgUQooTHVieS9HZW1tZWxsL1YpNzIgNzY5
IFEoaWNpc2Fuby9SaXp6by9IYW5kbGUpLS42NiBFKHkvQ3JvKS0uMTY1IEUKMTA5LjEwNih3
Y3JvZnQgU2VjdGlvbiktLjI3NSBGIDIuNzUoMy4yLiBbUCkyLjc1IEYoYWdlIDldKS0uMTY1
IEUgRVAKJSVQYWdlOiAxMCAxMAolJUJlZ2luUGFnZVNldHVwCkJQCiUlRW5kUGFnZVNldHVw
Ci9GMCAxMS9UaW1lcy1Sb21hbkAwIFNGKElOVEVSTkVUKTcyIDQ5IFEgNzEuNTg3KC1EUkFG
VCBFeHBpcmVzOiktMS4wMTIgRgooSmFudWFyeSAyMDAyKTIuNzUgRShKdWx5IDIwMDEpMTIz
LjcyNiBFKExDVCB2KTgzIDg1IFEKKGVyc2lvbiBudW1iZXIgXChWXCk6IDQgYml0cyktLjE2
NSBFKEluZGljYXRlcyB0aGUgTENUIHByb3RvY29sIHYpMTA1CjEwMS42IFEgMi43NShlcnNp
b24uIFRoZSktLjE2NSBGKExDVCB2KTIuNzUgRQooZXJzaW9uIG51bWJlciBmb3IgdGhpcyBz
cGVjaVwyMTRjYXRpb24gaXMgMC4pLS4xNjUgRShSZXNlcnYpODMgMTMxLjIgUQooZWQgXChy
XCk6IDUgYml0cyktLjE2NSBFKFJlc2VydikxMDUgMTQ3LjggUQooZWQgZm9yIGZ1dHVyZSB1
c2UuIEEgc2VuZGVyIE1VU1Qgc2V0IHRoZXNlIGJpdHMgdG8gemVybyBhbmQgYSByZWNlaSkK
LS4xNjUgRSAtLjE2NSh2ZSktLjI3NSBHIDIuNzUock0pLjE2NSBHKFVTVCktMi43NSBFKGln
bm9yZSB0aGVzZSBiaXRzLikKMTA1IDE2MC44IFEgLS4zODUoVHIpODMgMTkwLjQgUwooYW5z
cG9ydCBPYmplY3QgSWRlbnRpXDIxNGVyIFwyMTVhZyBcKElcKTogMiBiaXRzKS4zODUgRQoo
ST0wIGluZGljYXRlcyBubyBUKTEwNSAyMDcgUShyYW5zcG9ydCBPYmplY3QgSWRlbnRpXDIx
NGVyIFwoVCktLjM4NSBFCihPSVwpIFwyMTRlbGQgaXMgcHJlc2VudC4pLS4xOTggRShJPTEg
aW5kaWNhdGVzIHRoYXQgYSAzMi1iaXQgVCkxMDUgMjIwClEoT0kgXDIxNGVsZCBpcyBwcmVz
ZW50LiktLjE5OCBFKEk9MiBpbmRpY2F0ZXMgdGhhdCBhIDY0LWJpdCBUKTEwNSAyMzMgUQoo
T0kgXDIxNGVsZCBpcyBwcmVzZW50LiktLjE5OCBFKEk9MyBpbmRpY2F0ZXMgdGhhdCBhIDEy
OC1iaXQgVCkxMDUgMjQ2IFEKKE9JIFwyMTRlbGQgaXMgcHJlc2VudC4pLS4xOTggRShUaGUg
VCkxMDUgMjU5IFEKKE9JIFwyMTRlbGQgaW5kaWNhdGVzIHdoaWNoIG9iamVjdCB3aXRoaW4g
dGhlIHNlc3Npb24gdGhpcyBMQ1QgcGFjaykKLS4xOTggRShldCBwZXJ0YWlucyB0by4pLS4x
MSBFKFNlbmRlciBDdXJyZW50IFQpODMgMjg4LjYgUQooaW1lIHByZXNlbnQgXDIxNWFnIFwo
U1wpOiAxIGJpdCktLjM4NSBFIDIuNzUoUz0waSkxMDUgMzA1LjIgUwoobmRpY2F0ZXMgdGhh
dCB0aGUgU2VuZGVyIEN1cnJlbnQgVCktMi43NSBFCihpbWUgXChTQ1RcKSBcMjE0ZWxkIGlz
IG5vdCBwcmVzZW50LiktLjM4NSBFIDIuNzUoUz0xaSkxMDUgMzE4LjIgUwoobmRpY2F0ZXMg
dGhhdCB0aGUgU0NUIFwyMTRlbGQgaXMgcHJlc2VudC4pLTIuNzUgRQooVGhlIFNDVCBpcyBp
bnNlcnRlZCBieSBzZW5kZXJzIHRvIGluZGljYXRlIHRvIHJlY2VpKTEwNSAzMzEuMiBRIC0u
MTY1Cih2ZSktLjI3NSBHKHJzIGhvKS4xNjUgRSAyLjc1KHdsKS0uMjc1IEcob25nIHRoZSBz
ZXNzaW9uIGhhcyBiZWVuIGluKQotMi43NSBFKHByb2dyZXNzLikxMDUgMzQ0LjIgUShFeHBl
Y3RlZCBSZXNpZHVhbCBUKTgzIDM3My44IFEKKGltZSBwcmVzZW50IFwyMTVhZyBcKEVcKTog
MSBiaXQpLS4zODUgRSAyLjc1KEU9MGkpMTA1IDM5MC40IFMKKG5kaWNhdGVzIHRoYXQgdGhl
IEV4cGVjdGVkIFJlc2lkdWFsIFQpLTIuNzUgRShpbWUgXChFUiktLjM4NSBFCihUXCkgXDIx
NGVsZCBpcyBub3QgcHJlc2VudC4pLS42NiBFIDIuNzUoRT0xaSkxMDUgNDAzLjQgUwoobmRp
Y2F0ZXMgdGhhdCB0aGUgRVIpLTIuNzUgRSAyLjc1PDU0OGM+LS42NiBHKGVsZCBpcyBwcmVz
ZW50LiktMi43NSBFCihUaGUgRVIpMTA1IDQxNi40IFEgMi43NShUaSktLjY2IEcgMi43NShz
aSktMi43NSBHCihuc2VydGVkIGJ5IHNlbmRlcnMgdG8gaW5kaWNhdGUgdG8gcmVjZWkpLTIu
NzUgRSAtLjE2NSh2ZSktLjI3NSBHKHJzIGhvKQouMTY1IEUgMi43NSh3bSktLjI3NSBHKHVj
aCBsb25nZXIgdGhlIHNlc3Npb24gd2lsbCktMi43NSBFKGNvbnRpbnVlLikxMDUKNDI5LjQg
UShTZW5kZXJzIE1VU1QgTk8pMTA1IDQ0Mi40IFEgMi43NShUcyktLjQ0IEcoZXQgRSA9IDEg
d2hlbiB0aGUgRVIpCi0yLjc1IEUgMi43NShUZiktLjY2IEcob3IgdGhlIHNlc3Npb24gaXMg
bW9yZSB0aGFuIDJeMzItMSB0aW1lKS0yLjc1IEUoXAp1bml0cyBcKGFwcHJveGltYXRlbHkg
NDkgZGF5c1wpLCB3aGVyZSB0aW1lIGlzIG1lYXN1cmVkIGluIHVuaXRzIG9mIG1pbFwKbGlz
ZWNvbmRzLikxMDUgNDU1LjQgUShIZWFkZXIgZSk4MyA0ODUgUQooeHRlbnNpb24gcHJlc2Vu
dCBcMjE1YWcgXChYXCk6IDEgYml0KS0uMTY1IEUgMi43NShYPTBpKTEwNSA1MDEuNiBTCihu
ZGljYXRlcyBubyBIZWFkZXIgRXh0ZW5zaW9ucyBhcmUgcHJlc2VudC4pLTIuNzUgRSAyLjc1
KFg9MWkpMTA1IDUxNC42ClMobmRpY2F0ZXMgdGhhdCBIZWFkZXIgRXh0ZW5zaW9ucyBhcmUg
cHJlc2VudC4pLTIuNzUgRQooSGVhZGVyIEV4dGVuc2lvbnMgYXJlIHVzZWQgaW4gTENUIHRv
IGFjY29tbW9kYXRlIE9QVElPTikxMDUgNTI3LjYgUQooQUwgaGVhZGVyIFwyMTRlbGRzIHdo
aWNoIGFyZSktLjM4NSBFKG5vdCBhbCkxMDUgNTQwLjYgUSAtLjExKHdhKS0uMTEgRwooeXMg
dXNlZCBvciBoYSkuMTEgRSAuMzMgLS4xNjUodmUgdiktLjIyIEgoYXJpYWJsZSBzaXplLikt
LjExIEUoQ2xvc2UgVCkKODMgNTcwLjIgUShPSSBcMjE1YWcgXChBXCk6IDEgYml0KS0uMTk4
IEUoTm9ybWFsbHkpMTA1IDU4Ni44IFEgMi43NSgsdCkKLS43MTUgRyhoZSBDbG9zZSBUKS0y
Ljc1IEUoT0kgXDIxNWFnIGlzIHNldCB0byAwLiktLjE5OCBFKFRoZSBzZW5kZXIgTUEpCjUu
NSBFIDIuNzUoWXMpLTEuMTU1IEcoZXQgdGhlIENsb3NlIFQpLTIuNzUgRShPSSBcMjE1YWcg
dG8gMSktLjE5OCBFCih3aGVuIHRlcm1pbmF0aW9uIG9mIHRyYW5zbWlzc2lvbiBvZiBMQ1Qg
cGFjaykxMDUgNTk5LjggUQooZXRzIGZvciB0aGUgb2JqZWN0IGlkZW50aVwyMTRlZCBieSB0
aGUgVCktLjExIEUoT0kgaXMpLS4xOTggRSAyLjc1CihpbW1pbmVudC4gVGhlKTEwNSA2MTIu
OCBSKENsb3NlIFQpMi43NSBFKE9JIFwyMTVhZyBNQSktLjE5OCBFIDIuNzUoWWIpCi0xLjE1
NSBHIDIuNzUoZXMpLTIuNzUgRyhldCB0byAxIGluIGp1c3QgdGhlIGxhc3QgTENUIHBhY2sp
LTIuNzUgRQooZXQgdHJhbnNtaXR0ZWQgZm9yKS0uMTEgRSh0aGUgb2JqZWN0LCBvciBpdCBN
QSkxMDUgNjI1LjggUSAyLjc1KFliKQotMS4xNTUgRyAyLjc1KGVzKS0yLjc1IEcoZXQgdG8g
MSBpbiB0aGUgbGFzdCBjb3VwbGUgb2Ygc2Vjb25kcyBMQ1QgcGFjaykKLTIuNzUgRShldHMg
dHJhbnNtaXR0ZWQgZm9yKS0uMTEgRSh0aGUgb2JqZWN0LikxMDUgNjM4LjggUQooT25jZSB0
aGUgc2VuZGVyIHNldHMgdGhlIENsb3NlIFQpNS41IEUoT0kgXDIxNWFnIHRvIDEgaW4gb25l
IHBhY2spLS4xOTgKRShldCBmb3IgYSBwYXJ0aWN1bGFyKS0uMTEgRShvYmplY3QsIHRoZSBz
ZW5kZXIgU0hPVUxEIHNldCB0aGUgQ2xvc2UgVCkKMTA1IDY1MS44IFEoT0kgXDIxNWFnIHRv
IDEgaW4gYWxsIHN1YnNlcXVlbnQgcGFjayktLjE5OCBFKGV0cyBmb3IgdGhlKQotLjExIEUo
b2JqZWN0IHVudGlsIHRlcm1pbmF0aW9uIG9mIHRyYW5zbWlzc2lvbiBvZiBMQ1QgcGFjaykx
MDUgNjY0LjggUQooZXRzIGZvciB0aGUgb2JqZWN0LiktLjExIEUgMi43NShBcik1LjUgRyhl
Y2VpKS0yLjc1IEUgLS4xNjUodmUpLS4yNzUgRwoyLjc1KGRwKS4xNjUgRyhhY2spLTIuNzUg
RShldCktLjExIEUod2l0aCB0aGUgQ2xvc2UgVCkxMDUgNjc3LjggUQooT0kgXDIxNWFnIHNl
dCB0byAxIGluZGljYXRlcyB0byBhIHJlY2VpKS0uMTk4IEUgLS4xNjUodmUpLS4yNzUgRyAy
Ljc1CihydCkuMTY1IEcoaGF0IHRoZSBzZW5kZXIgd2lsbCBpbW1lZGlhdGVseSktMi43NSBF
CihzdG9wIHNlbmRpbmcgTENUIHBhY2spMTA1IDY5MC44IFEKKGV0cyBmb3IgdGhlIG9iamVj
dCBpZGVudGlcMjE0ZWQgYnkgdGhlIFQpLS4xMSBFIDIuNzUoT0kuIFdoZW4pLS4xOTggRgoy
Ljc1KGFyKTIuNzUgRyhlY2VpKS0yLjc1IEUgLS4xNjUodmUpLS4yNzUgRyAyLjc1KHJyKS4x
NjUgRyhlY2VpKS0yLjc1IEUKLS4xNjUodmUpLS4yNzUgRyAyLjc1KHNhKS4xNjUgRyhwYWNr
KTEwNSA3MDMuOCBRKGV0IHdpdGggdGhlIENsb3NlIFQpCi0uMTEgRShPSSBcMjE1YWcgc2V0
IHRvIDEgdGhlbiBpdCBzaG91bGQgYXNzdW1lIHRoYXQgbm8gbW9yZSBMQ1QgcGFjaykKLS4x
OTggRShldHMpLS4xMSBFKHdpbGwgYmUgc2VudCB0byB0aGUgc2Vzc2lvbiBmb3IgdGhpcyBv
YmplY3QuKTEwNQo3MTYuOCBRKEx1YnkvR2VtbWVsbC9WKTcyIDc2OSBRKGljaXNhbm8vUml6
em8vSGFuZGxlKS0uNjYgRSh5L0NybyktLjE2NQpFIDEwMy42MDYod2Nyb2Z0IFNlY3Rpb24p
LS4yNzUgRiAyLjc1KDMuMi4gW1ApMi43NSBGKGFnZSAxMF0pLS4xNjUgRSBFUAolJVBhZ2U6
IDExIDExCiUlQmVnaW5QYWdlU2V0dXAKQlAKJSVFbmRQYWdlU2V0dXAKL0YwIDExL1RpbWVz
LVJvbWFuQDAgU0YoSU5URVJORVQpNzIgNDkgUSA3MS41ODcoLURSQUZUIEV4cGlyZXM6KS0x
LjAxMiBGCihKYW51YXJ5IDIwMDIpMi43NSBFKEp1bHkgMjAwMSkxMjMuNzI2IEUKKENsb3Nl
IFNlc3Npb24gXDIxNWFnIFwoQlwpOiAxIGJpdCk4MyA4NSBRKE5vcm1hbGx5KTEwNSAxMDEu
NiBRIDIuNzUoLHQpCi0uNzE1IEcoaGUgQ2xvc2UgU2Vzc2lvbiBcMjE1YWcgaXMgc2V0IHRv
IDAuKS0yLjc1IEUoVGhlIHNlbmRlciBNQSk1LjUgRQoyLjc1KFlzKS0xLjE1NSBHKGV0IHRo
ZSBDbG9zZSBTZXNzaW9uIFwyMTVhZyB0byktMi43NSBFIDIuNzUoMXcpMTA1CjExNC42IFMo
aGVuIHRlcm1pbmF0aW9uIG9mIHRyYW5zbWlzc2lvbiBvZiBMQ1QgcGFjayktMi43NSBFCihl
dHMgZm9yIHRoZSBzZXNzaW9uIGlzIGltbWluZW50LiktLjExIEUoVGhlKTUuNSBFCihDbG9z
ZSBTZXNzaW9uIFwyMTVhZyBNQSkxMDUgMTI3LjYgUSAyLjc1KFliKS0xLjE1NSBHIDIuNzUo
ZXMpLTIuNzUgRwooZXQgdG8gMSBpbiBqdXN0IHRoZSBsYXN0IExDVCBwYWNrKS0yLjc1IEUK
KGV0IHRyYW5zbWl0dGVkIGZvciB0aGUgc2Vzc2lvbiwpLS4xMSBFKG9yIGl0IE1BKTEwNSAx
NDAuNiBRIDIuNzUoWWIpCi0xLjE1NSBHIDIuNzUoZXMpLTIuNzUgRyhldCB0byAxIGluIHRo
ZSBsYXN0IGNvdXBsZSBvZiBzZWNvbmRzIExDVCBwYWNrKQotMi43NSBFKGV0cyB0cmFuc21p
dHRlZCBmb3IgdGhlKS0uMTEgRSAyLjc1KHNlc3Npb24uIE9uY2UpMTA1IDE1My42IFIKKHRo
ZSBzZW5kZXIgc2V0cyB0aGUgQ2xvc2UgU2Vzc2lvbiBcMjE1YWcgdG8gMSBpbiBvbmUgcGFj
aykyLjc1IEUKKGV0LCB0aGUgc2VuZGVyKS0uMTEgRQooU0hPVUxEIHNldCB0aGUgQ2xvc2Ug
U2Vzc2lvbiBcMjE1YWcgdG8gMSBpbiBhbGwgc3Vic2VxdWVudCBwYWNrKTEwNQoxNjYuNiBR
KGV0cyB1bnRpbCB0ZXJtaW5hdGlvbiBvZiktLjExIEUodHJhbnNtaXNzaW9uIG9mIExDVCBw
YWNrKTEwNQoxNzkuNiBRKGV0cyBmb3IgdGhlIHNlc3Npb24uKS0uMTEgRSAyLjc1KEFyKTUu
NSBHKGVjZWkpLTIuNzUgRSAtLjE2NSh2ZSkKLS4yNzUgRyAyLjc1KGRwKS4xNjUgRyhhY2sp
LTIuNzUgRShldCB3aXRoIHRoZSBDbG9zZSBTZXNzaW9uKS0uMTEgRQooXDIxNWFnIHNldCB0
byAxIGluZGljYXRlcyB0byBhIHJlY2VpKTEwNSAxOTIuNiBRIC0uMTY1KHZlKS0uMjc1IEcg
Mi43NQoocnQpLjE2NSBHKGhhdCB0aGUgc2VuZGVyIHdpbGwgaW1tZWRpYXRlbHkgc3RvcCBz
ZW5kaW5nIExDVCktMi43NSBFCihwYWNrKTEwNSAyMDUuNiBRKGV0cyBmb3IgdGhlIHNlc3Np
b24uKS0uMTEgRShXaGVuIGEgcmVjZWkpNS41IEUgLS4xNjUKKHZlKS0uMjc1IEcgMi43NShy
cikuMTY1IEcoZWNlaSktMi43NSBFIC0uMTY1KHZlKS0uMjc1IEcgMi43NShzYXApLjE2NSBH
CihhY2spLTIuNzUgRShldCB3aXRoIHRoZSBDbG9zZSBTZXNzaW9uIFwyMTVhZyBzZXQpLS4x
MSBFCih0byAxIHRoZW4gaXQgc2hvdWxkIGFzc3VtZSB0aGF0IG5vIG1vcmUgTENUIHBhY2sp
MTA1IDIxOC42IFEKKGV0cyB3aWxsIGJlIHNlbnQgdG8gdGhlIHNlc3Npb24uKS0uMTEgRShM
Q1QgcGFjayk4MyAyNDguMiBRCihldCBoZWFkZXIgbGVuZ3RoIFwoSERSX0xFTlwpOiA4IGJp
dHMpLS4xMSBFKExlbmd0aCBvZiB0aGUgTENUIHBhY2spMTA1CjI2NC44IFEoZXQgaGVhZGVy
IGluIHVuaXRzIG9mIDMyLWJpdCB3KS0uMTEgRShvcmRzIFwoZSktLjExIEUKKHhjbHVkaW5n
IElQIG9yIFVEUCBoZWFkZXJzXCkuKS0uMTY1IEUKKFRoaXMgXDIxNGVsZCBjYW4gYmUgdXNl
ZCBmb3IgZGlyZWN0IGFjY2VzcyB0byB0aGUgYmUpMTA1IDI3Ny44IFEKKGdpbm5pbmcgb2Yg
dGhlIExDVCBwYWNrKS0uMTY1IEUoZXQgcGF5bG9hZC4pLS4xMSBFCihDb2RlcG9pbnQgXChD
UFwpOiA4IGJpdHMpODMgMzA3LjQgUQooQW4gb3BhcXVlIGlkZW50aVwyMTRlciB3aGljaCBp
cyBwYXNzZWQgdG8gdGhlIHBheWxvYWQgZGVjb2RlciB0byBjb24pCjEwNSAzMjQgUSAuMzMg
LS4xNjUodmV5IGkpLS40NCBIKG5mb3JtYXRpb24gb24gdGhlKS4xNjUgRShjb2RlYyBiZWlu
ZyB1XApzZWQgZm9yIHRoZSBwYXlsb2FkLiBUaGUgbWFwcGluZyBiZXR3ZWVuIHRoZSBjb2Rl
cG9pbnQgYW5kIHRoZSBhY3R1YWwpCjEwNSAzMzcgUShjb2RlYyBpcyBkZVwyMTRuZWQgb24g
YSBwZXIgc2Vzc2lvbiBiYXNpcyBhbmQgY29tbXVuaWNhdGVkIG91XAp0LW9mLWJhbmQgYXMg
cGFydCBvZiB0aGUpMTA1IDM1MCBRKHNlc3Npb24gZGVzY3JpcHRpb24gaW5mb3JtYXRpb24u
KTEwNQozNjMgUShUaGUgdXNlIG9mIHRoZSBDUCBcMjE0ZWxkIGlzIHNpbWlsYXIgdG8gdGhl
IFApNS41IEUoYXlsb2FkIFQpLS4xNjUKRSh5cGUpLS44OCBFKFwoUFRcKSBcMjE0ZWxkIGlu
IFIpMTA1IDM3NiBRCihUUCBoZWFkZXJzIGFzIGRlc2NyaWJlZCBpbiBSRkMxODg5LiktLjY2
IEUKKENvbmdlc3Rpb24gQ29udHJvbCBJbmZvcm1hdGlvbiBcKENDSVwpOiAzMiBiaXRzKTgz
IDQwNS42IFEoVXNlZCB0byBjYXJcCnJ5IGNvbmdlc3Rpb24gY29udHJvbCBpbmZvcm1hdGlv
biwgZS5nLiBmb3IgdGhlIGNvbmdlc3Rpb24gY29udHJvbCBzcGVjXAppXDIxNGVkIGluKTEw
NSA0MjIuMiBRKFs5XSBvciBvdGhlciBjb25nZXN0aW9uIGNvbnRyb2wgc2NoZW1lcy4pMTA1
CjQzNS4yIFEoVGhpcyBcMjE0ZWxkIGlzIG9wYXF1ZSBmb3IgdGhlIHB1cnBvc2Ugb2YgdGhp
cyk1LjUgRQooc3BlY2lcMjE0Y2F0aW9uLikxMDUgNDQ4LjIgUSAtLjM4NShUcik4MyA0Nzcu
OCBTCihhbnNwb3J0IE9iamVjdCBJZGVudGlcMjE0ZXIgXChUKS4zODUgRQooT0lcKTogMzIs
IDY0IG9yIDEyOCBiaXRzIFwoT1BUSU9OKS0uMTk4IEUoQUxcKSktLjM4NSBFCihUaGlzIFwy
MTRlbGQgaW5kaWNhdGVzIHdoaWNoIG9iamVjdCB3aXRoaW4gdGhlIHNlc3Npb24gdGhpcyBM
Q1QgcGFjaykKMTA1IDQ5NC40IFEoZXQgcGVydGFpbnMgdG8uKS0uMTEgRSAtLjE2NShGbyk1
LjUgRyhyKS4xNjUgRSAtLjE2NShleCkxMDUKNTA3LjQgUyhhbXBsZSwgYSBzZW5kZXIgbWln
aHQgc2VuZCBhIG51bWJlciBvZiBcMjE0bGVzIGluIHRoZSBzYW1lIHNlc3NcCmlvbiwgdXNp
bmcgVCkuMTY1IEUoT0k9MCBmb3IgdGhlKS0uMTk4IEUoXDIxNHJzdCBcMjE0bGUsIFQpMTA1
IDUyMC40IFEKKE9JPTEgZm9yIHRoZSBzZWNvbmQgb25lLCBldGMuKS0uMTk4IEUoVGhlIG1h
cHBpbmcgb2YgVCk1LjUgRQooT0kgXDIxNGVsZCB2KS0uMTk4IEUoYWx1ZXMgdG8gb2JqZWN0
cyktLjI3NSBFCihNVVNUIGJlIGRvbmUgb3V0IG9mIGJhbmQuKTEwNSA1MzMuNCBRKFRoaXMg
XDIxNGVsZCBNVVNUIE5PKTEwNSA1NDYuNCBRCjIuNzUoVGIpLS40NCBHIDIuNzUoZXApLTIu
NzUgRyhyZXNlbnQgaWYgST0wLiktMi43NSBFCihUaGlzIFwyMTRlbGQgTVVTVCBiZSAzMiBi
aXRzIGlmIEk9MS4pMTA1IDU1OS40IFEKKFRoaXMgXDIxNGVsZCBNVVNUIGJlIDY0IGJpdHMg
aWYgST0yLikxMDUgNTcyLjQgUQooVGhpcyBcMjE0ZWxkIE1VU1QgYmUgMTI4IGJpdHMgaWYg
ST0zLikxMDUgNTg1LjQgUShTZW5kZXIgQ3VycmVudCBUKTgzCjYxNSBRKGltZSBcKFNDVFwp
OiAzMiBiaXRzIFwoT1BUSU9OKS0uMzg1IEUoQUxcKSktLjM4NSBFKFRoaXMgXDIxNGVsZCBy
XAplcHJlc2VudHMgdGhlIGN1cnJlbnQgY2xvY2sgYXQgdGhlIHNlbmRlciBhdCB0aGUgdGlt
ZSB0aGlzIHBhY2spMTA1CjYzMS42IFEoZXQgdyktLjExIEUoYXMgdHJhbnNtaXR0ZWQsKS0u
MTEgRShtZWFzdXJlZCBpbiB1bml0cyBvZiAxbXMgYW5kXAogY29tcHV0ZWQgbW9kdWxvIDJe
MzIgdW5pdHMgZnJvbSB0aGUgc3RhcnQgb2YgdGhlIHNlc3Npb24uKTEwNSA2NDQuNiBRCihU
aGlzIFwyMTRlbGQgTVVTVCBOTykxMDUgNjU3LjYgUSAyLjc1KFRiKS0uNDQgRyAyLjc1KGVw
KS0yLjc1IEcKKHJlc2VudCBpZiBTPTAgYW5kIE1VU1QgYmUgcHJlc2VudCBpZiBTPTEuKS0y
Ljc1IEUoRXhwZWN0ZWQgUmVzaWR1YWwgVCkKODMgNjg3LjIgUShpbWUgXChFUiktLjM4NSBF
KFRcKTogMzIgYml0cyBcKE9QVElPTiktLjY2IEUoQUxcKSktLjM4NSBFCihUaGlzIFwyMTRl
bGQgcmVwcmVzZW50cyB0aGUgc2VuZGVyIGUpMTA1IDcwMy44IFEKKHhwZWN0ZWQgcmVzaWR1
YWwgdHJhbnNtaXNzaW9uIHRpbWUgZm9yIHRoZSBjdXJyZW50KS0uMTY1IEUKKHNlc3Npb24s
IG1lYXN1cmVkIGluIHVuaXRzIG9mIDFtcy4pMTA1IDcxNi44IFEoTHVieS9HZW1tZWxsL1Yp
NzIgNzY5IFEKKGljaXNhbm8vUml6em8vSGFuZGxlKS0uNjYgRSh5L0NybyktLjE2NSBFIDEw
My42MDYod2Nyb2Z0IFNlY3Rpb24pLS4yNzUKRiAyLjc1KDMuMi4gW1ApMi43NSBGKGFnZSAx
MV0pLS4xNjUgRSBFUAolJVBhZ2U6IDEyIDEyCiUlQmVnaW5QYWdlU2V0dXAKQlAKJSVFbmRQ
YWdlU2V0dXAKL0YwIDExL1RpbWVzLVJvbWFuQDAgU0YoSU5URVJORVQpNzIgNDkgUSA3MS41
ODcoLURSQUZUIEV4cGlyZXM6KS0xLjAxMiBGCihKYW51YXJ5IDIwMDIpMi43NSBFKEp1bHkg
MjAwMSkxMjMuNzI2IEUoVGhpcyBcMjE0ZWxkIE1VU1QgTk8pMTA1IDg1IFEKMi43NShUYikt
LjQ0IEcgMi43NShlcCktMi43NSBHCihyZXNlbnQgaWYgRT0wIGFuZCBNVVNUIGJlIHByZXNl
bnQgaWYgRT0xLiktMi43NSBFL0YxIDExL1RpbWVzLUJvbGRAMCBTRgooMy4zLik3MiAxMjQg
US9GMiAxMy9UaW1lcy1Cb2xkQDAgU0YoSGVhZGVyKTUuNSBFKC1FeHRlbnNpb24gRmllbGRz
KQotLjQ4MSBFIEYwIDEuNzYgLS44OChUbyBhKTcyIDE0MC42IFQobGxvKS44OCBFIDIuNzUo
d2YpLS4yNzUgRwoob3IgYWRkaXRpb25hbCBoZWFkZXIgXDIxNGVsZHMgYW5kIHRvIGUpLTIu
NzUgRQooeHRlbmQgdGhlIHNpemUgb2Ygc29tZSBvZiB0aGUgcHJlZGVcMjE0bmVkIFwyMTRl
bGRzLCB0aGUpLS4xNjUgRQooTENUIHBhY2spNzIgMTUzLjYgUShldCBoZWFkZXIgY29udGFp
bnMgYW4gYWRkaXRpb25hbCBoZWFkZXIgXDIxNGVsZCBcClwyMTVhZywgIlgiLiBJZiAiWCIg
aXMgc2V0IHRvIDAgdGhlbiBubyktLjExIEUKKGFkZGl0aW9uYWwgaGVhZGVyIFwyMTRlbGRz
IGFyZSBpbmNsdWRlZCB3aXRoaW4gdGhlIExDVCBwYWNrKTcyIDE2Ni42IFEKKGV0IGhlYWRl
ciBiZSktLjExIEUoeW9uZCB0aGUgcHJlZGVcMjE0bmVkIFwyMTRlbGRzLiktLjE2NSBFCihX
aGVuIGFkZGl0aW9uYWwgaGVhZGVycyBiZSk3MiAxNzkuNiBRCih5b25kIHRoZSBwcmVkZVwy
MTRuZWQgXDIxNGVsZHMgYXJlIHVzZWQsIHRoZSB2KS0uMTY1IEUKKGFsdWUgb2YgIlgiIHdp
dGhpbiB0aGUgTENUKS0uMjc1IEUocGFjayk3MiAxOTIuNiBRCihldCBoZWFkZXIgTVVTVCBi
ZSBzZXQgdG8gMS4pLS4xMSBFCihFeGFtcGxlcyBvZiB1c2Ugb2YgSGVhZGVyIEV4dGVuc2lv
bnMgaW5jbHVkZTopNzIgMjE4LjYgUSAxMShvRSk3Ny41CjIzNS4yIFMoeHRlbmRlZC1zaXpl
IHYpLTExIEUoZXJzaW9uIG9mIGFscmVhZHkgZSktLjE2NSBFCih4aXN0aW5nIGhlYWRlciBc
MjE0ZWxkcy4pLS4xNjUgRSAxMShvUyk3Ny41IDI1MS44IFMoZW5kZXIgYW5kIFJlY2VpKS0x
MQpFIC0uMTY1KHZlKS0uMjc1IEcgMi43NShyYSkuMTY1IEcodXRoZW50aWNhdGlvbiBpbmZv
cm1hdGlvbi4pLTIuNzUgRQooSWYgcHJlc2VudCwgSGVhZGVyIEV4dGVuc2lvbnMgTVVTVCBi
ZSBwcm9jZXNzZWQgdG8gZW5zdXJlIHRoYXQgdGhlKTcyCjI4MS40IFEgMi43NSh5YSktLjE2
NSBHKHJlIHJlY29nbml6ZWQgYmVmb3JlKS0yLjc1IEUocGVyZm9ybWluZyBhbik3MgoyOTQu
NCBRIDIuNzUoeWMpLS4xNjUgRwoob25nZXN0aW9uIGNvbnRyb2wgcHJvY2VkdXJlIG9yIG90
aGVyd2lzZSBhY2NlcHRpbmcgYW4gTENUIHBhY2spLTIuNzUgRQooZXQuIExDVCBwYWNrKS0u
MTEgRShldHMpLS4xMSBFCih3aXRoIHVucmVjb2duaXNlZCBIZWFkZXIgRXh0ZW5zaW9ucyBN
VVNUIGJlIGRpc2NhcmRlZCBieSB0aGUgcmVjZWkpNzIKMzA3LjQgUSh2aW5nIGFnZW50LCBo
ZW5jZSB0aGUpLS4yNzUgRSAtLjE2NShleCk3MiAzMjAuNCBTCihwZWN0ZWQgdXNlIG9mIGUp
LjE2NSBFCih4dGVuc2lvbnMgU0hPVUxEIGJlIHNpZ25hbGVkIG91dC1vZi1iYW5kIGJlZm9y
ZSBzZXNzaW9uIHN0YXJ0dXAuKS0uMTY1CkUoVGhlcmUgYXJlIHR3KTcyIDM0Ni40IFEgMi43
NShvZiktLjExIEcKKG9ybWF0cyBmb3IgSGVhZGVyIEV4dGVuc2lvbiBcMjE0ZWxkcywgYXMg
ZGVwaWN0ZWQgYmVsbyktMi43NSBFIDEuNDMKLS43MTUody4gVCktLjI3NSBIKGhlIFwyMTRy
c3QgZm9ybWF0IGlzIHVzZWQgZm9yKS43MTUgRSAtLjI3NSh2YSk3MgozNTkuNCBTKHJpYWJs
ZS1sZW5ndGggZSkuMjc1IEUoeHRlbnNpb25zLCB3aXRoIEhlYWRlciBFeHRlbnNpb24gVCkt
LjE2NQpFKHlwZSBcKEhFVFwpIHYpLS44OCBFKGFsdWVzIGJldHdlZW4gMCBhbmQgNjMuIFRo
ZSktLjI3NSBFCihzZWNvbmQgZm9ybWF0IGlzIHVzZWQgZm9yIFwyMTR4KTcyIDM3Mi40IFEo
ZWQgbGVuZ3RoIFwob25lIHcpLS4xNjUgRQoob3JkXCkgZSktLjExIEUoeHRlbnNpb24sIHVz
aW5nIEhFVCB2KS0uMTY1IEUoYWx1ZXMgZnJvbSA2NCB0byAxMjcuKQotLjI3NSBFL0YzIDgv
Q291cmllckAwIFNGIDkxLjIoMDEyMyk4MS42IDQxMS40IFMgNC44CigwMTIzNDU2Nzg5MDEy
MzQ1Njc4OTAxMjM0NTY3ODkwMSk4MS42IDQyNC40IFMKKCstKy0rLSstKy0rLSstKy0rLSst
Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rKTc2LjgKNDM3
LjQgUSh8THwgSEVUIFwoPD02M1wpKTc2LjggNDUwLjQgUSAzMy42KHxIKTkuNiBHIDE5LjIo
RUwgfCktMzMuNiBGKHwpCjE0OC44IEUgMTQ0KCstKy0rLSstKy0rLSstKy0rLSstKy0rLSst
Ky0rLSstKyArKTc2LjggNDYzLjQgUiAzMDIuNCguLikKNzYuOCA0NzYuNCBTIDY3LjIoLkgp
NzYuOCA0ODkuNCBTKGVhZGVyIEV4dGVuc2lvbiBDb250ZW50IFwoSEVDXCkpLTY3LjIKRSgu
KTkxLjIgRQooKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r
LSstKy0rLSstKy0rLSstKy0rLSspNzYuOAo1MDIuNCBRIDkxLjIoMDEyMyk4MS42IDUyOC40
IFMgNC44KDAxMjM0NTY3ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAxKTgxLjYKNTQxLjQgUwoo
Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst
Ky0rLSstKy0rLSspNzYuOAo1NTQuNCBRKHxMfCBIRVQgXCg+PTY0XCkpNzYuOCA1NjcuNCBR
IDMzLjYofEgpOS42IEcKKGVhZGVyIEV4dGVuc2lvbiBDb250ZW50IFwoSEVDXCkpLTMzLjYg
RSh8KTQ4IEUKKCstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst
Ky0rLSstKy0rLSstKy0rLSstKy0rKTc2LjgKNTgwLjQgUS9GNCAxMC9UaW1lcy1Sb21hbkAw
IFNGKEZpZ3VyZSA1IC0gRik3MiA2MTkuNCBRCihvcm1hdCBvZiBhZGRpdGlvbmFsIGhlYWRl
cnMpLS4xNSBFIEYwKFRoZSBlKTcyIDY0OSBRCih4cGxhbmF0aW9uIG9mIGVhY2ggc3ViLVwy
MTRlbGQgaXMgdGhlIGZvbGxvKS0uMTY1IEUod2luZy4pLS4yNzUgRQooTGFzdCBIZWFkZXIg
RXh0ZW5zaW9uIFwoTFwpOiAxIGJpdCk4MyA2NzguNiBRKE1VU1QgYmUgc2V0IHRvIDEgaW4g
dGhlIFwKbGFzdCBIZWFkZXIgRXh0ZW5zaW9uIFwyMTRlbGQgcHJlc2VudCBpbiBhbiBMQ1Qg
cGFjaykxMDUgNjk1LjIgUQooZXQgaGVhZGVyKS0uMTEgRSgsKS0uNDQgRShNVVNUIGJlIHNl
dCB0byAwIGluIGFsbCB0aGUgb3RoZXJzLikxMDUgNzA4LjIKUShMdWJ5L0dlbW1lbGwvVik3
MiA3NjkgUShpY2lzYW5vL1JpenpvL0hhbmRsZSktLjY2IEUoeS9Dcm8pLS4xNjUgRQoxMDMu
NjA2KHdjcm9mdCBTZWN0aW9uKS0uMjc1IEYgMi43NSgzLjMuIFtQKTIuNzUgRihhZ2UgMTJd
KS0uMTY1IEUgRVAKJSVQYWdlOiAxMyAxMwolJUJlZ2luUGFnZVNldHVwCkJQCiUlRW5kUGFn
ZVNldHVwCi9GMCAxMS9UaW1lcy1Sb21hbkAwIFNGKElOVEVSTkVUKTcyIDQ5IFEgNzEuNTg3
KC1EUkFGVCBFeHBpcmVzOiktMS4wMTIgRgooSmFudWFyeSAyMDAyKTIuNzUgRShKdWx5IDIw
MDEpMTIzLjcyNiBFKEhlYWRlciBFeHRlbnNpb24gVCk4MyA4NSBRCih5cGUgXChIRVRcKTog
NyBiaXRzKS0uODggRShUaGUgdHlwZSBvZiB0aGUgSGVhZGVyIEV4dGVuc2lvbi4gVGhpcyBk
b2N1XAptZW50IGRlXDIxNG5lcyBhIG51bWJlciBvZiBwb3NzaWJsZSB0eXBlcy4pMTA1IDEw
MS42IFEKKEFkZGl0aW9uYWwgdHlwZXMgbWF5IGJlIGRlXDIxNG5lZCBpbiBmdXR1cmUgdikx
MDUgMTE0LjYgUQooZXJzaW9uIG9mIHRoaXMgc3BlY2lcMjE0Y2F0aW9uLiBIRVQgdiktLjE2
NSBFKGFsdWVzIGZyb20gMCktLjI3NSBFCih0byA2MyBhcmUgdXNlZCBmb3IgdikxMDUgMTI3
LjYgUQooYXJpYWJsZS1sZW5ndGggSGVhZGVyIEV4dGVuc2lvbnMuIEhFVCB2KS0uMjc1IEUK
KGFsdWVzIGZyb20gNjQgdG8gMTI3IGFyZSB1c2VkKS0uMjc1IEUoZm9yIFwyMTR4KTEwNSAx
NDAuNiBRCihlZC1sZW5ndGggSGVhZGVyIEV4dGVuc2lvbnMuKS0uMTY1IEUKKEhlYWRlciBF
eHRlbnNpb24gTGVuZ3RoIFwoSEVMXCk6IDggYml0cyk4MyAxNzAuMiBRCihUaGUgbGVuZ3Ro
IG9mIHRoZSB3aG9sZSBIZWFkZXIgRXh0ZW5zaW9uIFwyMTRlbGQsIGUpMTA1IDE4Ni44IFEK
KHhwcmVzc2VkIGluIG11bHRpcGxlcyBvZiAzMi1iaXQgdyktLjE2NSBFKG9yZHMuKS0uMTEg
RQooVGhpcyBcMjE0ZWxkIE1VU1QgYmUgcHJlc2VudCBmb3IgdikxMDUgMTk5LjggUShhcmlh
YmxlLWxlbmd0aCBlKS0uMjc1IEUKKHh0ZW5zaW9ucyBcKEhFVCBiZXR3ZWVuIDAgYW5kIDYz
XCkgYW5kKS0uMTY1IEUoTVVTVCBOTykxMDUgMjEyLjggUSAyLjc1CihUYiktLjQ0IEcgMi43
NShlcCktMi43NSBHKHJlc2VudCBmb3IgXDIxNHgpLTIuNzUgRShlZC1sZW5ndGggZSktLjE2
NSBFCih4dGVuc2lvbnMgXChIRVQgYmV0d2VlbiA2NCBhbmQgMTI3XCkuKS0uMTY1IEUKKEhl
YWRlciBFeHRlbnNpb24gQ29udGVudCBcKEhFQ1wpOiB2KTg1Ljc1IDI0Mi40IFEoYXJpYWJs
ZSBsZW5ndGgpLS4yNzUKRShUaGUgY29udGVudCBvZiB0aGUgSGVhZGVyIEV4dGVuc2lvbi4g
VGhlIGZvcm1hdCBvZiB0aGlzIHN1Yi1cMjE0ZWxkIGRcCmVwZW5kcyBvbiB0aGUgSGVhZGVy
KTEwNSAyNTkgUShFeHRlbnNpb24gdHlwZS4pMTA1IDI3MiBRIC0uMTY1KEZvKTUuNSBHCjIu
NzU8NzI4Yz4uMTY1IEcgLS4xNjUoeGUpLTIuNzUgRwooZC1sZW5ndGggSGVhZGVyIEV4dGVu
c2lvbnMsIHRoZSBIRUMgaXMgMjQgYml0cy4pLjE2NSBFIC0uMTY1KEZvKTUuNSBHCjIuNzUo
cnYpLjE2NSBHKGFyaWFibGUtKS0zLjAyNSBFCihsZW5ndGggSGVhZGVyIEV4dGVuc2lvbnMs
IHRoZSBIRUMgXDIxNGVsZCBoYXMgdikxMDUgMjg1IFEKKGFyaWFibGUgc2l6ZSwgYXMgc3Bl
Y2lcMjE0ZWQgYnkgdGhlIEhFTCBcMjE0ZWxkLiktLjI3NSBFKE5vdGUgdGhhdCB0aGVcCiBs
ZW5ndGggb2YgZWFjaCBIZWFkZXIgRXh0ZW5zaW9uIFwyMTRlbGQgTVVTVCBiZSBhIG11bHRp
cGxlIG9mIDMyIGJpdHMuKQoxMDUgMjk4IFEoQWxzbyk1LjUgRShub3RlIHRoYXQgdGhlIHRv
dGFsIHNpemUgb2YgdGhlIExDVCBwYWNrKTEwNSAzMTEgUQooZXQgaGVhZGVyKS0uMTEgRSAy
Ljc1KCxpKS0uNDQgRyhuY2x1ZGluZyBhbGwgSGVhZGVyIEV4dGVuc2lvbnMgYW5kIGFsbCkK
LTIuNzUgRShPUFRJT04pMTA1IDMyNCBRKEFMIGhlYWRlciBcMjE0ZWxkcywgY2Fubm90IGUp
LS4zODUgRQooeGNlZWQgMjU1IDMyLWJpdCB3KS0uMTY1IEUob3Jkcy4pLS4xMSBFKEFuIExD
VCBwYWNrKTcyIDM1My42IFEKKGV0IHdpdGggSGVhZGVyIEV4dGVuc2lvbnMgTVVTVCBOTykt
LjExIEUgMi43NShUaCktLjQ0IEcgLTIuNDc1IC0uMjIKKGF2IGUpLTIuNzUgSChzcGFjZSBi
ZXR3ZWVuIHRoZSBlbmQgb2YgdGhlIGxhc3QpMi45NyBFCihIZWFkZXIgRXh0ZW5zaW9uIGFu
ZCB0aGUgYmUpNzIgMzY2LjYgUShnaW5uaW5nIG9mIHRoZSBMQ1QgcGFjayktLjE2NSBFCihl
dCBwYXlsb2FkLiktLjExIEUoQWxsIHNlbmRlcnMgYW5kIHJlY2VpKTcyIDM5Mi42IFEgLS4x
NjUodmUpLS4yNzUgRwoocnMgb2YgTENUIHBhY2spLjE2NSBFKGV0cyBNVVNUIHN1cHBvcnQg
dGhlIEVYVF9OT1AgSGVhZGVyIEV4dGVuc2lvbi4pCi0uMTEgRShUaGUgZm9sbG8pNzIgNDE4
LjYgUSh3aW5nIEhlYWRlciBFeHRlbnNpb24gdHlwZXMgYXJlIGRlXDIxNG5lZDopCi0uMjc1
IEUgMTMuNjYyKEVYVF9OT1A9MCBOby1PcGVyYXRpb24pNzIgNDQ4LjIgUiAtLjE2NShleCky
Ljc1IEcKKHRlbnNpb24uKS4xNjUgRShUaGUgaW5mb3JtYXRpb24gcHJlc2VudCBpbiB0aGlz
IGUpMTQ5IDQ2MS4yIFEKKHh0ZW5zaW9uIFwyMTRlbGQgTVVTVCBiZSBpZ25vcmVkIGJ5IHJl
Y2VpKS0uMTY1IEUgLS4xNjUodmUpLS4yNzUgRyhycy4pCi4xNjUgRSAzLjg4MyhFWFRfQ0NJ
X1Y9MSBDb25nZXN0aW9uKTcyIDQ5MC44IFIoQ29udHJvbCBJbmZvcm1hdGlvbiBlKQoyLjc1
IEUoeHRlbnNpb24sIHYpLS4xNjUgRShhcmlhYmxlIGxlbmd0aC4pLS4yNzUgRShUaGlzIGUp
MTQ5IDUwMy44IFEKKHh0ZW5zaW9uIFwyMTRlbGQgZSktLjE2NSBFKHh0ZW5kcyB0aGUgQ0NJ
IFwyMTRlbGQgcHJlc2VudCBpbiB0aGUgXDIxNHgpCi0uMTY1IEUoZWQgcGFydCBvZiB0aGUg
aGVhZGVyKS0uMTY1IEUoLiktLjYwNSBFKEl0IGlzIHVzZWQgd2hlbiB0aGUgY29uXApnZXN0
aW9uIGNvbnRyb2wgaW5mb3JtYXRpb24gZG9lcyBub3QgXDIxNHQgaW4gdGhlIDMyLWJpdCBD
Q0kpMTQ5IDUxNi44IFEKKFwyMTRlbGQuIFdoZW4gdGhpcyBvcHRpb24gaXMgcHJlc2VudCwg
dGhlIGNvbmNhdGVuYXRpb24gb2YgdGhlIDMyLWJpdCBcCkNDSSBcMjE0ZWxkIGluKTE0OSA1
MjkuOCBRKHRoZSBcMjE0eCkxNDkgNTQyLjggUQooZWQgcGFydCBvZiB0aGUgaGVhZGVyIHRv
Z2V0aGVyIHdpdGggdGhlIHYpLS4xNjUgRShhcmlhYmxlIGxlbmd0aCB2KQotLjI3NSBFKGFs
dWUgcHJvKS0uMjc1IEUodmlkZWQgaW4pLS4xNjUgRQoodGhpcyBvcHRpb24gaXMgdXNlZCBh
cyB0aGUgY29uZ2VzdGlvbiBjb250cm9sIGluZm9ybWF0aW9uLikxNDkgNTU1LjggUQooVGhl
IGludGVycHJldGF0aW9uIG9mKTUuNSBFKHRoZSBkYXRhIGNvbnRhaW5lZCBpbiBFWFRfQ0NJ
X1YgTVVTVCBiZSBuZSkKMTQ5IDU2OC44IFEoZ290aWF0ZWQgb3V0LW9mLWJhbmQuKS0uMTY1
IEUoVGhlIHVzZSk1LjUgRQoob2YgRVhUX0NDSV9WIGFuZCBFWFRfQ0NJX0YgaXMgbXV0dWFs
bHkgZSkxNDkgNTgxLjggUSh4Y2x1c2kpLS4xNjUgRQotLjE2NSh2ZSktLjI3NSBHKC4pLjE2
NSBFKEVYVF9BKTcyIDYxMS40IFEgNS43MihVVEg9MiBBdXRoZW50aWNhdGlvbikKLS42MDUg
RiAtLjE2NShleCkyLjc1IEcodGVuc2lvbikuMTY1IEUKKEluZm9ybWF0aW9uIHVzZWQgdG8g
YXV0aGVudGljYXRlIHRoZSBzZW5kZXIgb2YgdGhlIExDVCBwYWNrKTE0OSA2MjQuNCBRCjIu
NzUoZXQuIElmKS0uMTEgRihwcmVzZW50LCB0aGUpMi43NSBFKGZvcm1hdCBvZiB0aGlzIEhl
YWRlciBFeHRlbnNpb24gXAphbmQgaXRzIHByb2Nlc3NpbmcgTVVTVCBiZSBjb21tdW5pY2F0
ZWQpMTQ5IDYzNy40IFEKKG91dC1vZi1iYW5kIGFzIHBhcnQgb2YgdGhlIHNlc3Npb24gZGVz
Y3JpcHRpb24uKTE0OSA2NTAuNCBRCihJdCBpcyBSRUNPTU1FTkRFRCB0aGF0IHNlbmRlcnMg
cHJvKTE0OSA2NjMuNCBRCih2aWRlIHNvbWUgZm9ybSBvZiBhdXRoZW50aWNhdGlvbiBvbiB0
aGUpLS4xNjUgRShMQ1QgcGFjaykxNDkgNjc2LjQgUQooZXRzIHRoZSktLjExIEUgMi43NSh5
dCktLjE2NSBHIDIuNzUocmFuc21pdC4gSWYpLTIuNzUgRihFWFRfQSkyLjc1IEUKKFVUSCBp
cyBwcmVzZW50LCB3aGF0ZSktLjYwNSBFIC0uMTY1KHZlKS0uMjc1IEcgMi43NShyYSkuMTY1
IEcKKHV0aGVudGljYXRpb24pLTIuNzUgRQooY2hlY2tzIHRoYXQgY2FuIGJlIHBlcmZvcm1l
ZCBpbW1lZGlhdGVseSB1cG9uIHJlY2VwdGlvbiBvZiB0aGUgcGFjaykxNDkKNjg5LjQgUShl
dCBNVVNUKS0uMTEgRShiZSBwZXJmb3JtZWQgYmVmb3JlIGFjY2VwdGluZyB0aGUgcGFjaykx
NDkgNzAyLjQKUShldCBhbmQgcGVyZm9ybWluZyBhbiktLjExIEUgMi43NSh5YyktLjE2NSBH
KG9uZ2VzdGlvbiktMi43NSBFCihjb250cm9sLXJlbGF0ZWQgYWN0aW9uIG9uIGl0LikxNDkg
NzE1LjQgUShMdWJ5L0dlbW1lbGwvVik3MiA3NjkgUQooaWNpc2Fuby9SaXp6by9IYW5kbGUp
LS42NiBFKHkvQ3JvKS0uMTY1IEUgMTAzLjYwNih3Y3JvZnQgU2VjdGlvbiktLjI3NQpGIDIu
NzUoMy4zLiBbUCkyLjc1IEYoYWdlIDEzXSktLjE2NSBFIEVQCiUlUGFnZTogMTQgMTQKJSVC
ZWdpblBhZ2VTZXR1cApCUAolJUVuZFBhZ2VTZXR1cAovRjAgMTEvVGltZXMtUm9tYW5AMCBT
RihJTlRFUk5FVCk3MiA0OSBRIDcxLjU4NygtRFJBRlQgRXhwaXJlczopLTEuMDEyIEYKKEph
bnVhcnkgMjAwMikyLjc1IEUoSnVseSAyMDAxKTEyMy43MjYgRQooU29tZSBhdXRoZW50aWNh
dGlvbiBzY2hlbWVzIGltcG9zZSBhIGRlbGF5IG9mIHNlKTE0OSA4NSBRIC0uMTY1KHZlKQot
LjI3NSBHKHJhbCBzZWNvbmRzIGJldHdlZW4gd2hlbikuMTY1IEUgMi43NShhcCkxNDkgOTgg
UyhhY2spLTIuNzUgRQooZXQgaXMgcmVjZWkpLS4xMSBFIC0uMTY1KHZlKS0uMjc1IEcgMi43
NShkYSkuMTY1IEcobmQgd2hlbiB0aGUgcGFjaykKLTIuNzUgRShldCBpcyBmdWxseSBhdXRo
ZW50aWNhdGVkLiktLjExIEUoQW4pNS41IEUgMi43NSh5YyktLjE2NSBHCihvbmdlc3Rpb24p
LTIuNzUgRShjb250cm9sIHJlbGF0ZWQgYWN0aW9uIHRoYXQgaXMgYXBwcm9wcmlhdGUgTVVT
VCBOTykKMTQ5IDExMSBRIDIuNzUoVGIpLS40NCBHIDIuNzUoZWQpLTIuNzUgRyhlbGF5ZWQg
YnkgYW4pLTIuNzUgRSAyLjc1KHlzKQotLjE2NSBHKHVjaCktMi43NSBFKGZ1bGwgYXV0aGVu
dGljYXRpb24gZGVsYXkpMTQ5IDEyNCBRKC4pLS43MTUgRQooRVhUX0NDSV9GPTY1KTcyIDE1
My42IFEoQ29uZ2VzdGlvbiBDb250cm9sIEluZm9ybWF0aW9uIGUpMTQ5IDE2Ni42IFEKKHh0
ZW5zaW9uLCBcMjE0eCktLjE2NSBFKGVkIGxlbmd0aC4pLS4xNjUgRShUaGlzIGUpMTQ5IDE3
OS42IFEKKHh0ZW5zaW9uIFwyMTRlbGQgZSktLjE2NSBFKHh0ZW5kcyB0aGUgQ0NJIFwyMTRl
bGQgcHJlc2VudCBpbiB0aGUgXDIxNHgpCi0uMTY1IEUoZWQgcGFydCBvZiB0aGUgaGVhZGVy
KS0uMTY1IEUoLiktLjYwNSBFKEl0IGlzIHVzZWQgd2hlbiB0aGUgY29uXApnZXN0aW9uIGNv
bnRyb2wgaW5mb3JtYXRpb24gZG9lcyBub3QgXDIxNHQgaW4gdGhlIDMyLWJpdCBDQ0kpMTQ5
IDE5Mi42IFEKKFwyMTRlbGQuIFdoZW4gdGhpcyBvcHRpb24gaXMgcHJlc2VudCwgdGhlIGNv
bmNhdGVuYXRpb24gb2YgdGhlIDMyLWJpdCBcCkNDSSBcMjE0ZWxkIGluKTE0OSAyMDUuNiBR
KHRoZSBcMjE0eCkxNDkgMjE4LjYgUQooZWQgcGFydCBvZiB0aGUgaGVhZGVyIHRvZ2V0aGVy
IHdpdGggdGhlIDI0LWJpdCBcMjE0eCktLjE2NSBFCihlZCBsZW5ndGggdiktLjE2NSBFKGFs
dWUgcHJvKS0uMjc1IEUodmlkZWQpLS4xNjUgRQooaW4gdGhpcyBvcHRpb24gaXMgdXNlZCBh
cyB0aGUgY29uZ2VzdGlvbiBjb250cm9sIGluZm9ybWF0aW9uLikxNDkgMjMxLjYKUShUaGUg
aW50ZXJwcmV0YXRpb24pNS41IEUKKG9mIHRoZSBkYXRhIGNvbnRhaW5lZCBpbiBFWFRfQ0NJ
X0YgTVVTVCBiZSBuZSkxNDkgMjQ0LjYgUQooZ290aWF0ZWQgb3V0LW9mLWJhbmQuKS0uMTY1
IEUoVGhlKTUuNSBFCih1c2Ugb2YgRVhUX0NDSV9WIGFuZCBFWFRfQ0NJX0YgaXMgbXV0dWFs
bHkgZSkxNDkgMjU3LjYgUSh4Y2x1c2kpLS4xNjUgRQotLjE2NSh2ZSktLjI3NSBHKC4pLjE2
NSBFL0YxIDExL1RpbWVzLUJvbGRAMCBTRig0Lik3MiAyOTYuNiBRL0YyIDE0Ci9UaW1lcy1C
b2xkQDAgU0YoUHIpNS41IEUob2NlZHVyKS0uMjUyIEUoZXMpLS4yNTIgRSBGMSg0LjEuKTcy
IDMzNS42IFEKL0YzIDEzL1RpbWVzLUJvbGRAMCBTRihTZW5kZXIgT3BlcmF0aW9uKTUuNSBF
IEYwCihCZWZvcmUgYSBzZXNzaW9uIHN0YXJ0cywgYW4gTENUIHNlbmRlciBNVVNUIG1hayk3
MiAzNTIuMiBRIDIuNzUoZWEpLS4xMQpHIC0uMjc1KHZhKS0yLjk3IEcoaWxhYmxlIGFsbCBh
cHBsaWNhYmxlIGluZm9ybWF0aW9uIHJlKS4yNzUgRSAtLjA1NShnYSkKLS4xNjUgRyhyZGlu
ZykuMDU1IEUodGhlIHNlc3Npb24uKTcyIDM2NS4yIFEKKFRoaXMgaW5mb3JtYXRpb24gY291
bGQgaW5jbHVkZSwgYik1LjUgRSh1dCBpcyBub3QgbGltaXRlZCB0bzopLS4yMiBFIDExCihv
VCk3Ny41IDM4MS44IFMoaGUgbnVtYmVyIG9mIExDVCBjaGFubmVsczspLTExIEUgMTEob1Qp
NzcuNSAzOTguNCBTCihoZSBhZGRyZXNzZXMsIHBvcnQgbnVtYmVycyBhbmQgZGF0YSByYXRl
cyB1c2VkIGZvciBlYWNoIExDVCBjaGFubmVsOykKLTExIEUgMTEob1QpNzcuNSA0MTUgUyho
ZSBmb3JtYXQgb2YgdGhlIHBheWxvYWQuIEYpLTExIEUob3IgZSktLjE2NSBFCih4YW1wbGUs
IHRoZSBwYXlsb2FkIGNvdWxkIGNvbnRhaW4gb3RoZXIgcHJvdG9jb2wgaGVhZGVycyktLjE2
NSBFCihzdWNoIGFzIGFuIEZFQyBoZWFkZXIpOTQgNDI4IFEgNS41KC5UKS0uNjA1IEcoaGVu
IGZvciBlKS01LjUgRQooeGFtcGxlIHRoZSBpbmZvcm1hdGlvbiBjb3VsZCBpbmNsdWRlIHRo
ZSBtYXBwaW5nIG9mKS0uMTY1IEUKKGNvZGVwb2ludHMgdXNlZCBpbiB0aGUgc2Vzc2lvbiB0
byBGRUMgY29kZWMgdHlwZXMgYW5kIHBhcmFtZXRlcnM7KTk0CjQ0MSBRIDExKG9UKTc3LjUg
NDU3LjYgUyhoZSBjb25nZXN0aW9uIGNvbnRyb2wgc2NoZW1lIGJlaW5nIHVzZWQ7KS0xMSBF
CjExKG9UKTc3LjUgNDc0LjIgUwooaGUgcG9zc2libGUgSGVhZGVyIEV4dGVuc2lvbnMgdGhh
dCBjb3VsZCBiZSB1c2VkIGluIHRoZSBzZXNzaW9uOyktMTEgRQoxMShvVCk3Ny41IDQ5MC44
IFMoaGUgbWFwcGluZyBvZiBUKS0xMSBFKE9JIHYpLS4xOTggRQooYWx1ZVwoc1wpIHRvIG9i
amVjdHMgZm9yIHRoZSBzZXNzaW9uOyktLjI3NSBFIDExKG9UKTc3LjUgNTA3LjQgUwooaGUg
YXV0aGVudGljYXRpb24gc2NoZW1lIGJlaW5nIHVzZWQsIGFuZCBhbGwgcmVsZSktMTEgRSAt
LjI3NSh2YSktLjI3NQpHKG50IGluZm9ybWF0aW9uIHdoaWNoIGlzIG5lY2Vzc2FyeSBmb3Ip
LjI3NSBFCihzZW5kZXIgYXV0aGVudGljYXRpb24gcHVycG9zZXM7KTk0IDUyMC40IFEoVGhl
IHNlc3Npb24gZGVzY3JpcHRpb24gY291XApsZCBiZSBpbiBhIGZvcm0gc3VjaCBhcyBTRFAg
YXMgZGVcMjE0bmVkIGluIFJGQzIzMjcsIFhNTCBtZXRhZGF0YSwpNzIKNTUwIFEoSFRUUC9N
aW1lIGhlYWRlcnMsIGV0Yy4gSXQgbWlnaHQgYmUgY2FycmllZCBpbiBhIHNlc3Npb24gYW5u
b3VuY2VcCm1lbnQgcHJvdG9jb2wgc3VjaCBhcyBTQVApNzIgNTYzIFEoWzRdLCBvYnRhaW5l
ZCB1c2luZyBSQ0NQIHNlc3Npb24gY29uXAp0cm9sIGFzIGRlc2NyaWJlZCBpbiBbOF0sIGxv
Y2F0ZWQgb24gYSBXKTcyIDU3NiBRKGViIHBhZ2Ugd2l0aCktLjg4IEUKKHNjaGVkdWxpbmcg
aW5mb3JtYXRpb24sIG9yIGNvbik3MiA1ODkgUSAtLjE2NSh2ZXkpLS40NCBHCihlZCB2aWEg
RS1tYWlsIG9yIG90aGVyIG91dCBvZiBiYW5kIG1ldGhvZHMuKS4xNjUgRShEaXNjdXNzaW9u
IG9mKTUuNSBFCihzZXNzaW9uIGRlc2NyaXB0aW9uIGZvcm1hdCwgYW5kIGRpc3RyaWIpNzIg
NjAyIFEKKHV0aW9uIG9mIHNlc3Npb24gZGVzY3JpcHRpb25zIGlzIGJlKS0uMjIgRSh5b25k
IHRoZSBzY29wZSBvZiB0aGlzKS0uMTY1CkUoZG9jdW1lbnQuKTcyIDYxNSBRIC0uNDQoV2kp
NzIgNjQxIFMKKHRoaW4gYW4gTENUIHNlc3Npb24sIGFuIExDVCBzZW5kZXIgdHJhbnNtaXRz
IGEgc2VxdWVuY2Ugb2YgTENUIHBhY2spLjQ0CkUoZXRzIGVhY2ggY29udGFpbmluZyBhKS0u
MTEgRShwYXlsb2FkIGVuY29kZWQgYWNjb3JkaW5nIHRvIG9uZSBvZiB0aGUgXApjb2RlY3Mg
ZGVcMjE0bmVkIGluIHRoZSBzZXNzaW9uIGRlc2NyaXB0aW9uLik3MiA2NTQgUShMQ1QgcGFj
ayk1LjUgRQooZXRzKS0uMTEgRShhcmUgc2VudCBvKTcyIDY2NyBRIC0uMTY1KHZlKS0uMTY1
IEcgMi43NShybykuMTY1IEcKKG5lIG9yIG1vcmUgTENUIGNoYW5uZWxzIHdoaWNoIHRvZ2V0
aGVyIGNvbnN0aXR1dGUgYSBzZXNzaW9uLiktMi43NSBFCi0uMzg1KFRyKTUuNSBHKGFuc21p
c3Npb24gcmF0ZXMpLjM4NSBFKE1BKTcyIDY4MCBRIDIuNzUoWWIpLTEuMTU1IEcgMi43NQoo
ZWQpLTIuNzUgRyhpZiktMi43NSBFKGZlcmVudCBpbiBkaWYpLS4yNzUgRQooZmVyZW50IGNo
YW5uZWxzLiBUaGlzIGRvY3VtZW50IGRvZXMgbm90IHNwZWNpZnkgdGhlIExDVCBwYWNrKS0u
Mjc1IEUKKGV0IHBheWxvYWQsKS0uMTEgRShub3IgdGhlIG9yZGVyIGluIHdoaWNoIExDVCBw
YWNrKTcyIDY5MyBRCihldHMgYXJlIHRyYW5zbWl0dGVkLCBub3IgdGhlIG9yKS0uMTEgRSAt
LjA1NShnYSktLjE5OCBHCihuaXphdGlvbiBvZiBhIHNlc3Npb24gaW50bykuMDU1IEUKKG11
bHRpcGxlIGNoYW5uZWxzLiBBbHRob3VnaCB0aGVzZSBpc3N1ZXMgYWYpNzIgNzA2IFEoZmVj
dCB0aGUgZWYpLS4yNzUKRShcMjE0Y2llbmMpLS4yNzUgRSAyLjc1KHlvKS0uMTY1IEcgMi43
NShmdCktMi43NSBHKGhlIHByb3RvY29sLCB0aGUpCi0yLjc1IEUgMi43NSh5ZCktLjE2NSBH
IDIuNzUob24pLTIuNzUgRyhvdCBhZiktMi43NSBFKGZlY3QpLS4yNzUgRQoodGhlIGNvcnJl
Y3RuZXNzIG5vciB0aGUgaW50ZXIpNzIgNzE5IFEKKC1vcGVyYWJpbGl0eSBiZXR3ZWVuIHNl
bmRlcnMgYW5kIHJlY2VpKS0uMjIgRSAtLjE2NSh2ZSktLjI3NSBHKHJzLikuMTY1CkUoTHVi
eS9HZW1tZWxsL1YpNzIgNzY5IFEoaWNpc2Fuby9SaXp6by9IYW5kbGUpLS42NiBFKHkvQ3Jv
KS0uMTY1IEUKMTAzLjYwNih3Y3JvZnQgU2VjdGlvbiktLjI3NSBGIDIuNzUoNC4xLiBbUCky
Ljc1IEYoYWdlIDE0XSktLjE2NSBFIEVQCiUlUGFnZTogMTUgMTUKJSVCZWdpblBhZ2VTZXR1
cApCUAolJUVuZFBhZ2VTZXR1cAovRjAgMTEvVGltZXMtUm9tYW5AMCBTRihJTlRFUk5FVCk3
MiA0OSBRIDcxLjU4NygtRFJBRlQgRXhwaXJlczopLTEuMDEyIEYKKEphbnVhcnkgMjAwMiky
Ljc1IEUoSnVseSAyMDAxKTEyMy43MjYgRQooTXVsdGlwbGUgb2JqZWN0cyBjYW4gYmUgY2Fy
cmllZCB3aXRoaW4gdGhlIHNhbWUgTENUIHNlc3Npb24uKTcyIDg1IFEKKEluIHRoaXMgY2Fz
ZSwgZWFjaCBvYmplY3QgaXMpNS41IEUoaWRlbnRpXDIxNGVkIGJ5IGEgdW5pcXVlIFQpNzIg
OTggUQoyLjc1KE9JLiBPYmplY3RzKS0uMTk4IEYoTUEpMi43NSBFIDIuNzUoWWIpLTEuMTU1
IEcgMi43NShldCktMi43NSBHCihyYW5zbWl0dGVkIHNlcXVlbnRpYWxseSktMi43NSBFIDIu
NzUoLG8pLS43MTUgRyAyLjc1KHJ0KS0yLjc1IEcoaGUpCi0yLjc1IEUgMi43NSh5TSktLjE2
NSBHIDIuMzEgLTEuMTU1KEFZIGIpLTIuNzUgSChlKTEuMTU1IEUKKHRyYW5zbWl0dGVkIGNv
bmN1cnJlbnRseSk3MiAxMTEgUSguKS0uNzE1IEUgLS44OChUeSk3MiAxMzcgUyhwaWNhbGx5
KQouODggRSAyLjc1KCx0KS0uNzE1IEcoaGUgc2VuZGVyXChzXCkgY29udGludWVzIHRvIHNl
bmQgTENUIHBhY2spLTIuNzUgRQooZXRzIGluIGEgc2Vzc2lvbiB1bnRpbCB0aGUgdHJhbnNt
aXNzaW9uIGlzKS0uMTEgRShjb25zaWRlcmVkIGNvbXBsZXRlLikKNzIgMTUwIFEoVGhlIHRy
YW5zbWlzc2lvbiBNQSk1LjUgRSAyLjc1KFliKS0xLjE1NSBHIDIuNzUoZWMpLTIuNzUgRwoo
b25zaWRlcmVkIGNvbXBsZXRlIHdoZW4gc29tZSB0aW1lIGhhcyktMi43NSBFIC0uMTY1KGV4
KTcyIDE2MyBTCihwaXJlZCwgYSBjZXJ0YWluIG51bWJlciBvZiBwYWNrKS4xNjUgRShldHMg
aGEpLS4xMSBFIC4zMyAtLjE2NSh2ZSBiKQotLjIyIEgoZWVuIHNlbnQsIG9yIHNvbWUgb3V0
IG9mIGJhbmQgc2lnbmFsIFwocG9zc2libHkgZnJvbSBhKS4xNjUgRQooaGlnaGVyIGxlKTcy
IDE3NiBRIC0uMTY1KHZlKS0uMjc1IEcgMi43NShscCkuMTY1IEcKKHJvdG9jb2xcKSBoYXMg
aW5kaWNhdGVkIGNvbXBsZXRpb24gYnkgYSBzdWYpLTIuNzUgRQooXDIxNGNpZW50IG51bWJl
ciBvZiByZWNlaSktLjI3NSBFIC0uMTY1KHZlKS0uMjc1IEcocnMuKS4xNjUgRShUaGUgc3Bl
Y1wKaVwyMTRjYXRpb24gb2YgdGhlIHByb2Nlc3Npbmcgb2YgdGhlIHBheWxvYWQgY2Fycmll
ZCBpbiBMQ1QgcGFjayk3MiAyMDIKUShldHMgaXMgYmUpLS4xMSBFKHlvbmQgdGhlIHNjb3Bl
IG9mKS0uMTY1IEUodGhpcyBkb2N1bWVudC4pNzIgMjE1IFEKKExDVCB3aWxsIGFjdCBhcyBh
IHRyYW5zcG9ydCBsYXllciBhbmQgY29uKTUuNSBFIC4zMyAtLjE2NSh2ZXkgcCktLjQ0IEgK
KGF5bG9hZCBhbmQgYXNzb2NpYXRlZCBpbmZvcm1hdGlvbikuMTY1IEUoXChDb2RlcG9pbnQg
YW5kIFQpNzIgMjI4IFEKKE9JXCkgdG8gdGhlIHJlY2VpKS0uMTk4IEUgLS4xNjUodmUpLS4y
NzUgRyhycyBhbmQgYW4pLjE2NSBFIDIuNzUoeWMpCi0uMTY1IEcob21wbGV0ZSBwcm90b2Nv
bCB1c2luZyBMQ1Qgd2lsbCBpbXBsZW1lbnQpLTIuNzUgRQooY29uZ2VzdGlvbiBjb250cm9s
IC4pNzIgMjQxIFEgLS4xNjUoRm8pNzIgMjY3IFMgMi43NShydCkuMTY1IEcKKGhlIHJlYXNv
bnMgbWVudGlvbmVkIGFibyktMi43NSBFIC0uMTY1KHZlKS0uMTY1IEcgMi43NSgsdCkuMTY1
IEcKKGhpcyBkb2N1bWVudCBkb2VzIG5vdCBwb3NlIGFuKS0yLjc1IEUgMi43NSh5ciktLjE2
NSBHCihlc3RyaWN0aW9uIG9uIExDVCBwYWNrKS0yLjc1IEUoZXQpLS4xMSBFKHNpemVzLiBI
byk3MiAyODAgUSh3ZSktLjI3NSBFCi0uMTY1KHZlKS0uMjc1IEcgLjg4IC0uNDQociwgbiku
MTY1IEgoZXR3KS40NCBFKG9yayBlZiktLjExIEUoXDIxNGNpZW5jKQotLjI3NSBFIDIuNzUo
eWMpLS4xNjUgRwoob25zaWRlcmF0aW9ucyByZWNvbW1lbmQgdGhhdCB0aGUgc2VuZGVyIHVz
ZXMgYXMgbGFyKS0yLjc1IEUoZ2UgYXMpLS4xOTgKRShwb3NzaWJsZSBwYXlsb2FkIHNpemUs
IGIpNzIgMjkzIFEodXQgaW4gc3VjaCBhIHcpLS4yMiBFCihheSB0aGF0IExDVCBwYWNrKS0u
MTEgRShldHMgZG8gbm90IGUpLS4xMSBFKHhjZWVkIHRoZSBuZXR3KS0uMTY1IEUKKG9yaycp
LS4xMSBFIDIuNzUoc20pLS42MDUgRyhheGltdW0pLTIuNzUgRQoodHJhbnNtaXNzaW9uIHVu
aXQgc2l6ZSBcKE1UVVwpLCBvciBmcmFnbWVudGF0aW9uIGNvdXBsZWQgd2l0aCBwYWNrKTcy
CjMwNiBRKGV0IGxvc3MgbWlnaHQgaW50cm9kdWNlIHNlKS0uMTEgRSAtLjE2NSh2ZSktLjI3
NSBHKHJlKS4xNjUgRShpbmVmKQo3MiAzMTkgUShcMjE0Y2llbmMpLS4yNzUgRSAyLjc1KHlp
KS0uMTY1IEcgMi43NShudCktMi43NSBHCihoZSB0cmFuc21pc3Npb24uKS0yLjc1IEUoSXQg
aXMgYWxzbyBSRUNPTU1FTkRFRCB0aGF0IGFsbCBMQ1QgcGFjayk3MgozNDUgUShldHMgaGEp
LS4xMSBFIC4zMyAtLjE2NSh2ZSB0KS0uMjIgSChoZSBzYW1lIG9yIHYpLjE2NSBFCihlcnkg
c2ltaWxhciBzaXplcywgYXMgdGhpcyBjYW4pLS4xNjUgRShoYSk3MiAzNTggUSAuMzMgLS4x
NjUodmUgYSBzKQotLjIyIEggLTIuMzY1IC0uMjc1KGV2IGUpLjE2NSBIKHJlIGltcGFjdCBv
biB0aGUgZWYpLjI3NSBFKGZlY3RpKS0uMjc1IEUKLS4xNjUodmUpLS4yNzUgRyhuZXNzIG9m
IGNvbmdlc3Rpb24gY29udHJvbCBzY2hlbWVzIHN1Y2ggYXMgdGhlIG9uZXMpCi4xNjUgRShk
ZXNjcmliZWQgaW4gWzldLik3MiAzNzEgUSAyLjc1KEFzKTUuNSBHKGVuZGVyIG9mIExDVCBw
YWNrKS0yLjc1CkUoZXRzIE1VU1QgaW1wbGVtZW50IHRoZSBzZW5kZXIpLS4xMSBFKC1zaWRl
IHBhcnQgb2Ygb25lIG9mIHRoZSktLjIyIEUoXApjb25nZXN0aW9uIGNvbnRyb2wgc2NoZW1l
cyB0aGF0IGlzIGluIGFjY29yZGFuY2Ugd2l0aCBSRkMyMzU3LCBhbmQgdGhlIFwKY29ycmVz
cG9uZGluZyByZWNlaSk3MiAzODQgUSAtLjE2NSh2ZSktLjI3NSBHKHIpLjE2NSBFKGNvbmdl
c3Rpb24gY29udHJcCm9sIHNjaGVtZSBNVVNUIGJlIGNvbW11bmljYXRlZCBvdXQgb2YgYmFu
ZCBhbmQgaW1wbGVtZW50ZWQgYnkgYW4pNzIgMzk3ClEoeSktLjE2NSBFKHJlY2VpKTcyIDQx
MCBRIC0uMTY1KHZlKS0uMjc1IEcKKHJzIHBhcnRpY2lwYXRpbmcgaW4gdGhlIHNlc3Npb24u
KS4xNjUgRS9GMSAxMS9UaW1lcy1Cb2xkQDAgU0YoNC4yLik3Mgo0NDkgUS9GMiAxMy9UaW1l
cy1Cb2xkQDAgU0YoUmVjZWkpNS41IEUgLS4xMyh2ZSktLjEzIEcgMy4yNShyTykuMTMgRwoo
cGVyYXRpb24pLTMuMjUgRSBGMChSZWNlaSk3MiA0NjUuNiBRIC0uMTY1KHZlKS0uMjc1IEcK
KHJzIGNhbiBvcGVyYXRlIGRpZikuMTY1IEUoZmVyZW50bHkgZGVwZW5kaW5nIG9uIHRoZSBk
ZWxpKS0uMjc1IEUgLS4xNjUKKHZlKS0uMjc1IEcocnkgc2VydmljZSBtb2RlbC4pLjE2NSBF
IC0uMTY1KEZvKTUuNSBHIDIuNzUocmUpLjE2NSBHCih4YW1wbGUsIGZvciBhbiktMi45MTUg
RShvbiBkZW1hbmQgc2VydmljZSBtb2RlbCByZWNlaSk3MiA0NzguNiBRIC0uMTY1Cih2ZSkt
LjI3NSBHKHJzIE1BKS4xNjUgRSAyLjc1KFlqKS0xLjE1NSBHCihvaW4gYSBzZXNzaW9uLCBv
YnRhaW4gdGhlIG5lY2Vzc2FyeSBlbmNvZGluZyBzeW1ib2xzKS0yLjc1IEUKKHRvIHJlcHJv
ZHVjZSB0aGUgb2JqZWN0LCBhbmQgdGhlbiBsZWEpNzIgNDkxLjYgUSAuMzMgLS4xNjUodmUg
dCktLjIyIEgKKGhlIHNlc3Npb24uKS4xNjUgRShBcyBhbm90aGVyIGUpNS41IEUoeGFtcGxl
LCBmb3IgYSBzdHJlYW1pbmcgc2VydmljZSkKLS4xNjUgRShtb2RlbCBhIHJlY2VpKTcyIDUw
NC42IFEgLS4xNjUodmUpLS4yNzUgRyAyLjc1KHJNKS4xNjUgRyAyLjMxCi0xLjE1NShBWSBi
KS0yLjc1IEggMi43NShlYykxLjE1NSBHCihvbnRpbnVvdXNseSBqb2luZWQgdG8gYSBzZXQg
b2YgTENUIGNoYW5uZWxzIHRvIGRvKS0yLjc1IEUKKHdubG9hZCBhbGwgb2JqZWN0cyBpbikt
LjI3NSBFIDIuNzUoYXMpNzIgNTE3LjYgUyhlc3Npb24uKS0yLjc1IEUgMS43NgotLjg4KFRv
IGIpNzIgNTQzLjYgVCAyLjc1KGVhKS44OCBHCihibGUgdG8gcGFydGljaXBhdGUgaW4gYSBz
ZXNzaW9uLCBhIHJlY2VpKS0yLjc1IEUgLS4xNjUodmUpLS4yNzUgRyAyLjc1CihyTSkuMTY1
IEcoVVNUIFwyMTRyc3Qgb2J0YWluIHRoZSByZWxlKS0yLjc1IEUgLS4yNzUodmEpLS4yNzUg
RwoobnQgc2Vzc2lvbiBkZXNjcmlwdGlvbikuMjc1IEUoaW5mb3JtYXRpb24gYXMgbGlzdGVk
IGluIFNlY3Rpb24gNC4xLik3Mgo1NTYuNiBRIDEuNzYgLS44OChUbyBiKTcyIDU4Ni4yIFQg
Mi43NShlYSkuODggRwooYmxlIHRvIHBhcnRpY2lwYXRlIGluIGEgc2Vzc2lvbiwgYSByZWNl
aSktMi43NSBFIC0uMTY1KHZlKS0uMjc1IEcgMi43NQoock0pLjE2NSBHKFVTVCBpbXBsZW1l
bnQgdGhlIGNvbmdlc3Rpb24gY29udHJvbCBwcm90b2NvbCktMi43NSBFCihzcGVjaVwyMTRl
ZCBpbiB0aGUgc2Vzc2lvbiBkZXNjcmlwdGlvbi4gSWYgYSByZWNlaSk3MiA1OTkuMiBRIC0u
MTY1KHZlKQotLjI3NSBHIDIuNzUocmkpLjE2NSBHIDIuNzUoc24pLTIuNzUgRwoob3QgYWJs
ZSB0byBpbXBsZW1lbnQgdGhlIGNvbmdlc3Rpb24gY29udHJvbCktMi43NSBFCihwcm90b2Nv
bCB1c2VkIGluIHRoZSBzZXNzaW9uLCBpdCBNVVNUIE5PKTcyIDYxMi4yIFEgMi43NShUaikt
LjQ0IEcKKG9pbiB0aGUgc2Vzc2lvbi4pLTIuNzUgRQooSWYgc2VuZGVyIGF1dGhlbnRpY2F0
aW9uIGluZm9ybWF0aW9uIGlzIHByZXNlbnQgaW4gYW4gTENUIHBhY2spNzIgNjM4LjIKUShl
dCBoZWFkZXIpLS4xMSBFIDIuNzUoLGkpLS40NCBHIDIuNzUodE0pLTIuNzUgRyhVU1QgYmUg
dXNlZCBhcyktMi43NSBFCihzcGVjaVwyMTRlZCBpbiBTZWN0aW9uIDMuMy4gSWYgYSByZWNl
aSk3MiA2NTEuMiBRIC0uMTY1KHZlKS0uMjc1IEcgMi43NQoocmkpLjE2NSBHIDIuNzUoc3Up
LTIuNzUgRwoobmFibGUgdG8gaW1wbGVtZW50IHRoZSBhdXRoZW50aWNhdGlvbiBtZWNoYW5p
c20gdXNlZCktMi43NSBFCihieSB0aGUgc2Vzc2lvbiwgaXQgTVVTVCBOTyk3MiA2NjQuMiBR
IDIuNzUoVGopLS40NCBHKG9pbiB0aGUgc2Vzc2lvbi4pCi0yLjc1IEUgMS43NiAtLjg4KFRv
IGIpNzIgNjkwLjIgVCAyLjc1KGVhKS44OCBHKGJsZSB0byBiZSBhIHJlY2VpKS0yLjc1CkUg
LS4xNjUodmUpLS4yNzUgRyAyLjc1KHJpKS4xNjUgRyAyLjc1KG5hcyktMi43NSBHKGVzc2lv
biwgdGhlIHJlY2VpKQotMi43NSBFIC0uMTY1KHZlKS0uMjc1IEcgMi43NShyTSkuMTY1IEcK
KFVTVCBiZSBhYmxlIHRvIHByb2Nlc3MgdGhlIExDVCBwYWNrKS0yLjc1IEUoZXQpLS4xMSBF
KGhlYWRlcik3MiA3MDMuMiBRCjUuNSguVCktLjYwNSBHKGhlIHJlY2VpKS01LjUgRSAtLjE2
NSh2ZSktLjI3NSBHIDIuNzUock0pLjE2NSBHCihVU1QgYmUgYWJsZSB0byBkaXNjYXJkLCBm
b3J3KS0yLjc1IEUKKGFyZCwgc3RvcmUgb3IgcHJvY2VzcyB0aGUgTENUIHBhY2spLS4xMSBF
KGV0IHBheWxvYWQuKS0uMTEgRQooSWYgYSByZWNlaSk3MiA3MTYuMiBRIC0uMTY1KHZlKS0u
Mjc1IEcgMi43NShyaSkuMTY1IEcgMi43NShzbiktMi43NSBHCihvdCBhYmxlIHRvIHByb2Nl
c3MgYSBMQ1QgcGFjayktMi43NSBFKGV0IGhlYWRlciktLjExIEUgMi43NSgsaSktLjQ0IEcK
Mi43NSh0TSktMi43NSBHKFVTVCBlaXRoZXIgZHJvcCBmcm9tIHRoZSBzZXNzaW9uLCBvcikt
Mi43NSBFCihMdWJ5L0dlbW1lbGwvVik3MiA3NjkgUShpY2lzYW5vL1JpenpvL0hhbmRsZSkt
LjY2IEUoeS9Dcm8pLS4xNjUgRQoxMDMuNjA2KHdjcm9mdCBTZWN0aW9uKS0uMjc1IEYgMi43
NSg0LjIuIFtQKTIuNzUgRihhZ2UgMTVdKS0uMTY1IEUgRVAKJSVQYWdlOiAxNiAxNgolJUJl
Z2luUGFnZVNldHVwCkJQCiUlRW5kUGFnZVNldHVwCi9GMCAxMS9UaW1lcy1Sb21hbkAwIFNG
KElOVEVSTkVUKTcyIDQ5IFEgNzEuNTg3KC1EUkFGVCBFeHBpcmVzOiktMS4wMTIgRgooSmFu
dWFyeSAyMDAyKTIuNzUgRShKdWx5IDIwMDEpMTIzLjcyNiBFKHJlZHVjZSB0aGUgcmVjZWkp
NzIgODUgUSAuMzMKLS4xNjUodmUgYiktLjI3NSBIKGFuZHdpZHRoIHRvIHRoZSBtaW5pbXVt
IHYpLjE2NSBFKGFsdWUgYWxsbyktLjI3NSBFCih3ZWQgYnkgdGhlIGNvbmdlc3Rpb24gY29u
dHJvbCBwcm90b2NvbCktLjI3NSBFKGJlaW5nIHVzZWQuKTcyIDk4IFEKKFdoZW4gdGhlIHNl
c3Npb24gaXMgdHJhbnNtaXR0ZWQgb24gbXVsdGlwbGUgTENUIGNoYW5uZWxzLCByZWNlaSk3
MiAxMjQKUSAtLjE2NSh2ZSktLjI3NSBHKHJzIE1VU1QgZG8gaXQgYWNjb3JkaW5nIHRvIHRo
ZSkuMTY1IEUKKHNwZWNpXDIxNGVkIHN0YXJ0dXAgYmVoYSk3MiAxMzcgUQoodmlvciBvZiB0
aGUgY29uZ2VzdGlvbiBjb250cm9sIHByb3RvY29sIGl0c2VsZi4gRiktLjIyIEUKKG9yIGEg
bGF5ZXJlZCB0cmFuc21pc3Npb24gb24pLS4xNjUgRQoobXVsdGlwbGUgY2hhbm5lbHMsIHRo
aXMgdHlwaWNhbGx5IG1lYW5zIHRoYXQgYSByZWNlaSk3MiAxNTAgUSAtLjE2NSh2ZSkKLS4y
NzUgRyAyLjc1KHJ3KS4xNjUgRyhpbGwgaW5pdGlhbGx5IGpvaW4gb25seSBhIG1pbmltYWwg
c2V0IG9mKS0yLjc1IEUKKExDVCBjaGFubmVscywgcG9zc2libHkgYSBzaW5nbGUgb25lLik3
MiAxNjMgUQooVGhpcyBydWxlIGhhcyB0aGUgcHVycG9zZSBvZiBwcmUpNS41IEUgLS4xNjUo
dmUpLS4yNzUgRyhudGluZyByZWNlaSkKLjE2NSBFIC0uMTY1KHZlKS0uMjc1IEcocnMgZnJv
bSkuMTY1IEUoc3RhcnRpbmcgYXQgaGlnaCBkYXRhIHJhdGVzLik3MgoxNzYgUShNdWx0aXBs
ZSBvYmplY3RzIGNhbiBiZSBjYXJyaWVkIHdpdGhpbiB0aGUgc2FtZSBMQ1Qgc2Vzc2lvbi4p
NzIKMjAyIFEoSW4gdGhpcyBjYXNlLCBlYWNoIG9iamVjdCBpcyk1LjUgRShpZGVudGlcMjE0
ZWQgYnkgYSB1bmlxdWUgVCk3MgoyMTUgUSAyLjc1KE9JLiBOb3RlKS0uMTk4IEYodGhhdCBl
KTIuNzUgRSAtLjE2NSh2ZSktLjI3NSBHIDIuNzUobmkpLjE2NQpHIDIuNzUoZmFzKS0yLjc1
IEcoZXJ2KS0yLjc1IEUoZXIgc3RvcHMgc2VuZGluZyBMQ1QgcGFjayktLjE2NSBFCihldHMg
Zm9yIGFuIG9sZCBvYmplY3QpLS4xMSBFKGJlZm9yZSBzdGFydGluZyB0byB0cmFuc21pdCBM
Q1QgcGFjayk3MgoyMjggUShldHMgZm9yIGEgbmUpLS4xMSBFIDIuNzUod28pLS4yNzUgRyhi
amVjdCwgYm90aCB0aGUgbmV0dyktMi43NSBFCihvcmsgYW5kIHRoZSB1bmRlcmx5aW5nKS0u
MTEgRQoocHJvdG9jb2wgbGF5ZXJzIGNhbiBjYXVzZSBzb21lIHJlb3JkZXJpbmcgb2YgcGFj
ayk3MiAyNDEgUQooZXRzLCBlc3BlY2lhbGx5IHdoZW4gc2VudCBvKS0uMTEgRSAtLjE2NSh2
ZSktLjE2NSBHIDIuNzUocmQpLjE2NSBHKGlmKQotMi43NSBFKGZlcmVudCBMQ1QpLS4yNzUg
RShjaGFubmVscywgYW5kIHRodXMgcmVjZWkpNzIgMjU0IFEgLS4xNjUodmUpCi0uMjc1IEco
cnMgTVVTVCBOTykuMTY1IEUgMi43NShUYSktLjQ0IEcKKHNzdW1lIHRoYXQgdGhlIHJlY2Vw
dGlvbiBvZiBhbiBMQ1QgcGFjayktMi43NSBFKGV0IGZvciBhIG5lKS0uMTEgRSh3KQotLjI3
NSBFKG9iamVjdCBtZWFucyB0aGF0IHRoZXJlIGFyZSBubyBtb3JlIExDVCBwYWNrKTcyIDI2
NyBRCihldHMgaW4gdHJhbnNpdCBmb3IgdGhlIHByZSktLjExIEUodmlvdXMgb25lLCBhdCBs
ZWFzdCBmb3Igc29tZSktLjI3NSBFCihhbW91bnQgb2YgdGltZS4pNzIgMjgwIFEgMi43NShB
cik3MiAzMDYgUyhlY2VpKS0yLjc1IEUgLS4xNjUodmUpLS4yNzUgRwoyLjc1KHJNKS4xNjUg
RyAyLjMxIC0xLjE1NShBWSBiKS0yLjc1IEggMi43NShlYykxLjE1NSBHCihvbmN1cnJlbnRs
eSBqb2luZWQgdG8gbXVsdGlwbGUgTENUIHNlc3Npb25zLiktMi43NSBFKFRoZSByZWNlaSk1
LjUgRQotLjE2NSh2ZSktLjI3NSBHIDIuNzUock0pLjE2NSBHKFVTVCBwZXJmb3JtKS0yLjc1
IEUKKGNvbmdlc3Rpb24gY29udHJvbCBvbiBlYWNoIHN1Y2ggTENUIHNlc3Npb24uKTcyIDMx
OSBRCihJZiB0aGUgY29uZ2VzdGlvbiBjb250cm9sIHByb3RvY29sIGFsbG8pNS41IEUod3Mg
dGhlKS0uMjc1IEUocmVjZWkpNzIKMzMyIFEgLS4xNjUodmUpLS4yNzUgRyAyLjc1KHJzKS4x
NjUgRyhvbWUgXDIxNWUpLTIuNzUgRQooeGliaWxpdHkgaW4gdGVybXMgb2YgaXRzIGFjdGlv
bnMgd2l0aGluIGEgc2Vzc2lvbiB0aGVuIHRoZSByZWNlaSktLjE2NQpFIC0uMTY1KHZlKS0u
Mjc1IEcgMi43NShyTSkuMTY1IEcgMi4zMSAtMS4xNTUoQVkgbSktMi43NSBIKGFrKTEuMTU1
IEUoZSkKLS4xMSBFKGNob2ljZXMgdG8gb3B0aW1pemUgdGhlIHBhY2spNzIgMzQ1IFEoZXQg
XDIxNW8pLS4xMSBFIDIuNzUod3ApCi0uMjc1IEcoZXJmb3JtYW5jZSBhY3Jvc3MgdGhlIG11
bHRpcGxlIExDVCBzZXNzaW9ucywgYXMgbG9uZyBhcyB0aGUpCi0yLjc1IEUocmVjZWkpNzIg
MzU4IFEgLS4xNjUodmUpLS4yNzUgRyAyLjc1KHJzKS4xNjUgRwoodGlsbCBhZGhlcmVzIHRv
IHRoZSBjb25nZXN0aW9uIGNvbnRyb2wgcnVsZXMgZm9yIGVhY2ggTENUIHNlc3Npb24gaW5k
aSkKLTIuNzUgRSh2aWR1YWxseSktLjI3NSBFKC4pLS43MTUgRS9GMSAxMS9UaW1lcy1Cb2xk
QDAgU0YoNS4pNzIgMzk3IFEvRjIKMTQvVGltZXMtQm9sZEAwIFNGKFNlY3VyaXR5IENvbnNp
ZGVyYXRpb25zKTUuNSBFIEYwCihMQ1QgY2FuIGJlIHN1YmplY3QgdG8gZGVuaWFsLW9mLXNl
cnZpY2UgYXR0YWNrcyBieSBhdHRhY2spNzIgNDEzLjYgUQooZXJzIHdoaWNoIHRyeSB0byBj
b25mdXNlIHRoZSBjb25nZXN0aW9uKS0uMTEgRQooY29udHJvbCBtZWNoYW5pc20sIG9yIHNl
bmQgZm9yKTcyIDQyNi42IFEoZ2VkIHBhY2spLS4xOTggRQooZXRzIHRvIHRoZSBzZXNzaW9u
IHdoaWNoIHcpLS4xMSBFKG91bGQgcHJlKS0uMTEgRSAtLjE2NSh2ZSktLjI3NSBHCihudCBz
dWNjZXNzZnVsKS4xNjUgRShyZWNvbnN0cnVjdGlvbiBvZiBsYXIpNzIgNDM5LjYgUQooZ2Ug
cG9ydGlvbnMgb2YgdGhlIGRhdGEgc3RyZWFtLiktLjE5OCBFKFRoZSBzYW1lIGUpNzIgNDY1
LjYgUQooeGFjdCBwcm9ibGVtcyBhcmUgcHJlc2VudCBpbiBUQ1ApLS4xNjUgRSAyLjc1KCx3
KS0xLjIyMSBHCihoZXJlIGFuIGF0dGFjayktMi43NSBFKGVyIGNhbiBmb3IpLS4xMSBFKGdl
IHBhY2spLS4xOTggRQooZXRzIGFuZCBlaXRoZXIgc2xvKS0uMTEgRSh3KS0uMjc1IEUoZG8p
NzIgNDc4LjYgUSh3biBvciBpbmNyZWFzZSB0aGUgdFwKaHJvdWdocHV0IG9mIHRoZSBzZXNz
aW9uLCBvciByZXBsYWNlIHBhcnRzIG9mIHRoZSBkYXRhIHN0cmVhbSB3aXRoIGZvcikKLS4y
NzUgRShnZWQpLS4xOTggRQooZGF0YS4gSWYgdGhlIHN0cmVhbSBpcyBjYXJyeWluZyBjb21w
cmVzc2VkIG9yIG90aGVyd2lzZSBjb2RlZCBkYXRhLCBlKQo3MiA0OTEuNiBRIC0uMTY1KHZl
KS0uMjc1IEcgMi43NShuYXMpLjE2NSBHKGluZ2xlIGZvciktMi43NSBFKGdlZCBwYWNrKQot
LjE5OCBFKGV0KS0uMTEgRShjb3VsZCBhbHNvIGNhdXNlIGluY29ycmVjdCByZWNvbnN0cnVj
dGlvbiBvZiB0aGUgcmVzdFwKIG9mIHRoZSBkYXRhIHN0cmVhbS4pNzIgNTA0LjYgUShJdCBp
cyB0aGVyZWZvcmUgUkVDT01NRU5ERUQgdGhhdCBMQ1QgYWdcCmVudHMgaW1wbGVtZW50IHNv
bWUgZm9ybSBvZiBhdXRoZW50aWNhdGlvbiB0byk3MiA1MzAuNiBRCihwcm90ZWN0IHRoZW1z
ZWx2KTcyIDU0My42IFEoZXMgYWcpLS4xNjUgRShhaW5zdCBzdWNoIGF0dGFja3MuKS0uMDU1
IEUKRjEoNi4pNzIgNTgyLjYgUSBGMihJQU4pNS41IEUgMy41KEFDKS0uMjggRyhvbnNpZGVy
YXRpb25zKS0zLjUgRSBGMAooTm8gaW5mb3JtYXRpb24gaW4gdGhpcyBzcGVjaVwyMTRjYXRp
b24gaXMgc3ViamVjdCB0byBJQU4pNzIgNTk5LjIgUQoyLjc1KEFyKS0uMzg1IEcgLS4xNjUo
ZWcpLTIuNzUgRyhpc3RyYXRpb24uKS4xNjUgRQooQnVpbGRpbmcgYmxvY2tzIGNvbXBvbmVu
dHMgdXNlZCBieSBMQ1QgbWF5IGludHJvZHVjZSBhZGRpdGlvbmFsIElBTik3Mgo2MjUuMiBR
IDIuNzUoQWMpLS4zODUgRyhvbnNpZGVyYXRpb25zLiktMi43NSBFIEYxKDcuKTcyIDY2NC4y
IFEgRjIKKEludGVsbGVjdHVhbCBQcik1LjUgRShvcGVydHkgSXNzdWVzKS0uMjUyIEUgRjAo
Tm8gc3BlY2lcMjE0YyByZWxpYWJpbGlcCnR5IHByb3RvY29sIG9yIGNvbmdlc3Rpb24gY29u
dHJvbCBwcm90b2NvbCBpcyBzcGVjaVwyMTRlZCBvciByZWZlcmVuY2VkXAogYXMpNzIgNjkz
LjggUShtYW5kYXRvcnkgaW4gdGhpcyBkb2N1bWVudC4pNzIgNzA2LjggUShMdWJ5L0dlbW1l
bGwvVik3Mgo3NjkgUShpY2lzYW5vL1JpenpvL0hhbmRsZSktLjY2IEUoeS9Dcm8pLS4xNjUg
RSAxMTEuODU2KHdjcm9mdCBTZWN0aW9uKQotLjI3NSBGIDIuNzUoNy4gW1ApMi43NSBGKGFn
ZSAxNl0pLS4xNjUgRSBFUAolJVBhZ2U6IDE3IDE3CiUlQmVnaW5QYWdlU2V0dXAKQlAKJSVF
bmRQYWdlU2V0dXAKL0YwIDExL1RpbWVzLVJvbWFuQDAgU0YoSU5URVJORVQpNzIgNDkgUSA3
MS41ODcoLURSQUZUIEV4cGlyZXM6KS0xLjAxMiBGCihKYW51YXJ5IDIwMDIpMi43NSBFKEp1
bHkgMjAwMSkxMjMuNzI2IEUoTENUIE1BKTcyIDg1IFEgMi43NShZYiktMS4xNTUgRwoyLjc1
KGV1KS0yLjc1IEcoc2VkIHdpdGggY29uZ2VzdGlvbiBjb250cm9sIHByb3RvY29scyBhbmQg
b3RoZXIgcHJvdG9jb1wKbHMgd2hpY2ggYXJlIHByb3ByaWV0YXJ5KS0yLjc1IEUoLCktLjcx
NSBFKG9yIGhhKTcyIDk4IFEgLjMzIC0uMTY1KHZlIHApCi0uMjIgSChlbmRpbmcgb3IgZ3Jh
bnRlZCBwYXRlbnRzLikuMTY1IEUvRjEgMTEvVGltZXMtQm9sZEAwIFNGKDguKTcyIDEzNwpR
L0YyIDE0L1RpbWVzLUJvbGRAMCBTRihBY2tubyk1LjUgRSh3bGVkZ21lbnRzKS0uMTQgRSBG
MChUaGFua3MgdG8gVik3MgoxNTMuNiBRKGluY2VudCBSb2NhLCBCcnVjZSBMdWVjayktLjY2
IEUoZW5ob2YpLS4xMSBFIDIuNzUoZmEpLS4yNzUgRwoobmQgSGF5ZGVyIFJhZGhhIGZvciBk
ZXRhaWxlZCBjb21tZW50cyBvbiB0aGlzKS0yLjc1IEUoZG9jdW1lbnQuKTcyCjE2Ni42IFEo
WzFdIEJ5ZXJzLCBKLlcpNzIgMjIyLjIgUSguLCBMdWJ5KS0xLjAxMiBFIDIuNzUoLE0pLS43
MTUgRwooLiwgTWl0emVubWFjaGVyKS0yLjc1IEUgMi43NSgsTSktLjQ0IEcoLiwgYW5kIFJl
KS0yLjc1IEUKKGdlLCBBLiwgIkEgRGlnaXRhbCBGKS0uMTY1IEUob3VudGFpbiBBcHByb2Fj
aCB0byktLjE2NSBFCihSZWxpYWJsZSBEaXN0cmliKTcyIDIzNS4yIFEodXRpb24gb2YgQnVs
ayBEYXRhIiwgUHJvY2VlZGluZ3MgQSktLjIyIEUKKENNIFNJR0NPTU0gJzk4LCBWKS0uNDQg
RShhbmNvdXYpLTEuMjIxIEUoZXIpLS4xNjUgRSAyLjc1KCxDKS0uNDQgRwooYW5hZGEsIFNl
cHQpLTIuNzUgRSgxOTk4Lik3MiAyNDguMiBRKFsyXSBDYWluLCBCLiwgU3BlYWttYW4sIFQp
NzIgMjc0LjIKUSguLCBhbmQgVCktLjgxNCBFIC0uMjc1KG93KS0uODggRyhzbGUpLjI3NSBF
IDEuNDMgLS43MTUoeSwgRCktLjE2NSBICiguLCAiR2VuZXJpYyBSb3V0ZXIgQXNzaXN0IFwo
R1JBXCkgQnVpbGRpbmcgQmxvY2ssKS43MTUgRShNb3RpKTcyIDI4Ny4yClEgLS4yNzUodmEp
LS4yNzUgRyh0aW9uIGFuZCBBcmNoaXRlY3R1cmUiLCBJbnRlcm5ldCBEcmFmdCBkcmFmdC1p
ZXRmLXJtXAp0LWdyYS1hcmNoLTAwLnR4dCwgYSB3KS4yNzUgRShvcmsgaW4gcHJvZ3Jlc3Mu
KS0uMTEgRQooWzNdIEdlbW1lbGwsIEouLCBTY2hvb2xlcik3MiAzMTMuMiBRIDIuNzUoLEUp
LS40NCBHKC4sIGFuZCBHcmF5KS0yLjc1IEUKMi43NSgsSiktLjcxNSBHKC4sICJGQ2FzdCBT
Y2FsYWJsZSBNdWx0aWNhc3QgRmlsZSBEaXN0cmliKS0yLjc1IEUKKHV0aW9uOiBDYWNoaW5n
KS0uMjIgRShhbmQgUCk3MiAzMjYuMiBRKGFyYW1ldGVycyBPcHRpbWl6YXRpb25zIiwgVCkK
LS4xNjUgRShlY2huaWNhbCBSZXBvcnQgTVNSLVRSLTk5LTE0LCBNaWNyb3NvZnQgUmVzZWFy
Y2gsKS0uNzcgRQooUmVkbW9uZCwgVyk3MiAzMzkuMiBRKEEsIEFwcmlsLCAxOTk5LiktMS4z
MiBFKFs0XSBIYW5kbGUpNzIgMzY1LjIgUQoxLjQzIC0uNzE1KHksIE0pLS4xNjUgSAooLiwg
IlNBUDogU2Vzc2lvbiBBbm5vdW5jZW1lbnQgUHJvdG9jb2wiLCBJbnRlcm5ldCBEcmFmdCwg
SUVURiBNTVVTSUMpCi43MTUgRSAtLjg4KFdvKTcyIDM3OC4yIFMocmtpbmcgR3JvdXAsIE5v
KS44OCBFIDIuNzUodjEpLS4xNjUgRwooOTk2LCBhIHcpLTIuNzUgRShvcmsgaW4gcHJvZ3Jl
c3MuKS0uMTEgRShbNV0gSG9sYnJvb2ssIEguLCBDYWluLCBCLiwgIlwKU291cmNlLVNwZWNp
XDIxNGMgTXVsdGljYXN0IGZvciBJUCIsIEludGVybmV0IERyYWZ0LCBTU00gVyk3MiA0MDQu
MiBRCihvcmtpbmcpLS44OCBFKEdyb3VwLCBNYXJjaCAyMDAxLCBkcmFmdC1ob2xicm9vay1z
c20tYXJjaC0wMi50eHQsIGEgdyk3Mgo0MTcuMiBRKG9yayBpbiBwcm9ncmVzcy4pLS4xMSBF
KFs2XSBMdWJ5KTcyIDQ0My4yIFEgMi43NSgsTSktLjcxNSBHCiguLCBHZW1tZWxsLCBWKS0y
Ljc1IEUoaWNpc2FubywgTC4sIEouLCBSaXp6bywgTC4sIEhhbmRsZSktLjY2IEUgMS40Mwot
LjcxNSh5LCBNKS0uMTY1IEgoLiwgQ3JvKS43MTUgRSh3Y3JvZnQsIEouLCAiVGhlIHVzZSBv
ZiktLjI3NSBFIC0uMTY1CihGbyk3MiA0NTYuMiBTKHJ3KS4xNjUgRShhcmQgRXJyb3IgQ29y
cmVjdGlvbiBpbiBSZWxpYWJsZSBNdWx0aWNhc3QiLCBJXApudGVybmV0IERyYWZ0IGRyYWZ0
LWlldGYtcm10LWluZm8tZmVjLTAwLnR4dCwpLS4xMSBFKE5vKTcyIDQ2OS4yIFEgLS4xNjUK
KHZlKS0uMTY1IEcobWJlciAyMDAwLCBhIHcpLjE2NSBFKG9yayBpbiBwcm9ncmVzcy4pLS4x
MSBFKFs3XSBMdWJ5KTcyCjQ5NS4yIFEgMi43NSgsTSktLjcxNSBHKC4sIFYpLTIuNzUgRQoo
aWNpc2FubywgTC4sIEdlbW1lbGwsIEouLCBSaXp6bywgTC4sIEhhbmRsZSktLjY2IEUgMS40
MyAtLjcxNSh5LCBNKQotLjE2NSBIKC4sIENybykuNzE1IEUod2Nyb2Z0LCBKLiwgIlJNVCBC
QiktLjI3NSBFIC0uMTY1KEZvKTcyIDUwOC4yIFMKKHJ3KS4xNjUgRShhcmQgRXJyb3IgQ29y
cmVjdGlvbiBDb2RlcyIsIEludGVybmV0IERyYWZ0IGRyYWZ0LWlldGYtcm10LWJcCmItZmVj
LTAzLnR4dCwgSnVseSAyMDAxLiktLjExIEUoWzhdIEx1YnkpNzIgNTM0LjIgUSAyLjc1KCxN
KS0uNzE1IEcKKC4sIEhlcm5laywgRC4sIEspLTIuNzUgRSh1c2hpLCBELiwgUmFzbXVzc2Vu
LCBMLiwgU2ltdSwgUy4sIFYpLS4xNjUgRQooYWluaXNoLCBSLiwgIlJpY2ggQ29udGVudCBD
b250cm9sKS0xLjIyMSBFCihQcm90b2NvbDogQSBzZXNzaW9uIGNvbnRyb2wgcHJvdG9jb2wg
aW5zdGFudGlhdGlvbiIsIERpZ2l0YWwgRik3MiA1NDcuMgpRKG91bnRhaW4gZG9jdW1lbnQs
IGEgdyktLjE2NSBFKG9yayBpbiktLjExIEUocHJvZ3Jlc3MuKTcyIDU2MC4yIFEKKFs5XSBM
dWJ5KTcyIDU4Ni4yIFEgMi43NSgsTSktLjcxNSBHKC4sIFYpLTIuNzUgRShpY2lzYW5vLCBM
LiwgSGFrKS0uNjYKRShlbiwgQS4sICJSTVQgQkIgTGF5ZXJlZCBjb25nZXN0aW9uIGNvbnRy
b2wiLCBkcmFmdC1pZXRmLXJtdC1iYi0pLS4xMSBFCihsY2MtMDAudHh0LCBObyk3MiA1OTku
MiBRIC0uMTY1KHZlKS0uMTY1IEcobWJlciAyMDAwLCBhIHcpLjE2NSBFCihvcmsgaW4gcHJv
Z3Jlc3MuKS0uMTEgRShbMTBdIFJpenpvLCBMLiwgIkVmKTcyIDYyNS4yIFEoZmVjdGkpLS4y
NzUgRQouMzMgLS4xNjUodmUgRSktLjI3NSBICihyYXN1cmUgQ29kZXMgZm9yIFJlbGlhYmxl
IENvbXB1dGVyIENvbW11bmljYXRpb24gUHJvdG9jb2xzIiwpLjE2NSBFCi0uNDQoQUMpNzIg
NjM4LjIgUyAyLjc1KE1TKS40NCBHKElHQ09NTSBDb21wdXRlciBDb21tdW5pY2F0aW9uIFJl
KS0yLjc1CkUodmllKS0uMjc1IEUgMS40MyAtLjcxNSh3LCBWKS0uMjc1IEgob2wuMjcsIE5v
LjIsIHBwLjI0LTM2LCBBcHIgMTk5Ny4pCi0uNzA0IEUoWzExXSBQZXJyaWcsIEEuLCBDYW5l
dHRpLCBSLiwgQnJpc2NvZSwgQi4sIFQpNzIgNjY0LjIgUSh5ZyktLjg4CkUoYXIpLS4wNTUg
RSAyLjc1KCxEKS0uNDQgRyguLCBTb25nLCBELiwgIlRFU0xBOiBNdWx0aWNhc3QgU291cmNl
KS0yLjc1CkUoQXV0aGVudGljYXRpb24gVCk3MiA2NzcuMiBRCihyYW5zZm9ybSIsIGRyYWZ0
LWlydGYtc211Zy10ZXNsYS0wMC50eHQsIE5vKS0uMzg1IEUgLS4xNjUodmUpLS4xNjUgRwoo
bWJlcikuMTY1IEUgMi43NSgsMiktLjQ0IEcoMDAwLCBhIHcpLTIuNzUgRShvcmsgaW4gcHJv
Z3Jlc3MuKS0uMTEgRQooWzEyXSBSaXp6bywgTCwgYW5kIFYpNzIgNzAzLjIgUQooaWNpc2Fu
bywgTC4sICJSZWxpYWJsZSBNdWx0aWNhc3QgRGF0YSBEaXN0cmliKS0uNjYgRQoodXRpb24g
cHJvdG9jb2wgYmFzZWQgb24gc29mdHcpLS4yMiBFKGFyZSktLjExIEUKKEZFQyB0ZWNobmlx
dWVzIiwgUHJvY2VlZGluZ3Mgb2YgdGhlIEYpNzIgNzE2LjIgUShvdXJ0aCBJRUVFUyBXKS0u
MTY1IEUKKG9ya3Nob3Agb24gdGhlIEFyY2hpdGVjdHVyZSBhbmQpLS44OCBFKEx1YnkvR2Vt
bWVsbC9WKTcyIDc2OSBRCihpY2lzYW5vL1JpenpvL0hhbmRsZSktLjY2IEUoeS9Dcm8pLS4x
NjUgRSAxMTEuODU2KHdjcm9mdCBTZWN0aW9uKS0uMjc1CkYgMi43NSg4LiBbUCkyLjc1IEYo
YWdlIDE3XSktLjE2NSBFIEVQCiUlUGFnZTogMTggMTgKJSVCZWdpblBhZ2VTZXR1cApCUAol
JUVuZFBhZ2VTZXR1cAovRjAgMTEvVGltZXMtUm9tYW5AMCBTRihJTlRFUk5FVCk3MiA0OSBR
IDcxLjU4NygtRFJBRlQgRXhwaXJlczopLTEuMDEyIEYKKEphbnVhcnkgMjAwMikyLjc1IEUo
SnVseSAyMDAxKTEyMy43MjYgRShJbXBsZW1lbnRhdGlvbiBvZiBIaWdoIFBlcmZvcm1cCmFu
Y2UgQ29tbXVuaWNhdGlvbiBTeXN0ZW1zLCBIUENTJzk3LCBDaGFsa2lkaWtpLCBHcmVlY2Us
KTcyIDg1IFEKKEp1bmUgMTk5Ny4pNzIgOTggUShbMTNdIFNwZWFrbWFuLCBUKTcyIDEyNCBR
KC4sIEYpLS44MTQgRQooYXJpbmFjY2ksIEQuLCBDcm8pLS4xNjUgRSh3Y3JvZnQsIEouLCBH
ZW1tZWxsLCBKLiwgTGluLCBTLiwgVCktLjI3NSBFCih3ZWVkbHkpLS44OCBFIDIuNzUoLEEp
LS43MTUgRyguLCBMZXNoY2hpbmVyKS0yLjc1IEUoLCktLjQ0IEUoRC4sIEx1YnkpCjcyIDEz
NyBRIDIuNzUoLE0pLS43MTUgRyguLCBCaGFza2FyKS0yLjc1IEUgMi43NSgsTiktLjQ0IEcK
KC4sIEVkbW9uc3RvbmUsIFIuLCBKb2huc29uLCBLLiwgTW9udGdvbWVyeSktMi43NSBFIDIu
NzUoLFQpLS43MTUgRwooLiwgUml6em8sIEwuLCktMy41NjQgRShTdW1hbmFzZWspNzIgMTUw
IFEoZXJhLCBSLiwgViktLjExIEUKKGljaXNhbm8sIEwuLCAiUEdNIFJlbGlhYmxlIFQpLS42
NiBFCihyYW5zcG9ydCBQcm90b2NvbCIsIGRyYWZ0LXNwZWFrbWFuLXBnbS0pLS4zODUgRShz
cGVjLTA2LnR4dCwgYSB3KTcyIDE2MwpRKG9yayBpbiBwcm9ncmVzcy4pLS4xMSBFKFsxNF0g
Vik3MiAxODkgUShpY2lzYW5vLCBMLiwgUml6em8sIEwuLCBDcm8pCi0uNjYgRSh3Y3JvZnQs
IEouLCAiVENQLWxpayktLjI3NSBFIDIuNzUoZUMpLS4xMSBHCihvbmdlc3Rpb24gQ29udHJv
bCBmb3IgTGF5ZXJlZCBNdWx0aWNhc3QpLTIuNzUgRShEYXRhIFQpNzIgMjAyIFEKKHJhbnNm
ZXIiLCBJRUVFIEluZm9jb20gJzk4LCBTYW4gRnJhbmNpc2NvLCBDQSwgTWFyKS0uMzg1IEUo
LjI4LUFwcikKLS42MDUgRSguMSAxOTk4LiktLjYwNSBFKFsxNV0gVik3MiAyMjggUQooaWNp
c2FubywgTC4sICJOb3RlcyBPbiBhIEN1bXVsYXRpKS0uNjYgRSAuMzMgLS4xNjUodmUgTCkt
LjI3NSBICihheWVyZWQgT3IpLjE2NSBFIC0uMDU1KGdhKS0uMTk4IEcobml6YXRpb24gb2Yg
RGF0YSBQKS4wNTUgRShhY2spLS4xNjUgRQooZXRzIEFjcm9zcyBNdWx0aXBsZSktLjExIEUo
Z3JvdXBzIHdpdGggRGlmKTcyIDI0MSBRKGZlcmVudCBSYXRlcyIsIFVuaSkKLS4yNzUgRSAt
LjE2NSh2ZSktLjI3NSBHKHJzaXR5IENvbGxlKS4xNjUgRQooZ2UgTG9uZG9uIENvbXB1dGVy
IFNjaWVuY2UgUmVzZWFyY2ggTm90ZSktLjE2NSBFKFJOLzk4LzI1LCBXKTcyIDI1NCBRCihv
cmsgaW4gUHJvZ3Jlc3MgXChNYXkgMTk5OFwpLiktLjg4IEUvRjEgMTEvVGltZXMtQm9sZEAw
IFNGKDkuKTcyIDMwNiBRCi9GMiAxNC9UaW1lcy1Cb2xkQDAgU0YgLS43KEF1KTUuNSBHKHRo
b3JzJyBBZGRyKS43IEUoZXNzZXMpLS4yNTIgRSBGMAooTWljaGFlbCBMdWJ5KTgwLjI1IDMy
Mi42IFEobHVieUBkaWdpdGFsZm91bnRhaW4uY29tKTgwLjI1IDMzNS42IFEKKERpZ2l0YWwg
Rik4MC4yNSAzNDguNiBRKG91bnRhaW4pLS4xNjUgRSgzOTE0MSBDaSk4MC4yNSAzNjEuNiBR
Cih2aWMgQ2VudGVyIERyaSktLjI3NSBFIC0uMTY1KHZlKS0uMjc1IEcoU3VpdGUgMzAwKTgw
LjI1IDM3NC42IFEKKEZyZW1vbnQsIENBLCBVU0EsIDk0NTM4KTgwLjI1IDM4Ny42IFEoSmlt
IEdlbW1lbGwpODAuMjUgNDEzLjYgUQooamdlbW1lbGxAbWljcm9zb2Z0LmNvbSk4MC4yNSA0
MjYuNiBRKE1pY3Jvc29mdCBSZXNlYXJjaCk4MC4yNSA0MzkuNiBRCigzMDEgSG8pODAuMjUg
NDUyLjYgUSAtLjExKHdhKS0uMjc1IEcocmQgU3QuLCAjODMwKS4xMSBFCihTYW4gRnJhbmNp
c2NvLCBDQSwgVVNBLCA5NDEwNSk4MC4yNSA0NjUuNiBRKExvcmVuem8gVik4MC4yNSA0OTEu
NiBRCihpY2lzYW5vKS0uNjYgRShsb3JlbnpvQGNpc2NvLmNvbSk4MC4yNSA1MDQuNiBRKGNp
c2NvIFN5c3RlbXMsIEluYy4pCjgwLjI1IDUxNy42IFEoMTcwIFcpODAuMjUgNTMwLjYgUShl
c3QgVCktLjg4IEUoYXNtYW4gRHIpLS44OCBFKC4sKS0uNjA1CkUoU2FuIEpvc2UsIENBLCBV
U0EsIDk1MTM0KTgwLjI1IDU0My42IFEoTHVpZ2kgUml6em8pODAuMjUgNTY5LjYgUQoobHVp
Z2lAaWV0LnVuaXBpLml0KTgwLjI1IDU4Mi42IFEgLS40NChBQyk4MC4yNSA1OTUuNiBTKElS
SS9JQ1NJLCkuNDQgRQooMTk0NyBDZW50ZXIgU3QsIEJlcmspODAuMjUgNjA4LjYgUShlbGUp
LS4xMSBFIDEuNDMgLS43MTUoeSwgQyktLjE2NSBICihBLCBVU0EsIDk0NzA0KS43MTUgRShh
bmQpODAuMjUgNjIxLjYgUShEaXAuIEluZy4gZGVsbCdJbmZvcm1hemlvbmUsKQo4MC4yNSA2
MzQuNiBRKFVuaSk4MC4yNSA2NDcuNiBRIDEuNDMgLS43MTUodi4gZCktLjI3NSBIIDIuNzUo
aVApLjcxNSBHCihpc2EpLTIuNzUgRSh2aWEgRGlvdGlzYWx2aSAyLCA1NjEyNiBQaXNhLCBJ
dGFseSk4MC4yNSA2NjAuNiBRCihNYXJrIEhhbmRsZSk4MC4yNSA2ODYuNiBRKHkpLS4xNjUg
RShtamhAYWNpcmkub3IpODAuMjUgNjk5LjYgUShnKS0uMTk4CkUgLS40NChBQyk4MC4yNSA3
MTIuNiBTKElSSSwpLjQ0IEUoMTk0NyBDZW50ZXIgU3QsKTgwLjI1IDcyNS42IFEKKEx1Ynkv
R2VtbWVsbC9WKTcyIDc2OSBRKGljaXNhbm8vUml6em8vSGFuZGxlKS0uNjYgRSh5L0Nybykt
LjE2NSBFCjExMS44NTYod2Nyb2Z0IFNlY3Rpb24pLS4yNzUgRiAyLjc1KDkuIFtQKTIuNzUg
RihhZ2UgMThdKS0uMTY1IEUgRVAKJSVQYWdlOiAxOSAxOQolJUJlZ2luUGFnZVNldHVwCkJQ
CiUlRW5kUGFnZVNldHVwCi9GMCAxMS9UaW1lcy1Sb21hbkAwIFNGKElOVEVSTkVUKTcyIDQ5
IFEgNzEuNTg3KC1EUkFGVCBFeHBpcmVzOiktMS4wMTIgRgooSmFudWFyeSAyMDAyKTIuNzUg
RShKdWx5IDIwMDEpMTIzLjcyNiBFKEJlcmspODAuMjUgODUgUShlbGUpLS4xMSBFIDEuNDMK
LS43MTUoeSwgQyktLjE2NSBIKEEsIFVTQSwgOTQ3MDQpLjcxNSBFKEpvbiBDcm8pODAuMjUg
MTExIFEod2Nyb2Z0KS0uMjc1CkUoSi5Dcm8pODAuMjUgMTI0IFEod2Nyb2Z0QGNzLnVjbC5h
Yy51ayktLjI3NSBFCihEZXBhcnRtZW50IG9mIENvbXB1dGVyIFNjaWVuY2UpODAuMjUgMTM3
IFEoVW5pKTgwLjI1IDE1MCBRIC0uMTY1KHZlKQotLjI3NSBHKHJzaXR5IENvbGxlKS4xNjUg
RShnZSBMb25kb24pLS4xNjUgRShHbyk4MC4yNSAxNjMgUSh3ZXIgU3RyZWV0LCkKLS4yNzUg
RShMb25kb24gV0MxRSA2QlQpODAuMjUgMTc2IFEgMi43NSgsVSktLjgxNCBHKEspLTIuNzUg
RQooTHVieS9HZW1tZWxsL1YpNzIgNzY5IFEoaWNpc2Fuby9SaXp6by9IYW5kbGUpLS42NiBF
KHkvQ3JvKS0uMTY1IEUKMTExLjg1Nih3Y3JvZnQgU2VjdGlvbiktLjI3NSBGIDIuNzUoOS4g
W1ApMi43NSBGKGFnZSAxOV0pLS4xNjUgRSBFUAolJVBhZ2U6IDIwIDIwCiUlQmVnaW5QYWdl
U2V0dXAKQlAKJSVFbmRQYWdlU2V0dXAKL0YwIDExL1RpbWVzLVJvbWFuQDAgU0YoSU5URVJO
RVQpNzIgNDkgUSA3MS41ODcoLURSQUZUIEV4cGlyZXM6KS0xLjAxMiBGCihKYW51YXJ5IDIw
MDIpMi43NSBFKEp1bHkgMjAwMSkxMjMuNzI2IEUvRjEgMTEvVGltZXMtQm9sZEAwIFNGKDEw
Lik3MiA4NQpRL0YyIDE0L1RpbWVzLUJvbGRAMCBTRihGdWxsIENvcHlyaWdodCBTdGF0ZW1l
bnQpNS41IEUgRjAoQ29wKTcyIDEwMS42IFEKKHlyaWdodCBcKENcKSBUaGUgSW50ZXJuZXQg
U29jaWV0eSBcKDIwMDBcKS4pLS4xMSBFKEFsbCBSaWdodHMgUmVzZXJ2KQo1LjUgRShlZC4p
LS4xNjUgRShUaGlzIGRvY3VtZW50IGFuZCB0cmFuc2xhdGlvbnMgb2YgaXQgbWF5IGJlIGNv
cGllZCBhblwKZCBmdXJuaXNoZWQgdG8gb3RoZXJzLCBhbmQgZGVyaSk3MiAxMTguMiBRIC0u
Mjc1KHZhKS0uMjc1IEcodGkpLjI3NSBFCi4zMyAtLjE2NSh2ZSB3KS0uMjc1IEgob3Jrcyku
MDU1IEUodGhhdCBjb21tZW50IG9uIG9yIG90aGVyd2lzZSBlKTcyCjEzMS4yIFEKKHhwbGFp
biBpdCBvciBhc3Npc3QgaW4gaXRzIGltcGxlbWVudGF0aW9uIG1heSBiZSBwcmVwYXJlZCwg
Y29waWVkLCkKLS4xNjUgRShwdWJsaXNoZWQgYW5kIGRpc3RyaWIpNzIgMTQ0LjIgUQoodXRl
ZCwgaW4gd2hvbGUgb3IgaW4gcGFydCwgd2l0aG91dCByZXN0cmljdGlvbiBvZiBhbiktLjIy
IEUgMi43NSh5aykKLS4xNjUgRyhpbmQsIHBybyktMi43NSBFKHZpZGVkIHRoYXQgdGhlKS0u
MTY1IEUoYWJvKTcyIDE1Ny4yIFEgLjMzIC0uMTY1Cih2ZSBjKS0uMTY1IEgob3ApLjE2NSBF
KHlyaWdodCBub3RpY2UgYW5kIHRoaXMgcGFyYWdyYXBoIGFyZSBpbmNsdWRlZCBvXApuIGFs
bCBzdWNoIGNvcGllcyBhbmQgZGVyaSktLjExIEUgLS4yNzUodmEpLS4yNzUgRyh0aSkuMjc1
IEUgLjMzIC0uMTY1Cih2ZSB3KS0uMjc1IEgob3Jrcy4pLjA1NSBFKEhvKTcyIDE3MC4yIFEo
d2UpLS4yNzUgRSAtLjE2NSh2ZSktLjI3NSBHIC44OAotLjQ0KHIsIHQpLjE2NSBIKGhpcyBk
b2N1bWVudCBpdHNlbGYgbWF5IG5vdCBiZSBtb2RpXDIxNGVkIGluIGFuKS40NCBFCjIuNzUo
eXcpLS4xNjUgRyhheSktMi44NiBFIDIuNzUoLHMpLS43MTUgRyh1Y2ggYXMgYnkgcmVtbykt
Mi43NSBFCih2aW5nIHRoZSktLjE2NSBFKGNvcCk3MiAxODMuMiBRKHlyaWdodCBub3RpY2Ug
b3IgcmVmZXJlbmNlcyB0byB0aGUgSW50XAplcm5ldCBTb2NpZXR5IG9yIG90aGVyIEludGVy
bmV0IG9yKS0uMTEgRSAtLjA1NShnYSktLjE5OCBHKG5pemF0aW9ucywgZSkKLjA1NSBFKHhj
ZXB0IGFzKS0uMTY1IEUobmVlZGVkIGZvciB0aGUgcHVycG9zZSBvZiBkZSk3MiAxOTYuMiBR
IC0uMTY1Cih2ZSktLjI3NSBHKGxvcGluZyBJbnRlcm5ldCBzdGFuZGFyZHMgaW4gd2hpY2gg
Y2FzZSB0aGUgcHJvY2VkdXJlcyBmb3IpCi4xNjUgRShjb3ApNzIgMjA5LjIgUQooeXJpZ2h0
cyBkZVwyMTRuZWQgaW4gdGhlIEludGVybmV0IGxhbmd1YWdlcyBvdGhlciB0aGFuIEVuZ2xp
c2guKS0uMTEgRQooVGhlIGxpbWl0ZWQgcGVybWlzc2lvbnMgZ3JhbnRlZCBhYm8pNzIgMjI1
LjggUSAuMzMgLS4xNjUodmUgYSktLjE2NSBICihyZSBwZXJwZXR1YWwgYW5kIHdpbGwgbm90
IGJlIHJlKS4xNjUgRSAtLjIyKHZvKS0uMjc1IEcgLS4xMShrZSkuMjIgRwoyLjc1KGRiKS4x
MSBHIDIuNzUoeXQpLTIuNzUgRyhoZSBJbnRlcm5ldCktMi43NSBFCihTb2NpZXR5IG9yIGl0
cyBzdWNjZXNzb3JzIG9yIGFzc2lnbnMuKTcyIDIzOC44IFEKKFRoaXMgZG9jdW1lbnQgYW5k
IHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaGVyZWluIGlzIHBybyk3MiAyNTUuNCBRCih2
aWRlZCBvbiBhbiAiQVMgSVMiIGJhc2lzIGFuZCBUSEUpLS4xNjUgRQooSU5URVJORVQgU09D
SUVUWSBBTkQgVEhFIElOVEVSTkVUIEVOR0lORUVSSU5HIFQpNzIgMjY4LjQgUQooQVNLIEZP
UkNFIERJU0NMQUlNUyktMS4wMjMgRShBTEwgVyk3MiAyODEuNCBRCihBUlJBTlRJRVMsIEVY
UFJFU1MgT1IgSU1QTElFRCwgSU5DTFVESU5HIEIpLTEuMzIgRShVVCBOTyktLjExIEUgMi43
NQooVEwpLS40NCBHKElNSVRFRCBUKS0yLjc1IEUgMi43NShPQSktLjE5OCBHKE5ZKS0yLjc1
IEUgLTEuMzIoV0EpNzIgMjk0LjQKUyhSUkFOVFkgVEhBKTEuMzIgRSAyLjc1KFRUKS0xLjIy
MSBHKEhFIFVTRSBPRiBUSEUgSU5GT1JNQSktMi43NSBFCihUSU9OIEhFUkVJTiBXSUxMIE5P
KS0xLjIyMSBFIDIuNzUoVEkpLS40NCBHKE5GUklOR0UpLTIuNzUgRQooQU5ZIFJJR0hUUyBP
UiBBTlkgSU1QTElFRCBXKTcyIDMwNy40IFEoQVJSQU5USUVTIE9GIE1FUkNIQU5UKS0xLjMy
IEUKKEFCSUxJVFkgT1IgRklUTkVTUyktMS4wMjMgRShGT1IgQSBQKTcyIDMyMC40IFEoQVIp
LTEuMDEyIEUKKFRJQ1VMQVIgUFVSUE9TRS4iKS0uNjYgRShMdWJ5L0dlbW1lbGwvVik3MiA3
NjkgUShpY2lzYW5vL1JpenpvL0hhbmRsZSkKLS42NiBFKHkvQ3JvKS0uMTY1IEUgMTA2LjM1
Nih3Y3JvZnQgU2VjdGlvbiktLjI3NSBGIDIuNzUoMTAuIFtQKTIuNzUgRgooYWdlIDIwXSkt
LjE2NSBFIEVQCiUlUGFnZTogMjEgMjEKJSVCZWdpblBhZ2VTZXR1cApCUAolJUVuZFBhZ2VT
ZXR1cAovRjAgMTEvVGltZXMtUm9tYW5AMCBTRihJTlRFUk5FVCk3MiA0OSBRIDcxLjU4Nygt
RFJBRlQgRXhwaXJlczopLTEuMDEyIEYKKEphbnVhcnkgMjAwMikyLjc1IEUoSnVseSAyMDAx
KTEyMy43MjYgRShMdWJ5L0dlbW1lbGwvVik3MiA3NjkgUQooaWNpc2Fuby9SaXp6by9IYW5k
bGUpLS42NiBFKHkvQ3JvKS0uMTY1IEUgMTA2LjM1Nih3Y3JvZnQgU2VjdGlvbiktLjI3NQpG
IDIuNzUoMTAuIFtQKTIuNzUgRihhZ2UgMjFdKS0uMTY1IEUgRVAKJSVUcmFpbGVyCmVuZAol
JUVPRgo=
--==_Exmh_5195028970--
>From owner-rmt@listserv.lbl.gov Thu Jul 19 17:12:19 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f6K0CGO28854;
Thu, 19 Jul 2001 17:12:16 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f6K0CER28850
for <rmt@listserv.lbl.gov>; Thu, 19 Jul 2001 17:12:14 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f6K0CD721890
for <rmt@listserv.lbl.gov>; Thu, 19 Jul 2001 17:12:13 -0700 (PDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f6K0CCA21876
for <rmt@lbl.gov>; Thu, 19 Jul 2001 17:12:12 -0700 (PDT)
Received: from lorenzo-u10.cisco.com (lorenzo-u10.cisco.com [128.107.162.143])
by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f6K0C4X18278;
Thu, 19 Jul 2001 17:12:04 -0700 (PDT)
Received: from localhost (lorenzo@localhost) by lorenzo-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id RAA01812; Thu, 19 Jul 2001 17:11:45 -0700 (PDT)
Message-Id: <200107200011.RAA01812@lorenzo-u10.cisco.com>
X-Authentication-Warning: lorenzo-u10.cisco.com: lorenzo owned process doing -bs
X-Mailer: exmh version 2.3.1 01/18/2001 with version: MH 6.8.4 #29[UCI]
To: internet-drafts@ietf.org
cc: adamson@itd.nrl.navy.mil, jgemmell@MICROSOFT.com, luigi@iet.unipi.it,
mjh@aciri.org, J.Crowcroft@cs.ucl.ac.uk, lorenzo@cisco.com, rmt@lbl.gov
Subject: draft-ietf-rmt-bb-fec-03.txt
Mime-Version: 1.0
Content-Type: multipart/mixed ;
boundary="==_Exmh_5297534880"
Date: Thu, 19 Jul 2001 17:11:45 -0700
From: Lorenzo Vicisano <lorenzo@cisco.com>
Sender: owner-rmt@lbl.gov
Precedence: bulk
This is a multipart MIME message.
--==_Exmh_5297534880
Content-Type: text/plain; charset=us-ascii
Please post this draft on the IETF Internet Drafts archive.
This is an update of an existing WG draft (RMT).
Thank you,
Lorenzo Vicisano
--==_Exmh_5297534880
Content-Type: text/plain ; name="draft-ietf-rmt-bb-fec-03.txt"; charset=us-ascii
Content-Description: draft-ietf-rmt-bb-fec-03.txt
Content-Disposition: attachment; filename="draft-ietf-rmt-bb-fec-03.txt"
Internet Engineering Task Force RMT WG
INTERNET-DRAFT M.Luby/Digital Fountain
draft-ietf-rmt-bb-fec-03.txt L.Vicisano/Cisco
J.Gemmell/Microsoft
L.Rizzo/ACIRI and Univ. Pisa
M.Handley/ACIRI
J. Crowcroft/UCL
19 July 2001
Expires: January 2002
RMT BB Forward Error Correction Codes
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts.
Internet-Drafts are valid for a maximum of six months and may be
updated, replaced, or obsoleted by other documents at any time. It is
inappropriate to use Internet-Drafts as reference material or to cite
them other than as a "work in progress".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html.
This document is a product of the IETF RMT WG. Comments should be
addressed to the authors, or the WG's mailing list at rmt@isi.edu.
Abstract
This memo describes the abstract packet formats and IANA
registration procedures for use of Forward Error Correction
(FEC) codes within the context of reliable IP multicast
transport. This memo should be read in conjunction with and
uses the terminology of the companion memo [1], which
describes the use of Forward Error Correction (FEC) codes
within the context of reliable IP multicast transport and
Luby/Vicisano/Gemmell/Rizzo/Handley/Crowcroft [Page 1]
^L
INTERNET-DRAFT Expires: January 2002 July 2001
provides an introduction to some commonly used FEC codes.
1. FEC Abstract Packet Fields and Out-of-Band Information
This section specifies the information that protocol packets must carry
to implement the various forms of FEC-based reliability. A session is
defined to be all the information associated with a transmission of data
about a particular object by a single sender. There are three classes
of packets that may contain FEC information within a session: data
packets, session-control packets and feedback packets. They generally
contain different kinds of FEC information. Note that some protocols do
not use feedback packets.
Data packets may sometime serve as session-control packets as well; both
data and session-control packets generally travel downstream (from the
sender towards receivers) and are addressed to a multicast IP address
(sometime they might be addressed to the unicast address of a specific
receiver). In the following, for simplicity we will refer to both data
and session control packets as downstream-traveling packets, or simply
downstream packets.
As a general rule, feedback packets travel upstream (from receivers to
the sender) and are addressed to the unicast address of the sender.
Sometimes, however, they might be addressed to a multicast IP address or
to the unicast address of a receiver or also the the unicast address of
some different node (an intermediate node that provides recovery
services or a neighboring router).
The FEC-related information that can be present in downstream packets
can be classified as follows:
1) FEC Encoding Identifier
Identifies the FEC encoding being used and has the purpose of
allowing receivers to select the appropriate FEC decoder. As a
general rule, the "FEC Encoding Identifier" MUST be the same for a
given session, i.e., for all transmission of data related to a
particular object, but MAY vary across different transmissions of
data about different objects in different sessions, even if
transmitted using the same set of multicast groups and/or using a
single upper-layer session.
2) FEC payload ID
Identifies the symbol(s) in the payload of the packet. The content
of this piece of information depends on the encoder being used
Luby/Vicisano/Gemmell/Rizzo/Handley/Crowcroft Section 1. [Page 2]
^L
INTERNET-DRAFT Expires: January 2002 July 2001
(e.g. in Block FEC codes this may be the combination of block
index and encoding symbol identifier; in ideal expandable FEC
codes this may be just a flat encoding symbol identifier).
3) FEC Object Transmission Information
This is information regarding the encoding of a specific object
needed by the FEC decoder (e.g. for Block FEC codes this may be
the combination of block length and object length). This might
also include general parameters of the FEC encoder. Note that, in
strict terms, the "FEC Encoding Identifier" belongs to this class
of information, however, for practical purposes, we will consider
it separately.
All the classes of information above, except 2), can either be
transmitted within the transport session (using protocol packet-header
fields) or out of band. The information described in 2) MUST be
transmitted in data-packet header fields, as it provides a description
of the data contained in the packet. In the following we will specify
the content of 1), 2) and 3) regardless of whether these pieces of
information are transmitted in protocol packets or out of band. This
document neither specifies out-of-band methods to transport the
information nor does it specify the way out-of-band information is
associated with packet payloads. This last task is devolved to an upper-
layer protocol.
Within the context of FEC repair schemes, feedback packets are
(optionally) used to request FEC retransmission. The FEC-related
information present in feedback packets usually contains an FEC Block
Identifier, that defines the block that is being repaired, and the
number of Repair Symbols requested. Although this is the most common
case, variants are possible in which the receivers provide more specific
information about the Repair Symbols requested (e.g. an index range or a
list of symbols accepted). It is also possible to include multiple of
these request in a single feedback packet.
This document does not provide any detail about the format of FEC
information in feedback packets.
1.1. FEC Encoding Identifier
This is a numeric index that identifies a specific FEC scheme OR a class
of encoding schemes that share the same format of "FEC Payload ID" and
"FEC Object Transmission Information".
Luby/Vicisano/Gemmell/Rizzo/Handley/Crowcroft Section 1.1. [Page 3]
^L
INTERNET-DRAFT Expires: January 2002 July 2001
The FEC Encoding Identifier identifies a specific FEC scheme when the
encoding scheme is formally and fully specified, in a way that
independent implementors can implement both encoder and decoder from the
specification. Companion documents of this specification may specify
such FEC schemes and associate them with "FEC Encoding Identifier"
values. These documents MUST also specify a correspondent format for the
"FEC Payload ID" and "FEC Object Transmission Information". Currently
FEC Encoding Identifiers in the range 0-127 are reserved for this class
of encoding schemes (fully-specified schemes).
It is possible that a FEC scheme cannot be completely specified or that
such a specification is simply not available or also that a party exists
that owns the encoding scheme and it is not willing to disclose its
algorithm. We refer to these encoding schemes as "Under-Specified"
schemes. Under-specified schemes can still be identified as follows:
o A format of the fields "FEC Payload ID" and "FEC Object Transmission
Information" MUST be defined for the encoding scheme.
o A value of "FEC Encoding Identifier" MUST be reserved and associated
to the format definitions above. An already reserved "FEC Encoding
Identifier" MUST be reused if it is associated to the same format
of "FEC Payload ID" and "FEC Object Transmission Information" as the
ones needed for the new under-specified FEC scheme.
o A value of "FEC Encoding Name" must be reserved (see below).
An Under-specified FEC scheme is completely identified by the tuple (FEC
Encoding Identifier, FEC Encoding Name). The tuple MUST identify a
single scheme that has at least one implementation. The party that owns
this tuple MUST be able to provide information on how to obtain the
under-specified FEC scheme identified by the tuple (e.g. a pointer to a
publicly available reference-implementation or the name and contacts of
a company that sells it, either separately or embedded in another
product).
"FEC Encoding Names" are numeric identifiers scoped by a FEC Encoding
Identifier.
The FEC Encoding Name MUST be part of the "FEC Object Transmission
Information" and must be communicated to receivers together with the FEC
Encoding Identifier.
Different FEC schemes that share the same FEC Encoding Identifier -- but
have different FEC Encoding Names -- also share the same format of FEC
Payload ID and FEC Object Transmission Information.
Luby/Vicisano/Gemmell/Rizzo/Handley/Crowcroft Section 1.1. [Page 4]
^L
INTERNET-DRAFT Expires: January 2002 July 2001
This specification reserves the range 0-127 of FEC Encoding Identifiers
for fully-specified encoding schemes and the range 128-255 for under-
specified encoding schemes.
1.2. FEC Payload ID and FEC Object Transmission Information
A document that specifies an encoding scheme and reserves a value
of FEC Encoding Identifier MUST define a packet-field format for FEC
Payload ID and FEC Object Transmission Information according to the need
of the encoding scheme. This also applies to documents that reserves
values of FEC Encoding Identifiers for under-specified encoding schemes.
In this case the FEC Object Transmission Information must also include a
field to contain the "FEC Encoding Name".
A packet field definition of FEC Object Transmission Information MUST be
provided despite the fact that a protocol instantiation may decide to
communicate this information out of band.
All packet field definitions (FEC Payload ID and FEC Object Transmission
Information) MUST be fully specified at the level of bit-fields and they
must have a length that is a multiple of a 4-byte word (this is to
facilitate the alignment of packet fields in protocol instantiations).
Note that the specification of FEC Payload ID MUST allow an
implementation-independent identification of the packet payload even in
the case of Under-Specified encoding schemes.
2. Preassigned FEC Encoding Identifiers
This section specifies the FEC Encoding Identifier and the relative
packets field for a number of known schemes that follow under the class
of under-specified FEC schemes. Others may be specified in companion
documents.
2.1. Small Block, Large Block and Expandable FEC Codes
This section reserves a FEC Encoding Identifier for the families of
codes described in [1], and specifies the relative packet fields.
Under-specified FEC schemes that belong to this class MUST use this
identifier and packet field definitions.
The FEC Encoding Identifier for under specified codes assigned to Small
Block, Large Block, and Expandable FEC Codes is 128.
Luby/Vicisano/Gemmell/Rizzo/Handley/Crowcroft Section 2.1. [Page 5]
^L
INTERNET-DRAFT Expires: January 2002 July 2001
The FEC Payload ID is composed of an encoding symbol identifier and an
encoding block number structured as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| encoding block number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| encoding symbol ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In addition, a one bit FEC Encoding Flag MAY be included, and this flag
indicates whether the encoding symbol(s) in the payload of the packet
are source symbol(s) or redundant symbol(s).
The FEC Object Transmission Information has the following structure:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC Encoding Name | Object Length (MSB) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Object Length (LSB) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Block Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note that this structure limits the range of possible FEC Encoding Names
to 0-:-65536, despite the fact that the FEC Object Transmission
Information can also be transmitted out of band.
The Object Length, composed of a Most Significant Bytes portion (MSB)
and a Least Significant Bytes portion (LSB), is expressed in bytes.
2.2. Small Block Systematic FEC Codes
The following definitions apply to systematic codes of small length
(total block length < 2^16).
The FEC Encoding Identifier for under specified codes assigned to Small
Block Systematic FEC Codes is 129.
Although these codes can generally be accommodated by the FEC Encoding
Luby/Vicisano/Gemmell/Rizzo/Handley/Crowcroft Section 2.2. [Page 6]
^L
INTERNET-DRAFT Expires: January 2002 July 2001
Identifier described in Section 2.1, a specific Encoding-ID is defined
for systematic codes to allow better flexibility and to retain header
compactness. The small source block length and small exapansion factor
that often characterize systematic codes may require that the data
source changes frequently the source block length. To allow the dynamic
variation of the source block length and to communicate it to the
receivers with low overhead, the block length is included in the FEC
Payload ID.
The FEC Payload ID is composed of the encoding block number, the
encoding symbol identifier and the block length:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| encoding block number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source block length | encoding symbol ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The FEC Object Transmission Information, when used, has the following
structure:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC Encoding Name | Number of redundant symbols |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
When variable block-length is used, the number of redundant symbols is
to be interpreted as a maximum value (upper bound). This field is
provided as an indication to allow receives to preallocate a decoder
suitable for all the object blocks.
Note that this structure limits the range of possible FEC Encoding Names
to 0-:-65536, despite the FEC Object Transmission Information can also
be transmitted out of band.
3. IANA Considerations
Values of FEC Encoding Identifiers and FEC Encoding Names are subject to
IANA registration. FEC Encoding Identifiers and FEC Encoding Names are
hierarchical: FEC Encoding Identifiers (at the top level) scope ranges
Luby/Vicisano/Gemmell/Rizzo/Handley/Crowcroft Section 3. [Page 7]
^L
INTERNET-DRAFT Expires: January 2002 July 2001
of FEC Encoding Names. Not all FEC Encoding Identifiers have a
corresponding FEC Encoding Name scope (see below).
A FEC Encoding Identifier is a numeric non-negative index. Value from 0
to 127 are reserved for FEC encoders that are fully specified, as
described in section 3.1. The assignment of a FEC Encoding Identifier in
this range can only be granted if the requestor can provide such a
specification published as an IETF RFC. Values greater than 127 can be
assigned to under-specified encoding schemes. Note: this specification
already assigns the values 128 and 129.
In any case values of FEC Encoding Identifiers can only be assigned if
the required FEC packet fields corresponding to it (see section 1.2) are
specified in a RFC.
Each FEC Encoding Identifier assigned to an under-specified encoding
scheme scopes an independent range of FEC Encoding Names (i.e. the same
value of FEC Encoding Name can be reused for different FEC Encoding
Identifiers). An FEC Encoding Name is a numeric non-negative index. The
document that reserves a FEC Encoding Identifier MAY also specify a
range for the subordinate FEC Encoding Names.
Under the scope of a FEC Encoding Identifier, FEC Encoding Names are
assigned on a First Come First Served base to requestors that are able
to provide point of contact information and a pointer to publicly
accessible documentation describing the FEC scheme and ways to obtain it
(e.g. a pointer to a publicly available reference-implementation or the
name and contacts of a company that sells it, either separately or
embedded in another product). The requestor is responsible for keeping
this information up to date.
4. Acknowledgments
Brian Adamson contributed to this document by shaping Section 2.2 and
providing general feedback. We also wish to thank Vincent Roca for his
comments.
5. References
[1] Luby, M., Vicisano, Gemmell, J., L., Rizzo, L., Handley, M.,
Crowcroft, J., "The use of Forward Error Correction in Reliable
Multicast", Internet draft draft-ietf-rmt-info-fec-00.txt, November
2000.
Luby/Vicisano/Gemmell/Rizzo/Handley/Crowcroft Section 5. [Page 8]
^L
INTERNET-DRAFT Expires: January 2002 July 2001
6. Authors' Addresses
Michael Luby
luby@digitalfountain.com
Digital Fountain, Inc.
39141 Civic Center Drive
Suite 300
Fremont, CA 94538
Lorenzo Vicisano
lorenzo@cisco.com
cisco Systems, Inc.
170 West Tasman Dr.,
San Jose, CA, USA, 95134
Jim Gemmell
jgemmell@microsoft.com
Microsoft Research
301 Howard St., #830
San Francisco, CA, USA, 94105
Luigi Rizzo
luigi@iet.unipi.it
ACIRI, 1947 Center St., Berkeley CA 94704
and
Dip. di Ing. dell'Informazione
Universita` di Pisa
via Diotisalvi 2, 56126 Pisa, Italy
Mark Handley
mjh@aciri.org
ACIRI
1947 Center St.
Berkeley CA, USA, 94704
Jon Crowcroft
J.Crowcroft@cs.ucl.ac.uk
Department of Computer Science
University College London
Gower Street,
London WC1E 6BT, UK
Luby/Vicisano/Gemmell/Rizzo/Handley/Crowcroft Section 6. [Page 9]
^L
INTERNET-DRAFT Expires: January 2002 July 2001
7. Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are included
on all such copies and derivative works. However, this document itself
may not be modified in any way, such as by removing the copyright notice
or references to the Internet Society or other Internet organizations,
except as needed for the purpose of developing Internet standards in
which case the procedures for copyrights defined in the Internet
languages other than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE."
Luby/Vicisano/Gemmell/Rizzo/Handley/Crowcroft Section 7. [Page 10]
^L
INTERNET-DRAFT Expires: January 2002 July 2001
Luby/Vicisano/Gemmell/Rizzo/Handley/Crowcroft Section 7. [Page 11]
--==_Exmh_5297534880
Content-Type: application/postscript ; name="draft-ietf-rmt-bb-fec-03.ps"
Content-Description: draft-ietf-rmt-bb-fec-03.ps
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="draft-ietf-rmt-bb-fec-03.ps"
JSFQUy1BZG9iZS0zLjAKJSVDcmVhdG9yOiBncm9mZiB2ZXJzaW9uIDEuMTYuMQolJUNyZWF0
aW9uRGF0ZTogVGh1IEp1bCAxOSAxNzowODoxNCAyMDAxCiUlRG9jdW1lbnROZWVkZWRSZXNv
dXJjZXM6IGZvbnQgQ291cmllci1Cb2xkCiUlKyBmb250IFRpbWVzLUJvbGQKJSUrIGZvbnQg
VGltZXMtUm9tYW4KJSUrIGZvbnQgQ291cmllcgolJURvY3VtZW50U3VwcGxpZWRSZXNvdXJj
ZXM6IHByb2NzZXQgZ3JvcHMgMS4xNiAxCiUlUGFnZXM6IDkKJSVQYWdlT3JkZXI6IEFzY2Vu
ZAolJU9yaWVudGF0aW9uOiBQb3J0cmFpdAolJUVuZENvbW1lbnRzCiUlQmVnaW5Qcm9sb2cK
JSVCZWdpblJlc291cmNlOiBwcm9jc2V0IGdyb3BzIDEuMTYgMQovc2V0cGFja2luZyB3aGVy
ZXsKcG9wCmN1cnJlbnRwYWNraW5nCnRydWUgc2V0cGFja2luZwp9aWYKL2dyb3BzIDEyMCBk
aWN0IGR1cCBiZWdpbgovU0MgMzIgZGVmCi9BL3Nob3cgbG9hZCBkZWYKL0J7MCBTQyAzIC0x
IHJvbGwgd2lkdGhzaG93fWJpbmQgZGVmCi9DezAgZXhjaCBhc2hvd31iaW5kIGRlZgovRHsw
IGV4Y2ggMCBTQyA1IDIgcm9sbCBhd2lkdGhzaG93fWJpbmQgZGVmCi9FezAgcm1vdmV0byBz
aG93fWJpbmQgZGVmCi9GezAgcm1vdmV0byAwIFNDIDMgLTEgcm9sbCB3aWR0aHNob3d9Ymlu
ZCBkZWYKL0d7MCBybW92ZXRvIDAgZXhjaCBhc2hvd31iaW5kIGRlZgovSHswIHJtb3ZldG8g
MCBleGNoIDAgU0MgNSAyIHJvbGwgYXdpZHRoc2hvd31iaW5kIGRlZgovSXswIGV4Y2ggcm1v
dmV0byBzaG93fWJpbmQgZGVmCi9KezAgZXhjaCBybW92ZXRvIDAgU0MgMyAtMSByb2xsIHdp
ZHRoc2hvd31iaW5kIGRlZgovS3swIGV4Y2ggcm1vdmV0byAwIGV4Y2ggYXNob3d9YmluZCBk
ZWYKL0x7MCBleGNoIHJtb3ZldG8gMCBleGNoIDAgU0MgNSAyIHJvbGwgYXdpZHRoc2hvd31i
aW5kIGRlZgovTXtybW92ZXRvIHNob3d9YmluZCBkZWYKL057cm1vdmV0byAwIFNDIDMgLTEg
cm9sbCB3aWR0aHNob3d9YmluZCBkZWYKL097cm1vdmV0byAwIGV4Y2ggYXNob3d9YmluZCBk
ZWYKL1B7cm1vdmV0byAwIGV4Y2ggMCBTQyA1IDIgcm9sbCBhd2lkdGhzaG93fWJpbmQgZGVm
Ci9Re21vdmV0byBzaG93fWJpbmQgZGVmCi9Se21vdmV0byAwIFNDIDMgLTEgcm9sbCB3aWR0
aHNob3d9YmluZCBkZWYKL1N7bW92ZXRvIDAgZXhjaCBhc2hvd31iaW5kIGRlZgovVHttb3Zl
dG8gMCBleGNoIDAgU0MgNSAyIHJvbGwgYXdpZHRoc2hvd31iaW5kIGRlZgovU0Z7CmZpbmRm
b250IGV4Y2gKW2V4Y2ggZHVwIDAgZXhjaCAwIGV4Y2ggbmVnIDAgMF1tYWtlZm9udApkdXAg
c2V0Zm9udApbZXhjaC9zZXRmb250IGN2eF1jdnggYmluZCBkZWYKfWJpbmQgZGVmCi9NRnsK
ZmluZGZvbnQKWzUgMiByb2xsCjAgMyAxIHJvbGwKbmVnIDAgMF1tYWtlZm9udApkdXAgc2V0
Zm9udApbZXhjaC9zZXRmb250IGN2eF1jdnggYmluZCBkZWYKfWJpbmQgZGVmCi9sZXZlbDAg
MCBkZWYKL1JFUyAwIGRlZgovUEwgMCBkZWYKL0xTIDAgZGVmCi9NQU5VQUx7CnN0YXR1c2Rp
Y3QgYmVnaW4vbWFudWFsZmVlZCB0cnVlIHN0b3JlIGVuZAp9YmluZCBkZWYKL1BMR3sKZ3Nh
dmUgbmV3cGF0aCBjbGlwcGF0aCBwYXRoYmJveCBncmVzdG9yZQpleGNoIHBvcCBhZGQgZXhj
aCBwb3AKfWJpbmQgZGVmCi9CUHsKL2xldmVsMCBzYXZlIGRlZgoxIHNldGxpbmVjYXAKMSBz
ZXRsaW5lam9pbgo3MiBSRVMgZGl2IGR1cCBzY2FsZQpMU3sKOTAgcm90YXRlCn17CjAgUEwg
dHJhbnNsYXRlCn1pZmVsc2UKMSAtMSBzY2FsZQp9YmluZCBkZWYKL0VQewpsZXZlbDAgcmVz
dG9yZQpzaG93cGFnZQp9YmluZCBkZWYKL0RBewpuZXdwYXRoIGFyY24gc3Ryb2tlCn1iaW5k
IGRlZgovU057CnRyYW5zZm9ybQouMjUgc3ViIGV4Y2ggLjI1IHN1YiBleGNoCnJvdW5kIC4y
NSBhZGQgZXhjaCByb3VuZCAuMjUgYWRkIGV4Y2gKaXRyYW5zZm9ybQp9YmluZCBkZWYKL0RM
ewpTTgptb3ZldG8KU04KbGluZXRvIHN0cm9rZQp9YmluZCBkZWYKL0RDewpuZXdwYXRoIDAg
MzYwIGFyYyBjbG9zZXBhdGgKfWJpbmQgZGVmCi9UTSBtYXRyaXggZGVmCi9ERXsKVE0gY3Vy
cmVudG1hdHJpeCBwb3AKdHJhbnNsYXRlIHNjYWxlIG5ld3BhdGggMCAwIC41IDAgMzYwIGFy
YyBjbG9zZXBhdGgKVE0gc2V0bWF0cml4Cn1iaW5kIGRlZgovUkMvcmN1cnZldG8gbG9hZCBk
ZWYKL1JML3JsaW5ldG8gbG9hZCBkZWYKL1NUL3N0cm9rZSBsb2FkIGRlZgovTVQvbW92ZXRv
IGxvYWQgZGVmCi9DTC9jbG9zZXBhdGggbG9hZCBkZWYKL0ZMewpjdXJyZW50Z3JheSBleGNo
IHNldGdyYXkgZmlsbCBzZXRncmF5Cn1iaW5kIGRlZgovQkwvZmlsbCBsb2FkIGRlZgovTFcv
c2V0bGluZXdpZHRoIGxvYWQgZGVmCi9SRXsKZmluZGZvbnQKZHVwIG1heGxlbmd0aCAxIGlu
ZGV4L0ZvbnROYW1lIGtub3duIG5vdHsxIGFkZH1pZiBkaWN0IGJlZ2luCnsKMSBpbmRleC9G
SUQgbmV7ZGVmfXtwb3AgcG9wfWlmZWxzZQp9Zm9yYWxsCi9FbmNvZGluZyBleGNoIGRlZgpk
dXAvRm9udE5hbWUgZXhjaCBkZWYKY3VycmVudGRpY3QgZW5kIGRlZmluZWZvbnQgcG9wCn1i
aW5kIGRlZgovREVGUyAwIGRlZgovRUJFR0lOewptb3ZldG8KREVGUyBiZWdpbgp9YmluZCBk
ZWYKL0VFTkQvZW5kIGxvYWQgZGVmCi9DTlQgMCBkZWYKL2xldmVsMSAwIGRlZgovUEJFR0lO
ewovbGV2ZWwxIHNhdmUgZGVmCnRyYW5zbGF0ZQpkaXYgMyAxIHJvbGwgZGl2IGV4Y2ggc2Nh
bGUKbmVnIGV4Y2ggbmVnIGV4Y2ggdHJhbnNsYXRlCjAgc2V0Z3JheQowIHNldGxpbmVjYXAK
MSBzZXRsaW5ld2lkdGgKMCBzZXRsaW5lam9pbgoxMCBzZXRtaXRlcmxpbWl0CltdMCBzZXRk
YXNoCi9zZXRzdHJva2VhZGp1c3Qgd2hlcmV7CnBvcApmYWxzZSBzZXRzdHJva2VhZGp1c3QK
fWlmCi9zZXRvdmVycHJpbnQgd2hlcmV7CnBvcApmYWxzZSBzZXRvdmVycHJpbnQKfWlmCm5l
d3BhdGgKL0NOVCBjb3VudGRpY3RzdGFjayBkZWYKdXNlcmRpY3QgYmVnaW4KL3Nob3dwYWdl
e31kZWYKfWJpbmQgZGVmCi9QRU5EewpjbGVhcgpjb3VudGRpY3RzdGFjayBDTlQgc3Vie2Vu
ZH1yZXBlYXQKbGV2ZWwxIHJlc3RvcmUKfWJpbmQgZGVmCmVuZCBkZWYKL3NldHBhY2tpbmcg
d2hlcmV7CnBvcApzZXRwYWNraW5nCn1pZgolJUVuZFJlc291cmNlCiUlSW5jbHVkZVJlc291
cmNlOiBmb250IENvdXJpZXItQm9sZAolJUluY2x1ZGVSZXNvdXJjZTogZm9udCBUaW1lcy1C
b2xkCiUlSW5jbHVkZVJlc291cmNlOiBmb250IFRpbWVzLVJvbWFuCiUlSW5jbHVkZVJlc291
cmNlOiBmb250IENvdXJpZXIKZ3JvcHMgYmVnaW4vREVGUyAxIGRpY3QgZGVmIERFRlMgYmVn
aW4vdXsuMDAxIG11bH1iaW5kIGRlZiBlbmQvUkVTIDcyCmRlZi9QTCA3OTIgZGVmL0xTIGZh
bHNlIGRlZi9FTkMwWy9hc2NpaWNpcmN1bS9hc2NpaXRpbGRlL1NjYXJvbi9aY2Fyb24KL3Nj
YXJvbi96Y2Fyb24vWWRpZXJlc2lzL3RyYWRlbWFyay9xdW90ZXNpbmdsZS8ubm90ZGVmLy5u
b3RkZWYvLm5vdGRlZgovLm5vdGRlZi8ubm90ZGVmLy5ub3RkZWYvLm5vdGRlZi8ubm90ZGVm
Ly5ub3RkZWYvLm5vdGRlZi8ubm90ZGVmLy5ub3RkZWYKLy5ub3RkZWYvLm5vdGRlZi8ubm90
ZGVmLy5ub3RkZWYvLm5vdGRlZi8ubm90ZGVmLy5ub3RkZWYvLm5vdGRlZi8ubm90ZGVmCi8u
bm90ZGVmLy5ub3RkZWYvc3BhY2UvZXhjbGFtL3F1b3RlZGJsL251bWJlcnNpZ24vZG9sbGFy
L3BlcmNlbnQKL2FtcGVyc2FuZC9xdW90ZXJpZ2h0L3BhcmVubGVmdC9wYXJlbnJpZ2h0L2Fz
dGVyaXNrL3BsdXMvY29tbWEvaHlwaGVuCi9wZXJpb2Qvc2xhc2gvemVyby9vbmUvdHdvL3Ro
cmVlL2ZvdXIvZml2ZS9zaXgvc2V2ZW4vZWlnaHQvbmluZS9jb2xvbgovc2VtaWNvbG9uL2xl
c3MvZXF1YWwvZ3JlYXRlci9xdWVzdGlvbi9hdC9BL0IvQy9EL0UvRi9HL0gvSS9KL0svTC9N
L04vTwovUC9RL1IvUy9UL1UvVi9XL1gvWS9aL2JyYWNrZXRsZWZ0L2JhY2tzbGFzaC9icmFj
a2V0cmlnaHQvY2lyY3VtZmxleAovdW5kZXJzY29yZS9xdW90ZWxlZnQvYS9iL2MvZC9lL2Yv
Zy9oL2kvai9rL2wvbS9uL28vcC9xL3Ivcy90L3Uvdi93L3gveQovei9icmFjZWxlZnQvYmFy
L2JyYWNlcmlnaHQvdGlsZGUvLm5vdGRlZi9xdW90ZXNpbmdsYmFzZS9ndWlsbGVtb3RsZWZ0
Ci9ndWlsbGVtb3RyaWdodC9idWxsZXQvZmxvcmluL2ZyYWN0aW9uL3BlcnRob3VzYW5kL2Rh
Z2dlci9kYWdnZXJkYmwKL2VuZGFzaC9lbWRhc2gvZmYvZmkvZmwvZmZpL2ZmbC9kb3RsZXNz
aS9kb3RsZXNzai9ncmF2ZS9odW5nYXJ1bWxhdXQKL2RvdGFjY2VudC9icmV2ZS9jYXJvbi9y
aW5nL29nb25lay9xdW90ZWRibGxlZnQvcXVvdGVkYmxyaWdodC9vZS9sc2xhc2gKL3F1b3Rl
ZGJsYmFzZS9PRS9Mc2xhc2gvLm5vdGRlZi9leGNsYW1kb3duL2NlbnQvc3RlcmxpbmcvY3Vy
cmVuY3kveWVuCi9icm9rZW5iYXIvc2VjdGlvbi9kaWVyZXNpcy9jb3B5cmlnaHQvb3JkZmVt
aW5pbmUvZ3VpbHNpbmdsbGVmdAovbG9naWNhbG5vdC9taW51cy9yZWdpc3RlcmVkL21hY3Jv
bi9kZWdyZWUvcGx1c21pbnVzL3R3b3N1cGVyaW9yCi90aHJlZXN1cGVyaW9yL2FjdXRlL211
L3BhcmFncmFwaC9wZXJpb2RjZW50ZXJlZC9jZWRpbGxhL29uZXN1cGVyaW9yCi9vcmRtYXNj
dWxpbmUvZ3VpbHNpbmdscmlnaHQvb25lcXVhcnRlci9vbmVoYWxmL3RocmVlcXVhcnRlcnMK
L3F1ZXN0aW9uZG93bi9BZ3JhdmUvQWFjdXRlL0FjaXJjdW1mbGV4L0F0aWxkZS9BZGllcmVz
aXMvQXJpbmcvQUUKL0NjZWRpbGxhL0VncmF2ZS9FYWN1dGUvRWNpcmN1bWZsZXgvRWRpZXJl
c2lzL0lncmF2ZS9JYWN1dGUvSWNpcmN1bWZsZXgKL0lkaWVyZXNpcy9FdGgvTnRpbGRlL09n
cmF2ZS9PYWN1dGUvT2NpcmN1bWZsZXgvT3RpbGRlL09kaWVyZXNpcwovbXVsdGlwbHkvT3Ns
YXNoL1VncmF2ZS9VYWN1dGUvVWNpcmN1bWZsZXgvVWRpZXJlc2lzL1lhY3V0ZS9UaG9ybgov
Z2VybWFuZGJscy9hZ3JhdmUvYWFjdXRlL2FjaXJjdW1mbGV4L2F0aWxkZS9hZGllcmVzaXMv
YXJpbmcvYWUvY2NlZGlsbGEKL2VncmF2ZS9lYWN1dGUvZWNpcmN1bWZsZXgvZWRpZXJlc2lz
L2lncmF2ZS9pYWN1dGUvaWNpcmN1bWZsZXgvaWRpZXJlc2lzCi9ldGgvbnRpbGRlL29ncmF2
ZS9vYWN1dGUvb2NpcmN1bWZsZXgvb3RpbGRlL29kaWVyZXNpcy9kaXZpZGUvb3NsYXNoCi91
Z3JhdmUvdWFjdXRlL3VjaXJjdW1mbGV4L3VkaWVyZXNpcy95YWN1dGUvdGhvcm4veWRpZXJl
c2lzXWRlZgovQ291cmllckAwIEVOQzAvQ291cmllciBSRS9UaW1lcy1Sb21hbkAwIEVOQzAv
VGltZXMtUm9tYW4gUkUKL1RpbWVzLUJvbGRAMCBFTkMwL1RpbWVzLUJvbGQgUkUvQ291cmll
ci1Cb2xkQDAgRU5DMC9Db3VyaWVyLUJvbGQgUkUKJSVFbmRQcm9sb2cKJSVQYWdlOiAxIDEK
JSVCZWdpblBhZ2VTZXR1cApCUAolJUVuZFBhZ2VTZXR1cAovRjAgMTAvQ291cmllci1Cb2xk
QDAgU0YoSW50ZXJuZXQgRW5naW5lZXJpbmcgVGFzayBGb3JjZSk3MiA4NSBRKFJNVCBXRykK
MjA5Ljk5OSBFIDIwMy45OTkoSU5URVJORVQtRFJBRlQgTS5MdWJ5L0RpZ2l0YWwpNzIgOTgg
UihGb3VudGFpbik2IEUKMTY3Ljk5OShkcmFmdC1pZXRmLXJtdC1iYi1mZWMtMDMucHMgTC5W
aWNpc2Fuby9DaXNjbyk3MiAxMTEgUgooSi5HZW1tZWxsL01pY3Jvc29mdCkzODkuOTk5IDEy
NCBRKEwuUml6em8vQUNJUkkgYW5kIFVuaXYuIFBpc2EpMzM1Ljk5OQoxMzcgUShNLkhhbmRs
ZXkvQUNJUkkpNDEzLjk5OSAxNTAgUShKLiBDcm93Y3JvZnQvVUNMKTQwNy45OTkgMTYzIFEK
KDE5IEp1bHkgMjAwMSk0MzEuOTk5IDE3NiBRKEV4cGlyZXM6IEphbnVhcnkgMjAwMikzNzcu
OTk5IDE4OSBRL0YxIDE0Ci9UaW1lcy1Cb2xkQDAgU0YoUk1UIEJCIEYpMTU5LjE0NCAyMTQg
UShvcndhcmQgRXJyKS0uMzUgRShvciBDb3JyKS0uMjUyCkUoZWN0aW9uIENvZGVzKS0uMjUy
IEUvRjIgMTEvVGltZXMtUm9tYW5AMCBTRihUaGlzIGRvY3VtZW50IGlzIGFuIEludGVyXApu
ZXQtRHJhZnQgYW5kIGlzIGluIGZ1bGwgY29uZm9ybWFuY2Ugd2l0aCBhbGwgcHJvKTcyIDIz
MyBRCih2aXNpb25zIG9mIFNlY3Rpb24gMTAgb2YpLS4xNjUgRShSRkMyMDI2Lik3MiAyNDYg
UQooSW50ZXJuZXQtRHJhZnRzIGFyZSB3KTcyIDI3MiBRCihvcmtpbmcgZG9jdW1lbnRzIG9m
IHRoZSBJbnRlcm5ldCBFbmdpbmVlcmluZyBUKS0uMTEgRShhc2sgRiktLjg4IEUKKG9yY2Ug
XChJRVRGXCksIGl0cyBhcmVhcywpLS4xNjUgRShhbmQgaXRzIHcpNzIgMjg1IFEob3JraW5n
IGdyb3Vwcy4pCi0uMTEgRShOb3RlIHRoYXQgb3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3Ry
aWIpNS41IEUodXRlIHcpLS4yMiBFCihvcmtpbmcgZG9jdW1lbnRzIGFzKS0uMTEgRShJbnRl
cm5ldC1EcmFmdHMuKTcyIDI5OCBRCihJbnRlcm5ldC1EcmFmdHMgYXJlIHYpNzIgMzI0IFEK
KGFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhzIGFuZCBtYXkgYmUgdXBkYXRlZCwg
cmVwbGFjZWQsIG9yKS0uMjc1CkUob2Jzb2xldGVkIGJ5IG90aGVyIGRvY3VtZW50cyBhdCBh
bik3MiAzMzcgUSAyLjc1KHl0KS0uMTY1IEcgMi43NQooaW1lLiBJdCktMi43NSBGKGlzIGlu
YXBwcm9wcmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBhcyByZWZlcmVuY2UpCjIuNzUg
RShtYXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyBhICJ3KTcyIDM1MCBR
CihvcmsgaW4gcHJvZ3Jlc3MiLiktLjExIEUKKFRoZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJu
ZXQtRHJhZnRzIGNhbiBiZSBhY2Nlc3NlZCBhdCBodHRwOi8vd3d3KTcyCjM3NiBRKC5pZXRm
Lm9yKS0uNzE1IEUoZy9pZXRmLzFpZC1hYnN0cmFjdHMudHh0KS0uMTk4IEUgMS43NiAtLjg4
KFRvIHYpCjcyIDQwMiBUKGllKS44OCBFIDIuNzUod3QpLS4yNzUgRyhoZSBsaXN0IEludGVy
bmV0LURyYWZ0IFNoYWRvKS0yLjc1IEUKMi43NSh3RCktLjI3NSBHKGlyZWN0b3JpZXMsIHNl
ZSBodHRwOi8vd3d3KS0yLjc1IEUoLmlldGYub3IpLS43MTUgRQooZy9zaGFkbyktLjE5OCBF
IC0uNzE1KHcuKS0uMjc1IEcoaHRtbC4pLjcxNSBFCihUaGlzIGRvY3VtZW50IGlzIGEgcHJv
ZHVjdCBvZiB0aGUgSUVURiBSTVQgV0cuKTcyIDQyOCBRCihDb21tZW50cyBzaG91bGQgYmUg
YWRkcmVzc2VkIHRvIHRoZSk1LjUgRShhdXRob3JzLCBvciB0aGUgV0cnKTcyIDQ0MSBRCjIu
NzUoc20pLS42MDUgRyhhaWxpbmcgbGlzdCBhdCBybXRAaXNpLmVkdS4pLTIuNzUgRS9GMyAx
MS9UaW1lcy1Cb2xkQDAKU0YoQWJzdHJhY3QpMjY3LjUzNCA0NzMgUSBGMihUaGlzIG1lbW8g
ZGVzY3JpYmVzIHRoZSBhYnN0cmFjdCBwYWNrKTk3CjQ5NS42IFEoZXQgZm9ybWF0cyBhbmQg
SUFOKS0uMTEgRSAyLjc1KEFyKS0uMzg1IEcgLS4xNjUoZWcpLTIuNzUgRwooaXN0cmF0aW9u
IHByb2NlZHVyZXMpLjE2NSBFKGZvciB1c2Ugb2YgRik5NyA1MDguNiBRKG9ydyktLjE2NSBF
CihhcmQgRXJyb3IgQ29ycmVjdGlvbiBcKEZFQ1wpIGNvZGVzIHdpdGhpbiB0aGUgY29udGUp
LS4xMSBFCih4dCBvZiByZWxpYWJsZSBJUCktLjE2NSBFKG11bHRpY2FzdCB0cmFuc3BvcnQu
KTk3IDUyMS42IFEKKFRoaXMgbWVtbyBzaG91bGQgYmUgcmVhZCBpbiBjb25qdW5jdGlvbiB3
aXRoIGFuZCB1c2VzIHRoZSk1LjUgRQoodGVybWlub2xvZ3kgb2YgdGhlIGNvbXBhbmlvbiBt
ZW1vIFsxXSwgd2hpY2ggZGVzY3JpYmVzIHRoZSB1c2Ugb2YgRik5Nwo1MzQuNiBRKG9ydykt
LjE2NSBFKGFyZCBFcnJvciktLjExIEUKKENvcnJlY3Rpb24gXChGRUNcKSBjb2RlcyB3aXRo
aW4gdGhlIGNvbnRlKTk3IDU0Ny42IFEKKHh0IG9mIHJlbGlhYmxlIElQIG11bHRpY2FzdCB0
cmFuc3BvcnQgYW5kKS0uMTY1IEUocHJvKTk3IDU2MC42IFEKKHZpZGVzIGFuIGludHJvZHVj
dGlvbiB0byBzb21lIGNvbW1vbmx5IHVzZWQgRkVDIGNvZGVzLiktLjE2NSBFIEYzKDEuKTcy
CjU5OS42IFEgRjEoRkVDIEFic3RyYWN0IFApNS41IEUoYWNrKS0uMTQgRQooZXQgRmllbGRz
IGFuZCBPdXQtb2YtQmFuZCBJbmYpLS4xNCBFKG9ybWF0aW9uKS0uMzUgRSBGMgooVGhpcyBz
ZWN0aW9uIHNwZWNpXDIxNGVzIHRoZSBpbmZvcm1hdGlvbiB0aGF0IHByb3RvY29sIHBhY2sp
NzIgNjE2LjIgUQooZXRzIG11c3QgY2FycnkgdG8gaW1wbGVtZW50IHRoZSB2KS0uMTEgRShh
cmlvdXMpLS4yNzUgRQooZm9ybXMgb2YgRkVDLWJhc2VkIHJlbGlhYmlsaXR5KTcyIDYyOS4y
IFEgNS41KC5BKS0uNzE1IEcKKHNlc3Npb24gaXMgZGVcMjE0bmVkIHRvIGJlIGFsbCB0aGUg
aW5mb3JtYXRpb24gYXNzb2NpYXRlZCB3aXRoIGEpLTIuNzUKRSh0cmFuc21pc3Npb24gb2Yg
ZGF0YSBhYm91dCBhIHBhcnRpY3VsYXIgb2JqZWN0IGJ5IGEgc2luZ2xlIHNlbmRlcik3Mgo2
NDIuMiBRIDUuNSguVCktLjYwNSBHKGhlcmUgYXJlIHRocmVlIGNsYXNzZXMgb2YpLTUuNSBF
KHBhY2spNzIgNjU1LjIgUQooZXRzIHRoYXQgbWF5IGNvbnRhaW4gRkVDIGluZm9ybWF0aW9u
IHdpdGhpbiBhIHNlc3Npb246IGRhdGEgcGFjayktLjExIEUKKGV0cywgc2Vzc2lvbi1jb250
cm9sIHBhY2spLS4xMSBFKGV0cyktLjExIEUoYW5kIGZlZWRiYWNrIHBhY2spNzIgNjY4LjIK
USAyLjc1KGV0cy4gVGhlKS0uMTEgRiAyLjc1KHlnKS0uMTY1IEcoZW5lcmFsbHkgY29udGFp
biBkaWYpLTIuNzUgRQooZmVyZW50IGtpbmRzIG9mIEZFQyBpbmZvcm1hdGlvbi4pLS4yNzUg
RShOb3RlIHRoYXQpNS41IEUKKHNvbWUgcHJvdG9jb2xzIGRvIG5vdCB1c2UgZmVlZGJhY2sg
cGFjayk3MiA2ODEuMiBRKGV0cy4pLS4xMSBFCihEYXRhIHBhY2spNzIgNzA3LjIgUShldHMg
bWF5IHNvbWV0aW1lIHNlcnYpLS4xMSBFIDIuNzUoZWEpLS4xNjUgRyAyLjc1CihzcyktMi43
NSBHKGVzc2lvbi1jb250cm9sIHBhY2spLTIuNzUgRQooZXRzIGFzIHdlbGw7IGJvdGggZGF0
YSBhbmQgc2Vzc2lvbi0pLS4xMSBFKGNvbnRyb2wgcGFjayk3MiA3MjAuMiBRCihldHMgZ2Vu
ZXJhbGx5IHRyYSktLjExIEUgLS4xNjUodmUpLS4yMiBHIDIuNzUobGQpLjE2NSBHIC0uMjc1
KG93KS0yLjc1CkcobnN0cmVhbSBcKGZyb20gdGhlIHNlbmRlciB0bykuMjc1IEUgLS4xMSh3
YSktLjI3NSBHKHJkcyByZWNlaSkuMTEgRQotLjE2NSh2ZSktLjI3NSBHKHJzXCkgYW5kIGFy
ZSkuMTY1IEUoTHVieS9WKTcyIDc2OSBRCihpY2lzYW5vL0dlbW1lbGwvUml6em8vSGFuZGxl
KS0uNjYgRSh5L0NybyktLjE2NSBFIDExNy4zNTYKKHdjcm9mdCBTZWN0aW9uKS0uMjc1IEYg
Mi43NSgxLiBbUCkyLjc1IEYoYWdlIDFdKS0uMTY1IEUgRVAKJSVQYWdlOiAyIDIKJSVCZWdp
blBhZ2VTZXR1cApCUAolJUVuZFBhZ2VTZXR1cAovRjAgMTEvVGltZXMtUm9tYW5AMCBTRihJ
TlRFUk5FVCk3MiA0OSBRIDcxLjU4NygtRFJBRlQgRXhwaXJlczopLTEuMDEyIEYKKEphbnVh
cnkgMjAwMikyLjc1IEUoSnVseSAyMDAxKTEyMy43MjYgRQooYWRkcmVzc2VkIHRvIGEgbXVs
dGljYXN0IElQIGFkZHJlc3MgXChzb21ldGltZSB0aGUpNzIgODUgUSAyLjc1KHltKQotLjE2
NSBHKGlnaHQgYmUgYWRkcmVzc2VkIHRvIHRoZSB1bmljYXN0IGFkZHJlc3Mgb2YgYSktMi43
NSBFCihzcGVjaVwyMTRjIHJlY2VpKTcyIDk4IFEgLS4xNjUodmUpLS4yNzUgRyhyXCkuIElu
IHRoZSBmb2xsbykuMTY1IEUKKHdpbmcsIGZvciBzaW1wbGljaXR5IHdlIHdpbGwgcmVmZXIg
dG8gYm90aCBkYXRhIGFuZCBzZXNzaW9uIGNvbnRyb2wpCi0uMjc1IEUocGFjayk3MiAxMTEg
UShldHMgYXMgZG8pLS4xMSBFKHduc3RyZWFtLXRyYSktLjI3NSBFIC0uMTY1KHZlKQotLjIy
IEcobGluZyBwYWNrKS4xNjUgRShldHMsIG9yIHNpbXBseSBkbyktLjExIEUod25zdHJlYW0g
cGFjayktLjI3NSBFCihldHMuKS0uMTEgRShBcyBhIGdlbmVyYWwgcnVsZSwgZmVlZGJhY2sg
cGFjayk3MiAxMzcgUShldHMgdHJhKS0uMTEgRQotLjE2NSh2ZSktLjIyIEcgMi43NShsdSku
MTY1IEcocHN0cmVhbSBcKGZyb20gcmVjZWkpLTIuNzUgRSAtLjE2NSh2ZSkKLS4yNzUgRyhy
cyB0byB0aGUgc2VuZGVyXCkgYW5kIGFyZSkuMTY1IEUKKGFkZHJlc3NlZCB0byB0aGUgdW5p
Y2FzdCBhZGRyZXNzIG9mIHRoZSBzZW5kZXIpNzIgMTUwIFEgMi43NSguUyktLjYwNSBHCihv
bWV0aW1lcywgaG8pLTIuNzUgRSh3ZSktLjI3NSBFIC0uMTY1KHZlKS0uMjc1IEcgLjg4IC0u
NDQociwgdCkuMTY1IEgKKGhlKS40NCBFIDIuNzUoeW0pLS4xNjUgRyhpZ2h0IGJlIGFkZHJl
c3NlZCB0byBhKS0yLjc1IEUKKG11bHRpY2FzdCBJUCBhZGRyZXNzIG9yIHRvIHRoZSB1bmlj
YXN0IGFkZHJlc3Mgb2YgYSByZWNlaSk3MiAxNjMgUQotLjE2NSh2ZSktLjI3NSBHIDIuNzUo
cm8pLjE2NSBHIDIuNzUocmEpLTIuNzUgRwoobHNvIHRoZSB0aGUgdW5pY2FzdCBhZGRyZXNz
IG9mIHNvbWUpLTIuNzUgRShkaWYpNzIgMTc2IFEKKGZlcmVudCBub2RlIFwoYW4gaW50ZXJt
ZWRpYXRlIG5vZGUgdGhhdCBwcm8pLS4yNzUgRSh2aWRlcyByZWNvKS0uMTY1IEUKLS4xNjUo
dmUpLS4xNjUgRyhyeSBzZXJ2aWNlcyBvciBhIG5laWdoYm9yaW5nIHJvdXRlclwpLikuMTY1
IEUKKFRoZSBGRUMtcmVsYXRlZCBpbmZvcm1hdGlvbiB0aGF0IGNhbiBiZSBwcmVzZW50IGlu
IGRvKTcyIDIwMiBRCih3bnN0cmVhbSBwYWNrKS0uMjc1IEUoZXRzIGNhbiBiZSBjbGFzc2lc
MjE0ZWQgYXMpLS4xMSBFKGZvbGxvKTcyIDIxNSBRCih3czopLS4yNzUgRSA3LjMzNygxXCkg
RkVDKTc0Ljc1IDI0NC42IFIoRW5jb2RpbmcgSWRlbnRpXDIxNGVyKTIuNzUgRQooSWRlbnRp
XDIxNGVzIHRoZSBGRUMgZW5jb2RpbmcgYmVpbmcgdXNlZCBhbmQgaGFzIHRoZSBwdXJwb3Nl
IG9mIGFsbG8pCjEwNSAyNjEuMiBRKHdpbmcgcmVjZWkpLS4yNzUgRSAtLjE2NSh2ZSktLjI3
NSBHKHJzIHRvIHNlbGVjdCkuMTY1IEUKKHRoZSBhcHByb3ByaWF0ZSBGRUMgZGVjb2Rlcikx
MDUgMjc0LjIgUSAyLjc1KC5BKS0uNjA1IEcgMi43NShzYWcpLTIuNzUKRyhlbmVyYWwgcnVs
ZSwgdGhlICJGRUMgRW5jb2RpbmcgSWRlbnRpXDIxNGVyIiBNVVNUIGJlKS0yLjc1IEUKKHRo
ZSBzYW1lIGZvciBhIGdpKTEwNSAyODcuMiBRIC0uMTY1KHZlKS0uMjc1IEcgMi43NShucyku
MTY1IEcoZXNzaW9uLCBcCmkuZS4sIGZvciBhbGwgdHJhbnNtaXNzaW9uIG9mIGRhdGEgcmVs
YXRlZCB0byBhIHBhcnRpY3VsYXIgb2JqZWN0LCktMi43NQpFIC0uMjIoYnUpMTA1IDMwMC4y
IFMgMi43NSh0TSkuMjIgRyAyLjMxIC0xLjE1NShBWSB2KS0yLjc1IEgKKGFyeSBhY3Jvc3Mg
ZGlmKS44OCBFKGZlcmVudCB0cmFuc21pc3Npb25zIG9mIGRhdGEgYWJvdXQgZGlmKS0uMjc1
IEUKKGZlcmVudCBvYmplY3RzIGluIGRpZiktLjI3NSBFKGZlcmVudCktLjI3NSBFKHNlc3Np
b25zLCBlKTEwNSAzMTMuMiBRCi0uMTY1KHZlKS0uMjc1IEcgMi43NShuaSkuMTY1IEcgMi43
NShmdCktMi43NSBHKHJhbnNtaXR0ZWQgdXNpbmcgdGhlIHNhXAptZSBzZXQgb2YgbXVsdGlj
YXN0IGdyb3VwcyBhbmQvb3IgdXNpbmcgYSBzaW5nbGUpLTIuNzUgRSh1cHBlcikxMDUgMzI2
LjIKUSgtbGF5ZXIgc2Vzc2lvbi4pLS4yMiBFIDcuMzM3KDJcKSBGRUMpNzQuNzUgMzQyLjgg
UihwYXlsb2FkIElEKTIuNzUgRQooSWRlbnRpXDIxNGVzIHRoZSBzeW1ib2xcKHNcKSBpbiB0
aGUgcGF5bG9hZCBvZiB0aGUgcGFjaykxMDUgMzU5LjQgUQooZXQuIFRoZSBjb250ZW50IG9m
IHRoaXMgcGllY2Ugb2YpLS4xMSBFKGluZm9ybWF0aW9uIGRlcGVuZHMgb24gdGhlIGVuY1wK
b2RlciBiZWluZyB1c2VkIFwoZS5nLiBpbiBCbG9jayBGRUMgY29kZXMgdGhpcyBtYXkgYmUg
dGhlKTEwNSAzNzIuNCBRCihjb21iaW5hdGlvbiBvZiBibG9jayBpbmRlKTEwNSAzODUuNCBR
IDIuNzUoeGEpLS4xNjUgRwoobmQgZW5jb2Rpbmcgc3ltYm9sIGlkZW50aVwyMTRlcjsgaW4g
aWRlYWwgZSktMi43NSBFKHhwYW5kYWJsZSBGRUMpLS4xNjUKRShjb2RlcyB0aGlzIG1heSBi
ZSBqdXN0IGEgXDIxNWF0IGVuY29kaW5nIHN5bWJvbCBpZGVudGlcMjE0ZXJcKS4pMTA1CjM5
OC40IFEgNy4zMzcoM1wpIEZFQyk3NC43NSA0MTUgUihPYmplY3QgVCkyLjc1IEUKKHJhbnNt
aXNzaW9uIEluZm9ybWF0aW9uKS0uMzg1IEUoVGhpcyBpcyBpbmZvcm1hdGlvbiByZSkxMDUg
NDMxLjYgUQotLjA1NShnYSktLjE2NSBHCihyZGluZyB0aGUgZW5jb2Rpbmcgb2YgYSBzcGVj
aVwyMTRjIG9iamVjdCBuZWVkZWQgYnkgdGhlIEZFQyBkZWNvZGVyKQouMDU1IEUoXChlLmcu
IGZvciBCbG9jayBGRUMgY29kZXMgdGhpcyBtYXkgYmUgdGhlIGNvbWJpbmF0aW9uIG9mIGJs
b2NrIFwKbGVuZ3RoIGFuZCBvYmplY3QgbGVuZ3RoXCkuKTEwNSA0NDQuNiBRCihUaGlzIG1p
Z2h0IGFsc28gaW5jbHVkZSBnZW5lcmFsIHBhcmFtZXRlcnMgb2YgdGhlIEZFQyBlbmNvZGVy
KTEwNSA0NTcuNgpRIDIuNzUoLk4pLS42MDUgRyhvdGUgdGhhdCwgaW4gc3RyaWN0IHRlcm1z
LCktMi43NSBFKHRoZSAiRkVDIEVuY29kaW5nIFwKSWRlbnRpXDIxNGVyIiBiZWxvbmdzIHRv
IHRoaXMgY2xhc3Mgb2YgaW5mb3JtYXRpb24sIGhvKTEwNSA0NzAuNiBRKHdlKQotLjI3NSBF
IC0uMTY1KHZlKS0uMjc1IEcgLjg4IC0uNDQociwgZikuMTY1IEgob3IgcHJhY3RpY2FsKS40
NCBFCihwdXJwb3Nlcywgd2Ugd2lsbCBjb25zaWRlciBpdCBzZXBhcmF0ZWx5KTEwNSA0ODMu
NiBRKC4pLS43MTUgRQooQWxsIHRoZSBjbGFzc2VzIG9mIGluZm9ybWF0aW9uIGFibyk5NyA1
MTMuMiBRIC0uMTY1KHZlKS0uMTY1IEcgMi43NSgsZSkKLjE2NSBHKHhjZXB0IDJcKSwgY2Fu
IGVpdGhlciBiZSB0cmFuc21pdHRlZCB3aXRoaW4gdGhlKS0yLjkxNSBFCih0cmFuc3BvcnQg
c2Vzc2lvbiBcKHVzaW5nIHByb3RvY29sIHBhY2spNzIgNTI2LjIgUQooZXQtaGVhZGVyIFwy
MTRlbGRzXCkgb3Igb3V0IG9mIGJhbmQuIFRoZSBpbmZvcm1hdGlvbiBkZXNjcmliZWQpLS4x
MSBFCihpbiAyXCkgTVVTVCBiZSB0cmFuc21pdHRlZCBpbiBkYXRhLXBhY2spNzIgNTM5LjIg
UQooZXQgaGVhZGVyIFwyMTRlbGRzLCBhcyBpdCBwcm8pLS4xMSBFKHZpZGVzIGEgZGVzY3Jp
cHRpb24gb2YgdGhlIGRhdGEpCi0uMTY1IEUoY29udGFpbmVkIGluIHRoZSBwYWNrKTcyIDU1
Mi4yIFEoZXQuIEluIHRoZSBmb2xsbyktLjExIEUKKHdpbmcgd2Ugd2lsbCBzcGVjaWZ5IHRo
ZSBjb250ZW50IG9mIDFcKSwgMlwpIGFuZCAzXCkgcmUpLS4yNzUgRSAtLjA1NQooZ2EpLS4x
NjUgRyhyZGxlc3Mgb2YpLjA1NSBFCih3aGV0aGVyIHRoZXNlIHBpZWNlcyBvZiBpbmZvcm1h
dGlvbiBhcmUgdHJhbnNtaXR0ZWQgaW4gcHJvdG9jb2wgcGFjayk3Mgo1NjUuMiBRKGV0cyBv
ciBvdXQgb2YgYmFuZC4gVGhpcyktLjExIEUoZG9jdW1lbnQgbmVpdGhlciBzcGVjaVwyMTRl
cyBvdVwKdC1vZi1iYW5kIG1ldGhvZHMgdG8gdHJhbnNwb3J0IHRoZSBpbmZvcm1hdGlvbiBu
b3IgZG9lcyBpdCBzcGVjaWZ5KTcyCjU3OC4yIFEodGhlIHcpNzIgNTkxLjIgUQooYXkgb3V0
LW9mLWJhbmQgaW5mb3JtYXRpb24gaXMgYXNzb2NpYXRlZCB3aXRoIHBhY2spLS4xMSBFCihl
dCBwYXlsb2Fkcy4gVGhpcyBsYXN0IHRhc2sgaXMgZGUpLS4xMSBFIC0uMjIodm8pLS4yNzUg
RyhsdikuMjIgRQooZWQgdG8pLS4xNjUgRShhbiB1cHBlcik3MiA2MDQuMiBRKC1sYXllciBw
cm90b2NvbC4pLS4yMiBFIC0uNDQoV2kpNzIKNjMwLjIgUyh0aGluIHRoZSBjb250ZSkuNDQg
RSh4dCBvZiBGRUMgcmVwYWlyIHNjaGVtZXMsIGZlZWRiYWNrIHBhY2spCi0uMTY1IEUoZXRz
IGFyZSBcKG9wdGlvbmFsbHlcKSB1c2VkIHRvIHJlcXVlc3QgRkVDKS0uMTEgRSAyLjc1Cihy
ZXRyYW5zbWlzc2lvbi4gVGhlKTcyIDY0My4yIFIKKEZFQy1yZWxhdGVkIGluZm9ybWF0aW9u
IHByZXNlbnQgaW4gZmVlZGJhY2sgcGFjaykyLjc1IEUKKGV0cyB1c3VhbGx5IGNvbnRhaW5z
IGFuKS0uMTEgRShGRUMgQmxvY2sgSWRlbnRpXDIxNGVyKTcyIDY1Ni4yIFEgMi43NQooLHQp
LS40NCBHKGhhdCBkZVwyMTRuZXMgdGhlIGJsb2NrIHRoYXQgaXMgYmVpbmcgcmVwYWlyZWQs
IGFuZCB0aGUgbnVtYlwKZXIgb2YgUmVwYWlyKS0yLjc1IEUKKFN5bWJvbHMgcmVxdWVzdGVk
LiBBbHRob3VnaCB0aGlzIGlzIHRoZSBtb3N0IGNvbW1vbiBjYXNlLCB2KTcyIDY2OS4yIFEK
KGFyaWFudHMgYXJlIHBvc3NpYmxlIGluIHdoaWNoIHRoZSktLjI3NSBFKHJlY2VpKTcyIDY4
Mi4yIFEgLS4xNjUodmUpCi0uMjc1IEcocnMgcHJvKS4xNjUgRSh2aWRlIG1vcmUgc3BlY2lc
MjE0YyBpbmZvcm1hdGlvbiBhYm91dCB0aGUgUmVwYWlyXAogU3ltYm9scyByZXF1ZXN0ZWQg
XChlLmcuIGFuIGluZGUpLS4xNjUgRSh4KS0uMTY1IEUocmFuZ2Ugb3IgYSBsaXN0IG9mIFwK
c3ltYm9scyBhY2NlcHRlZFwpLiBJdCBpcyBhbHNvIHBvc3NpYmxlIHRvIGluY2x1ZGUgbXVs
dGlwbGUgb2YgdGhlc2UgcmVcCnF1ZXN0IGluIGEpNzIgNjk1LjIgUShzaW5nbGUgZmVlZGJh
Y2sgcGFjayk3MiA3MDguMiBRKGV0LiktLjExIEUoTHVieS9WKQo3MiA3NjkgUShpY2lzYW5v
L0dlbW1lbGwvUml6em8vSGFuZGxlKS0uNjYgRSh5L0NybyktLjE2NSBFIDExNy4zNTYKKHdj
cm9mdCBTZWN0aW9uKS0uMjc1IEYgMi43NSgxLiBbUCkyLjc1IEYoYWdlIDJdKS0uMTY1IEUg
RVAKJSVQYWdlOiAzIDMKJSVCZWdpblBhZ2VTZXR1cApCUAolJUVuZFBhZ2VTZXR1cAovRjAg
MTEvVGltZXMtUm9tYW5AMCBTRihJTlRFUk5FVCk3MiA0OSBRIDcxLjU4NygtRFJBRlQgRXhw
aXJlczopLTEuMDEyIEYKKEphbnVhcnkgMjAwMikyLjc1IEUoSnVseSAyMDAxKTEyMy43MjYg
RShUaGlzIGRvY3VtZW50IGRvZXMgbm90IHBybyk3Mgo4NSBRKHZpZGUgYW4pLS4xNjUgRSAy
Ljc1KHlkKS0uMTY1IEcKKGV0YWlsIGFib3V0IHRoZSBmb3JtYXQgb2YgRkVDIGluZm9ybWF0
aW9uIGluIGZlZWRiYWNrKS0yLjc1IEUocGFjayk3Mgo5OCBRKGV0cy4pLS4xMSBFL0YxIDEx
L1RpbWVzLUJvbGRAMCBTRigxLjEuKTcyIDEzNyBRL0YyIDEzL1RpbWVzLUJvbGRAMApTRihG
RUMgRW5jb2RpbmcgSWRlbnRpXDIxNGVyKTUuNSBFIEYwKFRoaXMgaXMgYSBudW1lcmljIGlu
ZGUpNzIgMTY2LjYgUQoyLjc1KHh0KS0uMTY1IEcoaGF0IGlkZW50aVwyMTRlcyBhIHNwZWNp
XDIxNGMgRkVDIHNjaGVtZSBPUiBhIGNsYXNzIG9mIFwKZW5jb2Rpbmcgc2NoZW1lcyktMi43
NSBFKHRoYXQgc2hhcmUgdGhlIHNhbWUgZm9ybWF0IG9mICJGRUMgUCk3MiAxNzkuNiBRCihh
eWxvYWQgSUQiIGFuZCAiRkVDIE9iamVjdCBUKS0uMTY1IEUocmFuc21pc3Npb24gSW5mb3Jt
YXRpb24iLiktLjM4NSBFCihUaGUgRkVDIEVuY29kaW5nIElkZW50aVwyMTRlciBpZGVudGlc
MjE0ZXMgYSBzcGVjaVwyMTRjIEZFQyBzY2hlbWUgd2hlXApuIHRoZSBlbmNvZGluZyBzY2hl
bWUgaXMpNzIgMjA1LjYgUQooZm9ybWFsbHkgYW5kIGZ1bGx5IHNwZWNpXDIxNGVkLCBpbiBh
IHcpNzIgMjE4LjYgUQooYXkgdGhhdCBpbmRlcGVuZGVudCBpbXBsZW1lbnRvcnMgY2FuIGlt
cGxlbWVudCBib3RoIGVuY29kZXIpLS4xMSBFKGFuZFwKIGRlY29kZXIgZnJvbSB0aGUgc3Bl
Y2lcMjE0Y2F0aW9uLiBDb21wYW5pb24gZG9jdW1lbnRzIG9mIHRoaXMgc3BlY2lcClwyMTRj
YXRpb24gbWF5IHNwZWNpZnkgc3VjaCk3MiAyMzEuNiBRCihGRUMgc2NoZW1lcyBhbmQgYXNz
b2NpYXRlIHRoZW0gd2l0aCAiRkVDIEVuY29kaW5nIElkZW50aVwyMTRlciIgdik3MgoyNDQu
NiBRKGFsdWVzLiBUaGVzZSBkb2N1bWVudHMpLS4yNzUgRQooTVVTVCBhbHNvIHNwZWNpZnkg
YSBjb3JyZXNwb25kZW50IGZvcm1hdCBmb3IgdGhlICJGRUMgUCk3MiAyNTcuNiBRCihheWxv
YWQgSUQiIGFuZCAiRkVDIE9iamVjdCktLjE2NSBFIC0uMzg1KFRyKTcyIDI3MC42IFMKKGFu
c21pc3Npb24gSW5mb3JtYXRpb24iLikuMzg1IEUKKEN1cnJlbnRseSBGRUMgRW5jb2Rpbmcg
SWRlbnRpXDIxNGVycyBpbiB0aGUgcmFuZ2UgMC0xMjcgYXJlIHJlc2Vydik1LjUKRShlZCkt
LjE2NSBFCihmb3IgdGhpcyBjbGFzcyBvZiBlbmNvZGluZyBzY2hlbWVzIFwoZnVsbHktc3Bl
Y2lcMjE0ZWQgc2NoZW1lc1wpLik3MgoyODMuNiBRKEl0IGlzIHBvc3NpYmxlIHRoYXQgYSBG
RUMgc2NoZW1lIGNhbm5vdCBiZSBjb21wbGV0ZWx5IHNwZWNpXDIxNFwKZWQgb3IgdGhhdCBz
dWNoIGEgc3BlY2lcMjE0Y2F0aW9uIGlzKTcyIDMwOS42IFEoc2ltcGx5IG5vdCBhKTcyIDMy
Mi42IFEKLS4yNzUodmEpLS4yMiBHKGlsYWJsZSBvciBhbHNvIHRoYXQgYSBwYXJ0eSBlKS4y
NzUgRSh4aXN0cyB0aGF0IG8pLS4xNjUKRSh3bnMgdGhlIGVuY29kaW5nIHNjaGVtZSBhbmQg
aXQgaXMgbm90IHdpbGxpbmcpLS4yNzUgRQoodG8gZGlzY2xvc2UgaXRzIGFsZ29yaXRobS4g
Vyk3MiAzMzUuNiBRIDIuNzUoZXIpLS44OCBHCihlZmVyIHRvIHRoZXNlIGVuY29kaW5nIHNj
aGVtZXMgYXMgIlVuZGVyKS0yLjc1IEUKKC1TcGVjaVwyMTRlZCIgc2NoZW1lcy4pLS4yMiBF
KFVuZGVyKTcyIDM0OC42IFEKKC1zcGVjaVwyMTRlZCBzY2hlbWVzIGNhbiBzdGlsbCBiZSBp
ZGVudGlcMjE0ZWQgYXMgZm9sbG8pLS4yMiBFKHdzOikKLS4yNzUgRSAxMShvQSk3Ny41IDM2
NS4yIFMoZm9ybWF0IG9mIHRoZSBcMjE0ZWxkcyAiRkVDIFApLTguMjUgRQooYXlsb2FkIElE
IiBhbmQgIkZFQyBPYmplY3QgVCktLjE2NSBFKHJhbnNtaXNzaW9uIEluZm9ybWF0aW9uIikt
LjM4NSBFCihNVVNUIGJlIGRlXDIxNG5lZCBmb3IgdGhlIGVuY29kaW5nIHNjaGVtZS4pOTQg
Mzc4LjIgUSAxMShvQSk3Ny41IDM5NC44ClMgLS4yNzUodmEpLTguMjUgRyhsdWUgb2YgIkZF
QyBFbmNvZGluZyBJZGVudGlcMjE0ZXIiIE1VU1QgYmUgcmVzZXJ2KQouMjc1IEUoZWQgYW5k
IGFzc29jaWF0ZWQgdG8gdGhlIGZvcm1hdCktLjE2NSBFKGRlXDIxNG5pdGlvbnMgYWJvKTk0
CjQwNy44IFEgLS4xNjUodmUpLS4xNjUgRyAyLjc1KC5BKS4xNjUgRyAyLjc1KG5hKS0yLjc1
IEcobHJlYWR5IHJlc2VydikKLTIuNzUgRShlZCAiRkVDIEVuY29kaW5nIElkZW50aVwyMTRl
ciIpLS4xNjUgRShNVVNUIGJlIHJldXNlZCBpZiBpdCBpcykKNS41IEUoYXNzb2NpYXRlZCB0
byB0aGUgc2FtZSBmb3JtYXQgb2YgIkZFQyBQKTk0IDQyMC44IFEKKGF5bG9hZCBJRCIgYW5k
ICJGRUMgT2JqZWN0IFQpLS4xNjUgRShyYW5zbWlzc2lvbiktLjM4NSBFCihJbmZvcm1hdGlv
biIgYXMgdGhlIG9uZXMgbmVlZGVkIGZvciB0aGUgbmUpOTQgNDMzLjggUSAyLjc1KHd1KS0u
Mjc1IEcKKG5kZXIpLTIuNzUgRSgtc3BlY2lcMjE0ZWQgRkVDIHNjaGVtZS4pLS4yMiBFIDEx
KG9BKTc3LjUgNDUwLjQgUyAtLjI3NQoodmEpLTguMjUgRyhsdWUgb2YgIkZFQyBFbmNvZGlu
ZyBOYW1lIiBtdXN0IGJlIHJlc2VydikuMjc1IEUKKGVkIFwoc2VlIGJlbG8pLS4xNjUgRSh3
XCkuKS0uMjc1IEUoQW4gVW5kZXIpNzIgNDgwIFEoLXNwZWNpXDIxNGVkIEZFQyBcCnNjaGVt
ZSBpcyBjb21wbGV0ZWx5IGlkZW50aVwyMTRlZCBieSB0aGUgdHVwbGUgXChGRUMgRW5jb2Rp
bmcgSWRlbnRpXApcMjE0ZXIpLS4yMiBFKCwpLS40NCBFKEZFQyBFbmNvZGluZyBOYW1lXCku
IFRoZSB0dXBsZSBNVVNUIGlkZW50aWZ5IGEgc1wKaW5nbGUgc2NoZW1lIHRoYXQgaGFzIGF0
IGxlYXN0IG9uZSk3MiA0OTMgUQooaW1wbGVtZW50YXRpb24uIFRoZSBwYXJ0eSB0aGF0IG8p
NzIgNTA2IFEKKHducyB0aGlzIHR1cGxlIE1VU1QgYmUgYWJsZSB0byBwcm8pLS4yNzUgRSh2
aWRlIGluZm9ybWF0aW9uIG9uIGhvKS0uMTY1CkUgMi43NSh3dCktLjI3NSBHKG8pLTIuNzUg
RShvYnRhaW4gdGhlIHVuZGVyKTcyIDUxOSBRKC1zcGVjaVwyMTRlZCBGRUMgXApzY2hlbWUg
aWRlbnRpXDIxNGVkIGJ5IHRoZSB0dXBsZSBcKGUuZy4gYSBwb2ludGVyIHRvIGEgcHVibGlj
bHkpLS4yMiBFCi0uMjIoYXYpNzIgNTMyIFMKKGFpbGFibGUgcmVmZXJlbmNlLWltcGxlbWVu
dGF0aW9uIG9yIHRoZSBuYW1lIGFuZCBjb250YWN0cyBvZiBhIGNvbXBhbikKLS4wNTUgRSAy
Ljc1KHl0KS0uMTY1IEcoaGF0IHNlbGxzIGl0LCBlaXRoZXIpLTIuNzUgRQooc2VwYXJhdGVs
eSBvciBlbWJlZGRlZCBpbiBhbm90aGVyIHByb2R1Y3RcKS4pNzIgNTQ1IFEoIkZFQyBFbmNv
ZGluZyBOYVwKbWVzIiBhcmUgbnVtZXJpYyBpZGVudGlcMjE0ZXJzIHNjb3BlZCBieSBhIEZF
QyBFbmNvZGluZyBJZGVudGlcMjE0ZXIpNzIKNTcxIFEoLiktLjYwNSBFKFRoZSBGRUMgRW5j
b2RpbmcgTmFtZSBNVVNUIGJlIHBhcnQgb2YgdGhlICJGRUMgT2JqZWN0IFQpCjcyIDU5NyBR
KHJhbnNtaXNzaW9uIEluZm9ybWF0aW9uIiBhbmQpLS4zODUgRQoobXVzdCBiZSBjb21tdW5p
Y2F0ZWQgdG8gcmVjZWkpNzIgNjEwIFEgLS4xNjUodmUpLS4yNzUgRwoocnMgdG9nZXRoZXIg
d2l0aCB0aGUgRkVDIEVuY29kaW5nIElkZW50aVwyMTRlcikuMTY1IEUoLiktLjYwNSBFKERp
Zik3Mgo2MzYgUQooZmVyZW50IEZFQyBzY2hlbWVzIHRoYXQgc2hhcmUgdGhlIHNhbWUgRkVD
IEVuY29kaW5nIElkZW50aVwyMTRlciAtLSBiKQotLjI3NSBFKHV0IGhhKS0uMjIgRSAuMzMg
LS4xNjUodmUgZCktLjIyIEgoaWYpLjE2NSBFKGZlcmVudCBGRUMpLS4yNzUgRQooRW5jb2Rp
bmcgTmFtZXMgLS0gYWxzbyBzaGFyZSB0aGUgc2FtZSBmb3JtYXQgb2YgRkVDIFApNzIgNjQ5
IFEKKGF5bG9hZCBJRCBhbmQgRkVDIE9iamVjdCBUKS0uMTY1IEUocmFuc21pc3Npb24pLS4z
ODUgRShJbmZvcm1hdGlvbi4pNzIKNjYyIFEoVGhpcyBzcGVjaVwyMTRjYXRpb24gcmVzZXJ2
KTcyIDY4OCBRCihlcyB0aGUgcmFuZ2UgMC0xMjcgb2YgRkVDIEVuY29kaW5nIElkZW50aVwy
MTRlcnMgZm9yIGZ1bGx5LXNwZWNpXDIxNGVkKQotLjE2NSBFKGVuY29kaW5nIHNjaGVtZXMg
YW5kIHRoZSByYW5nZSAxMjgtMjU1IGZvciB1bmRlcik3MiA3MDEgUQooLXNwZWNpXDIxNGVk
IGVuY29kaW5nIHNjaGVtZXMuKS0uMjIgRShMdWJ5L1YpNzIgNzY5IFEKKGljaXNhbm8vR2Vt
bWVsbC9SaXp6by9IYW5kbGUpLS42NiBFKHkvQ3JvKS0uMTY1IEUgMTA5LjEwNgood2Nyb2Z0
IFNlY3Rpb24pLS4yNzUgRiAyLjc1KDEuMS4gW1ApMi43NSBGKGFnZSAzXSktLjE2NSBFIEVQ
CiUlUGFnZTogNCA0CiUlQmVnaW5QYWdlU2V0dXAKQlAKJSVFbmRQYWdlU2V0dXAKL0YwIDEx
L1RpbWVzLVJvbWFuQDAgU0YoSU5URVJORVQpNzIgNDkgUSA3MS41ODcoLURSQUZUIEV4cGly
ZXM6KS0xLjAxMiBGCihKYW51YXJ5IDIwMDIpMi43NSBFKEp1bHkgMjAwMSkxMjMuNzI2IEUv
RjEgMTEvVGltZXMtQm9sZEAwIFNGKDEuMi4pNzIKODUgUS9GMiAxMy9UaW1lcy1Cb2xkQDAg
U0YoRkVDIFApNS41IEUoYXlsb2FkIElEIGFuZCBGRUMgT2JqZWN0IFQpLS4xMyBFCihyYW5z
bWlzc2lvbiBJbmYpLS45NjIgRShvcm1hdGlvbiktLjMyNSBFIEYwIDIuNzUoQWQpOTcgMTE0
LjYgUwoob2N1bWVudCB0aGF0IHNwZWNpXDIxNGVzIGFuIGVuY29kaW5nIHNjaGVtZSBhbmQg
cmVzZXJ2KS0yLjc1IEUoZXMgYSB2KQotLjE2NSBFKGFsdWUgb2YgRkVDIEVuY29kaW5nKS0u
Mjc1IEUoSWRlbnRpXDIxNGVyIE1VU1QgZGVcMjE0bmUgYSBwYWNrKQo3MiAxMjcuNiBRKGV0
LVwyMTRlbGQgZm9ybWF0IGZvciBGRUMgUCktLjExIEUKKGF5bG9hZCBJRCBhbmQgRkVDIE9i
amVjdCBUKS0uMTY1IEUocmFuc21pc3Npb24pLS4zODUgRShJbmZvcm1hdGlvbiBhY2NcCm9y
ZGluZyB0byB0aGUgbmVlZCBvZiB0aGUgZW5jb2Rpbmcgc2NoZW1lLiBUaGlzIGFsc28gYXBw
bGllcyB0byBkb2N1bWVuXAp0cyB0aGF0KTcyIDE0MC42IFEocmVzZXJ2KTcyIDE1My42IFEo
ZXMgdiktLjE2NSBFCihhbHVlcyBvZiBGRUMgRW5jb2RpbmcgSWRlbnRpXDIxNGVycyBmb3Ig
dW5kZXIpLS4yNzUgRQooLXNwZWNpXDIxNGVkIGVuY29kaW5nIHNjaGVtZXMuIEluIHRoaXMg
Y2FzZSktLjIyIEUodGhlIEZFQyBPYmplY3QgVCk3MgoxNjYuNiBRKHJhbnNtaXNzaW9uIElu
Zm9ybWF0aW9uIG11c3QgYWxzbyBpbmNsdWRlIGEgXDIxNGVsZCB0byBjb250YWluIFwKdGhl
ICJGRUMgRW5jb2RpbmcpLS4zODUgRShOYW1lIi4pNzIgMTc5LjYgUSAyLjc1KEFwKTcyIDIw
NS42IFMoYWNrKS0yLjc1CkUoZXQgXDIxNGVsZCBkZVwyMTRuaXRpb24gb2YgRkVDIE9iamVj
dCBUKS0uMTEgRQoocmFuc21pc3Npb24gSW5mb3JtYXRpb24gTVVTVCBiZSBwcm8pLS4zODUg
RSh2aWRlZCBkZXNwaXRlIHRoZSktLjE2NSBFCi0uMTEoZmEpNzIgMjE4LjYgUyhjdCB0aGF0
IGEgcHJvdG9jb2wgaW5zdGFudGlhdGlvbiBtYXkgZGVjaWRlIHRvIGNvbW11XApuaWNhdGUg
dGhpcyBpbmZvcm1hdGlvbiBvdXQgb2YgYmFuZC4pLjExIEUoQWxsIHBhY2spNzIgMjQ0LjYg
UQooZXQgXDIxNGVsZCBkZVwyMTRuaXRpb25zIFwoRkVDIFApLS4xMSBFKGF5bG9hZCBJRCBh
bmQgRkVDIE9iamVjdCBUKQotLjE2NSBFKHJhbnNtaXNzaW9uIEluZm9ybWF0aW9uXCkgTVVT
VCktLjM4NSBFCihiZSBmdWxseSBzcGVjaVwyMTRlZCBhdCB0aGUgbGUpNzIgMjU3LjYgUSAt
LjE2NSh2ZSktLjI3NSBHIDIuNzUobG8pLjE2NQpHIDIuNzUoZmIpLTIuNzUgRyhpdC1cMjE0
ZWxkcyBhbmQgdGhlKS0yLjc1IEUgMi43NSh5bSktLjE2NSBHKHVzdCBoYSkKLTIuNzUgRSAu
MzMgLS4xNjUodmUgYSBsKS0uMjIgSChlbmd0aCB0aGF0IGlzIGEgbXVsdGlwbGUgb2YgYSku
MTY1IEUKKDQtYnl0ZSB3KTcyIDI3MC42IFEob3JkIFwodGhpcyBpcyB0byBmKS0uMTEgRQoo
YWNpbGl0YXRlIHRoZSBhbGlnbm1lbnQgb2YgcGFjayktLjExIEUKKGV0IFwyMTRlbGRzIGlu
IHByb3RvY29sIGluc3RhbnRpYXRpb25zXCkuKS0uMTEgRQooTm90ZSB0aGF0IHRoZSBzcGVj
aVwyMTRjYXRpb24gb2YgRkVDIFApNzIgMjk2LjYgUShheWxvYWQgSUQgTVVTVCBhbGxvKQot
LjE2NSBFIDIuNzUod2EpLS4yNzUgRyAyLjc1KG5pKS0yLjc1IEcobXBsZW1lbnRhdGlvbi1p
bmRlcGVuZGVudCktMi43NQpFKGlkZW50aVwyMTRjYXRpb24gb2YgdGhlIHBhY2spNzIgMzA5
LjYgUShldCBwYXlsb2FkIGUpLS4xMSBFIC0uMTY1KHZlKQotLjI3NSBHIDIuNzUobmkpLjE2
NSBHIDIuNzUobnQpLTIuNzUgRyhoZSBjYXNlIG9mIFVuZGVyKS0yLjc1IEUKKC1TcGVjaVwy
MTRlZCBlbmNvZGluZyBzY2hlbWVzLiktLjIyIEUgRjEoMi4pNzIgMzQ4LjYgUS9GMyAxNAov
VGltZXMtQm9sZEAwIFNGKFByKTUuNSBFKGVhc3NpZ25lZCBGRUMgRW5jb2RpbmcgSWRlbnRp
XDIxNGVycyktLjI1MiBFCkYwCihUaGlzIHNlY3Rpb24gc3BlY2lcMjE0ZXMgdGhlIEZFQyBF
bmNvZGluZyBJZGVudGlcMjE0ZXIgYW5kIHRoZSByZWxhdGkpCjcyIDM2NS4yIFEgLjMzIC0u
MTY1KHZlIHApLS4yNzUgSChhY2spLjE2NSBFCihldHMgXDIxNGVsZCBmb3IgYSBudW1iZXIg
b2YpLS4xMSBFKGtubyk3MiAzNzguMiBRCih3biBzY2hlbWVzIHRoYXQgZm9sbG8pLS4yNzUg
RSAyLjc1KHd1KS0uMjc1IEcobmRlciB0aGUgY2xhc3Mgb2YgdW5kZXIpCi0yLjc1IEUoLXNw
ZWNpXDIxNGVkIEZFQyBzY2hlbWVzLiBPdGhlcnMgbWF5IGJlKS0uMjIgRQooc3BlY2lcMjE0
ZWQgaW4gY29tcGFuaW9uIGRvY3VtZW50cy4pNzIgMzkxLjIgUSBGMSgyLjEuKTcyIDQzMC4y
IFEgRjIKKFNtYWxsIEJsb2NrLCBMYXIpNS41IEUoZ2UgQmxvY2sgYW5kIEV4cGFuZGFibGUg
RkVDIENvZGVzKS0uMTMgRSBGMAooVGhpcyBzZWN0aW9uIHJlc2Vydik3MiA0NDYuOCBRCihl
cyBhIEZFQyBFbmNvZGluZyBJZGVudGlcMjE0ZXIgZm9yIHRoZSBmKS0uMTY1IEUKKGFtaWxp
ZXMgb2YgY29kZXMgZGVzY3JpYmVkIGluIFsxXSwgYW5kKS0uMTEgRShzcGVjaVwyMTRlcyB0
aGUgcmVsYXRpKTcyCjQ1OS44IFEgLjMzIC0uMTY1KHZlIHApLS4yNzUgSChhY2spLjE2NSBF
KGV0IFwyMTRlbGRzLiktLjExIEUoVW5kZXIpNS41CkUoLXNwZWNpXDIxNGVkIEZFQyBzY2hl
bWVzIHRoYXQgYmVsb25nIHRvIHRoaXMgY2xhc3MgTVVTVCktLjIyIEUKKHVzZSB0aGlzIGlk
ZW50aVwyMTRlciBhbmQgcGFjayk3MiA0NzIuOCBRKGV0IFwyMTRlbGQgZGVcMjE0bml0aW9u
cy4pCi0uMTEgRShUaGUgRkVDIEVuY29kaW5nIElkZW50aVwyMTRlciBmb3IgdW5kZXIgc3Bl
Y2lcMjE0ZWQgY29kZXMgYXNzaWduXAplZCB0byBTbWFsbCBCbG9jaywgTGFyKTcyIDQ5OC44
IFEoZ2UgQmxvY2ssIGFuZCktLjE5OCBFCihFeHBhbmRhYmxlIEZFQyBDb2RlcyBpcyAxMjgu
KTcyIDUxMS44IFEoVGhlIEZFQyBQKTcyIDUzNy44IFEoYXlsb2FkIElEXAogaXMgY29tcG9z
ZWQgb2YgYW4gZW5jb2Rpbmcgc3ltYm9sIGlkZW50aVwyMTRlciBhbmQgYW4gZW5jb2Rpbmcg
YmxvY2spCi0uMTY1IEUobnVtYmVyIHN0cnVjdHVyZWQgYXMgZm9sbG8pNzIgNTUwLjggUSh3
czopLS4yNzUgRS9GNCA4L0NvdXJpZXJAMApTRiA5MS4yKDAxMjMpNzYuOCA1ODkuOCBTIDQu
OCgwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMSk3Ni44CjYwMi44IFMKKCstKy0r
LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r
LSstKy0rKTcyCjYxNS44IFEgMTAwLjgofGUpNzIgNjI4LjggUyhuY29kaW5nIGJsb2NrIG51
bWJlciktMTAwLjggRSh8KTEwMC44IEUKKCstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r
LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rKTcyCjY0MS44IFEgMTA1LjYo
fGUpNzIgNjU0LjggUyhuY29kaW5nIHN5bWJvbCBJRCktMTA1LjYgRSh8KTExMC40IEUKKCst
Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst
Ky0rLSstKy0rKTcyCjY2Ny44IFEvRjUgMTAvVGltZXMtUm9tYW5AMCBTRgooSW4gYWRkaXRp
b24sIGEgb25lIGJpdCBGRUMgRW5jb2RpbmcgRmxhZyBNQSk3MiA3MDYuOCBRIDIuNShZYikt
MS4wNSBHCjIuNShlaSktMi41IEcobmNsdWRlZCwgYW5kIHRoaXMgXDIxNWFnIGluZGljYXRl
cyB3aGV0aGVyIHRoZSBlbmNvZGluZykKLTIuNSBFKHN5bWJvbFwoc1wpIGluIHRoZSBwYXls
b2FkIG9mIHRoZSBwYWNrKTcyIDcxOS44IFEKKGV0IGFyZSBzb3VyY2Ugc3ltYm9sXChzXCkg
b3IgcmVkdW5kYW50IHN5bWJvbFwoc1wpLiktLjEgRSBGMChMdWJ5L1YpNzIKNzY5IFEoaWNp
c2Fuby9HZW1tZWxsL1JpenpvL0hhbmRsZSktLjY2IEUoeS9Dcm8pLS4xNjUgRSAxMDkuMTA2
Cih3Y3JvZnQgU2VjdGlvbiktLjI3NSBGIDIuNzUoMi4xLiBbUCkyLjc1IEYoYWdlIDRdKS0u
MTY1IEUgRVAKJSVQYWdlOiA1IDUKJSVCZWdpblBhZ2VTZXR1cApCUAolJUVuZFBhZ2VTZXR1
cAovRjAgMTEvVGltZXMtUm9tYW5AMCBTRihJTlRFUk5FVCk3MiA0OSBRIDcxLjU4NygtRFJB
RlQgRXhwaXJlczopLTEuMDEyIEYKKEphbnVhcnkgMjAwMikyLjc1IEUoSnVseSAyMDAxKTEy
My43MjYgRS9GMSAxMC9UaW1lcy1Sb21hbkAwIFNGCihUaGUgRkVDIE9iamVjdCBUKTcyIDg1
IFEocmFuc21pc3Npb24gSW5mb3JtYXRpb24gaGFzIHRoZSBmb2xsbyktLjM1IEUKKHdpbmcg
c3RydWN0dXJlOiktLjI1IEUvRjIgOC9Db3VyaWVyQDAgU0YgOTEuMigwMTIzKTc2LjggMTI0
IFMgNC44CigwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMSk3Ni44IDEzNyBTCigr
LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r
LSstKy0rLSstKyk3MgoxNTAgUSAyOC44KHxGKTcyIDE2MyBTKEVDIEVuY29kaW5nIE5hbWUp
LTI4LjggRSAyNCh8TykzOC40IEcKKGJqZWN0IExlbmd0aCBcKE1TQlwpKS0yNCBFKHwpMzMu
NiBFCigrLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r
LSstKy0rLSstKy0rLSstKyk3MgoxNzYgUSAxMDAuOCh8Tyk3MiAxODkgUyhiamVjdCBMZW5n
dGggXChMU0JcKSktMTAwLjggRSh8KTExMC40IEUKKCstKy0rLSstKy0rLSstKy0rLSstKy0r
LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rKTcyCjIwMiBRIDEw
MC44KHxTKTcyIDIxNSBTKG91cmNlIEJsb2NrIExlbmd0aCktMTAwLjggRSh8KTExMC40IEUK
KCstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r
LSstKy0rLSstKy0rKTcyCjIyOCBRIEYxKE5vdGUgdGhhdCB0aGlzIHN0cnVjdHVyZSBsaW1p
dHMgdGhlIHJhbmdlIG9mIHBvc3NpYmxlIEZFQyBFbmNvXApkaW5nIE5hbWVzIHRvIDAtOi02
NTUzNiwgZGVzcGl0ZSB0aGUgZik3MiAyNjcgUShhY3QgdGhhdCktLjEgRQoodGhlIEZFQyBP
YmplY3QgVCk3MiAyODAgUQoocmFuc21pc3Npb24gSW5mb3JtYXRpb24gY2FuIGFsc28gYmUg
dHJhbnNtaXR0ZWQgb3V0IG9mIGJhbmQuKS0uMzUgRShUaFwKZSBPYmplY3QgTGVuZ3RoLCBj
b21wb3NlZCBvZiBhIE1vc3QgU2lnbmlcMjE0Y2FudCBCeXRlcyBwb3J0aW9uIFwoTVNCXClc
CiBhbmQgYSBMZWFzdCBTaWduaVwyMTRjYW50IEJ5dGVzKTcyIDMwNiBRKHBvcnRpb24gXChM
U0JcKSwgaXMgZSk3MiAzMTkgUQooeHByZXNzZWQgaW4gYnl0ZXMuKS0uMTUgRS9GMyAxMS9U
aW1lcy1Cb2xkQDAgU0YoMi4yLik3MiAzNTggUS9GNCAxMwovVGltZXMtQm9sZEAwIFNGKFNt
YWxsIEJsb2NrIFN5c3RlbWF0aWMgRkVDIENvZGVzKTUuNSBFIEYwKFRoZSBmb2xsbyk3Mgoz
NzQuNiBRKHdpbmcgZGVcMjE0bml0aW9ucyBhcHBseSB0byBzeXN0ZW1hdGljIGNvZGVzIG9m
IHNtYWxsIGxlbmd0aCBcKFwKdG90YWwgYmxvY2sgbGVuZ3RoIDwgMl4xNlwpLiktLjI3NSBF
KFRoZSBGRUMgRW5jb2RpbmcgSWRlbnRpXDIxNGVyIGZvciBcCnVuZGVyIHNwZWNpXDIxNGVk
IGNvZGVzIGFzc2lnbmVkIHRvIFNtYWxsIEJsb2NrIFN5c3RlbWF0aWMgRkVDKTcyIDQwMC42
ClEoQ29kZXMgaXMgMTI5Lik3MiA0MTMuNiBRKEFsdGhvdWdoIHRoZXNlIGNvZGVzIGNhbiBn
ZW5lcmFsbHkgYmUgYWNjb21tXApvZGF0ZWQgYnkgdGhlIEZFQyBFbmNvZGluZyBJZGVudGlc
MjE0ZXIgZGVzY3JpYmVkKTcyIDQzOS42IFEoaW4gU2VjdGlvblwKIDIuMSwgYSBzcGVjaVwy
MTRjIEVuY29kaW5nLUlEIGlzIGRlXDIxNG5lZCBmb3Igc3lzdGVtYXRpYyBjb2RlcyB0byBh
bGxcCm8pNzIgNDUyLjYgUSAyLjc1KHdiKS0uMjc1IEcoZXR0ZXIgXDIxNWUpLTIuNzUgRSh4
aWJpbGl0eSktLjE2NSBFKGFuZCB0XApvIHJldGFpbiBoZWFkZXIgY29tcGFjdG5lc3MuIFRo
ZSBzbWFsbCBzb3VyY2UgYmxvY2sgbGVuZ3RoIGFuZCBzbWFsbCBlKQo3MiA0NjUuNiBRKHhh
cGFuc2lvbiBmKS0uMTY1IEUoYWN0b3IgdGhhdCktLjExIEUob2Z0ZW4gY2hhcmFjdGVyaXpl
IHN5c1wKdGVtYXRpYyBjb2RlcyBtYXkgcmVxdWlyZSB0aGF0IHRoZSBkYXRhIHNvdXJjZSBj
aGFuZ2VzIGZyZXF1ZW50bHkgdGhlKTcyCjQ3OC42IFEoc291cmNlIGJsb2NrIGxlbmd0aC4g
VCk3MiA0OTEuNiBRIDIuNzUob2EpLS44OCBHKGxsbyktMi43NSBFCjIuNzUod3QpLS4yNzUg
RyhoZSBkeW5hbWljIHYpLTIuNzUgRQooYXJpYXRpb24gb2YgdGhlIHNvdXJjZSBibG9jayBs
ZW5ndGggYW5kIHRvKS0uMjc1IEUKKGNvbW11bmljYXRlIGl0IHRvIHRoZSByZWNlaSk3MiA1
MDQuNiBRIC0uMTY1KHZlKS0uMjc1IEcocnMgd2l0aCBsbykuMTY1CkUgMi43NSh3byktLjI3
NSBHIC0uMTY1KHZlKS0yLjkxNSBHCihyaGVhZCwgdGhlIGJsb2NrIGxlbmd0aCBpcyBpbmNs
dWRlZCBpbiB0aGUgRkVDKS4xNjUgRSAtLjE2NShQYSk3MiA1MTcuNgpTKHlsb2FkIElELiku
MTY1IEUoVGhlIEZFQyBQKTcyIDU0My42IFEKKGF5bG9hZCBJRCBpcyBjb21wb3NlZCBvZiB0
aGUgZW5jb2RpbmcgYmxvY2sgbnVtYmVyKS0uMTY1IEUgMi43NSgsdCktLjQ0CkcoaGUgZW5j
b2Rpbmcgc3ltYm9sIGlkZW50aVwyMTRlciktMi43NSBFKGFuZCB0aGUgYmxvY2sgbGVuZ3Ro
Oik3MiA1NTYuNgpRIEYyIDkxLjIoMDEyMyk3Ni44IDU5NS42IFMgNC44KDAxMjM0NTY3ODkw
MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxKTc2LjgKNjA4LjYgUwooKy0rLSstKy0rLSstKy0rLSst
Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSspNzIKNjIx
LjYgUSA5Nih8ZSk3MiA2MzQuNiBTKG5jb2RpbmcgYmxvY2sgbnVtYmVyKS05NiBFKHwpMTA1
LjYgRQooKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst
Ky0rLSstKy0rLSstKy0rLSspNzIKNjQ3LjYgUSAyOC44KHxTKTcyIDY2MC42IFMob3VyY2Ug
YmxvY2sgbGVuZ3RoKS0yOC44IEUgMzMuNih8ZSkyOC44IEcKKG5jb2Rpbmcgc3ltYm9sIElE
KS0zMy42IEUofCkyOC44IEUKKCstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r
LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rKTcyCjY3My42IFEgRjEoVGhlIEZFQyBP
YmplY3QgVCk3MiA3MTIuNiBRCihyYW5zbWlzc2lvbiBJbmZvcm1hdGlvbiwgd2hlbiB1c2Vk
LCBoYXMgdGhlIGZvbGxvKS0uMzUgRQood2luZyBzdHJ1Y3R1cmU6KS0uMjUgRSBGMChMdWJ5
L1YpNzIgNzY5IFEoaWNpc2Fuby9HZW1tZWxsL1JpenpvL0hhbmRsZSkKLS42NiBFKHkvQ3Jv
KS0uMTY1IEUgMTA5LjEwNih3Y3JvZnQgU2VjdGlvbiktLjI3NSBGIDIuNzUoMi4yLiBbUCky
Ljc1IEYKKGFnZSA1XSktLjE2NSBFIEVQCiUlUGFnZTogNiA2CiUlQmVnaW5QYWdlU2V0dXAK
QlAKJSVFbmRQYWdlU2V0dXAKL0YwIDExL1RpbWVzLVJvbWFuQDAgU0YoSU5URVJORVQpNzIg
NDkgUSA3MS41ODcoLURSQUZUIEV4cGlyZXM6KS0xLjAxMiBGCihKYW51YXJ5IDIwMDIpMi43
NSBFKEp1bHkgMjAwMSkxMjMuNzI2IEUvRjEgOC9Db3VyaWVyQDAgU0YgOTEuMigwMTIzKQo3
Ni44IDg1IFMgNC44KDAxMjM0NTY3ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAxKTc2LjggOTgg
UwooKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r
LSstKy0rLSstKy0rLSspNzIKMTExIFEgMjguOCh8Rik3MiAxMjQgUyhFQyBFbmNvZGluZyBO
YW1lKS0yOC44IEUgOS42KHxOKTM4LjQgRwoodW1iZXIgb2YgcmVkdW5kYW50IHN5bWJvbHMp
LTkuNiBFKHwpOS42IEUKKCstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst
Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rKTcyCjEzNyBRL0YyIDEwL1RpbWVzLVJvbWFu
QDAgU0YoV2hlbiB2KTcyIDE3NiBRKGFyaWFibGUgYmxvY2stbGVuZ3RoIGlzIHVzXAplZCwg
dGhlIG51bWJlciBvZiByZWR1bmRhbnQgc3ltYm9scyBpcyB0byBiZSBpbnRlcnByZXRlZCBh
cyBhIG1heGltdW0pCi0uMjUgRSAtLjI1KHZhKTcyIDE4OSBTKGx1ZSBcKHVwcGVyIGJvdW5k
XCkuIFRoaXMgXDIxNGVsZCBpcyBwcm8pLjI1IEUKKHZpZGVkIGFzIGFuIGluZGljYXRpb24g
dG8gYWxsbyktLjE1IEUgMi41KHdyKS0uMjUgRyhlY2VpKS0yLjUgRSAtLjE1Cih2ZSktLjI1
IEcgMi41KHN0KS4xNSBHIDIuNShvcCktMi41IEcocmVhbGxvY2F0ZSBhIGRlY29kZXIpLTIu
NSBFCihzdWl0YWJsZSBmb3IgYWxsIHRoZSBvYmplY3QgYmxvY2tzLik3MiAyMDIgUShOb3Rl
IHRoYXQgdGhpcyBzdHJ1Y3R1cmUgXApsaW1pdHMgdGhlIHJhbmdlIG9mIHBvc3NpYmxlIEZF
QyBFbmNvZGluZyBOYW1lcyB0byAwLTotNjU1MzYsIGRlc3BpdGUgdFwKaGUgRkVDKTcyIDIy
OCBRKE9iamVjdCBUKTcyIDI0MSBRCihyYW5zbWlzc2lvbiBJbmZvcm1hdGlvbiBjYW4gYWxz
byBiZSB0cmFuc21pdHRlZCBvdXQgb2YgYmFuZC4pLS4zNSBFL0YzCjExL1RpbWVzLUJvbGRA
MCBTRigzLik3MiAyODAgUS9GNCAxNC9UaW1lcy1Cb2xkQDAgU0YoSUFOKTUuNSBFIDMuNShB
QykKLS4yOCBHKG9uc2lkZXJhdGlvbnMpLTMuNSBFIEYwIC0xLjIyMShWYSk3MiAyOTYuNiBT
KGx1ZXMgb2YgRkVDIEVuY29kaW5cCmcgSWRlbnRpXDIxNGVycyBhbmQgRkVDIEVuY29kaW5n
IE5hbWVzIGFyZSBzdWJqZWN0IHRvIElBTikxLjIyMSBFIDIuNzUKKEFyKS0uMzg1IEcgLS4x
NjUoZWcpLTIuNzUgRyhpc3RyYXRpb24uKS4xNjUgRShGRUMgRW5jb2RpbmcgSWRlbnRpXDIx
NGVcCnJzIGFuZCBGRUMgRW5jb2RpbmcgTmFtZXMgYXJlIGhpZXJhcmNoaWNhbDogRkVDIEVu
Y29kaW5nIElkZW50aVwyMTRlcnMpCjcyIDMwOS42IFEoXChhdCB0aGUgdG9wIGxlKTcyIDMy
Mi42IFEgLS4xNjUodmUpLS4yNzUgRyhsXCkgc2NvcGUgcmFuZ2VzXAogb2YgRkVDIEVuY29k
aW5nIE5hbWVzLiBOb3QgYWxsIEZFQyBFbmNvZGluZyBJZGVudGlcMjE0ZXJzIGhhKS4xNjUg
RSAuMzMKLS4xNjUodmUgYSktLjIyIEgoY29ycmVzcG9uZGluZyBGRUMgRW5jb2RpbmcgTmFt
ZSBzY29wZSBcKHNlZSBiZWxvKTcyCjMzNS42IFEod1wpLiktLjI3NSBFIDIuNzUoQUYpNzIg
MzYxLjYgUwooRUMgRW5jb2RpbmcgSWRlbnRpXDIxNGVyIGlzIGEgbnVtZXJpYyBub24tbmUp
LTIuNzUgRSAtLjA1NShnYSktLjE2NSBHCih0aSkuMDU1IEUgLjMzIC0uMTY1KHZlIGkpLS4y
NzUgSChuZGUpLjE2NSBFKHguIFYpLS4xNjUgRQooYWx1ZSBmcm9tIDAgdG8gMTI3IGFyZSBy
ZXNlcnYpLTEuMjIxIEUoZWQgZm9yKS0uMTY1IEUoRkVDIGVuY29kZXJzIHRoYVwKdCBhcmUg
ZnVsbHkgc3BlY2lcMjE0ZWQsIGFzIGRlc2NyaWJlZCBpbiBzZWN0aW9uIDMuMS4gVGhlIGFz
c2lnbm1lbnQgb2ZcCiBhIEZFQyk3MiAzNzQuNiBRKEVuY29kaW5nIElkZW50aVwyMTRlciBp
biB0aGlzIHJhbmdlIGNhbiBvbmx5IGJlIGdyYW50XAplZCBpZiB0aGUgcmVxdWVzdG9yIGNh
biBwcm8pNzIgMzg3LjYgUSh2aWRlIHN1Y2ggYSktLjE2NSBFCihzcGVjaVwyMTRjYXRpb24g
cHVibGlzaGVkIGFzIGFuIElFVEYgUkZDLiBWKTcyIDQwMC42IFEKKGFsdWVzIGdyZWF0ZXIg
dGhhbiAxMjcgY2FuIGJlIGFzc2lnbmVkIHRvIHVuZGVyKS0xLjIyMSBFKC0pLS4yMiBFKHNw
ZWNcCmlcMjE0ZWQgZW5jb2Rpbmcgc2NoZW1lcy4gTm90ZTogdGhpcyBzcGVjaVwyMTRjYXRp
b24gYWxyZWFkeSBhc3NpZ25zIHRoXAplIHYpNzIgNDEzLjYgUShhbHVlcyAxMjggYW5kIDEy
OS4pLS4yNzUgRShJbiBhbik3MiA0MzkuNiBRIDIuNzUoeWMpLS4xNjUKRyhhc2UgdiktMi43
NSBFKGFsdWVzIG9mIEZFQyBFbmNvZGluZyBJZGVudGlcMjE0ZXJzIGNhbiBvbmx5IGJlIGFz
c2lnbmVcCmQgaWYgdGhlIHJlcXVpcmVkIEZFQyBwYWNrKS0uMjc1IEUoZXQpLS4xMSBFKFwy
MTRlbGRzIGNvcnJlc3BvbmRpbmcgdG8gXAppdCBcKHNlZSBzZWN0aW9uIDEuMlwpIGFyZSBz
cGVjaVwyMTRlZCBpbiBhIFJGQy4pNzIgNDUyLjYgUQooRWFjaCBGRUMgRW5jb2RpbmcgSWRl
bnRpXDIxNGVyIGFzc2lnbmVkIHRvIGFuIHVuZGVyKTcyIDQ3OC42IFEKKC1zcGVjaVwyMTRl
ZCBlbmNvZGluZyBzY2hlbWUgc2NvcGVzIGFuKS0uMjIgRQooaW5kZXBlbmRlbnQgcmFuZ2Ug
b2YgRkVDIEVuY29kaW5nIE5hbWVzIFwoaS5lLiB0aGUgc2FtZSB2KTcyIDQ5MS42IFEKKGFs
dWUgb2YgRkVDIEVuY29kaW5nIE5hbWUgY2FuIGJlKS0uMjc1IEUocmV1c2VkIGZvciBkaWYp
NzIgNTA0LjYgUShmZXJcCmVudCBGRUMgRW5jb2RpbmcgSWRlbnRpXDIxNGVyc1wpLiBBbiBG
RUMgRW5jb2RpbmcgTmFtZSBpcyBhIG51bWVyaWMgbm9uXAotKS0uMjc1IEUobmUpNzIgNTE3
LjYgUSAtLjA1NShnYSktLjE2NSBHKHRpKS4wNTUgRSAuMzMgLS4xNjUodmUgaSktLjI3NQpI
KG5kZSkuMTY1IEUoeC4gVGhlIGRvY3VtZW50IHRoYXQgcmVzZXJ2KS0uMTY1IEUKKGVzIGEg
RkVDIEVuY29kaW5nIElkZW50aVwyMTRlciBNQSktLjE2NSBFIDIuNzUoWWEpLTEuMTU1IEcK
KGxzbyBzcGVjaWZ5IGEgcmFuZ2UpLTIuNzUgRShmb3IgdGhlIHN1Ym9yZGluYXRlIEZFQyBF
bmNvZGluZyBOYW1lcy4pNzIKNTMwLjYgUShVbmRlciB0aGUgc2NvcGUgb2YgYSBGRUMgRW5j
b2RpbmcgSWRlbnRpXDIxNGVyKTcyIDU1Ni42IFEgMi43NQooLEYpLS40NCBHKEVDIEVuY29k
aW5nIE5hbWVzIGFyZSBhc3NpZ25lZCBvbiBhIEZpcnN0KS0yLjc1IEUKKENvbWUgRmlyc3Qg
U2Vydik3MiA1NjkuNiBRKGVkIGJhc2UgdG8gcmVxdWVzdG9ycyB0aGF0IGFyZSBhYmxlIHRv
IHBybykKLS4xNjUgRSh2aWRlIHBvaW50IG9mIGNvbnRhY3QgaW5mb3JtYXRpb24gYW5kIGEp
LS4xNjUgRShwb2ludGVyIHRvIHB1YmxcCmljbHkgYWNjZXNzaWJsZSBkb2N1bWVudGF0aW9u
IGRlc2NyaWJpbmcgdGhlIEZFQyBzY2hlbWUgYW5kIHcpNzIgNTgyLjYgUQooYXlzIHRvIG9i
dGFpbiBpdCktLjExIEUoXChlLmcuIGEgcG9pbnRlciB0byBhIHB1YmxpY2x5IGEpNzIgNTk1
LjYgUQotLjI3NSh2YSktLjIyIEcKKGlsYWJsZSByZWZlcmVuY2UtaW1wbGVtZW50YXRpb24g
b3IgdGhlIG5hbWUgYW5kIGNvbnRhY3RzIG9mIGEpLjI3NSBFCihjb21wYW4pNzIgNjA4LjYg
USAyLjc1KHl0KS0uMTY1IEcoaGF0IHNlbGxzIGl0LCBlaXRoZXIgc2VwYXJhdGVseSBvciBl
XAptYmVkZGVkIGluIGFub3RoZXIgcHJvZHVjdFwpLiBUaGUgcmVxdWVzdG9yIGlzKS0yLjc1
IEUKKHJlc3BvbnNpYmxlIGZvciBrKTcyIDYyMS42IFEoZWVwaW5nIHRoaXMgaW5mb3JtYXRp
b24gdXAgdG8gZGF0ZS4pLS4xMSBFCkYzKDQuKTcyIDY2MC42IFEgRjQoQWNrbm8pNS41IEUo
d2xlZGdtZW50cyktLjE0IEUgRjAKKEJyaWFuIEFkYW1zb24gY29udHJpYik3MiA2NzcuMiBR
Cih1dGVkIHRvIHRoaXMgZG9jdW1lbnQgYnkgc2hhcGluZyBTZWN0aW9uIDIuMiBhbmQgcHJv
KS0uMjIgRQoodmlkaW5nIGdlbmVyYWwpLS4xNjUgRShmZWVkYmFjay4gVyk3MiA2OTAuMiBR
IDIuNzUoZWEpLS44OCBHCihsc28gd2lzaCB0byB0aGFuayBWKS0yLjc1IEUoaW5jZW50IFJv
Y2EgZm9yIGhpcyBjb21tZW50cy4pLS42NiBFCihMdWJ5L1YpNzIgNzY5IFEoaWNpc2Fuby9H
ZW1tZWxsL1JpenpvL0hhbmRsZSktLjY2IEUoeS9Dcm8pLS4xNjUgRQoxMTcuMzU2KHdjcm9m
dCBTZWN0aW9uKS0uMjc1IEYgMi43NSg0LiBbUCkyLjc1IEYoYWdlIDZdKS0uMTY1IEUgRVAK
JSVQYWdlOiA3IDcKJSVCZWdpblBhZ2VTZXR1cApCUAolJUVuZFBhZ2VTZXR1cAovRjAgMTEv
VGltZXMtUm9tYW5AMCBTRihJTlRFUk5FVCk3MiA0OSBRIDcxLjU4NygtRFJBRlQgRXhwaXJl
czopLTEuMDEyIEYKKEphbnVhcnkgMjAwMikyLjc1IEUoSnVseSAyMDAxKTEyMy43MjYgRS9G
MSAxMS9UaW1lcy1Cb2xkQDAgU0YoNS4pNzIgODUKUS9GMiAxNC9UaW1lcy1Cb2xkQDAgU0Yo
UmVmZXIpNS41IEUoZW5jZXMpLS4yNTIgRSBGMChbMV0gTHVieSk3MiAxMTQuNiBRCjIuNzUo
LE0pLS43MTUgRyguLCBWKS0yLjc1IEUKKGljaXNhbm8sIEdlbW1lbGwsIEouLCBMLiwgUml6
em8sIEwuLCBIYW5kbGUpLS42NiBFIDEuNDMgLS43MTUoeSwgTSkKLS4xNjUgSCAyLjc1KC4s
IENybykuNzE1IEYod2Nyb2Z0LCBKLiwgIlRoZSB1c2Ugb2YpLS4yNzUgRSAtLjE2NShGbyk3
MgoxMjcuNiBTKHJ3KS4xNjUgRShhcmQgRXJyb3IgQ29ycmVjdGlvbiBpbiBSZWxpYWJsZSBN
dWx0aWNhc3QiLCBJbnRlcm5ldFwKIGRyYWZ0IGRyYWZ0LWlldGYtcm10LWluZm8tZmVjLTAw
LnR4dCwpLS4xMSBFKE5vKTcyIDE0MC42IFEgLS4xNjUodmUpCi0uMTY1IEcobWJlciAyMDAw
LikuMTY1IEUgRjEoNi4pNzIgMTc5LjYgUSBGMiAtLjcoQXUpNS41IEcodGhvcnMnIEFkZHIp
Ci43IEUoZXNzZXMpLS4yNTIgRSBGMChNaWNoYWVsIEx1YnkpODAuMjUgMTk2LjIgUQoobHVi
eUBkaWdpdGFsZm91bnRhaW4uY29tKTgwLjI1IDIwOS4yIFEoRGlnaXRhbCBGKTgwLjI1IDIy
Mi4yIFEKKG91bnRhaW4sIEluYy4pLS4xNjUgRSgzOTE0MSBDaSk4MC4yNSAyMzUuMiBRKHZp
YyBDZW50ZXIgRHJpKS0uMjc1IEUKLS4xNjUodmUpLS4yNzUgRyhTdWl0ZSAzMDApODAuMjUg
MjQ4LjIgUShGcmVtb250LCBDQSk4MC4yNSAyNjEuMiBRCig5NDUzOCk1LjUgRShMb3Jlbnpv
IFYpODAuMjUgMjg3LjIgUShpY2lzYW5vKS0uNjYgRShsb3JlbnpvQGNpc2NvLmNvbSkKODAu
MjUgMzAwLjIgUShjaXNjbyBTeXN0ZW1zLCBJbmMuKTgwLjI1IDMxMy4yIFEoMTcwIFcpODAu
MjUgMzI2LjIgUQooZXN0IFQpLS44OCBFKGFzbWFuIERyKS0uODggRSguLCktLjYwNSBFKFNh
biBKb3NlLCBDQSwgVVNBLCA5NTEzNCk4MC4yNQozMzkuMiBRKEppbSBHZW1tZWxsKTgwLjI1
IDM2NS4yIFEoamdlbW1lbGxAbWljcm9zb2Z0LmNvbSk4MC4yNSAzNzguMiBRCihNaWNyb3Nv
ZnQgUmVzZWFyY2gpODAuMjUgMzkxLjIgUSgzMDEgSG8pODAuMjUgNDA0LjIgUSAtLjExKHdh
KS0uMjc1IEcKKHJkIFN0LiwgIzgzMCkuMTEgRShTYW4gRnJhbmNpc2NvLCBDQSwgVVNBLCA5
NDEwNSk4MC4yNSA0MTcuMiBRCihMdWlnaSBSaXp6byk4MC4yNSA0NDMuMiBRKGx1aWdpQGll
dC51bmlwaS5pdCk4MC4yNSA0NTYuMiBRIC0uNDQoQUMpCjgwLjI1IDQ2OS4yIFMoSVJJLCAx
OTQ3IENlbnRlciBTdC4sIEJlcmspLjQ0IEUoZWxlKS0uMTEgRSAyLjc1KHlDKS0uMTY1Ckcg
Mi43NShBOSktMi43NSBHKDQ3MDQpLTIuNzUgRShhbmQpODAuMjUgNDgyLjIgUQooRGlwLiBk
aSBJbmcuIGRlbGwnSW5mb3JtYXppb25lKTgwLjI1IDQ5NS4yIFEoVW5pKTgwLjI1IDUwOC4y
IFEgLS4xNjUKKHZlKS0uMjc1IEcocnNpdGFgIGRpIFBpc2EpLjE2NSBFKHZpYSBEaW90aXNh
bHZpIDIsIDU2MTI2IFBpc2EsIEl0YWx5KQo4MC4yNSA1MjEuMiBRKE1hcmsgSGFuZGxlKTgw
LjI1IDU0Ny4yIFEoeSktLjE2NSBFKG1qaEBhY2lyaS5vcik4MC4yNQo1NjAuMiBRKGcpLS4x
OTggRSAtLjQ0KEFDKTgwLjI1IDU3My4yIFMoSVJJKS40NCBFKDE5NDcgQ2VudGVyIFN0Lik4
MC4yNQo1ODYuMiBRKEJlcmspODAuMjUgNTk5LjIgUShlbGUpLS4xMSBFIDIuNzUoeUMpLS4x
NjUgRyhBLCBVU0EsIDk0NzA0KQotMi43NSBFKEpvbiBDcm8pODAuMjUgNjI1LjIgUSh3Y3Jv
ZnQpLS4yNzUgRShKLkNybyk4MC4yNSA2MzguMiBRCih3Y3JvZnRAY3MudWNsLmFjLnVrKS0u
Mjc1IEUoRGVwYXJ0bWVudCBvZiBDb21wdXRlciBTY2llbmNlKTgwLjI1IDY1MS4yClEoVW5p
KTgwLjI1IDY2NC4yIFEgLS4xNjUodmUpLS4yNzUgRyhyc2l0eSBDb2xsZSkuMTY1IEUoZ2Ug
TG9uZG9uKS0uMTY1CkUoR28pODAuMjUgNjc3LjIgUSh3ZXIgU3RyZWV0LCktLjI3NSBFKExv
bmRvbiBXQzFFIDZCVCk4MC4yNSA2OTAuMiBRCjIuNzUoLFUpLS44MTQgRyhLKS0yLjc1IEUo
THVieS9WKTcyIDc2OSBRKGljaXNhbm8vR2VtbWVsbC9SaXp6by9IYW5kbGUpCi0uNjYgRSh5
L0NybyktLjE2NSBFIDExNy4zNTYod2Nyb2Z0IFNlY3Rpb24pLS4yNzUgRiAyLjc1KDYuIFtQ
KTIuNzUgRgooYWdlIDddKS0uMTY1IEUgRVAKJSVQYWdlOiA4IDgKJSVCZWdpblBhZ2VTZXR1
cApCUAolJUVuZFBhZ2VTZXR1cAovRjAgMTEvVGltZXMtUm9tYW5AMCBTRihJTlRFUk5FVCk3
MiA0OSBRIDcxLjU4NygtRFJBRlQgRXhwaXJlczopLTEuMDEyIEYKKEphbnVhcnkgMjAwMiky
Ljc1IEUoSnVseSAyMDAxKTEyMy43MjYgRS9GMSAxMS9UaW1lcy1Cb2xkQDAgU0YoNy4pNzIg
ODUKUS9GMiAxNC9UaW1lcy1Cb2xkQDAgU0YoRnVsbCBDb3B5cmlnaHQgU3RhdGVtZW50KTUu
NSBFIEYwKENvcCk3MiAxMDEuNiBRCih5cmlnaHQgXChDXCkgVGhlIEludGVybmV0IFNvY2ll
dHkgXCgyMDAwXCkuKS0uMTEgRShBbGwgUmlnaHRzIFJlc2VydikKNS41IEUoZWQuKS0uMTY1
IEUoVGhpcyBkb2N1bWVudCBhbmQgdHJhbnNsYXRpb25zIG9mIGl0IG1heSBiZSBjb3BpZWQg
YW5cCmQgZnVybmlzaGVkIHRvIG90aGVycywgYW5kIGRlcmkpNzIgMTE4LjIgUSAtLjI3NSh2
YSktLjI3NSBHKHRpKS4yNzUgRQouMzMgLS4xNjUodmUgdyktLjI3NSBIKG9ya3MpLjA1NSBF
KHRoYXQgY29tbWVudCBvbiBvciBvdGhlcndpc2UgZSk3MgoxMzEuMiBRCih4cGxhaW4gaXQg
b3IgYXNzaXN0IGluIGl0cyBpbXBsZW1lbnRhdGlvbiBtYXkgYmUgcHJlcGFyZWQsIGNvcGll
ZCwpCi0uMTY1IEUocHVibGlzaGVkIGFuZCBkaXN0cmliKTcyIDE0NC4yIFEKKHV0ZWQsIGlu
IHdob2xlIG9yIGluIHBhcnQsIHdpdGhvdXQgcmVzdHJpY3Rpb24gb2YgYW4pLS4yMiBFIDIu
NzUoeWspCi0uMTY1IEcoaW5kLCBwcm8pLTIuNzUgRSh2aWRlZCB0aGF0IHRoZSktLjE2NSBF
KGFibyk3MiAxNTcuMiBRIC4zMyAtLjE2NQoodmUgYyktLjE2NSBIKG9wKS4xNjUgRSh5cmln
aHQgbm90aWNlIGFuZCB0aGlzIHBhcmFncmFwaCBhcmUgaW5jbHVkZWQgb1wKbiBhbGwgc3Vj
aCBjb3BpZXMgYW5kIGRlcmkpLS4xMSBFIC0uMjc1KHZhKS0uMjc1IEcodGkpLjI3NSBFIC4z
MyAtLjE2NQoodmUgdyktLjI3NSBIKG9ya3MuKS4wNTUgRShIbyk3MiAxNzAuMiBRKHdlKS0u
Mjc1IEUgLS4xNjUodmUpLS4yNzUgRyAuODgKLS40NChyLCB0KS4xNjUgSChoaXMgZG9jdW1l
bnQgaXRzZWxmIG1heSBub3QgYmUgbW9kaVwyMTRlZCBpbiBhbikuNDQgRQoyLjc1KHl3KS0u
MTY1IEcoYXkpLTIuODYgRSAyLjc1KCxzKS0uNzE1IEcodWNoIGFzIGJ5IHJlbW8pLTIuNzUg
RQoodmluZyB0aGUpLS4xNjUgRShjb3ApNzIgMTgzLjIgUSh5cmlnaHQgbm90aWNlIG9yIHJl
ZmVyZW5jZXMgdG8gdGhlIEludFwKZXJuZXQgU29jaWV0eSBvciBvdGhlciBJbnRlcm5ldCBv
ciktLjExIEUgLS4wNTUoZ2EpLS4xOTggRyhuaXphdGlvbnMsIGUpCi4wNTUgRSh4Y2VwdCBh
cyktLjE2NSBFKG5lZWRlZCBmb3IgdGhlIHB1cnBvc2Ugb2YgZGUpNzIgMTk2LjIgUSAtLjE2
NQoodmUpLS4yNzUgRyhsb3BpbmcgSW50ZXJuZXQgc3RhbmRhcmRzIGluIHdoaWNoIGNhc2Ug
dGhlIHByb2NlZHVyZXMgZm9yKQouMTY1IEUoY29wKTcyIDIwOS4yIFEKKHlyaWdodHMgZGVc
MjE0bmVkIGluIHRoZSBJbnRlcm5ldCBsYW5ndWFnZXMgb3RoZXIgdGhhbiBFbmdsaXNoLikt
LjExIEUKKFRoZSBsaW1pdGVkIHBlcm1pc3Npb25zIGdyYW50ZWQgYWJvKTcyIDIyNS44IFEg
LjMzIC0uMTY1KHZlIGEpLS4xNjUgSAoocmUgcGVycGV0dWFsIGFuZCB3aWxsIG5vdCBiZSBy
ZSkuMTY1IEUgLS4yMih2byktLjI3NSBHIC0uMTEoa2UpLjIyIEcKMi43NShkYikuMTEgRyAy
Ljc1KHl0KS0yLjc1IEcoaGUgSW50ZXJuZXQpLTIuNzUgRQooU29jaWV0eSBvciBpdHMgc3Vj
Y2Vzc29ycyBvciBhc3NpZ25zLik3MiAyMzguOCBRCihUaGlzIGRvY3VtZW50IGFuZCB0aGUg
aW5mb3JtYXRpb24gY29udGFpbmVkIGhlcmVpbiBpcyBwcm8pNzIgMjU1LjQgUQoodmlkZWQg
b24gYW4gIkFTIElTIiBiYXNpcyBhbmQgVEhFKS0uMTY1IEUKKElOVEVSTkVUIFNPQ0lFVFkg
QU5EIFRIRSBJTlRFUk5FVCBFTkdJTkVFUklORyBUKTcyIDI2OC40IFEKKEFTSyBGT1JDRSBE
SVNDTEFJTVMpLTEuMDIzIEUoQUxMIFcpNzIgMjgxLjQgUQooQVJSQU5USUVTLCBFWFBSRVNT
IE9SIElNUExJRUQsIElOQ0xVRElORyBCKS0xLjMyIEUoVVQgTk8pLS4xMSBFIDIuNzUKKFRM
KS0uNDQgRyhJTUlURUQgVCktMi43NSBFIDIuNzUoT0EpLS4xOTggRyhOWSktMi43NSBFIC0x
LjMyKFdBKTcyIDI5NC40ClMoUlJBTlRZIFRIQSkxLjMyIEUgMi43NShUVCktMS4yMjEgRyhI
RSBVU0UgT0YgVEhFIElORk9STUEpLTIuNzUgRQooVElPTiBIRVJFSU4gV0lMTCBOTyktMS4y
MjEgRSAyLjc1KFRJKS0uNDQgRyhORlJJTkdFKS0yLjc1IEUKKEFOWSBSSUdIVFMgT1IgQU5Z
IElNUExJRUQgVyk3MiAzMDcuNCBRKEFSUkFOVElFUyBPRiBNRVJDSEFOVCktMS4zMiBFCihB
QklMSVRZIE9SIEZJVE5FU1MpLTEuMDIzIEUoRk9SIEEgUCk3MiAzMjAuNCBRKEFSKS0xLjAx
MiBFCihUSUNVTEFSIFBVUlBPU0UuIiktLjY2IEUoTHVieS9WKTcyIDc2OSBRKGljaXNhbm8v
R2VtbWVsbC9SaXp6by9IYW5kbGUpCi0uNjYgRSh5L0NybyktLjE2NSBFIDExNy4zNTYod2Ny
b2Z0IFNlY3Rpb24pLS4yNzUgRiAyLjc1KDcuIFtQKTIuNzUgRgooYWdlIDhdKS0uMTY1IEUg
RVAKJSVQYWdlOiA5IDkKJSVCZWdpblBhZ2VTZXR1cApCUAolJUVuZFBhZ2VTZXR1cAovRjAg
MTEvVGltZXMtUm9tYW5AMCBTRihJTlRFUk5FVCk3MiA0OSBRIDcxLjU4NygtRFJBRlQgRXhw
aXJlczopLTEuMDEyIEYKKEphbnVhcnkgMjAwMikyLjc1IEUoSnVseSAyMDAxKTEyMy43MjYg
RShMdWJ5L1YpNzIgNzY5IFEKKGljaXNhbm8vR2VtbWVsbC9SaXp6by9IYW5kbGUpLS42NiBF
KHkvQ3JvKS0uMTY1IEUgMTE3LjM1Ngood2Nyb2Z0IFNlY3Rpb24pLS4yNzUgRiAyLjc1KDcu
IFtQKTIuNzUgRihhZ2UgOV0pLS4xNjUgRSBFUAolJVRyYWlsZXIKZW5kCiUlRU9GCg==
--==_Exmh_5297534880--
>From owner-rmt@listserv.lbl.gov Thu Jul 19 23:08:07 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f6K67KM16714;
Thu, 19 Jul 2001 23:07:20 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f6K67JR16710
for <rmt@listserv.lbl.gov>; Thu, 19 Jul 2001 23:07:19 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f6K67It05223
for <rmt@listserv.lbl.gov>; Thu, 19 Jul 2001 23:07:18 -0700 (PDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f6K67IA05220
for <rmt@lbl.gov>; Thu, 19 Jul 2001 23:07:18 -0700 (PDT)
Received: from lorenzo-u10.cisco.com (lorenzo-u10.cisco.com [128.107.162.143])
by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f6K0C4X18278;
Thu, 19 Jul 2001 17:12:04 -0700 (PDT)
Received: from localhost (lorenzo@localhost) by lorenzo-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id RAA01812; Thu, 19 Jul 2001 17:11:45 -0700 (PDT)
Message-Id: <200107200011.RAA01812@lorenzo-u10.cisco.com>
X-Authentication-Warning: lorenzo-u10.cisco.com: lorenzo owned process doing -bs
X-Mailer: exmh version 2.3.1 01/18/2001 with version: MH 6.8.4 #29[UCI]
To: internet-drafts@ietf.org
cc: adamson@itd.nrl.navy.mil, jgemmell@MICROSOFT.com, luigi@iet.unipi.it,
mjh@aciri.org, J.Crowcroft@cs.ucl.ac.uk, lorenzo@cisco.com, rmt@lbl.gov
Subject: draft-ietf-rmt-bb-fec-03.txt
Mime-Version: 1.0
Content-Type: multipart/mixed ;
boundary="==_Exmh_5297534880"
Date: Thu, 19 Jul 2001 17:11:45 -0700
From: Lorenzo Vicisano <lorenzo@cisco.com>
Sender: owner-rmt@lbl.gov
Precedence: bulk
This is a multipart MIME message.
--==_Exmh_5297534880
Content-Type: text/plain; charset=us-ascii
Please post this draft on the IETF Internet Drafts archive.
This is an update of an existing WG draft (RMT).
Thank you,
Lorenzo Vicisano
--==_Exmh_5297534880
Content-Type: text/plain ; name="draft-ietf-rmt-bb-fec-03.txt"; charset=us-ascii
Content-Description: draft-ietf-rmt-bb-fec-03.txt
Content-Disposition: attachment; filename="draft-ietf-rmt-bb-fec-03.txt"
Internet Engineering Task Force RMT WG
INTERNET-DRAFT M.Luby/Digital Fountain
draft-ietf-rmt-bb-fec-03.txt L.Vicisano/Cisco
J.Gemmell/Microsoft
L.Rizzo/ACIRI and Univ. Pisa
M.Handley/ACIRI
J. Crowcroft/UCL
19 July 2001
Expires: January 2002
RMT BB Forward Error Correction Codes
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts.
Internet-Drafts are valid for a maximum of six months and may be
updated, replaced, or obsoleted by other documents at any time. It is
inappropriate to use Internet-Drafts as reference material or to cite
them other than as a "work in progress".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html.
This document is a product of the IETF RMT WG. Comments should be
addressed to the authors, or the WG's mailing list at rmt@isi.edu.
Abstract
This memo describes the abstract packet formats and IANA
registration procedures for use of Forward Error Correction
(FEC) codes within the context of reliable IP multicast
transport. This memo should be read in conjunction with and
uses the terminology of the companion memo [1], which
describes the use of Forward Error Correction (FEC) codes
within the context of reliable IP multicast transport and
Luby/Vicisano/Gemmell/Rizzo/Handley/Crowcroft [Page 1]
^L
INTERNET-DRAFT Expires: January 2002 July 2001
provides an introduction to some commonly used FEC codes.
1. FEC Abstract Packet Fields and Out-of-Band Information
This section specifies the information that protocol packets must carry
to implement the various forms of FEC-based reliability. A session is
defined to be all the information associated with a transmission of data
about a particular object by a single sender. There are three classes
of packets that may contain FEC information within a session: data
packets, session-control packets and feedback packets. They generally
contain different kinds of FEC information. Note that some protocols do
not use feedback packets.
Data packets may sometime serve as session-control packets as well; both
data and session-control packets generally travel downstream (from the
sender towards receivers) and are addressed to a multicast IP address
(sometime they might be addressed to the unicast address of a specific
receiver). In the following, for simplicity we will refer to both data
and session control packets as downstream-traveling packets, or simply
downstream packets.
As a general rule, feedback packets travel upstream (from receivers to
the sender) and are addressed to the unicast address of the sender.
Sometimes, however, they might be addressed to a multicast IP address or
to the unicast address of a receiver or also the the unicast address of
some different node (an intermediate node that provides recovery
services or a neighboring router).
The FEC-related information that can be present in downstream packets
can be classified as follows:
1) FEC Encoding Identifier
Identifies the FEC encoding being used and has the purpose of
allowing receivers to select the appropriate FEC decoder. As a
general rule, the "FEC Encoding Identifier" MUST be the same for a
given session, i.e., for all transmission of data related to a
particular object, but MAY vary across different transmissions of
data about different objects in different sessions, even if
transmitted using the same set of multicast groups and/or using a
single upper-layer session.
2) FEC payload ID
Identifies the symbol(s) in the payload of the packet. The content
of this piece of information depends on the encoder being used
Luby/Vicisano/Gemmell/Rizzo/Handley/Crowcroft Section 1. [Page 2]
^L
INTERNET-DRAFT Expires: January 2002 July 2001
(e.g. in Block FEC codes this may be the combination of block
index and encoding symbol identifier; in ideal expandable FEC
codes this may be just a flat encoding symbol identifier).
3) FEC Object Transmission Information
This is information regarding the encoding of a specific object
needed by the FEC decoder (e.g. for Block FEC codes this may be
the combination of block length and object length). This might
also include general parameters of the FEC encoder. Note that, in
strict terms, the "FEC Encoding Identifier" belongs to this class
of information, however, for practical purposes, we will consider
it separately.
All the classes of information above, except 2), can either be
transmitted within the transport session (using protocol packet-header
fields) or out of band. The information described in 2) MUST be
transmitted in data-packet header fields, as it provides a description
of the data contained in the packet. In the following we will specify
the content of 1), 2) and 3) regardless of whether these pieces of
information are transmitted in protocol packets or out of band. This
document neither specifies out-of-band methods to transport the
information nor does it specify the way out-of-band information is
associated with packet payloads. This last task is devolved to an upper-
layer protocol.
Within the context of FEC repair schemes, feedback packets are
(optionally) used to request FEC retransmission. The FEC-related
information present in feedback packets usually contains an FEC Block
Identifier, that defines the block that is being repaired, and the
number of Repair Symbols requested. Although this is the most common
case, variants are possible in which the receivers provide more specific
information about the Repair Symbols requested (e.g. an index range or a
list of symbols accepted). It is also possible to include multiple of
these request in a single feedback packet.
This document does not provide any detail about the format of FEC
information in feedback packets.
1.1. FEC Encoding Identifier
This is a numeric index that identifies a specific FEC scheme OR a class
of encoding schemes that share the same format of "FEC Payload ID" and
"FEC Object Transmission Information".
Luby/Vicisano/Gemmell/Rizzo/Handley/Crowcroft Section 1.1. [Page 3]
^L
INTERNET-DRAFT Expires: January 2002 July 2001
The FEC Encoding Identifier identifies a specific FEC scheme when the
encoding scheme is formally and fully specified, in a way that
independent implementors can implement both encoder and decoder from the
specification. Companion documents of this specification may specify
such FEC schemes and associate them with "FEC Encoding Identifier"
values. These documents MUST also specify a correspondent format for the
"FEC Payload ID" and "FEC Object Transmission Information". Currently
FEC Encoding Identifiers in the range 0-127 are reserved for this class
of encoding schemes (fully-specified schemes).
It is possible that a FEC scheme cannot be completely specified or that
such a specification is simply not available or also that a party exists
that owns the encoding scheme and it is not willing to disclose its
algorithm. We refer to these encoding schemes as "Under-Specified"
schemes. Under-specified schemes can still be identified as follows:
o A format of the fields "FEC Payload ID" and "FEC Object Transmission
Information" MUST be defined for the encoding scheme.
o A value of "FEC Encoding Identifier" MUST be reserved and associated
to the format definitions above. An already reserved "FEC Encoding
Identifier" MUST be reused if it is associated to the same format
of "FEC Payload ID" and "FEC Object Transmission Information" as the
ones needed for the new under-specified FEC scheme.
o A value of "FEC Encoding Name" must be reserved (see below).
An Under-specified FEC scheme is completely identified by the tuple (FEC
Encoding Identifier, FEC Encoding Name). The tuple MUST identify a
single scheme that has at least one implementation. The party that owns
this tuple MUST be able to provide information on how to obtain the
under-specified FEC scheme identified by the tuple (e.g. a pointer to a
publicly available reference-implementation or the name and contacts of
a company that sells it, either separately or embedded in another
product).
"FEC Encoding Names" are numeric identifiers scoped by a FEC Encoding
Identifier.
The FEC Encoding Name MUST be part of the "FEC Object Transmission
Information" and must be communicated to receivers together with the FEC
Encoding Identifier.
Different FEC schemes that share the same FEC Encoding Identifier -- but
have different FEC Encoding Names -- also share the same format of FEC
Payload ID and FEC Object Transmission Information.
Luby/Vicisano/Gemmell/Rizzo/Handley/Crowcroft Section 1.1. [Page 4]
^L
INTERNET-DRAFT Expires: January 2002 July 2001
This specification reserves the range 0-127 of FEC Encoding Identifiers
for fully-specified encoding schemes and the range 128-255 for under-
specified encoding schemes.
1.2. FEC Payload ID and FEC Object Transmission Information
A document that specifies an encoding scheme and reserves a value
of FEC Encoding Identifier MUST define a packet-field format for FEC
Payload ID and FEC Object Transmission Information according to the need
of the encoding scheme. This also applies to documents that reserves
values of FEC Encoding Identifiers for under-specified encoding schemes.
In this case the FEC Object Transmission Information must also include a
field to contain the "FEC Encoding Name".
A packet field definition of FEC Object Transmission Information MUST be
provided despite the fact that a protocol instantiation may decide to
communicate this information out of band.
All packet field definitions (FEC Payload ID and FEC Object Transmission
Information) MUST be fully specified at the level of bit-fields and they
must have a length that is a multiple of a 4-byte word (this is to
facilitate the alignment of packet fields in protocol instantiations).
Note that the specification of FEC Payload ID MUST allow an
implementation-independent identification of the packet payload even in
the case of Under-Specified encoding schemes.
2. Preassigned FEC Encoding Identifiers
This section specifies the FEC Encoding Identifier and the relative
packets field for a number of known schemes that follow under the class
of under-specified FEC schemes. Others may be specified in companion
documents.
2.1. Small Block, Large Block and Expandable FEC Codes
This section reserves a FEC Encoding Identifier for the families of
codes described in [1], and specifies the relative packet fields.
Under-specified FEC schemes that belong to this class MUST use this
identifier and packet field definitions.
The FEC Encoding Identifier for under specified codes assigned to Small
Block, Large Block, and Expandable FEC Codes is 128.
Luby/Vicisano/Gemmell/Rizzo/Handley/Crowcroft Section 2.1. [Page 5]
^L
INTERNET-DRAFT Expires: January 2002 July 2001
The FEC Payload ID is composed of an encoding symbol identifier and an
encoding block number structured as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| encoding block number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| encoding symbol ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In addition, a one bit FEC Encoding Flag MAY be included, and this flag
indicates whether the encoding symbol(s) in the payload of the packet
are source symbol(s) or redundant symbol(s).
The FEC Object Transmission Information has the following structure:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC Encoding Name | Object Length (MSB) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Object Length (LSB) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Block Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note that this structure limits the range of possible FEC Encoding Names
to 0-:-65536, despite the fact that the FEC Object Transmission
Information can also be transmitted out of band.
The Object Length, composed of a Most Significant Bytes portion (MSB)
and a Least Significant Bytes portion (LSB), is expressed in bytes.
2.2. Small Block Systematic FEC Codes
The following definitions apply to systematic codes of small length
(total block length < 2^16).
The FEC Encoding Identifier for under specified codes assigned to Small
Block Systematic FEC Codes is 129.
Although these codes can generally be accommodated by the FEC Encoding
Luby/Vicisano/Gemmell/Rizzo/Handley/Crowcroft Section 2.2. [Page 6]
^L
INTERNET-DRAFT Expires: January 2002 July 2001
Identifier described in Section 2.1, a specific Encoding-ID is defined
for systematic codes to allow better flexibility and to retain header
compactness. The small source block length and small exapansion factor
that often characterize systematic codes may require that the data
source changes frequently the source block length. To allow the dynamic
variation of the source block length and to communicate it to the
receivers with low overhead, the block length is included in the FEC
Payload ID.
The FEC Payload ID is composed of the encoding block number, the
encoding symbol identifier and the block length:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| encoding block number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source block length | encoding symbol ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The FEC Object Transmission Information, when used, has the following
structure:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC Encoding Name | Number of redundant symbols |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
When variable block-length is used, the number of redundant symbols is
to be interpreted as a maximum value (upper bound). This field is
provided as an indication to allow receives to preallocate a decoder
suitable for all the object blocks.
Note that this structure limits the range of possible FEC Encoding Names
to 0-:-65536, despite the FEC Object Transmission Information can also
be transmitted out of band.
3. IANA Considerations
Values of FEC Encoding Identifiers and FEC Encoding Names are subject to
IANA registration. FEC Encoding Identifiers and FEC Encoding Names are
hierarchical: FEC Encoding Identifiers (at the top level) scope ranges
Luby/Vicisano/Gemmell/Rizzo/Handley/Crowcroft Section 3. [Page 7]
^L
INTERNET-DRAFT Expires: January 2002 July 2001
of FEC Encoding Names. Not all FEC Encoding Identifiers have a
corresponding FEC Encoding Name scope (see below).
A FEC Encoding Identifier is a numeric non-negative index. Value from 0
to 127 are reserved for FEC encoders that are fully specified, as
described in section 3.1. The assignment of a FEC Encoding Identifier in
this range can only be granted if the requestor can provide such a
specification published as an IETF RFC. Values greater than 127 can be
assigned to under-specified encoding schemes. Note: this specification
already assigns the values 128 and 129.
In any case values of FEC Encoding Identifiers can only be assigned if
the required FEC packet fields corresponding to it (see section 1.2) are
specified in a RFC.
Each FEC Encoding Identifier assigned to an under-specified encoding
scheme scopes an independent range of FEC Encoding Names (i.e. the same
value of FEC Encoding Name can be reused for different FEC Encoding
Identifiers). An FEC Encoding Name is a numeric non-negative index. The
document that reserves a FEC Encoding Identifier MAY also specify a
range for the subordinate FEC Encoding Names.
Under the scope of a FEC Encoding Identifier, FEC Encoding Names are
assigned on a First Come First Served base to requestors that are able
to provide point of contact information and a pointer to publicly
accessible documentation describing the FEC scheme and ways to obtain it
(e.g. a pointer to a publicly available reference-implementation or the
name and contacts of a company that sells it, either separately or
embedded in another product). The requestor is responsible for keeping
this information up to date.
4. Acknowledgments
Brian Adamson contributed to this document by shaping Section 2.2 and
providing general feedback. We also wish to thank Vincent Roca for his
comments.
5. References
[1] Luby, M., Vicisano, Gemmell, J., L., Rizzo, L., Handley, M.,
Crowcroft, J., "The use of Forward Error Correction in Reliable
Multicast", Internet draft draft-ietf-rmt-info-fec-00.txt, November
2000.
Luby/Vicisano/Gemmell/Rizzo/Handley/Crowcroft Section 5. [Page 8]
^L
INTERNET-DRAFT Expires: January 2002 July 2001
6. Authors' Addresses
Michael Luby
luby@digitalfountain.com
Digital Fountain, Inc.
39141 Civic Center Drive
Suite 300
Fremont, CA 94538
Lorenzo Vicisano
lorenzo@cisco.com
cisco Systems, Inc.
170 West Tasman Dr.,
San Jose, CA, USA, 95134
Jim Gemmell
jgemmell@microsoft.com
Microsoft Research
301 Howard St., #830
San Francisco, CA, USA, 94105
Luigi Rizzo
luigi@iet.unipi.it
ACIRI, 1947 Center St., Berkeley CA 94704
and
Dip. di Ing. dell'Informazione
Universita` di Pisa
via Diotisalvi 2, 56126 Pisa, Italy
Mark Handley
mjh@aciri.org
ACIRI
1947 Center St.
Berkeley CA, USA, 94704
Jon Crowcroft
J.Crowcroft@cs.ucl.ac.uk
Department of Computer Science
University College London
Gower Street,
London WC1E 6BT, UK
Luby/Vicisano/Gemmell/Rizzo/Handley/Crowcroft Section 6. [Page 9]
^L
INTERNET-DRAFT Expires: January 2002 July 2001
7. Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are included
on all such copies and derivative works. However, this document itself
may not be modified in any way, such as by removing the copyright notice
or references to the Internet Society or other Internet organizations,
except as needed for the purpose of developing Internet standards in
which case the procedures for copyrights defined in the Internet
languages other than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE."
Luby/Vicisano/Gemmell/Rizzo/Handley/Crowcroft Section 7. [Page 10]
^L
INTERNET-DRAFT Expires: January 2002 July 2001
Luby/Vicisano/Gemmell/Rizzo/Handley/Crowcroft Section 7. [Page 11]
--==_Exmh_5297534880
Content-Type: application/postscript ; name="draft-ietf-rmt-bb-fec-03.ps"
Content-Description: draft-ietf-rmt-bb-fec-03.ps
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="draft-ietf-rmt-bb-fec-03.ps"
JSFQUy1BZG9iZS0zLjAKJSVDcmVhdG9yOiBncm9mZiB2ZXJzaW9uIDEuMTYuMQolJUNyZWF0
aW9uRGF0ZTogVGh1IEp1bCAxOSAxNzowODoxNCAyMDAxCiUlRG9jdW1lbnROZWVkZWRSZXNv
dXJjZXM6IGZvbnQgQ291cmllci1Cb2xkCiUlKyBmb250IFRpbWVzLUJvbGQKJSUrIGZvbnQg
VGltZXMtUm9tYW4KJSUrIGZvbnQgQ291cmllcgolJURvY3VtZW50U3VwcGxpZWRSZXNvdXJj
ZXM6IHByb2NzZXQgZ3JvcHMgMS4xNiAxCiUlUGFnZXM6IDkKJSVQYWdlT3JkZXI6IEFzY2Vu
ZAolJU9yaWVudGF0aW9uOiBQb3J0cmFpdAolJUVuZENvbW1lbnRzCiUlQmVnaW5Qcm9sb2cK
JSVCZWdpblJlc291cmNlOiBwcm9jc2V0IGdyb3BzIDEuMTYgMQovc2V0cGFja2luZyB3aGVy
ZXsKcG9wCmN1cnJlbnRwYWNraW5nCnRydWUgc2V0cGFja2luZwp9aWYKL2dyb3BzIDEyMCBk
aWN0IGR1cCBiZWdpbgovU0MgMzIgZGVmCi9BL3Nob3cgbG9hZCBkZWYKL0J7MCBTQyAzIC0x
IHJvbGwgd2lkdGhzaG93fWJpbmQgZGVmCi9DezAgZXhjaCBhc2hvd31iaW5kIGRlZgovRHsw
IGV4Y2ggMCBTQyA1IDIgcm9sbCBhd2lkdGhzaG93fWJpbmQgZGVmCi9FezAgcm1vdmV0byBz
aG93fWJpbmQgZGVmCi9GezAgcm1vdmV0byAwIFNDIDMgLTEgcm9sbCB3aWR0aHNob3d9Ymlu
ZCBkZWYKL0d7MCBybW92ZXRvIDAgZXhjaCBhc2hvd31iaW5kIGRlZgovSHswIHJtb3ZldG8g
MCBleGNoIDAgU0MgNSAyIHJvbGwgYXdpZHRoc2hvd31iaW5kIGRlZgovSXswIGV4Y2ggcm1v
dmV0byBzaG93fWJpbmQgZGVmCi9KezAgZXhjaCBybW92ZXRvIDAgU0MgMyAtMSByb2xsIHdp
ZHRoc2hvd31iaW5kIGRlZgovS3swIGV4Y2ggcm1vdmV0byAwIGV4Y2ggYXNob3d9YmluZCBk
ZWYKL0x7MCBleGNoIHJtb3ZldG8gMCBleGNoIDAgU0MgNSAyIHJvbGwgYXdpZHRoc2hvd31i
aW5kIGRlZgovTXtybW92ZXRvIHNob3d9YmluZCBkZWYKL057cm1vdmV0byAwIFNDIDMgLTEg
cm9sbCB3aWR0aHNob3d9YmluZCBkZWYKL097cm1vdmV0byAwIGV4Y2ggYXNob3d9YmluZCBk
ZWYKL1B7cm1vdmV0byAwIGV4Y2ggMCBTQyA1IDIgcm9sbCBhd2lkdGhzaG93fWJpbmQgZGVm
Ci9Re21vdmV0byBzaG93fWJpbmQgZGVmCi9Se21vdmV0byAwIFNDIDMgLTEgcm9sbCB3aWR0
aHNob3d9YmluZCBkZWYKL1N7bW92ZXRvIDAgZXhjaCBhc2hvd31iaW5kIGRlZgovVHttb3Zl
dG8gMCBleGNoIDAgU0MgNSAyIHJvbGwgYXdpZHRoc2hvd31iaW5kIGRlZgovU0Z7CmZpbmRm
b250IGV4Y2gKW2V4Y2ggZHVwIDAgZXhjaCAwIGV4Y2ggbmVnIDAgMF1tYWtlZm9udApkdXAg
c2V0Zm9udApbZXhjaC9zZXRmb250IGN2eF1jdnggYmluZCBkZWYKfWJpbmQgZGVmCi9NRnsK
ZmluZGZvbnQKWzUgMiByb2xsCjAgMyAxIHJvbGwKbmVnIDAgMF1tYWtlZm9udApkdXAgc2V0
Zm9udApbZXhjaC9zZXRmb250IGN2eF1jdnggYmluZCBkZWYKfWJpbmQgZGVmCi9sZXZlbDAg
MCBkZWYKL1JFUyAwIGRlZgovUEwgMCBkZWYKL0xTIDAgZGVmCi9NQU5VQUx7CnN0YXR1c2Rp
Y3QgYmVnaW4vbWFudWFsZmVlZCB0cnVlIHN0b3JlIGVuZAp9YmluZCBkZWYKL1BMR3sKZ3Nh
dmUgbmV3cGF0aCBjbGlwcGF0aCBwYXRoYmJveCBncmVzdG9yZQpleGNoIHBvcCBhZGQgZXhj
aCBwb3AKfWJpbmQgZGVmCi9CUHsKL2xldmVsMCBzYXZlIGRlZgoxIHNldGxpbmVjYXAKMSBz
ZXRsaW5lam9pbgo3MiBSRVMgZGl2IGR1cCBzY2FsZQpMU3sKOTAgcm90YXRlCn17CjAgUEwg
dHJhbnNsYXRlCn1pZmVsc2UKMSAtMSBzY2FsZQp9YmluZCBkZWYKL0VQewpsZXZlbDAgcmVz
dG9yZQpzaG93cGFnZQp9YmluZCBkZWYKL0RBewpuZXdwYXRoIGFyY24gc3Ryb2tlCn1iaW5k
IGRlZgovU057CnRyYW5zZm9ybQouMjUgc3ViIGV4Y2ggLjI1IHN1YiBleGNoCnJvdW5kIC4y
NSBhZGQgZXhjaCByb3VuZCAuMjUgYWRkIGV4Y2gKaXRyYW5zZm9ybQp9YmluZCBkZWYKL0RM
ewpTTgptb3ZldG8KU04KbGluZXRvIHN0cm9rZQp9YmluZCBkZWYKL0RDewpuZXdwYXRoIDAg
MzYwIGFyYyBjbG9zZXBhdGgKfWJpbmQgZGVmCi9UTSBtYXRyaXggZGVmCi9ERXsKVE0gY3Vy
cmVudG1hdHJpeCBwb3AKdHJhbnNsYXRlIHNjYWxlIG5ld3BhdGggMCAwIC41IDAgMzYwIGFy
YyBjbG9zZXBhdGgKVE0gc2V0bWF0cml4Cn1iaW5kIGRlZgovUkMvcmN1cnZldG8gbG9hZCBk
ZWYKL1JML3JsaW5ldG8gbG9hZCBkZWYKL1NUL3N0cm9rZSBsb2FkIGRlZgovTVQvbW92ZXRv
IGxvYWQgZGVmCi9DTC9jbG9zZXBhdGggbG9hZCBkZWYKL0ZMewpjdXJyZW50Z3JheSBleGNo
IHNldGdyYXkgZmlsbCBzZXRncmF5Cn1iaW5kIGRlZgovQkwvZmlsbCBsb2FkIGRlZgovTFcv
c2V0bGluZXdpZHRoIGxvYWQgZGVmCi9SRXsKZmluZGZvbnQKZHVwIG1heGxlbmd0aCAxIGlu
ZGV4L0ZvbnROYW1lIGtub3duIG5vdHsxIGFkZH1pZiBkaWN0IGJlZ2luCnsKMSBpbmRleC9G
SUQgbmV7ZGVmfXtwb3AgcG9wfWlmZWxzZQp9Zm9yYWxsCi9FbmNvZGluZyBleGNoIGRlZgpk
dXAvRm9udE5hbWUgZXhjaCBkZWYKY3VycmVudGRpY3QgZW5kIGRlZmluZWZvbnQgcG9wCn1i
aW5kIGRlZgovREVGUyAwIGRlZgovRUJFR0lOewptb3ZldG8KREVGUyBiZWdpbgp9YmluZCBk
ZWYKL0VFTkQvZW5kIGxvYWQgZGVmCi9DTlQgMCBkZWYKL2xldmVsMSAwIGRlZgovUEJFR0lO
ewovbGV2ZWwxIHNhdmUgZGVmCnRyYW5zbGF0ZQpkaXYgMyAxIHJvbGwgZGl2IGV4Y2ggc2Nh
bGUKbmVnIGV4Y2ggbmVnIGV4Y2ggdHJhbnNsYXRlCjAgc2V0Z3JheQowIHNldGxpbmVjYXAK
MSBzZXRsaW5ld2lkdGgKMCBzZXRsaW5lam9pbgoxMCBzZXRtaXRlcmxpbWl0CltdMCBzZXRk
YXNoCi9zZXRzdHJva2VhZGp1c3Qgd2hlcmV7CnBvcApmYWxzZSBzZXRzdHJva2VhZGp1c3QK
fWlmCi9zZXRvdmVycHJpbnQgd2hlcmV7CnBvcApmYWxzZSBzZXRvdmVycHJpbnQKfWlmCm5l
d3BhdGgKL0NOVCBjb3VudGRpY3RzdGFjayBkZWYKdXNlcmRpY3QgYmVnaW4KL3Nob3dwYWdl
e31kZWYKfWJpbmQgZGVmCi9QRU5EewpjbGVhcgpjb3VudGRpY3RzdGFjayBDTlQgc3Vie2Vu
ZH1yZXBlYXQKbGV2ZWwxIHJlc3RvcmUKfWJpbmQgZGVmCmVuZCBkZWYKL3NldHBhY2tpbmcg
d2hlcmV7CnBvcApzZXRwYWNraW5nCn1pZgolJUVuZFJlc291cmNlCiUlSW5jbHVkZVJlc291
cmNlOiBmb250IENvdXJpZXItQm9sZAolJUluY2x1ZGVSZXNvdXJjZTogZm9udCBUaW1lcy1C
b2xkCiUlSW5jbHVkZVJlc291cmNlOiBmb250IFRpbWVzLVJvbWFuCiUlSW5jbHVkZVJlc291
cmNlOiBmb250IENvdXJpZXIKZ3JvcHMgYmVnaW4vREVGUyAxIGRpY3QgZGVmIERFRlMgYmVn
aW4vdXsuMDAxIG11bH1iaW5kIGRlZiBlbmQvUkVTIDcyCmRlZi9QTCA3OTIgZGVmL0xTIGZh
bHNlIGRlZi9FTkMwWy9hc2NpaWNpcmN1bS9hc2NpaXRpbGRlL1NjYXJvbi9aY2Fyb24KL3Nj
YXJvbi96Y2Fyb24vWWRpZXJlc2lzL3RyYWRlbWFyay9xdW90ZXNpbmdsZS8ubm90ZGVmLy5u
b3RkZWYvLm5vdGRlZgovLm5vdGRlZi8ubm90ZGVmLy5ub3RkZWYvLm5vdGRlZi8ubm90ZGVm
Ly5ub3RkZWYvLm5vdGRlZi8ubm90ZGVmLy5ub3RkZWYKLy5ub3RkZWYvLm5vdGRlZi8ubm90
ZGVmLy5ub3RkZWYvLm5vdGRlZi8ubm90ZGVmLy5ub3RkZWYvLm5vdGRlZi8ubm90ZGVmCi8u
bm90ZGVmLy5ub3RkZWYvc3BhY2UvZXhjbGFtL3F1b3RlZGJsL251bWJlcnNpZ24vZG9sbGFy
L3BlcmNlbnQKL2FtcGVyc2FuZC9xdW90ZXJpZ2h0L3BhcmVubGVmdC9wYXJlbnJpZ2h0L2Fz
dGVyaXNrL3BsdXMvY29tbWEvaHlwaGVuCi9wZXJpb2Qvc2xhc2gvemVyby9vbmUvdHdvL3Ro
cmVlL2ZvdXIvZml2ZS9zaXgvc2V2ZW4vZWlnaHQvbmluZS9jb2xvbgovc2VtaWNvbG9uL2xl
c3MvZXF1YWwvZ3JlYXRlci9xdWVzdGlvbi9hdC9BL0IvQy9EL0UvRi9HL0gvSS9KL0svTC9N
L04vTwovUC9RL1IvUy9UL1UvVi9XL1gvWS9aL2JyYWNrZXRsZWZ0L2JhY2tzbGFzaC9icmFj
a2V0cmlnaHQvY2lyY3VtZmxleAovdW5kZXJzY29yZS9xdW90ZWxlZnQvYS9iL2MvZC9lL2Yv
Zy9oL2kvai9rL2wvbS9uL28vcC9xL3Ivcy90L3Uvdi93L3gveQovei9icmFjZWxlZnQvYmFy
L2JyYWNlcmlnaHQvdGlsZGUvLm5vdGRlZi9xdW90ZXNpbmdsYmFzZS9ndWlsbGVtb3RsZWZ0
Ci9ndWlsbGVtb3RyaWdodC9idWxsZXQvZmxvcmluL2ZyYWN0aW9uL3BlcnRob3VzYW5kL2Rh
Z2dlci9kYWdnZXJkYmwKL2VuZGFzaC9lbWRhc2gvZmYvZmkvZmwvZmZpL2ZmbC9kb3RsZXNz
aS9kb3RsZXNzai9ncmF2ZS9odW5nYXJ1bWxhdXQKL2RvdGFjY2VudC9icmV2ZS9jYXJvbi9y
aW5nL29nb25lay9xdW90ZWRibGxlZnQvcXVvdGVkYmxyaWdodC9vZS9sc2xhc2gKL3F1b3Rl
ZGJsYmFzZS9PRS9Mc2xhc2gvLm5vdGRlZi9leGNsYW1kb3duL2NlbnQvc3RlcmxpbmcvY3Vy
cmVuY3kveWVuCi9icm9rZW5iYXIvc2VjdGlvbi9kaWVyZXNpcy9jb3B5cmlnaHQvb3JkZmVt
aW5pbmUvZ3VpbHNpbmdsbGVmdAovbG9naWNhbG5vdC9taW51cy9yZWdpc3RlcmVkL21hY3Jv
bi9kZWdyZWUvcGx1c21pbnVzL3R3b3N1cGVyaW9yCi90aHJlZXN1cGVyaW9yL2FjdXRlL211
L3BhcmFncmFwaC9wZXJpb2RjZW50ZXJlZC9jZWRpbGxhL29uZXN1cGVyaW9yCi9vcmRtYXNj
dWxpbmUvZ3VpbHNpbmdscmlnaHQvb25lcXVhcnRlci9vbmVoYWxmL3RocmVlcXVhcnRlcnMK
L3F1ZXN0aW9uZG93bi9BZ3JhdmUvQWFjdXRlL0FjaXJjdW1mbGV4L0F0aWxkZS9BZGllcmVz
aXMvQXJpbmcvQUUKL0NjZWRpbGxhL0VncmF2ZS9FYWN1dGUvRWNpcmN1bWZsZXgvRWRpZXJl
c2lzL0lncmF2ZS9JYWN1dGUvSWNpcmN1bWZsZXgKL0lkaWVyZXNpcy9FdGgvTnRpbGRlL09n
cmF2ZS9PYWN1dGUvT2NpcmN1bWZsZXgvT3RpbGRlL09kaWVyZXNpcwovbXVsdGlwbHkvT3Ns
YXNoL1VncmF2ZS9VYWN1dGUvVWNpcmN1bWZsZXgvVWRpZXJlc2lzL1lhY3V0ZS9UaG9ybgov
Z2VybWFuZGJscy9hZ3JhdmUvYWFjdXRlL2FjaXJjdW1mbGV4L2F0aWxkZS9hZGllcmVzaXMv
YXJpbmcvYWUvY2NlZGlsbGEKL2VncmF2ZS9lYWN1dGUvZWNpcmN1bWZsZXgvZWRpZXJlc2lz
L2lncmF2ZS9pYWN1dGUvaWNpcmN1bWZsZXgvaWRpZXJlc2lzCi9ldGgvbnRpbGRlL29ncmF2
ZS9vYWN1dGUvb2NpcmN1bWZsZXgvb3RpbGRlL29kaWVyZXNpcy9kaXZpZGUvb3NsYXNoCi91
Z3JhdmUvdWFjdXRlL3VjaXJjdW1mbGV4L3VkaWVyZXNpcy95YWN1dGUvdGhvcm4veWRpZXJl
c2lzXWRlZgovQ291cmllckAwIEVOQzAvQ291cmllciBSRS9UaW1lcy1Sb21hbkAwIEVOQzAv
VGltZXMtUm9tYW4gUkUKL1RpbWVzLUJvbGRAMCBFTkMwL1RpbWVzLUJvbGQgUkUvQ291cmll
ci1Cb2xkQDAgRU5DMC9Db3VyaWVyLUJvbGQgUkUKJSVFbmRQcm9sb2cKJSVQYWdlOiAxIDEK
JSVCZWdpblBhZ2VTZXR1cApCUAolJUVuZFBhZ2VTZXR1cAovRjAgMTAvQ291cmllci1Cb2xk
QDAgU0YoSW50ZXJuZXQgRW5naW5lZXJpbmcgVGFzayBGb3JjZSk3MiA4NSBRKFJNVCBXRykK
MjA5Ljk5OSBFIDIwMy45OTkoSU5URVJORVQtRFJBRlQgTS5MdWJ5L0RpZ2l0YWwpNzIgOTgg
UihGb3VudGFpbik2IEUKMTY3Ljk5OShkcmFmdC1pZXRmLXJtdC1iYi1mZWMtMDMucHMgTC5W
aWNpc2Fuby9DaXNjbyk3MiAxMTEgUgooSi5HZW1tZWxsL01pY3Jvc29mdCkzODkuOTk5IDEy
NCBRKEwuUml6em8vQUNJUkkgYW5kIFVuaXYuIFBpc2EpMzM1Ljk5OQoxMzcgUShNLkhhbmRs
ZXkvQUNJUkkpNDEzLjk5OSAxNTAgUShKLiBDcm93Y3JvZnQvVUNMKTQwNy45OTkgMTYzIFEK
KDE5IEp1bHkgMjAwMSk0MzEuOTk5IDE3NiBRKEV4cGlyZXM6IEphbnVhcnkgMjAwMikzNzcu
OTk5IDE4OSBRL0YxIDE0Ci9UaW1lcy1Cb2xkQDAgU0YoUk1UIEJCIEYpMTU5LjE0NCAyMTQg
UShvcndhcmQgRXJyKS0uMzUgRShvciBDb3JyKS0uMjUyCkUoZWN0aW9uIENvZGVzKS0uMjUy
IEUvRjIgMTEvVGltZXMtUm9tYW5AMCBTRihUaGlzIGRvY3VtZW50IGlzIGFuIEludGVyXApu
ZXQtRHJhZnQgYW5kIGlzIGluIGZ1bGwgY29uZm9ybWFuY2Ugd2l0aCBhbGwgcHJvKTcyIDIz
MyBRCih2aXNpb25zIG9mIFNlY3Rpb24gMTAgb2YpLS4xNjUgRShSRkMyMDI2Lik3MiAyNDYg
UQooSW50ZXJuZXQtRHJhZnRzIGFyZSB3KTcyIDI3MiBRCihvcmtpbmcgZG9jdW1lbnRzIG9m
IHRoZSBJbnRlcm5ldCBFbmdpbmVlcmluZyBUKS0uMTEgRShhc2sgRiktLjg4IEUKKG9yY2Ug
XChJRVRGXCksIGl0cyBhcmVhcywpLS4xNjUgRShhbmQgaXRzIHcpNzIgMjg1IFEob3JraW5n
IGdyb3Vwcy4pCi0uMTEgRShOb3RlIHRoYXQgb3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3Ry
aWIpNS41IEUodXRlIHcpLS4yMiBFCihvcmtpbmcgZG9jdW1lbnRzIGFzKS0uMTEgRShJbnRl
cm5ldC1EcmFmdHMuKTcyIDI5OCBRCihJbnRlcm5ldC1EcmFmdHMgYXJlIHYpNzIgMzI0IFEK
KGFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhzIGFuZCBtYXkgYmUgdXBkYXRlZCwg
cmVwbGFjZWQsIG9yKS0uMjc1CkUob2Jzb2xldGVkIGJ5IG90aGVyIGRvY3VtZW50cyBhdCBh
bik3MiAzMzcgUSAyLjc1KHl0KS0uMTY1IEcgMi43NQooaW1lLiBJdCktMi43NSBGKGlzIGlu
YXBwcm9wcmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBhcyByZWZlcmVuY2UpCjIuNzUg
RShtYXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyBhICJ3KTcyIDM1MCBR
CihvcmsgaW4gcHJvZ3Jlc3MiLiktLjExIEUKKFRoZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJu
ZXQtRHJhZnRzIGNhbiBiZSBhY2Nlc3NlZCBhdCBodHRwOi8vd3d3KTcyCjM3NiBRKC5pZXRm
Lm9yKS0uNzE1IEUoZy9pZXRmLzFpZC1hYnN0cmFjdHMudHh0KS0uMTk4IEUgMS43NiAtLjg4
KFRvIHYpCjcyIDQwMiBUKGllKS44OCBFIDIuNzUod3QpLS4yNzUgRyhoZSBsaXN0IEludGVy
bmV0LURyYWZ0IFNoYWRvKS0yLjc1IEUKMi43NSh3RCktLjI3NSBHKGlyZWN0b3JpZXMsIHNl
ZSBodHRwOi8vd3d3KS0yLjc1IEUoLmlldGYub3IpLS43MTUgRQooZy9zaGFkbyktLjE5OCBF
IC0uNzE1KHcuKS0uMjc1IEcoaHRtbC4pLjcxNSBFCihUaGlzIGRvY3VtZW50IGlzIGEgcHJv
ZHVjdCBvZiB0aGUgSUVURiBSTVQgV0cuKTcyIDQyOCBRCihDb21tZW50cyBzaG91bGQgYmUg
YWRkcmVzc2VkIHRvIHRoZSk1LjUgRShhdXRob3JzLCBvciB0aGUgV0cnKTcyIDQ0MSBRCjIu
NzUoc20pLS42MDUgRyhhaWxpbmcgbGlzdCBhdCBybXRAaXNpLmVkdS4pLTIuNzUgRS9GMyAx
MS9UaW1lcy1Cb2xkQDAKU0YoQWJzdHJhY3QpMjY3LjUzNCA0NzMgUSBGMihUaGlzIG1lbW8g
ZGVzY3JpYmVzIHRoZSBhYnN0cmFjdCBwYWNrKTk3CjQ5NS42IFEoZXQgZm9ybWF0cyBhbmQg
SUFOKS0uMTEgRSAyLjc1KEFyKS0uMzg1IEcgLS4xNjUoZWcpLTIuNzUgRwooaXN0cmF0aW9u
IHByb2NlZHVyZXMpLjE2NSBFKGZvciB1c2Ugb2YgRik5NyA1MDguNiBRKG9ydyktLjE2NSBF
CihhcmQgRXJyb3IgQ29ycmVjdGlvbiBcKEZFQ1wpIGNvZGVzIHdpdGhpbiB0aGUgY29udGUp
LS4xMSBFCih4dCBvZiByZWxpYWJsZSBJUCktLjE2NSBFKG11bHRpY2FzdCB0cmFuc3BvcnQu
KTk3IDUyMS42IFEKKFRoaXMgbWVtbyBzaG91bGQgYmUgcmVhZCBpbiBjb25qdW5jdGlvbiB3
aXRoIGFuZCB1c2VzIHRoZSk1LjUgRQoodGVybWlub2xvZ3kgb2YgdGhlIGNvbXBhbmlvbiBt
ZW1vIFsxXSwgd2hpY2ggZGVzY3JpYmVzIHRoZSB1c2Ugb2YgRik5Nwo1MzQuNiBRKG9ydykt
LjE2NSBFKGFyZCBFcnJvciktLjExIEUKKENvcnJlY3Rpb24gXChGRUNcKSBjb2RlcyB3aXRo
aW4gdGhlIGNvbnRlKTk3IDU0Ny42IFEKKHh0IG9mIHJlbGlhYmxlIElQIG11bHRpY2FzdCB0
cmFuc3BvcnQgYW5kKS0uMTY1IEUocHJvKTk3IDU2MC42IFEKKHZpZGVzIGFuIGludHJvZHVj
dGlvbiB0byBzb21lIGNvbW1vbmx5IHVzZWQgRkVDIGNvZGVzLiktLjE2NSBFIEYzKDEuKTcy
CjU5OS42IFEgRjEoRkVDIEFic3RyYWN0IFApNS41IEUoYWNrKS0uMTQgRQooZXQgRmllbGRz
IGFuZCBPdXQtb2YtQmFuZCBJbmYpLS4xNCBFKG9ybWF0aW9uKS0uMzUgRSBGMgooVGhpcyBz
ZWN0aW9uIHNwZWNpXDIxNGVzIHRoZSBpbmZvcm1hdGlvbiB0aGF0IHByb3RvY29sIHBhY2sp
NzIgNjE2LjIgUQooZXRzIG11c3QgY2FycnkgdG8gaW1wbGVtZW50IHRoZSB2KS0uMTEgRShh
cmlvdXMpLS4yNzUgRQooZm9ybXMgb2YgRkVDLWJhc2VkIHJlbGlhYmlsaXR5KTcyIDYyOS4y
IFEgNS41KC5BKS0uNzE1IEcKKHNlc3Npb24gaXMgZGVcMjE0bmVkIHRvIGJlIGFsbCB0aGUg
aW5mb3JtYXRpb24gYXNzb2NpYXRlZCB3aXRoIGEpLTIuNzUKRSh0cmFuc21pc3Npb24gb2Yg
ZGF0YSBhYm91dCBhIHBhcnRpY3VsYXIgb2JqZWN0IGJ5IGEgc2luZ2xlIHNlbmRlcik3Mgo2
NDIuMiBRIDUuNSguVCktLjYwNSBHKGhlcmUgYXJlIHRocmVlIGNsYXNzZXMgb2YpLTUuNSBF
KHBhY2spNzIgNjU1LjIgUQooZXRzIHRoYXQgbWF5IGNvbnRhaW4gRkVDIGluZm9ybWF0aW9u
IHdpdGhpbiBhIHNlc3Npb246IGRhdGEgcGFjayktLjExIEUKKGV0cywgc2Vzc2lvbi1jb250
cm9sIHBhY2spLS4xMSBFKGV0cyktLjExIEUoYW5kIGZlZWRiYWNrIHBhY2spNzIgNjY4LjIK
USAyLjc1KGV0cy4gVGhlKS0uMTEgRiAyLjc1KHlnKS0uMTY1IEcoZW5lcmFsbHkgY29udGFp
biBkaWYpLTIuNzUgRQooZmVyZW50IGtpbmRzIG9mIEZFQyBpbmZvcm1hdGlvbi4pLS4yNzUg
RShOb3RlIHRoYXQpNS41IEUKKHNvbWUgcHJvdG9jb2xzIGRvIG5vdCB1c2UgZmVlZGJhY2sg
cGFjayk3MiA2ODEuMiBRKGV0cy4pLS4xMSBFCihEYXRhIHBhY2spNzIgNzA3LjIgUShldHMg
bWF5IHNvbWV0aW1lIHNlcnYpLS4xMSBFIDIuNzUoZWEpLS4xNjUgRyAyLjc1CihzcyktMi43
NSBHKGVzc2lvbi1jb250cm9sIHBhY2spLTIuNzUgRQooZXRzIGFzIHdlbGw7IGJvdGggZGF0
YSBhbmQgc2Vzc2lvbi0pLS4xMSBFKGNvbnRyb2wgcGFjayk3MiA3MjAuMiBRCihldHMgZ2Vu
ZXJhbGx5IHRyYSktLjExIEUgLS4xNjUodmUpLS4yMiBHIDIuNzUobGQpLjE2NSBHIC0uMjc1
KG93KS0yLjc1CkcobnN0cmVhbSBcKGZyb20gdGhlIHNlbmRlciB0bykuMjc1IEUgLS4xMSh3
YSktLjI3NSBHKHJkcyByZWNlaSkuMTEgRQotLjE2NSh2ZSktLjI3NSBHKHJzXCkgYW5kIGFy
ZSkuMTY1IEUoTHVieS9WKTcyIDc2OSBRCihpY2lzYW5vL0dlbW1lbGwvUml6em8vSGFuZGxl
KS0uNjYgRSh5L0NybyktLjE2NSBFIDExNy4zNTYKKHdjcm9mdCBTZWN0aW9uKS0uMjc1IEYg
Mi43NSgxLiBbUCkyLjc1IEYoYWdlIDFdKS0uMTY1IEUgRVAKJSVQYWdlOiAyIDIKJSVCZWdp
blBhZ2VTZXR1cApCUAolJUVuZFBhZ2VTZXR1cAovRjAgMTEvVGltZXMtUm9tYW5AMCBTRihJ
TlRFUk5FVCk3MiA0OSBRIDcxLjU4NygtRFJBRlQgRXhwaXJlczopLTEuMDEyIEYKKEphbnVh
cnkgMjAwMikyLjc1IEUoSnVseSAyMDAxKTEyMy43MjYgRQooYWRkcmVzc2VkIHRvIGEgbXVs
dGljYXN0IElQIGFkZHJlc3MgXChzb21ldGltZSB0aGUpNzIgODUgUSAyLjc1KHltKQotLjE2
NSBHKGlnaHQgYmUgYWRkcmVzc2VkIHRvIHRoZSB1bmljYXN0IGFkZHJlc3Mgb2YgYSktMi43
NSBFCihzcGVjaVwyMTRjIHJlY2VpKTcyIDk4IFEgLS4xNjUodmUpLS4yNzUgRyhyXCkuIElu
IHRoZSBmb2xsbykuMTY1IEUKKHdpbmcsIGZvciBzaW1wbGljaXR5IHdlIHdpbGwgcmVmZXIg
dG8gYm90aCBkYXRhIGFuZCBzZXNzaW9uIGNvbnRyb2wpCi0uMjc1IEUocGFjayk3MiAxMTEg
UShldHMgYXMgZG8pLS4xMSBFKHduc3RyZWFtLXRyYSktLjI3NSBFIC0uMTY1KHZlKQotLjIy
IEcobGluZyBwYWNrKS4xNjUgRShldHMsIG9yIHNpbXBseSBkbyktLjExIEUod25zdHJlYW0g
cGFjayktLjI3NSBFCihldHMuKS0uMTEgRShBcyBhIGdlbmVyYWwgcnVsZSwgZmVlZGJhY2sg
cGFjayk3MiAxMzcgUShldHMgdHJhKS0uMTEgRQotLjE2NSh2ZSktLjIyIEcgMi43NShsdSku
MTY1IEcocHN0cmVhbSBcKGZyb20gcmVjZWkpLTIuNzUgRSAtLjE2NSh2ZSkKLS4yNzUgRyhy
cyB0byB0aGUgc2VuZGVyXCkgYW5kIGFyZSkuMTY1IEUKKGFkZHJlc3NlZCB0byB0aGUgdW5p
Y2FzdCBhZGRyZXNzIG9mIHRoZSBzZW5kZXIpNzIgMTUwIFEgMi43NSguUyktLjYwNSBHCihv
bWV0aW1lcywgaG8pLTIuNzUgRSh3ZSktLjI3NSBFIC0uMTY1KHZlKS0uMjc1IEcgLjg4IC0u
NDQociwgdCkuMTY1IEgKKGhlKS40NCBFIDIuNzUoeW0pLS4xNjUgRyhpZ2h0IGJlIGFkZHJl
c3NlZCB0byBhKS0yLjc1IEUKKG11bHRpY2FzdCBJUCBhZGRyZXNzIG9yIHRvIHRoZSB1bmlj
YXN0IGFkZHJlc3Mgb2YgYSByZWNlaSk3MiAxNjMgUQotLjE2NSh2ZSktLjI3NSBHIDIuNzUo
cm8pLjE2NSBHIDIuNzUocmEpLTIuNzUgRwoobHNvIHRoZSB0aGUgdW5pY2FzdCBhZGRyZXNz
IG9mIHNvbWUpLTIuNzUgRShkaWYpNzIgMTc2IFEKKGZlcmVudCBub2RlIFwoYW4gaW50ZXJt
ZWRpYXRlIG5vZGUgdGhhdCBwcm8pLS4yNzUgRSh2aWRlcyByZWNvKS0uMTY1IEUKLS4xNjUo
dmUpLS4xNjUgRyhyeSBzZXJ2aWNlcyBvciBhIG5laWdoYm9yaW5nIHJvdXRlclwpLikuMTY1
IEUKKFRoZSBGRUMtcmVsYXRlZCBpbmZvcm1hdGlvbiB0aGF0IGNhbiBiZSBwcmVzZW50IGlu
IGRvKTcyIDIwMiBRCih3bnN0cmVhbSBwYWNrKS0uMjc1IEUoZXRzIGNhbiBiZSBjbGFzc2lc
MjE0ZWQgYXMpLS4xMSBFKGZvbGxvKTcyIDIxNSBRCih3czopLS4yNzUgRSA3LjMzNygxXCkg
RkVDKTc0Ljc1IDI0NC42IFIoRW5jb2RpbmcgSWRlbnRpXDIxNGVyKTIuNzUgRQooSWRlbnRp
XDIxNGVzIHRoZSBGRUMgZW5jb2RpbmcgYmVpbmcgdXNlZCBhbmQgaGFzIHRoZSBwdXJwb3Nl
IG9mIGFsbG8pCjEwNSAyNjEuMiBRKHdpbmcgcmVjZWkpLS4yNzUgRSAtLjE2NSh2ZSktLjI3
NSBHKHJzIHRvIHNlbGVjdCkuMTY1IEUKKHRoZSBhcHByb3ByaWF0ZSBGRUMgZGVjb2Rlcikx
MDUgMjc0LjIgUSAyLjc1KC5BKS0uNjA1IEcgMi43NShzYWcpLTIuNzUKRyhlbmVyYWwgcnVs
ZSwgdGhlICJGRUMgRW5jb2RpbmcgSWRlbnRpXDIxNGVyIiBNVVNUIGJlKS0yLjc1IEUKKHRo
ZSBzYW1lIGZvciBhIGdpKTEwNSAyODcuMiBRIC0uMTY1KHZlKS0uMjc1IEcgMi43NShucyku
MTY1IEcoZXNzaW9uLCBcCmkuZS4sIGZvciBhbGwgdHJhbnNtaXNzaW9uIG9mIGRhdGEgcmVs
YXRlZCB0byBhIHBhcnRpY3VsYXIgb2JqZWN0LCktMi43NQpFIC0uMjIoYnUpMTA1IDMwMC4y
IFMgMi43NSh0TSkuMjIgRyAyLjMxIC0xLjE1NShBWSB2KS0yLjc1IEgKKGFyeSBhY3Jvc3Mg
ZGlmKS44OCBFKGZlcmVudCB0cmFuc21pc3Npb25zIG9mIGRhdGEgYWJvdXQgZGlmKS0uMjc1
IEUKKGZlcmVudCBvYmplY3RzIGluIGRpZiktLjI3NSBFKGZlcmVudCktLjI3NSBFKHNlc3Np
b25zLCBlKTEwNSAzMTMuMiBRCi0uMTY1KHZlKS0uMjc1IEcgMi43NShuaSkuMTY1IEcgMi43
NShmdCktMi43NSBHKHJhbnNtaXR0ZWQgdXNpbmcgdGhlIHNhXAptZSBzZXQgb2YgbXVsdGlj
YXN0IGdyb3VwcyBhbmQvb3IgdXNpbmcgYSBzaW5nbGUpLTIuNzUgRSh1cHBlcikxMDUgMzI2
LjIKUSgtbGF5ZXIgc2Vzc2lvbi4pLS4yMiBFIDcuMzM3KDJcKSBGRUMpNzQuNzUgMzQyLjgg
UihwYXlsb2FkIElEKTIuNzUgRQooSWRlbnRpXDIxNGVzIHRoZSBzeW1ib2xcKHNcKSBpbiB0
aGUgcGF5bG9hZCBvZiB0aGUgcGFjaykxMDUgMzU5LjQgUQooZXQuIFRoZSBjb250ZW50IG9m
IHRoaXMgcGllY2Ugb2YpLS4xMSBFKGluZm9ybWF0aW9uIGRlcGVuZHMgb24gdGhlIGVuY1wK
b2RlciBiZWluZyB1c2VkIFwoZS5nLiBpbiBCbG9jayBGRUMgY29kZXMgdGhpcyBtYXkgYmUg
dGhlKTEwNSAzNzIuNCBRCihjb21iaW5hdGlvbiBvZiBibG9jayBpbmRlKTEwNSAzODUuNCBR
IDIuNzUoeGEpLS4xNjUgRwoobmQgZW5jb2Rpbmcgc3ltYm9sIGlkZW50aVwyMTRlcjsgaW4g
aWRlYWwgZSktMi43NSBFKHhwYW5kYWJsZSBGRUMpLS4xNjUKRShjb2RlcyB0aGlzIG1heSBi
ZSBqdXN0IGEgXDIxNWF0IGVuY29kaW5nIHN5bWJvbCBpZGVudGlcMjE0ZXJcKS4pMTA1CjM5
OC40IFEgNy4zMzcoM1wpIEZFQyk3NC43NSA0MTUgUihPYmplY3QgVCkyLjc1IEUKKHJhbnNt
aXNzaW9uIEluZm9ybWF0aW9uKS0uMzg1IEUoVGhpcyBpcyBpbmZvcm1hdGlvbiByZSkxMDUg
NDMxLjYgUQotLjA1NShnYSktLjE2NSBHCihyZGluZyB0aGUgZW5jb2Rpbmcgb2YgYSBzcGVj
aVwyMTRjIG9iamVjdCBuZWVkZWQgYnkgdGhlIEZFQyBkZWNvZGVyKQouMDU1IEUoXChlLmcu
IGZvciBCbG9jayBGRUMgY29kZXMgdGhpcyBtYXkgYmUgdGhlIGNvbWJpbmF0aW9uIG9mIGJs
b2NrIFwKbGVuZ3RoIGFuZCBvYmplY3QgbGVuZ3RoXCkuKTEwNSA0NDQuNiBRCihUaGlzIG1p
Z2h0IGFsc28gaW5jbHVkZSBnZW5lcmFsIHBhcmFtZXRlcnMgb2YgdGhlIEZFQyBlbmNvZGVy
KTEwNSA0NTcuNgpRIDIuNzUoLk4pLS42MDUgRyhvdGUgdGhhdCwgaW4gc3RyaWN0IHRlcm1z
LCktMi43NSBFKHRoZSAiRkVDIEVuY29kaW5nIFwKSWRlbnRpXDIxNGVyIiBiZWxvbmdzIHRv
IHRoaXMgY2xhc3Mgb2YgaW5mb3JtYXRpb24sIGhvKTEwNSA0NzAuNiBRKHdlKQotLjI3NSBF
IC0uMTY1KHZlKS0uMjc1IEcgLjg4IC0uNDQociwgZikuMTY1IEgob3IgcHJhY3RpY2FsKS40
NCBFCihwdXJwb3Nlcywgd2Ugd2lsbCBjb25zaWRlciBpdCBzZXBhcmF0ZWx5KTEwNSA0ODMu
NiBRKC4pLS43MTUgRQooQWxsIHRoZSBjbGFzc2VzIG9mIGluZm9ybWF0aW9uIGFibyk5NyA1
MTMuMiBRIC0uMTY1KHZlKS0uMTY1IEcgMi43NSgsZSkKLjE2NSBHKHhjZXB0IDJcKSwgY2Fu
IGVpdGhlciBiZSB0cmFuc21pdHRlZCB3aXRoaW4gdGhlKS0yLjkxNSBFCih0cmFuc3BvcnQg
c2Vzc2lvbiBcKHVzaW5nIHByb3RvY29sIHBhY2spNzIgNTI2LjIgUQooZXQtaGVhZGVyIFwy
MTRlbGRzXCkgb3Igb3V0IG9mIGJhbmQuIFRoZSBpbmZvcm1hdGlvbiBkZXNjcmliZWQpLS4x
MSBFCihpbiAyXCkgTVVTVCBiZSB0cmFuc21pdHRlZCBpbiBkYXRhLXBhY2spNzIgNTM5LjIg
UQooZXQgaGVhZGVyIFwyMTRlbGRzLCBhcyBpdCBwcm8pLS4xMSBFKHZpZGVzIGEgZGVzY3Jp
cHRpb24gb2YgdGhlIGRhdGEpCi0uMTY1IEUoY29udGFpbmVkIGluIHRoZSBwYWNrKTcyIDU1
Mi4yIFEoZXQuIEluIHRoZSBmb2xsbyktLjExIEUKKHdpbmcgd2Ugd2lsbCBzcGVjaWZ5IHRo
ZSBjb250ZW50IG9mIDFcKSwgMlwpIGFuZCAzXCkgcmUpLS4yNzUgRSAtLjA1NQooZ2EpLS4x
NjUgRyhyZGxlc3Mgb2YpLjA1NSBFCih3aGV0aGVyIHRoZXNlIHBpZWNlcyBvZiBpbmZvcm1h
dGlvbiBhcmUgdHJhbnNtaXR0ZWQgaW4gcHJvdG9jb2wgcGFjayk3Mgo1NjUuMiBRKGV0cyBv
ciBvdXQgb2YgYmFuZC4gVGhpcyktLjExIEUoZG9jdW1lbnQgbmVpdGhlciBzcGVjaVwyMTRl
cyBvdVwKdC1vZi1iYW5kIG1ldGhvZHMgdG8gdHJhbnNwb3J0IHRoZSBpbmZvcm1hdGlvbiBu
b3IgZG9lcyBpdCBzcGVjaWZ5KTcyCjU3OC4yIFEodGhlIHcpNzIgNTkxLjIgUQooYXkgb3V0
LW9mLWJhbmQgaW5mb3JtYXRpb24gaXMgYXNzb2NpYXRlZCB3aXRoIHBhY2spLS4xMSBFCihl
dCBwYXlsb2Fkcy4gVGhpcyBsYXN0IHRhc2sgaXMgZGUpLS4xMSBFIC0uMjIodm8pLS4yNzUg
RyhsdikuMjIgRQooZWQgdG8pLS4xNjUgRShhbiB1cHBlcik3MiA2MDQuMiBRKC1sYXllciBw
cm90b2NvbC4pLS4yMiBFIC0uNDQoV2kpNzIKNjMwLjIgUyh0aGluIHRoZSBjb250ZSkuNDQg
RSh4dCBvZiBGRUMgcmVwYWlyIHNjaGVtZXMsIGZlZWRiYWNrIHBhY2spCi0uMTY1IEUoZXRz
IGFyZSBcKG9wdGlvbmFsbHlcKSB1c2VkIHRvIHJlcXVlc3QgRkVDKS0uMTEgRSAyLjc1Cihy
ZXRyYW5zbWlzc2lvbi4gVGhlKTcyIDY0My4yIFIKKEZFQy1yZWxhdGVkIGluZm9ybWF0aW9u
IHByZXNlbnQgaW4gZmVlZGJhY2sgcGFjaykyLjc1IEUKKGV0cyB1c3VhbGx5IGNvbnRhaW5z
IGFuKS0uMTEgRShGRUMgQmxvY2sgSWRlbnRpXDIxNGVyKTcyIDY1Ni4yIFEgMi43NQooLHQp
LS40NCBHKGhhdCBkZVwyMTRuZXMgdGhlIGJsb2NrIHRoYXQgaXMgYmVpbmcgcmVwYWlyZWQs
IGFuZCB0aGUgbnVtYlwKZXIgb2YgUmVwYWlyKS0yLjc1IEUKKFN5bWJvbHMgcmVxdWVzdGVk
LiBBbHRob3VnaCB0aGlzIGlzIHRoZSBtb3N0IGNvbW1vbiBjYXNlLCB2KTcyIDY2OS4yIFEK
KGFyaWFudHMgYXJlIHBvc3NpYmxlIGluIHdoaWNoIHRoZSktLjI3NSBFKHJlY2VpKTcyIDY4
Mi4yIFEgLS4xNjUodmUpCi0uMjc1IEcocnMgcHJvKS4xNjUgRSh2aWRlIG1vcmUgc3BlY2lc
MjE0YyBpbmZvcm1hdGlvbiBhYm91dCB0aGUgUmVwYWlyXAogU3ltYm9scyByZXF1ZXN0ZWQg
XChlLmcuIGFuIGluZGUpLS4xNjUgRSh4KS0uMTY1IEUocmFuZ2Ugb3IgYSBsaXN0IG9mIFwK
c3ltYm9scyBhY2NlcHRlZFwpLiBJdCBpcyBhbHNvIHBvc3NpYmxlIHRvIGluY2x1ZGUgbXVs
dGlwbGUgb2YgdGhlc2UgcmVcCnF1ZXN0IGluIGEpNzIgNjk1LjIgUShzaW5nbGUgZmVlZGJh
Y2sgcGFjayk3MiA3MDguMiBRKGV0LiktLjExIEUoTHVieS9WKQo3MiA3NjkgUShpY2lzYW5v
L0dlbW1lbGwvUml6em8vSGFuZGxlKS0uNjYgRSh5L0NybyktLjE2NSBFIDExNy4zNTYKKHdj
cm9mdCBTZWN0aW9uKS0uMjc1IEYgMi43NSgxLiBbUCkyLjc1IEYoYWdlIDJdKS0uMTY1IEUg
RVAKJSVQYWdlOiAzIDMKJSVCZWdpblBhZ2VTZXR1cApCUAolJUVuZFBhZ2VTZXR1cAovRjAg
MTEvVGltZXMtUm9tYW5AMCBTRihJTlRFUk5FVCk3MiA0OSBRIDcxLjU4NygtRFJBRlQgRXhw
aXJlczopLTEuMDEyIEYKKEphbnVhcnkgMjAwMikyLjc1IEUoSnVseSAyMDAxKTEyMy43MjYg
RShUaGlzIGRvY3VtZW50IGRvZXMgbm90IHBybyk3Mgo4NSBRKHZpZGUgYW4pLS4xNjUgRSAy
Ljc1KHlkKS0uMTY1IEcKKGV0YWlsIGFib3V0IHRoZSBmb3JtYXQgb2YgRkVDIGluZm9ybWF0
aW9uIGluIGZlZWRiYWNrKS0yLjc1IEUocGFjayk3Mgo5OCBRKGV0cy4pLS4xMSBFL0YxIDEx
L1RpbWVzLUJvbGRAMCBTRigxLjEuKTcyIDEzNyBRL0YyIDEzL1RpbWVzLUJvbGRAMApTRihG
RUMgRW5jb2RpbmcgSWRlbnRpXDIxNGVyKTUuNSBFIEYwKFRoaXMgaXMgYSBudW1lcmljIGlu
ZGUpNzIgMTY2LjYgUQoyLjc1KHh0KS0uMTY1IEcoaGF0IGlkZW50aVwyMTRlcyBhIHNwZWNp
XDIxNGMgRkVDIHNjaGVtZSBPUiBhIGNsYXNzIG9mIFwKZW5jb2Rpbmcgc2NoZW1lcyktMi43
NSBFKHRoYXQgc2hhcmUgdGhlIHNhbWUgZm9ybWF0IG9mICJGRUMgUCk3MiAxNzkuNiBRCihh
eWxvYWQgSUQiIGFuZCAiRkVDIE9iamVjdCBUKS0uMTY1IEUocmFuc21pc3Npb24gSW5mb3Jt
YXRpb24iLiktLjM4NSBFCihUaGUgRkVDIEVuY29kaW5nIElkZW50aVwyMTRlciBpZGVudGlc
MjE0ZXMgYSBzcGVjaVwyMTRjIEZFQyBzY2hlbWUgd2hlXApuIHRoZSBlbmNvZGluZyBzY2hl
bWUgaXMpNzIgMjA1LjYgUQooZm9ybWFsbHkgYW5kIGZ1bGx5IHNwZWNpXDIxNGVkLCBpbiBh
IHcpNzIgMjE4LjYgUQooYXkgdGhhdCBpbmRlcGVuZGVudCBpbXBsZW1lbnRvcnMgY2FuIGlt
cGxlbWVudCBib3RoIGVuY29kZXIpLS4xMSBFKGFuZFwKIGRlY29kZXIgZnJvbSB0aGUgc3Bl
Y2lcMjE0Y2F0aW9uLiBDb21wYW5pb24gZG9jdW1lbnRzIG9mIHRoaXMgc3BlY2lcClwyMTRj
YXRpb24gbWF5IHNwZWNpZnkgc3VjaCk3MiAyMzEuNiBRCihGRUMgc2NoZW1lcyBhbmQgYXNz
b2NpYXRlIHRoZW0gd2l0aCAiRkVDIEVuY29kaW5nIElkZW50aVwyMTRlciIgdik3MgoyNDQu
NiBRKGFsdWVzLiBUaGVzZSBkb2N1bWVudHMpLS4yNzUgRQooTVVTVCBhbHNvIHNwZWNpZnkg
YSBjb3JyZXNwb25kZW50IGZvcm1hdCBmb3IgdGhlICJGRUMgUCk3MiAyNTcuNiBRCihheWxv
YWQgSUQiIGFuZCAiRkVDIE9iamVjdCktLjE2NSBFIC0uMzg1KFRyKTcyIDI3MC42IFMKKGFu
c21pc3Npb24gSW5mb3JtYXRpb24iLikuMzg1IEUKKEN1cnJlbnRseSBGRUMgRW5jb2Rpbmcg
SWRlbnRpXDIxNGVycyBpbiB0aGUgcmFuZ2UgMC0xMjcgYXJlIHJlc2Vydik1LjUKRShlZCkt
LjE2NSBFCihmb3IgdGhpcyBjbGFzcyBvZiBlbmNvZGluZyBzY2hlbWVzIFwoZnVsbHktc3Bl
Y2lcMjE0ZWQgc2NoZW1lc1wpLik3MgoyODMuNiBRKEl0IGlzIHBvc3NpYmxlIHRoYXQgYSBG
RUMgc2NoZW1lIGNhbm5vdCBiZSBjb21wbGV0ZWx5IHNwZWNpXDIxNFwKZWQgb3IgdGhhdCBz
dWNoIGEgc3BlY2lcMjE0Y2F0aW9uIGlzKTcyIDMwOS42IFEoc2ltcGx5IG5vdCBhKTcyIDMy
Mi42IFEKLS4yNzUodmEpLS4yMiBHKGlsYWJsZSBvciBhbHNvIHRoYXQgYSBwYXJ0eSBlKS4y
NzUgRSh4aXN0cyB0aGF0IG8pLS4xNjUKRSh3bnMgdGhlIGVuY29kaW5nIHNjaGVtZSBhbmQg
aXQgaXMgbm90IHdpbGxpbmcpLS4yNzUgRQoodG8gZGlzY2xvc2UgaXRzIGFsZ29yaXRobS4g
Vyk3MiAzMzUuNiBRIDIuNzUoZXIpLS44OCBHCihlZmVyIHRvIHRoZXNlIGVuY29kaW5nIHNj
aGVtZXMgYXMgIlVuZGVyKS0yLjc1IEUKKC1TcGVjaVwyMTRlZCIgc2NoZW1lcy4pLS4yMiBF
KFVuZGVyKTcyIDM0OC42IFEKKC1zcGVjaVwyMTRlZCBzY2hlbWVzIGNhbiBzdGlsbCBiZSBp
ZGVudGlcMjE0ZWQgYXMgZm9sbG8pLS4yMiBFKHdzOikKLS4yNzUgRSAxMShvQSk3Ny41IDM2
NS4yIFMoZm9ybWF0IG9mIHRoZSBcMjE0ZWxkcyAiRkVDIFApLTguMjUgRQooYXlsb2FkIElE
IiBhbmQgIkZFQyBPYmplY3QgVCktLjE2NSBFKHJhbnNtaXNzaW9uIEluZm9ybWF0aW9uIikt
LjM4NSBFCihNVVNUIGJlIGRlXDIxNG5lZCBmb3IgdGhlIGVuY29kaW5nIHNjaGVtZS4pOTQg
Mzc4LjIgUSAxMShvQSk3Ny41IDM5NC44ClMgLS4yNzUodmEpLTguMjUgRyhsdWUgb2YgIkZF
QyBFbmNvZGluZyBJZGVudGlcMjE0ZXIiIE1VU1QgYmUgcmVzZXJ2KQouMjc1IEUoZWQgYW5k
IGFzc29jaWF0ZWQgdG8gdGhlIGZvcm1hdCktLjE2NSBFKGRlXDIxNG5pdGlvbnMgYWJvKTk0
CjQwNy44IFEgLS4xNjUodmUpLS4xNjUgRyAyLjc1KC5BKS4xNjUgRyAyLjc1KG5hKS0yLjc1
IEcobHJlYWR5IHJlc2VydikKLTIuNzUgRShlZCAiRkVDIEVuY29kaW5nIElkZW50aVwyMTRl
ciIpLS4xNjUgRShNVVNUIGJlIHJldXNlZCBpZiBpdCBpcykKNS41IEUoYXNzb2NpYXRlZCB0
byB0aGUgc2FtZSBmb3JtYXQgb2YgIkZFQyBQKTk0IDQyMC44IFEKKGF5bG9hZCBJRCIgYW5k
ICJGRUMgT2JqZWN0IFQpLS4xNjUgRShyYW5zbWlzc2lvbiktLjM4NSBFCihJbmZvcm1hdGlv
biIgYXMgdGhlIG9uZXMgbmVlZGVkIGZvciB0aGUgbmUpOTQgNDMzLjggUSAyLjc1KHd1KS0u
Mjc1IEcKKG5kZXIpLTIuNzUgRSgtc3BlY2lcMjE0ZWQgRkVDIHNjaGVtZS4pLS4yMiBFIDEx
KG9BKTc3LjUgNDUwLjQgUyAtLjI3NQoodmEpLTguMjUgRyhsdWUgb2YgIkZFQyBFbmNvZGlu
ZyBOYW1lIiBtdXN0IGJlIHJlc2VydikuMjc1IEUKKGVkIFwoc2VlIGJlbG8pLS4xNjUgRSh3
XCkuKS0uMjc1IEUoQW4gVW5kZXIpNzIgNDgwIFEoLXNwZWNpXDIxNGVkIEZFQyBcCnNjaGVt
ZSBpcyBjb21wbGV0ZWx5IGlkZW50aVwyMTRlZCBieSB0aGUgdHVwbGUgXChGRUMgRW5jb2Rp
bmcgSWRlbnRpXApcMjE0ZXIpLS4yMiBFKCwpLS40NCBFKEZFQyBFbmNvZGluZyBOYW1lXCku
IFRoZSB0dXBsZSBNVVNUIGlkZW50aWZ5IGEgc1wKaW5nbGUgc2NoZW1lIHRoYXQgaGFzIGF0
IGxlYXN0IG9uZSk3MiA0OTMgUQooaW1wbGVtZW50YXRpb24uIFRoZSBwYXJ0eSB0aGF0IG8p
NzIgNTA2IFEKKHducyB0aGlzIHR1cGxlIE1VU1QgYmUgYWJsZSB0byBwcm8pLS4yNzUgRSh2
aWRlIGluZm9ybWF0aW9uIG9uIGhvKS0uMTY1CkUgMi43NSh3dCktLjI3NSBHKG8pLTIuNzUg
RShvYnRhaW4gdGhlIHVuZGVyKTcyIDUxOSBRKC1zcGVjaVwyMTRlZCBGRUMgXApzY2hlbWUg
aWRlbnRpXDIxNGVkIGJ5IHRoZSB0dXBsZSBcKGUuZy4gYSBwb2ludGVyIHRvIGEgcHVibGlj
bHkpLS4yMiBFCi0uMjIoYXYpNzIgNTMyIFMKKGFpbGFibGUgcmVmZXJlbmNlLWltcGxlbWVu
dGF0aW9uIG9yIHRoZSBuYW1lIGFuZCBjb250YWN0cyBvZiBhIGNvbXBhbikKLS4wNTUgRSAy
Ljc1KHl0KS0uMTY1IEcoaGF0IHNlbGxzIGl0LCBlaXRoZXIpLTIuNzUgRQooc2VwYXJhdGVs
eSBvciBlbWJlZGRlZCBpbiBhbm90aGVyIHByb2R1Y3RcKS4pNzIgNTQ1IFEoIkZFQyBFbmNv
ZGluZyBOYVwKbWVzIiBhcmUgbnVtZXJpYyBpZGVudGlcMjE0ZXJzIHNjb3BlZCBieSBhIEZF
QyBFbmNvZGluZyBJZGVudGlcMjE0ZXIpNzIKNTcxIFEoLiktLjYwNSBFKFRoZSBGRUMgRW5j
b2RpbmcgTmFtZSBNVVNUIGJlIHBhcnQgb2YgdGhlICJGRUMgT2JqZWN0IFQpCjcyIDU5NyBR
KHJhbnNtaXNzaW9uIEluZm9ybWF0aW9uIiBhbmQpLS4zODUgRQoobXVzdCBiZSBjb21tdW5p
Y2F0ZWQgdG8gcmVjZWkpNzIgNjEwIFEgLS4xNjUodmUpLS4yNzUgRwoocnMgdG9nZXRoZXIg
d2l0aCB0aGUgRkVDIEVuY29kaW5nIElkZW50aVwyMTRlcikuMTY1IEUoLiktLjYwNSBFKERp
Zik3Mgo2MzYgUQooZmVyZW50IEZFQyBzY2hlbWVzIHRoYXQgc2hhcmUgdGhlIHNhbWUgRkVD
IEVuY29kaW5nIElkZW50aVwyMTRlciAtLSBiKQotLjI3NSBFKHV0IGhhKS0uMjIgRSAuMzMg
LS4xNjUodmUgZCktLjIyIEgoaWYpLjE2NSBFKGZlcmVudCBGRUMpLS4yNzUgRQooRW5jb2Rp
bmcgTmFtZXMgLS0gYWxzbyBzaGFyZSB0aGUgc2FtZSBmb3JtYXQgb2YgRkVDIFApNzIgNjQ5
IFEKKGF5bG9hZCBJRCBhbmQgRkVDIE9iamVjdCBUKS0uMTY1IEUocmFuc21pc3Npb24pLS4z
ODUgRShJbmZvcm1hdGlvbi4pNzIKNjYyIFEoVGhpcyBzcGVjaVwyMTRjYXRpb24gcmVzZXJ2
KTcyIDY4OCBRCihlcyB0aGUgcmFuZ2UgMC0xMjcgb2YgRkVDIEVuY29kaW5nIElkZW50aVwy
MTRlcnMgZm9yIGZ1bGx5LXNwZWNpXDIxNGVkKQotLjE2NSBFKGVuY29kaW5nIHNjaGVtZXMg
YW5kIHRoZSByYW5nZSAxMjgtMjU1IGZvciB1bmRlcik3MiA3MDEgUQooLXNwZWNpXDIxNGVk
IGVuY29kaW5nIHNjaGVtZXMuKS0uMjIgRShMdWJ5L1YpNzIgNzY5IFEKKGljaXNhbm8vR2Vt
bWVsbC9SaXp6by9IYW5kbGUpLS42NiBFKHkvQ3JvKS0uMTY1IEUgMTA5LjEwNgood2Nyb2Z0
IFNlY3Rpb24pLS4yNzUgRiAyLjc1KDEuMS4gW1ApMi43NSBGKGFnZSAzXSktLjE2NSBFIEVQ
CiUlUGFnZTogNCA0CiUlQmVnaW5QYWdlU2V0dXAKQlAKJSVFbmRQYWdlU2V0dXAKL0YwIDEx
L1RpbWVzLVJvbWFuQDAgU0YoSU5URVJORVQpNzIgNDkgUSA3MS41ODcoLURSQUZUIEV4cGly
ZXM6KS0xLjAxMiBGCihKYW51YXJ5IDIwMDIpMi43NSBFKEp1bHkgMjAwMSkxMjMuNzI2IEUv
RjEgMTEvVGltZXMtQm9sZEAwIFNGKDEuMi4pNzIKODUgUS9GMiAxMy9UaW1lcy1Cb2xkQDAg
U0YoRkVDIFApNS41IEUoYXlsb2FkIElEIGFuZCBGRUMgT2JqZWN0IFQpLS4xMyBFCihyYW5z
bWlzc2lvbiBJbmYpLS45NjIgRShvcm1hdGlvbiktLjMyNSBFIEYwIDIuNzUoQWQpOTcgMTE0
LjYgUwoob2N1bWVudCB0aGF0IHNwZWNpXDIxNGVzIGFuIGVuY29kaW5nIHNjaGVtZSBhbmQg
cmVzZXJ2KS0yLjc1IEUoZXMgYSB2KQotLjE2NSBFKGFsdWUgb2YgRkVDIEVuY29kaW5nKS0u
Mjc1IEUoSWRlbnRpXDIxNGVyIE1VU1QgZGVcMjE0bmUgYSBwYWNrKQo3MiAxMjcuNiBRKGV0
LVwyMTRlbGQgZm9ybWF0IGZvciBGRUMgUCktLjExIEUKKGF5bG9hZCBJRCBhbmQgRkVDIE9i
amVjdCBUKS0uMTY1IEUocmFuc21pc3Npb24pLS4zODUgRShJbmZvcm1hdGlvbiBhY2NcCm9y
ZGluZyB0byB0aGUgbmVlZCBvZiB0aGUgZW5jb2Rpbmcgc2NoZW1lLiBUaGlzIGFsc28gYXBw
bGllcyB0byBkb2N1bWVuXAp0cyB0aGF0KTcyIDE0MC42IFEocmVzZXJ2KTcyIDE1My42IFEo
ZXMgdiktLjE2NSBFCihhbHVlcyBvZiBGRUMgRW5jb2RpbmcgSWRlbnRpXDIxNGVycyBmb3Ig
dW5kZXIpLS4yNzUgRQooLXNwZWNpXDIxNGVkIGVuY29kaW5nIHNjaGVtZXMuIEluIHRoaXMg
Y2FzZSktLjIyIEUodGhlIEZFQyBPYmplY3QgVCk3MgoxNjYuNiBRKHJhbnNtaXNzaW9uIElu
Zm9ybWF0aW9uIG11c3QgYWxzbyBpbmNsdWRlIGEgXDIxNGVsZCB0byBjb250YWluIFwKdGhl
ICJGRUMgRW5jb2RpbmcpLS4zODUgRShOYW1lIi4pNzIgMTc5LjYgUSAyLjc1KEFwKTcyIDIw
NS42IFMoYWNrKS0yLjc1CkUoZXQgXDIxNGVsZCBkZVwyMTRuaXRpb24gb2YgRkVDIE9iamVj
dCBUKS0uMTEgRQoocmFuc21pc3Npb24gSW5mb3JtYXRpb24gTVVTVCBiZSBwcm8pLS4zODUg
RSh2aWRlZCBkZXNwaXRlIHRoZSktLjE2NSBFCi0uMTEoZmEpNzIgMjE4LjYgUyhjdCB0aGF0
IGEgcHJvdG9jb2wgaW5zdGFudGlhdGlvbiBtYXkgZGVjaWRlIHRvIGNvbW11XApuaWNhdGUg
dGhpcyBpbmZvcm1hdGlvbiBvdXQgb2YgYmFuZC4pLjExIEUoQWxsIHBhY2spNzIgMjQ0LjYg
UQooZXQgXDIxNGVsZCBkZVwyMTRuaXRpb25zIFwoRkVDIFApLS4xMSBFKGF5bG9hZCBJRCBh
bmQgRkVDIE9iamVjdCBUKQotLjE2NSBFKHJhbnNtaXNzaW9uIEluZm9ybWF0aW9uXCkgTVVT
VCktLjM4NSBFCihiZSBmdWxseSBzcGVjaVwyMTRlZCBhdCB0aGUgbGUpNzIgMjU3LjYgUSAt
LjE2NSh2ZSktLjI3NSBHIDIuNzUobG8pLjE2NQpHIDIuNzUoZmIpLTIuNzUgRyhpdC1cMjE0
ZWxkcyBhbmQgdGhlKS0yLjc1IEUgMi43NSh5bSktLjE2NSBHKHVzdCBoYSkKLTIuNzUgRSAu
MzMgLS4xNjUodmUgYSBsKS0uMjIgSChlbmd0aCB0aGF0IGlzIGEgbXVsdGlwbGUgb2YgYSku
MTY1IEUKKDQtYnl0ZSB3KTcyIDI3MC42IFEob3JkIFwodGhpcyBpcyB0byBmKS0uMTEgRQoo
YWNpbGl0YXRlIHRoZSBhbGlnbm1lbnQgb2YgcGFjayktLjExIEUKKGV0IFwyMTRlbGRzIGlu
IHByb3RvY29sIGluc3RhbnRpYXRpb25zXCkuKS0uMTEgRQooTm90ZSB0aGF0IHRoZSBzcGVj
aVwyMTRjYXRpb24gb2YgRkVDIFApNzIgMjk2LjYgUShheWxvYWQgSUQgTVVTVCBhbGxvKQot
LjE2NSBFIDIuNzUod2EpLS4yNzUgRyAyLjc1KG5pKS0yLjc1IEcobXBsZW1lbnRhdGlvbi1p
bmRlcGVuZGVudCktMi43NQpFKGlkZW50aVwyMTRjYXRpb24gb2YgdGhlIHBhY2spNzIgMzA5
LjYgUShldCBwYXlsb2FkIGUpLS4xMSBFIC0uMTY1KHZlKQotLjI3NSBHIDIuNzUobmkpLjE2
NSBHIDIuNzUobnQpLTIuNzUgRyhoZSBjYXNlIG9mIFVuZGVyKS0yLjc1IEUKKC1TcGVjaVwy
MTRlZCBlbmNvZGluZyBzY2hlbWVzLiktLjIyIEUgRjEoMi4pNzIgMzQ4LjYgUS9GMyAxNAov
VGltZXMtQm9sZEAwIFNGKFByKTUuNSBFKGVhc3NpZ25lZCBGRUMgRW5jb2RpbmcgSWRlbnRp
XDIxNGVycyktLjI1MiBFCkYwCihUaGlzIHNlY3Rpb24gc3BlY2lcMjE0ZXMgdGhlIEZFQyBF
bmNvZGluZyBJZGVudGlcMjE0ZXIgYW5kIHRoZSByZWxhdGkpCjcyIDM2NS4yIFEgLjMzIC0u
MTY1KHZlIHApLS4yNzUgSChhY2spLjE2NSBFCihldHMgXDIxNGVsZCBmb3IgYSBudW1iZXIg
b2YpLS4xMSBFKGtubyk3MiAzNzguMiBRCih3biBzY2hlbWVzIHRoYXQgZm9sbG8pLS4yNzUg
RSAyLjc1KHd1KS0uMjc1IEcobmRlciB0aGUgY2xhc3Mgb2YgdW5kZXIpCi0yLjc1IEUoLXNw
ZWNpXDIxNGVkIEZFQyBzY2hlbWVzLiBPdGhlcnMgbWF5IGJlKS0uMjIgRQooc3BlY2lcMjE0
ZWQgaW4gY29tcGFuaW9uIGRvY3VtZW50cy4pNzIgMzkxLjIgUSBGMSgyLjEuKTcyIDQzMC4y
IFEgRjIKKFNtYWxsIEJsb2NrLCBMYXIpNS41IEUoZ2UgQmxvY2sgYW5kIEV4cGFuZGFibGUg
RkVDIENvZGVzKS0uMTMgRSBGMAooVGhpcyBzZWN0aW9uIHJlc2Vydik3MiA0NDYuOCBRCihl
cyBhIEZFQyBFbmNvZGluZyBJZGVudGlcMjE0ZXIgZm9yIHRoZSBmKS0uMTY1IEUKKGFtaWxp
ZXMgb2YgY29kZXMgZGVzY3JpYmVkIGluIFsxXSwgYW5kKS0uMTEgRShzcGVjaVwyMTRlcyB0
aGUgcmVsYXRpKTcyCjQ1OS44IFEgLjMzIC0uMTY1KHZlIHApLS4yNzUgSChhY2spLjE2NSBF
KGV0IFwyMTRlbGRzLiktLjExIEUoVW5kZXIpNS41CkUoLXNwZWNpXDIxNGVkIEZFQyBzY2hl
bWVzIHRoYXQgYmVsb25nIHRvIHRoaXMgY2xhc3MgTVVTVCktLjIyIEUKKHVzZSB0aGlzIGlk
ZW50aVwyMTRlciBhbmQgcGFjayk3MiA0NzIuOCBRKGV0IFwyMTRlbGQgZGVcMjE0bml0aW9u
cy4pCi0uMTEgRShUaGUgRkVDIEVuY29kaW5nIElkZW50aVwyMTRlciBmb3IgdW5kZXIgc3Bl
Y2lcMjE0ZWQgY29kZXMgYXNzaWduXAplZCB0byBTbWFsbCBCbG9jaywgTGFyKTcyIDQ5OC44
IFEoZ2UgQmxvY2ssIGFuZCktLjE5OCBFCihFeHBhbmRhYmxlIEZFQyBDb2RlcyBpcyAxMjgu
KTcyIDUxMS44IFEoVGhlIEZFQyBQKTcyIDUzNy44IFEoYXlsb2FkIElEXAogaXMgY29tcG9z
ZWQgb2YgYW4gZW5jb2Rpbmcgc3ltYm9sIGlkZW50aVwyMTRlciBhbmQgYW4gZW5jb2Rpbmcg
YmxvY2spCi0uMTY1IEUobnVtYmVyIHN0cnVjdHVyZWQgYXMgZm9sbG8pNzIgNTUwLjggUSh3
czopLS4yNzUgRS9GNCA4L0NvdXJpZXJAMApTRiA5MS4yKDAxMjMpNzYuOCA1ODkuOCBTIDQu
OCgwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMSk3Ni44CjYwMi44IFMKKCstKy0r
LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r
LSstKy0rKTcyCjYxNS44IFEgMTAwLjgofGUpNzIgNjI4LjggUyhuY29kaW5nIGJsb2NrIG51
bWJlciktMTAwLjggRSh8KTEwMC44IEUKKCstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r
LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rKTcyCjY0MS44IFEgMTA1LjYo
fGUpNzIgNjU0LjggUyhuY29kaW5nIHN5bWJvbCBJRCktMTA1LjYgRSh8KTExMC40IEUKKCst
Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst
Ky0rLSstKy0rKTcyCjY2Ny44IFEvRjUgMTAvVGltZXMtUm9tYW5AMCBTRgooSW4gYWRkaXRp
b24sIGEgb25lIGJpdCBGRUMgRW5jb2RpbmcgRmxhZyBNQSk3MiA3MDYuOCBRIDIuNShZYikt
MS4wNSBHCjIuNShlaSktMi41IEcobmNsdWRlZCwgYW5kIHRoaXMgXDIxNWFnIGluZGljYXRl
cyB3aGV0aGVyIHRoZSBlbmNvZGluZykKLTIuNSBFKHN5bWJvbFwoc1wpIGluIHRoZSBwYXls
b2FkIG9mIHRoZSBwYWNrKTcyIDcxOS44IFEKKGV0IGFyZSBzb3VyY2Ugc3ltYm9sXChzXCkg
b3IgcmVkdW5kYW50IHN5bWJvbFwoc1wpLiktLjEgRSBGMChMdWJ5L1YpNzIKNzY5IFEoaWNp
c2Fuby9HZW1tZWxsL1JpenpvL0hhbmRsZSktLjY2IEUoeS9Dcm8pLS4xNjUgRSAxMDkuMTA2
Cih3Y3JvZnQgU2VjdGlvbiktLjI3NSBGIDIuNzUoMi4xLiBbUCkyLjc1IEYoYWdlIDRdKS0u
MTY1IEUgRVAKJSVQYWdlOiA1IDUKJSVCZWdpblBhZ2VTZXR1cApCUAolJUVuZFBhZ2VTZXR1
cAovRjAgMTEvVGltZXMtUm9tYW5AMCBTRihJTlRFUk5FVCk3MiA0OSBRIDcxLjU4NygtRFJB
RlQgRXhwaXJlczopLTEuMDEyIEYKKEphbnVhcnkgMjAwMikyLjc1IEUoSnVseSAyMDAxKTEy
My43MjYgRS9GMSAxMC9UaW1lcy1Sb21hbkAwIFNGCihUaGUgRkVDIE9iamVjdCBUKTcyIDg1
IFEocmFuc21pc3Npb24gSW5mb3JtYXRpb24gaGFzIHRoZSBmb2xsbyktLjM1IEUKKHdpbmcg
c3RydWN0dXJlOiktLjI1IEUvRjIgOC9Db3VyaWVyQDAgU0YgOTEuMigwMTIzKTc2LjggMTI0
IFMgNC44CigwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMSk3Ni44IDEzNyBTCigr
LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r
LSstKy0rLSstKyk3MgoxNTAgUSAyOC44KHxGKTcyIDE2MyBTKEVDIEVuY29kaW5nIE5hbWUp
LTI4LjggRSAyNCh8TykzOC40IEcKKGJqZWN0IExlbmd0aCBcKE1TQlwpKS0yNCBFKHwpMzMu
NiBFCigrLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r
LSstKy0rLSstKy0rLSstKyk3MgoxNzYgUSAxMDAuOCh8Tyk3MiAxODkgUyhiamVjdCBMZW5n
dGggXChMU0JcKSktMTAwLjggRSh8KTExMC40IEUKKCstKy0rLSstKy0rLSstKy0rLSstKy0r
LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rKTcyCjIwMiBRIDEw
MC44KHxTKTcyIDIxNSBTKG91cmNlIEJsb2NrIExlbmd0aCktMTAwLjggRSh8KTExMC40IEUK
KCstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r
LSstKy0rLSstKy0rKTcyCjIyOCBRIEYxKE5vdGUgdGhhdCB0aGlzIHN0cnVjdHVyZSBsaW1p
dHMgdGhlIHJhbmdlIG9mIHBvc3NpYmxlIEZFQyBFbmNvXApkaW5nIE5hbWVzIHRvIDAtOi02
NTUzNiwgZGVzcGl0ZSB0aGUgZik3MiAyNjcgUShhY3QgdGhhdCktLjEgRQoodGhlIEZFQyBP
YmplY3QgVCk3MiAyODAgUQoocmFuc21pc3Npb24gSW5mb3JtYXRpb24gY2FuIGFsc28gYmUg
dHJhbnNtaXR0ZWQgb3V0IG9mIGJhbmQuKS0uMzUgRShUaFwKZSBPYmplY3QgTGVuZ3RoLCBj
b21wb3NlZCBvZiBhIE1vc3QgU2lnbmlcMjE0Y2FudCBCeXRlcyBwb3J0aW9uIFwoTVNCXClc
CiBhbmQgYSBMZWFzdCBTaWduaVwyMTRjYW50IEJ5dGVzKTcyIDMwNiBRKHBvcnRpb24gXChM
U0JcKSwgaXMgZSk3MiAzMTkgUQooeHByZXNzZWQgaW4gYnl0ZXMuKS0uMTUgRS9GMyAxMS9U
aW1lcy1Cb2xkQDAgU0YoMi4yLik3MiAzNTggUS9GNCAxMwovVGltZXMtQm9sZEAwIFNGKFNt
YWxsIEJsb2NrIFN5c3RlbWF0aWMgRkVDIENvZGVzKTUuNSBFIEYwKFRoZSBmb2xsbyk3Mgoz
NzQuNiBRKHdpbmcgZGVcMjE0bml0aW9ucyBhcHBseSB0byBzeXN0ZW1hdGljIGNvZGVzIG9m
IHNtYWxsIGxlbmd0aCBcKFwKdG90YWwgYmxvY2sgbGVuZ3RoIDwgMl4xNlwpLiktLjI3NSBF
KFRoZSBGRUMgRW5jb2RpbmcgSWRlbnRpXDIxNGVyIGZvciBcCnVuZGVyIHNwZWNpXDIxNGVk
IGNvZGVzIGFzc2lnbmVkIHRvIFNtYWxsIEJsb2NrIFN5c3RlbWF0aWMgRkVDKTcyIDQwMC42
ClEoQ29kZXMgaXMgMTI5Lik3MiA0MTMuNiBRKEFsdGhvdWdoIHRoZXNlIGNvZGVzIGNhbiBn
ZW5lcmFsbHkgYmUgYWNjb21tXApvZGF0ZWQgYnkgdGhlIEZFQyBFbmNvZGluZyBJZGVudGlc
MjE0ZXIgZGVzY3JpYmVkKTcyIDQzOS42IFEoaW4gU2VjdGlvblwKIDIuMSwgYSBzcGVjaVwy
MTRjIEVuY29kaW5nLUlEIGlzIGRlXDIxNG5lZCBmb3Igc3lzdGVtYXRpYyBjb2RlcyB0byBh
bGxcCm8pNzIgNDUyLjYgUSAyLjc1KHdiKS0uMjc1IEcoZXR0ZXIgXDIxNWUpLTIuNzUgRSh4
aWJpbGl0eSktLjE2NSBFKGFuZCB0XApvIHJldGFpbiBoZWFkZXIgY29tcGFjdG5lc3MuIFRo
ZSBzbWFsbCBzb3VyY2UgYmxvY2sgbGVuZ3RoIGFuZCBzbWFsbCBlKQo3MiA0NjUuNiBRKHhh
cGFuc2lvbiBmKS0uMTY1IEUoYWN0b3IgdGhhdCktLjExIEUob2Z0ZW4gY2hhcmFjdGVyaXpl
IHN5c1wKdGVtYXRpYyBjb2RlcyBtYXkgcmVxdWlyZSB0aGF0IHRoZSBkYXRhIHNvdXJjZSBj
aGFuZ2VzIGZyZXF1ZW50bHkgdGhlKTcyCjQ3OC42IFEoc291cmNlIGJsb2NrIGxlbmd0aC4g
VCk3MiA0OTEuNiBRIDIuNzUob2EpLS44OCBHKGxsbyktMi43NSBFCjIuNzUod3QpLS4yNzUg
RyhoZSBkeW5hbWljIHYpLTIuNzUgRQooYXJpYXRpb24gb2YgdGhlIHNvdXJjZSBibG9jayBs
ZW5ndGggYW5kIHRvKS0uMjc1IEUKKGNvbW11bmljYXRlIGl0IHRvIHRoZSByZWNlaSk3MiA1
MDQuNiBRIC0uMTY1KHZlKS0uMjc1IEcocnMgd2l0aCBsbykuMTY1CkUgMi43NSh3byktLjI3
NSBHIC0uMTY1KHZlKS0yLjkxNSBHCihyaGVhZCwgdGhlIGJsb2NrIGxlbmd0aCBpcyBpbmNs
dWRlZCBpbiB0aGUgRkVDKS4xNjUgRSAtLjE2NShQYSk3MiA1MTcuNgpTKHlsb2FkIElELiku
MTY1IEUoVGhlIEZFQyBQKTcyIDU0My42IFEKKGF5bG9hZCBJRCBpcyBjb21wb3NlZCBvZiB0
aGUgZW5jb2RpbmcgYmxvY2sgbnVtYmVyKS0uMTY1IEUgMi43NSgsdCktLjQ0CkcoaGUgZW5j
b2Rpbmcgc3ltYm9sIGlkZW50aVwyMTRlciktMi43NSBFKGFuZCB0aGUgYmxvY2sgbGVuZ3Ro
Oik3MiA1NTYuNgpRIEYyIDkxLjIoMDEyMyk3Ni44IDU5NS42IFMgNC44KDAxMjM0NTY3ODkw
MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxKTc2LjgKNjA4LjYgUwooKy0rLSstKy0rLSstKy0rLSst
Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSspNzIKNjIx
LjYgUSA5Nih8ZSk3MiA2MzQuNiBTKG5jb2RpbmcgYmxvY2sgbnVtYmVyKS05NiBFKHwpMTA1
LjYgRQooKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst
Ky0rLSstKy0rLSstKy0rLSspNzIKNjQ3LjYgUSAyOC44KHxTKTcyIDY2MC42IFMob3VyY2Ug
YmxvY2sgbGVuZ3RoKS0yOC44IEUgMzMuNih8ZSkyOC44IEcKKG5jb2Rpbmcgc3ltYm9sIElE
KS0zMy42IEUofCkyOC44IEUKKCstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r
LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rKTcyCjY3My42IFEgRjEoVGhlIEZFQyBP
YmplY3QgVCk3MiA3MTIuNiBRCihyYW5zbWlzc2lvbiBJbmZvcm1hdGlvbiwgd2hlbiB1c2Vk
LCBoYXMgdGhlIGZvbGxvKS0uMzUgRQood2luZyBzdHJ1Y3R1cmU6KS0uMjUgRSBGMChMdWJ5
L1YpNzIgNzY5IFEoaWNpc2Fuby9HZW1tZWxsL1JpenpvL0hhbmRsZSkKLS42NiBFKHkvQ3Jv
KS0uMTY1IEUgMTA5LjEwNih3Y3JvZnQgU2VjdGlvbiktLjI3NSBGIDIuNzUoMi4yLiBbUCky
Ljc1IEYKKGFnZSA1XSktLjE2NSBFIEVQCiUlUGFnZTogNiA2CiUlQmVnaW5QYWdlU2V0dXAK
QlAKJSVFbmRQYWdlU2V0dXAKL0YwIDExL1RpbWVzLVJvbWFuQDAgU0YoSU5URVJORVQpNzIg
NDkgUSA3MS41ODcoLURSQUZUIEV4cGlyZXM6KS0xLjAxMiBGCihKYW51YXJ5IDIwMDIpMi43
NSBFKEp1bHkgMjAwMSkxMjMuNzI2IEUvRjEgOC9Db3VyaWVyQDAgU0YgOTEuMigwMTIzKQo3
Ni44IDg1IFMgNC44KDAxMjM0NTY3ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAxKTc2LjggOTgg
UwooKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r
LSstKy0rLSstKy0rLSspNzIKMTExIFEgMjguOCh8Rik3MiAxMjQgUyhFQyBFbmNvZGluZyBO
YW1lKS0yOC44IEUgOS42KHxOKTM4LjQgRwoodW1iZXIgb2YgcmVkdW5kYW50IHN5bWJvbHMp
LTkuNiBFKHwpOS42IEUKKCstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst
Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rKTcyCjEzNyBRL0YyIDEwL1RpbWVzLVJvbWFu
QDAgU0YoV2hlbiB2KTcyIDE3NiBRKGFyaWFibGUgYmxvY2stbGVuZ3RoIGlzIHVzXAplZCwg
dGhlIG51bWJlciBvZiByZWR1bmRhbnQgc3ltYm9scyBpcyB0byBiZSBpbnRlcnByZXRlZCBh
cyBhIG1heGltdW0pCi0uMjUgRSAtLjI1KHZhKTcyIDE4OSBTKGx1ZSBcKHVwcGVyIGJvdW5k
XCkuIFRoaXMgXDIxNGVsZCBpcyBwcm8pLjI1IEUKKHZpZGVkIGFzIGFuIGluZGljYXRpb24g
dG8gYWxsbyktLjE1IEUgMi41KHdyKS0uMjUgRyhlY2VpKS0yLjUgRSAtLjE1Cih2ZSktLjI1
IEcgMi41KHN0KS4xNSBHIDIuNShvcCktMi41IEcocmVhbGxvY2F0ZSBhIGRlY29kZXIpLTIu
NSBFCihzdWl0YWJsZSBmb3IgYWxsIHRoZSBvYmplY3QgYmxvY2tzLik3MiAyMDIgUShOb3Rl
IHRoYXQgdGhpcyBzdHJ1Y3R1cmUgXApsaW1pdHMgdGhlIHJhbmdlIG9mIHBvc3NpYmxlIEZF
QyBFbmNvZGluZyBOYW1lcyB0byAwLTotNjU1MzYsIGRlc3BpdGUgdFwKaGUgRkVDKTcyIDIy
OCBRKE9iamVjdCBUKTcyIDI0MSBRCihyYW5zbWlzc2lvbiBJbmZvcm1hdGlvbiBjYW4gYWxz
byBiZSB0cmFuc21pdHRlZCBvdXQgb2YgYmFuZC4pLS4zNSBFL0YzCjExL1RpbWVzLUJvbGRA
MCBTRigzLik3MiAyODAgUS9GNCAxNC9UaW1lcy1Cb2xkQDAgU0YoSUFOKTUuNSBFIDMuNShB
QykKLS4yOCBHKG9uc2lkZXJhdGlvbnMpLTMuNSBFIEYwIC0xLjIyMShWYSk3MiAyOTYuNiBT
KGx1ZXMgb2YgRkVDIEVuY29kaW5cCmcgSWRlbnRpXDIxNGVycyBhbmQgRkVDIEVuY29kaW5n
IE5hbWVzIGFyZSBzdWJqZWN0IHRvIElBTikxLjIyMSBFIDIuNzUKKEFyKS0uMzg1IEcgLS4x
NjUoZWcpLTIuNzUgRyhpc3RyYXRpb24uKS4xNjUgRShGRUMgRW5jb2RpbmcgSWRlbnRpXDIx
NGVcCnJzIGFuZCBGRUMgRW5jb2RpbmcgTmFtZXMgYXJlIGhpZXJhcmNoaWNhbDogRkVDIEVu
Y29kaW5nIElkZW50aVwyMTRlcnMpCjcyIDMwOS42IFEoXChhdCB0aGUgdG9wIGxlKTcyIDMy
Mi42IFEgLS4xNjUodmUpLS4yNzUgRyhsXCkgc2NvcGUgcmFuZ2VzXAogb2YgRkVDIEVuY29k
aW5nIE5hbWVzLiBOb3QgYWxsIEZFQyBFbmNvZGluZyBJZGVudGlcMjE0ZXJzIGhhKS4xNjUg
RSAuMzMKLS4xNjUodmUgYSktLjIyIEgoY29ycmVzcG9uZGluZyBGRUMgRW5jb2RpbmcgTmFt
ZSBzY29wZSBcKHNlZSBiZWxvKTcyCjMzNS42IFEod1wpLiktLjI3NSBFIDIuNzUoQUYpNzIg
MzYxLjYgUwooRUMgRW5jb2RpbmcgSWRlbnRpXDIxNGVyIGlzIGEgbnVtZXJpYyBub24tbmUp
LTIuNzUgRSAtLjA1NShnYSktLjE2NSBHCih0aSkuMDU1IEUgLjMzIC0uMTY1KHZlIGkpLS4y
NzUgSChuZGUpLjE2NSBFKHguIFYpLS4xNjUgRQooYWx1ZSBmcm9tIDAgdG8gMTI3IGFyZSBy
ZXNlcnYpLTEuMjIxIEUoZWQgZm9yKS0uMTY1IEUoRkVDIGVuY29kZXJzIHRoYVwKdCBhcmUg
ZnVsbHkgc3BlY2lcMjE0ZWQsIGFzIGRlc2NyaWJlZCBpbiBzZWN0aW9uIDMuMS4gVGhlIGFz
c2lnbm1lbnQgb2ZcCiBhIEZFQyk3MiAzNzQuNiBRKEVuY29kaW5nIElkZW50aVwyMTRlciBp
biB0aGlzIHJhbmdlIGNhbiBvbmx5IGJlIGdyYW50XAplZCBpZiB0aGUgcmVxdWVzdG9yIGNh
biBwcm8pNzIgMzg3LjYgUSh2aWRlIHN1Y2ggYSktLjE2NSBFCihzcGVjaVwyMTRjYXRpb24g
cHVibGlzaGVkIGFzIGFuIElFVEYgUkZDLiBWKTcyIDQwMC42IFEKKGFsdWVzIGdyZWF0ZXIg
dGhhbiAxMjcgY2FuIGJlIGFzc2lnbmVkIHRvIHVuZGVyKS0xLjIyMSBFKC0pLS4yMiBFKHNw
ZWNcCmlcMjE0ZWQgZW5jb2Rpbmcgc2NoZW1lcy4gTm90ZTogdGhpcyBzcGVjaVwyMTRjYXRp
b24gYWxyZWFkeSBhc3NpZ25zIHRoXAplIHYpNzIgNDEzLjYgUShhbHVlcyAxMjggYW5kIDEy
OS4pLS4yNzUgRShJbiBhbik3MiA0MzkuNiBRIDIuNzUoeWMpLS4xNjUKRyhhc2UgdiktMi43
NSBFKGFsdWVzIG9mIEZFQyBFbmNvZGluZyBJZGVudGlcMjE0ZXJzIGNhbiBvbmx5IGJlIGFz
c2lnbmVcCmQgaWYgdGhlIHJlcXVpcmVkIEZFQyBwYWNrKS0uMjc1IEUoZXQpLS4xMSBFKFwy
MTRlbGRzIGNvcnJlc3BvbmRpbmcgdG8gXAppdCBcKHNlZSBzZWN0aW9uIDEuMlwpIGFyZSBz
cGVjaVwyMTRlZCBpbiBhIFJGQy4pNzIgNDUyLjYgUQooRWFjaCBGRUMgRW5jb2RpbmcgSWRl
bnRpXDIxNGVyIGFzc2lnbmVkIHRvIGFuIHVuZGVyKTcyIDQ3OC42IFEKKC1zcGVjaVwyMTRl
ZCBlbmNvZGluZyBzY2hlbWUgc2NvcGVzIGFuKS0uMjIgRQooaW5kZXBlbmRlbnQgcmFuZ2Ug
b2YgRkVDIEVuY29kaW5nIE5hbWVzIFwoaS5lLiB0aGUgc2FtZSB2KTcyIDQ5MS42IFEKKGFs
dWUgb2YgRkVDIEVuY29kaW5nIE5hbWUgY2FuIGJlKS0uMjc1IEUocmV1c2VkIGZvciBkaWYp
NzIgNTA0LjYgUShmZXJcCmVudCBGRUMgRW5jb2RpbmcgSWRlbnRpXDIxNGVyc1wpLiBBbiBG
RUMgRW5jb2RpbmcgTmFtZSBpcyBhIG51bWVyaWMgbm9uXAotKS0uMjc1IEUobmUpNzIgNTE3
LjYgUSAtLjA1NShnYSktLjE2NSBHKHRpKS4wNTUgRSAuMzMgLS4xNjUodmUgaSktLjI3NQpI
KG5kZSkuMTY1IEUoeC4gVGhlIGRvY3VtZW50IHRoYXQgcmVzZXJ2KS0uMTY1IEUKKGVzIGEg
RkVDIEVuY29kaW5nIElkZW50aVwyMTRlciBNQSktLjE2NSBFIDIuNzUoWWEpLTEuMTU1IEcK
KGxzbyBzcGVjaWZ5IGEgcmFuZ2UpLTIuNzUgRShmb3IgdGhlIHN1Ym9yZGluYXRlIEZFQyBF
bmNvZGluZyBOYW1lcy4pNzIKNTMwLjYgUShVbmRlciB0aGUgc2NvcGUgb2YgYSBGRUMgRW5j
b2RpbmcgSWRlbnRpXDIxNGVyKTcyIDU1Ni42IFEgMi43NQooLEYpLS40NCBHKEVDIEVuY29k
aW5nIE5hbWVzIGFyZSBhc3NpZ25lZCBvbiBhIEZpcnN0KS0yLjc1IEUKKENvbWUgRmlyc3Qg
U2Vydik3MiA1NjkuNiBRKGVkIGJhc2UgdG8gcmVxdWVzdG9ycyB0aGF0IGFyZSBhYmxlIHRv
IHBybykKLS4xNjUgRSh2aWRlIHBvaW50IG9mIGNvbnRhY3QgaW5mb3JtYXRpb24gYW5kIGEp
LS4xNjUgRShwb2ludGVyIHRvIHB1YmxcCmljbHkgYWNjZXNzaWJsZSBkb2N1bWVudGF0aW9u
IGRlc2NyaWJpbmcgdGhlIEZFQyBzY2hlbWUgYW5kIHcpNzIgNTgyLjYgUQooYXlzIHRvIG9i
dGFpbiBpdCktLjExIEUoXChlLmcuIGEgcG9pbnRlciB0byBhIHB1YmxpY2x5IGEpNzIgNTk1
LjYgUQotLjI3NSh2YSktLjIyIEcKKGlsYWJsZSByZWZlcmVuY2UtaW1wbGVtZW50YXRpb24g
b3IgdGhlIG5hbWUgYW5kIGNvbnRhY3RzIG9mIGEpLjI3NSBFCihjb21wYW4pNzIgNjA4LjYg
USAyLjc1KHl0KS0uMTY1IEcoaGF0IHNlbGxzIGl0LCBlaXRoZXIgc2VwYXJhdGVseSBvciBl
XAptYmVkZGVkIGluIGFub3RoZXIgcHJvZHVjdFwpLiBUaGUgcmVxdWVzdG9yIGlzKS0yLjc1
IEUKKHJlc3BvbnNpYmxlIGZvciBrKTcyIDYyMS42IFEoZWVwaW5nIHRoaXMgaW5mb3JtYXRp
b24gdXAgdG8gZGF0ZS4pLS4xMSBFCkYzKDQuKTcyIDY2MC42IFEgRjQoQWNrbm8pNS41IEUo
d2xlZGdtZW50cyktLjE0IEUgRjAKKEJyaWFuIEFkYW1zb24gY29udHJpYik3MiA2NzcuMiBR
Cih1dGVkIHRvIHRoaXMgZG9jdW1lbnQgYnkgc2hhcGluZyBTZWN0aW9uIDIuMiBhbmQgcHJv
KS0uMjIgRQoodmlkaW5nIGdlbmVyYWwpLS4xNjUgRShmZWVkYmFjay4gVyk3MiA2OTAuMiBR
IDIuNzUoZWEpLS44OCBHCihsc28gd2lzaCB0byB0aGFuayBWKS0yLjc1IEUoaW5jZW50IFJv
Y2EgZm9yIGhpcyBjb21tZW50cy4pLS42NiBFCihMdWJ5L1YpNzIgNzY5IFEoaWNpc2Fuby9H
ZW1tZWxsL1JpenpvL0hhbmRsZSktLjY2IEUoeS9Dcm8pLS4xNjUgRQoxMTcuMzU2KHdjcm9m
dCBTZWN0aW9uKS0uMjc1IEYgMi43NSg0LiBbUCkyLjc1IEYoYWdlIDZdKS0uMTY1IEUgRVAK
JSVQYWdlOiA3IDcKJSVCZWdpblBhZ2VTZXR1cApCUAolJUVuZFBhZ2VTZXR1cAovRjAgMTEv
VGltZXMtUm9tYW5AMCBTRihJTlRFUk5FVCk3MiA0OSBRIDcxLjU4NygtRFJBRlQgRXhwaXJl
czopLTEuMDEyIEYKKEphbnVhcnkgMjAwMikyLjc1IEUoSnVseSAyMDAxKTEyMy43MjYgRS9G
MSAxMS9UaW1lcy1Cb2xkQDAgU0YoNS4pNzIgODUKUS9GMiAxNC9UaW1lcy1Cb2xkQDAgU0Yo
UmVmZXIpNS41IEUoZW5jZXMpLS4yNTIgRSBGMChbMV0gTHVieSk3MiAxMTQuNiBRCjIuNzUo
LE0pLS43MTUgRyguLCBWKS0yLjc1IEUKKGljaXNhbm8sIEdlbW1lbGwsIEouLCBMLiwgUml6
em8sIEwuLCBIYW5kbGUpLS42NiBFIDEuNDMgLS43MTUoeSwgTSkKLS4xNjUgSCAyLjc1KC4s
IENybykuNzE1IEYod2Nyb2Z0LCBKLiwgIlRoZSB1c2Ugb2YpLS4yNzUgRSAtLjE2NShGbyk3
MgoxMjcuNiBTKHJ3KS4xNjUgRShhcmQgRXJyb3IgQ29ycmVjdGlvbiBpbiBSZWxpYWJsZSBN
dWx0aWNhc3QiLCBJbnRlcm5ldFwKIGRyYWZ0IGRyYWZ0LWlldGYtcm10LWluZm8tZmVjLTAw
LnR4dCwpLS4xMSBFKE5vKTcyIDE0MC42IFEgLS4xNjUodmUpCi0uMTY1IEcobWJlciAyMDAw
LikuMTY1IEUgRjEoNi4pNzIgMTc5LjYgUSBGMiAtLjcoQXUpNS41IEcodGhvcnMnIEFkZHIp
Ci43IEUoZXNzZXMpLS4yNTIgRSBGMChNaWNoYWVsIEx1YnkpODAuMjUgMTk2LjIgUQoobHVi
eUBkaWdpdGFsZm91bnRhaW4uY29tKTgwLjI1IDIwOS4yIFEoRGlnaXRhbCBGKTgwLjI1IDIy
Mi4yIFEKKG91bnRhaW4sIEluYy4pLS4xNjUgRSgzOTE0MSBDaSk4MC4yNSAyMzUuMiBRKHZp
YyBDZW50ZXIgRHJpKS0uMjc1IEUKLS4xNjUodmUpLS4yNzUgRyhTdWl0ZSAzMDApODAuMjUg
MjQ4LjIgUShGcmVtb250LCBDQSk4MC4yNSAyNjEuMiBRCig5NDUzOCk1LjUgRShMb3Jlbnpv
IFYpODAuMjUgMjg3LjIgUShpY2lzYW5vKS0uNjYgRShsb3JlbnpvQGNpc2NvLmNvbSkKODAu
MjUgMzAwLjIgUShjaXNjbyBTeXN0ZW1zLCBJbmMuKTgwLjI1IDMxMy4yIFEoMTcwIFcpODAu
MjUgMzI2LjIgUQooZXN0IFQpLS44OCBFKGFzbWFuIERyKS0uODggRSguLCktLjYwNSBFKFNh
biBKb3NlLCBDQSwgVVNBLCA5NTEzNCk4MC4yNQozMzkuMiBRKEppbSBHZW1tZWxsKTgwLjI1
IDM2NS4yIFEoamdlbW1lbGxAbWljcm9zb2Z0LmNvbSk4MC4yNSAzNzguMiBRCihNaWNyb3Nv
ZnQgUmVzZWFyY2gpODAuMjUgMzkxLjIgUSgzMDEgSG8pODAuMjUgNDA0LjIgUSAtLjExKHdh
KS0uMjc1IEcKKHJkIFN0LiwgIzgzMCkuMTEgRShTYW4gRnJhbmNpc2NvLCBDQSwgVVNBLCA5
NDEwNSk4MC4yNSA0MTcuMiBRCihMdWlnaSBSaXp6byk4MC4yNSA0NDMuMiBRKGx1aWdpQGll
dC51bmlwaS5pdCk4MC4yNSA0NTYuMiBRIC0uNDQoQUMpCjgwLjI1IDQ2OS4yIFMoSVJJLCAx
OTQ3IENlbnRlciBTdC4sIEJlcmspLjQ0IEUoZWxlKS0uMTEgRSAyLjc1KHlDKS0uMTY1Ckcg
Mi43NShBOSktMi43NSBHKDQ3MDQpLTIuNzUgRShhbmQpODAuMjUgNDgyLjIgUQooRGlwLiBk
aSBJbmcuIGRlbGwnSW5mb3JtYXppb25lKTgwLjI1IDQ5NS4yIFEoVW5pKTgwLjI1IDUwOC4y
IFEgLS4xNjUKKHZlKS0uMjc1IEcocnNpdGFgIGRpIFBpc2EpLjE2NSBFKHZpYSBEaW90aXNh
bHZpIDIsIDU2MTI2IFBpc2EsIEl0YWx5KQo4MC4yNSA1MjEuMiBRKE1hcmsgSGFuZGxlKTgw
LjI1IDU0Ny4yIFEoeSktLjE2NSBFKG1qaEBhY2lyaS5vcik4MC4yNQo1NjAuMiBRKGcpLS4x
OTggRSAtLjQ0KEFDKTgwLjI1IDU3My4yIFMoSVJJKS40NCBFKDE5NDcgQ2VudGVyIFN0Lik4
MC4yNQo1ODYuMiBRKEJlcmspODAuMjUgNTk5LjIgUShlbGUpLS4xMSBFIDIuNzUoeUMpLS4x
NjUgRyhBLCBVU0EsIDk0NzA0KQotMi43NSBFKEpvbiBDcm8pODAuMjUgNjI1LjIgUSh3Y3Jv
ZnQpLS4yNzUgRShKLkNybyk4MC4yNSA2MzguMiBRCih3Y3JvZnRAY3MudWNsLmFjLnVrKS0u
Mjc1IEUoRGVwYXJ0bWVudCBvZiBDb21wdXRlciBTY2llbmNlKTgwLjI1IDY1MS4yClEoVW5p
KTgwLjI1IDY2NC4yIFEgLS4xNjUodmUpLS4yNzUgRyhyc2l0eSBDb2xsZSkuMTY1IEUoZ2Ug
TG9uZG9uKS0uMTY1CkUoR28pODAuMjUgNjc3LjIgUSh3ZXIgU3RyZWV0LCktLjI3NSBFKExv
bmRvbiBXQzFFIDZCVCk4MC4yNSA2OTAuMiBRCjIuNzUoLFUpLS44MTQgRyhLKS0yLjc1IEUo
THVieS9WKTcyIDc2OSBRKGljaXNhbm8vR2VtbWVsbC9SaXp6by9IYW5kbGUpCi0uNjYgRSh5
L0NybyktLjE2NSBFIDExNy4zNTYod2Nyb2Z0IFNlY3Rpb24pLS4yNzUgRiAyLjc1KDYuIFtQ
KTIuNzUgRgooYWdlIDddKS0uMTY1IEUgRVAKJSVQYWdlOiA4IDgKJSVCZWdpblBhZ2VTZXR1
cApCUAolJUVuZFBhZ2VTZXR1cAovRjAgMTEvVGltZXMtUm9tYW5AMCBTRihJTlRFUk5FVCk3
MiA0OSBRIDcxLjU4NygtRFJBRlQgRXhwaXJlczopLTEuMDEyIEYKKEphbnVhcnkgMjAwMiky
Ljc1IEUoSnVseSAyMDAxKTEyMy43MjYgRS9GMSAxMS9UaW1lcy1Cb2xkQDAgU0YoNy4pNzIg
ODUKUS9GMiAxNC9UaW1lcy1Cb2xkQDAgU0YoRnVsbCBDb3B5cmlnaHQgU3RhdGVtZW50KTUu
NSBFIEYwKENvcCk3MiAxMDEuNiBRCih5cmlnaHQgXChDXCkgVGhlIEludGVybmV0IFNvY2ll
dHkgXCgyMDAwXCkuKS0uMTEgRShBbGwgUmlnaHRzIFJlc2VydikKNS41IEUoZWQuKS0uMTY1
IEUoVGhpcyBkb2N1bWVudCBhbmQgdHJhbnNsYXRpb25zIG9mIGl0IG1heSBiZSBjb3BpZWQg
YW5cCmQgZnVybmlzaGVkIHRvIG90aGVycywgYW5kIGRlcmkpNzIgMTE4LjIgUSAtLjI3NSh2
YSktLjI3NSBHKHRpKS4yNzUgRQouMzMgLS4xNjUodmUgdyktLjI3NSBIKG9ya3MpLjA1NSBF
KHRoYXQgY29tbWVudCBvbiBvciBvdGhlcndpc2UgZSk3MgoxMzEuMiBRCih4cGxhaW4gaXQg
b3IgYXNzaXN0IGluIGl0cyBpbXBsZW1lbnRhdGlvbiBtYXkgYmUgcHJlcGFyZWQsIGNvcGll
ZCwpCi0uMTY1IEUocHVibGlzaGVkIGFuZCBkaXN0cmliKTcyIDE0NC4yIFEKKHV0ZWQsIGlu
IHdob2xlIG9yIGluIHBhcnQsIHdpdGhvdXQgcmVzdHJpY3Rpb24gb2YgYW4pLS4yMiBFIDIu
NzUoeWspCi0uMTY1IEcoaW5kLCBwcm8pLTIuNzUgRSh2aWRlZCB0aGF0IHRoZSktLjE2NSBF
KGFibyk3MiAxNTcuMiBRIC4zMyAtLjE2NQoodmUgYyktLjE2NSBIKG9wKS4xNjUgRSh5cmln
aHQgbm90aWNlIGFuZCB0aGlzIHBhcmFncmFwaCBhcmUgaW5jbHVkZWQgb1wKbiBhbGwgc3Vj
aCBjb3BpZXMgYW5kIGRlcmkpLS4xMSBFIC0uMjc1KHZhKS0uMjc1IEcodGkpLjI3NSBFIC4z
MyAtLjE2NQoodmUgdyktLjI3NSBIKG9ya3MuKS4wNTUgRShIbyk3MiAxNzAuMiBRKHdlKS0u
Mjc1IEUgLS4xNjUodmUpLS4yNzUgRyAuODgKLS40NChyLCB0KS4xNjUgSChoaXMgZG9jdW1l
bnQgaXRzZWxmIG1heSBub3QgYmUgbW9kaVwyMTRlZCBpbiBhbikuNDQgRQoyLjc1KHl3KS0u
MTY1IEcoYXkpLTIuODYgRSAyLjc1KCxzKS0uNzE1IEcodWNoIGFzIGJ5IHJlbW8pLTIuNzUg
RQoodmluZyB0aGUpLS4xNjUgRShjb3ApNzIgMTgzLjIgUSh5cmlnaHQgbm90aWNlIG9yIHJl
ZmVyZW5jZXMgdG8gdGhlIEludFwKZXJuZXQgU29jaWV0eSBvciBvdGhlciBJbnRlcm5ldCBv
ciktLjExIEUgLS4wNTUoZ2EpLS4xOTggRyhuaXphdGlvbnMsIGUpCi4wNTUgRSh4Y2VwdCBh
cyktLjE2NSBFKG5lZWRlZCBmb3IgdGhlIHB1cnBvc2Ugb2YgZGUpNzIgMTk2LjIgUSAtLjE2
NQoodmUpLS4yNzUgRyhsb3BpbmcgSW50ZXJuZXQgc3RhbmRhcmRzIGluIHdoaWNoIGNhc2Ug
dGhlIHByb2NlZHVyZXMgZm9yKQouMTY1IEUoY29wKTcyIDIwOS4yIFEKKHlyaWdodHMgZGVc
MjE0bmVkIGluIHRoZSBJbnRlcm5ldCBsYW5ndWFnZXMgb3RoZXIgdGhhbiBFbmdsaXNoLikt
LjExIEUKKFRoZSBsaW1pdGVkIHBlcm1pc3Npb25zIGdyYW50ZWQgYWJvKTcyIDIyNS44IFEg
LjMzIC0uMTY1KHZlIGEpLS4xNjUgSAoocmUgcGVycGV0dWFsIGFuZCB3aWxsIG5vdCBiZSBy
ZSkuMTY1IEUgLS4yMih2byktLjI3NSBHIC0uMTEoa2UpLjIyIEcKMi43NShkYikuMTEgRyAy
Ljc1KHl0KS0yLjc1IEcoaGUgSW50ZXJuZXQpLTIuNzUgRQooU29jaWV0eSBvciBpdHMgc3Vj
Y2Vzc29ycyBvciBhc3NpZ25zLik3MiAyMzguOCBRCihUaGlzIGRvY3VtZW50IGFuZCB0aGUg
aW5mb3JtYXRpb24gY29udGFpbmVkIGhlcmVpbiBpcyBwcm8pNzIgMjU1LjQgUQoodmlkZWQg
b24gYW4gIkFTIElTIiBiYXNpcyBhbmQgVEhFKS0uMTY1IEUKKElOVEVSTkVUIFNPQ0lFVFkg
QU5EIFRIRSBJTlRFUk5FVCBFTkdJTkVFUklORyBUKTcyIDI2OC40IFEKKEFTSyBGT1JDRSBE
SVNDTEFJTVMpLTEuMDIzIEUoQUxMIFcpNzIgMjgxLjQgUQooQVJSQU5USUVTLCBFWFBSRVNT
IE9SIElNUExJRUQsIElOQ0xVRElORyBCKS0xLjMyIEUoVVQgTk8pLS4xMSBFIDIuNzUKKFRM
KS0uNDQgRyhJTUlURUQgVCktMi43NSBFIDIuNzUoT0EpLS4xOTggRyhOWSktMi43NSBFIC0x
LjMyKFdBKTcyIDI5NC40ClMoUlJBTlRZIFRIQSkxLjMyIEUgMi43NShUVCktMS4yMjEgRyhI
RSBVU0UgT0YgVEhFIElORk9STUEpLTIuNzUgRQooVElPTiBIRVJFSU4gV0lMTCBOTyktMS4y
MjEgRSAyLjc1KFRJKS0uNDQgRyhORlJJTkdFKS0yLjc1IEUKKEFOWSBSSUdIVFMgT1IgQU5Z
IElNUExJRUQgVyk3MiAzMDcuNCBRKEFSUkFOVElFUyBPRiBNRVJDSEFOVCktMS4zMiBFCihB
QklMSVRZIE9SIEZJVE5FU1MpLTEuMDIzIEUoRk9SIEEgUCk3MiAzMjAuNCBRKEFSKS0xLjAx
MiBFCihUSUNVTEFSIFBVUlBPU0UuIiktLjY2IEUoTHVieS9WKTcyIDc2OSBRKGljaXNhbm8v
R2VtbWVsbC9SaXp6by9IYW5kbGUpCi0uNjYgRSh5L0NybyktLjE2NSBFIDExNy4zNTYod2Ny
b2Z0IFNlY3Rpb24pLS4yNzUgRiAyLjc1KDcuIFtQKTIuNzUgRgooYWdlIDhdKS0uMTY1IEUg
RVAKJSVQYWdlOiA5IDkKJSVCZWdpblBhZ2VTZXR1cApCUAolJUVuZFBhZ2VTZXR1cAovRjAg
MTEvVGltZXMtUm9tYW5AMCBTRihJTlRFUk5FVCk3MiA0OSBRIDcxLjU4NygtRFJBRlQgRXhw
aXJlczopLTEuMDEyIEYKKEphbnVhcnkgMjAwMikyLjc1IEUoSnVseSAyMDAxKTEyMy43MjYg
RShMdWJ5L1YpNzIgNzY5IFEKKGljaXNhbm8vR2VtbWVsbC9SaXp6by9IYW5kbGUpLS42NiBF
KHkvQ3JvKS0uMTY1IEUgMTE3LjM1Ngood2Nyb2Z0IFNlY3Rpb24pLS4yNzUgRiAyLjc1KDcu
IFtQKTIuNzUgRihhZ2UgOV0pLS4xNjUgRSBFUAolJVRyYWlsZXIKZW5kCiUlRU9GCg==
--==_Exmh_5297534880--
>From owner-rmt@listserv.lbl.gov Fri Jul 20 08:52:24 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f6KFpOD18179;
Fri, 20 Jul 2001 08:51:24 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f6KFpNR18175
for <rmt@listserv.lbl.gov>; Fri, 20 Jul 2001 08:51:23 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f6KFpMj11702
for <rmt@listserv.lbl.gov>; Fri, 20 Jul 2001 08:51:22 -0700 (PDT)
Received: from cisco.com (cypher.cisco.com [171.69.11.18])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f6KFpLA11693
for <rmt@lbl.gov>; Fri, 20 Jul 2001 08:51:21 -0700 (PDT)
Received: from localhost (speakman@localhost)
by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id IAA18748;
Fri, 20 Jul 2001 08:50:45 -0700 (PDT)
Message-Id: <200107201550.IAA18748@cisco.com>
To: internet-drafts@ietf.org
cc: rmt@lbl.gov
Subject: draft-ietf-rmt-gra-arch-02.txt
Mime-Version: 1.0 (generated by tm-edit 7.105)
Content-Type: text/plain; charset=US-ASCII
Date: Fri, 20 Jul 2001 08:50:45 -0700
From: Tony Speakman <speakman@cisco.com>
Sender: owner-rmt@lbl.gov
Precedence: bulk
Please post the following draft for discussion in the RMT WG:
ftp://ftp-eng.cisco.com/speakman/draft-ietf-rmt-gra-arch-02.txt
Thanks,
Tony S
>From owner-rmt@listserv.lbl.gov Fri Jul 20 12:16:44 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f6KJG8I26455;
Fri, 20 Jul 2001 12:16:08 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f6KJG6R26451
for <rmt@listserv.lbl.gov>; Fri, 20 Jul 2001 12:16:06 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f6KJG5s25529
for <rmt@listserv.lbl.gov>; Fri, 20 Jul 2001 12:16:05 -0700 (PDT)
Received: from mx.webfountain.com (mx.digitalfountain.com [209.219.233.39])
by SpamWall.lbl.gov (8.11.2/8.11.2) with SMTP id f6KJG4A25515
for <rmt@lbl.gov>; Fri, 20 Jul 2001 12:16:04 -0700 (PDT)
Received: (qmail 23642 invoked from network); 20 Jul 2001 19:15:50 -0000
Received: from mail.intranet (10.1.1.37)
by mx.digitalfountain.com with SMTP; 20 Jul 2001 19:15:50 -0000
Received: from leningrad (leningrad.intranet [10.1.3.72])
by mail.intranet (8.9.3/8.9.3) with SMTP id MAA29212;
Fri, 20 Jul 2001 12:15:24 -0700
X-Authentication-Warning: mail.intranet: Host leningrad.intranet [10.1.3.72] claimed to be leningrad
From: "Mike Luby" <luby@digitalfountain.com>
To: <internet-drafts@ietf.org>
Cc: "Michael Luby" <luby@digitalfountain.com>,
"Jim Gemmell" <jgemmell@MICROSOFT.com>, "Luigi Rizzo" <luigi@iet.unipi.it>,
"Lorenzo Vicisano" <lorenzo@cisco.com>,
"Mark Handley" <mjh@icsi.berkeley.edu>,
"Jon Crowcroft" <J.Crowcroft@cs.ucl.ac.uk>,
"Roger Kermode" <Roger.Kermode@motorola.com>, <rmt@lbl.gov>
Subject:
Date: Fri, 20 Jul 2001 12:17:04 -0700
Message-ID: <NEBBIAPCNKEDCLPNFBNCAEPLCGAA.luby@digitalfountain.com>
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="----=_NextPart_000_0002_01C11115.E3203A10"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Sender: owner-rmt@lbl.gov
Precedence: bulk
This is a multi-part message in MIME format.
------=_NextPart_000_0002_01C11115.E3203A10
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Please post this draft on the IETF Internet Drafts archive.
This is an update of an existing WG draft (RMT).
Michael Luby
Chief Technical Officer
Digital Fountain, Inc.
39141 Civic Center Drive
Suite 300
Fremont, CA 94538
www.digitalfountain.com
luby@digitalfountain.com
(510) 284-1420 (phone)
(510) 284-1499 (fax)
(510) 284-1400 (main)
------=_NextPart_000_0002_01C11115.E3203A10
Content-Type: text/plain;
name="submitted draft-ietf-rmt-bb-alc-02-mgl-7-20-2001.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
filename="submitted draft-ietf-rmt-bb-alc-02-mgl-7-20-2001.txt"
Internet Engineering Task Force RMT WG=0A=
INTERNET-DRAFT M.Luby/Digital Fountain=0A=
draft-ietf-rmt-pi-alc-02.txt J.Gemmell/Microsoft=0A=
L.Vicisano/Cisco=0A=
L.Rizzo/ACIRI and Univ. Pisa=0A=
J. Crowcroft/UCL=0A=
20 July 2001=0A=
Expires: January 2002=0A=
=0A=
=0A=
Asynchronous Layered Coding:=0A=
A massively scalable reliably content delivery protocol=0A=
=0A=
=0A=
=0A=
Status of this Document=0A=
=0A=
This document is an Internet-Draft and is in full conformance with all=0A=
provisions of Section 10 of RFC2026.=0A=
=0A=
Internet-Drafts are working documents of the Internet Engineering Task=0A=
Force (IETF), its areas, and its working groups. Note that other groups=0A=
may also distribute working documents as Internet-Drafts.=0A=
=0A=
Internet-Drafts are valid for a maximum of six months and MAY be=0A=
updated, replaced, or obsoleted by other documents at any time. It is=0A=
inappropriate to use Internet-Drafts as reference material or to cite=0A=
them other than as a "work in progress".=0A=
=0A=
The list of current Internet-Drafts can be accessed at=0A=
http://www.ietf.org/ietf/1id-abstracts.txt=0A=
=0A=
To view the list Internet-Draft Shadow Directories, see=0A=
http://www.ietf.org/shadow.html.=0A=
=0A=
This document is a product of the IETF RMT WG. Comments should be=0A=
addressed to the authors, or the WG's mailing list at rmt@lbl.gov.=0A=
=0A=
=0A=
Abstract=0A=
=0A=
=0A=
This document describes the Asynchronous Layered Coding=0A=
protocol, a massively scalable reliable content delivery=0A=
protocol, hereafter referred to as ALC. ALC can be used for=0A=
=0A=
=0A=
=0A=
Luby/Gemmell/Vicisano/Rizzo/Crowcroft [Page 1]=0A=
=0C=0A=
INTERNET-DRAFT Expires: January 2002 July 2001=0A=
=0A=
=0A=
multi-rate reliable delivery of content to large sets of=0A=
receivers. ALC uses the LCT transport described in [3]=0A=
augmented with a congestion control protocol that is compliant=0A=
with RFC2387 such as one of the layered congestion control=0A=
protocols described [4]. ALC achieves reliability based on FEC=0A=
codecs as generally described in [1], and in particular based=0A=
on the details provided in the FEC building block described in=0A=
[2].=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
Luby/Gemmell/Vicisano/Rizzo/Crowcroft [Page 2]=0A=
=0C=0A=
INTERNET-DRAFT Expires: January 2002 July 2001=0A=
=0A=
=0A=
Table of Contents=0A=
=0A=
=0A=
1. Introduction. . . . . . . . . . . . . . . . . . . . . . 4=0A=
1.1. Related Documents. . . . . . . . . . . . . . . . . . 5=0A=
1.2. Environmental Requirements and Considerations. . . . 5=0A=
2. General Architecture. . . . . . . . . . . . . . . . . . 6=0A=
2.1. Delivery service models. . . . . . . . . . . . . . . 6=0A=
2.2. Congestion Control . . . . . . . . . . . . . . . . . 7=0A=
3. Type of packets used by the ALC protocol. . . . . . . . 7=0A=
3.1. Packet format for the ALC protocol . . . . . . . . . 8=0A=
3.2. Packet header fields for the ALC protocol. . . . . . 8=0A=
4. Procedures. . . . . . . . . . . . . . . . . . . . . . . 9=0A=
4.1. Sender Operation . . . . . . . . . . . . . . . . . . 9=0A=
4.2. Receiver Operation . . . . . . . . . . . . . . . . . 10=0A=
5. Security Considerations . . . . . . . . . . . . . . . . 10=0A=
6. IANA Considerations . . . . . . . . . . . . . . . . . . 10=0A=
7. Intellectual Property Issues. . . . . . . . . . . . . . 10=0A=
8. Authors' Addresses. . . . . . . . . . . . . . . . . . . 11=0A=
9. Full Copyright Statement. . . . . . . . . . . . . . . . 13=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
Luby/Gemmell/Vicisano/Rizzo/Crowcroft [Page 3]=0A=
=0C=0A=
INTERNET-DRAFT Expires: January 2002 July 2001=0A=
=0A=
=0A=
1. Introduction=0A=
=0A=
This document describes a massively scalable reliable content delivery=0A=
protocol, Asynchronous Layered Coding (ALC), for multi-rate reliable=0A=
content delivery. ALC is a protocol instantiation as defined in=0A=
RFC3048. ALC uses the LCT transport [3]. Thus, like the LCT transport,=0A=
the ALC protocol is primarily designed to be used with the IP multicast=0A=
network service, but MAY also be used with other basic underlying=0A=
network or transport services such as unicast UDP. ALC uses FEC codes=0A=
to provide reliability as generally described in [1], i.e. all packets=0A=
in a session contain FEC coded information in formats that are compliant=0A=
with the FEC building block described in [2]. A crucial point is that=0A=
ALC strongly relies on FEC codecs in the sense that there is no request=0A=
for retransmission of individual packets from receivers that miss=0A=
packets in order to assure reliable reception of an object, and the=0A=
packets and their rate of transmission out of the sender can be=0A=
independent of the number and the individual reception experiences of=0A=
the receivers. In some delivery service models it is appropriate that=0A=
receivers send out of band messages to the sender to provide guaranteed=0A=
delivery of content. For example, in a push reliable delivery model=0A=
receivers may send messages to a sender to continue the session if=0A=
receivers have not yet received enough packets to recover the content or=0A=
to terminate the session when receivers have received enough packets to=0A=
recover the content. To be able to track usage of the system, receivers=0A=
may also send messages out of band to the sender that contain statistics=0A=
on their reception experience. ALC, however, does not require nor=0A=
specify such messages, with the aim of avoiding unnecessary limitation=0A=
to the scalability of the basic ALC protocol.=0A=
=0A=
The LCT transport provides support for congestion control, and the ALC=0A=
protocol uses this support. The congestion control protocol must=0A=
conform with RFC 2357. It is recommended that the congestion control=0A=
protocol used for ALC be a multi-rate protocol, as described in [4]. In=0A=
this case, a sender sends packets in the session to several LCT channels=0A=
at potentially different rates. Then, individual receivers can adjust=0A=
their reception rate within a session by adjusting which set of LCT=0A=
channels they are joined to at each point in time depending on the=0A=
available bandwidth between the receiver and the sender, but independent=0A=
of other receivers. A single rate congestion control protocol can also=0A=
be used, but this may limit the scalability of the session in terms of=0A=
the number of receivers that can concurrently participate.=0A=
=0A=
Receiver may join and leave a session asynchronously at their=0A=
discretion.=0A=
=0A=
An ALC packet thus consists of an LCT packet header, an FEC packet=0A=
header, optional by additional parameters and packet payload.=0A=
=0A=
=0A=
=0A=
=0A=
Luby/Gemmell/Vicisano/Rizzo/Crowcroft Section 1. [Page 4]=0A=
=0C=0A=
INTERNET-DRAFT Expires: January 2002 July 2001=0A=
=0A=
=0A=
ALC has the following properties when the LCT transport uses multicast=0A=
to deliver packets:=0A=
=0A=
=0A=
o To each receiver, it appears as if though there is a dedicated session=0A=
from the sender to the receiver, where the reception rate adjusts to=0A=
congestion along the path from sender to receiver.=0A=
=0A=
o To the sender, there is no difference in load or outgoing rate if one=0A=
receiver is joined to the session or a million (or any number of)=0A=
receivers are joined to the session, independent of when the receivers=0A=
join and leave.=0A=
=0A=
o On each link in the network, the packet traffic from the session and=0A=
its reaction to competing traffic is the same whether there is one=0A=
receiver or a million receivers beyond the link.=0A=
=0A=
Thus, ALC provides a massively scalable content delivery system that=0A=
is network friendly.=0A=
=0A=
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=0A=
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this=0A=
document are to be interpreted as described in RFC2119.=0A=
=0A=
=0A=
1.1. Related Documents=0A=
=0A=
The LCT transport that ALC MUST use is described in [3]. A more in-=0A=
depth description of the use of FEC codecs in reliable content delivery=0A=
protocols is given in [1]. All packets in a session MUST contain FEC=0A=
coded information in formats that are compliant with the FEC building=0A=
block described in [2]. Implementors of ALC MUST also implement a=0A=
congestion control protocol in accordance to RFC2357, where the=0A=
congestion control is over the entire session. Some possible schemes=0A=
are specified in [4]. Congestion control MUST be integrated into ALC=0A=
through the support provided in the LCT transport.=0A=
=0A=
It is RECOMMENDED that ALC implementors use some authentication scheme=0A=
to protect the protocol from attacks. An example of a possibly suitable=0A=
scheme is described in [5]. Authentication in ALC, if used, is to be=0A=
integrated through the support provided in the LCT transport.=0A=
=0A=
=0A=
1.2. Environmental Requirements and Considerations=0A=
=0A=
ALC is intended for congestion controlled, multi-rate delivery of=0A=
objects, i.e., reliable content delivery.=0A=
=0A=
=0A=
=0A=
=0A=
Luby/Gemmell/Vicisano/Rizzo/Crowcroft Section 1.2. [Page 5]=0A=
=0C=0A=
INTERNET-DRAFT Expires: January 2002 July 2001=0A=
=0A=
=0A=
All of the environmental requirements and considerations that apply to=0A=
the LCT transport and to the FEC building block also apply to ALC.=0A=
=0A=
=0A=
2. General Architecture=0A=
=0A=
ALC protocol consists basically of using FEC codecs in the form=0A=
described in [2] with the LCT transport as described in [3]. Thus, the=0A=
terminology used in the description of the LCT transport and the FEC=0A=
building block are inherited by the ALC protocol and this terminology is=0A=
used below. In particular, the definition of a session for the ALC=0A=
protocol is the same as it is for the LCT transport.=0A=
=0A=
Packets used within the ALC protocol are specialized versions of LCT=0A=
packets. In particular, a packet consists of an LCT packet header, an=0A=
FEC payload ID, optional additional parameters as appropriate, and the=0A=
packet payload. From the point of view of the LCT transport, the FEC=0A=
payload ID, the additional parameters if present, and the packet payload=0A=
are all part of the LCT packet payload.=0A=
=0A=
The out of band information used by the ALC protocol consists of the out=0A=
of band all information required for both the LCT transport and for the=0A=
FEC building block. The possible means for acquiring this out of band=0A=
information is the same as for the LCT transport and the FEC building=0A=
block, and in particular is outside the scope of the ALC protocol.=0A=
=0A=
Congestion control for the ALC protocol MUST conform to RFC 2387, and=0A=
MUST be provided through the mechanisms provided by the LCT transport.=0A=
Although it is not mandatory, ALC is most scalable when multi-rate=0A=
congestion control is used that does not require feedback from receivers=0A=
to the sender, and thus use of a mult-rate congestion control as=0A=
described in [4] is RECOMMENDED.=0A=
=0A=
=0A=
2.1. Delivery service models=0A=
=0A=
ALC can support several different delivery service models. Two examples=0A=
are briefly described here.=0A=
=0A=
=0A=
Push service model.=0A=
=0A=
One way a push service model can be used for reliable content delivery=0A=
is to deliver a series of objects. For example, a receiver could join=0A=
the session and dynamically adapt the number of LCT channels the=0A=
receiver is joined to until enough packets have been received to=0A=
reconstruct an object. After reconstructing the object the receiver may=0A=
stay in the session and wait for the transmission of the next object.=0A=
=0A=
=0A=
=0A=
Luby/Gemmell/Vicisano/Rizzo/Crowcroft Section 2.1. [Page 6]=0A=
=0C=0A=
INTERNET-DRAFT Expires: January 2002 July 2001=0A=
=0A=
=0A=
The push model is particularly attractive in satellite networks and=0A=
wireless networks. In these cases, a session may consist of one fixed=0A=
rate LCT channel.=0A=
=0A=
=0A=
On-demand content delivery model.=0A=
=0A=
For an on-demand content delivery service model, senders typically=0A=
transmit for some given time period selected to be long enough to allow=0A=
all the intended receivers to join the session and recover a single=0A=
object. For example a popular software update might be transmitted=0A=
using ALC for several days, even though a receiver may be able to=0A=
complete the download in one hour total of connection time, perhaps=0A=
spread over several intervals of time.=0A=
=0A=
In this case the receivers join the session at any point in time when it=0A=
is active and dynamically adapt the number of LCT channels they=0A=
subscribe to according to the available bandwidth using a multi-rate=0A=
congestion control protocol. Receivers leave the session when they have=0A=
received enough packets to recover the object.=0A=
=0A=
=0A=
Other service models.=0A=
=0A=
=0A=
There may be other delivery service models that can be supported by ALC.=0A=
The description of the potential applications, the appropriate delivery=0A=
service model, and the additional mechanisms to support such=0A=
functionalities when combined with ALC is beyond the scope of this=0A=
document.=0A=
=0A=
=0A=
2.2. Congestion Control=0A=
=0A=
The specific congestion control protocol to be used for ALC sessions=0A=
should be suitable for reliable content delivery. While the general=0A=
behavior of the congestion control protocol is to reduce the throughput=0A=
in presence of congestion and gradually increase it in the absence of=0A=
congestion, the actual dynamic behavior (e.g. response to single losses)=0A=
can vary.=0A=
=0A=
Some possible multi-rate congestion control protocols for reliable=0A=
content delivery using LCT are described in [4].=0A=
=0A=
3. Type of packets used by the ALC protocol=0A=
=0A=
The type of packet used by the ALC protocol is a specialized version of=0A=
an LCT packet. LCT packets are sent by senders to LCT channels.=0A=
=0A=
=0A=
=0A=
Luby/Gemmell/Vicisano/Rizzo/Crowcroft Section 3. [Page 7]=0A=
=0C=0A=
INTERNET-DRAFT Expires: January 2002 July 2001=0A=
=0A=
=0A=
Some instances of sessions MAY require the generation of feedback from=0A=
the receivers to the sender. However, the mechanism for doing this is=0A=
outside the scope of ALC.=0A=
=0A=
=0A=
3.1. Packet format for the ALC protocol=0A=
=0A=
The packet format used for ALC protocol is depicted in Figure 1.=0A=
=0A=
=0A=
0 1 2 3=0A=
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=0A=
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A=
| LCT packet header |=0A=
| |=0A=
+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=
=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=0A=
| FEC Payload ID |=0A=
| |=0A=
+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=
=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=0A=
| Additional parameters |=0A=
| (optional) |=0A=
+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=
=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=0A=
| Payload |=0A=
| |=0A=
| |=0A=
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A=
=0A=
=0A=
Figure 1 - Packet format for ALC protocol=0A=
=0A=
=0A=
3.2. Packet header fields for the ALC protocol=0A=
=0A=
The description of the fields and their functions within the LCT packet=0A=
header can be found in [3]. The information that needs to be=0A=
communicated out of band for the LCT transport and the possible=0A=
mechanisms for achieving this are described in [3].=0A=
=0A=
The description of the fields and their functions within the FEC payload=0A=
ID can be found in [2], with the exception that the FEC Encoding Flag=0A=
value, if applicable, MAY be communicated via the value of the Codepoint=0A=
field within LCT packet header. The information that needs to be=0A=
communicated out of band for the FEC codecs and the possible mechanisms=0A=
for achieving this are described in [2]. The mechanisms for=0A=
communicating the out of band information needed for the LCT transport,=0A=
including the mapping between the Codepoint field values in the LCT=0A=
packet header and the interpretations of the values, MAY be the same as=0A=
those used for communicating the out of band information needed for the=0A=
=0A=
=0A=
=0A=
Luby/Gemmell/Vicisano/Rizzo/Crowcroft Section 3.2. [Page 8]=0A=
=0C=0A=
INTERNET-DRAFT Expires: January 2002 July 2001=0A=
=0A=
=0A=
FEC building block, with the exception that portions of the information=0A=
needed for FEC building blocks may be communicated either through the=0A=
use of the Codepoint field in the LCT packet header, or through the=0A=
Additional Parameters fields that follow the FEC payload ID.=0A=
=0A=
The fields and formats of the optional Additional Parameters fields MUST=0A=
be communicated to the receivers out of band. The particular Additional=0A=
Parameters fields that may appear in packets MUST be communicated out of=0A=
band. The specification of which Additional Parameters fields that=0A=
appear in a packet MUST be communicated via the value of the Codepoint=0A=
field in the LCT packet header, and the mapping between Codepoint field=0A=
values and the Additional Parameters fields that appear in a packet MUST=0A=
be communicated out of band. It is RECOMMENDED that the format of any=0A=
Additonal Parameters fields adhere to the format of Header-Extension=0A=
Fields defined for the LCT transport in [3].=0A=
=0A=
4. Procedures=0A=
=0A=
=0A=
4.1. Sender Operation=0A=
=0A=
The sender operation when using the ALC protocol includes all the points=0A=
made about the sender operation when using the LCT transport as=0A=
described in [3], and the FEC building block as described in [2]. The=0A=
following description highlights some of the additional considerations=0A=
to be taken into account with respect to the ALC protocol.=0A=
=0A=
Before a session starts, a sender using the ALC protocol MUST make=0A=
available all applicable information regarding the session. This=0A=
information includes:=0A=
=0A=
o Any information needed by the LCT transport;=0A=
=0A=
o The congestion control protocol being used within the LCT transport;=0A=
=0A=
o The mapping between values of the Codepoint field in the LCT packet=0A=
header and interpretations of these values;=0A=
=0A=
o Any information needed for the FEC building block;=0A=
=0A=
o If used, the authentication scheme being used within the LCT=0A=
transport, and all relevant information which is necessary for=0A=
sender authentication purposes;=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
Luby/Gemmell/Vicisano/Rizzo/Crowcroft Section 4.1. [Page 9]=0A=
=0C=0A=
INTERNET-DRAFT Expires: January 2002 July 2001=0A=
=0A=
=0A=
4.2. Receiver Operation=0A=
=0A=
The receiver operation when using the ALC protocol includes all the=0A=
points made about the receiver operation that pertain to reliable=0A=
content delivery when using the LCT transport as described in [3], and=0A=
that pertain to using the FEC building block as described in [2]. The=0A=
following description highlights some of the additional considerations=0A=
to be taken into account with respect to the ALC protocol.=0A=
=0A=
When a receiver receives a packet, the receiver MUST process the LCT=0A=
packet header (excluding the Codepoint field) as described in [3]=0A=
before processing any other fields of the packet.=0A=
=0A=
=0A=
5. Security Considerations=0A=
=0A=
The same security consideration that apply to the LCT transport and to=0A=
the FEC building block also apply to the ALC protocol. In addition, any=0A=
security considerations that apply to the congestion control protocol=0A=
used by the ALC protocol within the LCT transport also apply.=0A=
=0A=
=0A=
6. IANA Considerations=0A=
=0A=
No information in this specification is directly subject to IANA=0A=
registration. However, building blocks components used by the ALC=0A=
protcol may introduce additional IANA considerations. In particular,=0A=
the FEC building block used by the ALC protocol does require IANA=0A=
registration of the FEC codecs used.=0A=
=0A=
=0A=
7. Intellectual Property Issues=0A=
=0A=
=0A=
No specific reliability protocol or congestion control protocol is=0A=
specified or referenced as mandatory in this document.=0A=
=0A=
ALC MAY be used with congestion control protocols and other protocols=0A=
which are proprietary, or have pending or granted patents.=0A=
=0A=
=0A=
=0A=
[1] Luby, M., Gemmell, Vicisano, L., J., Rizzo, L., Handley, M.,=0A=
Crowcroft, J., "The use of Forward Error Correction in Reliable=0A=
Multicast", Internet Draft draft-ietf-rmt-info-fec-00.txt, November=0A=
2000, a work in progress.=0A=
=0A=
[2] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., Handley, M.,=0A=
=0A=
=0A=
=0A=
Luby/Gemmell/Vicisano/Rizzo/Crowcroft Section 7. [Page 10]=0A=
=0C=0A=
INTERNET-DRAFT Expires: January 2002 July 2001=0A=
=0A=
=0A=
Crowcroft, J., "RMT BB Forward Error Correction Codes", Internet Draft=0A=
draft-ietf-rmt-bb-fec-03.txt, July 2001.=0A=
=0A=
[3] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., Handley, M.,=0A=
Crowcroft, J., "Layered Coding Transport: A massively scalable content=0A=
delivery transport", Internet Draft draft-ietf-rmt-bb-lct-01.txt, July=0A=
2001.=0A=
=0A=
[4] Luby, M., Vicisano, L., Haken, A., "RMT BB Layered congestion=0A=
control", draft-ietf-rmt-bb-lcc-00.txt, November 2000, a work in=0A=
progress.=0A=
=0A=
[5] Perrig, A., Canetti, R., Briscoe, B., Tygar, D., Song, D., "TESLA:=0A=
Multicast Source Authentication Transform", draft-irtf-smug-=0A=
tesla-00.txt, November, 2000, a work in progress.=0A=
=0A=
=0A=
=0A=
8. Authors' Addresses=0A=
=0A=
Michael Luby=0A=
luby@digitalfountain.com=0A=
Digital Fountain=0A=
39141 Civic Center Drive=0A=
Suite 300=0A=
Fremont, CA, USA, 94538=0A=
=0A=
Jim Gemmell=0A=
jgemmell@microsoft.com=0A=
Microsoft Research=0A=
301 Howard St., #830=0A=
San Francisco, CA, USA, 94105=0A=
=0A=
Lorenzo Vicisano=0A=
lorenzo@cisco.com=0A=
cisco Systems, Inc.=0A=
170 West Tasman Dr.,=0A=
San Jose, CA, USA, 95134=0A=
=0A=
Luigi Rizzo=0A=
luigi@iet.unipi.it=0A=
Dip. Ing. dell'Informazione,=0A=
Univ. di Pisa=0A=
via Diotisalvi 2, 56126 Pisa, Italy=0A=
=0A=
Jon Crowcroft=0A=
J.Crowcroft@cs.ucl.ac.uk=0A=
Department of Computer Science=0A=
=0A=
=0A=
=0A=
Luby/Gemmell/Vicisano/Rizzo/Crowcroft Section 8. [Page 11]=0A=
=0C=0A=
INTERNET-DRAFT Expires: January 2002 July 2001=0A=
=0A=
=0A=
University College London=0A=
Gower Street,=0A=
London WC1E 6BT, UK=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
Luby/Gemmell/Vicisano/Rizzo/Crowcroft Section 8. [Page 12]=0A=
=0C=0A=
INTERNET-DRAFT Expires: January 2002 July 2001=0A=
=0A=
=0A=
9. Full Copyright Statement=0A=
=0A=
Copyright (C) The Internet Society (2000). All Rights Reserved.=0A=
=0A=
This document and translations of it may be copied and furnished to=0A=
others, and derivative works that comment on or otherwise explain it or=0A=
assist in its implementation may be prepared, copied, published and=0A=
distributed, in whole or in part, without restriction of any kind,=0A=
provided that the above copyright notice and this paragraph are included=0A=
on all such copies and derivative works. However, this document itself=0A=
may not be modified in any way, such as by removing the copyright notice=0A=
or references to the Internet Society or other Internet organizations,=0A=
except as needed for the purpose of developing Internet standards in=0A=
which case the procedures for copyrights defined in the Internet=0A=
languages other than English.=0A=
=0A=
The limited permissions granted above are perpetual and will not be=0A=
revoked by the Internet Society or its successors or assigns.=0A=
=0A=
This document and the information contained herein is provided on an "AS=0A=
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK=0A=
FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT=0A=
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT=0A=
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR=0A=
FITNESS FOR A PARTICULAR PURPOSE."=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
Luby/Gemmell/Vicisano/Rizzo/Crowcroft Section 9. [Page 13]=0A=
=0C=0A=
INTERNET-DRAFT Expires: January 2002 July 2001=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
Luby/Gemmell/Vicisano/Rizzo/Crowcroft Section 9. [Page 14]=0A=
------=_NextPart_000_0002_01C11115.E3203A10
Content-Type: application/pdf;
name="submitted draft-ietf-rmt-bb-alc-02-mgl-7-20-2001.pdf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="submitted draft-ietf-rmt-bb-alc-02-mgl-7-20-2001.pdf"
JVBERi0xLjMNJeLjz9MNCjUwIDAgb2JqDTw8IA0vTGluZWFyaXplZCAxIA0vTyA1MiANL0ggWyA3
NTQgMjcxIF0gDS9MIDMyNDgyIA0vRSAxMDQ2OSANL04gMTEgDS9UIDMxMzY0IA0+PiANZW5kb2Jq
DSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICB4cmVmDTUwIDE2IA0wMDAwMDAwMDE2IDAwMDAwIG4NCjAwMDAwMDA2NjcgMDAwMDAgbg0KMDAw
MDAwMTAyNSAwMDAwMCBuDQowMDAwMDAxMTc5IDAwMDAwIG4NCjAwMDAwMDEzMDQgMDAwMDAgbg0K
MDAwMDAwMjA5NCAwMDAwMCBuDQowMDAwMDAyNDY1IDAwMDAwIG4NCjAwMDAwMDM5MzAgMDAwMDAg
bg0KMDAwMDAwNTA1NiAwMDAwMCBuDQowMDAwMDA1MjYxIDAwMDAwIG4NCjAwMDAwMDU0NjIgMDAw
MDAgbg0KMDAwMDAwNTY2MSAwMDAwMCBuDQowMDAwMDA2NzE5IDAwMDAwIG4NCjAwMDAwMDY4NTgg
MDAwMDAgbg0KMDAwMDAwMDc1NCAwMDAwMCBuDQowMDAwMDAxMDA0IDAwMDAwIG4NCnRyYWlsZXIN
PDwNL1NpemUgNjYNL0luZm8gNDkgMCBSIA0vUm9vdCA1MSAwIFIgDS9QcmV2IDMxMzU0IA0vSURb
PGJhMWYzZGJmNzc2MGIxODBlZjRkNTllNWVlYmU4M2NlPjxiYTFmM2RiZjc3NjBiMTgwZWY0ZDU5
ZTVlZWJlODNjZT5dDT4+DXN0YXJ0eHJlZg0wDSUlRU9GDSAgICAgDTUxIDAgb2JqDTw8IA0vVHlw
ZSAvQ2F0YWxvZyANL1BhZ2VzIDM3IDAgUiANL0pUIDQ4IDAgUiANL1BhZ2VMYWJlbHMgMzUgMCBS
IA0+PiANZW5kb2JqDTY0IDAgb2JqDTw8IC9TIDE1NiAvTCAyMDUgL0ZpbHRlciAvRmxhdGVEZWNv
ZGUgL0xlbmd0aCA2NSAwIFIgPj4gDXN0cmVhbQ0KSIliYGBgZmBg+sTAAiR1GfgYEIAPKAaCHBPA
3I4G9YVXXatEXrgYqrpEs0rYf2BgmJaWmebmAJJlb522HIaWRVSeXVcRmQVE7VFggkFQUKKBgQEZ
CXYwMEowMHAAIYjAZjoQyDMwJP8B0jxAzA8WqWXgYbzAoDnhW/Dhl6wMPiyLlzK8Zdd0ZD2kAJZW
YmAo1QPSTEDsDRBgAGy1L/QNZW5kc3RyZWFtDWVuZG9iag02NSAwIG9iag0xNTggDWVuZG9iag01
MiAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgMzYgMCBSIA0vUmVzb3VyY2VzIDUzIDAg
UiANL0NvbnRlbnRzIDU2IDAgUiANL01lZGlhQm94IFsgMCAwIDYxMiA3OTIgXSANL0Nyb3BCb3gg
WyAwIDAgNjEyIDc5MiBdIA0vUm90YXRlIDAgDT4+IA1lbmRvYmoNNTMgMCBvYmoNPDwgDS9Qcm9j
U2V0IFsgL1BERiAvVGV4dCBdIA0vRm9udCA8PCAvRjIgNTcgMCBSIC9GMyA2MSAwIFIgL0Y0IDU0
IDAgUiA+PiANL0V4dEdTdGF0ZSA8PCAvR1MxIDYyIDAgUiA+PiANPj4gDWVuZG9iag01NCAwIG9i
ag08PCANL1R5cGUgL0ZvbnQgDS9TdWJ0eXBlIC9UeXBlMSANL0ZpcnN0Q2hhciAzMiANL0xhc3RD
aGFyIDE4MSANL1dpZHRocyBbIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYw
MCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgDTYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYw
MCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCANNjAwIDYwMCA2MDAgNjAwIDYw
MCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIA02MDAgNjAwIDYw
MCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgDTYw
MCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAw
IDYwMCANNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAw
IDYwMCA2MDAgNjAwIA02MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAw
IDYwMCA2MDAgNjAwIDYwMCA2MDAgDTYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAw
IDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCANNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAw
IDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIA02MDAgNjAwIDYwMCA2MDAgNjAw
IF0gDS9FbmNvZGluZyAvV2luQW5zaUVuY29kaW5nIA0vQmFzZUZvbnQgL0RFSUFMRytDb3VyaWVy
LUJvbGQgDS9Gb250RGVzY3JpcHRvciA1NSAwIFIgDT4+IA1lbmRvYmoNNTUgMCBvYmoNPDwgDS9U
eXBlIC9Gb250RGVzY3JpcHRvciANL0FzY2VudCA2MjYgDS9DYXBIZWlnaHQgNTYyIA0vRGVzY2Vu
dCAtMTQyIA0vRmxhZ3MgMjYyMTc5IA0vRm9udEJCb3ggWyAtMTEzIC0yNTAgNzQ5IDgwMSBdIA0v
Rm9udE5hbWUgL0RFSUFMRytDb3VyaWVyLUJvbGQgDS9JdGFsaWNBbmdsZSAwIA0vU3RlbVYgMTA2
IA0vWEhlaWdodCA0MzkgDS9DaGFyU2V0ICgvbi9sL3AvZS9OL0cvRS9oeXBoZW4vei9mL1UvSS9w
ZXJpb2Qvci9zcGFjZS9WL0ovUC9zL3NsYXNoL2kvRi9XL2EvTC90L3pcDWVyby9NL3Uvb25lL1Qv
ay9BL3YvZy9tL3R3by9iL2NvbG9uL0Mvdy94L28vYy9SL0QvZC95KQ0vRm9udEZpbGUzIDYzIDAg
UiANPj4gDWVuZG9iag01NiAwIG9iag08PCAvTGVuZ3RoIDEzOTAgL0ZpbHRlciAvRmxhdGVEZWNv
ZGUgPj4gDXN0cmVhbQ0KSImMVlFv4jgQfudXjO4pOTUmCU2BfboeLVWrdrVqs7s6sX0wiQHfJjGy
nVL2Z9wvvhk7gXbbW52QwCTjmW+++WbsP/PBcH4KCeSrQRIDffBnnMI4HkNeD2JYD4ZXDwmsDa7z
gr52g0Vw3VihG2HhslnLRggtmzXk3HyHudKFCKM0nk6nbBrc3+Xw9Sp8zG9wa5SwEeQXgzRmI3zd
ufqYX95/vMyji/vzeQ537LZd7ocXci0tr8LoLI6DuWoby2Xj3OS/D5JTNu32B6XmKxtJYVeRrm20
lRGviihO2dbADbsSdS2qangnC62MWtkw/3swGrGMtvdwXE7BLfsiC2l4o4YzaQpFltGYpQcztLiX
P36o4fns+v4aeFPC50Y+MfiEu8j6lfENg5lWOwy7ssPPs1sySNnp0SCN4aat9pDGceJiZS/fXj5v
pRbmA9zwpuXamaVkNpyPunKd+nJh9aYjFo8mkE0TqtkiODf7ptjoMJkEqlGtgVu+D5M4EO6RKGGm
SizYB8dndMrGZ0kGUcym6eSMoqMHrGAWBzU3RtLOJ7cd0ZqCV3xZCfCuKol/9lAo1ENjocQHR3NE
vfUgrCpU5aIliUedkMiy0YgABw+WW0SpVmA30sCFKtoa3fl0U5+uU08WU4oEMCfDsjMEXPMGelFG
F6QJVyB8IRtYtVVFGFdK17wpBOyk3QDHh1utwiQLnqSRqnEIHkRhcU1toFZH3SaTZOIKcz+fpXF6
xggcvknZ6GzUkfY6PkLSGImYUPo79UcPt8tUwPtdFE7iwHUSIaNugm/B9WU+/xaegPRuuTl5C20R
uIzR4mXQtVbt1rAwyrCRPiorMDK3oDC+7l5CzffIhlFQSmO1XIZpHLT2v8Bz0/fhzxn/X1KewjQL
eCVLwIoAx/jPsm5rosXIZ6hRTRvj6nd3jhCy4C8vx2WIqvLLdltyK8oT0GJb8YJWSr/HiVoaVQk0
heW+y/pFKqQSonnvvVpZCwZ+fW39r5MQ36JStlpy4k9BawS8ScwglpXQAgXWE7TADkIryStERxsL
6Qog6g4K1qKhnRx+68kmwWKwNXa/+Y31Kb2kNEfpVFgp4qtotaYO+BlNgX6XAnhRoBtMHjPdWLv9
MBzudrvwLAsYjUymXH+uh/RnmMgy4ktUAC+wlvbZHtNwolT0hezg95MUVMNdR1sP6KcOfNjwUr2w
u8CRVlilpTAnYIT4JSRz3EzvNrau2AtAb/qfSCvbwh6aC1sG/PHTqX+mal92s1FtVTp+ylJ7grA4
uOvdrmrtRmlz4kqIjr9e/RNmWWD6ESkr6g+XP7KMh9Af1bJiaz9YHHbn9Ti4x2w8ziZU02k3z4Lz
jvZXIy9KMpx4o4Qs4+w0e2/ylcIU2LHCOGjd4D8MfVRjP+yJHjeGT1zD0VxPCR+CxLn+Xt7HUe/H
vHg95g+73ZjvfaOoBZYepe2aQXtmUeHnt7OuDLjq5HksZ0sloGFQt5WVkaY+O4R9E45030FB5xX3
ihEoKT9bUWXi5Q7T9zSG7saH8YwdJtntLAesQGO2Sh9ZLakZF6NH4O2a6MYH/uig+Gth3ElBULSq
DiT4ASsN1ZJcF6reYiYI1u2lA2Q0GYNpiw0RoxrRS7bqKvYL573XRXDEuDh9ZMQvdvvG96XPG6dl
J1JPJQrV7mHJiWt0Pb/EOqhSFG52rUUjNB6J+1fJHyu0SB5P/JGK44lrK4sWiT96I/ylwFtaZY6n
aukZpHcUzR8ssnJ6XFaq+H7g/zXj6aM7SlD36TgdoyxTNu5aJZmwSTId+7ujuyr2d7wv4RlO6+4K
529qeANzE8TdwmDxiVBxFArqBZ2wcZA8OgSX+eDfAQAU81mcCmVuZHN0cmVhbQ1lbmRvYmoNNTcg
MCBvYmoNPDwgDS9UeXBlIC9Gb250IA0vU3VidHlwZSAvVHlwZTEgDS9GaXJzdENoYXIgMTkgDS9M
YXN0Q2hhciAyNTUgDS9XaWR0aHMgWyA2MTEgMjc4IDU2NCAxNjcgMzMzIDMzMyAyNzggMzMzIDMz
MyAzMzMgMzMzIDU1NiA1NTYgMjUwIDMzMyA0MDggNTAwIA01MDAgODMzIDc3OCAxODAgMzMzIDMz
MyA1MDAgNTY0IDI1MCAzMzMgMjUwIDI3OCA1MDAgNTAwIDUwMCA1MDAgDTUwMCA1MDAgNTAwIDUw
MCA1MDAgNTAwIDI3OCAyNzggNTY0IDU2NCA1NjQgNDQ0IDkyMSA3MjIgNjY3IDY2NyANNzIyIDYx
MSA1NTYgNzIyIDcyMiAzMzMgMzg5IDcyMiA2MTEgODg5IDcyMiA3MjIgNTU2IDcyMiA2NjcgNTU2
IA02MTEgNzIyIDcyMiA5NDQgNzIyIDcyMiA2MTEgMzMzIDI3OCAzMzMgNDY5IDUwMCAzMzMgNDQ0
IDUwMCA0NDQgDTUwMCA0NDQgMzMzIDUwMCA1MDAgMjc4IDI3OCA1MDAgMjc4IDc3OCA1MDAgNTAw
IDUwMCA1MDAgMzMzIDM4OSANMjc4IDUwMCA1MDAgNzIyIDUwMCA1MDAgNDQ0IDQ4MCAyMDAgNDgw
IDU0MSAzNTAgMCAzNTAgMzMzIDUwMCA0NDQgDTEwMDAgNTAwIDUwMCAzMzMgMTAwMCA1NTYgMzMz
IDg4OSAzNTAgNjExIDM1MCAzNTAgMzMzIDMzMyA0NDQgNDQ0IA0zNTAgNTAwIDEwMDAgMzMzIDk4
MCAzODkgMzMzIDcyMiAzNTAgNDQ0IDcyMiAyNTAgMzMzIDUwMCA1MDAgNTAwIA01MDAgMjAwIDUw
MCAzMzMgNzYwIDI3NiA1MDAgNTY0IDMzMyA3NjAgMzMzIDQwMCA1NjQgMzAwIDMwMCAzMzMgDTUw
MCA0NTMgMjUwIDMzMyAzMDAgMzEwIDUwMCA3NTAgNzUwIDc1MCA0NDQgNzIyIDcyMiA3MjIgNzIy
IDcyMiANNzIyIDg4OSA2NjcgNjExIDYxMSA2MTEgNjExIDMzMyAzMzMgMzMzIDMzMyA3MjIgNzIy
IDcyMiA3MjIgNzIyIA03MjIgNzIyIDU2NCA3MjIgNzIyIDcyMiA3MjIgNzIyIDcyMiA1NTYgNTAw
IDQ0NCA0NDQgNDQ0IDQ0NCA0NDQgDTQ0NCA2NjcgNDQ0IDQ0NCA0NDQgNDQ0IDQ0NCAyNzggMjc4
IDI3OCAyNzggNTAwIDUwMCA1MDAgNTAwIDUwMCANNTAwIDUwMCA1NjQgNTAwIDUwMCA1MDAgNTAw
IDUwMCA1MDAgNTAwIDUwMCBdIA0vRW5jb2RpbmcgNjAgMCBSIA0vQmFzZUZvbnQgL1RpbWVzLVJv
bWFuIA0vRm9udERlc2NyaXB0b3IgNTkgMCBSIA0+PiANZW5kb2JqDTU4IDAgb2JqDTw8IA0vVHlw
ZSAvRm9udERlc2NyaXB0b3IgDS9Bc2NlbnQgNjk5IA0vQ2FwSGVpZ2h0IDY3NiANL0Rlc2NlbnQg
LTIwNSANL0ZsYWdzIDI2MjE3OCANL0ZvbnRCQm94IFsgLTE2OCAtMjE4IDEwMDAgOTM1IF0gDS9G
b250TmFtZSAvVGltZXMtQm9sZCANL0l0YWxpY0FuZ2xlIDAgDS9TdGVtViAxMzkgDS9YSGVpZ2h0
IDQ2MSANPj4gDWVuZG9iag01OSAwIG9iag08PCANL1R5cGUgL0ZvbnREZXNjcmlwdG9yIA0vQXNj
ZW50IDY5OSANL0NhcEhlaWdodCA2NjIgDS9EZXNjZW50IC0yMTcgDS9GbGFncyAzNCANL0ZvbnRC
Qm94IFsgLTE2OCAtMjE4IDEwMDAgODk4IF0gDS9Gb250TmFtZSAvVGltZXMtUm9tYW4gDS9JdGFs
aWNBbmdsZSAwIA0vU3RlbVYgODQgDS9YSGVpZ2h0IDQ1MCANPj4gDWVuZG9iag02MCAwIG9iag08
PCANL1R5cGUgL0VuY29kaW5nIA0vQmFzZUVuY29kaW5nIC9XaW5BbnNpRW5jb2RpbmcgDS9EaWZm
ZXJlbmNlcyBbIDE5IC9Mc2xhc2ggL2xzbGFzaCAvbWludXMgL2ZyYWN0aW9uIC9icmV2ZSAvY2Fy
b24gL2RvdGxlc3NpIC9kb3RhY2NlbnQgDS9odW5nYXJ1bWxhdXQgL29nb25layAvcmluZyAvZmkg
L2ZsIF0gDT4+IA1lbmRvYmoNNjEgMCBvYmoNPDwgDS9UeXBlIC9Gb250IA0vU3VidHlwZSAvVHlw
ZTEgDS9GaXJzdENoYXIgMzIgDS9MYXN0Q2hhciAyNTUgDS9XaWR0aHMgWyAyNTAgMzMzIDU1NSA1
MDAgNTAwIDEwMDAgODMzIDI3OCAzMzMgMzMzIDUwMCA1NzAgMjUwIDMzMyAyNTAgMjc4IA01MDAg
NTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgMzMzIDMzMyA1NzAgNTcwIDU3MCA1
MDAgDTkzMCA3MjIgNjY3IDcyMiA3MjIgNjY3IDYxMSA3NzggNzc4IDM4OSA1MDAgNzc4IDY2NyA5
NDQgNzIyIDc3OCANNjExIDc3OCA3MjIgNTU2IDY2NyA3MjIgNzIyIDEwMDAgNzIyIDcyMiA2Njcg
MzMzIDI3OCAzMzMgNTgxIDUwMCANMzMzIDUwMCA1NTYgNDQ0IDU1NiA0NDQgMzMzIDUwMCA1NTYg
Mjc4IDMzMyA1NTYgMjc4IDgzMyA1NTYgNTAwIA01NTYgNTU2IDQ0NCAzODkgMzMzIDU1NiA1MDAg
NzIyIDUwMCA1MDAgNDQ0IDM5NCAyMjAgMzk0IDUyMCAwIDcyMiANNzIyIDcyMiA2NjcgNzIyIDc3
OCA3MjIgNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgNDQ0IDQ0NCA0NDQgNDQ0IA00NDQgMjc4IDI3
OCAyNzggMjc4IDU1NiA1MDAgNTAwIDUwMCA1MDAgNTAwIDU1NiA1NTYgNTU2IDU1NiA1MDAgDTQw
MCA1MDAgNTAwIDUwMCAzNTAgNTQwIDU1NiA3NDcgNzQ3IDEwMDAgMzMzIDMzMyAwIDEwMDAgNzc4
IDAgNTcwIA0wIDAgNTAwIDU1NiAwIDAgMCAwIDAgMzAwIDMzMCAwIDcyMiA1MDAgNTAwIDMzMyA1
NzAgMCA1MDAgMCAwIDUwMCANNTAwIDEwMDAgMjUwIDcyMiA3MjIgNzc4IDEwMDAgNzIyIDUwMCAx
MDAwIDUwMCA1MDAgMzMzIDMzMyA1NzAgMCANNTAwIDcyMiAxNjcgNTAwIDMzMyAzMzMgNTU2IDU1
NiA1MDAgMjUwIDMzMyA1MDAgMTAwMCA3MjIgNjY3IDcyMiANNjY3IDY2NyAzODkgMzg5IDM4OSAz
ODkgNzc4IDc3OCAwIDc3OCA3MjIgNzIyIDcyMiAyNzggMzMzIDMzMyAzMzMgDTMzMyAzMzMgMzMz
IDMzMyAzMzMgMzMzIDMzMyBdIA0vRW5jb2RpbmcgL01hY1JvbWFuRW5jb2RpbmcgDS9CYXNlRm9u
dCAvVGltZXMtQm9sZCANL0ZvbnREZXNjcmlwdG9yIDU4IDAgUiANPj4gDWVuZG9iag02MiAwIG9i
ag08PCANL1R5cGUgL0V4dEdTdGF0ZSANL1NBIGZhbHNlIA0vU00gMC4wMiANL09QIGZhbHNlIA0v
b3AgZmFsc2UgDS9PUE0gMSANL0JHMiAvRGVmYXVsdCANL1VDUjIgL0RlZmF1bHQgDS9UUjIgL0Rl
ZmF1bHQgDT4+IA1lbmRvYmoNNjMgMCBvYmoNPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0
aCAzMzY4IC9TdWJ0eXBlIC9UeXBlMUMgPj4gDXN0cmVhbQ0KSIlkVAtUE2cWniGZGR4hVmJizWgS
WVdaxSGKVZCHgLo21sfyKOJZX8gziIAEFRSkiq0iAvXVWqCCiqj44iXiiiK6iOsLRVHQrmt1ZX7t
6bJ60Dv2T9v9k9Lu2dMzOffkvzP3u/d+97s/TckdKJqmh0yfYQqePXPstNRV6ea49HEhqcmxNn+Q
xFPScFoa4SDpZNIQ+TYFjTMUshaFXNIrNJjBRW83vD3F6CronwsKfrEKDgoHQdPgi8OV+9wohqYd
07Lzio3GiYLRaJyWmpaVbk5IzDC8F/O+Ybyvj68nsb5Gux1vt952O8luJ9utjyE4NnVZnCE8y5IR
t8JiMKXEpKanpaZHZ8TFCgZDcHKyIcyGaTGExVni0lcT70AfBlsfA///rzWKJg+lZCieotwpapSc
GkNT4xyo8RTlTVEfyKgQlppFUbMZKtyRGk8oohwoGTWUmkTNpb6gTtNy2o/+hL7poHVY7HBQ5ibz
lmXL9su+k7vL18q7GWcmgtnK3GJNbBXbx4Vx1ZzkaHb80vGZk8wp1emCM+Mc69zgEuSy1qXN5QfF
R4pKxQvXoUolhIk0jIQ7MmkphKlFfMeLU+aCLw3LIFQm6W+r65afnhMaHx29sjLiTkt9TZNOiYe9
vU3flRbKpINvPdT+NVbXH4/1xDPKXFGaLdL/FiGtVyZthRb16yyIwSa8YBPOC5pYgi0wDz7eCRu6
dMYtar8cPHycRy4M69ZVcm2F28HjJf+6GE8J1SsLEA3liKBrEA6Q9nK4JJIxchBwnLEacbDAKQue
S4GI7hUh4alMWq2Bid4mHMKBEuRMd+fV5j7toS2Hcg/oWtPmXfDkAz9MmrtA7y3u5W6g4u1trYmm
mMykqMU6/Dm2MAH2Zh//r1+4+/uGcZH89yQUoA4EqxBdDBvBFXJkEtKgcA5HSRYGfyrAIBZPtmqY
PwuwEX3AHu5gIJs9PJPxEdgy2KHGRrYH5tgZM/bSLQgeijLpWrc6vINZtXz6Uj8eayJf9cM4cDjf
2XJ+TVqj3lOEHK9obvf6qKM+PJ6AOfwODsTcdTwXkurAtfzWfRtvkgbR/SJUEbR2OKd+kdTv2awr
j128fQmPjwsPrBp/AXaz8B682wFZeq/N6pmZ00LjdavNcflLeV9JAwwLTqcn/9GG9e2Rk+L+xvvI
DVTia1SPVH3SWQ3ECdgR54HnaxPiVD9DhsCp+kwjwR3yyBG7IEi05gvdtkRkTAjGoMqGbgKhE9+I
J5Hqkeon6SL8qIYE60ahy6oJEqAR4UGc6hGMeTNL5FQ/QYYXOZkM8AfIJUfsTAZE0oO5163hOdzs
9UGqfukfMFeNcDXJLYH7BNacx2xKSclfwUdEftUYp0+qXd96QQuGJ7dFnaq//fjqFc16LwTrhUVc
ZWxixQwee2IFdsWzcSiMGA1j9CpJ7GvcWa4HD26AQ9j5QibtIvKbRDiZhKxTBPC1arAvaSq3VxqF
6IsIsojIv5UsamR9V4DpuJr7cHPEhKzMwuK1utA9loo2LVACXsutO9IX1cdXVRXt2q8v3MZ01Rxp
6tfC6d8yjRZhDdH6RQ3sE/B0vIYkVCDcLrywajyFX7/qQnCCzFSypcPzOUzh2lFQy+C/CPfYdURm
EQJsRp5sKdz5D65l2tl+OFGCbzGCTX2RbI6kYQaAnomwgwC9tAOVCAj/jcObpZEMninct2qmCvA1
GgMdLHxh9WSeShaWhL1EEE7q1IuQTiJPSYPUZ9c3JZ/UNS+dXmLi8R6hxy6rMwgrX4ITCy4937zS
exWpF6WnZ27U5axILDDz/hD+jK2s3vLJAf3R7PLlCVqbNrQIvAnwYJEMVybd06AgDnPgWfcl01J6
qr1Te3nlpcgjuvLEJUXLeFwp3LOnyUfBoO1mn2LlgaR98aWJw3IkcgX5b16iGw/e8A5beW1LyK+b
UI9AafsN8SHb8EYNKdZynIJgMCjJLBUCPEHYldCtxIPJWJHkjujvRdhEmnwxQM9zXMZNzFjogem8
axd0cFy0OXtwJTdtx59uLdGlnGn47Czf2LC7rFZ/7XBVV4cWznDKitWSBdFbYSvQUCCTvrdjFQjP
ODwc/4AN8APTjfBWoYuFeVYLg1gwkStjICofsmAsZMqkV/aoTAFxZlwzGg4wJtYDH0yEOobUkCX8
lb1GYh+wwEArcLiV6WGv21By0RT0SryJ3NpEKHimypauaFAgTOFqCuqzj+oexmN5wRo+JCg97SP9
ST9m38W2ssv8ga78efpcrtgcW5TI4/SNeESmXtU8q90f5KfPfVV2SKfKLjiyt2SXbiGnaoYJ8qWL
wsyz+JjYr482d5Wev1Tzaf5hPdlRPwQl6CFyeyrCMaTKVjVL5yBVDU5jQY6Hz49aa47TQQaeKjzg
VNnWmQECBBK4Wi6t5mRGJw+Gf4EjcHphmzpwzuwp0e8fBIe7p2709TVMWqAj4HBYpC+LUEF0Uv+N
en4nExMxf/lU3j+gSXxwpb2vtnZDdrXevxeijJncHnPC9ngeB/uRFaexByh8wFV8XNd6Q2+n55cq
mxDUiISfJxo0VarECQK4YDV3LP7j0kgejxiLHbArIQEP6hsJI1rOlx6tIywkcPmQrCZeF0yvSwqc
1d7Tc7Xt0flLK5aVkbe71nxusWhJrd+hx4i+jqCJCOnSFXX0fSZ57oyVITx2Xv7345/ppcHstt2F
Jyq0oHR/hN3IRT40AAvY+Z+YBp8nT6tPdeoMEKvG9Wxb+dWqNv5Se3bEQZuioVD8b5FlH9PUFYZx
0d1e1A1njyXAnS1uZiqTy/yIQyhiQGEKDhzTjS/riuCU8qkoAk6rY2GBAmr5KKLIR1CBSd3QMjdx
i5nZdGpxIGVB45R4TwlEnTPvTV7+2Gk1WXL+Ped9z3mf5/ecMal8rxLSJEKJQ+6Wn6gIDa/lqnIM
lQZBt/VwwU7N1uyyxES/nMVBY2haLMq+FLeACbZIuOUcf97UfMfWazx8gSV4rPMpZWwIocpOJ1gf
k3H5LowxxWl5MmLgz2Yk1ScK+M7CAPTCWROBMO9yn+Xsec02Pr4sBfmIoNbadHVBIFd4/07xoAAb
Tk3AFA0ZhwG2+33kVeEJKSsi1/TdHbjZNzxyLVnrSkuooNdgkQfU0Gnwj2xUwaJ5uIiHlkkjKxsM
Ttwvgj9WYOjL4DBRymJjtmQHM+rgKwb9IW/6Lq+/rB3Ud8Gbkg+Rn1I0iycVyz7igDXO+BXN4iQU
onjyb1fLd5kXMr7d5psnuhAmRzPOmBll6xjSQ9i8q0RYOhnt5rm7s1Cq/F2Cqa415y0yIqM3/Rhy
mEAHk34L0ev3ZeWpe/Iyju4WDFkHdjN7jDRjmOjAilUilNMwly8K+cYTLcdbBesxw14NXoXFNA5y
+c7WdnOj0GXOMWrQ/qqWVlI+kyBTYiMcYMyDHTzp7TCeKWlTXzAkWz4VNiXsy9VriKPTZZb/S/RC
Gn/xpxt1Z4RbRwzbNPhJuCuMKLRTD5sTHOxyVyBbBdxKmI6r0RuJFgMxDALjGYZ48LsNK9SiSRUQ
+nlYvD9z14M7P4/CzN7VcUwMMXRYgnqqpUoWD8wW4yyj81RkBJagnz1g86aizHQ1GT+HqxjqI1hG
XKf4NszhS5qufOEQwGfsOajYkwR9owqOTojQzW+H11jFKU3fD95MXv5q9OxsWEuJXb4JD1XEerK0
sfS4uu1QljVKiIrTpSVqiL0fU0WYghX+oqykuB6W8cTafbb7dE+LZ21Ta22z0FZlzK90mViE+AmI
EKnyoaR9BAXS2lHSQGrkU+CjGkiwxVSrcXYNt8v04RGrX8+D6mY1aeixHSru0pCOBPbFqIWIoN28
ZXuqWScsX5C+EN8Af2N/qYZYusts1R1FnrWllcaDfjtiizavSzpuzleTpH72J2nAeOkMX3Sx70Cf
QGpg2ujVRy7sgYVJawl7fduPqmKJK96+QLdeWP217aIGIpjB8BD4iugbK17Hz3ic+2xv/5Cj8/Qf
jGmPta53UT55DDskUij3u0DtdMmYjRpTecPOjKw4IbTslxYNdDCxDWMMn15VcKRIva5lKPe6cLn3
RJtVQwoNrsABJ/Wog/IJKJ4mPwAnM1Sx+CvPIFaAU6GAu+HKn3sKCEcnN6SAEHCy7wAsxblsY+su
qiyFdEgFHUmRn7s360Q7T7o2YsxKSONiFeGYxpGUeIjhblNMZ9kDHu6D/oTke5jMDSpeuA90X+cE
lGA27LkPmZgGJcRBBuRhbxrKM8H4ccQBM0DB/UUxU2xUbEzYcJVrorjH1ZoXenJklCWkD7dShBKa
rXAMDYdzucy+TJ5yJFUehXwmio4fIJtQ+W93n9mijcdZqGeX1HOXKOaLAwpYjpeCcS6rhVNF6KDr
FWCWI7mX/PR4IYGBYbnSG9YEBWMUww+0c7cm52OINAgf8NiMrdwa3uvLetlehwEWCKyrbmAHHJtM
qOD3W2R7Pb5ngYencG25Jxw8+rR8sts0nc6gMyte95LH5/wHHaJ4cAplbmRzdHJlYW0NZW5kb2Jq
DTEgMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDM2IDAgUiANL1Jlc291cmNlcyAyIDAg
UiANL0NvbnRlbnRzIDMgMCBSIA0vTWVkaWFCb3ggWyAwIDAgNjEyIDc5MiBdIA0vQ3JvcEJveCBb
IDAgMCA2MTIgNzkyIF0gDS9Sb3RhdGUgMCANPj4gDWVuZG9iag0yIDAgb2JqDTw8IA0vUHJvY1Nl
dCBbIC9QREYgL1RleHQgXSANL0ZvbnQgPDwgL0YyIDU3IDAgUiAvRjMgNjEgMCBSID4+IA0vRXh0
R1N0YXRlIDw8IC9HUzEgNjIgMCBSID4+IA0+PiANZW5kb2JqDTMgMCBvYmoNPDwgL0xlbmd0aCA4
NTQgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSImUls1ym0gUhfd6iNRdNguh/qFp
mJ1iyy67Us6UTc1GlQWGtkQGgaYBJ8pj5InnNuDEEgjHVpWlsrt1vj733Nt8jGaLKw4MoqcZY0Dx
hW+Kg/IERLsZhc1scf3AYFPh5yixv77N1uTmLlrd360iJ+Rkfnm/vIrAmfuSKjckq+/7zOjqL2fO
JSW3cdHE5gCcUu7MGeOecgNy2+Ttn5jzJbpFBNEjiA5BABehy7gPiirLsSatVPyYayif4KIsal3U
Vb/75QC0200hVOD7od1ImAs3RW3KtEnqrCyc6OurgzKfvixk9nTEHf1pN/36ck95L5taS4iw/58L
31UwZy6H6NLKovC9zuNap3BZJs2u5T1S50yCL9WU+ohyt6FT9obKa5TmLqwKx6PkOTNlYZXjHGH+
a7AuLQfERWpNrLJUm9j60ln5m01wZPPkGNsIU7fwiEm9dgOBrnWBUjksTbLNap3UjdEndlBcjqpC
TNZjRF6INyzhthqXOs8cLsmzwyTRGMlKm+cs0bArU52fGsB54Cqk4WyCZoSlW9+xyJFgcFsdtH6j
K+t7G2VT5iPJoJO5HJGm4UBaHdkgXIicgJLDvu2ifZz86zBKNAaiqTCnjweotxqWny5gb8q6TJDr
xJVAWFdkeC61Q6x+bYflj1VH2Or8bavyCwieSrOL27c3kRQFGYwm9QxQIN8E4gOgrY6xV+CDztPq
j7BC5aJR6kyYR7CUGGAdNZGHTKZMdIqdUw3nmPSnknpO1H8VVzUSV8/W5kEX9uyf9/2wGO1b6U3P
0RFxL5wUX6M6t1M00a8a16HEdFfLb54T67F7pHjnXO03HMEc2S+tD0ljsvpwOjoHvSv52TyeUedy
Un1NfLzHlneOkGTZnX5yfL/UhL13lvY7OpBgxAbV3qc6z+0Ix3mOkcQyoCc3VdWc5rIfopK+b4j2
689DBC4sm3pbmuonLNMU+6EatERg+88L3rjch+L9lrPiaxK6cNXkOaZgb4fDwWSbbQ0PNd719nYd
SaOn3pNGfLboN3QQjB4fDR/PeFfXwA2YHa/2kexT83hYXOvdDmuz+MfxKcmSrIqLcnGf/fhRLi5M
aZvoW2LKpxrW3XjbaHBYgF/iKsK/tOSraPa/AAMA8k1QiAplbmRzdHJlYW0NZW5kb2JqDTQgMCBv
YmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDM2IDAgUiANL1Jlc291cmNlcyA1IDAgUiANL0Nv
bnRlbnRzIDYgMCBSIA0vTWVkaWFCb3ggWyAwIDAgNjEyIDc5MiBdIA0vQ3JvcEJveCBbIDAgMCA2
MTIgNzkyIF0gDS9Sb3RhdGUgMCANPj4gDWVuZG9iag01IDAgb2JqDTw8IA0vUHJvY1NldCBbIC9Q
REYgL1RleHQgXSANL0ZvbnQgPDwgL0YyIDU3IDAgUiAvRjMgNjEgMCBSID4+IA0vRXh0R1N0YXRl
IDw8IC9HUzEgNjIgMCBSID4+IA0+PiANZW5kb2JqDTYgMCBvYmoNPDwgL0xlbmd0aCAyMDk2IC9G
aWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJtFddc9u2En33j+hg+kTekWVSH5bdN1/H
7nXGTXMd5s50nDxAJCQhIQGWIKOqv75nAVCgLDntyx3P0JRE7J49u3t2+e/s7OJ+wlKWrc7SlCX4
w7/FhC1mU5ZVZwlbn138/CFla4P7LKfL9uw5eniX3T29u8vi60l0/ubp5j5j8fnlPFmMr6O7P2rZ
CPNTfD6ZJ9Fbrjre7NgkSSbxeZpOZovxVfS2K+1Xafw5ewsIUwchYefT8WQxWbDszVmUjuPsy1k6
c7Bm7Go+XszZIlkQMmBQbROnV5EuuryVWnlTp6K5vE7GM3cq20jDCp13lVAtK4TJG7kUhnFWcWNk
PJlH3+J0HgkANDkv+bIUrBGltDe5Vq07Vw4eRXh1o1ud63LEbsxO5ZtGK90ZCwlBpeP0Kr2ioJ6j
R74TjSjYrS6kWrNP0c3j7ad4xFa6YVVXtvK84e0/cBlfzqNxfD5PErLAJIXQo2BSmZarVvI9Mdm/
4JsjdPGDgnep2NP97TSZXY0ZHe8MOGg3gj3eZqxtuDK1blr2PP08ZtmmMyNWyq9xmkTCpfXo0ZE9
DVPBW0BjgExWvJEgFZTLNUFoNVsKclywrWw39vzDe8dBzk3LlGi35FI3X5kRzTeZixFbxpMk6lr2
yw1+mke/OTi8NGQt+A5mNew2bMmNzFmnCtGUO+J9aBzMh5C9J8NMl28YGOuUg/Pxzfs4TdMh6cRa
8Hl/d4tsFUSkplRQor7Jos+lLGW7I4NroUTDS8eFLT+bj+f084jJsRgz/MZqnju+W0M/cuBCeWpl
64FLdeyWjKCIKptzOuM+UFp5y3hDpVTVQIJi2hNOhx2lsrT1uCx1/vUAWPD0PEE1OMJv3L+86XLJ
gVZLWJXeF1FjWrTAGjFS8KAEkHqguY2IvBuhjHBnKEuCLCgdHDbi906AeuqNRtgcVdLRoFcwUriO
kEXHDxlbNbrCiVwMW8ajIwsv6dUNCoPSBg3oGjFE4NuQjNWt98xxXX4ROaqeq8KGMjTov5MATa2M
A4fQUb70nSOAHOd8wDKaApGJmn5S+ydVVy3xZO/uRewBnaBY/6hFI4WiKvbHj7joE/mg3H+jq0HY
R/rmu4JVyF8JymyyeY0qR2dTkJbaY8YpwD7gJYGvUMZ87XpkwECrD3Rj3zprDA8UrEAlHmGCSS+O
viXv6RcdJ1HjYnJccBQ9hMM2Ud2ZTZDWI4s2uuMoArSK71xIwzB4CMICkqoTPjaXcLk6wcyGU9u5
j3RBPnBVumU7ccQkYip8TJgr682ArEHdwT/OOfL6Y03Q636SaIu0FU0llUtdgLrdCPWPwf4fQfqM
ZvEVJJou8Ijr0o8fmz4KooFlyDBSsW+pnWlFNToRBCXPDgpK1yCnfSqHZfqiOqm4vfBC2aCwBjPK
iprv81f6zw7XUfC10YRoKw5Ia+JZEo3ogiBxLbQgGaQi+L3DKoX7hpla5HK1c1OphzwKQs5lZZXJ
5QkXLa2ed0oBGx7HxuBhRKWsZOvGRB+n3XTchPI8uolJUt7PcbuOYZuZjKeX00u3zWRHK8Oge2mG
1vZLEnDwB8htP8MaWpZ6ORu66XcReXJ98hZ7+YJ/P4mOrAeDVWds+mggOsaw+7DJdL7wZfZg5YzK
sqoo44XN+J4vX5ev2rfLBoVIYUC++XCRC5uh3b6GA3+GcfqgXKig1lYIVg2I1V5S6N/RtBo2bEvl
PChzDAPKR77hSDyUGoVba+oo6TYOuaKHVxi2UAICaMahPMGmGp2aLYeNhHHFePGFWH1Z/jZkovhg
Z1nu/PNUkduNRAkb0Qa/KLkD0LBKvna+2dECX7BguJ0RAQkOA37lAAOyIimneUnmXU/uG2EecemW
eOrrrSzazXDUtlsh1KkJGVSpr1GXEder9od+FX0xrd3C+erA9ZuTAVZaK4ivUFsB2lGRWdLdmmsL
LqzCVD9W3Gxfv9bP+2GkrPT3m0Hw6DcMfWpYOQHktvbzrqHiQTHVvIEMyhoxjPteHYrD02uUEljK
qO3/UpwcLjzc9tD54NUK7nlffoVEVwnib1DLN8qpyr518HBnKAAD9TZ+jaOyGzyyEfwwxxyg/YZE
6+v3HtW2A9Awy90p4eJFIf0D4I1XoiViiYCB0ZrvSs2Lk2xSNBvu3tJWuizdKKGSpy1MIBWQTTu/
j9/jrKSGNyu00eHuE1IzkJqfAorL6+TaodAHg9lNe2rHU+1zONZk6ymta8EpdEOLUbuhVSGs/xzI
CqBs0e193u02f7As7is3PST571FsraO+4Qei5QTK+CWu13pe4t4v+JgbFklAccrdfB659J1bbPPk
On2VuZOyMngTOpDrnLZ+RuVBGxyWlbWm5FvwIFKr72iYxK1xt0FJX+GwZx1OMMhkWdKHTxF9VANV
3svFp/iEYBxq9kB/Ri/lkio2dO3Jd5XXtCL5PtO/ht61JVpK9bUfnwrKT2Wum6+jF+9v1DaW9R/y
YeV5CQII2dKuwPN+gcLWUAsabafYHBiTrncNep+itmNin+zvpm/wTsO9gvq8HHO1dKNT+6lFQZ+U
kwxqOOoXr7CxIeUcoQaTEFo3TcrwBnH8emiXbjcmqHIDu6AQm3BR7uLLvjH6VYM5wl1N7cXeH8TW
8+MvHz9kP47cf/buV+oR+/np7r/00MeHp7s39PnDf24eH/c34cl9cczG6Ww+o7jT2XiaXi9YtgWG
x265u/hZYOcry4v/xZfok1warvTFk/zzT31x2ziNzRu9atkHYTPu+E8xztNZcnk9XkTP7wk9vYLg
K1jHV9PP1vdddvbXANc+noQKZW5kc3RyZWFtDWVuZG9iag03IDAgb2JqDTw8IA0vVHlwZSAvUGFn
ZSANL1BhcmVudCAzNiAwIFIgDS9SZXNvdXJjZXMgOCAwIFIgDS9Db250ZW50cyA5IDAgUiANL01l
ZGlhQm94IFsgMCAwIDYxMiA3OTIgXSANL0Nyb3BCb3ggWyAwIDAgNjEyIDc5MiBdIA0vUm90YXRl
IDAgDT4+IA1lbmRvYmoNOCAwIG9iag08PCANL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gDS9Gb250
IDw8IC9GMiA1NyAwIFIgL0YzIDYxIDAgUiA+PiANL0V4dEdTdGF0ZSA8PCAvR1MxIDYyIDAgUiA+
PiANPj4gDWVuZG9iag05IDAgb2JqDTw8IC9MZW5ndGggMTYyMSAvRmlsdGVyIC9GbGF0ZURlY29k
ZSA+PiANc3RyZWFtDQpIiYRX226jSBB990eMWnmClU3MzXb2zZs4s4lyGSXMSqsoD21o2z0LNEvD
ZDJfv1XVYLBNZhXJwUBXnTpVdar8RzQ6v/aYy6LNyHXZFP7g39xj88BnUTaasu3o/POzy7YarqMY
P95GL9bNQ7R6elhF9oVnTa6eltcRsyezcDp3LqzVj0KWQv9uT7xwat3yvOblO/OmU8+euK4XzJ2F
dVundMu1X6PbkcsmvuPNvTmLrsD42fOfj1/vrs7GrLliD492MLUivPO0uny8v189XK3ohful7U5D
62+45nnCzh6/RDePD7YfWsu7MyZzVu2kJidTNnEdd+Eu0ImVqLjORF4xXgpWKbYW8HIlyqIUlUgY
1ywROi7lGr6AlafrS891Lxw7+gaE+YawCeEOgzAkk2Cdnru+4dFnFwGb4cNsZD2JlKPhq8avNpaG
qJ/5CyfAQy9WtBPs7jJiVclzXaiygnB4xZZ3l+z+63PEag2wj6C++K+OPQmnU2tpMpCpEoObJKKo
ds27RSVVztQG7IlTdl4sNAxPr1eXLFaJiDVaLkUq+ToVcAuoAu4SuGF7ofXddkNLQJKLUlUqVqlG
VNveM3tq5QaN7C5f3FeHLdOUFTz+B9JoiYr8cKaF1gCQkEW/AR6KFt1yeN6iwnA3qsw4BQMPzBdt
SMLExiorADNAfZMQOwRLh9e2N7VqmSYy37J1qsD73tMhl17L5Q0YEpg4VWpkZp8CnmrFZPsUsAPK
rdAECQGXKt3TAiY7RzyOVZnwPKb6wwLzw/mYve0EVuRODBkCVhXyuSe1NEzi6+Ad2q6lroH9rDLB
CgW3IG+dbx3vAK4mjnQhYvmpiTeAjFye+qVImxZB19uSihm+KmKi2pWq3u721WSc1AWVLERPmKXJ
GMV2UNROW4Ge48/8GTXTTYXB9pq9q3zZTwUWqsYgeQ12gYLYVIOJEJlF8kVcETbouaNC36dmU6qM
8aqCUtRQlTmjQH9wdIYJ5y2N70zXsqI+aJycdGD46nQ0LA+BwXMIYszkBrEnYzzd6U+P3B6n7H+o
bJ1ZPUr7QjU90invVKeCcNaKzipHsf0uS9tdWCpHpnnKnsS/tblF3GuSWygVDVhKCs3I7LCmBf6F
szDmKYWaos0xDGjagVJPkZqsTis5QTpOpQZSotbfILEaKHSEMz6RpyFdOzZjz0JroPwAJciSkUdo
rIaPPRclcdHjIT7godGfooBagdSe1DsdqdQQvo8VygjN3iiw6DR8Dya5SXFgchCwRejMQ+YHizYN
n0UOeFO2pJzGO4lNUpsE/yKRvu85Hk00zOO+e4gADWysuYZKT1NKUK0R/uEQwQhRp9mx0HYSjRV9
3KlWj72BgceiXQ2FgKdhiGcyV6navlOHtU5PB99hVtClEWbMzi/yQNMUVFpil67f6d0DMowB7Ose
FKkNmrVIFVbgW1d65PUmhzFYgkzUKS+x4MadtCfiUy5b4PvpSJ1z4hzdomJw1ERgnHS0ffNjrTgq
/y/YH72pTNAxQQ2Zh/G2U4Sn8ie81zSXpl4AxEhzb8Q7zER206wBg2Hzoe7ojHQFh4zkRy7YTnDo
xgNz+60D01rw91TxhN1cjZmikoBO4Ekim0uABPxB+qC9dW9kFxBzUUoQpDFry6TntjHbzN5rnCj0
hgKxQ6DfpTCpJyAKMG26JB8U47itwM55HzM+HIYLYwVWWA3K9CuElDJOm1dZ9bqh7+00qtMpjfup
qsnCGr319zFT7QPt0U9ddWQAMfWMDAzsRnvN3FirTjKO9LUt+eEublIU7brtiGUCzuO5/o6GzvAU
9fNHoR71XK/bjkV/ANC+IQmYyZrsiwEznnHAGDexKkRLXp/ZoUYeWOYGZaNdsEmazT7KPH8xN3ja
/a+/fwyPr25nyUS847nUmT5cW5qSONoAzQ+WtNrReaNauapYBu45bHo0qZtmNhvEnrdM6QpI4SkN
f9if8/7iMLxFU3HSmE6UMJ6awmIbIZI1VD9thPuhUIpY9DcH3U52jVvMgdRQnmuzmpJeI5oPwZxM
s+CVdb9YAyeYe3Mk1w0c372AyzdAc1ev388/iywTaXr+lz2Dn1Wx1DxX50/y5091flmaGROXalOx
Z5js2EwEzwP5dYPp7MKZWy9G5rcCb4F1uBW8kutVNPpvAInp+70KZW5kc3RyZWFtDWVuZG9iag0x
MCAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgMzYgMCBSIA0vUmVzb3VyY2VzIDExIDAg
UiANL0NvbnRlbnRzIDEyIDAgUiANL01lZGlhQm94IFsgMCAwIDYxMiA3OTIgXSANL0Nyb3BCb3gg
WyAwIDAgNjEyIDc5MiBdIA0vUm90YXRlIDAgDT4+IA1lbmRvYmoNMTEgMCBvYmoNPDwgDS9Qcm9j
U2V0IFsgL1BERiAvVGV4dCBdIA0vRm9udCA8PCAvRjIgNTcgMCBSIC9GMyA2MSAwIFIgPj4gDS9F
eHRHU3RhdGUgPDwgL0dTMSA2MiAwIFIgPj4gDT4+IA1lbmRvYmoNMTIgMCBvYmoNPDwgL0xlbmd0
aCAxNTUyIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJjFfJcts4EL37IzI4klMR
TVKilrllbCWVVLZyWDMHJwcQhEQkIMECwHGUr59ugNRi0XIqVYpMAr28fv269Xd+df06JQnJN1dJ
QmL4B/8tUrKYTUleX8Vke3X95ktCtga+5ww/Hq7ug7cf8/Xdx3UertJgcnv36nVOwsk8ixfRKlj/
bIXm5q9wkmZx8I42HdU7ksZxGk6SJJ0tomXwrpPuURJ+y9+B0ck0ShfpguS3V8Hd+ubThw/rj7fr
2yjMv0OAUx+gO5bNsswdS6PEvU6mPuwpWc3IfL7EsO+DWy5FmMTBf/jBwb/h2v0tGCe1Krk0zvV4
9vMsiWbe0Kv3N4TRhpiubZW2YCdMMzSbgVkqSSk2+GDDNW8sKdHt4b1ze+QyInm4jIMHjEThB6CG
8eHpn7RuJTeEak4KLfgfO7BmmBYFLweUkihZJkuXfgUOL8BzH3zuTHWedXSatbOZxavE3/nUcOKC
oztCSdtbONx2SBScdIaXZKM00ZAvLSQnTDV2FABhiFWPHodxoD07qP8PnAhIXW3OE70PVPGdMwvY
+bOv0QS4PgLtJQSrOeOjLpjqZEm+K9EQW3HIxxihGkKbkpS7htaCUQlkpCVtrTvRdHXBNQRD3t/k
LqD8TwiDVbRpoIbuzJPeBHw1/iu6BJgg+66xQhLeqG5bkZayH46U1pCKhmk82IAPpEMWFJw3Ix5K
b9aGyB33Fc6oxljdMQv5HEL1iEXk1cZyrNH+lGi2Lnx/4HImNXDAWPgYAc5zRFjHAXh5cG01bUwt
/FGA0AHqS2V7t9FQ5DSazqdzX+Qczjm+eZ4Ba1qqrWCdpBqrY8EwxH8U6B4u0fQkopZLKSw6tL7F
9A/j4wVBgt4yJ28GQr3t70Ooho8RkFHIHTk2QIDQIKbCWMxRQde8+OmiKomGKJA4pOfL0HDjTfqp
mZS8xhBPGuhYuH6jbX1LHHdVHPRJqXEHT0rUS/izKbkGmu/avjX6mvpqG1Vzsj1lzACgqEfxa6G7
VQmGJVTfdwRoiFRAxr4n4Al4Umj0oU9BSscdgUGXiOspT7WTlbGuPnARiY+HnxId6AbJ96ScZHF8
huSRyKAgqhb5CBhsPI1Qq7u2xJLXYltZzGtACzPt0AeBEXIIymH4eIbQHfDr6OGekQ6dC+KGTASf
ToIBD6YwUogGMSk9no1UtMQmRpqCQWhYZak8UosNcqMBEBBBLOJLAiWraGuIaTWH26MwmhDxcUGl
2IvpLPbpYM20e0ilcSIANke7/i1WD3odO2xMjaDK5yV2Wgdvdz6MFg5YJ1LghTxUoJ1AVTD6lF48
Uv4xxj4xDMjxDDgKwXSFH9SOyIwpXTqlVc5Er/EIh5CuUgWE8CBKW/UEoYdi1J20YuJEBIqy5cYV
BXtXK0laraxiSkbk7gwoyUeHyTF0DpzT0KsQ+8EHGLsi4u1hupxNoH2cI8MM0n2q4w4z5xk5hIN6
ZFU7l780mq/i1X52QB/2raCciWf2MAABaNQvM/1mB+1a7LBXeynAieQXsNb6YTbGFMysVSisAphP
21YCq/A8NLQrfgs1a7XAgj6nvEhMd6csBZoAgzVHyglTm6MRqw7LaMcqsuka5o/DLdiiXJVBCQq3
fjwIoBkusdARha+86v0YplruhzS8LBXrasjjUoVg6U7Pl+5kmUXZarXyC/PNgbY3SNswWQZKXli2
k7m76QA3LWfiBbvE/X587FdQzK0nOOhV5bY9V1VhXbPBGYz4Ud2eXVzDeRb0TPi3EtLL05Y3TuEK
3m9uQulhy7kUsluChwqC77Jj3qCtNPZR2zkFA7GF6ctcTY7MIS+2mpadm8aiYaDJoJfCDqsZLYZr
mKnfVvfXex4y2+Gk8bp3msDXgEfbCJrXtIChE7F+NkplANqvoWsVL2EDMiNq/gVXgxauCAT295TM
/ObPCC+UqMEwc0d+Du1/KiEm97NvUV/z+f5IAjSerxb+9+v7rthdv+F1DRvj9T/hHBZ3Jgxt1PWd
+PVLXd9oPzyZhlFPvvjZ6LUMW4CEyXSarKJFcP8ZI6Rbjo/APjzKvrn41vnV/wMAuFud6wplbmRz
dHJlYW0NZW5kb2JqDTEzIDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1BhcmVudCAzNiAwIFIgDS9S
ZXNvdXJjZXMgMTQgMCBSIA0vQ29udGVudHMgMTUgMCBSIA0vTWVkaWFCb3ggWyAwIDAgNjEyIDc5
MiBdIA0vQ3JvcEJveCBbIDAgMCA2MTIgNzkyIF0gDS9Sb3RhdGUgMCANPj4gDWVuZG9iag0xNCAw
IG9iag08PCANL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gDS9Gb250IDw8IC9GMSAzMSAwIFIgL0Yy
IDU3IDAgUiAvRjMgNjEgMCBSID4+IA0vRXh0R1N0YXRlIDw8IC9HUzEgNjIgMCBSID4+IA0+PiAN
ZW5kb2JqDTE1IDAgb2JqDTw8IC9MZW5ndGggMTI5NCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiAN
c3RyZWFtDQpIicRW247bNhB990cU8yi1a62ouwv0YbvZTROkQZAIBYrNPtASbbORRVWUstkg39pv
6QxpSfbazR0obMiyKM6cOTNzhr/ms/PrABjkqxlj4OMHf9IA0iiEfDvzYT07f/yKwVrjfV7Q5W52
4zx5nl+9fH6Vu4vAmT96eXGdgztPYj/1Fs7Vu0a2Qv/szoPYd57yuuftPQS+H7hzxoIo9TLnaV+Z
R8y9zZ8ihNBC8GEeekEapJA/mjmh5+Z/zVhkYUWQxV4aQ+qnhOzGyd00cu4bAWoFDS/euMx3RKeh
16KE5T10GwEXzy6haV2WOapThap27k5FnCx8L9pZxp3dkeUThq1RkBo46EYUklfyPb701mWxI1ot
VU02eA3PLvM9Ux5YcvCpQYRxM49lLKO4b5z9aHgrQIu6I8f4W6JV6JSxV2x4XYtKe4ONwAuTMLE2
XqmtAFnrjteF0IRCC02ANPx+gcZj50+LoRV/95gvE9Va1KLl3Q72SohyiVBg1aqtWW9FIaQbxM4Q
IEHBhVNBWLBuHDueO4993/nN9R1Fm+/wRlgreAE3iPB/6+L1jC7IDV7J3VZQiFJvYaVaKJWs1+gN
2cav6jstSwtbF8omC7PinaioOIrjXUUxW1OhTXwIiwjixWJI/AtifUr4ivCpdsvH2y8tqjgLvGwq
qr1iWlm7pqYouocFVYpGFh0uyhqu5brHDLEhNmY9ZcZRBhnzEoij0HpijKIpZo7PgpCCNXlJAsOA
j28Oa1GcpNni9B3tm9PLe1vNxp/m3/ghy/mPyMcHVIMQJcAZWgNJ2QhONTNnUYQLH0y4+DLe4a4w
80gKKI/m/9w8mAA6P/3yjZ9DbBlCuL66hBf8vlK8hCeP8Gmc/O/AAoJwUZaS+pRXyF3Lt6LDbhwW
R3wspnzf7TYa7K8d1diNr10YXzSy/t1wsoRKcXCbUJIHEh94/Dz+PpPl71GaUxv7to19auPQXwxt
PPQizOEFieBRRz9s5kM9OlCHIPWtWRSm4FiYxuUjYbJ9Av+IqtRfK01BHHnBJE2l0EUrm0H7ydgP
xjyvS/onW1j1ddGZCXInUYZr89LhYBuQFTjylgK56GujYDfhrXc8JIxjWVviyHG3QQJrHDtmsKCB
Qm23fS0LTkqIkk/QloRotQuY3Hctr3Wj2m7AOrZLo3DkLau9SaLNTl5spJ1A40ihOWs5WIoTkGN/
wUbIX8sVqUkzqskxScHt2SjY0yAlA2a7oHp7V4hm4mqwelUXqqRYriu+BjNXedWLM5B4+miaChlE
Gs4ejP6lGcTm9oDot5IPbXpjBvFocAj3UuF8wnncmcCHGE/Wwt4J4FPpnpx+Mu8UNIYsipF0+LJk
jxJ+mPTg1oN8c2RjwmNtiANQ+zFROGLEOVbiQZ1iWuqi6svB1hZTRPdL0d0JUZ9ieMyAhpONN1G3
68CBFbQg2qYVHbfluEvgZO8jRWHOVjhbgGOCNkqL6bhyQMhhsXweMyaDSzfwnV5WhollpYo3Z/Cx
cifyKIrJ4S6c//Bz2odGwu+P1EWgX0HQWtWvLQKM9sjTg7x8TAXtidYwqZDUdiB1crA3xe0wGSb5
Tk8o6AnBSlXV7gA9pudQUkbBir0wSEPSD4bH32SR2nH8rF/enz8W262oqvM/3MR3ZCE1r9X5S/n+
vTq/bK39olWrDl4JI2HWGU0ocFkYsoWXOjcW7lrQI7SPj5Jb4/wqn/07AEesBl4KZW5kc3RyZWFt
DWVuZG9iag0xNiAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgMzYgMCBSIA0vUmVzb3Vy
Y2VzIDE3IDAgUiANL0NvbnRlbnRzIDE4IDAgUiANL01lZGlhQm94IFsgMCAwIDYxMiA3OTIgXSAN
L0Nyb3BCb3ggWyAwIDAgNjEyIDc5MiBdIA0vUm90YXRlIDAgDT4+IA1lbmRvYmoNMTcgMCBvYmoN
PDwgDS9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIA0vRm9udCA8PCAvRjIgNTcgMCBSIC9GMyA2MSAw
IFIgPj4gDS9FeHRHU3RhdGUgPDwgL0dTMSA2MiAwIFIgPj4gDT4+IA1lbmRvYmoNMTggMCBvYmoN
PDwgL0xlbmd0aCAxMzg3IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJrFdNc5tI
EL37R7jmCFsWZpDQR/aU2HI2qdhJ2ezuQfFhBGNpNoihZoY4yq/f7hkkwEJRUpVyWcJAf0z3e6/b
b5Kzy5uIUJI8nVFKQviBr0lEJqMhSTZnIVmdXb59oGSl4TpJ8eP5bOG9u0vm93fzxJ9F3uD6/vVN
QvzBOA4nwcybfyuF4vqVP4ji0HvPioqpLYnCMPIHlEajSTD13le5vUX9x+Q9OB0Mg2gSTUhyDc6T
NSfnPM80YUVGnqTaMKOJfCIGHsjSCFmwnLzOMlFffvJp7DHFNtxwpWvb278fErLkJJWbTVWIlBme
ESN3AWlAp3TqAqJfxVMu/Cj2vqIzdCMrg0GXkETgD+IwtImVTBmRVjlTJzMwa2bIhm0JK0sO74sC
rNMvPg09brRNJPkDwvdm2h9dlzwV5/AGhMXHz2uRrk8l0kSyGTXZsFY+/fX6Kpit+lesDMsrvmvD
lcx4KUVhbAh0hnc/XCVNsJbvNWcZV/4o9C4cKrCxaLCBZESxgrjmmfPipdt9WAcFtDh61iZwq/q/
ctbDir8zRGhyP7/6eHs7v7ueX1un7XLyGp5oyArMZ+sOaNM8Dg2WrbniAEfS9fGXK1QUeoP5N8ML
jX2+Ee0uehk/L7jlxa7mxChW6FIqgyddDB8DP/kPiD10xAa0R8FwPBwj2r2RfUhHjuwjMo2DSUzi
WYh8X3iflE+nnkx5Vtkr7gJ3xCGOKb4MrqhzNnQPh2Q22j984AUchXwsubJwdSn1aU08HAUja2Mh
7uzkzg4wDsCoNMLEAuDDFSmVNDKVORw3zasM4ZHn9qkFjwZcZZywJbbU7H1iBi+YfzRKt6pMEwiS
KrHkWV3iiz0ib+ZXZIktq0SeWTDnMv0CNg1QusbRY0AS2/Y8l4jwZ7Ry71h1I2uxWufwCyfRcrMn
HWuwn0rARlYnrxFIS94CJnNILyAePGJpKivg1LMwaxA6FBGzw167nMFOHBu4LLw3HJAGsaGI2sJR
G5BAfWHv2FYd6Y0l2abOpKY9lsmRWuRsmXPbNyBpDhyEPw/FeRAGIYwJO3rqK5w/onCcwXwU9+kI
5s6KqWyXSJ2r43FAAVhA5LbRDjivXMggxqBxOKMYtD3pJAwtiOu99kOvJjh8wLSDz7bDgvMM+rvc
HsLnz6YxO2/YfmjhimtrDJdGQcn2tVtyPEmlwSM2rZHXk15fKmpLQk9JNzlQbMS4o78rUEMcMOeq
VNzUAHS+dWtSaJfggHZr+8sV3elcP816qvAO/D45vGEBLxx1KvgsjKhHp07XHHj1E2V2PEeYKg4A
tQsCnrAwfYXpHMANZwBeAbuF1rgF4WFq1rzIqKxUKTVWrS3dgwhXo3gUx7V2R4eCOwynTj4X3r1d
YihyzJIu9JQrRKPCmHS/DEczGkydn+RwIWp8/U5l7tvGfiKwne3wl2HYMomtEVZOkEhQVBDTvL3M
bU/J+zGpbnS+G7DxdFT9Sa/oN4F+t/qTftHfrw2nxd+Nx7b2/4tVY8ehcPhA74TefjWC4lh41JGd
FZAJ8uQHcvQZbMDwG0ILqnZsl+8q3GffbXM9QxzKZodbHRkb0dniJHhT9cpWd6FJKqi51GxZLabG
vVsWHdcUg+0orZQwW8i13crjSxIdxUHUsFPDPglKUjvp4GG/+cK/WHWfX8AdAS1/gN6+urJcy67T
LnjcwlzsUXrRrWR/qvow14YgP5qPVrLrWduRnWMyTpr8/XHs7TedaTCpWwY7xJDOJm7qf6iW28u3
fLPheX75jz8OPZEKzQp5eS++f5eXV8pRN1XyyRBoptVWe9I4ILCPhONZMPEWbvlfcbwF3uHW5NGG
nidn/w8ACh+92gplbmRzdHJlYW0NZW5kb2JqDTE5IDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1Bh
cmVudCAzNiAwIFIgDS9SZXNvdXJjZXMgMjAgMCBSIA0vQ29udGVudHMgMjEgMCBSIA0vTWVkaWFC
b3ggWyAwIDAgNjEyIDc5MiBdIA0vQ3JvcEJveCBbIDAgMCA2MTIgNzkyIF0gDS9Sb3RhdGUgMCAN
Pj4gDWVuZG9iag0yMCAwIG9iag08PCANL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gDS9Gb250IDw8
IC9GMiA1NyAwIFIgL0YzIDYxIDAgUiA+PiANL0V4dEdTdGF0ZSA8PCAvR1MxIDYyIDAgUiA+PiAN
Pj4gDWVuZG9iag0yMSAwIG9iag08PCAvTGVuZ3RoIDEzMjkgL0ZpbHRlciAvRmxhdGVEZWNvZGUg
Pj4gDXN0cmVhbQ0KSIm8Vttu2zgQffdHLAbdF2lhKbpacp/qOE6bIAmKWLvAwsgDLdE2W0n0klRT
9z/3f3ZIyZfETrLYAosgNEVRwzNnzszwPOudXQbgQ7bo+T54+Ic/SQBJFEJW9TxY9s4+Tn1YSpxn
uR4eezPr6i6b3N9NMnsYWM7F/egyA9sZxF7iDq3J9zUTVL63nSD2rGtSN0RsIPC8wHZ8P4gSN7Wu
m9Is+fZDdo0QwhaCB07oBkmQQHbRswaunX3p+VELK4I0dpMYEi/RyBDD6M4OPGvUnjPmtWQFFUQx
nHVmT3k2GHpu1Fq448DqBReV+QjnoFZMglzTnP2Sd4sSCnQnVwhYNvMvOAPFQR8extvDhe1Z1PZj
a8mkaiG40L76xO0gth6pHr/pLdTW+yPP6usBd+E41440rCxYvTTQkQjf9VM/1UTMrHnJ868Scl6t
eU1rJaGRtID5BgFTGN2MYS24ynkJFdmgH0rwoskpkKJgGgwpnwHOn7C1xXpVm8Oz3/DINRGK5U1J
Oqxmgz7tcjKGQ7xgwJ0ExDWiglMJgv7VIItv0wZ8scWwOy3nBc1bl40insoljuLYyCU5KZeBH2zD
fVUrWpYYwAb5+CxsP7X4mgq1gSspG/qaaOI0cFNtRWum0wc6VTIyZyVDCzt3uUC89ZJK4w1OMRbl
/vVOXsgWbhV0QQWtc3wiUsN/EnirInVBFBebnTYLnjcVKsDtNgduOAgHrUo07bcj2/di68+W4Lkh
2ExNfB6ZWr0GTwIeCByJFwdrjyuWr4Bg+HBtLRhVmND2IEZVnNAqerUiWh+d2nFAeeG4prXRC25Y
CoKxKGBNlFazu7UTummX/DNr5j/ATTPvDjI+3Lp9+EirCqPYhz/sgWexnElS8z7c4Ktr/L9nP350
j5/Ql9Kc39kYGCQ4ajtj0SZmLvhCtd++y1BwyNNWg88cu9SmuHhEgi0iCpgIga6MudDVoasf90YS
JYXbpsT0IVK964PWnaipggtBFgoKPTrI4sIRFU6wAjkLmjue56rvqr9PwTuuT2xprOYYEiyYXh8I
GAhcfNUnYkiWWG33HB4qYha8zqH2+pjHn+Lw/jaD8/P/xN8Y81y+ydd83rIVGrZg10lOExD+7wTc
kA2mdKG9eaGaZ7oEYgbINRfqPYywaEvJ9g1Cd5qclEZHOkMxRaBAYe13YEFQWwP/hrBdSS1z5SBV
z5k7riWz6CRxx1x9Il91QGndh9E+/rBl4bjYIN4XAD6jqcx3OQE/mwqO5+IHvrnBdDN9jZnFD/CZ
CsGWLfoxQRYVQwXgw7lgMucUJ/iQ2ckQ7zYbGy351hK7YqifW2pw5QL3TNHXPlyYSjKZ3oze76sA
vmtETo/dPLxUjRosvLX+wPC1k4m+oexZE8iarJqlo6gsyYsMHXTtt7k67KiRiyU4NO0nPdlRg8h3
g7ajjmzdWdSKC/k3jIrC9FS0+nIvTT03QBNB5MbD4dB01FvsLoSWrdyOWmCJqx8KtmSKlAve1Iqw
2sWLkN5pquRF+w7a8tJu2NfQcOhHPozb3GE5jKnOFUyUg2zaZce0YYpC6HmdcetS0ApVi8IY9eH3
KQ7DKA7To3yxrlm1LSrHLnxZtm8+VAwLhcRSceCAdr9dxOYhKRH5audaiDrt7o/bojlVKK9f09Db
gyY1XKJMcq3WJ0jxIqBNoWIxak7shl1c/cgN/WHSik6zftZBPztM7zNTBc+elDiYtqW61VWK90Y/
8gZDN7FmnzWVZEn1ElrHpfTBYJxkvX8GAOtqfEcKZW5kc3RyZWFtDWVuZG9iag0yMiAwIG9iag08
PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgMzYgMCBSIA0vUmVzb3VyY2VzIDIzIDAgUiANL0NvbnRl
bnRzIDI0IDAgUiANL01lZGlhQm94IFsgMCAwIDYxMiA3OTIgXSANL0Nyb3BCb3ggWyAwIDAgNjEy
IDc5MiBdIA0vUm90YXRlIDAgDT4+IA1lbmRvYmoNMjMgMCBvYmoNPDwgDS9Qcm9jU2V0IFsgL1BE
RiAvVGV4dCBdIA0vRm9udCA8PCAvRjIgNTcgMCBSID4+IA0vRXh0R1N0YXRlIDw8IC9HUzEgNjIg
MCBSID4+IA0+PiANZW5kb2JqDTI0IDAgb2JqDTw8IC9MZW5ndGggNTUyIC9GaWx0ZXIgL0ZsYXRl
RGVjb2RlID4+IA1zdHJlYW0NCkiJZFJNT+MwEL3nV8zRXiWu7eaj2RPQFkS3Qoi6y6HikA1u5d3E
rhIHaH/G/uK1E9oFoUgTe+bpzZs3vhLB6JoDA7ENGAPqPvfLOGTxGEQdUNgFo5sVg13rzqL04TXY
oNs7MX+4mwuccxTNHi6vBeAoTWhGcjR/26tGtt9xxBOKFoXuiuYAnFKOI8Z4nJEJWnRVn2L4SSwC
SrIEojHhGc9AzBz/0jRSHw38xClFqlRtoc0AhYgRNmETj0PVALtwgNKQ0tRY/A7EtwD1CVgdWivr
NoRbXZL30gaxjMIjnlAkWwvCH4q2LjTMGpwkiIR9H0+ycsmFaWUI08sQ1isX8oSNY8/kdHAyTsdp
r2PZqZ2CB3U8mvfiR5G+eKGkJZ1We0WUPamcqT1x2nYEnmVV/b3VW9PUxVEZLcN3DCU0TQbP11ph
nqAXnDqVPsCzGjy+d/6cVPcLQi+qgJky1hWqFwU8hCRlPAWPdHbYojp8mWKDFkbDtDG+y2vZmK39
arkDkU+Qi7IlXVmRoiTdn7N1M7kvGltLbcFsYWrqfWdlA6tSSV3K8yrOI7EEyaZV9uCwVSX9fSdh
afSz0SfSDboZ+noi20hpw/+lAQqPUzaH9ErgLEbhYM4aU/SjB0bDO4s5oTnN/TQsJmOWZ4O/y+7X
YXQj69rtYvTx4Y36xY4+jQ0rWVq3qKHHhABmMU1zkqHNvVdfOPku5dhdKn/q+89F8E+AAQBnx+8K
CmVuZHN0cmVhbQ1lbmRvYmoNMjUgMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDM2IDAg
UiANL1Jlc291cmNlcyAyNiAwIFIgDS9Db250ZW50cyAyNyAwIFIgDS9NZWRpYUJveCBbIDAgMCA2
MTIgNzkyIF0gDS9Dcm9wQm94IFsgMCAwIDYxMiA3OTIgXSANL1JvdGF0ZSAwIA0+PiANZW5kb2Jq
DTI2IDAgb2JqDTw8IA0vUHJvY1NldCBbIC9QREYgL1RleHQgXSANL0ZvbnQgPDwgL0YyIDU3IDAg
UiAvRjMgNjEgMCBSID4+IA0vRXh0R1N0YXRlIDw8IC9HUzEgNjIgMCBSID4+IA0+PiANZW5kb2Jq
DTI3IDAgb2JqDTw8IC9MZW5ndGggMTIzNyAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFt
DQpIiZRW32+bSBB+9x9RjfoEJ5uw/kV8b9TBCT0HR0DuLkr7sMZre6+YRQvEdf/6m1ns2q4inU6R
NsuyM/PNN98M/pR2bmZ9YJCuO4yBi3/4z+uDNxxAuuu4sOnc3CcMNhXu04yWfefVCqM0iKMgtSd9
q3cX+7MU7N545HrOxAq+l1KL6ne71x+51mdeNFwfoO+6fbvHWH/oObfW5yY3R8z+mn5GCIMWggu9
gdP3+h6kdx1r4tjpPx02bGEN4XbkeCPwXI+QWbMmz2GqyoOWm20NSc1rsRNFTTbv5zSeuM6QbF8t
tLOZax1tv1jTLzakWwFhUQtdCHSnMinqA75ClO4X27F7I9e1fIwZk00FsaiEfrPZyBIrx6SB6Jkz
cieM0L9a6VZWsFJZQ6iAFyuoNS+qnNdSFRWoNcgadvwASwGZKqVYmUvrRhey2uJTrUDVW6Grrnmx
Elra/ZH1Rgs6afcUnxbkH9c9ZaX0t+oMiN2y2xZQveU1RtoZPKoApVv/e1kJME6+lzmXBeHCd7yq
ZFWDea5A7src8Gvgn3CXWpRci1X3mEHXxE1/w2hls8zbPAx4dKXl0u67VlPTfXS736pcUCTco5e6
C3tZb1VTA8oHb2cmEvLECwJ3aAX1TRZoXmpFZ29yRURRYpjJKXjPdVw2MnJ13EGrWG74WZpVvSHj
7c6spTEcOu6wj2JBri6lftRIoWqZibaMVFgEzDeal1vA/DGDLG8ICgLmqJGqybYtJdX/r12rpl6L
56qCD4oM9+LC3LW0PXStLi3oB9f6SndYO5GvTb0wBarZTq3kB4SKrF8Ra+Lzgz0eoTdzYrLgFSwP
WJHdkfBi8yvV2MZHrs2OSMPU7QnOgmvysNRarIUWRYa8oLzr91ruJMvzG6VtRpNlwwv5o22fLgl2
iGffM1Fid1UnQJelK4SgmqzRI0UqG10qlDoqanVBYY5lwqR+RqtqrBjXq6rVqKRKcjQzLrTKxKpB
fZLXs9izy3mC7IsPRcvwVYY5LzYN36BxmyDqtoCg2FCfvDNCLJpIudxJbBgohd5J7EgaHai7gs74
sh2QjhlzaHEWvtG4eeuMx8MLVWMnoF7RWynqhudGnXuJkj2qQx+ZwUZVKK5vlBapbNVKYonbo14u
U2sVy3BAe8NLyVoXRaUpgorC0ldKV6cJsykqM+b/e3huqc2Q9V07gTKFs0gSzUiloClVXU8FasUC
PvoJhMlHWHKcZsZR+hC8Nx1PnzRIFtMwSF/Aj+7oLvx8EUT3YRQEcRjdA375Bpaf/AGzRTwN4C5M
pnM/fEzOkvDnc/jLZsijH8d+lIZB0oXg76c4SBJYxBA+Ps3D4K6L/qfz5zty+onIfk4hWlA3py3N
8/AxTAOEYrNba9Ge+dHLOdBlkBdE7NuMsZM1JfCcBLCYHXNBvI/HG+EigocgDsII/goR7VVYvEmJ
BhcJRS8Qh/cPqYFPT8cUfk2Tgj0G8fQBHw1Nn8J5iNDQahamEeZ/djojV/BEvyN8lFZsjxFBOH2e
+zE8PcdPiyRwPp7KNXQd71gvNnBu2cRr+3zeLA839wI/bHl+8ye5kJmseKFuYvnjh7qZ6nZuZlqt
cc4I82Fp05w4YLPBaDxxPOv1icSD/UlH6B2PmPvVBA/Szr8DAHFOoP0KZW5kc3RyZWFtDWVuZG9i
ag0yOCAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgMzggMCBSIA0vUmVzb3VyY2VzIDI5
IDAgUiANL0NvbnRlbnRzIDMwIDAgUiANL01lZGlhQm94IFsgMCAwIDYxMiA3OTIgXSANL0Nyb3BC
b3ggWyAwIDAgNjEyIDc5MiBdIA0vUm90YXRlIDAgDT4+IA1lbmRvYmoNMjkgMCBvYmoNPDwgDS9Q
cm9jU2V0IFsgL1BERiAvVGV4dCBdIA0vRm9udCA8PCAvRjIgNTcgMCBSID4+IA0vRXh0R1N0YXRl
IDw8IC9HUzEgNjIgMCBSID4+IA0+PiANZW5kb2JqDTMwIDAgb2JqDTw8IC9MZW5ndGggMjI2IC9G
aWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJJI3LasMwEEX3+opZSgtLGtmyou7axgk1
JRRHdBOycI1iBH4UOyZNvr5KwsDM5cDc8+aI2ChAcCeCCDJOPEaByVJwPZHQErHdI7RzzK65rws5
0I+dK6pd4ZhVNFlXrxsHLMm1NNzS4u83TH5+YYnSkpb1sNTTFZSUiiWIKjN8RculeyBkR1fG0vjL
M51pcGuCKV+hNU/R5/JzFVvf977rxDfLJQ1NmOthFFW43UbxPo1MaXpppvF0hr1vzmEcnmbLgWGq
c8sNPXwx1LRu/R3F9ogQjw954ci/AAMAsYFCPgplbmRzdHJlYW0NZW5kb2JqDTMxIDAgb2JqDTw8
IA0vVHlwZSAvRm9udCANL1N1YnR5cGUgL1R5cGUxIA0vRmlyc3RDaGFyIDMyIA0vTGFzdENoYXIg
MTgxIA0vV2lkdGhzIFsgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYw
MCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCANNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYw
MCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIA02MDAgNjAwIDYwMCA2MDAgNjAwIDYw
MCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgDTYwMCA2MDAgNjAwIDYw
MCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCANNjAwIDYw
MCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAw
IA02MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAw
IDYwMCA2MDAgDTYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAw
IDYwMCA2MDAgNjAwIDYwMCANNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAw
IDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIA02MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAw
IDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgDTYwMCA2MDAgNjAwIDYwMCA2MDAgXSAN
L0VuY29kaW5nIC9XaW5BbnNpRW5jb2RpbmcgDS9CYXNlRm9udCAvREVJQkpFK0NvdXJpZXIgDS9G
b250RGVzY3JpcHRvciAzMiAwIFIgDT4+IA1lbmRvYmoNMzIgMCBvYmoNPDwgDS9UeXBlIC9Gb250
RGVzY3JpcHRvciANL0FzY2VudCA2MjkgDS9DYXBIZWlnaHQgNTYyIA0vRGVzY2VudCAtMTU3IA0v
RmxhZ3MgMzUgDS9Gb250QkJveCBbIC0yOCAtMjUwIDYyOCA4MDUgXSANL0ZvbnROYW1lIC9ERUlC
SkUrQ291cmllciANL0l0YWxpY0FuZ2xlIDAgDS9TdGVtViA1MSANL1hIZWlnaHQgNDI2IA0vQ2hh
clNldCAoL24vZm91ci9wL2UvbC9FL2h5cGhlbi9maXZlL2VxdWFsL0kvc2l4L3NwYWNlL2gvci9Q
L3NldmVuL2Jhci9GL2kvTC9hL3MvXA1wYXJlbmxlZnQvdC96ZXJvL2VpZ2h0L3BhcmVucmlnaHQv
b25lL25pbmUvVC9rL0EvdHdvL20vQy9wbHVzL3RocmVlL28vYy9cDUQvZC95KQ0vRm9udEZpbGUz
IDMzIDAgUiANPj4gDWVuZG9iag0zMyAwIG9iag08PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAvTGVu
Z3RoIDMxMzkgL1N1YnR5cGUgL1R5cGUxQyA+PiANc3RyZWFtDQpIiTxUaVQUVxqt6qa6GiXN2J3C
mS6swmWIG06jIKBxEAFFBYSmWrZGoAFZDgo2KBIFjIKCQCaSCRk0KG4sjktsRNxA6rHoGERHjduY
mVFjxIkaNZqvzOucTIEmp965P96533fuvfW+jyQcFARJks5BwQvnLQqeEpiz2pqZZh268pdYQnIl
pTEKaYxSGu1Q5UTifCflWScHaYyTSw7+6LX69UmKayB/qax8g0405DnDoVHI9Z1gLaEkSfWaIoPB
a5rBYAjMyS20ZqZn5LtNTJnk5unn6zdVRj/DMHoO4/RhnDGMM4fRZxh93QJScyxpblGFeflpK/Lc
Fq5MybHm5liT89NSp7m5BWRnuxmHOue5GdPy0qxr5NtfXRCk/BGOJOFEEBqCGOVIcAQxjiAmKInJ
BOFBEJ4E4U0Q8wgiSEEsJIlQiohSEHEEkUAQU+RcCAWhJLyIDKKCqCdpcgpZRL5QjFesVvyiHKfc
4fA7hz85FDlcpNypTGov1UP9TxWsKlC9poPoPfTP6nnqtepL6ieOKY5tjj+NSB5xeKT3yIKRHSOv
aDSTXxeRYENKyfLalTGpgjEZjae66/F7F7B7ryfXpTL/JxA4mKAHTeurrqfcm4I6pITLYGOeRcPU
YCA5k6opmuqa2DoWa/R4QiDmzD5yae+DC+AO7+k1YBRJaBSVUi0YGRGHQ4QJR+BIE0TiCBEiaA2s
QiTwcE0pJcIqBuFrAq0pQdIH8q0Dgia5shQ6mZNb7qf2c30ZiU0hbEFB+eZC3teabtjgp96SXb6s
WD9lF06GuRBWA9mPONMWZiPt/gEei0fMyL2+t4wrOVna0aEHuhG0oGi35ac2cI0x28KrwtWaSiTt
LyDhkJzCX1wQ9pf203hdDCXQEHSEsifiIFmNzMkRySci7JPFWF1AawrCe2jwB556dffUmdv65k0t
xXu5/gz/pnA2IDQ3OpYPEumBq809Ny7Fz16/pWhzEVeS9X7QqgKcj4N+HzHkD7LlI2qld8W1XbpB
KRumMc/mtGR+wume2Zpszbf0Bzfu27CLa8szHQlhQyLyM5fy9YnU33afO9TP3rUtjYlNCXPjy4Ud
Kt1gc3NFaRN/eOPpFYJ+4SLztMgl9fXxXJH5SBGVd/5K2W720Y9dQPGyjR8RnDtNwn3Z7FoX5PHj
I+QBMJvG1fhnKg4a3bBC9q2QGhh8DmcOq9yGYJb8I5wRNMjey8GfeRRyF49KMJcULucgBtoRfop7
adtG6uiFrsrt7FMxdHFguGlsWHh9g8BvEKiC8xfXDrDgfwLUA7ymGMFGBKZu7WMRdv/T2KV7qZOk
Ymkv0xNELwhflxnD+0ZFeOHJemwC5/B7nO7lD9e/+n4w9A5WeJvNaSv5KiBPfXunXa2TGmyddSeq
qyqq2cqGqgbu09rKrTW87qXRrmRMmYsnGmMPnlnDldV92FS+R93Z2Nfaz7a3F6bv4WsLa6z5ek3D
GqkOkc9EaOtTSpVSLdNrd8djxK+hjcYx9jrqvEpT3A253bC8W/uDmIpgq5gu6l5IG8DAfBN+OL2O
0z0+XN/e8m/9QMog1o//c+T4sKbk01ZO92J1yfwUT/3My7NhFAfOV24M8rrHgdDAhEYnB2bOqH34
dPCT5hunzZEytR7vY/zm5EaYp2x/8OS7z9tu9luCOU1xDyzshio5d0cRDsm5fwS3mWvr7kWe5Vqy
4nfEs1g518fD0OsJ7/R92dh1kP8Q+8wLNVjVm1ZmbckqLasuZaONA6qjto//auNhRPMjICBCH2Vj
lhctMQexXmZ05SrquGVrX5+5j29YuSOhKkWtAYX4HJH/lQKGJnUng+wBAi0FYAMj2gNMQzMAKgQn
UapNWwYZEAFpusfS9y7IRONUqY7CFQKMV+HFdgsVJkAGMqiOg4qCNtUJrKImCaoDkM/gCpXuDoyE
f1DyO5DWi+TFbslZdieeZ/JOUalLQ3IXsFg7+SFMhzAY03X9y75sczs/S4RMUzi9YifVmBy3fSmL
PcdjPfbAft/iP8Li2zebT5wfetqSZWhfiPBAftsIzjLgO+f2uD3cthVZVeks3izcslvmCJClam+r
rmnlX+28dR8W64VNjLHYmLuMC02bWxTAYoVkeaq631qe1MH/PadpkZd+yHYigiSkBVcRvNBXKA7p
7LqfpC9cIErArvg0JILXPATLhADsBUm0zg5t2BVBlD1PuGO3vC+ofmtBggcCb3RdFtgpaRkw2q3C
TbvFX4DtCI+W+3i/7eMNSdCOWfpXV/vlihJ5N/lIFvBBdq0AvnYL9hV+I0xHw1u80wU+FfAybJN5
oxC2Ca/slrHDLJiEoFYmeiM4LBM7pNHMvdgneCqHG94GY0PYAybBaFX/QF13K7/7wGfHjukFl1Wl
1pICLjo7bLORxRTUygSxsyiuRZ6ij1fl698KOIUgcOi86yv1STQDCfbPcAKS13+grNNZABFhZ1lT
IHYf2ilJCKZ3g6Zb29sNSNStl864ID8ooxsrmtY3crY1sS0z2QXzC/Ii+ToTtf3A1cZL7KGD5YXN
/P51NRlZ+my6JjGuRp4B36VeEbzuzKKe4Oc3Lh/vQpxuvQ+9FSYzujNLYkPMs9jwpGNHG3fs3lXH
7/9CrD7FtreVlbbxmhIRnneTVxE8lKNoHmBWI2q1dU7kLBYbkoDq/+bq16Dq6SpKP87Pl00J8fSB
hPjPI1kcMB//wYAngtILtINXDp7s49+YeYDktLWdCL4bMvMvFzRbuoz/X2W1xkRxhVGR7s6WJrt1
h5HKwEytCSSVSGOKkVawPAQ1NFoZcFteFhDQQEHiIzxsaZCKJTy6IF22ogQoUAJlreEhIS57QaJI
kRLUDYVNBYI0QrQR+034SNO7u7FJ/97cx7nn+875zhEJvDCJuftZ5A8xPPL+vshRrKiyohJ8Jsd+
uv0LhbuX+QZyKdytEaG+uPHw/NyTidlndB34Tp8IB9A9BLRDLqPD8IK6VMctLn9QkRQUlBfPxyd+
13RcTG/Msgx6Vss7GNDuB1cMwC1b/VFAtwl0hbAZW0vXmHAQTnL4l3KkemQcFDwI7T65dr04YbuA
2gKNVIPT9hromdGzD1G170Baok4AI4rSH+t1uyXIIbuhgunpv9M7xs8aP5VELAx09pWVLINGC8ZJ
ibBL7HN4LLdyoAlHDQOl660cYdglDJE1mCKBH1rpMFU6T4FAFeVugc2QiSGQwa7K9+g8YlL7k/uP
3Qi9/xYrgz+oFU8JZko3lRiO3gqZ+w+PNxxihrsV7OqNk7N7Bj5WSY5r7X4OzbSml6hWQmkNzkgQ
vF6HYa+gHhvSjhO7WHYSdy92Rl7eTI6CkWEHer4aSG0SavPyKs7xutSM9GzRdP5Ep45PysrOyhbZ
mb63JfO65iXR0b3wI9N2ramzj/+1Yu/XIt7+23HH5cqfxwhfW3uppEbsOF2WluqJ1x2vPhr6nP5U
ZSeZtcpTdpZrGLbPdKE3q1m4cjbTEMdH7M9K0ImsdRS9o234yMk33QPVzM3u+113+J6hLyNErA50
5CKgJm0mspdd75DFzR+Bd1CiSee193EbblnZDu+B39MV8BCkbznfD0NRiXzUk5mlKRu8CQGdqI4R
1BhLgCWwQCi0Zxb4k1An76fRy1RsKmwX2BlbSsj1YD7gUHp8Op1cv6G3ZFs3Ulg9do9IZVLaSfIi
D+rlFeApOfQddN11IHBH0OTq4tgsHTUenaj8RHBynmzRQhxhJ1iTPAZrXOm1i/VFV1TNBadqMnm/
qBDpoMhOgAr3S7CJ9scmSXYjGAsJDGt6ARv6Osx8c2PJCb3o/Lh2icRboMuSaW+2KdkAHpztcENE
lRBR5V+a0KYqvFxUX+95d97QI7BWQvJzukUaMXfGpDAtiTGGaOrvYbEBufqcq/niYJy18kGJil3o
vWjWtxxXVV0oLyjxDMGNxWlR0lVTnDAiYTDpY04PDJz5nWenwHV6+LEDxgLtsm1UMd/3ciUWxbmj
H2VE8jmnKutyxC+MxV3tnlBErRZrgYtBLlyaRANDjXNDnvnBw7aWUQf5spFoGyAafUC/CJE0/M3J
Gpp7I6UhBj9AMyXZrLhHMFoaV0IUvnwXAxWsFV0k0JNdSuiTjQo1lq8VuEDrLVeYxnJurUD3TwGj
Pl8nTxhwex3MNeC+MiUU6Z+XrXeVM/9fV71af524kTfkZfd/AeiZqJcKZW5kc3RyZWFtDWVuZG9i
ag0zNCAwIG9iag08PCANL1MgL0QgDT4+IA1lbmRvYmoNMzUgMCBvYmoNPDwgDS9OdW1zIFsgMCAz
NCAwIFIgXSANPj4gDWVuZG9iag0zNiAwIG9iag08PCANL1R5cGUgL1BhZ2VzIA0vS2lkcyBbIDUy
IDAgUiAxIDAgUiA0IDAgUiA3IDAgUiAxMCAwIFIgMTMgMCBSIDE2IDAgUiAxOSAwIFIgMjIgMCBS
IDI1IDAgUiANXSANL0NvdW50IDEwIA0vUGFyZW50IDM3IDAgUiANPj4gDWVuZG9iag0zNyAwIG9i
ag08PCANL1R5cGUgL1BhZ2VzIA0vS2lkcyBbIDM2IDAgUiAzOCAwIFIgXSANL0NvdW50IDExIA0+
PiANZW5kb2JqDTM4IDAgb2JqDTw8IA0vVHlwZSAvUGFnZXMgDS9LaWRzIFsgMjggMCBSIF0gDS9D
b3VudCAxIA0vUGFyZW50IDM3IDAgUiANPj4gDWVuZG9iag0zOSAwIG9iag08PCANL0R0IChEOjIw
MDEwNzIwMTEwNzExKQ0vSlRNIChEaXN0aWxsZXIpDT4+IA1lbmRvYmoNNDAgMCBvYmoNL1RoaXMg
DWVuZG9iag00MSAwIG9iag08PCANL0NQIChEaXN0aWxsZXIpDS9GaSA0MCAwIFIgDT4+IA1lbmRv
YmoNNDIgMCBvYmoNPDwgDS9SIFsgMTIwMCAxMjAwIF0gDT4+IA1lbmRvYmoNNDMgMCBvYmoNPDwg
DS9KVEYgMCANL01CIFsgMCAwIDYxMiA3OTIgXSANL1IgNDIgMCBSIA0vVyBbIDAgMTAgXSANPj4g
DWVuZG9iag00NCAwIG9iag08PCANL0ZpIFsgNDEgMCBSIF0gDS9QIFsgNDMgMCBSIF0gDT4+IA1l
bmRvYmoNNDUgMCBvYmoNPDwgDS9EbSBbIDYxMiA3OTIgNjEyIDc5MiBdIA0+PiANZW5kb2JqDTQ2
IDAgb2JqDTw8IA0vTWUgNDUgMCBSIA0+PiANZW5kb2JqDTQ3IDAgb2JqDTw8IA0vRCBbIDQ0IDAg
UiBdIA0vTVMgNDYgMCBSIA0vVHlwZSAvSm9iVGlja2V0Q29udGVudHMgDT4+IA1lbmRvYmoNNDgg
MCBvYmoNPDwgDS9BIFsgMzkgMCBSIF0gDS9DbiBbIDQ3IDAgUiBdIA0vViAxLjEwMDAxIA0+PiAN
ZW5kb2JqDTQ5IDAgb2JqDTw8IA0vQ3JlYXRpb25EYXRlIChEOjIwMDEwNzIwMTEwNzExKQ0vUHJv
ZHVjZXIgKEFjcm9iYXQgRGlzdGlsbGVyIDQuMCBmb3IgV2luZG93cykNL0NyZWF0b3IgKGdyb2Zm
IHZlcnNpb24gMS4xNSkNL01vZERhdGUgKEQ6MjAwMTA3MjAxMTA3MTEtMDcnMDAnKQ0+PiANZW5k
b2JqDXhyZWYNMCA1MCANMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDEwMzE4IDAwMDAwIG4NCjAw
MDAwMTA0NjkgMDAwMDAgbg0KMDAwMDAxMDU4MiAwMDAwMCBuDQowMDAwMDExNTA5IDAwMDAwIG4N
CjAwMDAwMTE2NjAgMDAwMDAgbg0KMDAwMDAxMTc3MyAwMDAwMCBuDQowMDAwMDEzOTQzIDAwMDAw
IG4NCjAwMDAwMTQwOTQgMDAwMDAgbg0KMDAwMDAxNDIwNyAwMDAwMCBuDQowMDAwMDE1OTAyIDAw
MDAwIG4NCjAwMDAwMTYwNTYgMDAwMDAgbg0KMDAwMDAxNjE3MCAwMDAwMCBuDQowMDAwMDE3Nzk3
IDAwMDAwIG4NCjAwMDAwMTc5NTEgMDAwMDAgbg0KMDAwMDAxODA3NiAwMDAwMCBuDQowMDAwMDE5
NDQ1IDAwMDAwIG4NCjAwMDAwMTk1OTkgMDAwMDAgbg0KMDAwMDAxOTcxMyAwMDAwMCBuDQowMDAw
MDIxMTc1IDAwMDAwIG4NCjAwMDAwMjEzMjkgMDAwMDAgbg0KMDAwMDAyMTQ0MyAwMDAwMCBuDQow
MDAwMDIyODQ3IDAwMDAwIG4NCjAwMDAwMjMwMDEgMDAwMDAgbg0KMDAwMDAyMzEwNCAwMDAwMCBu
DQowMDAwMDIzNzMwIDAwMDAwIG4NCjAwMDAwMjM4ODQgMDAwMDAgbg0KMDAwMDAyMzk5OCAwMDAw
MCBuDQowMDAwMDI1MzEwIDAwMDAwIG4NCjAwMDAwMjU0NjQgMDAwMDAgbg0KMDAwMDAyNTU2NyAw
MDAwMCBuDQowMDAwMDI1ODY3IDAwMDAwIG4NCjAwMDAwMjY2NTIgMDAwMDAgbg0KMDAwMDAyNzAz
OCAwMDAwMCBuDQowMDAwMDMwMjY5IDAwMDAwIG4NCjAwMDAwMzAzMDAgMDAwMDAgbg0KMDAwMDAz
MDM0NCAwMDAwMCBuDQowMDAwMDMwNDg4IDAwMDAwIG4NCjAwMDAwMzA1NjIgMDAwMDAgbg0KMDAw
MDAzMDY0NCAwMDAwMCBuDQowMDAwMDMwNzA4IDAwMDAwIG4NCjAwMDAwMzA3MzEgMDAwMDAgbg0K
MDAwMDAzMDc4MyAwMDAwMCBuDQowMDAwMDMwODI1IDAwMDAwIG4NCjAwMDAwMzA5MDIgMDAwMDAg
bg0KMDAwMDAzMDk1NyAwMDAwMCBuDQowMDAwMDMxMDA2IDAwMDAwIG4NCjAwMDAwMzEwNDIgMDAw
MDAgbg0KMDAwMDAzMTExOSAwMDAwMCBuDQowMDAwMDMxMTg2IDAwMDAwIG4NCnRyYWlsZXINPDwN
L1NpemUgNTANL0lEWzxiYTFmM2RiZjc3NjBiMTgwZWY0ZDU5ZTVlZWJlODNjZT48YmExZjNkYmY3
NzYwYjE4MGVmNGQ1OWU1ZWViZTgzY2U+XQ0+Pg1zdGFydHhyZWYNMTczDSUlRU9GDQ==
------=_NextPart_000_0002_01C11115.E3203A10
Content-Type: application/postscript;
name="submitted draft-ietf-rmt-bb-alc-02-mgl-7-20-2001.ps"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
filename="submitted draft-ietf-rmt-bb-alc-02-mgl-7-20-2001.ps"
%!PS-Adobe-3.0=0A=
%%Creator: groff version 1.15=0A=
%%CreationDate: Fri Jul 20 10:58:42 2001=0A=
%%DocumentNeededResources: font Courier-Bold=0A=
%%+ font Times-Bold=0A=
%%+ font Times-Roman=0A=
%%+ font Courier=0A=
%%DocumentSuppliedResources: procset grops 1.15 1=0A=
%%Pages: 11=0A=
%%PageOrder: Ascend=0A=
%%Orientation: Portrait=0A=
%%EndComments=0A=
%%BeginProlog=0A=
%%BeginResource: procset grops 1.15 1=0A=
/setpacking where{=0A=
pop=0A=
currentpacking=0A=
true setpacking=0A=
}if=0A=
/grops 120 dict dup begin=0A=
/SC 32 def=0A=
/A/show load def=0A=
/B{0 SC 3 -1 roll widthshow}bind def=0A=
/C{0 exch ashow}bind def=0A=
/D{0 exch 0 SC 5 2 roll awidthshow}bind def=0A=
/E{0 rmoveto show}bind def=0A=
/F{0 rmoveto 0 SC 3 -1 roll widthshow}bind def=0A=
/G{0 rmoveto 0 exch ashow}bind def=0A=
/H{0 rmoveto 0 exch 0 SC 5 2 roll awidthshow}bind def=0A=
/I{0 exch rmoveto show}bind def=0A=
/J{0 exch rmoveto 0 SC 3 -1 roll widthshow}bind def=0A=
/K{0 exch rmoveto 0 exch ashow}bind def=0A=
/L{0 exch rmoveto 0 exch 0 SC 5 2 roll awidthshow}bind def=0A=
/M{rmoveto show}bind def=0A=
/N{rmoveto 0 SC 3 -1 roll widthshow}bind def=0A=
/O{rmoveto 0 exch ashow}bind def=0A=
/P{rmoveto 0 exch 0 SC 5 2 roll awidthshow}bind def=0A=
/Q{moveto show}bind def=0A=
/R{moveto 0 SC 3 -1 roll widthshow}bind def=0A=
/S{moveto 0 exch ashow}bind def=0A=
/T{moveto 0 exch 0 SC 5 2 roll awidthshow}bind def=0A=
/SF{=0A=
findfont exch=0A=
[exch dup 0 exch 0 exch neg 0 0]makefont=0A=
dup setfont=0A=
[exch/setfont cvx]cvx bind def=0A=
}bind def=0A=
/MF{=0A=
findfont=0A=
[5 2 roll=0A=
0 3 1 roll=0A=
neg 0 0]makefont=0A=
dup setfont=0A=
[exch/setfont cvx]cvx bind def=0A=
}bind def=0A=
/level0 0 def=0A=
/RES 0 def=0A=
/PL 0 def=0A=
/LS 0 def=0A=
/MANUAL{=0A=
statusdict begin/manualfeed true store end=0A=
}bind def=0A=
/PLG{=0A=
gsave newpath clippath pathbbox grestore=0A=
exch pop add exch pop=0A=
}bind def=0A=
/BP{=0A=
/level0 save def=0A=
1 setlinecap=0A=
1 setlinejoin=0A=
72 RES div dup scale=0A=
LS{=0A=
90 rotate=0A=
}{=0A=
0 PL translate=0A=
}ifelse=0A=
1 -1 scale=0A=
}bind def=0A=
/EP{=0A=
level0 restore=0A=
showpage=0A=
}bind def=0A=
/DA{=0A=
newpath arcn stroke=0A=
}bind def=0A=
/SN{=0A=
transform=0A=
.25 sub exch .25 sub exch=0A=
round .25 add exch round .25 add exch=0A=
itransform=0A=
}bind def=0A=
/DL{=0A=
SN=0A=
moveto=0A=
SN=0A=
lineto stroke=0A=
}bind def=0A=
/DC{=0A=
newpath 0 360 arc closepath=0A=
}bind def=0A=
/TM matrix def=0A=
/DE{=0A=
TM currentmatrix pop=0A=
translate scale newpath 0 0 .5 0 360 arc closepath=0A=
TM setmatrix=0A=
}bind def=0A=
/RC/rcurveto load def=0A=
/RL/rlineto load def=0A=
/ST/stroke load def=0A=
/MT/moveto load def=0A=
/CL/closepath load def=0A=
/FL{=0A=
currentgray exch setgray fill setgray=0A=
}bind def=0A=
/BL/fill load def=0A=
/LW/setlinewidth load def=0A=
/RE{=0A=
findfont=0A=
dup maxlength 1 index/FontName known not{1 add}if dict begin=0A=
{=0A=
1 index/FID ne{def}{pop pop}ifelse=0A=
}forall=0A=
/Encoding exch def=0A=
dup/FontName exch def=0A=
currentdict end definefont pop=0A=
}bind def=0A=
/DEFS 0 def=0A=
/EBEGIN{=0A=
moveto=0A=
DEFS begin=0A=
}bind def=0A=
/EEND/end load def=0A=
/CNT 0 def=0A=
/level1 0 def=0A=
/PBEGIN{=0A=
/level1 save def=0A=
translate=0A=
div 3 1 roll div exch scale=0A=
neg exch neg exch translate=0A=
0 setgray=0A=
0 setlinecap=0A=
1 setlinewidth=0A=
0 setlinejoin=0A=
10 setmiterlimit=0A=
[]0 setdash=0A=
/setstrokeadjust where{=0A=
pop=0A=
false setstrokeadjust=0A=
}if=0A=
/setoverprint where{=0A=
pop=0A=
false setoverprint=0A=
}if=0A=
newpath=0A=
/CNT countdictstack def=0A=
userdict begin=0A=
/showpage{}def=0A=
}bind def=0A=
/PEND{=0A=
clear=0A=
countdictstack CNT sub{end}repeat=0A=
level1 restore=0A=
}bind def=0A=
end def=0A=
/setpacking where{=0A=
pop=0A=
setpacking=0A=
}if=0A=
%%EndResource=0A=
%%IncludeResource: font Courier-Bold=0A=
%%IncludeResource: font Times-Bold=0A=
%%IncludeResource: font Times-Roman=0A=
%%IncludeResource: font Courier=0A=
grops begin/DEFS 1 dict def DEFS begin/u{.001 mul}bind def end/RES 72=0A=
def/PL 792 def/LS false def/ENC0[/asciicircum/asciitilde/Scaron/Zcaron=0A=
/scaron/zcaron/Ydieresis/trademark/quotesingle/.notdef/.notdef/.notdef=0A=
/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef=0A=
/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef=0A=
/.notdef/.notdef/space/exclam/quotedbl/numbersign/dollar/percent=0A=
/ampersand/quoteright/parenleft/parenright/asterisk/plus/comma/hyphen=0A=
/period/slash/zero/one/two/three/four/five/six/seven/eight/nine/colon=0A=
/semicolon/less/equal/greater/question/at/A/B/C/D/E/F/G/H/I/J/K/L/M/N/O=0A=
/P/Q/R/S/T/U/V/W/X/Y/Z/bracketleft/backslash/bracketright/circumflex=0A=
/underscore/quoteleft/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y=0A=
/z/braceleft/bar/braceright/tilde/.notdef/quotesinglbase/guillemotleft=0A=
/guillemotright/bullet/florin/fraction/perthousand/dagger/daggerdbl=0A=
/endash/emdash/ff/fi/fl/ffi/ffl/dotlessi/dotlessj/grave/hungarumlaut=0A=
/dotaccent/breve/caron/ring/ogonek/quotedblleft/quotedblright/oe/lslash=0A=
/quotedblbase/OE/Lslash/.notdef/exclamdown/cent/sterling/currency/yen=0A=
/brokenbar/section/dieresis/copyright/ordfeminine/guilsinglleft=0A=
/logicalnot/minus/registered/macron/degree/plusminus/twosuperior=0A=
/threesuperior/acute/mu/paragraph/periodcentered/cedilla/onesuperior=0A=
/ordmasculine/guilsinglright/onequarter/onehalf/threequarters=0A=
/questiondown/Agrave/Aacute/Acircumflex/Atilde/Adieresis/Aring/AE=0A=
/Ccedilla/Egrave/Eacute/Ecircumflex/Edieresis/Igrave/Iacute/Icircumflex=0A=
/Idieresis/Eth/Ntilde/Ograve/Oacute/Ocircumflex/Otilde/Odieresis=0A=
/multiply/Oslash/Ugrave/Uacute/Ucircumflex/Udieresis/Yacute/Thorn=0A=
/germandbls/agrave/aacute/acircumflex/atilde/adieresis/aring/ae/ccedilla=0A=
/egrave/eacute/ecircumflex/edieresis/igrave/iacute/icircumflex/idieresis=0A=
/eth/ntilde/ograve/oacute/ocircumflex/otilde/odieresis/divide/oslash=0A=
/ugrave/uacute/ucircumflex/udieresis/yacute/thorn/ydieresis]def=0A=
/Courier@0 ENC0/Courier RE/Times-Roman@0 ENC0/Times-Roman RE=0A=
/Times-Bold@0 ENC0/Times-Bold RE/Courier-Bold@0 ENC0/Courier-Bold RE=0A=
%%EndProlog=0A=
%%Page: 1 1=0A=
%%BeginPageSetup=0A=
BP=0A=
%%EndPageSetup=0A=
/F0 10/Courier-Bold@0 SF(Internet Engineering Task Force)72 85 Q(RMT WG)=0A=
209.999 E 203.999(INTERNET-DRAFT M.Luby/Digital)72 98 R(Fountain)6 E=0A=
149.999(draft-ietf-rmt-pi-alc-02.ps J.Gemmell/Microsoft)72 111 R=0A=
(L.Vicisano/Cisco)407.999 124 Q(L.Rizzo/ACIRI and Univ. Pisa)335.999 137=0A=
Q(J. Crowcroft/UCL)407.999 150 Q(20 July 2001)431.999 163 Q=0A=
(Expires: January 2002)377.999 176 Q/F1 14/Times-Bold@0 SF(Asynchr)=0A=
193.038 201 Q(onous Lay)-.252 E(er)-.14 E(ed Coding:)-.252 E 3.5(Am)=0A=
126.377 214 S(assi)-3.5 E -.14(ve)-.14 G(ly scalable r).14 E=0A=
(eliably content deli)-.252 E -.14(ve)-.14 G(ry pr).14 E(otocol)-.252 E=0A=
/F2 11/Times-Bold@0 SF(Status of this Document)72 259 Q/F3 11=0A=
/Times-Roman@0 SF(This document is an Internet-Draft and is in full con\=0A=
formance with all pro)72 275.6 Q(visions of Section 10 of)-.165 E=0A=
(RFC2026.)72 288.6 Q(Internet-Drafts are w)72 314.6 Q=0A=
(orking documents of the Internet Engineering T)-.11 E(ask F)-.88 E=0A=
(orce \(IETF\), its areas,)-.165 E(and its w)72 327.6 Q(orking groups.)=0A=
-.11 E(Note that other groups may also distrib)5.5 E(ute w)-.22 E=0A=
(orking documents as)-.11 E(Internet-Drafts.)72 340.6 Q=0A=
(Internet-Drafts are v)72 366.6 Q=0A=
(alid for a maximum of six months and MA)-.275 E 2.75(Yb)-1.155 G 2.75=0A=
(eu)-2.75 G(pdated, replaced, or)-2.75 E=0A=
(obsoleted by other documents at an)72 379.6 Q 2.75(yt)-.165 G 2.75=0A=
(ime. It)-2.75 F(is inappropriate to use Internet-Drafts as reference)=0A=
2.75 E(material or to cite them other than as a "w)72 392.6 Q=0A=
(ork in progress".)-.11 E=0A=
(The list of current Internet-Drafts can be accessed at http://www)72=0A=
418.6 Q(.ietf.or)-.715 E(g/ietf/1id-abstracts.txt)-.198 E 1.76 -.88=0A=
(To v)72 444.6 T(ie).88 E 2.75(wt)-.275 G(he list Internet-Draft Shado)=0A=
-2.75 E 2.75(wD)-.275 G(irectories, see http://www)-2.75 E(.ietf.or)=0A=
-.715 E(g/shado)-.198 E -.715(w.)-.275 G(html.).715 E=0A=
(This document is a product of the IETF RMT WG.)72 470.6 Q=0A=
(Comments should be addressed to the)5.5 E(authors, or the WG')72 483.6=0A=
Q 2.75(sm)-.605 G(ailing list at rmt@lbl.go)-2.75 E -.715(v.)-.165 G F2=0A=
(Abstract)267.534 515.6 Q F3(This document describes the Asynchronous L\=0A=
ayered Coding protocol, a massi)97 538.2 Q -.165(ve)-.275 G(ly).165 E=0A=
(scalable reliable content deli)97 551.2 Q -.165(ve)-.275 G=0A=
(ry protocol, hereafter referred to as ALC.).165 E(ALC can be)5.5 E=0A=
(used for multi-rate reliable deli)97 564.2 Q -.165(ve)-.275 G=0A=
(ry of content to lar).165 E(ge sets of recei)-.198 E -.165(ve)-.275 G=0A=
2.75(rs. ALC).165 F(uses the)2.75 E(LCT transport described in [3] augm\=0A=
ented with a congestion control protocol that is)97 577.2 Q(compliant w\=0A=
ith RFC2387 such as one of the layered congestion control protocols)97=0A=
590.2 Q(described [4]. ALC achie)97 603.2 Q -.165(ve)-.275 G 2.75(sr)=0A=
.165 G(eliability based on FEC codecs as generally described in)-2.75 E=0A=
([1], and in particular based on the details pro)97 616.2 Q=0A=
(vided in the FEC b)-.165 E(uilding block)-.22 E(described in [2].)97=0A=
629.2 Q(Luby/Gemmell/V)72 769 Q(icisano/Rizzo/Cro)-.66 E 207.017=0A=
(wcroft [P)-.275 F(age 1])-.165 E EP=0A=
%%Page: 2 2=0A=
%%BeginPageSetup=0A=
BP=0A=
%%EndPageSetup=0A=
/F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 71.587(-DRAFT Expires:)-1.012 F=0A=
(January 2002)2.75 E(July 2001)123.726 E/F1 13/Times-Bold@0 SF -1.196=0A=
(Ta)239.126 85 S(ble of Contents)1.196 E/F2 10/Times-Roman@0 SF=0A=
(1. Introduction)97 123 Q F0 11(......................)3.56 G F2(3)11.5=0A=
E(1.1. Related Documents)107 135 Q F0 11(..................)11.9 G F2(4)=0A=
11.5 E(1.2. En)107 147 Q(vironmental Requirements and Considerations)-.4=0A=
E F0 11(..........)3.97 G F2(4)11.5 E(2. General Architecture)97 159 Q=0A=
F0 11(...................)10.12 G F2(4)11.5 E(2.1. Deli)107 171 Q -.15=0A=
(ve)-.25 G(ry service models).15 E F0 11(.................)7.45 G F2(5)=0A=
11.5 E(2.2. Congestion Control)107 183 Q F0 11(..................)11.88=0A=
G F2(5)11.5 E(3. T)97 195 Q(ype of pack)-.8 E=0A=
(ets used by the ALC protocol)-.1 E F0 11(.............)7.4 G F2(6)11.5=0A=
E(3.1. P)107 207 Q(ack)-.15 E(et format for the ALC protocol)-.1 E F0 11=0A=
(..............)2.72 G F2(6)11.5 E(3.2. P)107 219 Q(ack)-.15 E=0A=
(et header \214elds for the ALC protocol)-.1 E F0 11(............)6.06 G=0A=
F2(6)11.5 E(4. Procedures)97 231 Q F0 11(......................)8.57 G=0A=
F2(7)11.5 E(4.1. Sender Operation)107 243 Q F0 11(...................)=0A=
6.49 G F2(7)11.5 E(4.2. Recei)107 255 Q -.15(ve)-.25 G 2.5(rO).15 G=0A=
(peration)-2.5 E F0 11(..................)12.87 G F2(7)11.5 E=0A=
(5. Security Considerations)97 267 Q F0 11(..................)12.17 G F2=0A=
(7)11.5 E(6. IAN)97 279 Q 2.5(AC)-.35 G(onsiderations)-2.5 E F0 11=0A=
(...................)7.11 G F2(8)11.5 E(7. Intellectual Property Issues)=0A=
97 291 Q F0 11(.................)12.88 G F2(8)11.5 E=0A=
(8. Authors' Addresses)97 303 Q F0 11(....................)1.35 G F2(8)=0A=
11.5 E(9. Full Cop)97 315 Q(yright Statement)-.1 E F0 11=0A=
(..................)6.42 G F2(10)6.5 E F0(Luby/Gemmell/V)72 769 Q=0A=
(icisano/Rizzo/Cro)-.66 E 207.017(wcroft [P)-.275 F(age 2])-.165 E EP=0A=
%%Page: 3 3=0A=
%%BeginPageSetup=0A=
BP=0A=
%%EndPageSetup=0A=
/F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 71.587(-DRAFT Expires:)-1.012 F=0A=
(January 2002)2.75 E(July 2001)123.726 E/F1 11/Times-Bold@0 SF(1.)72 85=0A=
Q/F2 14/Times-Bold@0 SF(Intr)5.5 E(oduction)-.252 E F0=0A=
(This document describes a massi)72 101.6 Q -.165(ve)-.275 G=0A=
(ly scalable reliable content deli).165 E -.165(ve)-.275 G=0A=
(ry protocol, Asynchronous).165 E=0A=
(Layered Coding \(ALC\), for multi-rate reliable content deli)72 114.6 Q=0A=
-.165(ve)-.275 G(ry).165 E 5.5(.A)-.715 G=0A=
(LC is a protocol instantiation)-5.5 E=0A=
(as de\214ned in RFC3048. ALC uses the LCT transport [3]. Thus, lik)72=0A=
127.6 Q 2.75(et)-.11 G(he LCT transport, the ALC)-2.75 E=0A=
(protocol is primarily designed to be used with the IP multicast netw)72=0A=
140.6 Q(ork service, b)-.11 E(ut MA)-.22 E 2.75(Ya)-1.155 G(lso be)-2.75=0A=
E(used with other basic underlying netw)72 153.6 Q=0A=
(ork or transport services such as unicast UDP)-.11 E 5.5(.A)-1.221 G=0A=
(LC uses)-5.5 E(FEC codes to pro)72 166.6 Q=0A=
(vide reliability as generally described in [1], i.e. all pack)-.165 E=0A=
(ets in a session contain)-.11 E=0A=
(FEC coded information in formats that are compliant with the FEC b)72=0A=
179.6 Q(uilding block described in)-.22 E 2.75([2]. A)72 192.6 R(crucia\=0A=
l point is that ALC strongly relies on FEC codecs in the sense that the\=0A=
re is no)2.75 E(request for retransmission of indi)72 205.6 Q=0A=
(vidual pack)-.275 E(ets from recei)-.11 E -.165(ve)-.275 G=0A=
(rs that miss pack).165 E(ets in order to assure)-.11 E=0A=
(reliable reception of an object, and the pack)72 218.6 Q=0A=
(ets and their rate of transmission out of the sender can)-.11 E=0A=
(be independent of the number and the indi)72 231.6 Q=0A=
(vidual reception e)-.275 E(xperiences of the recei)-.165 E -.165(ve)=0A=
-.275 G 2.75(rs. In).165 F(some)2.75 E(deli)72 244.6 Q -.165(ve)-.275 G=0A=
(ry service models it is appropriate that recei).165 E -.165(ve)-.275 G=0A=
(rs send out of band messages to the sender to).165 E(pro)72 257.6 Q=0A=
(vide guaranteed deli)-.165 E -.165(ve)-.275 G(ry of content.).165 E=0A=
-.165(Fo)5.5 G 2.75(re).165 G(xample, in a push reliable deli)-2.915 E=0A=
-.165(ve)-.275 G(ry model recei).165 E -.165(ve)-.275 G(rs).165 E=0A=
(may send messages to a sender to continue the session if recei)72 270.6=0A=
Q -.165(ve)-.275 G(rs ha).165 E .33 -.165(ve n)-.22 H(ot yet recei).165=0A=
E -.165(ve)-.275 G 2.75(de).165 G(nough)-2.75 E(pack)72 283.6 Q=0A=
(ets to reco)-.11 E -.165(ve)-.165 G 2.75(rt).165 G=0A=
(he content or to terminate the session when recei)-2.75 E -.165(ve)=0A=
-.275 G(rs ha).165 E .33 -.165(ve r)-.22 H(ecei).165 E -.165(ve)-.275 G=0A=
2.75(de).165 G(nough)-2.75 E(pack)72 296.6 Q(ets to reco)-.11 E -.165=0A=
(ve)-.165 G 2.75(rt).165 G(he content.)-2.75 E 1.76 -.88(To b)5.5 H 2.75=0A=
(ea).88 G(ble to track usage of the system, recei)-2.75 E -.165(ve)-.275=0A=
G(rs may also send).165 E(messages out of band to the sender that conta\=0A=
in statistics on their reception e)72 309.6 Q(xperience. ALC,)-.165 E=0A=
(ho)72 322.6 Q(we)-.275 E -.165(ve)-.275 G .88 -.44(r, d).165 H=0A=
(oes not require nor specify such messages, with the aim of a).44 E -.22=0A=
(vo)-.22 G(iding unnecessary).22 E=0A=
(limitation to the scalability of the basic ALC protocol.)72 335.6 Q=0A=
(The LCT transport pro)72 361.6 Q=0A=
(vides support for congestion control, and the ALC protocol uses this)=0A=
-.165 E 2.75(support. The)72 374.6 R=0A=
(congestion control protocol must conform with RFC 2357.)2.75 E=0A=
(It is recommended that)5.5 E(the congestion control protocol used for \=0A=
ALC be a multi-rate protocol, as described in [4]. In this)72 387.6 Q=0A=
(case, a sender sends pack)72 400.6 Q(ets in the session to se)-.11 E=0A=
-.165(ve)-.275 G(ral LCT channels at potentially dif).165 E=0A=
(ferent rates.)-.275 E(Then, indi)72 413.6 Q(vidual recei)-.275 E -.165=0A=
(ve)-.275 G(rs can adjust their reception rate within a session by adju\=0A=
sting which set).165 E(of LCT channels the)72 426.6 Q 2.75(ya)-.165 G=0A=
(re joined to at each point in time depending on the a)-2.75 E -.275(va)=0A=
-.22 G(ilable bandwidth).275 E(between the recei)72 439.6 Q -.165(ve)=0A=
-.275 G 2.75(ra).165 G(nd the sender)-2.75 E 2.75(,b)-.44 G=0A=
(ut independent of other recei)-2.97 E -.165(ve)-.275 G 2.75(rs. A).165=0A=
F(single rate congestion)2.75 E(control protocol can also be used, b)72=0A=
452.6 Q=0A=
(ut this may limit the scalability of the session in terms of the)-.22 E=0A=
(number of recei)72 465.6 Q -.165(ve)-.275 G=0A=
(rs that can concurrently participate.).165 E(Recei)72 491.6 Q -.165(ve)=0A=
-.275 G 2.75(rm).165 G(ay join and lea)-2.75 E .33 -.165(ve a s)-.22 H=0A=
(ession asynchronously at their discretion.).165 E(An ALC pack)72 517.6=0A=
Q(et thus consists of an LCT pack)-.11 E(et header)-.11 E 2.75(,a)-.44 G=0A=
2.75(nF)-2.75 G(EC pack)-2.75 E(et header)-.11 E 2.75(,o)-.44 G=0A=
(ptional by)-2.75 E(additional parameters and pack)72 530.6 Q=0A=
(et payload.)-.11 E(ALC has the follo)72 556.6 Q=0A=
(wing properties when the LCT transport uses multicast to deli)-.275 E=0A=
-.165(ve)-.275 G 2.75(rp).165 G(ack)-2.75 E(ets:)-.11 E 5.5(oT)72 586.2=0A=
S 2.75(oe)-6.38 G(ach recei)-2.75 E -.165(ve)-.275 G .88 -.44(r, i).165=0A=
H 2.75(ta).44 G(ppears as if though there is a dedicated session from t\=0A=
he sender to the)-2.75 E(recei)83 599.2 Q -.165(ve)-.275 G .88 -.44=0A=
(r, w).165 H(here the reception rate adjusts to congestion along the pa\=0A=
th from sender to recei).44 E -.165(ve)-.275 G -.605(r.).165 G 5.5(oT)72=0A=
615.8 S 2.75(ot)-6.38 G(he sender)-2.75 E 2.75(,t)-.44 G(here is no dif)=0A=
-2.75 E(ference in load or outgoing rate if one recei)-.275 E -.165(ve)=0A=
-.275 G 2.75(ri).165 G 2.75(sj)-2.75 G(oined to the)-2.75 E=0A=
(session or a million \(or an)83 628.8 Q 2.75(yn)-.165 G=0A=
(umber of\) recei)-2.75 E -.165(ve)-.275 G=0A=
(rs are joined to the session, independent of when).165 E(the recei)83=0A=
641.8 Q -.165(ve)-.275 G(rs join and lea).165 E -.165(ve)-.22 G(.).165 E=0A=
5.5(oO)72 658.4 S 2.75(ne)-5.5 G(ach link in the netw)-2.75 E=0A=
(ork, the pack)-.11 E(et traf)-.11 E=0A=
(\214c from the session and its reaction to competing)-.275 E(traf)83=0A=
671.4 Q(\214c is the same whether there is one recei)-.275 E -.165(ve)=0A=
-.275 G 2.75(ro).165 G 2.75(ram)-2.75 G(illion recei)-2.75 E -.165(ve)=0A=
-.275 G(rs be).165 E(yond the link.)-.165 E(Thus, ALC pro)83 697.4 Q=0A=
(vides a massi)-.165 E -.165(ve)-.275 G(ly scalable content deli).165 E=0A=
-.165(ve)-.275 G(ry system that is netw).165 E(ork friendly)-.11 E(.)=0A=
-.715 E(The k)83 723.4 Q .33 -.165(ey w)-.11 H(ords "MUST", "MUST NO)=0A=
.055 E(T", "REQ)-.44 E(UIRED", "SHALL", "SHALL NO)-.11 E(T",)-.44 E=0A=
(Luby/Gemmell/V)72 769 Q(icisano/Rizzo/Cro)-.66 E 157.517=0A=
(wcroft Section)-.275 F 2.75(1. [P)2.75 F(age 3])-.165 E EP=0A=
%%Page: 4 4=0A=
%%BeginPageSetup=0A=
BP=0A=
%%EndPageSetup=0A=
/F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 71.587(-DRAFT Expires:)-1.012 F=0A=
(January 2002)2.75 E(July 2001)123.726 E("SHOULD", "SHOULD NO)83 85 Q=0A=
(T", "RECOMMENDED", "MA)-.44 E(Y", and "OPTION)-1.155 E(AL" in this)=0A=
-.385 E(document are to be interpreted as described in RFC2119.)83 98 Q=0A=
/F1 11/Times-Bold@0 SF(1.1.)72 137 Q/F2 13/Times-Bold@0 SF=0A=
(Related Documents)5.5 E F0=0A=
(The LCT transport that ALC MUST use is described in [3].)72 153.6 Q=0A=
2.75(Am)5.5 G(ore in-depth description of the)-2.75 E=0A=
(use of FEC codecs in reliable content deli)72 166.6 Q -.165(ve)-.275 G=0A=
(ry protocols is gi).165 E -.165(ve)-.275 G 2.75(ni).165 G 2.75(n[)-2.75=0A=
G(1]. All pack)-2.75 E(ets in a session)-.11 E(MUST contain FEC coded i\=0A=
nformation in formats that are compliant with the FEC b)72 179.6 Q=0A=
(uilding block)-.22 E(described in [2].)72 192.6 Q(Implementors of ALC \=0A=
MUST also implement a congestion control protocol in)5.5 E=0A=
(accordance to RFC2357, where the congestion control is o)72 205.6 Q=0A=
-.165(ve)-.165 G 2.75(rt).165 G(he entire session.)-2.75 E=0A=
(Some possible)5.5 E=0A=
(schemes are speci\214ed in [4]. Congestion control MUST be inte)72=0A=
218.6 Q(grated into ALC through the)-.165 E(support pro)72 231.6 Q=0A=
(vided in the LCT transport.)-.165 E(It is RECOMMENDED that ALC impleme\=0A=
ntors use some authentication scheme to protect the)72 257.6 Q=0A=
(protocol from attacks. An e)72 270.6 Q=0A=
(xample of a possibly suitable scheme is described in [5].)-.165 E=0A=
(Authentication in ALC, if used, is to be inte)72 283.6 Q=0A=
(grated through the support pro)-.165 E(vided in the LCT)-.165 E=0A=
(transport.)72 296.6 Q F1(1.2.)72 335.6 Q F2(En)5.5 E(vir)-.52 E=0A=
(onmental Requir)-.234 E(ements and Considerations)-.234 E F0=0A=
(ALC is intended for congestion controlled, multi-rate deli)72 352.2 Q=0A=
-.165(ve)-.275 G(ry of objects, i.e., reliable content).165 E(deli)72=0A=
365.2 Q -.165(ve)-.275 G(ry).165 E(.)-.715 E(All of the en)72 391.2 Q(v\=0A=
ironmental requirements and considerations that apply to the LCT transp\=0A=
ort and to)-.44 E(the FEC b)72 404.2 Q(uilding block also apply to ALC.)=0A=
-.22 E F1(2.)72 443.2 Q/F3 14/Times-Bold@0 SF(General Ar)5.5 E=0A=
(chitectur)-.252 E(e)-.252 E F0(ALC protocol consists basically of usin\=0A=
g FEC codecs in the form described in [2] with the LCT)72 459.8 Q(trans\=0A=
port as described in [3]. Thus, the terminology used in the description\=0A=
of the LCT transport)72 472.8 Q(and the FEC b)72 485.8 Q(uilding block\=0A=
are inherited by the ALC protocol and this terminology is used belo)=0A=
-.22 E -.715(w.)-.275 G(In particular)72 498.8 Q 2.75(,t)-.44 G(he de\=0A=
\214nition of a session for the ALC protocol is the same as it is for t\=0A=
he LCT)-2.75 E(transport.)72 511.8 Q -.165(Pa)72 537.8 S(ck).165 E=0A=
(ets used within the ALC protocol are specialized v)-.11 E=0A=
(ersions of LCT pack)-.165 E 2.75(ets. In)-.11 F(particular)2.75 E 2.75=0A=
(,a)-.44 G(pack)72 550.8 Q(et consists of an LCT pack)-.11 E(et header)=0A=
-.11 E 2.75(,a)-.44 G 2.75(nF)-2.75 G=0A=
(EC payload ID, optional additional parameters as)-2.75 E=0A=
(appropriate, and the pack)72 563.8 Q(et payload.)-.11 E=0A=
(From the point of vie)5.5 E 2.75(wo)-.275 G 2.75(ft)-2.75 G=0A=
(he LCT transport, the FEC)-2.75 E=0A=
(payload ID, the additional parameters if present, and the pack)72 576.8=0A=
Q(et payload are all part of the LCT)-.11 E(pack)72 589.8 Q(et payload.)=0A=
-.11 E(The out of band information used by the ALC protocol consists of\=0A=
the out of band all information)72 615.8 Q=0A=
(required for both the LCT transport and for the FEC b)72 628.8 Q=0A=
(uilding block.)-.22 E(The possible means for)5.5 E(acquiring this out \=0A=
of band information is the same as for the LCT transport and the FEC b)=0A=
72 641.8 Q(uilding)-.22 E=0A=
(block, and in particular is outside the scope of the ALC protocol.)72=0A=
654.8 Q(Congestion control for the ALC protocol MUST conform to RFC 238\=0A=
7, and MUST be pro)72 680.8 Q(vided)-.165 E(through the mechanisms pro)=0A=
72 693.8 Q(vided by the LCT transport.)-.165 E=0A=
(Although it is not mandatory)5.5 E 2.75(,A)-.715 G(LC is)-2.75 E(most \=0A=
scalable when multi-rate congestion control is used that does not requi\=0A=
re feedback from)72 706.8 Q(recei)72 719.8 Q -.165(ve)-.275 G=0A=
(rs to the sender).165 E 2.75(,a)-.44 G=0A=
(nd thus use of a mult-rate congestion control as described in [4] is)=0A=
-2.75 E(Luby/Gemmell/V)72 769 Q(icisano/Rizzo/Cro)-.66 E 157.517=0A=
(wcroft Section)-.275 F 2.75(2. [P)2.75 F(age 4])-.165 E EP=0A=
%%Page: 5 5=0A=
%%BeginPageSetup=0A=
BP=0A=
%%EndPageSetup=0A=
/F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 71.587(-DRAFT Expires:)-1.012 F=0A=
(January 2002)2.75 E(July 2001)123.726 E(RECOMMENDED.)72 85 Q/F1 11=0A=
/Times-Bold@0 SF(2.1.)72 124 Q/F2 13/Times-Bold@0 SF(Deli)5.5 E -.13(ve)=0A=
-.13 G(ry ser).13 E(vice models)-.13 E F0(ALC can support se)72 140.6 Q=0A=
-.165(ve)-.275 G(ral dif).165 E(ferent deli)-.275 E -.165(ve)-.275 G=0A=
(ry service models. T).165 E .22 -.11(wo e)-.88 H=0A=
(xamples are brie\215y described)-.055 E(here.)72 153.6 Q F1(Push ser)72=0A=
192.6 Q(vice model.)-.11 E F0(One w)72 209.2 Q=0A=
(ay a push service model can be used for reliable content deli)-.11 E=0A=
-.165(ve)-.275 G(ry is to deli).165 E -.165(ve)-.275 G 2.75(ras).165 G=0A=
(eries of)-2.75 E 2.75(objects. F)72 222.2 R(or e)-.165 E=0A=
(xample, a recei)-.165 E -.165(ve)-.275 G 2.75(rc).165 G=0A=
(ould join the session and dynamically adapt the number of LCT)-2.75 E=0A=
(channels the recei)72 235.2 Q -.165(ve)-.275 G 2.75(ri).165 G 2.75(sj)=0A=
-2.75 G(oined to until enough pack)-2.75 E(ets ha)-.11 E .33 -.165(ve b)=0A=
-.22 H(een recei).165 E -.165(ve)-.275 G 2.75(dt).165 G 2.75(or)-2.75 G=0A=
(econstruct an)-2.75 E=0A=
(object. After reconstructing the object the recei)72 248.2 Q -.165(ve)=0A=
-.275 G 2.75(rm).165 G(ay stay in the session and w)-2.75 E(ait for the)=0A=
-.11 E(transmission of the ne)72 261.2 Q(xt object.)-.165 E=0A=
(The push model is particularly attracti)72 287.2 Q .33 -.165(ve i)-.275=0A=
H 2.75(ns).165 G(atellite netw)-2.75 E(orks and wireless netw)-.11 E=0A=
2.75(orks. In)-.11 F(these)2.75 E=0A=
(cases, a session may consist of one \214x)72 300.2 Q=0A=
(ed rate LCT channel.)-.165 E F1(On-demand content deli)72 339.2 Q -.11=0A=
(ve)-.11 G(ry model.).11 E F0 -.165(Fo)72 355.8 S 2.75(ra).165 G 2.75=0A=
(no)-2.75 G(n-demand content deli)-2.75 E -.165(ve)-.275 G=0A=
(ry service model, senders typically transmit for some gi).165 E -.165=0A=
(ve)-.275 G 2.75(nt).165 G(ime)-2.75 E=0A=
(period selected to be long enough to allo)72 368.8 Q 2.75(wa)-.275 G=0A=
(ll the intended recei)-2.75 E -.165(ve)-.275 G=0A=
(rs to join the session and).165 E(reco)72 381.8 Q -.165(ve)-.165 G 2.75=0A=
(ras).165 G(ingle object.)-2.75 E -.165(Fo)5.5 G 2.75(re).165 G=0A=
(xample a popular softw)-2.915 E=0A=
(are update might be transmitted using ALC)-.11 E(for se)72 394.8 Q=0A=
-.165(ve)-.275 G(ral days, e).165 E -.165(ve)-.275 G 2.75(nt).165 G=0A=
(hough a recei)-2.75 E -.165(ve)-.275 G 2.75(rm).165 G=0A=
(ay be able to complete the do)-2.75 E(wnload in one hour total)-.275 E=0A=
(of connection time, perhaps spread o)72 407.8 Q -.165(ve)-.165 G 2.75=0A=
(rs).165 G -2.365 -.275(ev e)-2.75 H(ral interv).275 E(als of time.)=0A=
-.275 E(In this case the recei)72 433.8 Q -.165(ve)-.275 G=0A=
(rs join the session at an).165 E 2.75(yp)-.165 G=0A=
(oint in time when it is acti)-2.75 E .33 -.165(ve a)-.275 H=0A=
(nd dynamically).165 E(adapt the number of LCT channels the)72 446.8 Q=0A=
2.75(ys)-.165 G(ubscribe to according to the a)-2.75 E -.275(va)-.22 G=0A=
(ilable bandwidth using a).275 E=0A=
(multi-rate congestion control protocol. Recei)72 459.8 Q -.165(ve)-.275=0A=
G(rs lea).165 E .33 -.165(ve t)-.22 H(he session when the).165 E 2.75=0A=
(yh)-.165 G -2.475 -.22(av e)-2.75 H(recei)2.97 E -.165(ve)-.275 G(d)=0A=
.165 E(enough pack)72 472.8 Q(ets to reco)-.11 E -.165(ve)-.165 G 2.75=0A=
(rt).165 G(he object.)-2.75 E F1(Other ser)72 511.8 Q(vice models.)-.11=0A=
E F0(There may be other deli)72 541.4 Q -.165(ve)-.275 G=0A=
(ry service models that can be supported by ALC.).165 E=0A=
(The description of)5.5 E=0A=
(the potential applications, the appropriate deli)72 554.4 Q -.165(ve)=0A=
-.275 G(ry service model, and the additional mechanisms).165 E=0A=
(to support such functionalities when combined with ALC is be)72 567.4 Q=0A=
(yond the scope of this document.)-.165 E F1(2.2.)72 606.4 Q F2=0A=
(Congestion Contr)5.5 E(ol)-.234 E F0(The speci\214c congestion control\=0A=
protocol to be used for ALC sessions should be suitable for)72 623 Q=0A=
(reliable content deli)72 636 Q -.165(ve)-.275 G(ry).165 E 5.5(.W)-.715=0A=
G(hile the general beha)-5.5 E=0A=
(vior of the congestion control protocol is to)-.22 E(reduce the throug\=0A=
hput in presence of congestion and gradually increase it in the absence\=0A=
of)72 649 Q(congestion, the actual dynamic beha)72 662 Q=0A=
(vior \(e.g. response to single losses\) can v)-.22 E(ary)-.275 E(.)=0A=
-.715 E(Some possible multi-rate congestion control protocols for relia\=0A=
ble content deli)72 688 Q -.165(ve)-.275 G(ry using LCT are).165 E=0A=
(described in [4].)72 701 Q(Luby/Gemmell/V)72 769 Q(icisano/Rizzo/Cro)=0A=
-.66 E 149.267(wcroft Section)-.275 F 2.75(2.2. [P)2.75 F(age 5])-.165 E=0A=
EP=0A=
%%Page: 6 6=0A=
%%BeginPageSetup=0A=
BP=0A=
%%EndPageSetup=0A=
/F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 71.587(-DRAFT Expires:)-1.012 F=0A=
(January 2002)2.75 E(July 2001)123.726 E/F1 11/Times-Bold@0 SF(3.)72 85=0A=
Q/F2 14/Times-Bold@0 SF -1.036(Ty)5.5 G(pe of pack)1.036 E=0A=
(ets used by the ALC pr)-.14 E(otocol)-.252 E F0(The type of pack)72=0A=
101.6 Q(et used by the ALC protocol is a specialized v)-.11 E=0A=
(ersion of an LCT pack)-.165 E 2.75(et. LCT)-.11 F(pack)72 114.6 Q=0A=
(ets are sent by senders to LCT channels.)-.11 E=0A=
(Some instances of sessions MA)72 140.6 Q 2.75(Yr)-1.155 G=0A=
(equire the generation of feedback from the recei)-2.75 E -.165(ve)-.275=0A=
G(rs to the).165 E(sender)72 153.6 Q 5.5(.H)-.605 G -.275(ow)-5.5 G=0A=
-2.365 -.275(ev e).275 H .88 -.44(r, t).275 H=0A=
(he mechanism for doing this is outside the scope of ALC.).44 E F1(3.1.)=0A=
72 192.6 Q/F3 13/Times-Bold@0 SF -.13(Pa)5.5 G(ck).13 E(et f)-.13 E=0A=
(ormat f)-.325 E(or the ALC pr)-.325 E(otocol)-.234 E F0(The pack)72=0A=
209.2 Q(et format used for ALC protocol is depicted in Figure 1.)-.11 E=0A=
/F4 8/Courier@0 SF 91.2(0123)81.6 248.2 S 4.8=0A=
(01234567890123456789012345678901)81.6 261.2 S=0A=
(+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+)76.8=0A=
274.2 Q 105.6(|L)76.8 287.2 S(CT packet header)-105.6 E(|)115.2 E 302.4=0A=
(||)76.8 300.2 S=0A=
(+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D=
+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+)76.8=0A=
313.2 Q 110.4(|F)76.8 326.2 S(EC Payload ID)-110.4 E(|)124.8 E 302.4(||)=0A=
76.8 339.2 S=0A=
(+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D=
+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+)76.8=0A=
352.2 Q 100.8(|A)76.8 365.2 S(dditional parameters)-100.8 E(|)100.8 E=0A=
124.8(|\()76.8 378.2 S 124.8(optional\) |)-124.8 F=0A=
(+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D=
+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+)76.8=0A=
391.2 Q 129.6(|P)76.8 404.2 S 134.4(ayload |)-129.6 F 302.4(||)76.8=0A=
417.2 S 302.4(||)76.8 430.2 S=0A=
(+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+)76.8=0A=
443.2 Q/F5 10/Times-Roman@0 SF(Figure 1 - P)72 482.2 Q(ack)-.15 E=0A=
(et format for ALC protocol)-.1 E F1(3.2.)72 521.2 Q F3 -.13(Pa)5.5 G=0A=
(ck).13 E(et header \214elds f)-.13 E(or the ALC pr)-.325 E(otocol)-.234=0A=
E F0(The description of the \214elds and their functions within the LCT\=0A=
pack)72 537.8 Q(et header can be found in [3].)-.11 E(The information \=0A=
that needs to be communicated out of band for the LCT transport and the)=0A=
72 550.8 Q(possible mechanisms for achie)72 563.8 Q=0A=
(ving this are described in [3].)-.275 E(The description of the \214eld\=0A=
s and their functions within the FEC payload ID can be found in [2],)72=0A=
580.4 Q(with the e)72 593.4 Q(xception that the FEC Encoding Flag v)=0A=
-.165 E(alue, if applicable, MA)-.275 E 2.75(Yb)-1.155 G 2.75(ec)-2.75 G=0A=
(ommunicated via)-2.75 E(the v)72 606.4 Q=0A=
(alue of the Codepoint \214eld within LCT pack)-.275 E(et header)-.11 E=0A=
5.5(.T)-.605 G(he information that needs to be)-5.5 E(communicated out \=0A=
of band for the FEC codecs and the possible mechanisms for achie)72=0A=
619.4 Q(ving this are)-.275 E(described in [2]. The mechanisms for comm\=0A=
unicating the out of band information needed for the)72 632.4 Q=0A=
(LCT transport, including the mapping between the Codepoint \214eld v)72=0A=
645.4 Q(alues in the LCT pack)-.275 E(et)-.11 E=0A=
(header and the interpretations of the v)72 658.4 Q(alues, MA)-.275 E=0A=
2.75(Yb)-1.155 G 2.75(et)-2.75 G=0A=
(he same as those used for communicating)-2.75 E=0A=
(the out of band information needed for the FEC b)72 671.4 Q=0A=
(uilding block, with the e)-.22 E(xception that portions)-.165 E=0A=
(of the information needed for FEC b)72 684.4 Q=0A=
(uilding blocks may be communicated either through the use)-.22 E=0A=
(of the Codepoint \214eld in the LCT pack)72 697.4 Q(et header)-.11 E=0A=
2.75(,o)-.44 G 2.75(rt)-2.75 G(hrough the Additional P)-2.75 E=0A=
(arameters \214elds that)-.165 E(follo)72 710.4 Q 2.75(wt)-.275 G=0A=
(he FEC payload ID.)-2.75 E(Luby/Gemmell/V)72 769 Q(icisano/Rizzo/Cro)=0A=
-.66 E 149.267(wcroft Section)-.275 F 2.75(3.2. [P)2.75 F(age 6])-.165 E=0A=
EP=0A=
%%Page: 7 7=0A=
%%BeginPageSetup=0A=
BP=0A=
%%EndPageSetup=0A=
/F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 71.587(-DRAFT Expires:)-1.012 F=0A=
(January 2002)2.75 E(July 2001)123.726 E=0A=
(The \214elds and formats of the optional Additional P)72 85 Q=0A=
(arameters \214elds MUST be communicated to)-.165 E(the recei)72 98 Q=0A=
-.165(ve)-.275 G(rs out of band.).165 E(The particular Additional P)5.5=0A=
E(arameters \214elds that may appear in pack)-.165 E(ets)-.11 E=0A=
(MUST be communicated out of band.)72 111 Q=0A=
(The speci\214cation of which Additional P)5.5 E(arameters \214elds)=0A=
-.165 E(that appear in a pack)72 124 Q=0A=
(et MUST be communicated via the v)-.11 E=0A=
(alue of the Codepoint \214eld in the LCT)-.275 E(pack)72 137 Q=0A=
(et header)-.11 E 2.75(,a)-.44 G=0A=
(nd the mapping between Codepoint \214eld v)-2.75 E=0A=
(alues and the Additional P)-.275 E(arameters)-.165 E=0A=
(\214elds that appear in a pack)72 150 Q=0A=
(et MUST be communicated out of band.)-.11 E(It is RECOMMENDED that)5.5=0A=
E(the format of an)72 163 Q 2.75(yA)-.165 G(dditonal P)-2.75 E=0A=
(arameters \214elds adhere to the format of Header)-.165 E=0A=
(-Extension Fields)-.22 E(de\214ned for the LCT transport in [3].)72 176=0A=
Q/F1 11/Times-Bold@0 SF(4.)72 202 Q/F2 14/Times-Bold@0 SF(Pr)5.5 E=0A=
(ocedur)-.252 E(es)-.252 E F1(4.1.)72 241 Q/F3 13/Times-Bold@0 SF=0A=
(Sender Operation)5.5 E F0(The sender operation when using the ALC prot\=0A=
ocol includes all the points made about the sender)72 257.6 Q(operation\=0A=
when using the LCT transport as described in [3], and the FEC b)72=0A=
270.6 Q(uilding block as)-.22 E(described in [2]. The follo)72 283.6 Q(\=0A=
wing description highlights some of the additional considerations to be)=0A=
-.275 E(tak)72 296.6 Q=0A=
(en into account with respect to the ALC protocol.)-.11 E=0A=
(Before a session starts, a sender using the ALC protocol MUST mak)72=0A=
322.6 Q 2.75(ea)-.11 G -.275(va)-2.97 G(ilable all applicable).275 E=0A=
(information re)72 335.6 Q -.055(ga)-.165 G(rding the session.).055 E=0A=
(This information includes:)5.5 E 11(oA)77.5 352.2 S .33 -.165(ny i)-11=0A=
H(nformation needed by the LCT transport;).165 E 11(oT)77.5 368.8 S=0A=
(he congestion control protocol being used within the LCT transport;)-11=0A=
E 11(oT)77.5 385.4 S(he mapping between v)-11 E=0A=
(alues of the Codepoint \214eld in the LCT pack)-.275 E(et header and)=0A=
-.11 E(interpretations of these v)94 398.4 Q(alues;)-.275 E 11(oA)77.5=0A=
415 S .33 -.165(ny i)-11 H(nformation needed for the FEC b).165 E=0A=
(uilding block;)-.22 E 11(oI)77.5 431.6 S 2.75(fu)-11 G(sed, the authen\=0A=
tication scheme being used within the LCT transport, and all rele)-2.75=0A=
E -.275(va)-.275 G(nt).275 E=0A=
(information which is necessary for sender authentication purposes;)94=0A=
444.6 Q F1(4.2.)72 483.6 Q F3(Recei)5.5 E -.13(ve)-.13 G 3.25(rO).13 G=0A=
(peration)-3.25 E F0(The recei)72 500.2 Q -.165(ve)-.275 G 2.75(ro).165=0A=
G(peration when using the ALC protocol includes all the points made abo\=0A=
ut the)-2.75 E(recei)72 513.2 Q -.165(ve)-.275 G 2.75(ro).165 G=0A=
(peration that pertain to reliable content deli)-2.75 E -.165(ve)-.275 G=0A=
(ry when using the LCT transport as).165 E=0A=
(described in [3], and that pertain to using the FEC b)72 526.2 Q=0A=
(uilding block as described in [2]. The)-.22 E(follo)72 539.2 Q(wing de\=0A=
scription highlights some of the additional considerations to be tak)=0A=
-.275 E(en into account)-.11 E(with respect to the ALC protocol.)72=0A=
552.2 Q(When a recei)72 578.2 Q -.165(ve)-.275 G 2.75(rr).165 G(ecei)=0A=
-2.75 E -.165(ve)-.275 G 2.75(sap).165 G(ack)-2.75 E(et, the recei)-.11=0A=
E -.165(ve)-.275 G 2.75(rM).165 G(UST process the LCT pack)-2.75 E=0A=
(et header \(e)-.11 E(xcluding)-.165 E(the Codepoint \214eld\))72 591.2=0A=
Q(as described in [3] before processing an)5.5 E 2.75(yo)-.165 G=0A=
(ther \214elds of the pack)-2.75 E(et.)-.11 E F1(5.)72 630.2 Q F2=0A=
(Security Considerations)5.5 E F0(The same security consideration that \=0A=
apply to the LCT transport and to the FEC b)72 646.8 Q(uilding block)=0A=
-.22 E(also apply to the ALC protocol.)72 659.8 Q(In addition, an)5.5 E=0A=
2.75(ys)-.165 G(ecurity considerations that apply to the)-2.75 E(conges\=0A=
tion control protocol used by the ALC protocol within the LCT transport\=0A=
also apply)72 672.8 Q(.)-.715 E(Luby/Gemmell/V)72 769 Q=0A=
(icisano/Rizzo/Cro)-.66 E 157.517(wcroft Section)-.275 F 2.75(5. [P)2.75=0A=
F(age 7])-.165 E EP=0A=
%%Page: 8 8=0A=
%%BeginPageSetup=0A=
BP=0A=
%%EndPageSetup=0A=
/F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 71.587(-DRAFT Expires:)-1.012 F=0A=
(January 2002)2.75 E(July 2001)123.726 E/F1 11/Times-Bold@0 SF(6.)72 85=0A=
Q/F2 14/Times-Bold@0 SF(IAN)5.5 E 3.5(AC)-.28 G(onsiderations)-3.5 E F0=0A=
(No information in this speci\214cation is directly subject to IAN)72=0A=
101.6 Q 2.75(Ar)-.385 G -.165(eg)-2.75 G 2.75(istration. Ho).165 F(we)=0A=
-.275 E -.165(ve)-.275 G .88 -.44(r, b).165 H(uilding).22 E=0A=
(blocks components used by the ALC protcol may introduce additional IAN)=0A=
72 114.6 Q 2.75(Ac)-.385 G 2.75(onsiderations. In)-2.75 F(particular)72=0A=
127.6 Q 2.75(,t)-.44 G(he FEC b)-2.75 E=0A=
(uilding block used by the ALC protocol does require IAN)-.22 E 2.75(Ar)=0A=
-.385 G -.165(eg)-2.75 G(istration of).165 E(the FEC codecs used.)72=0A=
140.6 Q F1(7.)72 179.6 Q F2(Intellectual Pr)5.5 E(operty Issues)-.252 E=0A=
F0(No speci\214c reliability protocol or congestion control protocol is\=0A=
speci\214ed or referenced as)72 209.2 Q(mandatory in this document.)72=0A=
222.2 Q(ALC MA)72 248.2 Q 2.75(Yb)-1.155 G 2.75(eu)-2.75 G(sed with con\=0A=
gestion control protocols and other protocols which are proprietary)=0A=
-2.75 E(,)-.715 E(or ha)72 261.2 Q .33 -.165(ve p)-.22 H=0A=
(ending or granted patents.).165 E([1] Luby)72 303.8 Q 2.75(,M)-.715 G=0A=
(., Gemmell, V)-2.75 E(icisano, L., J., Rizzo, L., Handle)-.66 E 1.43=0A=
-.715(y, M)-.165 H(., Cro).715 E(wcroft, J., "The use of)-.275 E -.165=0A=
(Fo)72 316.8 S(rw).165 E(ard Error Correction in Reliable Multicast", I\=0A=
nternet Draft draft-ietf-rmt-info-fec-00.txt,)-.11 E(No)72 329.8 Q -.165=0A=
(ve)-.165 G(mber 2000, a w).165 E(ork in progress.)-.11 E([2] Luby)72=0A=
355.8 Q 2.75(,M)-.715 G(., Gemmell, J., V)-2.75 E=0A=
(icisano, L., Rizzo, L., Handle)-.66 E 1.43 -.715(y, M)-.165 H(., Cro)=0A=
.715 E(wcroft, J., "RMT BB)-.275 E -.165(Fo)72 368.8 S(rw).165 E(ard Er\=0A=
ror Correction Codes", Internet Draft draft-ietf-rmt-bb-fec-03.txt, Jul\=0A=
y 2001.)-.11 E([3] Luby)72 394.8 Q 2.75(,M)-.715 G(., Gemmell, J., V)=0A=
-2.75 E(icisano, L., Rizzo, L., Handle)-.66 E 1.43 -.715(y, M)-.165 H=0A=
(., Cro).715 E(wcroft, J., "Layered Coding)-.275 E -.385(Tr)72 407.8 S=0A=
(ansport: A massi).385 E -.165(ve)-.275 G(ly scalable content deli).165=0A=
E -.165(ve)-.275 G(ry transport", Internet Draft draft-ietf-rmt-bb-).165=0A=
E(lct-01.txt, July 2001.)72 420.8 Q([4] Luby)72 446.8 Q 2.75(,M)-.715 G=0A=
(., V)-2.75 E(icisano, L., Hak)-.66 E=0A=
(en, A., "RMT BB Layered congestion control", draft-ietf-rmt-bb-)-.11 E=0A=
(lcc-00.txt, No)72 459.8 Q -.165(ve)-.165 G(mber 2000, a w).165 E=0A=
(ork in progress.)-.11 E([5] Perrig, A., Canetti, R., Briscoe, B., T)72=0A=
485.8 Q(yg)-.88 E(ar)-.055 E 2.75(,D)-.44 G=0A=
(., Song, D., "TESLA: Multicast Source)-2.75 E(Authentication T)72 498.8=0A=
Q(ransform", draft-irtf-smug-tesla-00.txt, No)-.385 E -.165(ve)-.165 G=0A=
(mber).165 E 2.75(,2)-.44 G(000, a w)-2.75 E(ork in progress.)-.11 E F1=0A=
(8.)72 550.8 Q F2 -.7(Au)5.5 G(thors' Addr).7 E(esses)-.252 E F0=0A=
(Michael Luby)80.25 567.4 Q(luby@digitalfountain.com)80.25 580.4 Q=0A=
(Digital F)80.25 593.4 Q(ountain)-.165 E(39141 Ci)80.25 606.4 Q=0A=
(vic Center Dri)-.275 E -.165(ve)-.275 G(Suite 300)80.25 619.4 Q=0A=
(Fremont, CA, USA, 94538)80.25 632.4 Q(Jim Gemmell)80.25 658.4 Q=0A=
(jgemmell@microsoft.com)80.25 671.4 Q(Microsoft Research)80.25 684.4 Q=0A=
(301 Ho)80.25 697.4 Q -.11(wa)-.275 G(rd St., #830).11 E=0A=
(San Francisco, CA, USA, 94105)80.25 710.4 Q(Luby/Gemmell/V)72 769 Q=0A=
(icisano/Rizzo/Cro)-.66 E 157.517(wcroft Section)-.275 F 2.75(8. [P)2.75=0A=
F(age 8])-.165 E EP=0A=
%%Page: 9 9=0A=
%%BeginPageSetup=0A=
BP=0A=
%%EndPageSetup=0A=
/F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 71.587(-DRAFT Expires:)-1.012 F=0A=
(January 2002)2.75 E(July 2001)123.726 E(Lorenzo V)80.25 85 Q(icisano)=0A=
-.66 E(lorenzo@cisco.com)80.25 98 Q(cisco Systems, Inc.)80.25 111 Q=0A=
(170 W)80.25 124 Q(est T)-.88 E(asman Dr)-.88 E(.,)-.605 E=0A=
(San Jose, CA, USA, 95134)80.25 137 Q(Luigi Rizzo)80.25 163 Q=0A=
(luigi@iet.unipi.it)80.25 176 Q(Dip. Ing. dell'Informazione,)80.25 189 Q=0A=
(Uni)80.25 202 Q 1.43 -.715(v. d)-.275 H 2.75(iP).715 G(isa)-2.75 E=0A=
(via Diotisalvi 2, 56126 Pisa, Italy)80.25 215 Q(Jon Cro)80.25 241 Q=0A=
(wcroft)-.275 E(J.Cro)80.25 254 Q(wcroft@cs.ucl.ac.uk)-.275 E=0A=
(Department of Computer Science)80.25 267 Q(Uni)80.25 280 Q -.165(ve)=0A=
-.275 G(rsity Colle).165 E(ge London)-.165 E(Go)80.25 293 Q(wer Street,)=0A=
-.275 E(London WC1E 6BT)80.25 306 Q 2.75(,U)-.814 G(K)-2.75 E=0A=
(Luby/Gemmell/V)72 769 Q(icisano/Rizzo/Cro)-.66 E 157.517=0A=
(wcroft Section)-.275 F 2.75(8. [P)2.75 F(age 9])-.165 E EP=0A=
%%Page: 10 10=0A=
%%BeginPageSetup=0A=
BP=0A=
%%EndPageSetup=0A=
/F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 71.587(-DRAFT Expires:)-1.012 F=0A=
(January 2002)2.75 E(July 2001)123.726 E/F1 11/Times-Bold@0 SF(9.)72 85=0A=
Q/F2 14/Times-Bold@0 SF(Full Copyright Statement)5.5 E F0(Cop)72 101.6 Q=0A=
(yright \(C\) The Internet Society \(2000\).)-.11 E(All Rights Reserv)=0A=
5.5 E(ed.)-.165 E(This document and translations of it may be copied an\=0A=
d furnished to others, and deri)72 118.2 Q -.275(va)-.275 G(ti).275 E=0A=
.33 -.165(ve w)-.275 H(orks).055 E(that comment on or otherwise e)72=0A=
131.2 Q=0A=
(xplain it or assist in its implementation may be prepared, copied,)=0A=
-.165 E(published and distrib)72 144.2 Q=0A=
(uted, in whole or in part, without restriction of an)-.22 E 2.75(yk)=0A=
-.165 G(ind, pro)-2.75 E(vided that the)-.165 E(abo)72 157.2 Q .33 -.165=0A=
(ve c)-.165 H(op).165 E(yright notice and this paragraph are included o\=0A=
n all such copies and deri)-.11 E -.275(va)-.275 G(ti).275 E .33 -.165=0A=
(ve w)-.275 H(orks.).055 E(Ho)72 170.2 Q(we)-.275 E -.165(ve)-.275 G .88=0A=
-.44(r, t).165 H(his document itself may not be modi\214ed in an).44 E=0A=
2.75(yw)-.165 G(ay)-2.86 E 2.75(,s)-.715 G(uch as by remo)-2.75 E=0A=
(ving the)-.165 E(cop)72 183.2 Q(yright notice or references to the Int\=0A=
ernet Society or other Internet or)-.11 E -.055(ga)-.198 G(nizations, e)=0A=
.055 E(xcept as)-.165 E(needed for the purpose of de)72 196.2 Q -.165=0A=
(ve)-.275 G(loping Internet standards in which case the procedures for)=0A=
.165 E(cop)72 209.2 Q=0A=
(yrights de\214ned in the Internet languages other than English.)-.11 E=0A=
(The limited permissions granted abo)72 225.8 Q .33 -.165(ve a)-.165 H=0A=
(re perpetual and will not be re).165 E -.22(vo)-.275 G -.11(ke).22 G=0A=
2.75(db).11 G 2.75(yt)-2.75 G(he Internet)-2.75 E=0A=
(Society or its successors or assigns.)72 238.8 Q=0A=
(This document and the information contained herein is pro)72 255.4 Q=0A=
(vided on an "AS IS" basis and THE)-.165 E=0A=
(INTERNET SOCIETY AND THE INTERNET ENGINEERING T)72 268.4 Q=0A=
(ASK FORCE DISCLAIMS)-1.023 E(ALL W)72 281.4 Q=0A=
(ARRANTIES, EXPRESS OR IMPLIED, INCLUDING B)-1.32 E(UT NO)-.11 E 2.75=0A=
(TL)-.44 G(IMITED T)-2.75 E 2.75(OA)-.198 G(NY)-2.75 E -1.32(WA)72 294.4=0A=
S(RRANTY THA)1.32 E 2.75(TT)-1.221 G(HE USE OF THE INFORMA)-2.75 E=0A=
(TION HEREIN WILL NO)-1.221 E 2.75(TI)-.44 G(NFRINGE)-2.75 E=0A=
(ANY RIGHTS OR ANY IMPLIED W)72 307.4 Q(ARRANTIES OF MERCHANT)-1.32 E=0A=
(ABILITY OR FITNESS)-1.023 E(FOR A P)72 320.4 Q(AR)-1.012 E=0A=
(TICULAR PURPOSE.")-.66 E(Luby/Gemmell/V)72 769 Q(icisano/Rizzo/Cro)-.66=0A=
E 152.017(wcroft Section)-.275 F 2.75(9. [P)2.75 F(age 10])-.165 E EP=0A=
%%Page: 11 11=0A=
%%BeginPageSetup=0A=
BP=0A=
%%EndPageSetup=0A=
/F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 71.587(-DRAFT Expires:)-1.012 F=0A=
(January 2002)2.75 E(July 2001)123.726 E(Luby/Gemmell/V)72 769 Q=0A=
(icisano/Rizzo/Cro)-.66 E 152.017(wcroft Section)-.275 F 2.75(9. [P)2.75=0A=
F(age 11])-.165 E EP=0A=
%%Trailer=0A=
end=0A=
%%EOF=0A=
------=_NextPart_000_0002_01C11115.E3203A10--
>From owner-rmt@listserv.lbl.gov Fri Jul 20 13:49:49 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f6KKnQ729323;
Fri, 20 Jul 2001 13:49:26 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f6KKnOR29319
for <rmt@listserv.lbl.gov>; Fri, 20 Jul 2001 13:49:24 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f6KKnOp21118
for <rmt@listserv.lbl.gov>; Fri, 20 Jul 2001 13:49:24 -0700 (PDT)
Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f6KKnMA21110
for <rmt@lbl.gov>; Fri, 20 Jul 2001 13:49:22 -0700 (PDT)
Received: from [132.250.92.151] (manimac.itd.nrl.navy.mil [132.250.92.151])
by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id QAA05368;
Fri, 20 Jul 2001 16:48:20 -0400 (EDT)
Mime-Version: 1.0
X-Sender: adamson@pop.itd.nrl.navy.mil
Message-Id: <p0501040fb77e48da201a@[132.250.92.151]>
In-Reply-To: <NEBBIAPCNKEDCLPNFBNCAEPLCGAA.luby@digitalfountain.com>
References: <NEBBIAPCNKEDCLPNFBNCAEPLCGAA.luby@digitalfountain.com>
Date: Fri, 20 Jul 2001 16:48:21 -0400
To: <internet-drafts@ietf.org>
From: Brian Adamson <adamson@itd.nrl.navy.mil>
Subject: draft-ietf-rmt-bb-norm-02.txt
Cc: "Lorenzo Vicisano" <lorenzo@cisco.com>,
"Roger Kermode" <Roger.Kermode@motorola.com>, <rmt@lbl.gov>
Content-Type: multipart/mixed; boundary="============_-1216460392==_============"
Sender: owner-rmt@lbl.gov
Precedence: bulk
--============_-1216460392==_============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Please post this draft on the IETF Internet Drafts archive.
This is an update of an existing WG draft (RMT).
best regards,
--============_-1216460392==_============
Content-Id: <p0501040fb77e48da201a@[132.250.92.151].0.0>
Content-Type: text/plain; name="draft-ietf-rmt-bb-norm-02.txt"; charset="us-ascii" ; format="flowed"
Content-Disposition: attachment; filename="draft-ietf-rmt-bb-norm-02.txt"
; modification-date="Fri, 20 Jul 2001 16:44:57 -0400"
RMT Working Group B. Adamson/Newlink
INTERNET-DRAFT C. Bormann/Tellique
draft-ietf-rmt-bb-norm-02.txt M. Handley/ACIRI
Expires: January 2002 J. Macker/NRL
July 2001
NACK-Oriented Reliable Multicast (NORM) Protocol Building Blocks
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other docu-
ments at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract
This memo describes issues related to the creation of negative-
acknowledgment (NACK) oriented reliable multicast (NORM) protocols.
The general goals and assumptions for NORM are defined. The tech-
nical challenges related to NACK-oriented (and in some cases gen-
eral) reliable multicast protocol design are identified. These
challenges are resolved into a set of applicable "building blocks"
which are described in further detail. It is anticipated that
these building blocks (as they are further refined and defined in
future revisions of this document) will be useful in generating
different instantiations of reliable multicast protocols.
Adamson, Bormann, et al. Expires January 2002 [Page 1]
Internet Draft NORM Building Blocks July 2001
1.0 Background
Reliable multicast transport is a desirable technology for the
efficient and reliable distribution of data to a group on the
Internet. The complexities of group communication paradigms neces-
sitate different protocol types and instantiations to meet the
range of performance and scalability requirements of different
potential reliable multicast applications and users [Mankin98].
Properly designed negative-acknowledgement (NACK) oriented reliable
multicast (NORM) protocols offer scalability advantages for appli-
cations and/or network topologies where, for various reasons, it
is prohibitive to construct a higher order delivery infrastructure
above the basic Layer 3 IP multicast service (e.g. unicast or
hybrid unicast/multicast data distribution trees). Additionally,
the scalability property of NACK-oriented protocols [Pingali93,
Levine96] may be applicable where broad "fanout" is expected for a
single network hop (e.g. cable-TV data delivery, satellite, or
other broadcast communication communication services). Further-
more, the simplicity of a protocol based on "flat" group-wide mul-
ticast distribution may offer advantages for a broad range of dis-
tributed services or dynamic networks and applications.
While different protocol instantiations may be required to meet
specific application and network architecture demands [Clark90],
there are a number of fundamental components which may be common to
these different instantiations. This document describes the frame-
work and common "building block" components relevant to multicast
protocols based primarily on NACK operation for reliable transport.
2.0 Applicability
Each potential protocol instantiation using the building blocks
presented here (and other applicable building block documents) will
have specific criteria which will influence individual protocol
design. To support the development of applicable building blocks,
it is useful to identify and summarize driving general protocol
design goals and assumptions. These are areas which each protocol
instantiation will need to address in detail. Each building block
description in this document will include a discussion of the
impact of these design criteria. The categories of design criteria
considered here include:
1) Data content model
2) Group membership dynamics
3) Sender/receiver relationships
4) Group size
5) Data delivery performance
6) Network topology
Adamson, Bormann, et al. Expires January 2002 [Page 2]
Internet Draft NORM Building Blocks July 2001
3) Router/intermediate system assistance
In some cases, a building block may be designed to address a wide
range of assumptions while in other cases there will be trade-offs
required to meet different application needs. Where necessary,
building block features will designed to be parametric to meet dif-
ferent requirements. Of course, an underlying goal will be to min-
imize design complexity and to at least recommend default values
for any such parameters which meet a general purpose "bulk data
transfer" requirement in a typical Internet environment.
2.1 Data content model
The implicit goal of a reliable multicast protocol is the reliable
delivery of "data" among a group of members communicating through
IP multicast datagram service. However, the nature of the data
content and the service the application is attempting to provide
can impact design decisions. The service model may range from
long-lived transfer sessions of bulk quantities of data (file
broadcast) to more interactive exhanges of small messages (e.g.
white-boarding, text chat). And within those different models
there are other issues such as the sender's ability to cache
transmitted data (or state referencing it) for retransmission or
repair. The needs for ordering and/or causality in the sequence of
transmissions and receptions among members in the group may be dif-
ferent depending upon data content. The group communication
paradigm differs significantly from the point-to-point model in
that, depending upon the data content type, some receivers may com-
plete reception of a portion of data content and be able to act
upon it before other members have received the content. This may
be acceptable (or even desirable) for some applications but not for
others. These varying requirements drives the need for a number of
different protocol instantiation designs.
A significant challenge in developing generally useful building
block mechanisms is accommodating even a limited range of these
capabilities without defining specific application-level details.
Note that this particular building block "guideline" may be gener-
ally applicable beyond the realm of NACK-oriented reliable multi-
cast.
2.2 Group membership dynamics
Group communication can differ from point-to-point communications
with respect to the fact that even if the composition of the group
changes, the "thread" of communication can still exist. This con-
trasts with the point-to-point communication model where, if either
of the two parties leave, the communication process (exchange of
Adamson, Bormann, et al. Expires January 2002 [Page 3]
Internet Draft NORM Building Blocks July 2001
data) is terminated (or at least paused). Depending upon applica-
tion goals, senders and receivers participating in a reliable mul-
ticast transport "session" may be able to join late, leave, and/or
potentially rejoin while the ongoing group communication "thread"
still remains functional and useful.
Also note that this can impact protocol message content. If "late
joiners" are supported, some amount of additional information may
be placed in message headers to accommodate this functionality.
Alternatively, the information may be sent in its own message (on
demand or intermittently) if the impact to the overhead of typical
message transmissions is deemed too great. Group dynamics can also
impact other protocol mechanisms such as NACK or other timing, con-
gestion control operation, etc.
2.3 Sender/receiver relationships
The relationship of senders and receivers among group members
requires consideration. In some applications, there may be a sin-
gle sender multicasting to a group of receivers. In other cases,
there may be more than one sender or the potential for everyone in
the group to be a sender _and_ receiver of data may exist.
2.4 Group size
Native IP multicast [Deering89] may scale to extremely large group
sizes. It may be desirable for some applications to be able to
scale along with the multicast infrastructure's ability to scale.
In its simplest form, there are limits to the group size to which a
NACK-oriented protocol can apply without NACK implosion problems.
However, the potential for router assistance or other non-linear
NACK suppression mechanisms may enable these protocols to scale to
very large group sizes. In large scale cases, it may be pro-
hibitive for members to maintain state on all other members (in
particular, other receivers) in the group. The impact of group
size needs to be considered in the development of generally appli-
cable building blocks.
2.5 Data delivery performance
There is a trade-off between scalability and data delivery latency
when designing NACK-oriented protocols. If NACK suppression is to
be used, there will be some delays built into the NACK generation
and repair transmission process to allow suppression to occur and
for the sender of data to identify appropriate content for effi-
cient repair transmission. For example, backoff timeouts can be
used to ensure efficient NACK suppression and repair transmission,
but this comes at a cost of increased delivery latency and
Adamson, Bormann, et al. Expires January 2002 [Page 4]
Internet Draft NORM Building Blocks July 2001
increased buffering requirements for both senders and receivers.
The building blocks should allow applications to establish bounds
for data delivery performance. Note that application designers
must be aware of the scalabilty trade-off which is made when such
bounds are applied.
2.6 Network topology
The Internet Protocol has historically assumed a role of providing
service across heterogeneous network topologies. It is desirable
that a reliable multicast protocol be capable of effectively oper-
ating across a wide range of the networks to which general purpose
IP service applies. The bandwidth available on the links between
the members of a single group today may vary between low numbers
of kbit/s for wireless links and multiple Gbit/s for high speed LAN
connections, with varying degrees of contention from other flows.
Recently, a number of asymmetric network services including
56K/ADSL modems, CATV Internet service, satellite and other wire-
less communication services have begun to proliferate. Many of
these are inherently broadcast media with potentially large
"fanouts" to which IP multicast service is highly applicable.
Additionally, policy and/or technical issues may result in topolo-
gies where multicast connectivity is limited to a single logical
direction from a specific source or set of sources to the group at
large. Receivers in the group may be restricted to unicast feed-
back for NACKs and other messages. Consideration must be given, in
building block development and protocol design, to the nature of
the underlying networks over which the protocols may be operating.
2.7 Router/Intermediate System Assistance
While intermediate assistance from devices/systems with direct
knowledge of the underlying network topology may used to leverage
the performance and scalability of reliable multicast protocols,
there will continue to be a number of instances where this is not
available or practical. Any building block components for NACK-
oriented reliable multicast should be capable of operating without
such assistance but should also be capable of utilizing these fea-
tures when available.
3.0 Building Block Areas
The previous section has presented in general what building blocks
are intended to be and some of the criteria which may affect build-
ing block identification/design. This section describes different
building block areas applicable to NACK-oriented reliable multi-
cast protocols. Some of these areas are specific to NACK-oriented
Adamson, Bormann, et al. Expires January 2002 [Page 5]
Internet Draft NORM Building Blocks July 2001
protocols. Detailed descriptions of such areas are provided
below. In other cases, the areas (e.g. node identifiers, FEC,
etc) may be generally applicable to other forms of reliable multi-
cast. In those cases, the discussion below describes requirements
placed on those other general building block areas from the stand-
point of NACK-oriented reliable multicast.
For the individual building blocks to be incorporated as part of a
specific protocol instantiation, it is expected that a description
of some notional "interface" to the building blocks' functionality
be provided. For example, a building block component may require
some form of "input" from another building block component or
other source in order to perform its function. Any "inputs"
required by each building block component and/or any resultant
"output" provided by the building block will be defined and
described as the building block component's interface definition.
The following building block areas are described below:
(NACK-Oriented Components)
1) Sender transmission
2) NACK-oriented Repair Process
3) "Late-joining" Receiver Policies and Mechanisms
(Generally-applicable Components)
4) Node (member) Identification
5) Data Content Identification
6) Forward Error Correction
7) Round-trip Timing Collection
8) Group Size Determination/Estimation
9) Congestion Control Operation
10) Router/Intermediate System Assistance
11) Additional Protocol Mechanisms
Figure 1 provides an pictoral overview of these building block
areas and their relationships. For example, the content of the
data messages that sender initially transmits depends upon the
"Node Identification", Data Content Identification", "FEC" , and
"Congestion Control components (Note that the rate of message
transmission will generally depend upon the "Congestion Control"
component). Subsequently, the receivers response to these trans-
missions (e.g. NACKing for repair) will depend upon the content of
these transmissions and inputs from other building block compo-
nents. Then, the sender's processing of these responses will feed
back into its transmission strategy.
Application Data
|
Adamson, Bormann, et al. Expires January 2002 [Page 6]
Internet Draft NORM Building Blocks July 2001
V
.---------------------. .-----------------------.
| Node Identification |----------->| Sender Transmission |<------.
'---------------------' _.-' '-----------------------' |
.---------------------. _.-' .' | |
| Data Identification |--' .'' | ("Join" Policy) |
'---------------------' .' ' V |
.---------------------. .' ' .------------------------. |
.->| Congestion Control |-' ' | Receiver NACK-oriented | |
| '---------------------' .' | Repair Process | |
| .---------------------. .' | .------------------. | |
| | FEC |'. | | NACK Initiation | | |
| '---------------------'. '._ | '------------------' | |
| .---------------------. , '-._ | .------------------. | |
'--| RTT Collection |._' '->| | NACK Content | | |
'---------------------' .''. | '------------------' | |
.---------------------. ' ''-._ | .------------------. | |
| Group Size Est. |---'-'---'->| | NACK Suppression | | |
'---------------------''. ' ' | '------------------' | |
.---------------------. ' ' ' '------------------------' |
| Other | ' ' ' | |
'---------------------' ' ' ' | (Router Assistance) |
'. ' ' V |
'.'' .-------------------------. |
'>| Sender NACK Processing |_____/
| and Repair Response |
'-------------------------'
^ ^
| |
.-----------------------------.
| (Security) |
'-----------------------------'
Fig. 1 - NORM Building Block Framework
The components on the left side of this figure represent the components
which may be generally applicable beyond NORM and those on the right are
specific to NORM protocols. Some components (e.g. "Security") will
impact many aspects of the protocol and others such as "Router Assis-
tance" may be more transparent to the core protocol processing. The
sections below discuss issues with regards to these building block com-
ponents and their relationships. Where applicable, specific technical
recommendations are made for mechanisms which will properly satisfy the
goals of reliable multicast bulk transport for the Internet.
3.1 Sender transmission
Adamson, Bormann, et al. Expires January 2002 [Page 7]
Internet Draft NORM Building Blocks July 2001
Senders will transmit data content to the multicast session. The data
content will be application dependent. The sender will transmit data
content at a rate and with packet sizes determined by application and/or
network architecture requirements. When congestion control mechanisms
are used (recommended), the transmission rate will be controlled by the
congestion control mechanism. It is recommended that all data transmis-
sions from senders be subject to rate limitations determined by the
application or congestion control algorithm. The sender's transmissions
should make good utlization of the available capacity (which may be lim-
ited by the application and/or by congestion control). As a result, it
is expected there will be overlap and multiplexing of new data content
transmission with repair content.
In addition to data content, other sender messages or commands may be
employed as part of protocol operation. For NACK-oriented operation,
the reliability of any such commands may depend upon redundant transmis-
sion. Other factors related to NACK-oriented operation may determine
sender transmission formats and methods. Some consideration needs to be
given to the sender's behavior during intermittent idle periods when it
has no data to transmit. While many aspects may be protocol-specific,
there are techniques which may be generally applicable to NACK-oriented
reliable multicast. For example, the periodicity of redundant transmis-
sion of command messages issued by a sender should be dependent upon the
greatest round trip timing estimate and the resultant NACK operation.
More specifically, a command message might be redundantly transmitted by
a sender to indicate that it is temporarily (or permanently) halting
transmission. At this time, it may be appropriate for receivers to
respond with NACKs for any outstanding repairs they require following
the rules of the NACK process described below. For efficiency, the
sender should allow sufficient time between redundant transmissions to
receive any NACK-oriented responses from the receiver set to this com-
mand. Other protocol components may benefit from a similar approach.
Inputs:
1) Data content
2) Segmentation size
3) Transmission rate
4) Application controls
Outputs:
1) Rate-controlled stream of packets with headers uniquely
identifying data or repair content within the context of the
reliable multicast session.
2) Commands indicating sender's status or other transport con-
trol actions to be taken.
Adamson, Bormann, et al. Expires January 2002 [Page 8]
Internet Draft NORM Building Blocks July 2001
3.2 NACK-oriented repair process
The most critical component of the NACK-oriented reliable multicast
protocol building block is the NACK repair process. There are four
primary elements of a general NACK repair process:
1) Method for determining when receivers will initiate the NACK
process in response to sender transmission for which they
need repair.
2) NACK message content.
3) NACK suppression mechanisms to promote scalability of the
protocol.
4) Sender NACK reception, aggregation, and repair response.
3.2.1 NACK Process Initiation
The NACK process (cycle) will be initiated by receivers who detect
they require repair transmissions from a specific sender at defined
opportunities. When FEC is applied, a NACK cycle should only be
initiated when it is known by the receiver that its repair require-
ments exceed the amount of FEC pending transmission for a given
coding block of packets. This may be determined by the receiver if
the sender's transmission advertises the quantity of repair packets
it is already planning to send for a block, and/or at the end of
the current transmission block (if it is indicated) or at the start
of subsequent coding block for packets transmitted within the con-
text of a designed data content set (See object/stream data content
identifier discussion below).
Allowing receivers to initiate NACK cycles at any time they detect
their repair needs have exceeded pending repair transmissions may
result in slightly quicker repair cycles. However, it may be use-
ful to limit the initiation opportunities to specific events such
as at the end-of-transmission of an FEC coding block (or alterna-
tively at detection of subsequent coding blocks). This can allow
receivers to aggregate NACK content into a smaller number of NACK
messages. In either case, the NACK cycle should begin with
receivers observing backoff timeouts to facilitate NACK suppression
as described below.
Interface Description
Inputs:
1) Object/stream data content and sequencing identifiers from
sender transmissions.
Outputs:
Adamson, Bormann, et al. Expires January 2002 [Page 9]
Internet Draft NORM Building Blocks July 2001
1) NACK Process Initiation Decision
3.2.2 NACK Content
The content of NACK messages generated by reliable multicast
receivers will include information detailing the current repair
needs of each receiver. The specific information depends on the
use and type of FEC in the NORM repair process. The identification
of repair needs is dependent upon the data content identification
(See Section 3.5 below). At the highest level the NACK content
will identify the data transport object (or stream) within the mul-
ticast session which needs repair. For the indicated transport
entity, the NACK content will then identify the specific coding
blocks and/or segments of coding blocks it needs to reconstruct the
transmitted data. This content may consist FEC block erasure
counts and/or explicit indication of missing blocks or segments of
data and FEC content.
3.2.2 NACK Content Strategies
Where FEC-based repair is used, the NACK message content will need
to identify the coding block(s) for which repair is needed and the
count of erasures (missing packets) in the coding block. Note that
this assumes the FEC algorithm is capable of repairing _any_ loss
combination within the coding block and that the quantity of unique
FEC parity packets the server has available to transmit is essen-
tially unlimited (i.e. the server will always be able to provide
new parity packets in response to anysubsequent repair requests for
the same coding block). In other cases, the NACK content will need
to also _explicitly_ identify which packets (information and/or
parity) the receiver needs to successfully reconstruct the content
of the coding block.
When FEC is not used as part of the repair process or the protocol
instantiation is required to provide reliability even when the
sender has transmitted all available parity for a given coding
block (or the sender's ability to buffer transmission history is
exceeded by the delay*bandwidth*loss characteristics of the network
topology), the NACK content will need to contain _explicit_ coding
block and/or packet loss information so that the sender can provide
appropriate repair packets and/or data retransmissions. Explicit
loss information in NACK content may also potentially serve other
purposes. For example, it may be useful for decorrelating loss
characteristics among a group of receivers to help differentiate
candidate congestion control bottlenecks among the receiver set.
For cases where the amount of loss is very small with respect to
the coding block size, it may be efficient to simply provide a list
Adamson, Bormann, et al. Expires January 2002 [Page 10]
Internet Draft NORM Building Blocks July 2001
of coding block vector identifiers. However, in many cases, a bit
mask marking the locations of missing packets may be significantly
more efficient for communicating receiver repair needs. And since
the data content is logically divided into coding blocks, a system
of hierarchical bit masks can be used to encode missing content at
the object/stream, FEC block, and individual packet levels. Hier-
archical bit mask encoding can provide compact NACK messages even
in high delay*bandwidth*loss conditions. Bit mask based NACK con-
tent can also be efficiently processed with logical operations dur-
ing protocol operation.
When FEC is used and NACK content is designed to contain explicit
repair requests, there is strategy where the receivers can NACK for
specific content which will help facilitate NACK suppression and
repair efficiency. The assumptions for this strategy are that
sender may potentially exhaust its supply of new, unique parity
packets available for a given coding block and be required to
explicitly retransmit some data or parity segments to complete
reliable transfer. Another assumption is that an FEC algorithm
where any parity packet can fill any erasure within the coding
block is used. The goal of this strategy is to make maximum use of
the available parity and provide the minimal amount of data and
repair transmissions during reliable transfer of a coding block to
the group.
In this approach, the sender transmits the data content of the cod-
ing block (and optionally some quantity of parity packets) in its
initial transmission. Note that a coding block is considered to be
logically made up of the contiguous set of data vectors plus parity
vectors for the given FEC algorithm used. The sender transmits
parity vectors from the lowest ordinal part of the parity portion
of the coding block. When the receivers construct explicit NACK
content, they request transmission of only the _upper_ ordinal por-
tion, corresponding to the number of _data_ vectors, of the logical
coding block required to fill their packet erasures (Note this
_may_ include data vectors if there is a smaller number of parity
vectors than data vectors for the selected code, but generally will
consist solely of parity vectors). The receivers can also provide
a count of erasures as a convenience (saves processing time) to the
sender. Upon receipt of the NACK message, the sender will schedule
transmission of fresh, new parity vectors based on the erasure
count _if_ it has a sufficient quantity of vectors which were _not_
previously transmitted and ignore the explicit content requested..
Otherwise, the sender will resort to transmitting the set of repair
vectors requested. With this approach, the sender needs to main-
tain very little state on requests it has received from the group
without need for synchronization of repair requests from the group.
Since all receivers use this same algorithm to express their
Adamson, Bormann, et al. Expires January 2002 [Page 11]
Internet Draft NORM Building Blocks July 2001
explict repair needs, NACK suppression among receivers is simpli-
fied over the course of multiple repair cycles. The receivers can
simply compare NACKs heard from other receivers against their own
calculated repair needs to determine whether they should transmit
or suppress their pending NACK messages.
3.2.3 General Purpose NACK Content Encapsulation Format
This section describes a general format for encapsulating negative
acknowledgement (NACK) feedback content for reliable data transmis-
sion protocols. This includes protocols which may incorporate for-
ward error correction (FEC) for repair packet generation as well as
those which do not. This NACK format is structured according to a
logical, hierarchical framework where the sender transmits data
optionally in the form of one or more "streams" or "objects", with
each optionally composed of a series of FEC coding "blocks" with
each "block" composed of some number of data transmission segments
with source data and/or FEC parity content. This allows any seg-
ment of transmitted data (or FEC parity) to be hierarchically
addressed, as applicable, by the concatenation of "stream/object",
"block", and "segment" identifiers.
Note that multiple levels of streams and substreams or objects can
be instantiated within a hierarchy as required by protocol instan-
tiations to meet protocol or application needs. Also note that the
notional hierarchy of "streams" and/or "blocks" can be omitted for
protocols which do not employ them and the appropriate subset of
the message scheme described here can still be used for NACK repair
requests. Thus a protocol with a single virtual "stream" would
invoke only the message sets relevant to FEC "blocks" and transmis-
sion "segments".
Figure 2 illustrates this logical hierarchy of transmission content
identification, denoting that the notion streams (or objects)
and/or FEC blocking is optional at the protocol instantiation's
discretion. Since the notion of session "streams" and "blocks" are
optional, the framework degenerates to that of typical transport
data segmentation and reassembly in its simplest form.
Session_
\_
[Stream(s)]_
\_
[FEC Blocks]_
\_
Segments
Adamson, Bormann, et al. Expires January 2002 [Page 12]
Internet Draft NORM Building Blocks July 2001
Figure 2: Hierarchy of Reliable Data Transfer Content
Besides providing a general purpose, standard format for encapsu-
lating NACK content, the format presented here has other beneficial
properties:
1) A variety of forms of repair requests are supported: individ-
ual, ranges, and lists of repair symbols. Also, bitmask
formats for repair needs which can lend themselves to effi-
cient packing and processing are supported.
2) The format is independent of FEC type where FEC is applica-
ble.
3) Intermediate systems can process this format and perform
functions in support of feedback suppression or other proto-
col assistance with minimal side information.
In this specification, it is assumed that any "Streams" (or
Objects) and "FEC Blocks" can be identified with 32-bit numeric
fields. In some protocols, "Segments" may be identified by numeric
fields whose size is dependent upon the FEC coding technique used.
Thus, in this specification, feedback messages with "segment"
repair content identified fall into message categories denoting the
explicit size (in bytes) of segment identifier fields to allow mes-
sage parsing independent of FEC-type knowledge. Currently, segment
identification fields of 1, 2, and 4 bytes (8, 16, 32 bits) are
supported, but additional field sizes could easily be supported.
Additionally, it is understood that the use of "Streams" and/or
"Blocks" may not be applicable to some protocols. In this case,
the specification supports NACK content consisting soley of repair
requests for sets of transmission segments.
3.2.3.1 NACK Content Common Header
A simple common header allows NACK content to be efficiently encap-
sulated by receivers and parsed by senders and intermediate sys-
tems. This header is usually followed by content dependent upon
the header content, including sub-encapsulation of lower-level
NACKs. This header consists of NackType, NackForm, and NackLength
fields as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NackType | NackForm | NackLength (bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
enum NackType = {STREAM, BLOCKS, SEGMT1, SEGMT2, SEGMT4, OOB_DATA}
Adamson, Bormann, et al. Expires January 2002 [Page 13]
Internet Draft NORM Building Blocks July 2001
enum NackForm = {SINGLE, RANGE, LIST, MASK, SUBSET, COUNT}
The NackType field is of one of the values: STREAM, BLOCKS,
SEGMT1, SEGMT2, SEGMT4, or OOB_DATA. For example, the "STREAM"
type indicates the Nack is requesting repair transmission for one
or more "stream(s)" (or object) which have been transmitted. The
STREAM type and other NackTypes are described in detail in the sec-
tions below.
The NackForm field is used to describe the format of the content of
the given NACK message. The form "SINGLE" indicates the NACK is a
request for repair of a single unit of the given NackType (STREAM,
BLOCK, SEGMT1, SEGMT2, SEGMT4, or OOB_DATA) identified with appro-
priate fields (Note the "SINGLE" form can also be used for some
"wildcard" requests as described below). The "RANGE" form indi-
cates that repair is requested for a contiguous range of units of
the NackType field and the "LIST" form is used for discrete lists
of units of the NackType. The "MASK" form indicates that bitmask
content to describe the repair needs follows. Bitmask encoding of
repair needs can be efficient in terms of size and processing for
much NACK content. The "SUBSET" form is used to indicate content
comprised of NACKs for units below the level of the given NackType.
The "SUBSET" form provides context for the content with an indenti-
fier for the given NackType. For example, a NACK of {type=STREAM,
form=SUBSET} might encapsulate a NACK of {type=BLOCKS, form=SINGLE}
to denote a missing FEC coding block for the given stream or
object. Note the "COUNT" NackForm is only used with the SEGMTx
NackTypes and is used indicate the number of erasures (missing seg-
ments) in a given FEC coding block. The format for different com-
binations of NackType and NackForm are described in detail below.
The NackLength field is the size of the content attached to the
NACK encapsulation header. This includes the total length of "SUB-
SET" NACK content as well as the fields associated with the given
NACK (not including its own encapsulation header). The NackLength
is in units of bytes. Note in some cases there may be zero content
attached to a given NACK. The NackLength field assists in the
parsing of NACK content. For example, when the NACK content con-
sists of a concatenation of different NACK units (NACK messages,
bit masks, etc), the parser can use the NackLength field to find
the end of the given NACK content (or the beginning of the next set
of content).
3.2.3.2 STREAM NackType
The STREAM NackType is used by receivers to request repair for spe-
cific stream(s) or object(s) in the context of the reliable data
Adamson, Bormann, et al. Expires January 2002 [Page 14]
Internet Draft NORM Building Blocks July 2001
transfer session. Streams (or objects) are indentified by 32-bit
fields. The STREAM NackType may of NackForm SINGLE, RANGE, LIST,
MASK, or SUBSET. The following formats are used for these differ-
ent STREAM Nack forms:
STREAM::SINGLE
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type = STREAM | form = SINGLE | NackLength |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| stream/object id* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note: The "STREAM::SINGLE" NACK can be used as a "wildcard"
NACK requesting transmission/repair of all content the
sender is willing to send under it's transmission/repair
policies for late-joining receivers. This is done by
setting the NackLength value equal to zero and omitting
the "stream/object id" field.
STREAM::RANGE
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type = STREAM | form = RANGE | NackLength |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| start stream/object id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| end stream/object id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Adamson, Bormann, et al. Expires January 2002 [Page 15]
Internet Draft NORM Building Blocks July 2001
STREAM::LIST
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type = STREAM | form = LIST | NackLength |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| stream index 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| stream index 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| stream index N-1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Notes on STREAM::LIST content:
1) The list length can be determined from the NackLength field
by right shifting it 2 places (i.e. divide by 4).
STREAM::MASK
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type = STREAM | form = MASK | NackLength |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| mask1 offset (stream/object id) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| mask1 length (bytes) | mask1 data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| mask2 offset (stream/object id) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| mask2 length (bytes) | mask2 data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| maskN offset (stream/object id) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| maskN length (bytes) | maskN data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Adamson, Bormann, et al. Expires January 2002 [Page 16]
Internet Draft NORM Building Blocks July 2001
Notes on STREAM::MASK content:
1) The offset is an index to the starting stream id of the sub-
sequent bitmask.
2) The offset stream id shall be an even multiple of 32 for
alignment.
3) The MASK NackForm content is a concatenation of one or more
bitmasks. The NackLength field can be used by the parser to
determine the number of individual bitmasks included.
STREAM::SUBSET
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type = STREAM | form = SUBSET | NackLength |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| stream/object id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SubsetType | SubsetForm | SubsetLength |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| subset content ... |
Notes on STREAM::SUBSET content:
1) Valid STREAM::SUBSET NackTypes (i.e. SubsetType) include
STREAM, BLOCKS, SEGMENTS (SEGMT1, SEGMT2, SEGMT4), and
OOB_DATA. (Note that the "STREAM" (stream/object) type can
be a subset of the STREAM type so that protocol instantia-
tions may build multi-level hierarchies of streams, sub-
streams, and objects as needed. This allows the number of
hierarchy levels to be different for different protocols and
maintain protocol-independent parsing of NACK content).
2) The "stream/object id" field gives context for the attached
"subset" NACK content.
3) Multiple "subset" NACKs may be concatenated for the given,
identified stream. The NackLength can be used by the parser
to determine the number of subset items included.
3.2.3.3 BLOCKS NackType
The BLOCKS NackType is used by the receiver to request repair con-
tent for one or more specific FEC coding blocks. The BLOCK Nack-
Type may generally be enclosed as SUBSET content for a STREAM NACK,
but can be a stand-alone NACK type for protocols with a single
implicit transmission stream. FEC blocks are indentified by 32-bit
fields. The BLOCKS NackType may of the forms SINGLE, RANGE, LIST,
MASK, or SUBSET. The "non-SUBSET" forms implicity indicates the
Adamson, Bormann, et al. Expires January 2002 [Page 17]
Internet Draft NORM Building Blocks July 2001
specified FEC coding blocks are missing in entirety while the SUB-
SET form indicates repair is needed only for a portion of the iden-
tified coding block. The same formats as used for the STREAM Nack-
Type are used for the BLOCK NackType except that identifier fields
contain FEC block identifiers instead of stream/object identifiers.
The following formats are used for these different BLOCKS Nack
forms:
BLOCKS::SINGLE
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type = BLOCKS | form = SINGLE | NackLength |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC block id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note: The "BLOCKS::SINGLE" NACK can be used as a "wildcard"
NACK requesting transmission/repair of all FEC blocks for
an indicated stream/object (if applicable) the sender is
willing to send under it's transmission/repair policies
for late-joining receivers. This is done by setting the
NackLength value equal to zero and omitting the "block
id" field. This NACK method may be useful when a
receiver has only received out-of-band data associated
with a given stream or object and requires all of the
associated content.
BLOCKS::RANGE
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type = BLOCKS | form = RANGE | NackLength |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| start FEC block id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| end FEC block id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Adamson, Bormann, et al. Expires January 2002 [Page 18]
Internet Draft NORM Building Blocks July 2001
BLOCKS::LIST
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type = BLOCKS | form = LIST | NackLength |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC block index 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC block index 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC block index N-1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Notes on STREAM::LIST content:
1) The list length can be determined from the NackLength field
by right shifting it 2 places (i.e. divide by 4).
BLOCKS::MASK
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type = BLOCKS | form = MASK | NackLength |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| mask1 offset (block id) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| mask1 length (bytes) | mask1 data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| mask2 offset (block id) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| mask2 length (bytes) | mask2 data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| maskN offset (block id) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| maskN length (bytes) | maskN data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Adamson, Bormann, et al. Expires January 2002 [Page 19]
Internet Draft NORM Building Blocks July 2001
Notes on BLOCKS::MASK content:
1) The offset is an index to the starting block id of the subse-
quent bitmask.
2) The offset block id shall be an even multiple of 32 for
alignment.
3) The MASK NackForm content is a concatenation of one or more
bitmasks. The NackLength field can be used by the parser to
determine the number of individual bitmasks included.
BLOCKS::SUBSET
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type = BLOCKS | form = SUBSET | NackLength |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| block id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SubsetType | SubsetForm | SubsetLength |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| subset content ... |
Notes on BLOCKS::SUBSET content:
1) Valid BLOCKS::SUBSET NackTypes (i.e. SubsetType) include SEG-
MENTS (SEGMT1, SEGMT2, SEGMT4) only.
2) The "block id" field gives context for the attached "subset"
NACK content.
3) Multiple "subset" NACKs may be concatenated for the given,
identified block.
The NackLength can be used by the parser to determine the
number of subset items included.
3.2.3.4 SEGMENTS (SEGMT1, SEGMT2, and SEGMT4) NackTypes
The SEGMENTS NackTypes are used by the receiver to request repair
content for a set of segments possible associated with a given
stream and/or FEC coding block. For protocols employing FEC block-
ing, the SEGMENTS NackTypes may generally be enclosed as SUBSET
content for a BLOCK Nack (which in turn may be enclosed as part of
a STREAM NackType if applicable), but can be a stand-alone NACK
type for protocols with a single implicit transmission stream and
no block-based encoding. Segments are indentified by numeric iden-
tifiers. The appropriate size of segment identifier can be a func-
tion of the FEC encoding technique. For example, segments that are
part of FEC coding blocks up to 256 packets in length may use an
8-bit identifier while larger block codes may require a
Adamson, Bormann, et al. Expires January 2002 [Page 20]
Internet Draft NORM Building Blocks July 2001
correspondingly large segment identification field. For this rea-
son, the SEGMENTS NackType is split into distinct types of SEGMT1,
SEGMT2, and SEGMT4. As shown in the table below, the numeric por-
tion of the NackType name (1, 2, or 4) corresponds to the number of
bytes with which segment identifier fields occupy in the content of
that NackType. These values correspond to 8, 16, or 32 bit indexes
for fields related to segment identification, etc. Segment identi-
fier fields use "Big Endian" ordering of most to least significant
bytes.
+---------+----------------------+
|NackType | Bytes per Segment-Id |
+---------+----------------------+
| SEGMT1 | 1 |
+---------+----------------------+
| SEGMT2 | 2 |
+---------+----------------------+
| SEGMT4 | 4 |
+---------+----------------------+
Note that the use of appropriately sized fields allow for proper
computing alignment of associated message content while maintaining
efficient packing of NACK payload content for small to large block
sizes. If needed, this protocol specification could be easily
extended to include other word sizes (e.g. SEGMT5 for 64-bit index-
ing and alignment of segment identifiers).
The SEGMENTS NackTypes (SEGMT1, SEGMT2, SEGMT4) may of NackForm
SINGLE, RANGE, LIST, or MASK. Formats similar to those used for
the STREAM and BLOCK NackTypes are used with the appropriate inter-
pretation of segment identifier fields. The following formats are
used for these resulting different SEGMENTS NackForms:
SEGMENTS::SINGLE
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type = SEGMTx | form = SINGLE | NackLength |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...segment id... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note: The "segment id" field is of length 1, 2, or 4 bytes
directly corresponding to the type of SEGMT1, SEGMT2, or
SEGMT4.
Adamson, Bormann, et al. Expires January 2002 [Page 21]
Internet Draft NORM Building Blocks July 2001
SEGMENTS::RANGE
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type = SEGMTx | form = RANGE | NackLength |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...start segment id... | ...end segment id... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note: The "start segment id" and "end segment id" fields are of
length 1, 2, or 4 bytes directly corresponding to the
type of SEGMT1, SEGMT2, or SEGMT4.
SEGMENTS::LIST
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type = SEGMTx | form = LIST | NackLength |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...segment index 0... | ...segment index 1... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...segment index N-2... | ...segment index N-2... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Notes on SEGMENTS::LIST content:
1) The "segment index" fields are of length 1, 2, or 4 bytes
directly corresponding to the type of SEGMT1, SEGMT2, or
SEGMT4.
2) The LIST length can be determined from the NackLength field
by right shifting it 0, 1, or 2 places as needed for the
given SEGMTx type (i.e. divide by 1, 2, or 4).
SEGMENTS::MASK
An "erasure count" field is included for SEGMENT NackType content
of NackForm MASK. The "erasure count" field allows the parser of
the NACK message (generally a sender or repairer of data) to
quickly determine FEC repair strategies without needing to count
the "set" portion of the bitmask content. Note that the "erasure
count" can easily be determined for the "RANGE" and "LIST" forms
from the corresponding "end-start+1" or "NackLength" values. The
MASK form can also be used to provide "erasure count only" feedback
by omitting inclusion of bitmask content and setting the NackLength
Adamson, Bormann, et al. Expires January 2002 [Page 22]
Internet Draft NORM Building Blocks July 2001
appropriately small.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type = SEGMTx | form = MASK | NackLength |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...erasure count... | ...mask1 offset (seg id)... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...mask1 length... | mask1 data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...mask2 offset (seg id)... | ...mask2 length... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| mask2 data ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...maskN offset (seg id)... | ...maskN length... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| maskN data ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Notes on SEGMENTS::MASK content:
1) The "list length" and "segment index" fields are of length 1,
2, or 4 bytes directly corresponding to the type of SEGMT1,
SEGMT2, or SEGMT4.
2) The "offset" (segment id) shall be an even multiple of 8, 16,
or 32 corresponding to NackTypes of SEGMT1, SEGMT2, or
SEGMT4 for computing alignment purposes.
3) The "mask length" field shall be an even multiple of 1, 2, or
4 corresponding to NackTypes of SEGMT1, SEGMT2, or SEGMT4
for computing alignment purposes.
4) The "offset" is an index to the starting block id of the sub-
sequent bitmask.
5) The MASK NackForm content is a concatenation of one or more
bitmasks. The NackLength field can be used by the parser to
determine the number of individual bitmasks included.
Adamson, Bormann, et al. Expires January 2002 [Page 23]
Internet Draft NORM Building Blocks July 2001
SEGMENTS::COUNT
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type = SEGMTx | form = COUNT | NackLength |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...erasure count... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note: The "erasure count" field is of length 1, 2, or 4 bytes
directly corresponding to the NackType of SEGMT1, SEGMT2,
or SEGMT4.
3.2.3.5 OOB_DATA NackType
The OOB_DATA NackType is used by receivers to request repair of
out-of-band data content associated with a specific stream/object
or with the general context of a reliable data transfer session.
The nature of OOB_DATA is protocol specific, but the NACK format
specified in this document provides a general approach for request-
ing this type of repair. The only NackForm supported for the
OOB_DATA NackType is SINGLE. The OOB_DATA NACK can be transmitted
as a stand-alone NACK message where it is implicitly understood
that the request is for any OOB_DATA content general to the reli-
able data transfer session. Alternatively, the OOB_DATA NackType
can be transmitted as "subset" content of a STREAM NACK when the
receiver is requesting out-of-band data associated with a specific
stream or object within the session.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type = O_DATA | form = SINGLE | NackLength = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Adamson, Bormann, et al. Expires January 2002 [Page 24]
Internet Draft NORM Building Blocks July 2001
3.2.3.6 Example NACK Messages:
Request for OOB_DATA associated with a given stream/object:
(stream:1)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type = STREAM | form = SUBSET | NackLength = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| stream/object id = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type = O_DATA | form = SINGLE | NackLength = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Request for a SINGLE segment: (stream:1 block:5 segment:10 seg-
ment_id_length:2)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type = STREAM | form = SUBSET | NackLength = 18 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| stream/object id = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type = BLOCKS | form = SUBSET | NackLength = 10 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| block id = 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type = SEGMT2 | form = SINGLE | NackLength = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| segId = 10 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Adamson, Bormann, et al. Expires January 2002 [Page 25]
Internet Draft NORM Building Blocks July 2001
Request for a LIST of segments: (stream:1 block:5 seg-
ments:11,12,21,32 segment_id_length:1)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type = STREAM | form = SUBSET | NackLength = 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| stream/object id = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type = BLOCKS | form = SUBSET | NackLength = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| block id = 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type = SEGMT2 | form = LIST | NackLength = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| segId = 11 | segId = 12 | segId = 21 | segId = 32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Request indicating erasure count for a specfic FEC coding block:
(stream:1 block:5 erasures:4)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type = STREAM | form = SUBSET | NackLength = 17 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| stream/object id = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type = BLOCKS | form = SUBSET | NackLength = 9 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| block id = 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type = SEGMT1 | form = COUNT | NackLength = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| count = 4 |
+-+-+-+-+-+-+-+-+
Adamson, Bormann, et al. Expires January 2002 [Page 26]
Internet Draft NORM Building Blocks July 2001
Request with Bitmask indicating repair needs for a specific FEC
block: (stream:1 block:5 segment_id_length:1):
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type = STREAM | form = SUBSET | NackLength = 27 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| stream/object id = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type = BLOCKS | form = SUBSET | NackLength = 19 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| block id = 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type = SEGMT1 | form = MASK | NackLength = 11 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| offset = 0 | erasures = 16 | maskLen = 8 | maskData[0] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| maskData[1] | maskData[2] | maskData[3] | maskData[4] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| maskData[5] | maskData[6] | maskData[7] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Request for range of segments for coding block (no stream/objects):
(block:12 segments:239-283)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type = BLOCKS | form = SUBSET | NackLength = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| block id = 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type = SEGMT2 | form = RANGE | NackLength = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| start = 239 | end = 283 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Adamson, Bormann, et al. Expires January 2002 [Page 27]
Internet Draft NORM Building Blocks July 2001
Request for range of segments for coding block associated with an
object (or stream) which is a subset of another stream: (stream: 1
object: 342 block:12 segments:143-212)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type = STREAM | form = SUBSET | NackLength = 28 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| stream/object id = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type = STREAM | form = SUBSET | NackLength = 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| stream/object id = 342 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type = BLOCKS | form = SUBSET | NackLength = 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| block id = 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type = SEGMT2 | form = RANGE | NackLength = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| start = 143 | end = 212 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2.3 NACK Suppression Mechanisms
A primary NACK suppression mechanism is the use of initial backoff
timeouts by receivers wishing to transmit NACK messages[Floyd95].
Upon expiration of the timeout, a receiver will transmit a NACK
unless the content of the pending repair request is completely
superseded by NACK messages heard from other receivers (when
receivers are multicasting NACKs) or from some indicator from the
sender. (Note: When receivers are unicasting NACK messages, the
sender may facilitate NACK suppression by forwarding appropriate
NACKs it has received to the group at large or provide some other
indicator of the repair information it will be subsequently trans-
mitting).
The backoff timeout periods used by receivers should be indepen-
dently, randomly picked by receivers with an exponential distribu-
tion [Nonnenmacher98]. This results in the bulk of the receiver
set holding off transmission of NACK messages under the assumption
that the smaller number of "early NACKers" will supersede the
repair needs of the remainder of the group. The mean of the dis-
tribution should be determined as a function of the current esti-
mate of sender<->group greatest round trip time (GRTT) and a group
size estimate which determined by other mechanisms within the pro-
tocol (See section below) or preset by the multicast application.
Adamson, Bormann, et al. Expires January 2002 [Page 28]
Internet Draft NORM Building Blocks July 2001
A simple algorithm can be constructed to generate random backoff
timeouts with the appropriate distribution. Additionally, the
algorithm may be designed to optimize the backoff distribution
given the number of receivers (R) potentially generating feedback.
This "optimization" minimizes the number of feedback messages (e.g.
NACK) in the worst-case situation where all receivers generate a
NACK. The maximum backoff timeout (T) can also be controlled to
allow the application or protocol tradeoff NACK latency versus vol-
ume of feedback traffic. A larger value of T will result in a
lower density of feedback traffic for a given repair cycle. A
smaller value of T results in shorter latency which reduces the
buffering requirements of senders and receivers for reliable trans-
port.
Given the receiver group size (R), and maximum allowed backoff
timeout (T), a truncated exponential backoff timeout (t') can be
picked with the following algorithm:
1) Establish an optimal mean (L) for the exponential backoff based
on the group size:
L = ln(R) + 1
2) Pick a random number (x) from a uniform distribution
over a range of:
L L L
---------------- to ---------------- + ---
T * (exp(L) - 1) T * (exp(L) - 1) T
3) Transform this random variate to generate the
desired random backoff time (t) with the following
equation:
t' = T/L * ln(x * (exp(L) - 1) * (T/L))
This is a C language function which can be used to perform this
function:
double RandomBackoff(double maxTime, double groupSize)
{
double lambda = log(groupSize) + 1;
double x = UniformRand(lambda/maxTime) +
lambda / (maxTime*(exp(lambda)-1));
return ((maxTime/lambda) *
log(x*(exp(lambda)-1)*(maxTime/lambda)));
} // end RandomBackoff()
Adamson, Bormann, et al. Expires January 2002 [Page 29]
Internet Draft NORM Building Blocks July 2001
where UniformRand(double max) returns random numbers with a uniform
distribution from the range of 0..max. For example, based on the
POSIX "rand()" function, the following code can be used:
double UniformRand(double max)
{
return (max * ((double)rand()/(double)RAND_MAX));
}
The number of expected NACKs generated (N) within the first round
trip time for a single loss event can be approximately expected to
be:
N = exp(1.2 * L / (2*T/GRTT))
Thus the maximum backoff time (T) can be adjusted to tradeoff
worst-case NACK feedback volume versus latency. This is derived
from [Nonnenmacher98] and assumes T >= GRTT, and L is the mean of
the distribution optimized for the given group size as shown in the
algorithm above. Note that other mechanisms within protocol may
work to reduce redundant NACK generation further.
There are some secondary NACK suppression mechanisms which can also
be considered. For example, the sender's transmissions may follow
an ordinal sequence of transmission (observed through data/repair
content <objectIds> and/or <segmentIds>) which is "rewound" during
repair transmissions. Receivers may wish to limit transmission of
their NACKs only when the sender's current sequence of transmission
passes the point at which the receiver has incomplete transmis-
sions, thus reducing premature requests for repair of data the
sender may be providing in response to other receiver requests.
This mechanism can be very effective for protocol convergence in
high loss conditions when transmissions of NACKs from other
receivers (or indicators from the sender) are lost. Another mecha-
nism (particularly applicable when FEC is used) is for the sender
to embed an indication of impending repair transmissions in current
packets sent. For example, the indication may be as simple as an
advertisment of the number of FEC packets to be sent for the cur-
rent applicable coding block. Finally, some consideration might be
given to using the NACKing history of receivers to weight their
selection of NACK backoff timeout intervals. For example, if a
receiver has historically been experiencing the greatest degree of
loss, it may promote itself to statistically NACK sooner than other
receivers. Note this assumes there is some degree of correlation
over successive intervals of time in the loss experienced by
receivers. This adjustment of backoff timeout selection may
require the creation of an "early NACK" slot for these historical
NACKers. This additional slot in the NACK backoff window will
Adamson, Bormann, et al. Expires January 2002 [Page 30]
Internet Draft NORM Building Blocks July 2001
result in a longer repair cycle process which may not be desirable
for some applications. The resolution of these trade-offs may be
dependent upon the protocol's target application set or network.
Interface Description
Inputs:
1) Group greatest round trip time estimate (GRTT).
2) Group size estimate.
3) Application-defined bound on backoff timeout period.
4) NACKs from other receivers.
5) Pending repair indication from sender (may be forwarded
NACKs).
6) Current sender transmission sequence position.
Outputs:
1) Yes/no decision to generate NACK message upon backoff timer
expiration.
3.2.4 Sender NACK Processing and Repair Response
Upon reception of a repair request from a receiver in the group,
the sender will initiate a repair response procedure. The sender
may wish to delay transmission of repair content until it has had
sufficient time to accumulate potentially multiple NACKs from the
receiver set. This allows the sender to determine the most effi-
cient repair strategy for a given transport stream/object or FEC
coding block. Depending upon the approach used, some protocols may
find it beneficial for the sender to provide an indicator of pend-
ing repair transmissions as part of the its current transmitted
message content. This can aid some NACK suppression mechanisms.
Alternatively, in the case of unicast feedback from the receiver
set, it may be useful for the sender to forward (via multicast)
superseding NACK messages to the group to allow for NACK suppres-
sion when there is not multicast connectivity among the receiver
set.
When FEC is used, it is beneficial that the sender transmit previ-
ously untransmitted parity content whenever possible. This maxi-
mizes the receiving nodes' ability to reconstruct the entire trans-
mitted content from their individual subsets of received messages.
The transmitted object and/or stream content will be marked with
monotonically increasing sequence numbers (within a reasonably
large ordinal space). If the sender observes the discipline of
transmitting repair for the earliest content first, the receivers
Adamson, Bormann, et al. Expires January 2002 [Page 31]
Internet Draft NORM Building Blocks July 2001
can use a strategy of witholding repair requests for later content
until the sender once again returns to that point in the
object/stream transmission sequence. This can increase overall
message efficiency among the group and help work to keep repair
cycles relatively synchronized without dependence upon strict tim-
ing. This also helps minimize the buffering requirements of
receivers and senders and reduces redundant transmission of data to
the group at large.
Interface Description
Inputs:
1) Receiver NACKs
1) Group timing information
Outputs:
1) Repair messages (FEC and/or Data content retransmission)
3.3 Group "Join" Policies/ Procedures
Consideration should be given to how new receivers join a group
(perhaps where reliable transmission is already in progress) and
beging NACKing for any repair needs. If this is unconstrained, the
dynamics of group membership may impede the application's ability
to meet it goals progressing the transmission of data. Policies
limiting the opportunities at which receivers begin participating
in the NACK process may be used to achieve the desired behavior.
For example, it may be beneficial if receivers only attempt reli-
able reception from a newly-heard sender when upon non-repair
transmissions of data in the first FEC block of an object or logi-
cal portion of a stream. The sender may also implement policies
limiting which receivers from which it will accept NACK requests,
but this may be prohibitive for scalability reasons in some situa-
tions. In some types of bulk transfer applications (and for poten-
tial interactive applications), it may alternatively desirable to
have a looser transport synchronization policy and rely upon ses-
sion management mechanisms to control group dynamics which may
result in poor behavior.
Inputs:
1) Current object/stream data/repair content and sequencing
identifiers from sender transmissions.
Outputs:
Adamson, Bormann, et al. Expires January 2002 [Page 32]
Internet Draft NORM Building Blocks July 2001
1) Receiver yes/no decision to begin receiving and NACKing for
reliable reception of data
3.4 Reliable multicast member identification
In a NORM protocol (or other multicast protocols) where there is
the potential for multiple sources of data, it is necessary to pro-
vide some mechanism to uniquely identify the sources (and possibly
some or all receivers in some cases) within the group. Identity
based on arriving packet source addresses is insufficient for sev-
eral reasons. These reasons include routing changes for hosts with
multiple interfaces which result different packet source addresses
for a given host over time, network address translation (NAT) or
firewall devices, or other transport/network bridging approaches.
As a result, some type of unique source identifier (sourceId) field
should be present in packets transmitted by reliable multicast ses-
sion members.
3.5 Data Content identification
The data and repair content transmitted by a NORM sender requires
some form of identification in the protocol header fields. This
identification is required to facilitate the reliable NACK-oriented
repair process. These identifiers will be used in NACK messages
generated.
There are two very general types of data which may comprise bulk
transfer session content. These data types are static objects of
finite size and continuous non-finite streams. A given application
may wish to reliably multicast data content using either one or
both of these data models. While it may be possible for some
applications to further generalize this model and provide mecha-
nisms to encapsulate static objects as content embedded within a
stream, there are advantages to many applications to provide dis-
tinct support for static bulk objects and messages with the context
of a reliable multicast session. These applications may include
content caching servers, file transfer or collaborative tools with
bulk content. Applications with requirements for these static
object types can then take advantage of transport layer mechanisms
(i.e. segmentation/reassembly, caching, integrated forward error
correction coding, etc) rather than being required to provide their
own mechanisms for these functions at the application layer.
As noted, some applications may alternatively desire to transmit
bulk content in the form of one or more streams of non-finite size.
Example streams include continuous quasi-realtime message broad-
casts (e.g. stock ticker) or some content types which are part of
collaborative tools or other more complex applications. And, as
Adamson, Bormann, et al. Expires January 2002 [Page 33]
Internet Draft NORM Building Blocks July 2001
indicated above, some applications may wish to encapsulate other
bulk content (e.g. files) into one more streams within a multicast
session. Additionally, multiple streams can allow for parallized
transmission within the context of a single multicast session.
The components described within this building block draft document
are envisioned to be applicable to both of these models with the
potential for a mix of both types within a single multicast ses-
sion. To support this requirement, the normal data content identi-
fication should include a field to uniquely identify the object or
stream <objectId> within some reasonable temporal or ordinal inter-
val. Note that it is _not_ expected that this data content identi-
fication will be globally unique. It is expected that the
object/stream identifier will be unique with respect to a given
sender within the reliable multicast session and during the time
that sender is supporting a specific transport instance of that
object or stream.
Since the "bulk" object/stream content will generally require seg-
mentation, some form of segment identification <segmentId> must
also be provided. This segment identifier will be relative to any
object or stream identifier which has been provided. Thus, in some
cases, NORM protocol instantiations may be able to receive trans-
missions and request repair for multiple streams and one or more
sets of static objects in parallel. For protocol instantiations
employing FEC the <segmentId> portion of the data content identi-
fier may consist of a logical concatenation of a coding block iden-
tifier <blockId> and identifer for the specific data or parity seg-
ment of the code block. The RMT FEC Building Block (currently
"draft-ietf-rmt-bb-fec-02.txt") provides a standard message format
for identifying FEC transmission content. The "General Purpose
NACK Encapsulation Format" described herein (Section 3.2.2) is com-
patible with the RMT FEC Building Block specification.
Additionally, flags to determine the usage of the content identi-
fier fields (e.g. stream vs. object) may be applicable. Flags
may also serve other purposes in data content identification. It
is expected that any flags defined will be dependent upon individ-
ual protocol instantiations.
In summary, the following data content identification fields may be
required for NORM protocol data content messages:
1) Source node identifier (<senderId>)
2) Object/Stream identifier (<objectId>), if applicable.
3) FEC Block identifier (<blockId>), if applicable.
4) Segment identifier (<segmentId>)
5) Flags to differentiate interpretation of identifier fields
Adamson, Bormann, et al. Expires January 2002 [Page 34]
Internet Draft NORM Building Blocks July 2001
or identifier structure which implicitly indicates usage.
6) Additional FEC transmission content fields per FEC Building
Block
These fields have been identified since any generated NACK messages
will use these identifiers in requesting repair or retransmission
of data. NORM protocols are expected to greatly benefit from
interaction with other reliable multicast building blocks (Generic
Router Assist(GRA), in particular) and those other building blocks
will need to appropriately consider these anticipated requirements.
3.6 Forward Error Correction
Multiple forward error correction (FEC) approaches have been iden-
tified which can provide great performance enhancements to the
repair process of NACK-oriented and other reliable multicast proto-
cols [Metzner84, Macker97]. NORM protocols can reap additional
benefits since FEC-based repair does not _generally_ require
explicit knowledge of repair content within the bounds of its cod-
ing block size (in packets).
Generally, repair packets generated using FEC algorithms with good
erasure filling properties (e.g. Reed-Solomon) will be transmitted
only in response to NACK repair requests from receiving nodes.
However, there are benefits in some network environments for trans-
mitting some predetermined quantity of FEC repair packets multi-
plexed with the regular data segment transmissions [Gossink98].
This can reduce the amount of NACK traffic generated with rela-
tively little overhead cost when group sizes are very large or the
network connectivity has a large delay*bandwidth product with some
nominal level of expected packet loss. While the application of
FEC is not unique to NORM, these sorts of requirements may dictate
the types of algorithms and protocol approaches which are applica-
ble.
A specific issue related to the use of FEC with NORM is the mecha-
nism used to identify which portion(s) of transmitted data content
to which specific FEC packets are applicable. It is expected that
FEC algorithms will be based on generating a set of parity repair
packets for a corresponding block of transmitted data packets.
Since data content packets are uniquely identified by the concate-
nation of <sourceId/objectId/blockId/segmentId> during transport,
it is expected that FEC packets will be identified in a similar
manner. The RMT FEC Building Block specification provides detailed
recommendations concerning application of FEC and standard formats
for related reliable multicast protocol messages.
3.7 Round-trip Timing Collection
Adamson, Bormann, et al. Expires January 2002 [Page 35]
Internet Draft NORM Building Blocks July 2001
The measurement of packet propagation round-trip time (RTT) among
members of the group is required to support NACK suppression algo-
rithms, timing of sender commands or certain repair functions, and
congestion control operation. The nature of the round-trip infor-
mation collected is dependent upon the type of interaction among
the members of the group. In the case where only "one-to-many"
transmission is required, it may be necessary that only the sender
require RTT knowledge of the greatest RTT (GRTT) among the receiver
set and/or RTT knowledge of only a portion of the group. Here, the
GRTT information might be collected in a reasonably scalable man-
ner. For congestion control operation, it is possible that RTT
information may be required by each receiver in the group. In this
case, an alternative RTT collection scheme may be utilized where
receivers collect individual RTT measurements with respect to the
sender and advertise them (or an competed subset) to the group or
sender. Where it is likely that exchange of reliable multicast
data will occur among the group on a "many-to-many" basis, there
are alternative measurement techniques which might be employed for
increased efficiency [Ozdemir99]. And in some cases, there might
be absolute time synchronization among hosts which may simplify RTT
measurement. There are trade-offs in multicast congestion control
design which need further consideration before a universal recom-
mendation on RTT (or GRTT) measurement can be specified. Regard-
less of how the RTT information is collected (and more specifically
GRTT) with respect to congestion control or other requirements, the
sender will need to advertise its current GRTT estimate to the
group for timing of the
3.7.1 One-to-Many Sender GRTT Measurement
The goal of this form of RTT measurement is for the sender to learn
the GRTT among the receivers who are actively participating in NORM
operation. The set of receivers participating in this process may
be the entire group or some subset of the group determined from
another mechanism within the protocol instantiation. An approach
to collect this GRTT information follows.
The sender periodically polls the group with a message (independent
or "piggy-backed" with other transmissions) containing a <sendTime>
timestamp relative to an internal clock at the sender. Upon recep-
tion of this message, the receivers will record this <sendTime>
timestamp and the time (referenced to their own clocks) at which it
was received <recvTime>. When the receiver provides feedback to
the sender (either explicitly or as part of other feedback messages
depending upon protocol instantion specification), it will con-
struct a "response" using the formula:
<grttResponse> = <sendTime> + (<currentTime> - <recv_Time>)
Adamson, Bormann, et al. Expires January 2002 [Page 36]
Internet Draft NORM Building Blocks July 2001
where the <sendTime> is the timestamp from the last probe message
received from the source and the (<currentTime> - <recvTime>) is
the amount of time differential since that request was received
until the receiver generated the response.
The sender processes each receiver response by calculating a cur-
rent RTT measurement for the receiver from whom the response was
received using the following formula:
<receiverRtt> = <currentTime> - <grttResponse>
During the each periodic GRTT probing interval, the source keeps
the peak round trip estimate from the set of responses it has
received. The GRTT estimate should be filtered to be conservative
towards maintaining an estimate biased towards the greatest
receiver RTT measurements received. A conservative estimate of
GRTT maximizes the efficiency redundant NACK suppression and repair
aggregation. The update to the source's ongoing estimate of GRTT
is done observing the following rules:
1) If a receiver's response round trip calculation is greater
than the current GRTT estimate AND current peak, the
response value is immediately fed into the GRTT update fil-
ter given below. In any case, the source records the "peak"
receiver RTT measurement for the current probe interval.
2) At the end of the response collection period (i.e. the GRTT
probe interval), if the recorded "peak" response is less
than the current GRTT estimate AND this is the third consec-
utive collection period with a peak less than the current
GRTT estimate the recorded peak is fed into the GRTT update.
(Implicitly, Rule #1 was applied otherwise so no new update
is required).
3) At the end of the response collection period, the peak
tracking value is set to either ZERO if the "peak" is
greater than or equal to the current GRTT estimate (i.e.
Already incorporated into the filter under Rule #1) or kept
the same if its value is less than the current GRTT estimate
AND was not yet incorporated into the GRTT update filter
according to Rule #2. Thus for decreases in the source's
estimate of GRTT, the "peak" is tracked across three consec-
utive probe intervals. The current MDP implementation uses
the following GRTT update filter to incorporate new peak
responses into the the GRTT estimate:
if (peak > current_estimate)
current_estimate = 0.25 * current_estimate + 0.75 * peak;
Adamson, Bormann, et al. Expires January 2002 [Page 37]
Internet Draft NORM Building Blocks July 2001
else
current_estimate = 0.75 * current_estimate + 0.25 * peak;
This update method is biased towards maintaining an estimate of the
worst-case round trip delay. The reason the GRTT estimate is
reduced only after 3 consecutive collection periods with smaller
response peaks is to be conservative where packet loss may have
resulted in lost response messages. And then the reduction is
additionally conservatively weighted using the averaging filter
from above.
The GRTT collection period (i.e. period of probe transmission)
could be fixed at a value on the order of that expected for group
membership and/or network topology dynamics. For robustness, more
rapid probing could be used at protocol startup before settling to
a less frequent, steady-state interval. Optionally, an algorithm
may be developed to adjust the GRTT collection period dynamically
in response to the current GRTT estimate (or variations in it) and
to an estimation of packet loss. The overhead of probing messages
could then be reduced when the GRTT estimate is stable and unchang-
ing, but be adjusted to track more dynamically during periods of
variation with correspondingly shorter GRTT collection periods.
In summary, although NORM repair cycle timeouts are based on GRTT,
it should be noted that convergent operation of the protocol does
not _strictly_ depend on accurate GRTT estimation. The current
mechanism has proved sufficient in simulations and in the environ-
ments in which NORM-like protocols have been deployed to date. The
estimate provided by the algorithm tracks the peak envelope of
actual GRTT (including operating system effect as well as network
delays) even in relaitvely high loss connectivity. The steady-
state probing/update interval may potentially be varied to accommo-
date different levels of expected network dynamics in different
environments.
3.7.2 One-to-Many Receiver RTT Measurement
(TBD - Receivers "ping" sender for RTT measurement, and then
receivers competitively (worst case RTT metric) advertise their
measurements to the sender and optionally group so the sender can
determine GRTT ... Sender should still robustly advertise its cur-
rent GRTT knowledge to the group so group can use appropriate tim-
ing)
3.7.3 Many-to-Many RTT Measurement
(TBD - Describe approach based on Ozdemir99, if appropriate/appli-
cable?)
Adamson, Bormann, et al. Expires January 2002 [Page 38]
Internet Draft NORM Building Blocks July 2001
3.7.4 Sender GRTT Advertisement
To facilitate determistic NORM protocol operation, the sender
should robustly advertise its current estimation of GRTT to the
receiver set. Common, robust knowledge of the sender's current
operating GRTT estimate among the group will allow the protocol to
progress in its most efficient manner. The sender's GRTT estimate
can be robustly advertised to the group by simply embedding the
estimate into all pertinent messages transmitted by the sender.
The overhead of this can be made quite small by quantizing (com-
pressing) the GRTT estimate to a single byte of information. The
following C-lanquage function algorithm allows this to be done over
a wide range of GRTT values while maintaining a greater range of
precision for small GRTT values and less precision for large val-
ues:
unsigned char QuantizeGrtt(double grtt)
{
if (grtt > 1.0e03)
grtt = 1.0e03;
else if (grtt < 1.0e-06)
grtt = 1.0e-06;
if (grtt < 3.3e-05)
return ((unsigned char)(grtt * 1.0e06) - 1);
else
return ((unsigned char)(ceil(255.0.-
(13.0 * log(1.0e03/grtt)))));
}
Note that this function is useful for quantizing GRTT times in the
range of 1 microsecond to 1000 seconds. Of course, NORM protocol
implementations may wish to further constrain advertised GRTT esti-
mates (e.g. limit the maximum value) for practical reasons.
3.8 Group Size Determination/Estimation
(TBD)
3.9 Congestion Control Operation
(TBD - A NACK-oriented protocol may place limitations/requirements
on collection of information to facilitate congestion control of
senders. There are a number of specific issues of TCP-Friendly
Multicast Congestion Control (TFMCC)which must be addressed.)
3.10 Router/Intermediate System assistance
(TBD - NACK-oriented protocols can potentially benefit greatly from
Adamson, Bormann, et al. Expires January 2002 [Page 39]
Internet Draft NORM Building Blocks July 2001
router assistance. In particular, additional NACK suppression
would be beneficial (This may impact how synchronized receiver NACK
cycles are, sender advertisement of NACK-cycle parameters (i.e.
GRTT, group size, etc), NACK content, others)
3.11 Additional protocol mechanisms
(TBD- e.g. positive acknowledgement collection, performance
statistics collection, session management, etc)
4.0 Security Considerations (TBD)
5.0 References
[Mankin98] A. Mankin, A. Romanow, S. Bradner, V. Paxson, "IETF
Criteria for Evaluating Reliable Multicast Transport and Applica-
tion Protocols", RFC 2357, June 1998.
[Pingali93] S. Pingali, D. Towsley, J. Kurose. "A Comparison of
Sender-Initiated and Receiver-Initiated Reliable Multicast Proto-
cols". In Proc. INFOCOM, San Francisco, CA, October 1993.
[Levine96] B.N. Levine, J.J. Garcia-Luna-Aceves. "A Comparison of
Known Classes of Reliable Multicast Protocols", Proc. Interna-
tional Conference on Network Protocols (ICNP-96), Columbus, Ohio,
Oct 29--Nov 1, 1996.
[Clark90] D. Clark, D. Tennenhouse, "Architectural Considerations
for a New Generation of Protocols". In Proc. ACM SIGCOMM, pages
201--208, September 1990.
[Deering89] S. Deering. "Host Extensions for IP Multicasting".
Internet RFC1112, August 1989.
[Floyd95] S. Floyd, V. Jacobson, S. McCanne, C. Liu, and L.
Zhang. "A Reliable Multicast Framework for Light-weight Sessions
and Application Level Framing", Proc. ACM SIGCOMM, August 1995.
[Nonnenmacher98] J. Nonnenmacher and E. W. Biersack, "Optimal
multicast feedback," in IEEE Infocom , (San Francisco, California),
p. 964, March/April 1998.
[Gossink98] D. Gossink, J. Macker, "Reliable Multicast and Inte-
grated Parity Retransmission with Channel Estimation", IEEE GLOBE-
COM 98'.
[Metzner84] J. Metzner, "An Improved Broadcast Retransmission Pro-
tocol", IEEE Transactions on Communications, Vol. Com-32, No.6,
Adamson, Bormann, et al. Expires January 2002 [Page 40]
Internet Draft NORM Building Blocks July 2001
June 1984.
[Macker97a] J. Macker, "Integrated Erasure-Based Coding for Reli-
able Multicast Transmission", IRTF Meeting presentation, March
1997.
[Macker97b] J. Macker, "Reliable Multicast Transport and Integrated
Erasure-based Forward Error Correction", Proc. IEEE MILCOM 97,
October 1997.
[Ozdemir99] V. Ozdemir, S. Muthukrishnan, I. Rhee, "Scalable, Low-
Overhead Network Delay Estimation", NCSU/AT&T White Paper, February
1999.
6.0 Authors' Addresses
Brian Adamson
adamson@itd.nrl.navy.mil
Naval Research Laboratory
Washington, DC, USA, 20375
Carsten Bormann
cabo@tellique.de
Tellique Kommunikationstechnik GmbH
Gustav-Meyer-Allee 25 Geb ude 12
D-13355 Berlin, Germany
Mark Handley
mjh@aciri.org
1947 Center Street, Suite 600
Berkeley, CA 94704
Joe Macker
macker@itd.nrl.navy.mil
Naval Research Laboratory
Washington, DC, USA, 20375
Adamson, Bormann, et al. Expires January 2002 [Page 41]
--============_-1216460392==_============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
--
Brian
__________________________________
Brian Adamson
<http://manimac.itd.nrl.navy.mil>
<mailto:adamson@itd.nrl.navy.mil>
--============_-1216460392==_============--
>From owner-rmt@listserv.lbl.gov Fri Jul 20 13:54:48 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f6KKsih29351;
Fri, 20 Jul 2001 13:54:44 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f6KKsgR29347
for <rmt@listserv.lbl.gov>; Fri, 20 Jul 2001 13:54:42 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f6KKsfT23137
for <rmt@listserv.lbl.gov>; Fri, 20 Jul 2001 13:54:41 -0700 (PDT)
Received: from itd.nrl.navy.mil (s2.itd.nrl.navy.mil [132.250.83.3])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f6KKseA23132
for <rmt@lbl.gov>; Fri, 20 Jul 2001 13:54:40 -0700 (PDT)
Received: from [132.250.92.151] (manimac.itd.nrl.navy.mil [132.250.92.151])
by itd.nrl.navy.mil (8.8.8/8.8.8) with ESMTP id QAA05375;
Fri, 20 Jul 2001 16:48:22 -0400 (EDT)
Mime-Version: 1.0
X-Sender: adamson@pop.itd.nrl.navy.mil
Message-Id: <p05010410b77e495d3ee6@[132.250.92.151]>
In-Reply-To: <NEBBIAPCNKEDCLPNFBNCAEPLCGAA.luby@digitalfountain.com>
References: <NEBBIAPCNKEDCLPNFBNCAEPLCGAA.luby@digitalfountain.com>
Date: Fri, 20 Jul 2001 16:48:23 -0400
To: <internet-drafts@ietf.org>
From: Brian Adamson <adamson@itd.nrl.navy.mil>
Subject: draft-ietf-rmt-pi-norm-02.txt
Cc: "Lorenzo Vicisano" <lorenzo@cisco.com>,
"Roger Kermode" <Roger.Kermode@motorola.com>, <rmt@lbl.gov>
Content-Type: multipart/mixed; boundary="============_-1216460390==_============"
Sender: owner-rmt@lbl.gov
Precedence: bulk
--============_-1216460390==_============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Please post this draft on the IETF Internet Drafts archive.
This is an update of an existing WG draft (RMT).
--============_-1216460390==_============
Content-Id: <p05010410b77e495d3ee6@[132.250.92.151].0.0>
Content-Type: text/plain; name="draft-ietf-rmt-pi-norm-02.txt"; charset="us-ascii" ; format="flowed"
Content-Disposition: attachment; filename="draft-ietf-rmt-pi-norm-02.txt"
; modification-date="Fri, 20 Jul 2001 16:44:52 -0400"
RMT Working Group B. Adamson/Newlink
INTERNET-DRAFT C. Bormann/Tellique
draft-ietf-rmt-pi-norm-02.txt M. Handley/ACIRI
Expires: January 2002 J. Macker/NRL
July 2001
NACK-Oriented Reliable Multicast Protocol (NORM)
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other docu-
ments at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (1999). All Rights Reserved.
Abstract
This document describes the messages and procedures of the Nega-
tive-acknowledgement (NACK) oriented reliable multicast (NORM).
This revision of the document represents an initial outline of the
protocol description. The document requires refinement in a number
of areas to be considered complete. At this time, the document
describes the high level details of the reliable multicast bulk
transfer service model this protocol hopes to fulfill and the gen-
eral message types and mechanisms which will be used to accomplish
those goals.
Adamson, Borman, et al. Expires January 2002 [Page 1]
Internet Draft NORM Protocol July 2001
1.0 Protocol Design Goals
NORM is designed to provide end-to-end reliable transport of data
from sender(s) to a group of receivers over a multicast-capable
network. The primary design goal of NORM is to provide for effi-
cient, scalable, and robust bulk data (e.g. computer files, trans-
mission of persistent data) transfer adaptable (preferably in an
automated fashion) across heterogeneous networks and topologies.
The protocol is capable of operating in an end-to-end fashion with
no assistance from intermediate systems beyond basic IP multicast
group management and forwarding services. However, an additional
design goal will be compatibility with other reliable multicast
"building blocks" [REF RMT Building Block Guidelines] to take
advantage of additional network capabilities when available. Thus,
while the techniques utilized in NORM are principally applicable to
"flat" network distribution, they might also be applied to a given
level of a hierarchical (e.g. tree-based) multicast distribution
system if so desired. NORM can make use of reciprocal (among
senders and receivers) multicast routing when available but will
also be capable of efficient operation in asymmetric multicast
topologies [REF single source multicast, etc].
Group communication scalability requirements leads to adaptation of
negative acknowledgement (NACK) based protocol schemes [REF.].
NORM is a protocol centered around the use of selective NACKs to
request repairs of missing data. NORM also uses NACK suppression
methods and dynamic event timers to reduce retransmission requests
and avoid congestion within the network. When used in pure multi-
cast session operation, both NACKs and repair transmissions are
multicast to the group to aid in feedback and control message sup-
pression. This feature and additional message aggregation func-
tionality reduce the likelihood of multicast control message implo-
sion. NORM also dynamically measures the greatest group roundtrip
time (GRTT) between sources and the set of multicast receivers to
further improve the efficiency of the protocol state timers and
probabilistic backoff algorithms. This allows NORM to scale well
while maintaining reliable data delivery transport with low latency
relative to the network topology over which it is operating. NORM
also provides for the use of packet-level forward error correction
(FEC) techniques for efficient multicast repair and optional proac-
tive transmission robustness.
Another aspect of the NORM protocol design is providing support for
distributed multicast session participation with minimal coordina-
tion among sources and receivers. The protocol allows sources and
receivers to dynamically join and leave multicast sessions at will
with minimal overhead for control information and timing synchro-
nization among participants. To accommodate this capability, NORM
Adamson, Borman, et al. Expires January 2002 [Page 2]
Internet Draft NORM Protocol July 2001
protocol message headers contain some common information allowing
receivers to easily synchronize to sources throughout the lifetime
of a defined session. These common headers also include support
for collection of transmission timing information (e.g., round trip
delays) that allows NORM to adapt itself to a wide range of dynamic
network conditions with little or no pre-configuration. The proto-
col is purposely designed to be tolerant of inaccurate timing esti-
mations or lossy conditions which may occur many networks includin
mobile and wireless. The protocol is also designed to exhibit con-
vergence even under cases of heavy packet loss and large queueing
or transmission delays.
While the various features of NORM are designed to provide some
measure of general purpose utility, it is important to emphasize
the understanding that "no one size fits all" in the reliable mul-
ticast transport arena. There are numerous engineering tradeoffs
involved in reliable multicast transport design and this requires
an increased awareness of application and network architecture con-
siderations. Performance requirements affecting design can
include: group size, heterogeneity (e.g., capacity and/or delay),
asymmetric delivery, data ordering, delivery delay, group dynamics,
mobility, congestion control, and transport across low capacity
connections. NORM contains various protocol parameters to accommo-
date many of these differing requirements, but there is an assumed
model of bulk transfer transport service that drives the trade-offs
resulting in the protocol described here.
1.1 NORM Transport Service Model
An instance of the NORM protocol (NormSession) is defined within
the context of one or more senders and receivers mutually communi-
cating with prdefined IP addresses and host port(s). While point-
to-point (unicast) NormSessions may be established between a pair
of protocol participants (NormNodes), it is anticipated the proto-
col will be used for multicast data distribution and that partici-
pating nodes will communicate on a common IP multicast group
address and port number which has been chosen via other means (e.g.
MBONE session directory tools, administrative coordination, SIP
signalling, etc). Note that the protocol provides for an optional
mechanism for receiver nodes to use unicast addressing to provide
feedback to senders in networks where this is required (e.g. Single
Source Multicast Routing, asymmetric topologies, etc).
The protocol design is principally driven with the assumption of a
single sender transmitting bulk data content to a group of
receivers. However, the protocol does provide for multiple senders
to coexist within the context of a NormSession. In initial imple-
mentations of this protocol, it is anticipated that multiple
Adamson, Borman, et al. Expires January 2002 [Page 3]
Internet Draft NORM Protocol July 2001
senders will transmit independently of one another and receivers
will maintain state as necessary for each independent sender. In
future iterations of this document, it is possible that some
aspects of protocol operation (e.g. round-trip time collection)
will provide for alternate modes allowing more efficient perfor-
mance for applications requiring multiple senders.
NORM provides for three types of bulk data content objects (NormOb-
jects) to be reliably transported. These types include static com-
puter memory data content (NORM_OBJECT_DATA), computer storage
files (NORM_OBJECT_FILE), and non-finite streams of continuous data
content (NORM_OBJECT_STREAM). The distinction between
NORM_OBJECT_DATA and NORM_OBJECT_FILE is simply to provide a "hint"
to receivers in NormSessions serving multiple types of content as
to what type of storage should be allocated for received content
(i.e. memory or file storage). Other than that distinction, the
two are identical, providing for reliable transport of finite units
of content. The use of the NORM_OBJECT_STREAM type is at the
application's discretion and conceivably be used to carry static
data or file content also. Reliable stream service also opens up
other possibilities such as reliable messaging or other unbounded,
perhaps dynamically produced content. The NORM_OBJECT_STREAM pro-
vides for reliable transport analogous to that of the Transmission
Control Protocol (TCP) although NORM receivers will be able to
begin receiving stream content at any point in time (The applica-
bility of this feature will depend upon the application). The
static data and file services are anticpated to be useful for mul-
ticast-based cache applications with the ability to reliably pro-
vide transmission/repair of a large set of static data. Other
types of static data/file "casting" services might make use of
these transport object types, too. The NORM protocol allows for a
small amount of "out-of-band" data (NORM_INFO) to be attached to
the data content objects transmitted by the sender. This readily-
available "out-of-band" data allows multicast receivers to quickly
and efficiently determine the nature of the bulk content (data,
file, or stream) being transmitted to allow application-level con-
trol of the receiver node's participation in the current transport
activity. This allows the protocol to be flexible with minimal
pre-coordination among senders and receivers.
NORM does _not_ provide for global or application-level identifica-
tion of data content within in its message headers (It should be
noted that the NORM_INFO out-of-band data mechanism can be lever-
aged by the application for this purpose if desired, or identifica-
tion could alternatively be embedded within the data content).
NORM identifies data content objects (NormObjects) with transport
identifiers which are applicable while the sender is transmitting
and/or repairing the given object. These transport data content
Adamson, Borman, et al. Expires January 2002 [Page 4]
Internet Draft NORM Protocol July 2001
identifiers are assigned in a montonically increasing fashion by
each NORM sender during the course of a NormSession. Each sender
maintains its transport identifier assignments independently so
NormObjects are uniquely identified during transport by the con-
catenation of the sender's session-unique identifier (NormNodeId)
and the assigned NormObject transport identifier (NormTransportId).
The NormTransportIds are assigned from a large (32 bit?) numeric
space in increasing order and may be reassigned for long-lived ses-
sions. The NORM protocol provides mechanisms so that the sender
application may terminate transmission of data content and inform
the group of this in an efficient manner. Other similar protocol
control mechanisms (e.g. session termination, receiver synchroniza-
tion, etc) are specified so that reliable multicast application
variants may construct different, complete bulk transfer communica-
tion models to meet their goals.
In summary, the NORM protocol's goal is to provide reliable trans-
port of data content objects (including a potentially mixed set of
types) to the receiver set from one or more senders. The senders
will queue and transmit content in the form of static data or files
and/or non-finite, ongoing stream types. The sender will provide
for repair transmission of this content in response to NACK mes-
sages received from the receiver group. Mechanisms for "out-of-
band" information and other session management mechanisms are also
specified for use by applications to form a complete reliable mul-
ticast transport solutions for a range different purposes.
2.0 Protocol Definition
2.1 Assumptions
A NORM protocol instantiation (NormSession) is defined by the con-
text of participants communicating connectionless (e.g. User Data-
gram Protocol (UDP)) packets over an Internet Protocol (IP) network
on a common, pre-determined network address and host port number.
Generally, the participants exchange packets on an IP multicast
group address, but unicast transport may also be established or
applied as an adjunct to multicast delivery. Currently the protocol
uses a single multicast address for transmissions associated with a
given NORM session. However, in the future, it is possible that
multiple multicast addresses might be employed to segregate sepa-
rate degrees of repair information to different groups of receivers
experiencing different packet loss characteristics with respect to
a given sender. This capability is under ongoing investigation in
the research community [REF]. For multicast operation, the NORM
protocol assumes basic IP multicast forwarding service is available
at least from the sender(s) to the receiver set. However, the
Adamson, Borman, et al. Expires January 2002 [Page 5]
Internet Draft NORM Protocol July 2001
protocol also supports asymmetry where receiver participants may
transmit back to sender participants via unicast routing instead
of broadcasting to the session multicast address.
Each participant (NormNode) within an NormSession is assumed to
have an preselected unique XX-bit (TBD) identifier (NormNodeId).
NormNodes MUST have uniquely assigned identifiers within a single
NormSession to distinquish between possible multiple senders and to
distinguish feedback information from different receivers. The
protocol does not preclude multiple sender nodes actively transmit-
ting within the context of a single NORM session (i.e. many- to-
many operation), but any type of interactive coordination among
these senders is assumed to be controlled by a higher protocol
layer (perhaps using some of the optional NORM mechanisms later
specified to perform this coordination).
Unique data content transmitted within a NormSession uses sender-
assigned identifiers (NormObjectTransportIds) which are valid and
applicable only during the actual _transport_ of the particular
portion of data content (i.e. for as long as the sender is trans-
mitting and providing repair of the indicated data content). Any
globally unique identification of transported data content must be
assigned and processed by the higher level application using the
NORM transport service.
2.2 General Protocol Operation
A NORM sender primarily generates messages of type NORM_DATA which
carry the data content and related FEC parity-based repair informa-
tion for the bulk data/file or stream objects being transferred.
Parity content is by default sent only on in response to receiver
repair requests (NACKs) and thus normally imposes no additional
protocol overhead. However, the transport of an object can be
optionally configured to proactively transmit some amount of parity
packets along with the original data content to potentially enhance
performance (e.g., improved delay) at the cost of additional over-
head with initial data transmission. This configuration may be
sensible for certain network conditions and can allow for robust,
asymmetric multicast (e.g., unidirectional routing, satellite,
cable) [REF] with minimal receiver feedback, or, in some cases,
none.
A sender message of type NORM_INFO is also defined and is used to
carry any optional "out-of-band" context information for a given
transport object. Because of its simple, nature content of
NORM_INFO messages can be NACKed and repaired with a slightly lower
delay process than NORM's general FEC-encoded data content.
NORM_INFO may serve special purposes for some buld transfer,
Adamson, Borman, et al. Expires January 2002 [Page 6]
Internet Draft NORM Protocol July 2001
reliable multicast applications where receivers join the group mid-
stream and need to ascertain contextual information on the current
content being transmitted. The NACK process for NORM_INFO will be
described later.
The sender also generates messages of type NORM_CMD to perform cer-
tain protocol operations such as congestion control, end-of-trans-
mission flushing, round trip time estimation, receiver synchroniza-
tion, and optional positive acknowledgement requests or application
defined commands. The transmission of NORM_CMD messages from the
sender is accomplished by one of three different processes. These
include single, best effort unreliable transmission of the command,
repeated redundant transmission of the command, and positively
acknowledged commands. The transmission technique used for a given
command depends upon the function of the command. Several core
commands are defined for basic protocol operation. Additionally,
implementations may wish to consider providing the option of appli-
cation-defined commands which can take advantage of these transmis-
sion methodologies available for command. These transmission
methodologies make use of information available to the protocol
engine (e.g. round-trip timing, transmission rate, etc) to perform
efficiently.
An NORM receiver generates messages of type NORM_NACK or NORM_ACK
in response to transmissions of data and commands from a sender.
The NORM_NACK messages are generated to request repair of detected
data transmission losses. Receivers generally detect losses by
tracking the sequence of transmission from a sender. Sequencing
information is embedded in the transmitted data packets and end-of-
transmission commands from the sender. NORM_ACK messages are gen-
erated in response to certain commands transmitted by the sender.
In the general (and most scalable) protocol mode, receivers do not
transmit any NORM_ACK messages. However, in order to meet poten-
tial user requirements for positive data acknowledgement, and to
collect more detailed information for potential multicast conges-
tion control algorithms, NORM_ACK messages are defined and poten-
tially used. NORM_ACK messages are also generated by a small sub-
set of receivers when NORM dynamic end-to-end congestion control is
in operation.
NORM allows for reliable transfer of three different types of data
content. These include the type NORM_OBJECT_DATA which are static,
persistent blocks of data content maintained in the sender's appli-
cation memory storage and the type NORM_OBJECT_FILE which corre-
sponds to data stored in the sender's non-volatile file system.
Both of these types represent "NormObjects" of finite size which
are encapsulated for transmission and are temporarily yet uniquely
identified with the given sender's NormNodeId and a temporarily
Adamson, Borman, et al. Expires January 2002 [Page 7]
Internet Draft NORM Protocol July 2001
unique NormObjectTransportId. The third type of
All transmissions by individual senders and receivers are subject
to rate control governed by a peak transmission rate set for each
participant by the application. This can be used to limit the
quantity of multicast data transmitted by the group. When NORM's
congestion control algorithm is enabled the rate for senders is
automatically adjusted. And even when congestion control is
enabled, it may be desirable in some cases to establish minimum and
maximum bounds for the rate adjustment depending upon the applica-
tion.
2.3 Message Type and Header Definitions
As mentioned previously, there are two primary classes of NORM mes-
sages: messages generated by the sender of reliable multicast traf-
fic and messages generated by receivers.
2.3.1 NORM Common Message Header
There are some common message fields contained in all NORM message
types. All NORM protocol messages begin with a common header with
information fields as follows:
NORM Common Packet Header
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| version | type | sequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The "version" field is a (TBD)-bit value indicating the protocol
version number. Currently, NORM implementations SHOULD ignore
received messages with a different protocol version number. This
number is intended to indicate and distinguish upgrades of the pro-
tocol which may be non-interoperable.
The message "type" field is a (TBD)-bit value indicating the NORM
protocol message type. These types are defined as follows:
Adamson, Borman, et al. Expires January 2002 [Page 8]
Internet Draft NORM Protocol July 2001
Message Value
NORM_INFO 1
NORM_DATA 2
NORM_CMD 3
NORM_NACK 4
NORM_ACK 5
NORM_REPORT 6
The "sequence" field is a 16-bit value which is set by the message
originator as a monotonically increasing number incremented with
each NORM message transmitted. This value can be monitored by
receiving nodes to detect packet losses in the transmission. Note
that this value is NOT used to detect missing reliable data con-
tent, but is intended for use in an algorithm estimating raw packet
loss for congestion control purposes. The size of this field is
intended to be sufficient to allow detection of a reasonable range
of packet loss within the expected delay-bandwidth product of
expected network connections.
The "source_id" field is a 32-bit value identifying the node which
sent the message. A participant's NORM node identifier
(NormNodeId) can be set according to the application needs but
unique identifiers must be assigned within a single NormSession.
In some cases, use of the host IP address or a hash of it can suf-
fice, but alternative methodologies for assignment and potential
collision resolution of node identifiers within a multicast session
need to be considered. For example, the "source identifier" mecha-
nism defined in the RTPv2 specification [REF RTP] may be applicable
to use for NORM node identifiers. At this point in time, the pro-
tocol makes no assumptions about how these unique identifiers are
actually assigned.
NORM Message Types
Sender Messages:
NORM_DATA
This is expected to be the predominant message type transmitted by
NORM senders. These messages will contain data content for objects
of type NORM_OBJECT_DATA, NORM_OBJECT_FILE, and NORM_OBJECT_STREAM.
A goal of the protocol design is to provide for parallel transmis-
sion of different streams and data/file sets. NORM_DATA messages
will generally consist of original data content of the application
data being transmitted. The content size of these messages will a
Adamson, Borman, et al. Expires January 2002 [Page 9]
Internet Draft NORM Protocol July 2001
maximum of NormSegmentSize which is constant for the duration of a
given sender's term of participation in the session. Senders
advertise their NormSegmentSize in applicable messages which they
transmit. This allows receivers to allocate appropriate buffering
resources and to determine other information in order to properly
process received data messaging. Note this message type will also
be used to convey FEC parity repair content for NormObjects sent.
NORM_DATA Header
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flags | grtt | segment_size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| object_transport_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| object_size_lsb |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| object_size_msb | reserved | fec_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| fec_encoding_name | fec_num_parity |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| fec_block_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| fec_symbol_id | fec_num_data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| offset_lsb* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| offset_msb* | payload_len* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| payload_data* |
* Note the "offset" and "payload_len" fields for NORM_DATA messages
containing parity information are actually values computed from FEC
encoding of the "offset" and "payload_len" fields of the data seg-
ments of the applicable coding block. Thus, for parity packets,
these do _not_ represent these values directly.
The "flags" field contains a number of different binary flags pro-
viding information and hints regarding how the receiver should han-
dle the identified object. Defined flags in this field include:
Adamson, Borman, et al. Expires January 2002 [Page 10]
Internet Draft NORM Protocol July 2001
+---------------------+-------+------------------------------------------+
| Flag | Value | Purpose |
+---------------------+-------+------------------------------------------+
|NORM_FLAG_REPAIR | 0x01 | Indicates message is a repair transmis- |
| | | sion |
+---------------------+-------+------------------------------------------+
|NORM_FLAG_INFO | 0x02 | Indicates availability of NORM_INFO for |
| | | object, |
+---------------------+-------+------------------------------------------+
|NORM_FLAG_UNRELIABLE | 0x04 | Indicates that repair transmissions for |
| | | the specified object will be unavail- |
| | | able. (One-shot, best effort transmis- |
| | | sion) |
+---------------------+-------+------------------------------------------+
|NORM_FLAG_FILE | 0x08 | Indicates object is "file-based" data |
| | | (hint to use disk storage for reception) |
+---------------------+-------+------------------------------------------+
|NORM_FLAG_STREAM | 0x10 | Indicates object is of type |
| | | NORM_OBJECT_STREAM. |
+---------------------+-------+------------------------------------------+
The NORM_FLAG_REPAIR flag is set when the associated transmission
is a repair transmission. This information can be used by
receivers to facilitate a join policy where it is desired that
newly joining receivers only begin participating in the NACK pro-
cess upon receipt of new "fresh" data. The NORM_FLAG_INFO flag is
se only when there optional NORM_INFO content is available for the
associated object. Thus, receivers will NACK for retransmission of
NORM_INFO only when it is available. The NORM_FLAG_UNRELIABLE flag
is set when the sender wishes to transmit and object with "best
effort" delivery only and will not supply repair transmissions for
the object. The NORM_FLAG_FILE flag can be set as a "hint" from
the sender that the associated object should be stored in non-
volatile storage. The NORM_FLAG_STREAM flag is set when the iden-
tified object is of type NORM_OBJECT_STREAM. Note that the
"object_size" field is no longer applicable (Another use for this
field for "stream" objects may be determined as this capability is
designed).
The "grtt" field contains a non-linear quantized representation of
the sender's current estimate of group round-trip time (GRTT).
This value is used to control timing of the NACK repair process and
other aspects of protocol operation as described in this document.
The "segment_size" field indicates the sender's current setting for
maximum message payload content (in bytes). The "fec_type" field
describes the error correction coding technique and parameters the
sender is using to calculate parity repair segments. Knowledge of
Adamson, Borman, et al. Expires January 2002 [Page 11]
Internet Draft NORM Protocol July 2001
these fiels allows a NORM receiver to allocate appropriate buffer-
ing and FEC decoding resources.
The "object_transport_id" field is a monotonically and incremen-
tally increasing value assigned by a sender to the object being
transmitted. Transmissions and repair requests related to that
object use the same "object_id" value. For sessions of very long
or indefinite duration, the "object_id" field may be repeated, but
it is presumed that the 32-bit field size provides an adequate
enough sequence space to prevent temporary object confusion amongst
receivers and sources (i.e. receivers SHOULD re-synchronize with a
server when receiving object sequence identifiers sufficiently out-
of-range with the current state kept for a given source). During
the course of its transmission within a NORM session, an object is
uniquely identified by the concatenation of the sender "node_id"
and the given "object_transport_id". Note that NORM_INFO messages
associated with the identified object carry the same "object_trans-
port_id" value.
The "object_size" fields indicate the total size of the object (in
bytes). This information is used by receivers to determine storage
requirements and/or allocate storage for the received object.
Receivers with insufficient storage capability may wish to forego
reception (i.e. not NACK for) of the indicated object. The
"object_size" fields are not applicable for objects of type
NORM_OBJECT_STREAM. (Note: The "object_size" fields _may_ be
defined to serve an alternative use in this case).
The "fec_id" field corresponds to the FEC Encoding Identifier
described in the FEC Building Block document (currently "draft-
ietf-rmt-bb-fec-03.txt"). The packet format illustrated above
assumes "Small Block Systematic Codes" which correspond to an FEC
Encoding Identifier equal to 129.
The "fec_encoding_name" and "fec_num_parity" fields correspond to
the "FEC Encoding Name" and "Number of redundant symbols" fields of
the FEC Object Transmission Information format given by the FEC
Building Block document. The "fec_encoding_name" shall be a value
corresponding to the particular type of Small Block Systematic Code
being used (e.g. Reed-Solomon GF(2^8), Reed-Solomon GF(2^16), etc).
The standardized assignment these values are TBD. The
"fec_num_parity" field corresponds to a parameter for generating
specific FEC encoding/decoding algorithms for the named code. For
example, Reed-Solomon codes may be arbitrarily shortened to create
different code variations for a given block length. In this case,
the "fec_num_parity" value indicates the maximum number of avail-
able parity segments for the coding block from the sender. This
Adamson, Borman, et al. Expires January 2002 [Page 12]
Internet Draft NORM Protocol July 2001
field _may_ be interpreted differently for other systematic codes
as they are defined.
The "fec_block_id", "fec_symbol_id", "fec_num_data" fields directly
correspond to the "encoding block number", "encoding symbol id",
and "Source block length" fields of the FEC Payload ID format given
by the FEC Building Block document. The "fec_block_id" identifies
the coding block while the "fec_symbol_id" identifies which spe-
cific symbol (segment) within the coding block the attached packet
conveys. Given the "fec_num_data" (Source block length) informa-
tion of how many symbols of application data is contained in the
block, the receiver can determine whether the attached symbol is
data or parity content and treat it appropriately. (For systematic
codes, symbols numbered 0 through (fec_num_data-1) contain applica-
tion data while symbols numbered (fec_num_data) through
(fec_num_data+fec_numparity-1) contain the parity content calcu-
lated for the block).
The "offset" and "payload_len" fields are used to identify the
position and quantity of the content of the packet payload. For
senders employing systematic FEC encoding, these fields will corre-
spond to the actual values for NORM_DATA messages which contain
original data content. For NORM_DATA messages containing calcu-
lated parity content, these fields will actually contain the values
computed by FEC encoding of the "offset" and "length" values of the
data segments of the corresponding FEC coding block. This allows
the "offset" and "length" values of missing data content to be
determined when decoding an FEC coding block.
The "payload_data" field contains original data or computed parity
content for the identified segment. The maximum length of this
field corresponds to the sender's NormSegmentSize. The length of
this field for messages containing parity content will always be of
the length NormSegmentSize. When encoding a block of data segments
of varying sizes, the FEC encoder SHALL assume zero value padding
for data segments less than the NormSegmentSize. The receiver will
use the "length" information to properly retrieve receive data con-
tent and deliver it to the application.
NORM_INFO
The NORM_INFO message is used to convey _optional_ "out-of-band"
context information for objects transmitted. An example may be
MIME type information for the associated file, data, or stream
object. Receivers might use this information to make a decision as
whether to participate in reliable reception of the associated
Adamson, Borman, et al. Expires January 2002 [Page 13]
Internet Draft NORM Protocol July 2001
object. Each NormObject may have an independent unit of NORM_INFO
associated with it. NORM_DATA messages contain a flag to indicate
the availability of NORM_INFO for a given NormObject. NORM
receivers may NACK for retransmission of NORM_INFO when they have
not received it for a given NormObject. The size of the NORM_INFO
content is limited to that of a single NormSegmentSize for the
given sender. This atomic nature allows the NORM_INFO to be
rapidly and efficiently repaired within the NORM transmission pro-
cess.
NORM_INFO Header
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flags | grtt | segment_size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| object_transport_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| object_size_lsb |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| object_size_msb | reserved | fec_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| fec_encoding_name | fec_num_parity |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| payload_data |
The "flags", "grtt", "segment_size", "object_transport_id",
"object_size", "fec_id", "fec_encoding_name", and "fec_num_parity"
fields carry the same information and serve the same purpose as
with NORM_DATA messages. The "payload_data" field contains the
application-defined content which can be used by the receiver
application for various purposes.
NORM_CMD
NORM_CMD messages are transmitted by senders to perform a number of
different protocol functions. This includes round-trip timing col-
lection, potential congestion control functions, synchronization of
receiver NACKing "windows", notification of sender status and other
core protocol functions. A core set of NORM_CMD messages will be
enumerated. A range of command types will remain undefined for
potential application-specific usage. Some NORM_CMD types (possi-
bly including application-defined commands) may have some dynamic
content attached. This content will be limited to a single Norm-
SegmentSize to retain the atomic nature of commands. The NORM_CMD
message begins with a common header, following the usual NORM
Adamson, Borman, et al. Expires January 2002 [Page 14]
Internet Draft NORM Protocol July 2001
message common header. The header format is defined as:
NORM_CMD Common Header
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
grtt | flavor | ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The "grtt" field provides the same information and serves the same
purpose as with NORM_DATA and NORM_INFO messages. The "flavor"
field indicates the type of command to follow. The command flavors
(types) include:
+------------------+--------------+----------------------------------+
| Command | Flavor Value | Purpose |
+------------------+--------------+----------------------------------+
|NORM_CMD_FLUSH | 1 | Indicates sender temporary or |
| | | permanent end-of-transmission. |
| | | (Assists in robustly initiating |
| | | outstanding repair requests from |
| | | receivers). |
+------------------+--------------+----------------------------------+
|NORM_CMD_SQUELCH | 2 | Advertisement of current repair |
| | | window in response to out-of- |
| | | range NACKs. |
+------------------+--------------+----------------------------------+
|NORM_CMD_ACK_REQ | 3 | Requests positive acknowledge- |
| | | ment of a watermark point from a |
| | | specific list of receivers. |
+------------------+--------------+----------------------------------+
|NORM_CMD_GRTT_REQ | 4 | Probe used in collection of |
| | | sender's group GRTT estimate and |
| | | possibly congestion control |
| | | feedback. |
+------------------+--------------+----------------------------------+
NORM_CMD(FLUSH)
The NORM_CMD_FLUSH command is sent when the sender reaches the end
of any data content and pending repairs it has queued for transmis-
sion. This command is repeated once per 2*GRTT to excite the
receiver set for any outstanding repair requests for data up to and
including the point indicated by the FLUSH message. The number of
repeats is equal to ROBUST_FACTOR. The greater this number, the
higher the probability that all applicable receivers will be
Adamson, Borman, et al. Expires January 2002 [Page 15]
Internet Draft NORM Protocol July 2001
excited for repair requests (NACKs) _and_ the corresponding NACKs
are delivered to the sender. If a NACK message interrupts the
flush process, the sender will re-initiate the flush process when
repair transmissions are completed. Note that receivers also
employ a timeout mechanism to self-initiate NACKing when a sender
is determined to have gone "idle". This inactivity timeout is
related to 2*GRTT*ROBUST_FACTOR and will be discussed more later.
With a sufficient ROBUST_FACTOR value, data content is delivered
with a high assurance of reliability. The penalty of a large
ROBUST_FACTOR value is potentially excess sender NORM_CMD_FLUSH
transmissions and a longer timeout for receivers to self-initiate a
terminal NACK process. The format of the NORM_CMD_FLUSH message
(in addition to the NORM message common header) is:
NORM_CMD(FLUSH) Header
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| grtt | flavor = 1 | fec_symbol_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| fec_block_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| object_transport_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In addition to the common NORM_CMD "grtt" and "flavor" fields, the
NORM_CMD(FLUSH) message contains fields to identify the current
logical transmit position of the sender. These fields consist of
"fec_symbol_id", "fec_block_id", and "object_transport_id". These
fields are interpreted in the same manner as the fields of the same
names in the NORM_DATA message type. Receivers are expected to
check their completion state and initiate the NACK repair process
if they have outstanding repair needs up to this transmission
point. If the receivers have no outstanding repair needs, no
response is generated.
NORM_CMD(SQUELCH)
The NORM_CMD_SQUELCH command is multicast to the receiver set in
response to invalid NACKs received by the sender. The
NORM_CMD_SQUELCH command is limited to be sent at once per 2*GRTT
at the most. The NORM_CMD_SQUELCH advertises the "repair window"
of the sender by identifying the earliest (lowest) transmission
point for which it will provide repair, along with an encoded list
of objects from that point forward which are still valid for
repair. This mechanism allows the sender application to abort
Adamson, Borman, et al. Expires January 2002 [Page 16]
Internet Draft NORM Protocol July 2001
intermediate objects still in repair transmission. For example, an
object pending transmission/repair may for some reason may have
become obsolete. The receiver set learns from the NORM_CMD_SQUELCH
the set of data for which it is valid to request repair. In normal
conditions, it is expected the NORM_CMD_SQUELCH will be used infre-
quently, and is generally anticipated to provide a reference for
receivers who have fallen "out-of-sync" with the sender. The
NORM_CMD_SQUELCH contains the identity of the earliest transmission
point and includes a set of NormTransportIds which are valid. The
starting point of the included set begins at the greatest (latest)
of the sender's earliest transmission point or the lowest invalid
NormTransportId in the invalid NACK(s) which prompted the genera-
tion of the NORM_CMD_SQUELCH. The length of the list in the
NORM_CMD_SQUELCH is limited by the sender's NormSegmentSize. This
allows the receivers to learn the status of the sender's applicable
object repair window with minimal transmission of NORM_CMD_SQUELCH
commands. The format of the NORM_CMD_SQUELCH message (in addition
to the NORM message common header) is:
NORM_CMD(SQUELCH) Header
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| grtt | flavor = 2 | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| fec_block_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| object_transport_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| invalid_object_list ... |
In addition to the common NORM_CMD "grtt" and "flavor" fields, the
NORM_CMD(SQUELCH) message contains fields to identify the earliest
logical transmit position of the sender's current repair window and
a "repair window description" beginning with the index of the logi-
cally earliest invalid repair request from the offending NACK mes-
sage which initiated the SQUELCH response.
The "fec_block_id", and "object_transport_id" fields are concate-
nated to indicate the beginning of the sender's current repair win-
dow (i.e. the logically earliest point in its transmission history
for which the sender can provide repair). This serves as an adver-
tisement of a "synchronization point" for receivers to request
repair.
The "invalid_object_list" is a list of 32-bit object_transport_ids
which, although they are within the sender's current repair window,
Adamson, Borman, et al. Expires January 2002 [Page 17]
Internet Draft NORM Protocol July 2001
are no longer available for repair from the sender. The total size
of the "invalid_object_list" content is limited by the NormSegment-
Size of the sender. Thus, it is possible that in some cases a sin-
gle SQUELCH message may not be capable of completely listing the
entire set. In these cases, the sender should ensure that the list
begins with a "object_transport_id" (providing it is greater than
the "synchronization point" from a NACK message for which the
SQUELCH is being generated. This insures convergence of the
SQUELCH process, even if multiple invalid NACK/ SQUELCH response
iterations are required. This explicit description of invalid con-
tent within the sender's current window, allows the sender applica-
tion (most notably for discrete "object" based transport) to arbi-
trarily invalidate (i.e. dequeue) portions of enqueued content
(e.g. certain objects) for which it no longer wishes to provide
reliable transport.
(TBD) Provide example SQUELCH messages.
NORM_CMD_ACK_REQ
The NORM_CMD_ACK_REQ message is used by the sender to request
acknowledgement from a specified list of receivers. This message
serves in a lightweight positive acknowledgement mechanism which
can be optionally employed by the reliable multicast application to
deterministically determine that watermark points in the reliable
transmission have been achieved by specific receivers. er's appli-
cable object repair window with minimal transmission of
NORM_CMD_SQUELCH commands. The format of the NORM_CMD_ACK_REQ mes-
sage (in addition to the NORM message common header and the
NORM_CMD common header) is:
+-------------+---------------+----------------------------------+
| Field | Length (bits) | Purpose |
+-------------+---------------+----------------------------------+
| object_id | 32 | NormObjectTransportId of water- |
| | | mark NormObject for which the |
| | | sender supports acknowledgement. |
+-------------+---------------+----------------------------------+
| segment_id | (TBD) | Segment identifier of watermark |
| | | point within the identified |
| | | object. |
+-------------+---------------+----------------------------------+
| data | -- | List of NormNodeIds to which the |
| | | request applies. |
+-------------+---------------+----------------------------------+
Adamson, Borman, et al. Expires January 2002 [Page 18]
Internet Draft NORM Protocol July 2001
NORM_CMD(ACK_REQ) Header
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| grtt | flavor = 1 | fec_symbol_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| fec_block_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| object_transport_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| acking_node_list ... |
The "fec_symbol_id", "fec_block_id", and "object_transport_id" are
used to identify the watermark point for which the positive
acknowledgement request applies. This watermark point is similar
to that used in MDP_CMD(FLUSH) message. It should be noted that
all receivers are expected to treat the ACK_REQ command equiva-
lently to a FLUSH command and appropriately initiate NACK repair
cycles in response to any detected missing data up to the watermark
point.
The "acking_node_list" field contains the current list of receiver
NormNodeIds which should reply with postive acknowledgement to this
request. The NormNodeIds are listed in network (Big Endian) order.
The indicated receivers SHALL send a NORM_ACK message in response
to this request IF they have no outstanding repair needs up to and
including the watermark point. Note this does _not_ necessarily
mean the receivers actually received all of the data, but simply
that, for whatever reason (including the fact they may have already
received the data or if the receiving application simply chose
_not_ to receive the indicated data), they have no outstanding
repair needs prior to the watermark point. Verification of actual
received data content must be accomplished by another means outside
of this transport layer protocol. Receivers SHALL randomly spread
their response to this request using a uniform distribution over 1
GRTT of time. Note the size of the included list is limited to the
sender's NormSegmentSize setting. Thus, multiple NORM_CMD_ACK_REQ
cycles may be required to achieve responses from all receivers
specified. Also, the number of attempts to excite a response from
a given receive SHALL be limited to ROBUST_FACTOR. The
NORM_CMD_ACK_REQ is repeated at a rate of once per 2*GRTT. Note
that the content of the attached NormNodeId list will be dynami-
cally updated as this process progresses and ACKs are received from
the specified receiver set. The process SHALL terminate when all
desired receivers have responded or the maximum number of attempts
has been achieved. Note that repair requests can interrupt the
positive acknowledgement process and the positive acknowledgment
Adamson, Borman, et al. Expires January 2002 [Page 19]
Internet Draft NORM Protocol July 2001
process will resume only when there are no pending repair transmis-
sions up to the specified watermark point.
NORM_CMD_RTT_REQ
The NORM_CMD_RTT_REQ is periodically transmitted by the sender to
provide a reference point (a timestamp) so that receivers can cal-
culate appropriate response content in NORM_NACK and NORM_NACK mes-
sages from which the sender can monitor and estimate the current
GRTT. Currently, this reference is sent separately from other
sender message and not included in every message because of the
excessive overhead it may impose on data transmission. Generally,
the GRTT is not expected to be so dynamic as to require rapid
update. However, a technique is being investigated by the author
to provide a low overhead reference which could be attached to
every sender transmission and used for the receiver response gener-
ation [REF]. This command may also potentially be leveraged serve
as part of NORM congestion control to periodically provide updated
congestion control information and/or probing to the group. There
is expected to be sufficient content in this message that it merits
a separate message rather than be periodically included in the
overhead of other sender transmissions.
This command may also be extended to assume some responsibility in
initializing and updating a group size estimator used to appropri-
ately scale NACK suppression back-off timing, etc. For now, a min-
imal format is defined as a placeholder for this message. The for-
mat of the NORM_CMD_RTT_REQ message (in addition to the NORM mes-
sage common header and the NORM_CMD common header) is:
+----------+---------------+----------------------------------+
| Field | Length (bits) | Purpose |
+----------+---------------+----------------------------------+
| req_seq | 8 | NORM_CMD_RTT_REQ sequence number |
| | | T} send_time 64 T{ Timestamp |
| | | referenced to sender clock for |
| | | when the command was generated. |
+----------+---------------+----------------------------------+
The "req_seq" field is an 8-bit, monotonically increasing sequence
number which is incremented with each NORM_CMD_RTT_REQ command gen-
erated by the sender. Responses to the NORM_CMD_RTT_REQ embedded
in receiver NORM_NACK and NORM_ACK messages will identify the
sequence number of the NORM_CMD_RTT_REQ which they have most
recently received.
The "send_time" field is a precision timestamp indicating the time
Adamson, Borman, et al. Expires January 2002 [Page 20]
Internet Draft NORM Protocol July 2001
that the NORM_CMD_GRTT_REQ message was transmitted. This consists
of a 64-bit field containing 32-bits with the time in seconds and
32-bits with the time in microseconds since some reference time the
source maintains (usually 00:00:00, 1 January 1970). The ordering
of the fields in Big Endian network order.
Other candidate fields for this message include:
"flags" to mark different forms/purposes of the request. (e.g. a
WILDCARD flag to prompt an explicit response from the entire group)
"hold_time" field to provide a random back-off scaling factor when
an entire group response is expected.
Congestion control parameters such as "tx_rate", "rtt", "loss", etc
for assisting a congestion control mechanism appropiate for NORM.
Techniques are under investigation.
Receiver Messages:
NORM_NACK
The principal purpose of NORM_NACK messages will be for receivers
to request repair of content via negative acknowledgement upon
detection of incomplete data. NORM_NACKs will be transmitted
according to the rules of NACK generation and suppression of the
NORM NACK process. A goal for the content of these messages is to
use a format which can be potentially used by compatible intermedi-
ate systems [REF Generic Router Assist Building Block] to provide
assistance in promoting protocol scalability and efficiency when
available. NORM_NACK messages generated will also contain addi-
tional content to provide feedback to sender(s) for purposes of
round-trip timing collection, congestion control, etc.
NORM_NACK messages are transmitted by NORM receivers in response to
the detection of missing data in the sequence of transmissions
received from a particular source. The specific times and condi-
tions under which receivers will generate and transmit these
NORM_NACK messages are governed by the processes described in
detail later in this document. The payload of NORM_NACK messages
contains a list of "ObjectNACKs" for different objects and portions
of a those objects. In addition to the common message header the
NORM_NACK messages contain the following fields:
Adamson, Borman, et al. Expires January 2002 [Page 21]
Internet Draft NORM Protocol July 2001
NORM_NACK Header
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| server_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| grtt_response_msb |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| grtt_response_lsb |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| loss_estimate |grtt_req_sequence| reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data ... |
The "server_id" field identifies the source to which the NORM_NACK
message is destined. Other sources should ignore this message.
(Note that this another reason why multiple potential sources
within an NORM session MUST have unique NormNodeIds).
The "grtt_response" field contains a timestamp indicating the time
at which the NORM_NACK was transmitted. The format of this times-
tamp is the same as the "send_time" field of the NORM_CMD_GRTT_REQ.
However, note that the "grtt_response" timestamp is _relative_ to
the "send_time" the source provided with the corresponding
NORM_CMD_GRTT_REQ command. The receiver adjusts the source's
NORM_CMD_GRTT_REQ "send_time" timestamp by the time differential
from when the receiver received the NORM_CMD_GRTT_REQ to when the
NORM_NACK was transmitted to calculate the value in the
"grtt_response" field. The following formula applies:
"grtt_response" = request "send_time" + request_to_response_differential
If the "grtt_response" has ZERO value, that is an indication that
the receiver has not yet received a NORM_CMD_GRTT_REQ command from
the source and the source should ignore this portion of the
response.
The "loss_estimate" field is the receiver's current packet loss
fraction estimate for the indicated source. The loss fraction is a
value from 0.0 to 1.0 corresponding to a range of zero to 100 per-
cent packet loss. The 16-bit "loss_estimate" value is calculated by
the following formula:
"loss_estimate" = decimal_loss_fraction * 65535.0
The "grtt_req_sequence" field contains the sequence number identi-
fier of the received NORM_CMD_GRTT_REQ to which the response
Adamson, Borman, et al. Expires January 2002 [Page 22]
Internet Draft NORM Protocol July 2001
information in this NORM_NACK applies.
The "data" field of the NORM_NACK message specifies the repair
needs of this client pertaining to the indicated "server_id".
These repair needs are in the format described by the "General Pur-
pose NACK Content Encapsulation Format" in Section 3.2.3 of the
NORM Building Block specification (currently "draft-ietf-rmt-bb-
norm-02.txt". Note that the NACK content for multiple objects or
ranges of stream data may be present in one NORM_NACK message and
that each ObjectNACK consists of a hierarchical set of indicators
and bit masks depending upon what data the receiver has detected is
missing.
(TBD) Example NACK messages. (See NORM Building Block document for
now)
NORM_ACK
The basic operation of NORM transport will _not_ rely on the use
NORM_ACK (positive acknowledgement) messages. However, some appli-
cations may benefit from some limited form of positive acknowledge-
ment for certain functions. A simple, scalable positive acknowl-
edgement scheme is defined which can be leveraged by protocol
implementations when appropriate.
(TBD) Detailed description.
General Messages:
NORM_REPORT
This is an optional message generated by NORM participants. This
message may include periodic performance reports from receivers.
Additionally, this message type may be potentially used by applica-
tions to perform other session management functions such as period-
ically advertising the full identity of a participant or the gen-
eral context (more general than NORM_INFO messages which are asso-
ciated with specific data content objects) of the content being
transmitted to the group by a sender.
3.0 Detailed Protocol Operation
(TBD) This section describes the detailed interactions of senders
and receivers participating in a NORM session. Candidate subsec-
tions:
3.1 Sender Initialization and Transmission
Adamson, Borman, et al. Expires January 2002 [Page 23]
Internet Draft NORM Protocol July 2001
(TBD) Describes how a sender becomes active within the group,
transmits data content and how it may potentially go inactive or
leave the group.
3.2 Receiver Initialization and Reception
(TBD) Describes how a receiver joins the group, begins receiving
data content and any requirements on dynamically leaving and poten-
tially rejoining the group.
3.3 Receiver NACK Process
(TBD) Describes receiver criteria by which/when it chooses to
transmit NACK-based repair requests and the content of the these
messages.
3.3.1 NACK initiation
3.3.2 NACK content
3.4 Sender NACK Processing and Repair Transmission
(TBD) Describes how the sender accumulates NACK repair requests and
transmits repair information in response to these requests.
3.5 Additional Protocol Mechanisms
(TBD) Describes any other protocol mechanisms running periperally
or embedded as part of other protocol messaging.
3.5.1 Round-trip time collection
3.5.2 Congestion control operation
3.5.3 Other
(e.g. optional scalable, positive acknowledgements, asymmet-
ric feedback, performance reporting, etc)
4.0 Security Considerations
(TBD)
5.0 Suggested Use
(TBD)
Adamson, Borman, et al. Expires January 2002 [Page 24]
Internet Draft NORM Protocol July 2001
6.0 References
(TBD)
7.0 Authors' Addresses
Brian Adamson
adamson@itd.nrl.navy.mil
Newlink Global Engineering Corporation
8580 Cinder Bed Road, Suite 1000
Newington, VA, USA, 22122
Carsten Bormann
cabo@tellique.de
Tellique Kommunikationstechnik GmbH
Gustav-Meyer-Allee 25 Geb ude 12
D-13355 Berlin, Germany
Mark Handley
mjh@aciri.org
1947 Center Street, Suite 600
Berkeley, CA 94704
Joe Macker
macker@itd.nrl.navy.mil
Naval Research Laboratory
Washington, DC, USA, 20375
Adamson, Borman, et al. Expires January 2002 [Page 25]
--============_-1216460390==_============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
--
Brian
__________________________________
Brian Adamson
<http://manimac.itd.nrl.navy.mil>
<mailto:adamson@itd.nrl.navy.mil>
--============_-1216460390==_============--
>From owner-rmt@listserv.lbl.gov Fri Jul 20 14:06:14 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f6KL64101812;
Fri, 20 Jul 2001 14:06:04 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f6KL63R01808
for <rmt@listserv.lbl.gov>; Fri, 20 Jul 2001 14:06:03 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f6KL62E26983
for <rmt@listserv.lbl.gov>; Fri, 20 Jul 2001 14:06:02 -0700 (PDT)
Received: from mx.webfountain.com (mx.digitalfountain.com [209.219.233.39])
by SpamWall.lbl.gov (8.11.2/8.11.2) with SMTP id f6KL61A26969
for <rmt@lbl.gov>; Fri, 20 Jul 2001 14:06:01 -0700 (PDT)
Received: (qmail 24637 invoked from network); 20 Jul 2001 21:05:56 -0000
Received: from mail.intranet (10.1.1.37)
by mx.digitalfountain.com with SMTP; 20 Jul 2001 21:05:56 -0000
Received: from leningrad (leningrad.intranet [10.1.3.72])
by mail.intranet (8.9.3/8.9.3) with SMTP id OAA03976;
Fri, 20 Jul 2001 14:05:30 -0700
X-Authentication-Warning: mail.intranet: Host leningrad.intranet [10.1.3.72] claimed to be leningrad
From: "Mike Luby" <luby@digitalfountain.com>
To: <internet-drafts@ietf.org>
Cc: "Jim Gemmell" <jgemmell@MICROSOFT.com>, "Luigi Rizzo" <luigi@iet.unipi.it>,
"Lorenzo Vicisano" <lorenzo@cisco.com>,
"Mark Handley" <mjh@icsi.berkeley.edu>,
"Jon Crowcroft" <J.Crowcroft@cs.ucl.ac.uk>,
"Roger Kermode" <Roger.Kermode@motorola.com>, <rmt@lbl.gov>,
"Mike Luby" <luby@digitalfountain.com>
Subject: RE:
Date: Fri, 20 Jul 2001 14:07:10 -0700
Message-ID: <NEBBIAPCNKEDCLPNFBNCIEPLCGAA.luby@digitalfountain.com>
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="----=_NextPart_000_000B_01C11125.44940CE0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <NEBBIAPCNKEDCLPNFBNCAEPLCGAA.luby@digitalfountain.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Sender: owner-rmt@lbl.gov
Precedence: bulk
This is a multi-part message in MIME format.
------=_NextPart_000_000B_01C11125.44940CE0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Please replace the previous draft I sent earlier with this draft on the IETF
Internet Drafts archive. (The only difference is that this one is formatted
better and a bit more readable.)
This is an update of an existing WG draft (RMT).
Michael Luby
Chief Technical Officer
Digital Fountain, Inc.
39141 Civic Center Drive
Suite 300
Fremont, CA 94538
www.digitalfountain.com
luby@digitalfountain.com
(510) 284-1420 (phone)
(510) 284-1499 (fax)
(510) 284-1400 (main)
-----Original Message-----
From: Mike Luby [mailto:luby@digitalfountain.com]
Sent: Friday, July 20, 2001 12:17 PM
To: internet-drafts@ietf.org
Cc: Michael Luby; Jim Gemmell; Luigi Rizzo; Lorenzo Vicisano; Mark
Handley; Jon Crowcroft; Roger Kermode; rmt@lbl.gov
Subject:
Please post this draft on the IETF Internet Drafts archive.
This is an update of an existing WG draft (RMT).
Michael Luby
Chief Technical Officer
Digital Fountain, Inc.
39141 Civic Center Drive
Suite 300
Fremont, CA 94538
www.digitalfountain.com
luby@digitalfountain.com
(510) 284-1420 (phone)
(510) 284-1499 (fax)
(510) 284-1400 (main)
------=_NextPart_000_000B_01C11125.44940CE0
Content-Type: text/plain;
name="draft-ietf-rmt-bb-alc-02.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
filename="draft-ietf-rmt-bb-alc-02.txt"
Internet Engineering Task Force RMT WG=0A=
INTERNET-DRAFT M.Luby/Digital Fountain=0A=
draft-ietf-rmt-pi-alc-02.txt J.Gemmell/Microsoft=0A=
L.Vicisano/Cisco=0A=
L.Rizzo/ACIRI and Univ. Pisa=0A=
J. Crowcroft/UCL=0A=
20 July 2001=0A=
Expires: January 2002=0A=
=0A=
=0A=
Asynchronous Layered Coding:=0A=
A massively scalable reliably content delivery protocol=0A=
=0A=
=0A=
=0A=
Status of this Document=0A=
=0A=
This document is an Internet-Draft and is in full conformance with all=0A=
provisions of Section 10 of RFC2026.=0A=
=0A=
Internet-Drafts are working documents of the Internet Engineering Task=0A=
Force (IETF), its areas, and its working groups. Note that other groups=0A=
may also distribute working documents as Internet-Drafts.=0A=
=0A=
Internet-Drafts are valid for a maximum of six months and MAY be=0A=
updated, replaced, or obsoleted by other documents at any time. It is=0A=
inappropriate to use Internet-Drafts as reference material or to cite=0A=
them other than as a "work in progress".=0A=
=0A=
The list of current Internet-Drafts can be accessed at=0A=
http://www.ietf.org/ietf/1id-abstracts.txt=0A=
=0A=
To view the list Internet-Draft Shadow Directories, see=0A=
http://www.ietf.org/shadow.html.=0A=
=0A=
This document is a product of the IETF RMT WG. Comments should be=0A=
addressed to the authors, or the WG's mailing list at rmt@lbl.gov.=0A=
=0A=
=0A=
Abstract=0A=
=0A=
=0A=
This document describes the Asynchronous Layered Coding=0A=
protocol, a massively scalable reliable content delivery=0A=
protocol, hereafter referred to as ALC. ALC can be used for=0A=
=0A=
=0A=
=0A=
Luby/Gemmell/Vicisano/Rizzo/Crowcroft [Page 1]=0A=
=0C=0A=
INTERNET-DRAFT Expires: January 2002 July 2001=0A=
=0A=
=0A=
multi-rate reliable delivery of content to large sets of=0A=
receivers. ALC uses the LCT transport described in [3]=0A=
augmented with a congestion control protocol that is compliant=0A=
with RFC2387 such as one of the layered congestion control=0A=
protocols described [4]. ALC achieves reliability based on FEC=0A=
codecs as generally described in [1], and in particular based=0A=
on the details provided in the FEC building block described in=0A=
[2].=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
Luby/Gemmell/Vicisano/Rizzo/Crowcroft [Page 2]=0A=
=0C=0A=
INTERNET-DRAFT Expires: January 2002 July 2001=0A=
=0A=
=0A=
Table of Contents=0A=
=0A=
=0A=
1. Introduction. . . . . . . . . . . . . . . . . . . . . . 4=0A=
1.1. Related Documents. . . . . . . . . . . . . . . . . . 5=0A=
1.2. Environmental Requirements and Considerations. . . . 5=0A=
2. General Architecture. . . . . . . . . . . . . . . . . . 6=0A=
2.1. Delivery service models. . . . . . . . . . . . . . . 6=0A=
2.2. Congestion Control . . . . . . . . . . . . . . . . . 7=0A=
3. Type of packets used by the ALC protocol. . . . . . . . 7=0A=
3.1. Packet format for the ALC protocol . . . . . . . . . 8=0A=
3.2. Packet header fields for the ALC protocol. . . . . . 8=0A=
4. Procedures. . . . . . . . . . . . . . . . . . . . . . . 9=0A=
4.1. Sender Operation . . . . . . . . . . . . . . . . . . 9=0A=
4.2. Receiver Operation . . . . . . . . . . . . . . . . . 10=0A=
5. Security Considerations . . . . . . . . . . . . . . . . 10=0A=
6. IANA Considerations . . . . . . . . . . . . . . . . . . 10=0A=
7. Intellectual Property Issues. . . . . . . . . . . . . . 10=0A=
8. Authors' Addresses. . . . . . . . . . . . . . . . . . . 11=0A=
9. Full Copyright Statement. . . . . . . . . . . . . . . . 13=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
Luby/Gemmell/Vicisano/Rizzo/Crowcroft [Page 3]=0A=
=0C=0A=
INTERNET-DRAFT Expires: January 2002 July 2001=0A=
=0A=
=0A=
1. Introduction=0A=
=0A=
This document describes a massively scalable reliable content delivery=0A=
protocol, Asynchronous Layered Coding (ALC), for multi-rate reliable=0A=
content delivery. ALC is a protocol instantiation as defined in=0A=
RFC3048. ALC uses the LCT transport [3]. Thus, like the LCT transport,=0A=
the ALC protocol is primarily designed to be used with the IP multicast=0A=
network service, but MAY also be used with other basic underlying=0A=
network or transport services such as unicast UDP. ALC uses FEC codes=0A=
to provide reliability as generally described in [1], i.e. all packets=0A=
in a session contain FEC coded information in formats that are compliant=0A=
with the FEC building block described in [2]. A crucial point is that=0A=
ALC strongly relies on FEC codecs in the sense that there is no request=0A=
for retransmission of individual packets from receivers that miss=0A=
packets in order to assure reliable reception of an object, and the=0A=
packets and their rate of transmission out of the sender can be=0A=
independent of the number and the individual reception experiences of=0A=
the receivers. In some delivery service models it is appropriate that=0A=
receivers send out of band messages to the sender to provide guaranteed=0A=
delivery of content. For example, in a push reliable delivery model=0A=
receivers may send messages to a sender to continue the session if=0A=
receivers have not yet received enough packets to recover the content or=0A=
to terminate the session when receivers have received enough packets to=0A=
recover the content. To be able to track usage of the system, receivers=0A=
may also send messages out of band to the sender that contain statistics=0A=
on their reception experience. ALC, however, does not require nor=0A=
specify such messages, with the aim of avoiding unnecessary limitation=0A=
to the scalability of the basic ALC protocol.=0A=
=0A=
The LCT transport provides support for congestion control, and the ALC=0A=
protocol uses this support. The congestion control protocol must=0A=
conform with RFC 2357. It is recommended that the congestion control=0A=
protocol used for ALC be a multi-rate protocol, as described in [4]. In=0A=
this case, a sender sends packets in the session to several LCT channels=0A=
at potentially different rates. Then, individual receivers can adjust=0A=
their reception rate within a session by adjusting which set of LCT=0A=
channels they are joined to at each point in time depending on the=0A=
available bandwidth between the receiver and the sender, but independent=0A=
of other receivers. A single rate congestion control protocol can also=0A=
be used, but this may limit the scalability of the session in terms of=0A=
the number of receivers that can concurrently participate.=0A=
=0A=
Receiver may join and leave a session asynchronously at their=0A=
discretion.=0A=
=0A=
An ALC packet thus consists of an LCT packet header, an FEC packet=0A=
header, optional by additional parameters and packet payload.=0A=
=0A=
=0A=
=0A=
=0A=
Luby/Gemmell/Vicisano/Rizzo/Crowcroft Section 1. [Page 4]=0A=
=0C=0A=
INTERNET-DRAFT Expires: January 2002 July 2001=0A=
=0A=
=0A=
ALC has the following properties when the LCT transport uses multicast=0A=
to deliver packets:=0A=
=0A=
=0A=
o To each receiver, it appears as if though there is a dedicated session=0A=
from the sender to the receiver, where the reception rate adjusts to=0A=
congestion along the path from sender to receiver.=0A=
=0A=
o To the sender, there is no difference in load or outgoing rate if one=0A=
receiver is joined to the session or a million (or any number of)=0A=
receivers are joined to the session, independent of when the receivers=0A=
join and leave.=0A=
=0A=
o On each link in the network, the packet traffic from the session and=0A=
its reaction to competing traffic is the same whether there is one=0A=
receiver or a million receivers beyond the link.=0A=
=0A=
Thus, ALC provides a massively scalable content delivery system that=0A=
is network friendly.=0A=
=0A=
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=0A=
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this=0A=
document are to be interpreted as described in RFC2119.=0A=
=0A=
=0A=
1.1. Related Documents=0A=
=0A=
The LCT transport that ALC MUST use is described in [3]. A more in-=0A=
depth description of the use of FEC codecs in reliable content delivery=0A=
protocols is given in [1]. All packets in a session MUST contain FEC=0A=
coded information in formats that are compliant with the FEC building=0A=
block described in [2]. Implementors of ALC MUST also implement a=0A=
congestion control protocol in accordance to RFC2357, where the=0A=
congestion control is over the entire session. Some possible schemes=0A=
are specified in [4]. Congestion control MUST be integrated into ALC=0A=
through the support provided in the LCT transport.=0A=
=0A=
It is RECOMMENDED that ALC implementors use some authentication scheme=0A=
to protect the protocol from attacks. An example of a possibly suitable=0A=
scheme is described in [5]. Authentication in ALC, if used, is to be=0A=
integrated through the support provided in the LCT transport.=0A=
=0A=
=0A=
1.2. Environmental Requirements and Considerations=0A=
=0A=
ALC is intended for congestion controlled, multi-rate delivery of=0A=
objects, i.e., reliable content delivery.=0A=
=0A=
=0A=
=0A=
=0A=
Luby/Gemmell/Vicisano/Rizzo/Crowcroft Section 1.2. [Page 5]=0A=
=0C=0A=
INTERNET-DRAFT Expires: January 2002 July 2001=0A=
=0A=
=0A=
All of the environmental requirements and considerations that apply to=0A=
the LCT transport and to the FEC building block also apply to ALC.=0A=
=0A=
=0A=
2. General Architecture=0A=
=0A=
ALC protocol consists basically of using FEC codecs in the form=0A=
described in [2] with the LCT transport as described in [3]. Thus, the=0A=
terminology used in the description of the LCT transport and the FEC=0A=
building block are inherited by the ALC protocol and this terminology is=0A=
used below. In particular, the definition of a session for the ALC=0A=
protocol is the same as it is for the LCT transport.=0A=
=0A=
Packets used within the ALC protocol are specialized versions of LCT=0A=
packets. In particular, a packet consists of an LCT packet header, an=0A=
FEC payload ID, optional additional parameters as appropriate, and the=0A=
packet payload. From the point of view of the LCT transport, the FEC=0A=
payload ID, the additional parameters if present, and the packet payload=0A=
are all part of the LCT packet payload.=0A=
=0A=
The out of band information used by the ALC protocol consists of the out=0A=
of band all information required for both the LCT transport and for the=0A=
FEC building block. The possible means for acquiring this out of band=0A=
information is the same as for the LCT transport and the FEC building=0A=
block, and in particular is outside the scope of the ALC protocol.=0A=
=0A=
Congestion control for the ALC protocol MUST conform to RFC 2387, and=0A=
MUST be provided through the mechanisms provided by the LCT transport.=0A=
Although it is not mandatory, ALC is most scalable when multi-rate=0A=
congestion control is used that does not require feedback from receivers=0A=
to the sender, and thus use of a mult-rate congestion control as=0A=
described in [4] is RECOMMENDED.=0A=
=0A=
=0A=
2.1. Delivery service models=0A=
=0A=
ALC can support several different delivery service models. Two examples=0A=
are briefly described here.=0A=
=0A=
=0A=
Push service model.=0A=
=0A=
One way a push service model can be used for reliable content delivery=0A=
is to deliver a series of objects. For example, a receiver could join=0A=
the session and dynamically adapt the number of LCT channels the=0A=
receiver is joined to until enough packets have been received to=0A=
reconstruct an object. After reconstructing the object the receiver may=0A=
stay in the session and wait for the transmission of the next object.=0A=
=0A=
=0A=
=0A=
Luby/Gemmell/Vicisano/Rizzo/Crowcroft Section 2.1. [Page 6]=0A=
=0C=0A=
INTERNET-DRAFT Expires: January 2002 July 2001=0A=
=0A=
=0A=
The push model is particularly attractive in satellite networks and=0A=
wireless networks. In these cases, a session may consist of one fixed=0A=
rate LCT channel.=0A=
=0A=
=0A=
On-demand content delivery model.=0A=
=0A=
For an on-demand content delivery service model, senders typically=0A=
transmit for some given time period selected to be long enough to allow=0A=
all the intended receivers to join the session and recover a single=0A=
object. For example a popular software update might be transmitted=0A=
using ALC for several days, even though a receiver may be able to=0A=
complete the download in one hour total of connection time, perhaps=0A=
spread over several intervals of time.=0A=
=0A=
In this case the receivers join the session at any point in time when it=0A=
is active and dynamically adapt the number of LCT channels they=0A=
subscribe to according to the available bandwidth using a multi-rate=0A=
congestion control protocol. Receivers leave the session when they have=0A=
received enough packets to recover the object.=0A=
=0A=
=0A=
Other service models.=0A=
=0A=
=0A=
There may be other delivery service models that can be supported by ALC.=0A=
The description of the potential applications, the appropriate delivery=0A=
service model, and the additional mechanisms to support such=0A=
functionalities when combined with ALC is beyond the scope of this=0A=
document.=0A=
=0A=
=0A=
2.2. Congestion Control=0A=
=0A=
The specific congestion control protocol to be used for ALC sessions=0A=
should be suitable for reliable content delivery. While the general=0A=
behavior of the congestion control protocol is to reduce the throughput=0A=
in presence of congestion and gradually increase it in the absence of=0A=
congestion, the actual dynamic behavior (e.g. response to single losses)=0A=
can vary.=0A=
=0A=
Some possible multi-rate congestion control protocols for reliable=0A=
content delivery using LCT are described in [4].=0A=
=0A=
3. Type of packets used by the ALC protocol=0A=
=0A=
The type of packet used by the ALC protocol is a specialized version of=0A=
an LCT packet. LCT packets are sent by senders to LCT channels.=0A=
=0A=
=0A=
=0A=
Luby/Gemmell/Vicisano/Rizzo/Crowcroft Section 3. [Page 7]=0A=
=0C=0A=
INTERNET-DRAFT Expires: January 2002 July 2001=0A=
=0A=
=0A=
Some instances of sessions MAY require the generation of feedback from=0A=
the receivers to the sender. However, the mechanism for doing this is=0A=
outside the scope of ALC.=0A=
=0A=
=0A=
3.1. Packet format for the ALC protocol=0A=
=0A=
The packet format used for ALC protocol is depicted in Figure 1.=0A=
=0A=
=0A=
0 1 2 3=0A=
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=0A=
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A=
| LCT packet header |=0A=
| |=0A=
+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=
=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=0A=
| FEC Payload ID |=0A=
| |=0A=
+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=
=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=0A=
| Additional parameters |=0A=
| (optional) |=0A=
+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=
=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=0A=
| Payload |=0A=
| |=0A=
| |=0A=
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A=
=0A=
=0A=
Figure 1 - Packet format for ALC protocol=0A=
=0A=
=0A=
3.2. Packet header fields for the ALC protocol=0A=
=0A=
The description of the fields and their functions within the LCT packet=0A=
header can be found in [3]. The information that needs to be=0A=
communicated out of band for the LCT transport and the possible=0A=
mechanisms for achieving this are described in [3].=0A=
=0A=
The description of the fields and their functions within the FEC payload=0A=
ID can be found in [2], with the exception that the FEC Encoding Flag=0A=
value, if applicable, MAY be communicated via the value of the Codepoint=0A=
field within LCT packet header. The information that needs to be=0A=
communicated out of band for the FEC codecs and the possible mechanisms=0A=
for achieving this are described in [2]. The mechanisms for=0A=
communicating the out of band information needed for the LCT transport,=0A=
including the mapping between the Codepoint field values in the LCT=0A=
packet header and the interpretations of the values, MAY be the same as=0A=
those used for communicating the out of band information needed for the=0A=
=0A=
=0A=
=0A=
Luby/Gemmell/Vicisano/Rizzo/Crowcroft Section 3.2. [Page 8]=0A=
=0C=0A=
INTERNET-DRAFT Expires: January 2002 July 2001=0A=
=0A=
=0A=
FEC building block, with the exception that portions of the information=0A=
needed for FEC building blocks may be communicated either through the=0A=
use of the Codepoint field in the LCT packet header, or through the=0A=
Additional Parameters fields that follow the FEC payload ID.=0A=
=0A=
The fields and formats of the optional Additional Parameters fields MUST=0A=
be communicated to the receivers out of band. The particular Additional=0A=
Parameters fields that may appear in packets MUST be communicated out of=0A=
band. The specification of which Additional Parameters fields that=0A=
appear in a packet MUST be communicated via the value of the Codepoint=0A=
field in the LCT packet header, and the mapping between Codepoint field=0A=
values and the Additional Parameters fields that appear in a packet MUST=0A=
be communicated out of band. It is RECOMMENDED that the format of any=0A=
Additonal Parameters fields adhere to the format of Header-Extension=0A=
Fields defined for the LCT transport in [3].=0A=
=0A=
4. Procedures=0A=
=0A=
=0A=
4.1. Sender Operation=0A=
=0A=
The sender operation when using the ALC protocol includes all the points=0A=
made about the sender operation when using the LCT transport as=0A=
described in [3], and the FEC building block as described in [2]. The=0A=
following description highlights some of the additional considerations=0A=
to be taken into account with respect to the ALC protocol.=0A=
=0A=
Before a session starts, a sender using the ALC protocol MUST make=0A=
available all applicable information regarding the session. This=0A=
information includes:=0A=
=0A=
o Any information needed by the LCT transport;=0A=
=0A=
o The congestion control protocol being used within the LCT transport;=0A=
=0A=
o The mapping between values of the Codepoint field in the LCT packet=0A=
header and interpretations of these values;=0A=
=0A=
o Any information needed for the FEC building block;=0A=
=0A=
o If used, the authentication scheme being used within the LCT=0A=
transport, and all relevant information which is necessary for=0A=
sender authentication purposes;=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
Luby/Gemmell/Vicisano/Rizzo/Crowcroft Section 4.1. [Page 9]=0A=
=0C=0A=
INTERNET-DRAFT Expires: January 2002 July 2001=0A=
=0A=
=0A=
4.2. Receiver Operation=0A=
=0A=
The receiver operation when using the ALC protocol includes all the=0A=
points made about the receiver operation that pertain to reliable=0A=
content delivery when using the LCT transport as described in [3], and=0A=
that pertain to using the FEC building block as described in [2]. The=0A=
following description highlights some of the additional considerations=0A=
to be taken into account with respect to the ALC protocol.=0A=
=0A=
When a receiver receives a packet, the receiver MUST process the LCT=0A=
packet header (excluding the Codepoint field) as described in [3]=0A=
before processing any other fields of the packet.=0A=
=0A=
=0A=
5. Security Considerations=0A=
=0A=
The same security consideration that apply to the LCT transport and to=0A=
the FEC building block also apply to the ALC protocol. In addition, any=0A=
security considerations that apply to the congestion control protocol=0A=
used by the ALC protocol within the LCT transport also apply.=0A=
=0A=
=0A=
6. IANA Considerations=0A=
=0A=
No information in this specification is directly subject to IANA=0A=
registration. However, building blocks components used by the ALC=0A=
protcol may introduce additional IANA considerations. In particular,=0A=
the FEC building block used by the ALC protocol does require IANA=0A=
registration of the FEC codecs used.=0A=
=0A=
=0A=
7. Intellectual Property Issues=0A=
=0A=
=0A=
No specific reliability protocol or congestion control protocol is=0A=
specified or referenced as mandatory in this document.=0A=
=0A=
ALC MAY be used with congestion control protocols and other protocols=0A=
which are proprietary, or have pending or granted patents.=0A=
=0A=
=0A=
=0A=
[1] Luby, M., Gemmell, Vicisano, L., J., Rizzo, L., Handley, M.,=0A=
Crowcroft, J., "The use of Forward Error Correction in Reliable=0A=
Multicast", Internet Draft draft-ietf-rmt-info-fec-00.txt, November=0A=
2000, a work in progress.=0A=
=0A=
[2] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., Handley, M.,=0A=
=0A=
=0A=
=0A=
Luby/Gemmell/Vicisano/Rizzo/Crowcroft Section 7. [Page 10]=0A=
=0C=0A=
INTERNET-DRAFT Expires: January 2002 July 2001=0A=
=0A=
=0A=
Crowcroft, J., "RMT BB Forward Error Correction Codes", Internet Draft=0A=
draft-ietf-rmt-bb-fec-03.txt, July 2001.=0A=
=0A=
[3] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., Handley, M.,=0A=
Crowcroft, J., "Layered Coding Transport: A massively scalable content=0A=
delivery transport", Internet Draft draft-ietf-rmt-bb-lct-01.txt, July=0A=
2001.=0A=
=0A=
[4] Luby, M., Vicisano, L., Haken, A., "RMT BB Layered congestion=0A=
control", draft-ietf-rmt-bb-lcc-00.txt, November 2000, a work in=0A=
progress.=0A=
=0A=
[5] Perrig, A., Canetti, R., Briscoe, B., Tygar, D., Song, D., "TESLA:=0A=
Multicast Source Authentication Transform", draft-irtf-smug-=0A=
tesla-00.txt, November, 2000, a work in progress.=0A=
=0A=
=0A=
=0A=
8. Authors' Addresses=0A=
=0A=
Michael Luby=0A=
luby@digitalfountain.com=0A=
Digital Fountain=0A=
39141 Civic Center Drive=0A=
Suite 300=0A=
Fremont, CA, USA, 94538=0A=
=0A=
Jim Gemmell=0A=
jgemmell@microsoft.com=0A=
Microsoft Research=0A=
301 Howard St., #830=0A=
San Francisco, CA, USA, 94105=0A=
=0A=
Lorenzo Vicisano=0A=
lorenzo@cisco.com=0A=
cisco Systems, Inc.=0A=
170 West Tasman Dr.,=0A=
San Jose, CA, USA, 95134=0A=
=0A=
Luigi Rizzo=0A=
luigi@iet.unipi.it=0A=
Dip. Ing. dell'Informazione,=0A=
Univ. di Pisa=0A=
via Diotisalvi 2, 56126 Pisa, Italy=0A=
=0A=
Jon Crowcroft=0A=
J.Crowcroft@cs.ucl.ac.uk=0A=
Department of Computer Science=0A=
=0A=
=0A=
=0A=
Luby/Gemmell/Vicisano/Rizzo/Crowcroft Section 8. [Page 11]=0A=
=0C=0A=
INTERNET-DRAFT Expires: January 2002 July 2001=0A=
=0A=
=0A=
University College London=0A=
Gower Street,=0A=
London WC1E 6BT, UK=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
Luby/Gemmell/Vicisano/Rizzo/Crowcroft Section 8. [Page 12]=0A=
=0C=0A=
INTERNET-DRAFT Expires: January 2002 July 2001=0A=
=0A=
=0A=
9. Full Copyright Statement=0A=
=0A=
Copyright (C) The Internet Society (2000). All Rights Reserved.=0A=
=0A=
This document and translations of it may be copied and furnished to=0A=
others, and derivative works that comment on or otherwise explain it or=0A=
assist in its implementation may be prepared, copied, published and=0A=
distributed, in whole or in part, without restriction of any kind,=0A=
provided that the above copyright notice and this paragraph are included=0A=
on all such copies and derivative works. However, this document itself=0A=
may not be modified in any way, such as by removing the copyright notice=0A=
or references to the Internet Society or other Internet organizations,=0A=
except as needed for the purpose of developing Internet standards in=0A=
which case the procedures for copyrights defined in the Internet=0A=
languages other than English.=0A=
=0A=
The limited permissions granted above are perpetual and will not be=0A=
revoked by the Internet Society or its successors or assigns.=0A=
=0A=
This document and the information contained herein is provided on an "AS=0A=
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK=0A=
FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT=0A=
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT=0A=
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR=0A=
FITNESS FOR A PARTICULAR PURPOSE."=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
Luby/Gemmell/Vicisano/Rizzo/Crowcroft Section 9. [Page 13]=0A=
=0C=0A=
INTERNET-DRAFT Expires: January 2002 July 2001=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
Luby/Gemmell/Vicisano/Rizzo/Crowcroft Section 9. [Page 14]=0A=
------=_NextPart_000_000B_01C11125.44940CE0--
>From owner-rmt@listserv.lbl.gov Sun Jul 22 03:02:03 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f6MA09829262;
Sun, 22 Jul 2001 03:00:10 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f6MA08R29258
for <rmt@listserv.lbl.gov>; Sun, 22 Jul 2001 03:00:08 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f6MA08S10373
for <rmt@listserv.lbl.gov>; Sun, 22 Jul 2001 03:00:08 -0700 (PDT)
Received: from mail.greatbasin.net (mail.greatbasin.net [207.228.35.39])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f6MA07A10368
for <rmt@lbl.gov>; Sun, 22 Jul 2001 03:00:07 -0700 (PDT)
Received: from rogue (sugarpinellc.com [216.82.147.171])
by mail.greatbasin.net (8.9.3-MySQL-0.2.3b/8.9.3) with SMTP id DAA13984
for <rmt@lbl.gov>; Sun, 22 Jul 2001 03:00:07 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
From: Sugarpine.Sierra.West@greatbasin.net, LLC <info@sugarpinellc.com>
To: rmt@lbl.gov
Subject: Press Release
Message-ID: <200172210791rmt@lbl.gov>
Date: Sun, 22 Jul 2001 02:59:51 -0600
Sender: owner-rmt@lbl.gov
Precedence: bulk
For Immediate Release
Incline Village, Nevada
Contact Corporate Communications
www.sugarpinellc.com
Sugarpine Sierra West, LLC is proud to announce 4 additional services, Sports Memorabilia, Hair Raisers, Financial Services and Worlds-Best-4 the worlds largest virtual shopping mall featuring over 2.2 million products! Save time! Save money! Make money!!!
These services and products are now available to everyone. To view these tremendous opportunities, please visit our website. Sports Memorabilia may be viewed simply by clicking on its front-page banner. Hair Raisers may be viewed by visiting our web site, www.sugarpinellc.com, and select our associates^Ò link. Our Financial Services is linked and bannered on our home page.
As you all may already know, Sugarpine Sierra West, LLC is at its heart an asset hosting company. Please don^Òt forget to look at our Asset Gallery to see some outstanding business and investment opportunities, as well as collectables and real estate.
Sugarpine Sierra West, LLC would like to extend its sincere thanks and appreciation to all!
Please visit us at our web site at: www.sugarpinellc.com.
Corporate Communications:
Sugarpine Sierra West, LLC
Mr. Charles J. Armstrong II or Ms. Denise Pavlo
Phone: 775-832-2552
E-Mail: info@sugarpinellc.com
To be removed from our e-mail list, reply to this e-mail with "REMOVE" in the subject line of your reply.
>From owner-rmt@listserv.lbl.gov Mon Jul 23 09:40:26 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f6NGUoE13202;
Mon, 23 Jul 2001 09:30:50 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f6NGUnR13198
for <rmt@listserv.lbl.gov>; Mon, 23 Jul 2001 09:30:49 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f6NGUmg02105
for <rmt@listserv.lbl.gov>; Mon, 23 Jul 2001 09:30:48 -0700 (PDT)
Received: from cs.utexas.edu (root@cs.utexas.edu [128.83.139.9])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f6NGUlA02092
for <rmt@lbl.gov>; Mon, 23 Jul 2001 09:30:47 -0700 (PDT)
Received: from toulon.cs.utexas.edu (zxc@toulon.cs.utexas.edu [128.83.120.39])
by cs.utexas.edu (8.11.2/8.11.2) with ESMTP id f6NGUkQ20073;
Mon, 23 Jul 2001 11:30:46 -0500 (CDT)
Received: (from zxc@localhost)
by toulon.cs.utexas.edu (8.11.2/8.11.2) id f6NGUjK00797;
Mon, 23 Jul 2001 11:30:45 -0500 (CDT)
Date: Mon, 23 Jul 2001 11:30:45 -0500 (CDT)
From: Xincheng Zhang <zxc@cs.utexas.edu>
To: <Sugarpine.Sierra.West@greatbasin.net>, LLC <info@sugarpinellc.com>
cc: <rmt@lbl.gov>
Subject: REMOVE
In-Reply-To: <200172210791rmt@lbl.gov>
Message-ID: <Pine.GSO.4.33.0107231130390.796-100000@toulon.cs.utexas.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=X-UNKNOWN
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by SpamWall.lbl.gov id f6NGUnR13199
Sender: owner-rmt@lbl.gov
Precedence: bulk
xincheng
On Sun, 22 Jul 2001 Sugarpine.Sierra.West@greatbasin.net wrote:
> For Immediate Release
> Incline Village, Nevada
> Contact Corporate Communications
> www.sugarpinellc.com
>
> Sugarpine Sierra West, LLC is proud to announce 4 additional services, Sports Memorabilia, Hair Raisers, Financial Services and Worlds-Best-4 the worlds largest virtual shopping mall featuring over 2.2 million products! Save time! Save money! Make money!!!
>
> These services and products are now available to everyone. To view these tremendous opportunities, please visit our website. Sports Memorabilia may be viewed simply by clicking on its front-page banner. Hair Raisers may be viewed by visiting our web site, www.sugarpinellc.com, and select our associates^Ò link. Our Financial Services is linked and bannered on our home page.
>
> As you all may already know, Sugarpine Sierra West, LLC is at its heart an asset hosting company. Please don^Òt forget to look at our Asset Gallery to see some outstanding business and investment opportunities, as well as collectables and real estate.
>
> Sugarpine Sierra West, LLC would like to extend its sincere thanks and appreciation to all!
>
> Please visit us at our web site at: www.sugarpinellc.com.
>
> Corporate Communications:
> Sugarpine Sierra West, LLC
> Mr. Charles J. Armstrong II or Ms. Denise Pavlo
> Phone: 775-832-2552
> E-Mail: info@sugarpinellc.com
>
> To be removed from our e-mail list, reply to this e-mail with "REMOVE" in the subject line of your reply.
>
>
>
>From owner-rmt@listserv.lbl.gov Tue Jul 24 03:35:16 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f6OAYSE17681;
Tue, 24 Jul 2001 03:34:28 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f6OAYRw17677
for <rmt@listserv.lbl.gov>; Tue, 24 Jul 2001 03:34:27 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f6OAYQc13841
for <rmt@listserv.lbl.gov>; Tue, 24 Jul 2001 03:34:26 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f6OAYPA13837
for <rmt@lbl.gov>; Tue, 24 Jul 2001 03:34:25 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06648;
Tue, 24 Jul 2001 06:33:26 -0400 (EDT)
Message-Id: <200107241033.GAA06648@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: rmt@lbl.gov
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-rmt-bb-lct-01.txt,.ps
Date: Tue, 24 Jul 2001 06:33:26 -0400
Sender: owner-rmt@lbl.gov
Precedence: bulk
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Reliable Multicast Transport Working Group of the IETF.
Title : Layered Coding Transport: A massively scalable content
delivery transport
Author(s) : L. Vicisano et al.
Filename : draft-ietf-rmt-bb-lct-01.txt,.ps
Pages : 27
Date : 23-Jul-01
This document describes Layered Coding Transport, a massively
scalable reliable content delivery and stream delivery
transport, hereafter referred to as LCT. LCT can be used for
multi-rate delivery to large sets of receivers. In LCT,
scalability and congestion control are supported through the
use of layered coding techniques. Coding techniques can be
combined with LCT to provide support for reliability.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rmt-bb-lct-01.txt
Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-rmt-bb-lct-01.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.
Send a message to:
mailserv@ietf.org.
In the body type:
"FILE /internet-drafts/draft-ietf-rmt-bb-lct-01.txt".
NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv@ietf.org"
Content-Type: text/plain
Content-ID: <20010723141119.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-rmt-bb-lct-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-rmt-bb-lct-01.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <20010723141119.I-D@ietf.org>
--OtherAccess--
--NextPart--
>From owner-rmt@listserv.lbl.gov Tue Jul 24 03:35:16 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f6OAYWV17687;
Tue, 24 Jul 2001 03:34:32 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f6OAYVw17683
for <rmt@listserv.lbl.gov>; Tue, 24 Jul 2001 03:34:31 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f6OAYUG13848
for <rmt@listserv.lbl.gov>; Tue, 24 Jul 2001 03:34:30 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f6OAYTA13845
for <rmt@lbl.gov>; Tue, 24 Jul 2001 03:34:29 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06660;
Tue, 24 Jul 2001 06:33:31 -0400 (EDT)
Message-Id: <200107241033.GAA06660@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: rmt@lbl.gov
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-rmt-bb-fec-03.txt,.ps
Date: Tue, 24 Jul 2001 06:33:30 -0400
Sender: owner-rmt@lbl.gov
Precedence: bulk
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Reliable Multicast Transport Working Group of the IETF.
Title : RMT BB Forward Error Correction Codes
Author(s) : L. Vicisano et al.
Filename : draft-ietf-rmt-bb-fec-03.txt,.ps
Pages : 11
Date : 23-Jul-01
This memo describes the abstract packet formats and IANA
registration procedures for use of Forward Error Correction
(FEC) codes within the context of reliable IP multicast
transport. This memo should be read in conjunction with and
uses the terminology of the companion memo [1], which
describes the use of Forward Error Correction (FEC) codes
within the context of reliable IP multicast transport and
provides an introduction to some commonly used FEC codes.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rmt-bb-fec-03.txt
Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-rmt-bb-fec-03.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.
Send a message to:
mailserv@ietf.org.
In the body type:
"FILE /internet-drafts/draft-ietf-rmt-bb-fec-03.txt".
NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv@ietf.org"
Content-Type: text/plain
Content-ID: <20010723141128.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-rmt-bb-fec-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-rmt-bb-fec-03.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <20010723141128.I-D@ietf.org>
--OtherAccess--
--NextPart--
>From owner-rmt@listserv.lbl.gov Tue Jul 24 03:35:19 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f6OAYNA17675;
Tue, 24 Jul 2001 03:34:23 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f6OAYMw17671
for <rmt@listserv.lbl.gov>; Tue, 24 Jul 2001 03:34:22 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f6OAYLG13833
for <rmt@listserv.lbl.gov>; Tue, 24 Jul 2001 03:34:21 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f6OAYKA13829
for <rmt@lbl.gov>; Tue, 24 Jul 2001 03:34:20 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06631;
Tue, 24 Jul 2001 06:33:21 -0400 (EDT)
Message-Id: <200107241033.GAA06631@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: rmt@lbl.gov
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-rmt-pi-alc-02.txt
Date: Tue, 24 Jul 2001 06:33:21 -0400
Sender: owner-rmt@lbl.gov
Precedence: bulk
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Reliable Multicast Transport Working Group of the IETF.
Title : Asynchronous Layered Coding A scalable reliable
multicast protocol
Author(s) : L. Vicisano et al.
Filename : draft-ietf-rmt-pi-alc-02.txt
Pages : 14
Date : 23-Jul-01
This document describes the Asynchronous Layered Coding
protocol, a massively scalable reliable content delivery
protocol, hereafter referred to as ALC.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rmt-pi-alc-02.txt
Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-rmt-pi-alc-02.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.
Send a message to:
mailserv@ietf.org.
In the body type:
"FILE /internet-drafts/draft-ietf-rmt-pi-alc-02.txt".
NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv@ietf.org"
Content-Type: text/plain
Content-ID: <20010723141110.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-rmt-pi-alc-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-rmt-pi-alc-02.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <20010723141110.I-D@ietf.org>
--OtherAccess--
--NextPart--
>From owner-rmt@listserv.lbl.gov Tue Jul 24 12:39:03 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f6OJc3G11527;
Tue, 24 Jul 2001 12:38:03 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f6OJc1w11523
for <rmt@listserv.lbl.gov>; Tue, 24 Jul 2001 12:38:01 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f6OJbuG15573
for <rmt@listserv.lbl.gov>; Tue, 24 Jul 2001 12:37:56 -0700 (PDT)
Received: from acm.cs.umn.edu (acm.cs.umn.edu [128.101.32.12])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f6OJbuA15570
for <rmt@lbl.gov>; Tue, 24 Jul 2001 12:37:56 -0700 (PDT)
Received: from sorry.cs.umn.edu (sorry.cs.umn.edu [128.101.32.10])
by acm.cs.umn.edu (8.11.3/8.11.3) with ESMTP id f6OJbok69365;
Tue, 24 Jul 2001 14:37:50 -0500 (CDT)
(envelope-from orasis@acm.cs.umn.edu)
Received: (from orasis@localhost)
by sorry.cs.umn.edu (8.11.2/8.11.0) id f6OJbnq10521;
Tue, 24 Jul 2001 14:37:49 -0500 (CDT)
(envelope-from orasis)
Date: Tue, 24 Jul 2001 14:37:49 -0500
From: Justin Chapweske <orasis@acm.cs.umn.edu>
To: rm@mash.berkeley.edu
Cc: rmt@lbl.gov, justin@opencola.com, swarmcast-devel@lists.sourceforge.net
Subject: Java FEC Library 1.0 Released
Message-ID: <20010724143749.K7774@sorry.cs.umn.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Sender: owner-rmt@lbl.gov
Precedence: bulk
The 1.0 (bourbon-12) release of the Swarmcast FEC Library is available at
http://www.sourceforge.net/projects/swarmcast/ This software is based on
Luigi Rizzo's wonderful C FEC library but has been significantly expanded
to include multi-threaded IO routines for encoding and decoding
files. Just as with Luigi's library, this is released under a BSD-style
license.
I would highly recommend that anyone implementing a reliable multicast
solution in Java look at these libraries. We have been actively
developing them for over a year and believe you will find them to be quite
useful.
The features for this release include:
o Very efficient multi-threaded FEC I/O routines for easily encoding and
decoding files.
o Pure Java, native linux, and native win32 implementations of the
Vandermonde FEC codes.
o Platform specific libraries are automatically detected and deployed and
pure java codes are used for fallback in case platform specific libraries
cannot be found.
o An FEC codec plugin interface.
o Cryptographic hashes can be used to verify the integrity of the file
being decoded. If a block is found to be corrupt then the software can
attempt to repair it.
Thanks Luigi for the C code, Lorenzo for the JNI beginnings, and Jim
Gemmel for his papers on FEC IO.
--
Justin Chapweske, Lead Swarmcast Developer, OpenCola Inc.
http://www.swarmcast.com/
>From owner-rmt@listserv.lbl.gov Wed Jul 25 03:42:13 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f6PAfNK07786;
Wed, 25 Jul 2001 03:41:23 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f6PAfLK07782
for <rmt@listserv.lbl.gov>; Wed, 25 Jul 2001 03:41:21 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f6PAfK013229
for <rmt@listserv.lbl.gov>; Wed, 25 Jul 2001 03:41:21 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f6PAfIS13222
for <rmt@lbl.gov>; Wed, 25 Jul 2001 03:41:19 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08324;
Wed, 25 Jul 2001 06:40:18 -0400 (EDT)
Message-Id: <200107251040.GAA08324@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: rmt@lbl.gov
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-rmt-gra-arch-02.txt
Date: Wed, 25 Jul 2001 06:40:18 -0400
Sender: owner-rmt@lbl.gov
Precedence: bulk
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Reliable Multicast Transport Working Group of the IETF.
Title : Generic Router Assist (GRA) Building Block
Motivation and Architecture
Author(s) : B. Cain, T. Speakman, D. Towsley
Filename : draft-ietf-rmt-gra-arch-02.txt
Pages : 24
Date : 24-Jul-01
Generic Router Assist (GRA) is a network-based service that enables
end-to-end multicast transport protocols to take advantage of infor-
mation distributed across the network elements in a given multicast
distribution tree. The service consists of a canonical set of simple
functions which network elements may apply to selected packets in the
transport session as they traverse the distribution tree. The choice
of function and the packet parameters to which it is applied can be
defined and customized for a given transport session in a highly con-
trolled fashion that still permits enough flexibility for GRA to be
used to address a wide range of multicast transport problems not
amenable to end-to-end solution. This document provides the motiva-
tion and an architecture for GRA.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rmt-gra-arch-02.txt
Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-rmt-gra-arch-02.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.
Send a message to:
mailserv@ietf.org.
In the body type:
"FILE /internet-drafts/draft-ietf-rmt-gra-arch-02.txt".
NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv@ietf.org"
Content-Type: text/plain
Content-ID: <20010724132800.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-rmt-gra-arch-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-rmt-gra-arch-02.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <20010724132800.I-D@ietf.org>
--OtherAccess--
--NextPart--
>From owner-rmt@listserv.lbl.gov Thu Jul 26 12:01:27 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f6QIxLZ01957;
Thu, 26 Jul 2001 11:59:21 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f6QIxKK01953
for <rmt@listserv.lbl.gov>; Thu, 26 Jul 2001 11:59:20 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f6QIxJ824222
for <rmt@listserv.lbl.gov>; Thu, 26 Jul 2001 11:59:19 -0700 (PDT)
Received: from cecom6.monmouth.army.mil (cecom6.monmouth.army.mil [134.80.0.9])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f6QIxIS24218
for <rmt@lbl.gov>; Thu, 26 Jul 2001 11:59:18 -0700 (PDT)
Received: from [134.80.0.139] (mailsw2.monmouth.army.mil [134.80.0.139])
by cecom6.monmouth.army.mil (8.9.3/8.9.3) with ESMTP id OAA11185
for <rmt@lbl.gov>; Thu, 26 Jul 2001 14:59:11 -0400 (EDT)
X-IMPORTANT-Address-Change: All doim6 addresses have changed to mail1. Example:
mailbox@doim6.monmouth.army.mil is now mailbox@mail1.monmouth.army.mil
Received: from swgm6.monmouth.army.mil (unverified) by
(Content Technologies SMTPRS 4.2.1) with ESMTP id <T54fc252e1f8650008b1d9@>;
Thu, 26 Jul 2001 14:59:07 -0400
Received: by SWGM6 with Internet Mail Service (5.5.2653.19)
id <3VADS1KW>; Thu, 26 Jul 2001 14:59:07 -0400
Message-ID: <DDFD9B60F648D411AD670000F80822EA01A2D5E5@mail7.monmouth.army.mil>
From: "Lovuola, James J CECOM RDEC CSC"
<James.Lovuola@mail1.MONMOUTH.ARMY.MIL>
To: "'macker@itd.nrl.navy.mil'" <macker@itd.nrl.navy.mil>,
"'rmt@lbl.gov'"
<rmt@lbl.gov>
Cc: "Langan, Russell J CECOM RDEC HQ"
<Russell.Langan@mail1.MONMOUTH.ARMY.MIL>
Subject: Use of the Multicast Disemmination Protocol (MDP) for Unicast
Date: Thu, 26 Jul 2001 14:59:06 -0400
X-Mailer: Internet Mail Service (5.5.2653.19)
Sender: owner-rmt@lbl.gov
Precedence: bulk
Joe: I'm currently supporting the Army Systems Engineering Office (ASEO) in
investigating which Multicast and Reliable Multicast protocols would be
suitable for inclusion into the Joint Technical Architecture-Army (JTA-A).
One of the candidates we are looking at is MDP which is being supported
within the Army by FBCB2 for use over Combat Net Radio (CNR) and other
networks within the lower and upper Tactical Internet (TI).
At the CNR Implementation WG held last week, the issue surfaced as to
whether Segmentation/Reassembly (a CNR WG developed Application Framing
Prptocol to support Unicast) should be mandated over UDP for all large
messages (those larger than the maximum segment size of 496 octets). At the
meeting, I pointed out that S/R was never designed to support multicast and
other protocols (e.g., MDP) are much more suited to provide a reliable
transport service for multcast applications. My question is; Is it possible
that MDP could also provide a reliable transport service for Unicast (e.g.,
be used by different applications for both Multicast and Unicast)? The
problem with using TCP is that it imposes to much overhead for use over CNR
networks. S/R can also be used for Unicast but is not an open standard and
has not gained wide acceptance even within the CNR community (i.e., is only
being supported by Fire Support and a handful of synchronous users). S/R is
also not well documented ands does not contain any guidance on use of
timers, etc. Also I know that there are real-time protocols such a RTP that
could be used to ensure sequencing of packets for Unicast but they don't
provide a reliable transport service.
For MDP to support Unicast, it appears that addressing would be an obvious
issues; Could MDP support for instance both Class D addresses as well as
Unicast addresses? Would all Unicast receivers have to be considered as a
separate groups? Again, it may be more than just addressing, as I would
guess that for Unicast you would want to shut off some of the mechanisms
such as NACK supression, NAK aggregation for sending repair information,
etc. Would this be easy to do or would it require a major SW modification
effort? Has MDP ever been tested for Unicast? Any insight you could give
me on this subject would be greatly appreciated.
Regards
Jim L
>From owner-rmt@listserv.lbl.gov Fri Jul 27 04:35:50 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f6RBPpM29727;
Fri, 27 Jul 2001 04:25:51 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f6RBPnK29723
for <rmt@listserv.lbl.gov>; Fri, 27 Jul 2001 04:25:49 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f6RBPnu21589
for <rmt@listserv.lbl.gov>; Fri, 27 Jul 2001 04:25:49 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f6RBPmS21584
for <rmt@lbl.gov>; Fri, 27 Jul 2001 04:25:48 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07795;
Fri, 27 Jul 2001 07:24:47 -0400 (EDT)
Message-Id: <200107271124.HAA07795@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: rmt@lbl.gov
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-rmt-pi-norm-02.txt
Date: Fri, 27 Jul 2001 07:24:47 -0400
Sender: owner-rmt@lbl.gov
Precedence: bulk
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Reliable Multicast Transport Working Group of the IETF.
Title : NACK-Oriented Reliable Multicast Protocol (NORM)
Author(s) : B. Adamson, C. Bormann, M. Handley, J. Macker
Filename : draft-ietf-rmt-pi-norm-02.txt
Pages : 25
Date : 26-Jul-01
This document describes the messages and procedures of the Nega-
tive-acknowledgement (NACK) oriented reliable multicast (NORM).
This revision of the document represents an initial outline of the
protocol description. The document requires refinement in a number
of areas to be considered complete. At this time, the document
describes the high level details of the reliable multicast bulk
transfer service model this protocol hopes to fulfill and the gen-
eral message types and mechanisms which will be used to accomplish
those goals.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rmt-pi-norm-02.txt
Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-rmt-pi-norm-02.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.
Send a message to:
mailserv@ietf.org.
In the body type:
"FILE /internet-drafts/draft-ietf-rmt-pi-norm-02.txt".
NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv@ietf.org"
Content-Type: text/plain
Content-ID: <20010726171135.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-rmt-pi-norm-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-rmt-pi-norm-02.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <20010726171135.I-D@ietf.org>
--OtherAccess--
--NextPart--
>From owner-rmt@listserv.lbl.gov Fri Jul 27 04:35:51 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f6RBNxv29721;
Fri, 27 Jul 2001 04:23:59 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f6RBNvK29717
for <rmt@listserv.lbl.gov>; Fri, 27 Jul 2001 04:23:57 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f6RBNvi21475
for <rmt@listserv.lbl.gov>; Fri, 27 Jul 2001 04:23:57 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f6RBNtS21472
for <rmt@lbl.gov>; Fri, 27 Jul 2001 04:23:56 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07713;
Fri, 27 Jul 2001 07:22:55 -0400 (EDT)
Message-Id: <200107271122.HAA07713@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: rmt@lbl.gov
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-rmt-norm-bb-02.txt
Date: Fri, 27 Jul 2001 07:22:55 -0400
Sender: owner-rmt@lbl.gov
Precedence: bulk
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Reliable Multicast Transport Working Group of the IETF.
Title : NACK-Oriented Reliable Multicast (NORM) Protocol
Building Blocks
Author(s) : B. Adamson, C. Bormann, M. Handley, J. Macker
Filename : draft-ietf-rmt-norm-bb-02.txt
Pages : 41
Date : 26-Jul-01
This memo describes issues related to the creation of negative-
acknowledgment (NACK) oriented reliable multicast (NORM) protocols.
The general goals and assumptions for NORM are defined. The tech-
nical challenges related to NACK-oriented (and in some cases gen-
eral) reliable multicast protocol design are identified. These
challenges are resolved into a set of applicable 'building blocks'
which are described in further detail. It is anticipated that
these building blocks (as they are further refined and defined in
future revisions of this document) will be useful in generating
different instantiations of reliable multicast protocols.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rmt-norm-bb-02.txt
Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-rmt-norm-bb-02.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.
Send a message to:
mailserv@ietf.org.
In the body type:
"FILE /internet-drafts/draft-ietf-rmt-norm-bb-02.txt".
NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv@ietf.org"
Content-Type: text/plain
Content-ID: <20010726171121.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-rmt-norm-bb-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-rmt-norm-bb-02.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <20010726171121.I-D@ietf.org>
--OtherAccess--
--NextPart--
>From owner-rmt@listserv.lbl.gov Fri Jul 27 15:13:28 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f6RMBJT22268;
Fri, 27 Jul 2001 15:11:19 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f6RMBIK22264
for <rmt@listserv.lbl.gov>; Fri, 27 Jul 2001 15:11:18 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f6RMBFj19808
for <rmt@listserv.lbl.gov>; Fri, 27 Jul 2001 15:11:16 -0700 (PDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f6RMBDS19766
for <rmt@lbl.gov>; Fri, 27 Jul 2001 15:11:13 -0700 (PDT)
Received: from lorenzo-u10.cisco.com (lorenzo-u10.cisco.com [128.107.162.143])
by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f6RMAUg10650;
Fri, 27 Jul 2001 15:10:30 -0700 (PDT)
Received: from localhost (lorenzo@localhost) by lorenzo-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id PAA05383; Fri, 27 Jul 2001 15:10:30 -0700 (PDT)
Message-Id: <200107272210.PAA05383@lorenzo-u10.cisco.com>
X-Authentication-Warning: lorenzo-u10.cisco.com: lorenzo owned process doing -bs
X-Mailer: exmh version 2.3.1 01/18/2001 with version: MH 6.8.4 #29[UCI]
To: rmt@lbl.gov
cc: roger.kermode@motorola.com, mankin@ISI.EDU, sob@harvard.edu
Subject: RMT meeting -- draft agenda
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 27 Jul 2001 15:10:30 -0700
From: Lorenzo Vicisano <lorenzo@cisco.com>
Sender: owner-rmt@lbl.gov
Precedence: bulk
This the list of items, in a random order, based on the requests
received so far. Please send us addition and modification requests.
You have time until Monday, when we are planning to submit this to
the IETF.
thank you,
the RMT chairs.
- updates on GRA work Tony Speakman 20 mins
- updates on LCT BB Mike Luby 10 mins
- updates on ALC PI Mike Luby 10 mins
- discussion on RCCP PI Mike Luby 15 mins
(a) Present draft outline
(b) Is this type of document within the scope of RMT?
(c) Feedback on the draft if it is.
- discussion on FEC BBs Mike Luby 15 mins
(a) Are we moving this towards experimental now instead of standards?
(b) What are the processes for getting approval, i.e., what experiements
- updates on FEC BB Lorenzo Vicisano 10 mins
(a) General updates
(b) Issue on "Object Length" packet field
- NORM BB and PI updates Brian Adamson 10 mins
- general purpose NACK format Brian Adamson 20 mins
>From owner-rmt@listserv.lbl.gov Mon Jul 30 03:15:56 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f6UADqE00941;
Mon, 30 Jul 2001 03:13:52 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f6UADoK00937
for <rmt@listserv.lbl.gov>; Mon, 30 Jul 2001 03:13:50 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f6UADlh05554
for <rmt@listserv.lbl.gov>; Mon, 30 Jul 2001 03:13:48 -0700 (PDT)
Received: from unicorn.saver.ne.jp ([61.115.196.10])
by SpamWall.lbl.gov (8.11.2/8.11.2) with SMTP id f6UADGn05230
for <rmt@lbl.gov>; Mon, 30 Jul 2001 03:13:17 -0700 (PDT)
Date: Mon, 30 Jul 2001 03:13:17 -0700 (PDT)
Message-Id: <200107301013.f6UADGn05230@SpamWall.lbl.gov>
Received: (qmail 15752 invoked from network); 30 Jul 2001 10:19:55 -0000
Received: from unknown (HELO mc3.law13.hotmail.com) (61.115.196.131)
by 61.115.196.132 with SMTP; 30 Jul 2001 10:19:55 -0000
Reply-To: <dfweq23@hotmail.com>
From: "gfyt563@hotmail.com" <gfyt563@hotmail.com>
To: "0411@yahoo.com" <0411@yahoo.com>
Subject: WE PAY CASH NOW!
Content-Type: text/plain; charset="us-ascii";format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-rmt@lbl.gov
Precedence: bulk
WE PAY CASH, NOW!
We will pay you a lump sum of cash for Eight years of your Military and Government pensions, or your VA diusability.
We pay top dollar!
Go to: www.tfund2000.com and click on Military/Government pensions.
www.tfund2000.com
To be removed, please send a blank email with the word remove in the subject line.
>From owner-rmt@listserv.lbl.gov Mon Jul 30 12:44:47 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f6UJf1P15981;
Mon, 30 Jul 2001 12:41:01 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal2.lbl.gov (postal2.lbl.gov [131.243.248.26])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f6UJf0K15977
for <rmt@listserv.lbl.gov>; Mon, 30 Jul 2001 12:41:00 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal2.lbl.gov (8.11.2/8.11.2) with ESMTP id f6UJex703697
for <rmt@listserv.lbl.gov>; Mon, 30 Jul 2001 12:40:59 -0700 (PDT)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f6UHvsx23811
for <rmt@lbl.gov>; Mon, 30 Jul 2001 10:57:54 -0700 (PDT)
Received: from lorenzo-u10.cisco.com (lorenzo-u10.cisco.com [128.107.162.143])
by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f6UHvxY22661
for <rmt@lbl.gov>; Mon, 30 Jul 2001 10:58:00 -0700 (PDT)
Received: from localhost (lorenzo@localhost) by lorenzo-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id KAA17537 for <rmt@lbl.gov>; Mon, 30 Jul 2001 10:57:46 -0700 (PDT)
Message-Id: <200107301757.KAA17537@lorenzo-u10.cisco.com>
X-Authentication-Warning: lorenzo-u10.cisco.com: lorenzo owned process doing -bs
X-Mailer: exmh version 2.3.1 01/18/2001 with version: MH 6.8.4 #29[UCI]
To: rmt@lbl.gov
Subject: 51st IETF -- agenda update
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 30 Jul 2001 10:57:46 -0700
From: Lorenzo Vicisano <lorenzo@cisco.com>
Sender: owner-rmt@lbl.gov
Precedence: bulk
This is the new agenda. We'll be submitting this shortly, please
ask for changes now, if any.
thanks
the RMT chairs
- updates on GRA work Tony Speakman 20 mins
- LCT BB update Mike Luby 10 mins
- ALC PI update Mike Luby 10 mins
- discussion on RCCP PI Mike Luby 15 mins
(a) Present draft outline
(b) Is this type of document within the scope of RMT?
(c) Feedback on the draft if it is.
- discussion on CC BBs Mike Luby 15 mins
(a) Are we moving this towards experimental now instead of standards?
(b) What are the processes for getting approval, i.e., what experiements
- FEC BB update Lorenzo Vicisano 10 mins
(a) General updates
(b) Issue on "Object Length" packet field
- NORM BB and PI updates Brian Adamson 10 mins
- general purpose NACK format Brian Adamson 20 mins
- TRACK PI update Brian Whetten 10 mins
>From owner-rmt@listserv.lbl.gov Mon Jul 30 14:25:36 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f6ULNlE21793;
Mon, 30 Jul 2001 14:23:47 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f6ULNjK21789
for <rmt@listserv.lbl.gov>; Mon, 30 Jul 2001 14:23:45 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f6ULNid22179
for <rmt@listserv.lbl.gov>; Mon, 30 Jul 2001 14:23:44 -0700 (PDT)
Received: from mtiwmhc23.worldnet.att.net (mtiwmhc23.worldnet.att.net [204.127.131.48])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f6ULNf522153
for <rmt@lbl.gov>; Mon, 30 Jul 2001 14:23:41 -0700 (PDT)
Received: from reception ([12.80.24.110]) by mtiwmhc23.worldnet.att.net
(InterMail vM.4.01.03.16 201-229-121-116-20010115) with SMTP
id <20010730181736.CBE8490.mtiwmhc23.worldnet.att.net@reception>
for <rmt@lbl.gov>; Mon, 30 Jul 2001 18:17:36 +0000
From: "Richard Leathers"<leathersnb@worldnet.att.net>
To: rmt@lbl.gov
Subject: bills
date: Mon, 30 Jul 2001 11:16:33 -0500
MIME-Version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
Content-Type: multipart/mixed; boundary="----212C14E2_Outlook_Express_message_boundary"
Content-Disposition: Multipart message
Message-Id: <20010730181736.CBE8490.mtiwmhc23.worldnet.att.net@reception>
Sender: owner-rmt@lbl.gov
Precedence: bulk
------212C14E2_Outlook_Express_message_boundary
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
****************** Virus Warning Message (on the network)
Found virus TROJ_SIRCAM.A in file bills.doc.pif
The file e/iscan/virus/virTHBhLayrL is moved to the configured virus directory.
*********************************************************
------212C14E2_Outlook_Express_message_boundary
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: message text
Hi! How are you=3F
I send you this file in order to have your advice
See you later=2E Thanks
------212C14E2_Outlook_Express_message_boundary
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
****************** Virus Warning Message (on the network)
bills.doc.pif is removed from here because it contains a virus.
*********************************************************
------212C14E2_Outlook_Express_message_boundary
------212C14E2_Outlook_Express_message_boundary--
>From owner-rmt@listserv.lbl.gov Mon Jul 30 14:25:35 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f6ULNoR21799;
Mon, 30 Jul 2001 14:23:50 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f6ULNnK21795
for <rmt@listserv.lbl.gov>; Mon, 30 Jul 2001 14:23:49 -0700 (PDT)
Received: from localhost (root@localhost)
by postal1.lbl.gov (8.11.2/8.11.2) with SMTP id f6ULNm722228
for <rmt@listserv.lbl.gov>; Mon, 30 Jul 2001 14:23:48 -0700 (PDT)
Date: Mon, 30 Jul 2001 14:23:48 -0700 (PDT)
Message-Id: <200107302123.f6ULNm722228@postal1.lbl.gov>
From: VirusWall@lbl.gov
To: rmt@listserv.lbl.gov
Subject: Virus Alert
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-rmt@lbl.gov
Precedence: bulk
This is an automated message from the LBNL VirusWall.
The mail message you recently received from: leathersnb@worldnet.att.net
which included the file: bills.doc.pif
contained the virus: TROJ_SIRCAM.A.
PLEASE NOTE:
1. The virus has been REMOVED from the email message by the LBNL VirusWall
and will NOT INFECT your computer.
2. It is SAFE to read the message and open the attachment, though you should
always use caution when opening attachments from people you do not know.
3. You do not need to notify anyone that you received this message.
For more information take a look at our virus protection web page:
http://www.lbl.gov/ITSD/Security/resources/
If you have any questions, please contact the LBNL Help Desk
at http://www.lbl.gov/help/, or 510-486-4357.
Thanks,
The VirusWall
Lawrence Berkeley National Laboratory
>From owner-rmt@listserv.lbl.gov Tue Jul 31 13:29:00 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f6VKPVA29256;
Tue, 31 Jul 2001 13:25:31 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f6VKPTK29252
for <rmt@listserv.lbl.gov>; Tue, 31 Jul 2001 13:25:29 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f6VKPTT08048
for <rmt@listserv.lbl.gov>; Tue, 31 Jul 2001 13:25:29 -0700 (PDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f6VKPS508043
for <rmt@lbl.gov>; Tue, 31 Jul 2001 13:25:28 -0700 (PDT)
Received: from lorenzo-u10.cisco.com (lorenzo-u10.cisco.com [128.107.162.143])
by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f6VKPMg21809;
Tue, 31 Jul 2001 13:25:22 -0700 (PDT)
Received: from localhost (lorenzo@localhost) by lorenzo-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id NAA22223; Tue, 31 Jul 2001 13:25:22 -0700 (PDT)
Message-Id: <200107312025.NAA22223@lorenzo-u10.cisco.com>
X-Authentication-Warning: lorenzo-u10.cisco.com: lorenzo owned process doing -bs
X-Mailer: exmh version 2.3.1 01/18/2001 with version: MH 6.8.4 #29[UCI]
To: agenda@ietf.org
cc: rmt@lbl.gov
Subject: RMT agenda
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 31 Jul 2001 13:25:22 -0700
From: Lorenzo Vicisano <lorenzo@cisco.com>
Sender: owner-rmt@lbl.gov
Precedence: bulk
Please find attached the proposed agenda for
the two RMT meetings.
thank you,
the RMT chairs
- updates on GRA work Tony Speakman 20 mins
- LCT BB update Mike Luby 10 mins
- ALC PI update Mike Luby 10 mins
- discussion on RCCP PI Mike Luby 15 mins
(a) Present draft outline
(b) Is this type of document within the scope of RMT?
(c) Feedback on the draft if it is.
- discussion on CC BBs Mike Luby 15 mins
(a) Are we moving this towards experimental now instead of standards?
(b) What are the processes for getting approval, i.e., what experiements
- FEC BB update Lorenzo Vicisano 10 mins
(a) General updates
(b) Issue on "Object Length" packet field
- NORM BB and PI updates Brian Adamson 10 mins
- general purpose NACK format Brian Adamson 20 mins
- TRACK PI update Brian Whetten 10 mins
>From owner-rmt@listserv.lbl.gov Thu Aug 2 15:59:49 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f72Mvu826149;
Thu, 2 Aug 2001 15:57:56 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f72MvsK26145
for <rmt@listserv.lbl.gov>; Thu, 2 Aug 2001 15:57:54 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f72MvrG12879
for <rmt@listserv.lbl.gov>; Thu, 2 Aug 2001 15:57:53 -0700 (PDT)
Received: from ns2.webfountain.com (mx2.webfountain.com [216.136.183.167])
by SpamWall.lbl.gov (8.11.2/8.11.2) with SMTP id f72Mvq512866
for <rmt@lbl.gov>; Thu, 2 Aug 2001 15:57:52 -0700 (PDT)
Received: (qmail 7930 invoked from network); 2 Aug 2001 22:57:47 -0000
Received: from mail.intranet (10.1.1.37)
by ns2.webfountain.com with SMTP; 2 Aug 2001 22:57:47 -0000
Received: from leningrad (leningrad.intranet [10.1.3.72])
by mail.intranet (8.9.3/8.9.3) with SMTP id PAA12655;
Thu, 2 Aug 2001 15:57:47 -0700
X-Authentication-Warning: mail.intranet: Host leningrad.intranet [10.1.3.72] claimed to be leningrad
From: "Mike Luby" <luby@digitalfountain.com>
To: "Rmt@Lbl. Gov" <rmt@lbl.gov>
Cc: "Michael Luby" <luby@digitalfountain.com>,
"Lorenzo Vicisano" <lorenzo@cisco.com>, "Allison Mankin" <mankin@ISI.EDU>,
"Roger Kermode" <Roger.Kermode@motorola.com>
Subject:
Date: Thu, 2 Aug 2001 15:59:16 -0700
Message-ID: <NEBBIAPCNKEDCLPNFBNCCEBNCHAA.luby@digitalfountain.com>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Sender: owner-rmt@lbl.gov
Precedence: bulk
In the upcoming RMT working group meeting at the IETF there will be a
discussion about whether or not a session control protocol instantiation is:
(1) within the mandate of the RMT working group
(2) valuable assuming that the answer to (1) is "yes"
The following draft is a description of a possible session control protocol.
Note that this draft is not an official submission to the IETF, and its
content will not be reviewed at the IETF meeting. This draft is available
at:
http://www.digitalfountain.com/getDocument.htm/technology/library/draft-ietf
-rmt-mgl-pi-rccp-00-7-11-2001.txt
This document describes the Rich Content Control Protocol (RCCP), a session
control protocol for client initiated content delivery. The content in
question may be a file, a stream or some other form of content. The RCCP
protocol itself, however, is independent of the type of the content. RCCP
offers support for both multicast and unicast delivery.
Some of the key properties and goals of RCCP are:
(1) Initiation of the session including communication of the session
description to clients.
(2) Session monitoring to facilitate server side accounting.
(3) Session teardown, facilitating server side accounting and collection of
client statistics.
(4) Initiation and high level control of data packet reception.
(5) Prevention of some types of DoS attacks on servers.
(3) The ability to either directly or after configuration allow delivery of
content through firewalls.
This document is in a high state of flux, will be greatly modified in the
near future, and is not an official document within the IETF.
Michael Luby
Chief Technical Officer
Digital Fountain, Inc.
39141 Civic Center Drive
Suite 300
Fremont, CA 94538
www.digitalfountain.com
luby@digitalfountain.com
(510) 284-1420 (phone)
(510) 284-1499 (fax)
(510) 284-1400 (main)
>From owner-rmt@listserv.lbl.gov Thu Aug 2 16:02:13 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f72N2A428582;
Thu, 2 Aug 2001 16:02:10 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f72N28K28578
for <rmt@listserv.lbl.gov>; Thu, 2 Aug 2001 16:02:08 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f72N27Z14265
for <rmt@listserv.lbl.gov>; Thu, 2 Aug 2001 16:02:07 -0700 (PDT)
Received: from ns2.webfountain.com (mx2.webfountain.com [216.136.183.167])
by SpamWall.lbl.gov (8.11.2/8.11.2) with SMTP id f72N26514254
for <rmt@lbl.gov>; Thu, 2 Aug 2001 16:02:06 -0700 (PDT)
Received: (qmail 7947 invoked from network); 2 Aug 2001 23:02:01 -0000
Received: from mail.intranet (10.1.1.37)
by ns2.webfountain.com with SMTP; 2 Aug 2001 23:02:01 -0000
Received: from leningrad (leningrad.intranet [10.1.3.72])
by mail.intranet (8.9.3/8.9.3) with SMTP id QAA12934;
Thu, 2 Aug 2001 16:02:01 -0700
X-Authentication-Warning: mail.intranet: Host leningrad.intranet [10.1.3.72] claimed to be leningrad
From: "Mike Luby" <luby@digitalfountain.com>
To: "Rmt@Lbl. Gov" <rmt@lbl.gov>
Cc: "Michael Luby" <luby@digitalfountain.com>,
"Lorenzo Vicisano" <lorenzo@cisco.com>,
"Roger Kermode" <Roger.Kermode@motorola.com>
Subject: Session control protocol instantiation discussion within the IETF
Date: Thu, 2 Aug 2001 16:03:29 -0700
Message-ID: <NEBBIAPCNKEDCLPNFBNCGEBNCHAA.luby@digitalfountain.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_0000_01C11B6C.AC037450"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Sender: owner-rmt@lbl.gov
Precedence: bulk
This is a multi-part message in MIME format.
------=_NextPart_000_0000_01C11B6C.AC037450
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
(This is a resend of a recent message, but with a title and with the link
properly displayed (at least in some email programs)).
In the upcoming RMT working group meeting at the IETF there will be a
discussion about whether or not a session control protocol instantiation is:
(1) within the mandate of the RMT working group
(2) valuable assuming that the answer to (1) is "yes"
The following draft is a description of a possible session control protocol.
Note that this draft is not an official submission to the IETF, and its
content will not be reviewed at the IETF meeting. This draft is available
at:
http://www.digitalfountain.com/getDocument.htm/technology/library/draft-ietf
-rmt-mgl-pi-rccp-00-7-11-2001.txt
This document describes the Rich Content Control Protocol (RCCP), a session
control protocol for client initiated content delivery. The content in
question may be a file, a stream or some other form of content. The RCCP
protocol itself, however, is independent of the type of the content. RCCP
offers support for both multicast and unicast delivery.
Some of the key properties and goals of RCCP are:
(1) Initiation of the session including communication of the session
description to clients.
(2) Session monitoring to facilitate server side accounting.
(3) Session teardown, facilitating server side accounting and collection of
client statistics.
(4) Initiation and high level control of data packet reception.
(5) Prevention of some types of DoS attacks on servers.
(3) The ability to either directly or after configuration allow delivery of
content through firewalls.
This document is in a high state of flux, will be greatly modified in the
near future, and is not an official document within the IETF.
Michael Luby
Chief Technical Officer
Digital Fountain, Inc.
39141 Civic Center Drive
Suite 300
Fremont, CA 94538
www.digitalfountain.com
luby@digitalfountain.com
(510) 284-1420 (phone)
(510) 284-1499 (fax)
(510) 284-1400 (main)
------=_NextPart_000_0000_01C11B6C.AC037450
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE></TITLE>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2919.6307" name=3DGENERATOR></HEAD>
<BODY>
<P><FONT face=3DArial size=3D2>(This is a resend of a recent message, =
but with a=20
title and with the link properly displayed (at least in some email=20
programs)).</FONT></P>
<P><FONT size=3D2>In the upcoming RMT working group meeting at the IETF =
there will=20
be a<BR>discussion about whether or not a session control protocol =
instantiation=20
is:<BR><BR>(1) within the mandate of the RMT working group<BR><BR>(2) =
valuable=20
assuming that the answer to (1) is "yes"<BR><BR>The following draft is a =
description of a possible session control protocol.<BR>Note that this =
draft is=20
not an official submission to the IETF, and its<BR>content will not be =
reviewed=20
at the IETF meeting. This draft is available<BR>at:<BR><BR><A=20
href=3D"http://www.digitalfountain.com/getDocument.htm/technology/library=
/draft-ietf-rmt-mgl-pi-rccp-00-7-11-2001.txt"=20
target=3D_blank>http://www.digitalfountain.com/getDocument.htm/technology=
/library/draft-ietf-rmt-mgl-pi-rccp-00-7-11-2001.txt</A><BR><BR>This=20
document describes the Rich Content Control Protocol (RCCP), a=20
session<BR>control protocol for client initiated content =
delivery. =20
The content in<BR>question may be a file, a stream or some other form of =
content. The RCCP<BR>protocol itself, however, is =
independent of the=20
type of the content. RCCP<BR>offers support for both multicast and =
unicast delivery.<BR><BR>Some of the key properties and goals of =
RCCP=20
are:<BR><BR>(1) Initiation of the session including communication of the =
session<BR>description to clients.<BR>(2) Session monitoring to =
facilitate=20
server side accounting.<BR>(3) Session teardown, facilitating server =
side=20
accounting and collection of<BR>client statistics.<BR>(4) Initiation and =
high=20
level control of data packet reception.<BR>(5) Prevention of some types =
of DoS=20
attacks on servers.<BR>(3) The ability to either directly or after =
configuration=20
allow delivery of<BR>content through firewalls.<BR><BR>This document is =
in a=20
high state of flux, will be greatly modified in the<BR>near future, and =
is not=20
an official document within the IETF.<BR><BR>Michael Luby<BR>Chief =
Technical Officer<BR>Digital Fountain, Inc.<BR>39141 Civic Center =
Drive<BR>Suite=20
300<BR>Fremont, CA =20
94538<BR><BR><BR>www.digitalfountain.com<BR>luby@digitalfountain.com<BR>(=
510)=20
284-1420 (phone)<BR>(510) 284-1499 (fax)<BR>(510) 284-1400 (main)</FONT> =
</P></BODY></HTML>
------=_NextPart_000_0000_01C11B6C.AC037450--
>From owner-rmt@listserv.lbl.gov Thu Aug 2 18:16:13 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f731Fio03865;
Thu, 2 Aug 2001 18:15:44 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f731FhK03861
for <rmt@listserv.lbl.gov>; Thu, 2 Aug 2001 18:15:43 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f731Fhq18511
for <rmt@listserv.lbl.gov>; Thu, 2 Aug 2001 18:15:43 -0700 (PDT)
Received: from pec.etri.re.kr (pec.etri.re.kr [129.254.164.217])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f731FZ518487
for <rmt@lbl.gov>; Thu, 2 Aug 2001 18:15:36 -0700 (PDT)
Received: from escape (sjkoh3.etri.re.kr [129.254.164.124])
by pec.etri.re.kr (8.10.0/8.10.0) with SMTP id f7316NV16774;
Fri, 3 Aug 2001 10:06:24 +0900 (KST)
Message-ID: <001801c11bb9$14c10ba0$7ca4fe81@escape>
From: "Eunsook Kim" <eunsook@cs.sookmyung.ac.kr>
To: "Mike Luby" <luby@digitalfountain.com>, "Rmt@Lbl. Gov" <rmt@lbl.gov>
Cc: "Michael Luby" <luby@digitalfountain.com>,
"Lorenzo Vicisano" <lorenzo@cisco.com>,
"Roger Kermode" <Roger.Kermode@motorola.com>
References: <NEBBIAPCNKEDCLPNFBNCGEBNCHAA.luby@digitalfountain.com>
Subject: Re: Session control protocol instantiation discussion within the IETF
Date: Fri, 3 Aug 2001 10:09:55 +0900
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_0015_01C11C04.71C446A0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-rmt@lbl.gov
Precedence: bulk
This is a multi-part message in MIME format.
------=_NextPart_000_0015_01C11C04.71C446A0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: base64
SSBiZWxpZXZlIHN1Y2ggZGlzY3Vzc2lvbiBpcyB2ZXJ5IGNydWNpYWwgYW5kIHZhbHVhYmxlIGZv
ciB0aGUgZnVydGhlciBwcm9ncmVzcyBvZiBSTVQgV0cuDQoNCldlIG5vdGUgdGhhdCBpbiB0aGUg
cmVhbCBmaWVsZHMgaW5jbHVkaW5nIHRoZSBtdWx0aWNhc3QtYmFzZWQgY29udGVudHMgZGVsaXZl
cnkgYW5kIHRoZSByZWxhdGVkIG1hcmtldHMsDQp0aGVyZSBoYXMgYmVlbiBhIHVyZ2VudCBuZWVk
IGZyb20gc28gbWFueSBjb250ZW50cyBwcm92aWRlcnMgYW5kIENETiBzZXJ2aWNlIHByb3ZpZGVy
cw0KdG8gcHJvdmlkZSB0aGUgbXVsdGljYXN0IHNlc3Npb24gY29udHJvbCBvciBtYW5hZ2VtZW50
IA0KZm9yIHJlYWxpemluZyBwcm92aXNpb2luaW5nIG9mIG11bHRpY2FzdCBzZXJ2aWNlcy4NCg0K
SSB0aGluayB0aGlzIGlzc3VlIG11c3QgYmUgcHJvZ3Jlc3NpdmVseSBkaXNjdXNzZWQgaW4gdGhl
IFJNVCBXRywgYWxvbmcgd2l0aCBvcmlnaW5hbCBlcnJvci9jb25nZXN0aW9uIGNvbnRyb2xzLg0K
DQpJbiBhZGRpdGlvbiB0byBMdWJ5J3MgZHJhZnQsIGhlcmUgaXMgYW5vdGhlciBpbmZvcm1hdGl2
ZSBtYXRlcmlhbCBmb3IgdGhpcyBkaXNjdXNzaW9uOg0KaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRl
cm5ldC1kcmFmdHMvZHJhZnQta29oLXRzbS0wMC50eHQNCihzb21lIHBhcnRzIG9mIHRob3NlIGhh
dmUgYWxyZWFkeSBiZWVuIGRpc2N1c3NlZCBpbiB0aGUgbGFzdCBSTVQgbWVldGluZykNCg0KDQpC
ZXN0IFJlZ2FyZHMsDQoNCg0KDQpFdW5zb29rIEtpbQ0KDQpldW5haEBldHJpLnJlLmtyDQorODIt
Mi04NjAtNjEyNA0KUHJvdG9jb2wgRW5naW5lZXJpbmcgQ2VudGVyDQpFbGVjdHJvbmljcyBhbmQg
VGVsZWNvbW11bmljYXRpb25zIFJlc2VhcmNoIEluc3RpdHV0ZSAoRVRSSSkNCg0KDQogIC0tLS0t
IE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQogIEZyb206IE1pa2UgTHVieSANCiAgVG86IFJtdEBM
YmwuIEdvdiANCiAgQ2M6IE1pY2hhZWwgTHVieSA7IExvcmVuem8gVmljaXNhbm8gOyBSb2dlciBL
ZXJtb2RlIA0KICBTZW50OiBGcmlkYXksIEF1Z3VzdCAwMywgMjAwMSA4OjAzIEFNDQogIFN1Ympl
Y3Q6IFNlc3Npb24gY29udHJvbCBwcm90b2NvbCBpbnN0YW50aWF0aW9uIGRpc2N1c3Npb24gd2l0
aGluIHRoZSBJRVRGDQoNCg0KICAoVGhpcyBpcyBhIHJlc2VuZCBvZiBhIHJlY2VudCBtZXNzYWdl
LCBidXQgd2l0aCBhIHRpdGxlIGFuZCB3aXRoIHRoZSBsaW5rIHByb3Blcmx5IGRpc3BsYXllZCAo
YXQgbGVhc3QgaW4gc29tZSBlbWFpbCBwcm9ncmFtcykpLg0KDQogIEluIHRoZSB1cGNvbWluZyBS
TVQgd29ya2luZyBncm91cCBtZWV0aW5nIGF0IHRoZSBJRVRGIHRoZXJlIHdpbGwgYmUgYQ0KICBk
aXNjdXNzaW9uIGFib3V0IHdoZXRoZXIgb3Igbm90IGEgc2Vzc2lvbiBjb250cm9sIHByb3RvY29s
IGluc3RhbnRpYXRpb24gaXM6DQoNCiAgKDEpIHdpdGhpbiB0aGUgbWFuZGF0ZSBvZiB0aGUgUk1U
IHdvcmtpbmcgZ3JvdXANCg0KICAoMikgdmFsdWFibGUgYXNzdW1pbmcgdGhhdCB0aGUgYW5zd2Vy
IHRvICgxKSBpcyAieWVzIg0KDQogIFRoZSBmb2xsb3dpbmcgZHJhZnQgaXMgYSBkZXNjcmlwdGlv
biBvZiBhIHBvc3NpYmxlIHNlc3Npb24gY29udHJvbCBwcm90b2NvbC4NCiAgTm90ZSB0aGF0IHRo
aXMgZHJhZnQgaXMgbm90IGFuIG9mZmljaWFsIHN1Ym1pc3Npb24gdG8gdGhlIElFVEYsIGFuZCBp
dHMNCiAgY29udGVudCB3aWxsIG5vdCBiZSByZXZpZXdlZCBhdCB0aGUgSUVURiBtZWV0aW5nLiAg
VGhpcyBkcmFmdCBpcyBhdmFpbGFibGUNCiAgYXQ6DQoNCiAgaHR0cDovL3d3dy5kaWdpdGFsZm91
bnRhaW4uY29tL2dldERvY3VtZW50Lmh0bS90ZWNobm9sb2d5L2xpYnJhcnkvZHJhZnQtaWV0Zi1y
bXQtbWdsLXBpLXJjY3AtMDAtNy0xMS0yMDAxLnR4dA0KDQogIFRoaXMgZG9jdW1lbnQgZGVzY3Jp
YmVzIHRoZSBSaWNoIENvbnRlbnQgQ29udHJvbCBQcm90b2NvbCAoUkNDUCksIGEgc2Vzc2lvbg0K
ICBjb250cm9sIHByb3RvY29sIGZvciBjbGllbnQgaW5pdGlhdGVkICBjb250ZW50IGRlbGl2ZXJ5
LiAgVGhlIGNvbnRlbnQgaW4NCiAgcXVlc3Rpb24gbWF5IGJlIGEgZmlsZSwgYSBzdHJlYW0gb3Ig
c29tZSBvdGhlciBmb3JtIG9mIGNvbnRlbnQuICBUaGUgUkNDUA0KICBwcm90b2NvbCAgaXRzZWxm
LCBob3dldmVyLCBpcyBpbmRlcGVuZGVudCBvZiB0aGUgdHlwZSBvZiB0aGUgY29udGVudC4gIFJD
Q1ANCiAgb2ZmZXJzIHN1cHBvcnQgZm9yIGJvdGggbXVsdGljYXN0IGFuZCB1bmljYXN0ICBkZWxp
dmVyeS4NCg0KICBTb21lIG9mIHRoZSBrZXkgcHJvcGVydGllcyBhbmQgZ29hbHMgb2YgUkNDUCBh
cmU6DQoNCiAgKDEpIEluaXRpYXRpb24gb2YgdGhlIHNlc3Npb24gaW5jbHVkaW5nIGNvbW11bmlj
YXRpb24gb2YgdGhlIHNlc3Npb24NCiAgZGVzY3JpcHRpb24gdG8gY2xpZW50cy4NCiAgKDIpIFNl
c3Npb24gbW9uaXRvcmluZyB0byBmYWNpbGl0YXRlIHNlcnZlciBzaWRlIGFjY291bnRpbmcuDQog
ICgzKSBTZXNzaW9uIHRlYXJkb3duLCBmYWNpbGl0YXRpbmcgc2VydmVyIHNpZGUgYWNjb3VudGlu
ZyBhbmQgY29sbGVjdGlvbiBvZg0KICBjbGllbnQgc3RhdGlzdGljcy4NCiAgKDQpIEluaXRpYXRp
b24gYW5kIGhpZ2ggbGV2ZWwgY29udHJvbCBvZiBkYXRhIHBhY2tldCByZWNlcHRpb24uDQogICg1
KSBQcmV2ZW50aW9uIG9mIHNvbWUgdHlwZXMgb2YgRG9TIGF0dGFja3Mgb24gc2VydmVycy4NCiAg
KDMpIFRoZSBhYmlsaXR5IHRvIGVpdGhlciBkaXJlY3RseSBvciBhZnRlciBjb25maWd1cmF0aW9u
IGFsbG93IGRlbGl2ZXJ5IG9mDQogIGNvbnRlbnQgdGhyb3VnaCBmaXJld2FsbHMuDQoNCiAgVGhp
cyBkb2N1bWVudCBpcyBpbiBhIGhpZ2ggc3RhdGUgb2YgZmx1eCwgd2lsbCBiZSBncmVhdGx5IG1v
ZGlmaWVkIGluIHRoZQ0KICBuZWFyIGZ1dHVyZSwgYW5kIGlzIG5vdCBhbiBvZmZpY2lhbCAgZG9j
dW1lbnQgd2l0aGluIHRoZSBJRVRGLg0KDQogIE1pY2hhZWwgTHVieQ0KICBDaGllZiBUZWNobmlj
YWwgT2ZmaWNlcg0KICBEaWdpdGFsIEZvdW50YWluLCBJbmMuDQogIDM5MTQxIENpdmljIENlbnRl
ciBEcml2ZQ0KICBTdWl0ZSAzMDANCiAgRnJlbW9udCwgQ0EgIDk0NTM4DQoNCg0KICB3d3cuZGln
aXRhbGZvdW50YWluLmNvbQ0KICBsdWJ5QGRpZ2l0YWxmb3VudGFpbi5jb20NCiAgKDUxMCkgMjg0
LTE0MjAgKHBob25lKQ0KICAoNTEwKSAyODQtMTQ5OSAoZmF4KQ0KICAoNTEwKSAyODQtMTQwMCAo
bWFpbikgDQoNCg==
------=_NextPart_000_0015_01C11C04.71C446A0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: base64
PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv
L0VOIj4NCjxIVE1MPjxIRUFEPjxUSVRMRT48L1RJVExFPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250
ZW50LVR5cGUgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0KPE1FVEEg
Y29udGVudD0iTVNIVE1MIDUuNTAuNDYxNi4yMDAiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwv
U1RZTEU+DQo8L0hFQUQ+DQo8Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPjxGT05UIGZhY2U9
JiM0NDQwNDsmIzQ3NTQ4OyBzaXplPTI+DQo8RElWPjxGT05UIHNpemU9Mj5JIGJlbGlldmUmbmJz
cDtzdWNoIGRpc2N1c3Npb24gaXMgdmVyeSBjcnVjaWFsIGFuZCB2YWx1YWJsZSANCmZvciB0aGUg
ZnVydGhlciBwcm9ncmVzcyBvZiBSTVQgV0cuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXpl
PTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+V2Ugbm90ZSB0aGF0IGlu
IHRoZSByZWFsIGZpZWxkcyZuYnNwO2luY2x1ZGluZyZuYnNwO3RoZSANCm11bHRpY2FzdC1iYXNl
ZCBjb250ZW50cyBkZWxpdmVyeSBhbmQgdGhlIHJlbGF0ZWQgbWFya2V0cyw8L0ZPTlQ+PC9ESVY+
DQo8RElWPjxGT05UIHNpemU9Mj50aGVyZSBoYXMgYmVlbiZuYnNwO2EgdXJnZW50IG5lZWQgZnJv
bSBzbyBtYW55IGNvbnRlbnRzIA0KcHJvdmlkZXJzIGFuZCBDRE4gc2VydmljZSBwcm92aWRlcnM8
L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj50byBwcm92aWRlIHRoZSBtdWx0aWNhc3Qg
c2Vzc2k8L0ZPTlQ+PEZPTlQgc2l6ZT0yPm9uIGNvbnRyb2wgDQpvciBtYW5hZ2VtZW50IDwvRk9O
VD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPmZvciByZWFsaXppbmcmbmJzcDtwcm92aXNpb2lu
aW5nIG9mIG11bHRpY2FzdCANCnNlcnZpY2VzLjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6
ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPkkgdGhpbmsgdGhpcyBp
c3N1ZSBtdXN0IGJlIHByb2dyZXNzaXZlbHkgZGlzY3Vzc2VkIGluIHRoZSBSTVQgDQpXRywgYWxv
bmcgd2l0aCBvcmlnaW5hbCBlcnJvci9jb25nZXN0aW9uIGNvbnRyb2xzLjwvRk9OVD48L0RJVj4N
CjxESVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0y
PkluIGFkZGl0aW9uIHRvIEx1YnkncyZuYnNwO2RyYWZ0LCBoZXJlIGlzIGFub3RoZXIgaW5mb3Jt
YXRpdmUgDQptYXRlcmlhbCBmb3IgdGhpcyBkaXNjdXNzaW9uOjwvRk9OVD48L0RJVj4NCjxESVY+
PEZPTlQgc2l6ZT0yPjxBIA0KaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFm
dHMvZHJhZnQta29oLXRzbS0wMC50eHQiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJh
ZnRzL2RyYWZ0LWtvaC10c20tMDAudHh0PC9BPjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6
ZT0yPihzb21lIHBhcnRzIG9mIHRob3NlIGhhdmUgYWxyZWFkeSBiZWVuIGRpc2N1c3NlZCBpbiB0
aGUgbGFzdCANClJNVCBtZWV0aW5nKTwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjwv
Rk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5C
ZXN0IFJlZ2FyZHMsPC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+Jm5ic3A7
PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5FdW5zb29rIEtpbTwvRElWPg0KPERJVj4m
bmJzcDs8L0RJVj4NCjxESVY+PEEgaHJlZj0ibWFpbHRvOmV1bmFoQGV0cmkucmUua3IiPmV1bmFo
QGV0cmkucmUua3I8L0E+PC9ESVY+DQo8RElWPis4Mi0yLTg2MC02MTI0PC9ESVY+DQo8RElWPlBy
b3RvY29sIEVuZ2luZWVyaW5nIENlbnRlcjwvRElWPg0KPERJVj5FbGVjdHJvbmljcyBhbmQgVGVs
ZWNvbW11bmljYXRpb25zIFJlc2VhcmNoIEluc3RpdHV0ZSAoRVRSSSk8L0RJVj4NCjxESVY+Jm5i
c3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+PC9GT05UPjwv
RElWPg0KPEJMT0NLUVVPVEUgZGlyPWx0ciANCnN0eWxlPSJQQURESU5HLVJJR0hUOiAwcHg7IFBB
RERJTkctTEVGVDogNXB4OyBNQVJHSU4tTEVGVDogNXB4OyBCT1JERVItTEVGVDogIzAwMDAwMCAy
cHggc29saWQ7IE1BUkdJTi1SSUdIVDogMHB4Ij4NCiAgPERJViBzdHlsZT0iRk9OVDogMTBwdCAm
IzQ0NDA0OyYjNDc1NDg7Ij4tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIDwvRElWPg0KICA8
RElWIA0KICBzdHlsZT0iQkFDS0dST1VORDogI2U0ZTRlNDsgRk9OVDogMTBwdCAmIzQ0NDA0OyYj
NDc1NDg7OyBmb250LWNvbG9yOiBibGFjayI+PEI+RnJvbTo8L0I+IDxBIA0KICB0aXRsZT1sdWJ5
QGRpZ2l0YWxmb3VudGFpbi5jb20gaHJlZj0ibWFpbHRvOmx1YnlAZGlnaXRhbGZvdW50YWluLmNv
bSI+TWlrZSANCiAgTHVieTwvQT4gPC9ESVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDEwcHQgJiM0
NDQwNDsmIzQ3NTQ4OyI+PEI+VG86PC9CPiA8QSB0aXRsZT1ybXRAbGJsLmdvdiANCiAgaHJlZj0i
bWFpbHRvOlJtdEBMYmwuIEdvdiI+Um10QExibC4gR292PC9BPiA8L0RJVj4NCiAgPERJViBzdHls
ZT0iRk9OVDogMTBwdCAmIzQ0NDA0OyYjNDc1NDg7Ij48Qj5DYzo8L0I+IDxBIHRpdGxlPWx1YnlA
ZGlnaXRhbGZvdW50YWluLmNvbSANCiAgaHJlZj0ibWFpbHRvOmx1YnlAZGlnaXRhbGZvdW50YWlu
LmNvbSI+TWljaGFlbCBMdWJ5PC9BPiA7IDxBIA0KICB0aXRsZT1sb3JlbnpvQGNpc2NvLmNvbSBo
cmVmPSJtYWlsdG86bG9yZW56b0BjaXNjby5jb20iPkxvcmVuem8gVmljaXNhbm88L0E+IDsgDQog
IDxBIHRpdGxlPVJvZ2VyLktlcm1vZGVAbW90b3JvbGEuY29tIA0KICBocmVmPSJtYWlsdG86Um9n
ZXIuS2VybW9kZUBtb3Rvcm9sYS5jb20iPlJvZ2VyIEtlcm1vZGU8L0E+IDwvRElWPg0KICA8RElW
IHN0eWxlPSJGT05UOiAxMHB0ICYjNDQ0MDQ7JiM0NzU0ODsiPjxCPlNlbnQ6PC9CPiBGcmlkYXks
IEF1Z3VzdCAwMywgMjAwMSA4OjAzIEFNPC9ESVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDEwcHQg
JiM0NDQwNDsmIzQ3NTQ4OyI+PEI+U3ViamVjdDo8L0I+IFNlc3Npb24gY29udHJvbCBwcm90b2Nv
bCANCiAgaW5zdGFudGlhdGlvbiBkaXNjdXNzaW9uIHdpdGhpbiB0aGUgSUVURjwvRElWPg0KICA8
RElWPjxGT05UIGZhY2U9JiM0NDQwNDsmIzQ3NTQ4OyBzaXplPTI+PC9GT05UPjxCUj48L0RJVj4N
CiAgPFA+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+KFRoaXMgaXMgYSByZXNlbmQgb2YgYSByZWNl
bnQgbWVzc2FnZSwgYnV0IHdpdGggYSANCiAgdGl0bGUgYW5kIHdpdGggdGhlIGxpbmsgcHJvcGVy
bHkgZGlzcGxheWVkIChhdCBsZWFzdCBpbiBzb21lIGVtYWlsIA0KICBwcm9ncmFtcykpLjwvRk9O
VD48L1A+DQogIDxQPjxGT05UIHNpemU9Mj5JbiB0aGUgdXBjb21pbmcgUk1UIHdvcmtpbmcgZ3Jv
dXAgbWVldGluZyBhdCB0aGUgSUVURiB0aGVyZSANCiAgd2lsbCBiZSBhPEJSPmRpc2N1c3Npb24g
YWJvdXQgd2hldGhlciBvciBub3QgYSBzZXNzaW9uIGNvbnRyb2wgcHJvdG9jb2wgDQogIGluc3Rh
bnRpYXRpb24gaXM6PEJSPjxCUj4oMSkgd2l0aGluIHRoZSBtYW5kYXRlIG9mIHRoZSBSTVQgd29y
a2luZyANCiAgZ3JvdXA8QlI+PEJSPigyKSB2YWx1YWJsZSBhc3N1bWluZyB0aGF0IHRoZSBhbnN3
ZXIgdG8gKDEpIGlzICJ5ZXMiPEJSPjxCUj5UaGUgDQogIGZvbGxvd2luZyBkcmFmdCBpcyBhIGRl
c2NyaXB0aW9uIG9mIGEgcG9zc2libGUgc2Vzc2lvbiBjb250cm9sIA0KICBwcm90b2NvbC48QlI+
Tm90ZSB0aGF0IHRoaXMgZHJhZnQgaXMgbm90IGFuIG9mZmljaWFsIHN1Ym1pc3Npb24gdG8gdGhl
IElFVEYsIA0KICBhbmQgaXRzPEJSPmNvbnRlbnQgd2lsbCBub3QgYmUgcmV2aWV3ZWQgYXQgdGhl
IElFVEYgbWVldGluZy4mbmJzcDsgVGhpcyBkcmFmdCANCiAgaXMgYXZhaWxhYmxlPEJSPmF0OjxC
Uj48QlI+PEEgdGFyZ2V0PV9ibGFuayANCiAgaHJlZj0iaHR0cDovL3d3dy5kaWdpdGFsZm91bnRh
aW4uY29tL2dldERvY3VtZW50Lmh0bS90ZWNobm9sb2d5L2xpYnJhcnkvZHJhZnQtaWV0Zi1ybXQt
bWdsLXBpLXJjY3AtMDAtNy0xMS0yMDAxLnR4dCI+aHR0cDovL3d3dy5kaWdpdGFsZm91bnRhaW4u
Y29tL2dldERvY3VtZW50Lmh0bS90ZWNobm9sb2d5L2xpYnJhcnkvZHJhZnQtaWV0Zi1ybXQtbWds
LXBpLXJjY3AtMDAtNy0xMS0yMDAxLnR4dDwvQT48QlI+PEJSPlRoaXMgDQogIGRvY3VtZW50IGRl
c2NyaWJlcyB0aGUgUmljaCBDb250ZW50IENvbnRyb2wgUHJvdG9jb2wgKFJDQ1ApLCBhIA0KICBz
ZXNzaW9uPEJSPmNvbnRyb2wgcHJvdG9jb2wgZm9yIGNsaWVudCBpbml0aWF0ZWQmbmJzcDsgY29u
dGVudCBkZWxpdmVyeS4mbmJzcDsgDQogIFRoZSBjb250ZW50IGluPEJSPnF1ZXN0aW9uIG1heSBi
ZSBhIGZpbGUsIGEgc3RyZWFtIG9yIHNvbWUgb3RoZXIgZm9ybSBvZiANCiAgY29udGVudC4mbmJz
cDsgVGhlIFJDQ1A8QlI+cHJvdG9jb2wmbmJzcDsgaXRzZWxmLCBob3dldmVyLCBpcyBpbmRlcGVu
ZGVudCBvZiANCiAgdGhlIHR5cGUgb2YgdGhlIGNvbnRlbnQuJm5ic3A7IFJDQ1A8QlI+b2ZmZXJz
IHN1cHBvcnQgZm9yIGJvdGggbXVsdGljYXN0IGFuZCANCiAgdW5pY2FzdCZuYnNwOyBkZWxpdmVy
eS48QlI+PEJSPlNvbWUgb2YgdGhlIGtleSBwcm9wZXJ0aWVzIGFuZCBnb2FscyBvZiBSQ0NQIA0K
ICBhcmU6PEJSPjxCUj4oMSkgSW5pdGlhdGlvbiBvZiB0aGUgc2Vzc2lvbiBpbmNsdWRpbmcgY29t
bXVuaWNhdGlvbiBvZiB0aGUgDQogIHNlc3Npb248QlI+ZGVzY3JpcHRpb24gdG8gY2xpZW50cy48
QlI+KDIpIFNlc3Npb24gbW9uaXRvcmluZyB0byBmYWNpbGl0YXRlIA0KICBzZXJ2ZXIgc2lkZSBh
Y2NvdW50aW5nLjxCUj4oMykgU2Vzc2lvbiB0ZWFyZG93biwgZmFjaWxpdGF0aW5nIHNlcnZlciBz
aWRlIA0KICBhY2NvdW50aW5nIGFuZCBjb2xsZWN0aW9uIG9mPEJSPmNsaWVudCBzdGF0aXN0aWNz
LjxCUj4oNCkgSW5pdGlhdGlvbiBhbmQgaGlnaCANCiAgbGV2ZWwgY29udHJvbCBvZiBkYXRhIHBh
Y2tldCByZWNlcHRpb24uPEJSPig1KSBQcmV2ZW50aW9uIG9mIHNvbWUgdHlwZXMgb2YgRG9TIA0K
ICBhdHRhY2tzIG9uIHNlcnZlcnMuPEJSPigzKSBUaGUgYWJpbGl0eSB0byBlaXRoZXIgZGlyZWN0
bHkgb3IgYWZ0ZXIgDQogIGNvbmZpZ3VyYXRpb24gYWxsb3cgZGVsaXZlcnkgb2Y8QlI+Y29udGVu
dCB0aHJvdWdoIGZpcmV3YWxscy48QlI+PEJSPlRoaXMgDQogIGRvY3VtZW50IGlzIGluIGEgaGln
aCBzdGF0ZSBvZiBmbHV4LCB3aWxsIGJlIGdyZWF0bHkgbW9kaWZpZWQgaW4gdGhlPEJSPm5lYXIg
DQogIGZ1dHVyZSwgYW5kIGlzIG5vdCBhbiBvZmZpY2lhbCZuYnNwOyBkb2N1bWVudCB3aXRoaW4g
dGhlIElFVEYuPEJSPjxCUj5NaWNoYWVsIA0KICBMdWJ5PEJSPkNoaWVmIFRlY2huaWNhbCBPZmZp
Y2VyPEJSPkRpZ2l0YWwgRm91bnRhaW4sIEluYy48QlI+MzkxNDEgQ2l2aWMgDQogIENlbnRlciBE
cml2ZTxCUj5TdWl0ZSAzMDA8QlI+RnJlbW9udCwgQ0EmbmJzcDsgDQogIDk0NTM4PEJSPjxCUj48
QlI+d3d3LmRpZ2l0YWxmb3VudGFpbi5jb208QlI+bHVieUBkaWdpdGFsZm91bnRhaW4uY29tPEJS
Pig1MTApIA0KICAyODQtMTQyMCAocGhvbmUpPEJSPig1MTApIDI4NC0xNDk5IChmYXgpPEJSPig1
MTApIDI4NC0xNDAwIChtYWluKTwvRk9OVD4gDQo8L1A+PC9CTE9DS1FVT1RFPjwvQk9EWT48L0hU
TUw+DQo=
------=_NextPart_000_0015_01C11C04.71C446A0--
>From owner-rmt@listserv.lbl.gov Thu Aug 2 19:07:55 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f7327dZ06398;
Thu, 2 Aug 2001 19:07:39 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f7327YK06369
for <rmt@listserv.lbl.gov>; Thu, 2 Aug 2001 19:07:35 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f7327XI25870
for <rmt@listserv.lbl.gov>; Thu, 2 Aug 2001 19:07:33 -0700 (PDT)
Received: from postoffice.sarnoff.com (postoffice.sarnoff.com [130.33.10.147])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f7327X525865
for <rmt@lbl.gov>; Thu, 2 Aug 2001 19:07:33 -0700 (PDT)
Received: from postoffice.sarnoff.com ([127.0.0.1]) by
postoffice.sarnoff.com (Netscape Messaging Server 4.15) with
SMTP id GHGYEO00.KCJ for <rmt@lbl.gov>; Thu, 2 Aug 2001 21:49:36 -0400
Received: from nova.sarnoff.com ([130.33.8.27]) by
postoffice.sarnoff.com (Netscape Messaging Server 4.15) with
ESMTP id GH5C8000.A08; Fri, 27 Jul 2001 15:16:48 -0400
Received: from loki.ietf.org (loki.ietf.org [132.151.1.177])
by nova.sarnoff.com (8.9.2/8.9.2) with ESMTP id OAA10726;
Fri, 27 Jul 2001 14:29:51 -0400 (EDT)
Received: (from adm@localhost)
by loki.ietf.org (8.9.1b+Sun/8.9.1) id OAA19518
for ietf-123-outbound.05@ietf.org; Fri, 27 Jul 2001 14:15:01 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [10.27.2.28])
by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id HAA13161
for <all-ietf@loki.ietf.org>; Fri, 27 Jul 2001 07:24:51 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07795;
Fri, 27 Jul 2001 07:24:47 -0400 (EDT)
Message-Id: <200107271124.HAA07795@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: rmt@lbl.gov
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-rmt-pi-norm-02.txt
Date: Fri, 27 Jul 2001 07:24:47 -0400
Sender: owner-rmt@lbl.gov
Precedence: bulk
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Reliable Multicast Transport Working Group of the IETF.
Title : NACK-Oriented Reliable Multicast Protocol (NORM)
Author(s) : B. Adamson, C. Bormann, M. Handley, J. Macker
Filename : draft-ietf-rmt-pi-norm-02.txt
Pages : 25
Date : 26-Jul-01
This document describes the messages and procedures of the Nega-
tive-acknowledgement (NACK) oriented reliable multicast (NORM).
This revision of the document represents an initial outline of the
protocol description. The document requires refinement in a number
of areas to be considered complete. At this time, the document
describes the high level details of the reliable multicast bulk
transfer service model this protocol hopes to fulfill and the gen-
eral message types and mechanisms which will be used to accomplish
those goals.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rmt-pi-norm-02.txt
Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-rmt-pi-norm-02.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.
Send a message to:
mailserv@ietf.org.
In the body type:
"FILE /internet-drafts/draft-ietf-rmt-pi-norm-02.txt".
NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv@ietf.org"
Content-Type: text/plain
Content-ID: <20010726171135.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-rmt-pi-norm-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-rmt-pi-norm-02.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <20010726171135.I-D@ietf.org>
--OtherAccess--
--NextPart--
>From owner-rmt@listserv.lbl.gov Thu Aug 2 19:07:56 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f7327gQ06402;
Thu, 2 Aug 2001 19:07:42 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f7327bK06389
for <rmt@listserv.lbl.gov>; Thu, 2 Aug 2001 19:07:37 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f7327aW25897
for <rmt@listserv.lbl.gov>; Thu, 2 Aug 2001 19:07:36 -0700 (PDT)
Received: from postoffice.sarnoff.com (postoffice.sarnoff.com [130.33.10.147])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f7327Z525884
for <rmt@lbl.gov>; Thu, 2 Aug 2001 19:07:35 -0700 (PDT)
Received: from postoffice.sarnoff.com ([127.0.0.1]) by
postoffice.sarnoff.com (Netscape Messaging Server 4.15) with
SMTP id GHGZ3I00.CD5 for <rmt@lbl.gov>; Thu, 2 Aug 2001 22:04:30 -0400
Received: from nova.sarnoff.com ([130.33.8.27]) by
postoffice.sarnoff.com (Netscape Messaging Server 4.15) with
ESMTP id GH5SW400.PHN; Fri, 27 Jul 2001 21:16:52 -0400
Received: from loki.ietf.org (loki.ietf.org [132.151.1.177])
by nova.sarnoff.com (8.9.2/8.9.2) with ESMTP id PAA25124;
Tue, 24 Jul 2001 15:30:17 -0400 (EDT)
Received: (from adm@localhost)
by loki.ietf.org (8.9.1b+Sun/8.9.1) id PAA21111
for ietf-123-outbound.05@ietf.org; Tue, 24 Jul 2001 15:15:01 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [10.27.2.28])
by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA12949
for <all-ietf@loki.ietf.org>; Tue, 24 Jul 2001 06:33:28 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06648;
Tue, 24 Jul 2001 06:33:26 -0400 (EDT)
Message-Id: <200107241033.GAA06648@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: rmt@lbl.gov
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-rmt-bb-lct-01.txt,.ps
Date: Tue, 24 Jul 2001 06:33:26 -0400
Sender: owner-rmt@lbl.gov
Precedence: bulk
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Reliable Multicast Transport Working Group of the IETF.
Title : Layered Coding Transport: A massively scalable content
delivery transport
Author(s) : L. Vicisano et al.
Filename : draft-ietf-rmt-bb-lct-01.txt,.ps
Pages : 27
Date : 23-Jul-01
This document describes Layered Coding Transport, a massively
scalable reliable content delivery and stream delivery
transport, hereafter referred to as LCT. LCT can be used for
multi-rate delivery to large sets of receivers. In LCT,
scalability and congestion control are supported through the
use of layered coding techniques. Coding techniques can be
combined with LCT to provide support for reliability.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rmt-bb-lct-01.txt
Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-rmt-bb-lct-01.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.
Send a message to:
mailserv@ietf.org.
In the body type:
"FILE /internet-drafts/draft-ietf-rmt-bb-lct-01.txt".
NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv@ietf.org"
Content-Type: text/plain
Content-ID: <20010723141119.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-rmt-bb-lct-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-rmt-bb-lct-01.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <20010723141119.I-D@ietf.org>
--OtherAccess--
--NextPart--
>From owner-rmt@listserv.lbl.gov Thu Aug 2 19:07:56 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f7327ff06400;
Thu, 2 Aug 2001 19:07:41 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f7327ZK06372
for <rmt@listserv.lbl.gov>; Thu, 2 Aug 2001 19:07:35 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f7327YS25877
for <rmt@listserv.lbl.gov>; Thu, 2 Aug 2001 19:07:34 -0700 (PDT)
Received: from postoffice.sarnoff.com (postoffice.sarnoff.com [130.33.10.147])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f7327X525868
for <rmt@lbl.gov>; Thu, 2 Aug 2001 19:07:33 -0700 (PDT)
Received: from postoffice.sarnoff.com ([127.0.0.1]) by
postoffice.sarnoff.com (Netscape Messaging Server 4.15) with
SMTP id GHGYYR00.ODF for <rmt@lbl.gov>; Thu, 2 Aug 2001 22:01:39 -0400
Received: from nova.sarnoff.com ([130.33.8.27]) by
postoffice.sarnoff.com (Netscape Messaging Server 4.15) with
ESMTP id GH5PS400.DDI; Fri, 27 Jul 2001 20:09:40 -0400
Received: from loki.ietf.org (loki.ietf.org [132.151.1.177])
by nova.sarnoff.com (8.9.2/8.9.2) with ESMTP id PAA12374;
Wed, 25 Jul 2001 15:19:28 -0400 (EDT)
Received: (from adm@localhost)
by loki.ietf.org (8.9.1b+Sun/8.9.1) id OAA03283
for ietf-123-outbound.05@ietf.org; Wed, 25 Jul 2001 14:55:01 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [10.27.2.28])
by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA25758
for <all-ietf@loki.ietf.org>; Wed, 25 Jul 2001 06:40:22 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08324;
Wed, 25 Jul 2001 06:40:18 -0400 (EDT)
Message-Id: <200107251040.GAA08324@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: rmt@lbl.gov
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-rmt-gra-arch-02.txt
Date: Wed, 25 Jul 2001 06:40:18 -0400
Sender: owner-rmt@lbl.gov
Precedence: bulk
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Reliable Multicast Transport Working Group of the IETF.
Title : Generic Router Assist (GRA) Building Block
Motivation and Architecture
Author(s) : B. Cain, T. Speakman, D. Towsley
Filename : draft-ietf-rmt-gra-arch-02.txt
Pages : 24
Date : 24-Jul-01
Generic Router Assist (GRA) is a network-based service that enables
end-to-end multicast transport protocols to take advantage of infor-
mation distributed across the network elements in a given multicast
distribution tree. The service consists of a canonical set of simple
functions which network elements may apply to selected packets in the
transport session as they traverse the distribution tree. The choice
of function and the packet parameters to which it is applied can be
defined and customized for a given transport session in a highly con-
trolled fashion that still permits enough flexibility for GRA to be
used to address a wide range of multicast transport problems not
amenable to end-to-end solution. This document provides the motiva-
tion and an architecture for GRA.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rmt-gra-arch-02.txt
Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-rmt-gra-arch-02.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.
Send a message to:
mailserv@ietf.org.
In the body type:
"FILE /internet-drafts/draft-ietf-rmt-gra-arch-02.txt".
NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv@ietf.org"
Content-Type: text/plain
Content-ID: <20010724132800.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-rmt-gra-arch-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-rmt-gra-arch-02.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <20010724132800.I-D@ietf.org>
--OtherAccess--
--NextPart--
>From owner-rmt@listserv.lbl.gov Thu Aug 2 19:07:56 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f7327fo06401;
Thu, 2 Aug 2001 19:07:41 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f7327aK06380
for <rmt@listserv.lbl.gov>; Thu, 2 Aug 2001 19:07:36 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f7327Zo25891
for <rmt@listserv.lbl.gov>; Thu, 2 Aug 2001 19:07:36 -0700 (PDT)
Received: from postoffice.sarnoff.com (postoffice.sarnoff.com [130.33.10.147])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f7327Y525873
for <rmt@lbl.gov>; Thu, 2 Aug 2001 19:07:34 -0700 (PDT)
Received: from postoffice.sarnoff.com ([127.0.0.1]) by
postoffice.sarnoff.com (Netscape Messaging Server 4.15) with
SMTP id GHGZ2B00.EE3 for <rmt@lbl.gov>; Thu, 2 Aug 2001 22:03:47 -0400
Received: from nova.sarnoff.com ([130.33.8.27]) by
postoffice.sarnoff.com (Netscape Messaging Server 4.15) with
ESMTP id GH5SLG00.LGK; Fri, 27 Jul 2001 21:10:28 -0400
Received: from loki.ietf.org (loki.ietf.org [132.151.1.177])
by nova.sarnoff.com (8.9.2/8.9.2) with ESMTP id PAA25580;
Tue, 24 Jul 2001 15:42:48 -0400 (EDT)
Received: (from adm@localhost)
by loki.ietf.org (8.9.1b+Sun/8.9.1) id PAA21295
for ietf-123-outbound.05@ietf.org; Tue, 24 Jul 2001 15:25:01 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [10.27.2.28])
by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA12956
for <all-ietf@loki.ietf.org>; Tue, 24 Jul 2001 06:33:32 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06660;
Tue, 24 Jul 2001 06:33:31 -0400 (EDT)
Message-Id: <200107241033.GAA06660@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: rmt@lbl.gov
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-rmt-bb-fec-03.txt,.ps
Date: Tue, 24 Jul 2001 06:33:30 -0400
Sender: owner-rmt@lbl.gov
Precedence: bulk
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Reliable Multicast Transport Working Group of the IETF.
Title : RMT BB Forward Error Correction Codes
Author(s) : L. Vicisano et al.
Filename : draft-ietf-rmt-bb-fec-03.txt,.ps
Pages : 11
Date : 23-Jul-01
This memo describes the abstract packet formats and IANA
registration procedures for use of Forward Error Correction
(FEC) codes within the context of reliable IP multicast
transport. This memo should be read in conjunction with and
uses the terminology of the companion memo [1], which
describes the use of Forward Error Correction (FEC) codes
within the context of reliable IP multicast transport and
provides an introduction to some commonly used FEC codes.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rmt-bb-fec-03.txt
Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-rmt-bb-fec-03.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.
Send a message to:
mailserv@ietf.org.
In the body type:
"FILE /internet-drafts/draft-ietf-rmt-bb-fec-03.txt".
NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv@ietf.org"
Content-Type: text/plain
Content-ID: <20010723141128.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-rmt-bb-fec-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-rmt-bb-fec-03.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <20010723141128.I-D@ietf.org>
--OtherAccess--
--NextPart--
>From owner-rmt@listserv.lbl.gov Thu Aug 2 19:08:05 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f7327pm06403;
Thu, 2 Aug 2001 19:07:51 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f7327aK06382
for <rmt@listserv.lbl.gov>; Thu, 2 Aug 2001 19:07:36 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f7327a225894
for <rmt@listserv.lbl.gov>; Thu, 2 Aug 2001 19:07:36 -0700 (PDT)
Received: from postoffice.sarnoff.com (postoffice.sarnoff.com [130.33.10.147])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f7327Y525875
for <rmt@lbl.gov>; Thu, 2 Aug 2001 19:07:34 -0700 (PDT)
Received: from postoffice.sarnoff.com ([127.0.0.1]) by
postoffice.sarnoff.com (Netscape Messaging Server 4.15) with
SMTP id GHGZ3I00.5CQ for <rmt@lbl.gov>; Thu, 2 Aug 2001 22:04:30 -0400
Received: from nova.sarnoff.com ([130.33.8.27]) by
postoffice.sarnoff.com (Netscape Messaging Server 4.15) with
ESMTP id GH5SW400.EGI; Fri, 27 Jul 2001 21:16:52 -0400
Received: from loki.ietf.org (loki.ietf.org [132.151.1.177])
by nova.sarnoff.com (8.9.2/8.9.2) with ESMTP id PAA24869;
Tue, 24 Jul 2001 15:23:52 -0400 (EDT)
Received: (from adm@localhost)
by loki.ietf.org (8.9.1b+Sun/8.9.1) id PAA20968
for ietf-123-outbound.05@ietf.org; Tue, 24 Jul 2001 15:05:01 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [10.27.2.28])
by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA12941
for <all-ietf@loki.ietf.org>; Tue, 24 Jul 2001 06:33:23 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06631;
Tue, 24 Jul 2001 06:33:21 -0400 (EDT)
Message-Id: <200107241033.GAA06631@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: rmt@lbl.gov
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-rmt-pi-alc-02.txt
Date: Tue, 24 Jul 2001 06:33:21 -0400
Sender: owner-rmt@lbl.gov
Precedence: bulk
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Reliable Multicast Transport Working Group of the IETF.
Title : Asynchronous Layered Coding A scalable reliable
multicast protocol
Author(s) : L. Vicisano et al.
Filename : draft-ietf-rmt-pi-alc-02.txt
Pages : 14
Date : 23-Jul-01
This document describes the Asynchronous Layered Coding
protocol, a massively scalable reliable content delivery
protocol, hereafter referred to as ALC.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rmt-pi-alc-02.txt
Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-rmt-pi-alc-02.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.
Send a message to:
mailserv@ietf.org.
In the body type:
"FILE /internet-drafts/draft-ietf-rmt-pi-alc-02.txt".
NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv@ietf.org"
Content-Type: text/plain
Content-ID: <20010723141110.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-rmt-pi-alc-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-rmt-pi-alc-02.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <20010723141110.I-D@ietf.org>
--OtherAccess--
--NextPart--
>From owner-rmt@listserv.lbl.gov Thu Aug 2 19:07:55 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f7327ex06399;
Thu, 2 Aug 2001 19:07:40 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f7327ZK06376
for <rmt@listserv.lbl.gov>; Thu, 2 Aug 2001 19:07:35 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f7327YM25880
for <rmt@listserv.lbl.gov>; Thu, 2 Aug 2001 19:07:35 -0700 (PDT)
Received: from postoffice.sarnoff.com (postoffice.sarnoff.com [130.33.10.147])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f7327X525869
for <rmt@lbl.gov>; Thu, 2 Aug 2001 19:07:34 -0700 (PDT)
Received: from postoffice.sarnoff.com ([127.0.0.1]) by
postoffice.sarnoff.com (Netscape Messaging Server 4.15) with
SMTP id GHGYEP00.VCT for <rmt@lbl.gov>; Thu, 2 Aug 2001 21:49:37 -0400
Received: from nova.sarnoff.com ([130.33.8.27]) by
postoffice.sarnoff.com (Netscape Messaging Server 4.15) with
ESMTP id GH5C8100.V0H; Fri, 27 Jul 2001 15:16:49 -0400
Received: from loki.ietf.org (loki.ietf.org [132.151.1.177])
by nova.sarnoff.com (8.9.2/8.9.2) with ESMTP id OAA10507;
Fri, 27 Jul 2001 14:24:06 -0400 (EDT)
Received: (from adm@localhost)
by loki.ietf.org (8.9.1b+Sun/8.9.1) id OAA19296
for ietf-123-outbound.05@ietf.org; Fri, 27 Jul 2001 14:05:00 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [10.27.2.28])
by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id HAA13151
for <all-ietf@loki.ietf.org>; Fri, 27 Jul 2001 07:22:58 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07713;
Fri, 27 Jul 2001 07:22:55 -0400 (EDT)
Message-Id: <200107271122.HAA07713@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: rmt@lbl.gov
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-rmt-norm-bb-02.txt
Date: Fri, 27 Jul 2001 07:22:55 -0400
Sender: owner-rmt@lbl.gov
Precedence: bulk
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Reliable Multicast Transport Working Group of the IETF.
Title : NACK-Oriented Reliable Multicast (NORM) Protocol
Building Blocks
Author(s) : B. Adamson, C. Bormann, M. Handley, J. Macker
Filename : draft-ietf-rmt-norm-bb-02.txt
Pages : 41
Date : 26-Jul-01
This memo describes issues related to the creation of negative-
acknowledgment (NACK) oriented reliable multicast (NORM) protocols.
The general goals and assumptions for NORM are defined. The tech-
nical challenges related to NACK-oriented (and in some cases gen-
eral) reliable multicast protocol design are identified. These
challenges are resolved into a set of applicable 'building blocks'
which are described in further detail. It is anticipated that
these building blocks (as they are further refined and defined in
future revisions of this document) will be useful in generating
different instantiations of reliable multicast protocols.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rmt-norm-bb-02.txt
Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-rmt-norm-bb-02.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.
Send a message to:
mailserv@ietf.org.
In the body type:
"FILE /internet-drafts/draft-ietf-rmt-norm-bb-02.txt".
NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv@ietf.org"
Content-Type: text/plain
Content-ID: <20010726171121.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-rmt-norm-bb-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-rmt-norm-bb-02.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <20010726171121.I-D@ietf.org>
--OtherAccess--
--NextPart--
>From owner-rmt@listserv.lbl.gov Fri Aug 3 01:55:51 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f738tOR14159;
Fri, 3 Aug 2001 01:55:24 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f738tLK14145
for <rmt@listserv.lbl.gov>; Fri, 3 Aug 2001 01:55:21 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f738tKV12831
for <rmt@listserv.lbl.gov>; Fri, 3 Aug 2001 01:55:20 -0700 (PDT)
Received: from postoffice.sarnoff.com (postoffice.sarnoff.com [130.33.10.147])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f738tJ512823
for <rmt@lbl.gov>; Fri, 3 Aug 2001 01:55:19 -0700 (PDT)
Received: from postoffice.sarnoff.com ([127.0.0.1]) by
postoffice.sarnoff.com (Netscape Messaging Server 4.15) with
SMTP id GHHFDD00.SPI for <rmt@lbl.gov>; Fri, 3 Aug 2001 03:56:01 -0400
Received: from nova.sarnoff.com ([130.33.8.27]) by
postoffice.sarnoff.com (Netscape Messaging Server 4.15) with
ESMTP id GH5SLG00.LGK; Fri, 27 Jul 2001 21:10:28 -0400
Received: from loki.ietf.org (loki.ietf.org [132.151.1.177])
by nova.sarnoff.com (8.9.2/8.9.2) with ESMTP id PAA25580;
Tue, 24 Jul 2001 15:42:48 -0400 (EDT)
Received: (from adm@localhost)
by loki.ietf.org (8.9.1b+Sun/8.9.1) id PAA21295
for ietf-123-outbound.05@ietf.org; Tue, 24 Jul 2001 15:25:01 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [10.27.2.28])
by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA12956
for <all-ietf@loki.ietf.org>; Tue, 24 Jul 2001 06:33:32 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06660;
Tue, 24 Jul 2001 06:33:31 -0400 (EDT)
Message-Id: <200107241033.GAA06660@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: rmt@lbl.gov
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-rmt-bb-fec-03.txt,.ps
Date: Tue, 24 Jul 2001 06:33:30 -0400
Sender: owner-rmt@lbl.gov
Precedence: bulk
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Reliable Multicast Transport Working Group of the IETF.
Title : RMT BB Forward Error Correction Codes
Author(s) : L. Vicisano et al.
Filename : draft-ietf-rmt-bb-fec-03.txt,.ps
Pages : 11
Date : 23-Jul-01
This memo describes the abstract packet formats and IANA
registration procedures for use of Forward Error Correction
(FEC) codes within the context of reliable IP multicast
transport. This memo should be read in conjunction with and
uses the terminology of the companion memo [1], which
describes the use of Forward Error Correction (FEC) codes
within the context of reliable IP multicast transport and
provides an introduction to some commonly used FEC codes.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rmt-bb-fec-03.txt
Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-rmt-bb-fec-03.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.
Send a message to:
mailserv@ietf.org.
In the body type:
"FILE /internet-drafts/draft-ietf-rmt-bb-fec-03.txt".
NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv@ietf.org"
Content-Type: text/plain
Content-ID: <20010723141128.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-rmt-bb-fec-03.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-rmt-bb-fec-03.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <20010723141128.I-D@ietf.org>
--OtherAccess--
--NextPart--
>From owner-rmt@listserv.lbl.gov Fri Aug 3 01:55:51 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f738tVX14163;
Fri, 3 Aug 2001 01:55:31 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f738tMK14155
for <rmt@listserv.lbl.gov>; Fri, 3 Aug 2001 01:55:29 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f738tMI12842
for <rmt@listserv.lbl.gov>; Fri, 3 Aug 2001 01:55:22 -0700 (PDT)
Received: from postoffice.sarnoff.com (postoffice.sarnoff.com [130.33.10.147])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f738tK512833
for <rmt@lbl.gov>; Fri, 3 Aug 2001 01:55:21 -0700 (PDT)
Received: from postoffice.sarnoff.com ([127.0.0.1]) by
postoffice.sarnoff.com (Netscape Messaging Server 4.15) with
SMTP id GHHFDV00.BRW for <rmt@lbl.gov>; Fri, 3 Aug 2001 03:56:19 -0400
Received: from nova.sarnoff.com ([130.33.8.27]) by
postoffice.sarnoff.com (Netscape Messaging Server 4.15) with
ESMTP id GH5SW400.PHN; Fri, 27 Jul 2001 21:16:52 -0400
Received: from loki.ietf.org (loki.ietf.org [132.151.1.177])
by nova.sarnoff.com (8.9.2/8.9.2) with ESMTP id PAA25124;
Tue, 24 Jul 2001 15:30:17 -0400 (EDT)
Received: (from adm@localhost)
by loki.ietf.org (8.9.1b+Sun/8.9.1) id PAA21111
for ietf-123-outbound.05@ietf.org; Tue, 24 Jul 2001 15:15:01 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [10.27.2.28])
by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA12949
for <all-ietf@loki.ietf.org>; Tue, 24 Jul 2001 06:33:28 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06648;
Tue, 24 Jul 2001 06:33:26 -0400 (EDT)
Message-Id: <200107241033.GAA06648@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: rmt@lbl.gov
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-rmt-bb-lct-01.txt,.ps
Date: Tue, 24 Jul 2001 06:33:26 -0400
Sender: owner-rmt@lbl.gov
Precedence: bulk
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Reliable Multicast Transport Working Group of the IETF.
Title : Layered Coding Transport: A massively scalable content
delivery transport
Author(s) : L. Vicisano et al.
Filename : draft-ietf-rmt-bb-lct-01.txt,.ps
Pages : 27
Date : 23-Jul-01
This document describes Layered Coding Transport, a massively
scalable reliable content delivery and stream delivery
transport, hereafter referred to as LCT. LCT can be used for
multi-rate delivery to large sets of receivers. In LCT,
scalability and congestion control are supported through the
use of layered coding techniques. Coding techniques can be
combined with LCT to provide support for reliability.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rmt-bb-lct-01.txt
Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-rmt-bb-lct-01.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.
Send a message to:
mailserv@ietf.org.
In the body type:
"FILE /internet-drafts/draft-ietf-rmt-bb-lct-01.txt".
NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv@ietf.org"
Content-Type: text/plain
Content-ID: <20010723141119.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-rmt-bb-lct-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-rmt-bb-lct-01.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <20010723141119.I-D@ietf.org>
--OtherAccess--
--NextPart--
>From owner-rmt@listserv.lbl.gov Fri Aug 3 01:55:52 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f738tK314141;
Fri, 3 Aug 2001 01:55:21 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f738tIK14129
for <rmt@listserv.lbl.gov>; Fri, 3 Aug 2001 01:55:18 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f738tIs12813
for <rmt@listserv.lbl.gov>; Fri, 3 Aug 2001 01:55:18 -0700 (PDT)
Received: from postoffice.sarnoff.com (postoffice.sarnoff.com [130.33.10.147])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f738tG512809
for <rmt@lbl.gov>; Fri, 3 Aug 2001 01:55:17 -0700 (PDT)
Received: from postoffice.sarnoff.com ([127.0.0.1]) by
postoffice.sarnoff.com (Netscape Messaging Server 4.15) with
SMTP id GHHF5200.0QA for <rmt@lbl.gov>; Fri, 3 Aug 2001 03:51:02 -0400
Received: from nova.sarnoff.com ([130.33.8.27]) by
postoffice.sarnoff.com (Netscape Messaging Server 4.15) with
ESMTP id GH5C8000.A08; Fri, 27 Jul 2001 15:16:48 -0400
Received: from loki.ietf.org (loki.ietf.org [132.151.1.177])
by nova.sarnoff.com (8.9.2/8.9.2) with ESMTP id OAA10726;
Fri, 27 Jul 2001 14:29:51 -0400 (EDT)
Received: (from adm@localhost)
by loki.ietf.org (8.9.1b+Sun/8.9.1) id OAA19518
for ietf-123-outbound.05@ietf.org; Fri, 27 Jul 2001 14:15:01 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [10.27.2.28])
by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id HAA13161
for <all-ietf@loki.ietf.org>; Fri, 27 Jul 2001 07:24:51 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07795;
Fri, 27 Jul 2001 07:24:47 -0400 (EDT)
Message-Id: <200107271124.HAA07795@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: rmt@lbl.gov
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-rmt-pi-norm-02.txt
Date: Fri, 27 Jul 2001 07:24:47 -0400
Sender: owner-rmt@lbl.gov
Precedence: bulk
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Reliable Multicast Transport Working Group of the IETF.
Title : NACK-Oriented Reliable Multicast Protocol (NORM)
Author(s) : B. Adamson, C. Bormann, M. Handley, J. Macker
Filename : draft-ietf-rmt-pi-norm-02.txt
Pages : 25
Date : 26-Jul-01
This document describes the messages and procedures of the Nega-
tive-acknowledgement (NACK) oriented reliable multicast (NORM).
This revision of the document represents an initial outline of the
protocol description. The document requires refinement in a number
of areas to be considered complete. At this time, the document
describes the high level details of the reliable multicast bulk
transfer service model this protocol hopes to fulfill and the gen-
eral message types and mechanisms which will be used to accomplish
those goals.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rmt-pi-norm-02.txt
Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-rmt-pi-norm-02.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.
Send a message to:
mailserv@ietf.org.
In the body type:
"FILE /internet-drafts/draft-ietf-rmt-pi-norm-02.txt".
NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv@ietf.org"
Content-Type: text/plain
Content-ID: <20010726171135.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-rmt-pi-norm-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-rmt-pi-norm-02.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <20010726171135.I-D@ietf.org>
--OtherAccess--
--NextPart--
>From owner-rmt@listserv.lbl.gov Fri Aug 3 01:55:52 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f738tO814158;
Fri, 3 Aug 2001 01:55:24 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f738tLK14148
for <rmt@listserv.lbl.gov>; Fri, 3 Aug 2001 01:55:21 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f738tLb12837
for <rmt@listserv.lbl.gov>; Fri, 3 Aug 2001 01:55:21 -0700 (PDT)
Received: from postoffice.sarnoff.com (postoffice.sarnoff.com [130.33.10.147])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f738tK512827
for <rmt@lbl.gov>; Fri, 3 Aug 2001 01:55:20 -0700 (PDT)
Received: from postoffice.sarnoff.com ([127.0.0.1]) by
postoffice.sarnoff.com (Netscape Messaging Server 4.15) with
SMTP id GHHFDU00.0QF for <rmt@lbl.gov>; Fri, 3 Aug 2001 03:56:18 -0400
Received: from nova.sarnoff.com ([130.33.8.27]) by
postoffice.sarnoff.com (Netscape Messaging Server 4.15) with
ESMTP id GH5SW400.EGI; Fri, 27 Jul 2001 21:16:52 -0400
Received: from loki.ietf.org (loki.ietf.org [132.151.1.177])
by nova.sarnoff.com (8.9.2/8.9.2) with ESMTP id PAA24869;
Tue, 24 Jul 2001 15:23:52 -0400 (EDT)
Received: (from adm@localhost)
by loki.ietf.org (8.9.1b+Sun/8.9.1) id PAA20968
for ietf-123-outbound.05@ietf.org; Tue, 24 Jul 2001 15:05:01 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [10.27.2.28])
by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA12941
for <all-ietf@loki.ietf.org>; Tue, 24 Jul 2001 06:33:23 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06631;
Tue, 24 Jul 2001 06:33:21 -0400 (EDT)
Message-Id: <200107241033.GAA06631@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: rmt@lbl.gov
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-rmt-pi-alc-02.txt
Date: Tue, 24 Jul 2001 06:33:21 -0400
Sender: owner-rmt@lbl.gov
Precedence: bulk
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Reliable Multicast Transport Working Group of the IETF.
Title : Asynchronous Layered Coding A scalable reliable
multicast protocol
Author(s) : L. Vicisano et al.
Filename : draft-ietf-rmt-pi-alc-02.txt
Pages : 14
Date : 23-Jul-01
This document describes the Asynchronous Layered Coding
protocol, a massively scalable reliable content delivery
protocol, hereafter referred to as ALC.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rmt-pi-alc-02.txt
Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-rmt-pi-alc-02.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.
Send a message to:
mailserv@ietf.org.
In the body type:
"FILE /internet-drafts/draft-ietf-rmt-pi-alc-02.txt".
NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv@ietf.org"
Content-Type: text/plain
Content-ID: <20010723141110.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-rmt-pi-alc-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-rmt-pi-alc-02.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <20010723141110.I-D@ietf.org>
--OtherAccess--
--NextPart--
>From owner-rmt@listserv.lbl.gov Fri Aug 3 01:55:51 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f738tNQ14157;
Fri, 3 Aug 2001 01:55:23 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f738tKK14139
for <rmt@listserv.lbl.gov>; Fri, 3 Aug 2001 01:55:20 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f738tJq12825
for <rmt@listserv.lbl.gov>; Fri, 3 Aug 2001 01:55:19 -0700 (PDT)
Received: from postoffice.sarnoff.com (postoffice.sarnoff.com [130.33.10.147])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f738tI512816
for <rmt@lbl.gov>; Fri, 3 Aug 2001 01:55:18 -0700 (PDT)
Received: from postoffice.sarnoff.com ([127.0.0.1]) by
postoffice.sarnoff.com (Netscape Messaging Server 4.15) with
SMTP id GHHFCG00.PQL for <rmt@lbl.gov>; Fri, 3 Aug 2001 03:55:28 -0400
Received: from nova.sarnoff.com ([130.33.8.27]) by
postoffice.sarnoff.com (Netscape Messaging Server 4.15) with
ESMTP id GH5PS400.DDI; Fri, 27 Jul 2001 20:09:40 -0400
Received: from loki.ietf.org (loki.ietf.org [132.151.1.177])
by nova.sarnoff.com (8.9.2/8.9.2) with ESMTP id PAA12374;
Wed, 25 Jul 2001 15:19:28 -0400 (EDT)
Received: (from adm@localhost)
by loki.ietf.org (8.9.1b+Sun/8.9.1) id OAA03283
for ietf-123-outbound.05@ietf.org; Wed, 25 Jul 2001 14:55:01 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [10.27.2.28])
by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA25758
for <all-ietf@loki.ietf.org>; Wed, 25 Jul 2001 06:40:22 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08324;
Wed, 25 Jul 2001 06:40:18 -0400 (EDT)
Message-Id: <200107251040.GAA08324@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: rmt@lbl.gov
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-rmt-gra-arch-02.txt
Date: Wed, 25 Jul 2001 06:40:18 -0400
Sender: owner-rmt@lbl.gov
Precedence: bulk
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Reliable Multicast Transport Working Group of the IETF.
Title : Generic Router Assist (GRA) Building Block
Motivation and Architecture
Author(s) : B. Cain, T. Speakman, D. Towsley
Filename : draft-ietf-rmt-gra-arch-02.txt
Pages : 24
Date : 24-Jul-01
Generic Router Assist (GRA) is a network-based service that enables
end-to-end multicast transport protocols to take advantage of infor-
mation distributed across the network elements in a given multicast
distribution tree. The service consists of a canonical set of simple
functions which network elements may apply to selected packets in the
transport session as they traverse the distribution tree. The choice
of function and the packet parameters to which it is applied can be
defined and customized for a given transport session in a highly con-
trolled fashion that still permits enough flexibility for GRA to be
used to address a wide range of multicast transport problems not
amenable to end-to-end solution. This document provides the motiva-
tion and an architecture for GRA.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rmt-gra-arch-02.txt
Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-rmt-gra-arch-02.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.
Send a message to:
mailserv@ietf.org.
In the body type:
"FILE /internet-drafts/draft-ietf-rmt-gra-arch-02.txt".
NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv@ietf.org"
Content-Type: text/plain
Content-ID: <20010724132800.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-rmt-gra-arch-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-rmt-gra-arch-02.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <20010724132800.I-D@ietf.org>
--OtherAccess--
--NextPart--
>From owner-rmt@listserv.lbl.gov Fri Aug 3 01:55:52 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f738tNW14156;
Fri, 3 Aug 2001 01:55:23 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f738tJK14134
for <rmt@listserv.lbl.gov>; Fri, 3 Aug 2001 01:55:19 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f738tIW12819
for <rmt@listserv.lbl.gov>; Fri, 3 Aug 2001 01:55:18 -0700 (PDT)
Received: from postoffice.sarnoff.com (postoffice.sarnoff.com [130.33.10.147])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f738tH512812
for <rmt@lbl.gov>; Fri, 3 Aug 2001 01:55:17 -0700 (PDT)
Received: from postoffice.sarnoff.com ([127.0.0.1]) by
postoffice.sarnoff.com (Netscape Messaging Server 4.15) with
SMTP id GHHF5U00.AQL for <rmt@lbl.gov>; Fri, 3 Aug 2001 03:51:30 -0400
Received: from nova.sarnoff.com ([130.33.8.27]) by
postoffice.sarnoff.com (Netscape Messaging Server 4.15) with
ESMTP id GH5C8100.V0H; Fri, 27 Jul 2001 15:16:49 -0400
Received: from loki.ietf.org (loki.ietf.org [132.151.1.177])
by nova.sarnoff.com (8.9.2/8.9.2) with ESMTP id OAA10507;
Fri, 27 Jul 2001 14:24:06 -0400 (EDT)
Received: (from adm@localhost)
by loki.ietf.org (8.9.1b+Sun/8.9.1) id OAA19296
for ietf-123-outbound.05@ietf.org; Fri, 27 Jul 2001 14:05:00 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [10.27.2.28])
by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id HAA13151
for <all-ietf@loki.ietf.org>; Fri, 27 Jul 2001 07:22:58 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07713;
Fri, 27 Jul 2001 07:22:55 -0400 (EDT)
Message-Id: <200107271122.HAA07713@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: rmt@lbl.gov
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-rmt-norm-bb-02.txt
Date: Fri, 27 Jul 2001 07:22:55 -0400
Sender: owner-rmt@lbl.gov
Precedence: bulk
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Reliable Multicast Transport Working Group of the IETF.
Title : NACK-Oriented Reliable Multicast (NORM) Protocol
Building Blocks
Author(s) : B. Adamson, C. Bormann, M. Handley, J. Macker
Filename : draft-ietf-rmt-norm-bb-02.txt
Pages : 41
Date : 26-Jul-01
This memo describes issues related to the creation of negative-
acknowledgment (NACK) oriented reliable multicast (NORM) protocols.
The general goals and assumptions for NORM are defined. The tech-
nical challenges related to NACK-oriented (and in some cases gen-
eral) reliable multicast protocol design are identified. These
challenges are resolved into a set of applicable 'building blocks'
which are described in further detail. It is anticipated that
these building blocks (as they are further refined and defined in
future revisions of this document) will be useful in generating
different instantiations of reliable multicast protocols.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rmt-norm-bb-02.txt
Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-rmt-norm-bb-02.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.
Send a message to:
mailserv@ietf.org.
In the body type:
"FILE /internet-drafts/draft-ietf-rmt-norm-bb-02.txt".
NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body;
access-type="mail-server";
server="mailserv@ietf.org"
Content-Type: text/plain
Content-ID: <20010726171121.I-D@ietf.org>
ENCODING mime
FILE /internet-drafts/draft-ietf-rmt-norm-bb-02.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-ietf-rmt-norm-bb-02.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <20010726171121.I-D@ietf.org>
--OtherAccess--
--NextPart--
>From owner-rmt@listserv.lbl.gov Sun Aug 5 21:41:49 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f764Yli04669;
Sun, 5 Aug 2001 21:34:47 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f764YjK04665
for <rmt@listserv.lbl.gov>; Sun, 5 Aug 2001 21:34:45 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f764YWB23174
for <rmt@listserv.lbl.gov>; Sun, 5 Aug 2001 21:34:32 -0700 (PDT)
Received: from ns.live.com (ns.live.com [66.80.62.34])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f764YW523168
for <rmt@lbl.gov>; Sun, 5 Aug 2001 21:34:32 -0700 (PDT)
Received: (from rsf@localhost)
by ns.live.com (8.9.3/8.9.3) id VAA86250;
Sun, 5 Aug 2001 21:34:22 -0700 (PDT)
(envelope-from rsf)
Message-Id: <4.3.1.1.20010804234205.00b66990@localhost>
X-Sender: rsf@localhost
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Sun, 05 Aug 2001 00:25:54 -0700
To: "Mike Luby" <luby@digitalfountain.com>
From: Ross Finlayson <finlayson@live.com>
Subject: Re: Session control protocol instantiation discussion within
the IETF
Cc: "Rmt@Lbl. Gov" <rmt@lbl.gov>, confctrl@ISI.EDU
In-Reply-To: <NEBBIAPCNKEDCLPNFBNCGEBNCHAA.luby@digitalfountain.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-rmt@lbl.gov
Precedence: bulk
At 04:03 PM 8/2/01, Mike Luby wrote:
>In the upcoming RMT working group meeting at the IETF there will be a
>discussion about whether or not a session control protocol instantiation is:
>
>(1) within the mandate of the RMT working group
>
>(2) valuable assuming that the answer to (1) is "yes"
>
>The following draft is a description of a possible session control protocol.
>Note that this draft is not an official submission to the IETF, and its
>content will not be reviewed at the IETF meeting. This draft is available
>at:
>
><http://www.digitalfountain.com/getDocument.htm/technology/library/draft-ietf-rmt-mgl-pi-rccp-00-7-11-2001.txt>http://www.digitalfountain.com/getDocument.htm/technology/library/draft-ietf-rmt-mgl-pi-rccp-00-7-11-2001.txt
>
>This document describes the Rich Content Control Protocol (RCCP), a session
>control protocol for client initiated content delivery. The content in
>question may be a file, a stream or some other form of content. The RCCP
>protocol itself, however, is independent of the type of the content. RCCP
>offers support for both multicast and unicast delivery.
>
>Some of the key properties and goals of RCCP are:
>
>(1) Initiation of the session including communication of the session
>description to clients.
>(2) Session monitoring to facilitate server side accounting.
>(3) Session teardown, facilitating server side accounting and collection of
>client statistics.
>(4) Initiation and high level control of data packet reception.
>(5) Prevention of some types of DoS attacks on servers.
>(3) The ability to either directly or after configuration allow delivery of
>content through firewalls.
Mike & RMT (cc. MMUSIC),
I think such a protocol is needed, but at this point I'm not convinced that
it should be a completely new protocol. Instead, we should consider
whether such a protocol could be built upon the existing RTSP protocol -
the IETF standard control protocol for multimedia (AVT) sessions. RTSP
already addresses many of the issues that you outline for your control
protocol. While RTSP currently uses SDP - which is probably not rich
enough to describe reliable transport sessions - the 'next generation' of
SDP (nicknamed "SDPng") will be flexible enough to describe such
sessions. Presumably there can also be a "RTSPng" which can make use of
"SDPng", as well as having sufficient flexiblity to describe reliable
transport sessions.
Using RTSP (or "RTSPng") as the control protocol for reliable transport
sessions has several benefits over using a completely new protocol:
- Some multimedia sessions might include both streaming media (audio and/or
video) and reliable data delivery. It would be beneficial to use the same
control protocol for all parts of such a session.
- Some future RTP payload formats may include reliable (or semi-reliable)
delivery for part of its data. (E.g., a RTP payload format for Vorbis
audio will likely need to include a reliable delivery mechanism for
transporting 'codebooks' to receivers.) Ideally, all of the
parameters/attributes for such a session should be described in SDP (or SDPng).
- Some client tools may end up being used to receive/display both A/V
streams, and reliably-delivered files. It would simplify the
implementation of such clients if they could use a single control protocol,
rather than using one for A/V streams, and another for reliable data transport.
- Ditto for servers - if the same server implementation ends up being used
to serve both A/V streams and RMT data.
Ross.
>From owner-rmt@listserv.lbl.gov Mon Aug 6 15:37:18 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f76MacA04574;
Mon, 6 Aug 2001 15:36:39 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f76MabK04570
for <rmt@listserv.lbl.gov>; Mon, 6 Aug 2001 15:36:37 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f76Maal21082
for <rmt@listserv.lbl.gov>; Mon, 6 Aug 2001 15:36:36 -0700 (PDT)
Received: from real.com (prognet.com [205.219.198.1])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f76MaZ521075
for <rmt@lbl.gov>; Mon, 6 Aug 2001 15:36:35 -0700 (PDT)
Received: from goobox.prognet.com ([172.23.105.191])
by real.com (8.9.2/8.9.0) with ESMTP id PAA31755;
Mon, 6 Aug 2001 15:36:32 -0700 (PDT)
Date: Mon, 6 Aug 2001 15:35:52 -0700 (PDT)
From: Rob Lanphier <robla@real.com>
X-Sender: <robla@goobox.prognet.com>
To: Ross Finlayson <finlayson@live.com>
cc: Mike Luby <luby@digitalfountain.com>, "Rmt@Lbl. Gov" <rmt@lbl.gov>,
<confctrl@ISI.EDU>
Subject: Re: Session control protocol instantiation discussion within the
IETF
In-Reply-To: <4.3.1.1.20010804234205.00b66990@localhost>
Message-ID: <Pine.LNX.4.30.0108061528370.2206-100000@goobox.prognet.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-rmt@lbl.gov
Precedence: bulk
Yeah, what Ross said. It seems like we should be able to sit down this
week and figure out how to reformulate this as a proposal to extend RTSP.
This is roughly equivalent to the "Backchannel Multicast" feature we use
in RealServer (as distinguished from "Scalable Multicast" which doesn't
use the RTSP connection, but just serves an SDP file off of the HTTP port)
I'm here at the London meeting....let's try to catch up and sketch out an
RTSP version that meets your needs.
Rob
On Sun, 5 Aug 2001, Ross Finlayson wrote:
> At 04:03 PM 8/2/01, Mike Luby wrote:
> >In the upcoming RMT working group meeting at the IETF there will be a
> >discussion about whether or not a session control protocol instantiation is:
> >
> >(1) within the mandate of the RMT working group
> >
> >(2) valuable assuming that the answer to (1) is "yes"
> >
> >The following draft is a description of a possible session control protocol.
> >Note that this draft is not an official submission to the IETF, and its
> >content will not be reviewed at the IETF meeting. This draft is available
> >at:
> >
> ><http://www.digitalfountain.com/getDocument.htm/technology/library/draft-ietf-rmt-mgl-pi-rccp-00-7-11-2001.txt>http://www.digitalfountain.com/getDocument.htm/technology/library/draft-ietf-rmt-mgl-pi-rccp-00-7-11-2001.txt
> >
> >This document describes the Rich Content Control Protocol (RCCP), a session
> >control protocol for client initiated content delivery. The content in
> >question may be a file, a stream or some other form of content. The RCCP
> >protocol itself, however, is independent of the type of the content. RCCP
> >offers support for both multicast and unicast delivery.
> >
> >Some of the key properties and goals of RCCP are:
> >
> >(1) Initiation of the session including communication of the session
> >description to clients.
> >(2) Session monitoring to facilitate server side accounting.
> >(3) Session teardown, facilitating server side accounting and collection of
> >client statistics.
> >(4) Initiation and high level control of data packet reception.
> >(5) Prevention of some types of DoS attacks on servers.
> >(3) The ability to either directly or after configuration allow delivery of
> >content through firewalls.
>
> Mike & RMT (cc. MMUSIC),
>
> I think such a protocol is needed, but at this point I'm not convinced that
> it should be a completely new protocol. Instead, we should consider
> whether such a protocol could be built upon the existing RTSP protocol -
> the IETF standard control protocol for multimedia (AVT) sessions. RTSP
> already addresses many of the issues that you outline for your control
> protocol. While RTSP currently uses SDP - which is probably not rich
> enough to describe reliable transport sessions - the 'next generation' of
> SDP (nicknamed "SDPng") will be flexible enough to describe such
> sessions. Presumably there can also be a "RTSPng" which can make use of
> "SDPng", as well as having sufficient flexiblity to describe reliable
> transport sessions.
>
> Using RTSP (or "RTSPng") as the control protocol for reliable transport
> sessions has several benefits over using a completely new protocol:
> - Some multimedia sessions might include both streaming media (audio and/or
> video) and reliable data delivery. It would be beneficial to use the same
> control protocol for all parts of such a session.
> - Some future RTP payload formats may include reliable (or semi-reliable)
> delivery for part of its data. (E.g., a RTP payload format for Vorbis
> audio will likely need to include a reliable delivery mechanism for
> transporting 'codebooks' to receivers.) Ideally, all of the
> parameters/attributes for such a session should be described in SDP (or SDPng).
> - Some client tools may end up being used to receive/display both A/V
> streams, and reliably-delivered files. It would simplify the
> implementation of such clients if they could use a single control protocol,
> rather than using one for A/V streams, and another for reliable data transport.
> - Ditto for servers - if the same server implementation ends up being used
> to serve both A/V streams and RMT data.
>
> Ross.
>
>From owner-rmt@listserv.lbl.gov Wed Aug 8 20:46:23 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f793Xs511769;
Wed, 8 Aug 2001 20:33:54 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f793Xq911765
for <rmt@listserv.lbl.gov>; Wed, 8 Aug 2001 20:33:52 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f793Xpg15371
for <rmt@listserv.lbl.gov>; Wed, 8 Aug 2001 20:33:51 -0700 (PDT)
Received: from ns2.webfountain.com (mx2.webfountain.com [216.136.183.167])
by SpamWall.lbl.gov (8.11.2/8.11.2) with SMTP id f793Xn515368
for <rmt@lbl.gov>; Wed, 8 Aug 2001 20:33:51 -0700 (PDT)
Received: (qmail 24362 invoked from network); 9 Aug 2001 03:33:43 -0000
Received: from mail.intranet (10.1.1.37)
by ns2.webfountain.com with SMTP; 9 Aug 2001 03:33:43 -0000
Received: from mikedell (pptp-10-1-129-56.intranet [10.1.129.56])
by mail.intranet (8.9.3/8.9.3) with SMTP id UAA27005;
Wed, 8 Aug 2001 20:33:37 -0700
X-Authentication-Warning: mail.intranet: Host pptp-10-1-129-56.intranet [10.1.129.56] claimed to be mikedell
From: "Michael Luby" <luby@digitalfountain.com>
To: "Rob Lanphier" <robla@real.com>, "Ross Finlayson" <finlayson@live.com>
Cc: "Rmt@Lbl. Gov" <rmt@lbl.gov>, <confctrl@ISI.EDU>,
"Michael Luby" <luby@digitalfountain.com>,
"Allison Mankin" <mankin@ISI.EDU>, <sob@harvard.edu>
Subject: RE: Session control protocol instantiation discussion within the IETF
Date: Wed, 8 Aug 2001 20:37:44 -0700
Message-ID: <LEECJKFLPDAKCKACKOIBEEFHCAAA.luby@digitalfountain.com>
MIME-Version: 1.0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
In-Reply-To: <Pine.LNX.4.30.0108061528370.2206-100000@goobox.prognet.com>
Sender: owner-rmt@lbl.gov
Precedence: bulk
All,
I unfortunately was only at the IETF for a couple of days, and am back in
the Bay Area now. I would first like to talk with the transport area
directorate (Scott and Allison) to get some advice on this, and then
probably followup with a conference call with whoever is interested. Would
a conference call be ok with you Rob, Ross (and whoever else is
interested?).
Mike
-----Original Message-----
From: Rob Lanphier [mailto:robla@real.com]
Sent: Monday, August 06, 2001 3:36 PM
To: Ross Finlayson
Cc: Mike Luby; Rmt@Lbl. Gov; confctrl@ISI.EDU
Subject: Re: Session control protocol instantiation discussion within
the IETF
Yeah, what Ross said. It seems like we should be able to sit down this
week and figure out how to reformulate this as a proposal to extend RTSP.
This is roughly equivalent to the "Backchannel Multicast" feature we use
in RealServer (as distinguished from "Scalable Multicast" which doesn't
use the RTSP connection, but just serves an SDP file off of the HTTP port)
I'm here at the London meeting....let's try to catch up and sketch out an
RTSP version that meets your needs.
Rob
On Sun, 5 Aug 2001, Ross Finlayson wrote:
> At 04:03 PM 8/2/01, Mike Luby wrote:
> >In the upcoming RMT working group meeting at the IETF there will be a
> >discussion about whether or not a session control protocol instantiation
is:
> >
> >(1) within the mandate of the RMT working group
> >
> >(2) valuable assuming that the answer to (1) is "yes"
> >
> >The following draft is a description of a possible session control
protocol.
> >Note that this draft is not an official submission to the IETF, and its
> >content will not be reviewed at the IETF meeting. This draft is
available
> >at:
> >
>
><http://www.digitalfountain.com/getDocument.htm/technology/library/draft-ie
tf-rmt-mgl-pi-rccp-00-7-11-2001.txt>http://www.digitalfountain.com/getDocume
nt.htm/technology/library/draft-ietf-rmt-mgl-pi-rccp-00-7-11-2001.txt
> >
> >This document describes the Rich Content Control Protocol (RCCP), a
session
> >control protocol for client initiated content delivery. The content in
> >question may be a file, a stream or some other form of content. The RCCP
> >protocol itself, however, is independent of the type of the content.
RCCP
> >offers support for both multicast and unicast delivery.
> >
> >Some of the key properties and goals of RCCP are:
> >
> >(1) Initiation of the session including communication of the session
> >description to clients.
> >(2) Session monitoring to facilitate server side accounting.
> >(3) Session teardown, facilitating server side accounting and collection
of
> >client statistics.
> >(4) Initiation and high level control of data packet reception.
> >(5) Prevention of some types of DoS attacks on servers.
> >(3) The ability to either directly or after configuration allow delivery
of
> >content through firewalls.
>
> Mike & RMT (cc. MMUSIC),
>
> I think such a protocol is needed, but at this point I'm not convinced
that
> it should be a completely new protocol. Instead, we should consider
> whether such a protocol could be built upon the existing RTSP protocol -
> the IETF standard control protocol for multimedia (AVT) sessions. RTSP
> already addresses many of the issues that you outline for your control
> protocol. While RTSP currently uses SDP - which is probably not rich
> enough to describe reliable transport sessions - the 'next generation' of
> SDP (nicknamed "SDPng") will be flexible enough to describe such
> sessions. Presumably there can also be a "RTSPng" which can make use of
> "SDPng", as well as having sufficient flexiblity to describe reliable
> transport sessions.
>
> Using RTSP (or "RTSPng") as the control protocol for reliable transport
> sessions has several benefits over using a completely new protocol:
> - Some multimedia sessions might include both streaming media (audio
and/or
> video) and reliable data delivery. It would be beneficial to use the same
> control protocol for all parts of such a session.
> - Some future RTP payload formats may include reliable (or semi-reliable)
> delivery for part of its data. (E.g., a RTP payload format for Vorbis
> audio will likely need to include a reliable delivery mechanism for
> transporting 'codebooks' to receivers.) Ideally, all of the
> parameters/attributes for such a session should be described in SDP (or
SDPng).
> - Some client tools may end up being used to receive/display both A/V
> streams, and reliably-delivered files. It would simplify the
> implementation of such clients if they could use a single control
protocol,
> rather than using one for A/V streams, and another for reliable data
transport.
> - Ditto for servers - if the same server implementation ends up being used
> to serve both A/V streams and RMT data.
>
> Ross.
>
>From owner-rmt@listserv.lbl.gov Wed Aug 8 20:59:08 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f793nSR11785;
Wed, 8 Aug 2001 20:49:28 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f793nQ911781
for <rmt@listserv.lbl.gov>; Wed, 8 Aug 2001 20:49:26 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f793nPO16821
for <rmt@listserv.lbl.gov>; Wed, 8 Aug 2001 20:49:26 -0700 (PDT)
Received: from minotaur.nge.isi.edu (minotaur.nge.isi.edu [65.114.169.202])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f793nP516818
for <rmt@lbl.gov>; Wed, 8 Aug 2001 20:49:25 -0700 (PDT)
Received: from minotaur (mankin@localhost)
by minotaur.nge.isi.edu (8.11.2/8.11.2) with ESMTP id f793nHI04291;
Wed, 8 Aug 2001 23:49:18 -0400
Message-Id: <200108090349.f793nHI04291@minotaur.nge.isi.edu>
To: "Michael Luby" <luby@digitalfountain.com>
cc: "Rob Lanphier" <robla@real.com>, "Ross Finlayson" <finlayson@live.com>,
"Rmt@Lbl. Gov" <rmt@lbl.gov>, confctrl@ISI.EDU,
"Allison Mankin" <mankin@ISI.EDU>, sob@harvard.edu
Reply-To: mankin@ISI.EDU
Subject: Re: Session control protocol instantiation discussion within the IETF
In-reply-to: Your message of Wed, 08 Aug 2001 20:37:44 -0700.
<LEECJKFLPDAKCKACKOIBEEFHCAAA.luby@digitalfountain.com>
Date: Wed, 08 Aug 2001 23:49:17 -0400
From: Allison Mankin <mankin@ISI.EDU>
Sender: owner-rmt@lbl.gov
Precedence: bulk
Mike,
We ADs would be happy to talk with you about this sometime (but after
we all recover from IETF).
Having had one hallway talk with you while you were in London,
I think there is some value to discussing session work (without
prejudging if it would extend an existing charter or start up in
a new situation of some sort).
Mike Luby wrote:
> All,
> I unfortunately was only at the IETF for a couple of days, and am back in
> the Bay Area now. I would first like to talk with the transport area
> directorate (Scott and Allison) to get some advice on this, and then
> probably followup with a conference call with whoever is interested. Would
> a conference call be ok with you Rob, Ross (and whoever else is
> interested?).
> Mike
>
>From owner-rmt@listserv.lbl.gov Wed Aug 15 08:39:00 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f7FFXbD28811;
Wed, 15 Aug 2001 08:33:37 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f7FFXZZ28807
for <rmt@listserv.lbl.gov>; Wed, 15 Aug 2001 08:33:36 -0700 (PDT)
Received: from localhost (root@localhost)
by postal1.lbl.gov (8.11.2/8.11.2) with SMTP id f7FFXZM09335
for <rmt@listserv.lbl.gov>; Wed, 15 Aug 2001 08:33:35 -0700 (PDT)
Date: Wed, 15 Aug 2001 08:33:35 -0700 (PDT)
Message-Id: <200108151533.f7FFXZM09335@postal1.lbl.gov>
From: VirusWall@lbl.gov
To: rmt@listserv.lbl.gov
Subject: Virus Alert
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-rmt@lbl.gov
Precedence: bulk
This is an automated message from the LBNL VirusWall.
The mail message you recently received from: autow@wshlab2.ee.kuas.edu.tw
which included the file: javacomm20-win32.zip.lnk
contained the virus: TROJ_SIRCAM.A.
PLEASE NOTE:
1. The virus has been REMOVED from the email message by the LBNL VirusWall
and will NOT INFECT your computer.
2. It is SAFE to read the message and open the attachment, though you should
always use caution when opening attachments from people you do not know.
3. You do not need to notify anyone that you received this message.
For more information take a look at our virus protection web page:
http://www.lbl.gov/ITSD/Security/resources/
If you have any questions, please contact the LBNL Help Desk
at http://www.lbl.gov/help/, or 510-486-4357.
Thanks,
The VirusWall
Lawrence Berkeley National Laboratory
>From owner-rmt@listserv.lbl.gov Wed Aug 15 08:39:00 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f7FFXXX28805;
Wed, 15 Aug 2001 08:33:33 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f7FFXWZ28801
for <rmt@listserv.lbl.gov>; Wed, 15 Aug 2001 08:33:32 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f7FFXUN09281
for <rmt@listserv.lbl.gov>; Wed, 15 Aug 2001 08:33:30 -0700 (PDT)
Received: from wshlab2.ee.kuas.edu.tw (wshlab2.ee.nkit.edu.tw [140.127.114.233])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f7FFUR508077
for <rmt@lbl.gov>; Wed, 15 Aug 2001 08:30:28 -0700 (PDT)
Received: from wshstd.ee.kuas.edu.tw (unknown [140.127.114.234])
by wshlab2.ee.kuas.edu.tw (Postfix) with SMTP id 9B0D223686
for <rmt@lbl.gov>; Wed, 15 Aug 2001 23:32:33 +0800 (CST)
From: "=?ISO-8859-1?Q?=C4=A3=B0=F3?=" <autow@wshlab2.ee.kuas.edu.tw>
To: rmt@lbl.gov
Subject: javacomm20-win32
date: Wed, 15 Aug 2001 23:47:53 +0800
MIME-Version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
Content-Type: multipart/mixed; boundary="----5E983576_Outlook_Express_message_boundary"
Content-Disposition: Multipart message
Message-Id: <20010815153233.9B0D223686@wshlab2.ee.kuas.edu.tw>
Sender: owner-rmt@lbl.gov
Precedence: bulk
------5E983576_Outlook_Express_message_boundary
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
****************** Virus Warning Message (on the network)
Found virus TROJ_SIRCAM.A in file javacomm20-win32.zip.lnk
The file e/iscan/virus/virACBn6aaYn is moved to the configured virus directory.
*********************************************************
------5E983576_Outlook_Express_message_boundary
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: message text
Hi! How are you=3F
I send you this file in order to have your advice
See you later=2E Thanks
------5E983576_Outlook_Express_message_boundary
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
****************** Virus Warning Message (on the network)
javacomm20-win32.zip.lnk is removed from here because it contains a virus.
*********************************************************
------5E983576_Outlook_Express_message_boundary
------5E983576_Outlook_Express_message_boundary--
>From owner-rmt@listserv.lbl.gov Wed Aug 15 18:03:27 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f7G0xbV02594;
Wed, 15 Aug 2001 17:59:37 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f7G0xaZ02590
for <rmt@listserv.lbl.gov>; Wed, 15 Aug 2001 17:59:36 -0700 (PDT)
Received: from localhost (root@localhost)
by postal1.lbl.gov (8.11.2/8.11.2) with SMTP id f7G0xaw10901
for <rmt@listserv.lbl.gov>; Wed, 15 Aug 2001 17:59:36 -0700 (PDT)
Date: Wed, 15 Aug 2001 17:59:36 -0700 (PDT)
Message-Id: <200108160059.f7G0xaw10901@postal1.lbl.gov>
From: VirusWall@lbl.gov
To: rmt@listserv.lbl.gov
Subject: Virus Alert
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-rmt@lbl.gov
Precedence: bulk
This is an automated message from the LBNL VirusWall.
The mail message you recently received from: autow@wshlab2.ee.kuas.edu.tw
which included the file: javacomm20-win32.zip.pif
contained the virus: TROJ_SIRCAM.A.
PLEASE NOTE:
1. The virus has been REMOVED from the email message by the LBNL VirusWall
and will NOT INFECT your computer.
2. It is SAFE to read the message and open the attachment, though you should
always use caution when opening attachments from people you do not know.
3. You do not need to notify anyone that you received this message.
For more information take a look at our virus protection web page:
http://www.lbl.gov/ITSD/Security/resources/
If you have any questions, please contact the LBNL Help Desk
at http://www.lbl.gov/help/, or 510-486-4357.
Thanks,
The VirusWall
Lawrence Berkeley National Laboratory
>From owner-rmt@listserv.lbl.gov Wed Aug 15 18:03:27 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f7G0xUq02588;
Wed, 15 Aug 2001 17:59:30 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f7G0xTZ02584
for <rmt@listserv.lbl.gov>; Wed, 15 Aug 2001 17:59:29 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f7G0xRn10875
for <rmt@listserv.lbl.gov>; Wed, 15 Aug 2001 17:59:27 -0700 (PDT)
Received: from wshlab2.ee.kuas.edu.tw ([140.127.114.233])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f7G0wO510565
for <rmt@lbl.gov>; Wed, 15 Aug 2001 17:58:27 -0700 (PDT)
Received: from wshstd.ee.kuas.edu.tw (unknown [140.127.114.234])
by wshlab2.ee.kuas.edu.tw (Postfix) with SMTP id 5B16C236A1
for <rmt@lbl.gov>; Thu, 16 Aug 2001 09:00:43 +0800 (CST)
From: "=?ISO-8859-1?Q?=C4=A3=B0=F3?=" <autow@wshlab2.ee.kuas.edu.tw>
To: rmt@lbl.gov
Subject: javacomm20-win32
date: Thu, 16 Aug 2001 09:16:02 +0800
MIME-Version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
Content-Type: multipart/mixed; boundary="----2C762821_Outlook_Express_message_boundary"
Content-Disposition: Multipart message
Message-Id: <20010816010043.5B16C236A1@wshlab2.ee.kuas.edu.tw>
Sender: owner-rmt@lbl.gov
Precedence: bulk
------2C762821_Outlook_Express_message_boundary
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
****************** Virus Warning Message (on the network)
Found virus TROJ_SIRCAM.A in file javacomm20-win32.zip.pif
The file e/iscan/virus/virPUB.pbWjr is moved to the configured virus directory.
*********************************************************
------2C762821_Outlook_Express_message_boundary
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: message text
Hi! How are you=3F
I send you this file in order to have your advice
See you later=2E Thanks
------2C762821_Outlook_Express_message_boundary
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
****************** Virus Warning Message (on the network)
javacomm20-win32.zip.pif is removed from here because it contains a virus.
*********************************************************
------2C762821_Outlook_Express_message_boundary
------2C762821_Outlook_Express_message_boundary--
>From owner-rmt@listserv.lbl.gov Fri Aug 17 10:56:09 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f7HHqax22587;
Fri, 17 Aug 2001 10:52:36 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f7HHqZV22583
for <rmt@listserv.lbl.gov>; Fri, 17 Aug 2001 10:52:35 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f7HHqYT03412
for <rmt@listserv.lbl.gov>; Fri, 17 Aug 2001 10:52:34 -0700 (PDT)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f7HHqY503408
for <rmt@lbl.gov>; Fri, 17 Aug 2001 10:52:34 -0700 (PDT)
Received: from lorenzo-u10.cisco.com (lorenzo-u10.cisco.com [128.107.162.143])
by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f7HHqiT22598
for <rmt@lbl.gov>; Fri, 17 Aug 2001 10:52:44 -0700 (PDT)
Received: from localhost (lorenzo@localhost) by lorenzo-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id KAA19204 for <rmt@lbl.gov>; Fri, 17 Aug 2001 10:52:28 -0700 (PDT)
Message-Id: <200108171752.KAA19204@lorenzo-u10.cisco.com>
X-Authentication-Warning: lorenzo-u10.cisco.com: lorenzo owned process doing -bs
X-Mailer: exmh version 2.3.1 01/18/2001 with version: MH 6.8.4 #29[UCI]
To: rmt@lbl.gov
Subject: Presentations and Minutes submissions for the 51st IETF (fwd)
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 17 Aug 2001 10:52:28 -0700
From: Lorenzo Vicisano <lorenzo@cisco.com>
Sender: owner-rmt@lbl.gov
Precedence: bulk
For all presenters at the last RMT meeting in London, please submit you
presentation material to minutes@ietf.org, if you have not already
done so.
thank you,
Lorenzo Vicisano
------- Forwarded Message
Message-ID: <3B7D3CB8.576A3196@ietf.org>
Date: Fri, 17 Aug 2001 11:48:09 -0400
From: IETF Proceedings Coordinator <minutes@ietf.org>
MIME-Version: 1.0
To: wgchairs@ietf.org, bofchairs@ietf.org
CC: scoya@ietf.org
Subject: Presentations and Minutes submissions for the 51st IETF
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Hello,
This is a reminder to all group chairs and presenters to submit your
visual materials and meeting minutes. Any materials from interim
meetings should be noted as such. No intermediate drafts of meeting
minutes should be submitted, only final drafts.
Slide presentations must be provided in one of the following formats:
.html / .htm HTML
.pdf Adobe Portable Document Format
.ps Postscript 1, 2
.ppt Microsoft PowerPoint (95-2000)
.txt Dos/Mac/Unix Text
Meeting minutes must be provided as plain text (Dos/Mac/or Unix)
Meeting agendas may be provided within a presentation or in the minutes.
All submitted material is now available at the following location:
http://www.ietf.org/proceedings/01aug/index.html
To submit materials, please email them to minutes@ietf.org.
It will take approximately 2-3 days for newly submitted materials to
post.
Thank you,
Proceedings Coordinator
------- End of Forwarded Message
>From owner-rmt@listserv.lbl.gov Sat Aug 18 14:06:51 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f7IL0FL10039;
Sat, 18 Aug 2001 14:00:15 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f7IL0EV10006
for <rmt@listserv.lbl.gov>; Sat, 18 Aug 2001 14:00:14 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f7IL0DK23277
for <rmt@listserv.lbl.gov>; Sat, 18 Aug 2001 14:00:13 -0700 (PDT)
Received: from dfw-smtpout1.email.verio.net (dfw-smtpout1.email.verio.net [129.250.36.41])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f7IL0C523274
for <rmt@lbl.gov>; Sat, 18 Aug 2001 14:00:12 -0700 (PDT)
Received: from [129.250.38.63] (helo=dfw-mmp3.email.verio.net)
by dfw-smtpout1.email.verio.net with esmtp
id 15YDCQ-0006xq-00; Sat, 18 Aug 2001 21:00:06 +0000
Received: from [63.184.75.187] (helo=localhost)
by dfw-mmp3.email.verio.net with esmtp
id 15YDCG-0002bW-00; Sat, 18 Aug 2001 20:59:56 +0000
X-Sender: robertlong@veriomail.com
From: Bob Long <robertlong@veriomail.com>
To: "Mortgage Rate Info" <robertlong@veriomail.com>
Date: Sat, 18 Aug 2001 14:06:04 -0700
Subject: Need a Home Loan? We Can Help!!
Reply-To: robertlong@veriomail.com
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_001__28034840_50764.44"
Message-Id: <E15YDCG-0002bW-00@dfw-mmp3.email.verio.net>
Sender: owner-rmt@lbl.gov
Precedence: bulk
This is a Multipart MIME message.
------=_NextPart_000_001__28034840_50764.44
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit
------=_NextPart_000_001__28034840_50764.44
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: base64
DQoNCjxIVE1MPg0KDQo8aGVhZD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIg
Q09OVEVOVD0idGV4dC9odG1sO2NoYXJzZXQ9aXNvLTg4NTktMSI+DQo8IURPQ1RZUEUgSFRN
TCBQVUJMSUMgIi0vL1czQy8vRFREIEhUTUwgNC4wIFRyYW5zaXRpb25hbC8vRU4iPg0KPFRJ
VExFPkZyZWUgUmF0ZSBRdW90ZTwvVElUTEU+DQo8TUVUQSBjb250ZW50PSJ0ZXh0L2h0bWw7
IGNoYXJzZXQ9aXNvLTg4NTktMSIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+PFhNRVRBIA0K
Y29udGVudD0iTW96aWxsYS80LjcgW2VuXSAoV2luOTg7IEkpIFtOZXRzY2FwZV0iIG5hbWU9
IkdFTkVSQVRPUiI+DQo8TUVUQSBjb250ZW50PSJNaWNyb3NvZnQgRnJvbnRQYWdlIDQuMCIg
bmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVBRD4NCjxCT0RZIGJhY2tn
cm91bmQ9aHR0cDovLzIxNy42Ny4yMzAuMTUvbW9uZXlfZ3IuanBnIGJnQ29sb3I9I2ZmZmZm
ZiBiZ3Byb3BlcnRpZXM9ImZpeGVkIj4NCjxESVYgc3R5bGU9IkZPTlQ6IDEwcHQgYXJpYWwi
Pg0KPERJVj4mbmJzcDs8L0RJVj48L0RJVj4NCjxESVY+PEJSPjwvRElWPg0KPFAgYWxpZ249
Y2VudGVyPjxlbT48Yj48Zm9udCBjb2xvcj0iI2ZmMDAwMCIgc2l6ZT0iNiI+JnF1b3Q7UmVm
aW5hbmNpbmcgWW91cg0KQ3VycmVudCBNb3J0Z2FnZSBNYWtlcyAkZW5zZSEmcXVvdDs8L2Zv
bnQ+PC9iPjwvZW0+PC9QPg0KPHAgYWxpZ249ImNlbnRlciI+PGI+PGZvbnQgc2l6ZT0iNCI+
TW9ydGdhZ2UgUmF0ZXMgQXJlIFNvIExvdyEmbmJzcDs8L2ZvbnQ+PC9iPjwvcD4NCjxwIGFs
aWduPSJjZW50ZXIiPjxiPjxmb250IHNpemU9IjQiPllvdSBDYW4gU2F2ZSBUaG91c2FuZHMg
T2YgRG9sbGFycyBCeSBUYWtpbmcNCkFkdmFudGFnZSBOb3chPC9mb250PjwvYj48L3A+DQo8
UCBhbGlnbj1jZW50ZXI+PEVNPjxCPjxGT05UIGNvbG9yPSNmZjAwMDAgc2l6ZT01PiZxdW90
O1dFIEFSRSBBTiBBU1NPQ0lBVElPTiBPRg0KTU9SVEdBR0UgQlJPS0VSUyBBTkQgTEVOREVS
UyA8L0ZPTlQ+PC9CPjwvRU0+PC9QPg0KPFAgYWxpZ249Y2VudGVyPjxFTT48Qj48Rk9OVCBj
b2xvcj0jZmYwMDAwIHNpemU9NT5XSVRIIFRIRSBCRVNUIFJBVEVTIEFORCBUSEUgTE9XRVNU
DQpDT1NUUyEmcXVvdDwvRk9OVD48L0I+PC9FTT48L1A+DQo8cCBhbGlnbj0iY2VudGVyIj4m
bmJzcDs8L3A+DQo8UCBhbGlnbj1jZW50ZXI+PEZPTlQgY29sb3I9IzAwMDBmZiBzaXplPTQ+
PEI+V2UmbmJzcDtoYXZlIHRob3VzYW5kcyBvZiBsb2FuIA0KcHJvZ3JhbXMgdGhyb3VnaCBo
dW5kcmVkcyBvZiBsZW5kZXJzITxCUj48L0I+PC9GT05UPjxGT05UIHNpemU9Mz48L0ZPTlQ+
PC9QPg0KPFAgYWxpZ249Y2VudGVyPjxTVFJPTkc+PEZPTlQgc2l6ZT01PllvdSBjYW4gY2hv
b3NlIGZyb20mbmJzcDsiQWRqdXN0YWJsZSBSYXRlDQpNb3J0Z2FnZXMgDQphcyBsb3cgYXMg
My45NSUmcXVvdDs8L0ZPTlQ+PC9TVFJPTkc+PC9QPg0KPFAgYWxpZ249Y2VudGVyPjxTVFJP
Tkc+PEZPTlQgc2l6ZT01PmFuZCZuYnNwOyJGaXhlZCBSYXRlIE1vcnRnYWdlcyBhcyBsb3cg
YXMNCjYuNTAlJm5ic3A7PC9GT05UPjwvU1RST05HPjwvUD4NCjxQIGFsaWduPWNlbnRlcj48
U1RST05HPjxGT05UIHNpemU9NT5hbGwgd2l0aCB0aGUgbG93ZXN0IGNvc3RzIGluIHRoZQ0K
TmF0aW9uISZxdW90OzwvRk9OVD48L1NUUk9ORz48QklHPjxCSUc+PEZPTlQgY29sb3I9I2Zm
MDAwMD4qPC9GT05UPjwvQklHPjwvQklHPjwvUD4NCjxQIGFsaWduPWNlbnRlcj48Rk9OVCAN
CnNpemU9NT48Zm9udCBjb2xvcj0iI0ZGMDAwMCI+JnF1b3Q7PGI+PGk+WU9VIENBTiA8dT5C
VVkgRE9XTiBZT1VSIElOVEVSRVNUIFJBVEU8L3U+DQpUTzwvaT48L2I+PC9mb250PjwvRk9O
VD48L1A+DQo8UCBhbGlnbj1jZW50ZXI+PGZvbnQgY29sb3I9IiNGRjAwMDAiIHNpemU9IjUi
PjxiPjxpPkFTIExPVyBBUyBZT1UgQ0FODQpBRkZPUkQhJnF1b3Q7PC9pPjwvYj48L2ZvbnQ+
PEZPTlQgDQpzaXplPTU+PEJSPjwvRk9OVD48Rk9OVCBzaXplPTM+PC9GT05UPjwvUD4NCjxQ
IGFsaWduPWNlbnRlcj48Rk9OVCBzaXplPSswPjxGT05UIGNvbG9yPSMwMDAwZmYgc2l6ZT0y
PjxCSUc+PEJJRz48Rk9OVCANCmNvbG9yPSNmZjAwMDAgc2l6ZT01Pio8L0ZPTlQ+PC9CSUc+
PFNUUk9ORz5BbGwgcmF0ZXMgYXJlIGJhc2VkIG9uIA0KcXVhbGlmaWNhdGlvbjwvU1RST05H
PiE8L0JJRz48L0ZPTlQ+PC9GT05UPjwvUD4NCjxQIGFsaWduPWNlbnRlcj48Rk9OVCBzaXpl
PSswPjxGT05UIHNpemU9Mj48QklHPjwvQklHPjwvRk9OVD48Rk9OVCANCmNvbG9yPSMwMDAw
ZmY+PEZPTlQgZmFjZT1BcmlhbD48Rk9OVCBzaXplPTI+PEEgaHJlZj0iaHR0cDovLzIxNy42
Ny4yMzAuMTUiIA0KdGFyZ2V0PV9ibGFuaz48Rk9OVCBzaXplPTU+PFNUUk9ORz48Rk9OVCBm
YWNlPSJUaW1lcyBOZXcgUm9tYW4iPkNsaWNrIGhlcmUgZm9yIA0KeW91ciA8L0ZPTlQ+PEZP
TlQgc2l6ZT02PjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PEVNPiJGUkVFIFJBVEUg
DQpRVU9URSIhPC9FTT48L0ZPTlQ+PC9GT05UPjwvU1RST05HPjwvRk9OVD48L0E+PC9GT05U
PjwvRk9OVD48L0ZPTlQ+PC9GT05UPjwvUD4NCjxQIGFsaWduPWxlZnQ+Jm5ic3A7PC9QPg0K
PFAgYWxpZ249bGVmdD48aT48Yj48Zm9udCBmYWNlPSJBcmlhbCIgc2l6ZT0iKzAiPkNMSUNL
IE9OIExPQU5TIEJFTE9XIEZPUiBZT1VSDQpGUkVFIEFQUExJQ0FUSU9OITwvZm9udD48L2I+
PC9pPjxGT05UIGZhY2U9QXJpYWw+PEJSPjwvRk9OVD48L1A+DQo8UCBhbGlnbj1sZWZ0PjxT
VFJPTkc+PEVNPjxBIGhyZWY9Imh0dHA6Ly8yMTcuNjcuMjMwLjE1IiANCnRhcmdldD1fYmxh
bms+PGZvbnQgc2l6ZT0iNSIgY29sb3I9IiM4MDAwODAiPlB1cmNoYXNlIExvYW5zPC9mb250
PjwvQT4gPEZPTlQgc2l6ZT01Pg0KPC9GT05UPiA8L0VNPjxGT05UIA0Kc2l6ZT00Pi0gPEVN
PlRob3VzYW5kcyBvZiBwcm9ncmFtcyANCmZvciBGaXJzdCBNb3J0Z2FnZXMhPC9FTT48L0ZP
TlQ+PEk+PC9JPjwvU1RST05HPjxJPjxGT05UIA0KY29sb3I9IzAwMDAwMD48QlI+PEJSPjwv
Rk9OVD48L0k+PEEgaHJlZj0iaHR0cDovLzIxNy42Ny4yMzAuMTUiIF9ibGFuaz8+PEVNPjxT
VFJPTkc+PGZvbnQgc2l6ZT0iNSIgY29sb3I9IiM4MDAwODAiPlJlZmluYW5jZSBMb2Fuczwv
Zm9udD48L1NUUk9ORz48L0VNPjxJPjxGT05UIA0KY29sb3I9IzAwMDAwMCBzaXplPTI+IDwv
Rk9OVD48L0k+PC9BPjxJPjxGT05UIGNvbG9yPSMwMDAwMDAgc2l6ZT00Pi0gPEI+UmVkdWNl
IHlvdXIgDQptb250aGx5IHBheW1lbnRzIGFuZDwvRk9OVD48Rk9OVCBjb2xvcj0jMDAwMDAw
IHNpemU9Mj4gPC9GT05UPjxGT05UIA0KY29sb3I9I2ZmMDAwMCBzaXplPTU+R2V0IENhc2gg
QmFjayE8L0ZPTlQ+PC9CPjxGT05UIGNvbG9yPSMwMDAwMDAgc2l6ZT00PiANCjwvRk9OVD48
Rk9OVCBjb2xvcj0jMDAwMDAwIHNpemU9Mz48QlI+PEJSPjwvRk9OVD48L0k+PEEgDQpocmVm
PSJodHRwOi8vMjE3LjY3LjIzMC4xNSIgdGFyZ2V0PV9ibGFuaz48Zm9udCBjb2xvcj0iIzgw
MDA4MCI+PEVNPjxCPjxGT05UIHNpemU9NT5TZWNvbmQgDQpNb3J0Z2FnZXM8L0ZPTlQ+PC9C
PjwvRU0+PEk+PEZPTlQgc2l6ZT0zPiA8L0ZPTlQ+PC9JPg0KPC9mb250PiA8L0E+PEk+PEZP
TlQgY29sb3I9IzAwMDAwMCBzaXplPTM+IC0gPC9GT05UPjxCPjxGT05UIA0KY29sb3I9IzAw
MDAwMCBzaXplPTQ+V2UgY2FuIGhlbHAgeW91IGdldCBmcm9tIDwvRk9OVD48Rk9OVCBjb2xv
cj0jZmYwMDAwIA0Kc2l6ZT01PjkwJTwvRk9OVD48Rk9OVCBjb2xvcj0jMDAwMDAwIHNpemU9
ND4gdXAgdG8gPC9GT05UPjxGT05UIGNvbG9yPSNmZjAwMDAgDQpzaXplPTU+MTI1JTwvRk9O
VD48Rk9OVCBjb2xvcj0jMDAwMDAwIHNpemU9ND4gb2YgeW91ciBob21lcyB2YWx1ZSEgKHJh
dGlvcyB2YXJ5IA0KYnkgc3RhdGUpPC9GT05UPjwvQj48L1A+DQo8UCBhbGlnbj1sZWZ0PjxB
IGhyZWY9Imh0dHA6Ly8yMTcuNjcuMjMwLjE1IiANCnRhcmdldD1fYmxhbms+PEI+PGZvbnQg
c2l6ZT0iNSIgY29sb3I9IiM4MDAwODAiPkRlYnQgQ29uc29saWRhdGlvbjwvZm9udD48L0I+
PC9BPjxGT05UIGNvbG9yPSMwMDAwMDAgc2l6ZT0zPiA8Rk9OVCBjb2xvcj0jMDAwMDAwIHNp
emU9ND4tIA0KPEI+Q29tYmluZSA8L0ZPTlQ+PEZPTlQgY29sb3I9I2ZmMDAwMCBzaXplPTU+
YWxsPC9GT05UPjxGT05UIGNvbG9yPSMwMDAwMDAgDQpzaXplPTQ+IHlvdXIgYmlsbHMgaW50
byA8L0ZPTlQ+PEZPTlQgY29sb3I9I2ZmMDAwMCBzaXplPTU+T25lIExvdyBNb250aGx5IA0K
UGF5bWVudCE8L0ZPTlQ+PC9CPjxCUj48QlI+PC9GT05UPjxCPjxBIA0KaHJlZj0iaHR0cDov
LzIxNy42Ny4yMzAuMTUiIHRhcmdldD1fYmxhbms+PGZvbnQgc2l6ZT0iNSIgY29sb3I9IiM4
MDAwODAiPkZpcnN0IFRpbWUgSG9tZSBCdXllcnM8L2ZvbnQ+PC9BPjxGT05UIGNvbG9yPSMw
MDAwMDAgc2l6ZT0zPiAtIA0KPEZPTlQgY29sb3I9IzAwMDAwMCBzaXplPTQ+V2UgY2FuIGhl
bHAgeW91IGJ1eSB3aXRoIDxGT05UIGNvbG9yPSNmZjAwMDAgDQpzaXplPTU+TG93PC9GT05U
PjwvRk9OVD48Rk9OVCBjb2xvcj0jZmYwMDAwIHNpemU9NT4gTW9uZXkgRG93bjwvRk9OVD48
Rk9OVCANCmNvbG9yPSMwMDAwMDAgc2l6ZT00PiwgYW5kIGV2ZW4gPC9GT05UPjxGT05UIGNv
bG9yPSNmZjAwMDAgc2l6ZT01PkdldCBDYXNoIA0KQmFjayE8L0ZPTlQ+PC9GT05UPjwvQj48
L1A+PC9JPg0KPFAgYWxpZ249Y2VudGVyPjxCSUc+PEJJRz48Rk9OVCBjb2xvcj0jZmYwMDAw
Pio8L0ZPTlQ+PC9CSUc+QWxsIHJhdGVzIGFyZSBiYXNlZCANCm9uIHF1YWxpZmljYXRpb24h
PC9CSUc+PC9QPg0KPFAgYWxpZ249Y2VudGVyPjxCPjxJPjxGT05UIGNvbG9yPSMwMDAwMDAg
c2l6ZT02PldlIGhhdmUgcHJvZ3JhbXMgZm9yIA0KPC9GT05UPjxGT05UIGNvbG9yPSNmZjAw
MDAgc2l6ZT02PjxVPkVWRVJZPC9VPjwvRk9OVD48Rk9OVCBjb2xvcj0jMDAwMDAwIHNpemU9
Nj4gDQpjcmVkaXQgc2l0dWF0aW9uITwvRk9OVD48QlI+PEJSPjxBIGhyZWY9Imh0dHA6Ly8y
MTcuNjcuMjMwLjE1IiB0YXJnZXQ9X2JsYW5rPjxGT05UIA0KY29sb3I9IzAwMDBmZiBzaXpl
PTU+Q2xpY2sgaGVyZSBmb3IgeW91ciBGUkVFIFJBVEUgUVVPVEUhPC9GT05UPjwvQT48L0k+
PC9CPjwvUD4NCjxQIGFsaWduPWxlZnQ+PEZPTlQgY29sb3I9IzAwODAwMD48U1RST05HPiAN
CklmIHlvdSBmZWVsIHRoYXQgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBtZXNzYWdlIGluIGVy
cm9yLCBwbGVhc2UgZm9sbG93IHRoZSBiZWxvdyANCmluc3RydWN0aW9ucyBhbmQgeW91IHdp
bGwgYmUgcmVtb3ZlZCBpbW1lZGlhdGVseS4gIFdlIGltbWVkaWF0ZWx5IGhvbm9yIGFsbCBy
ZXF1ZXN0cyANCnRvIGJlIHJlbW92ZWQgZnJvbSB0aGlzIGxpc3QuIFRoaXMgbWVzc2FnZSBp
cyBiZWluZyBzZW50IHRvIHlvdSBpbiBjb21wbGlhbmNlIHdpdGggDQp0aGUgRmVkZXJhbCBs
ZWdpc2xhdGlvbiBmb3IgY29tbWVyY2lhbCBlLW1haWwgKEguUi40MTc2IC0gU2VjdGlvbiAx
MDEsICBQYXJhZ3JhcGggDQooZSkoMSkoYSkpIGFuZCBCaWxsIHMuMTYxOCBUaXRsZSBJSUkg
cGFzc2VkIGJ5IHRoZSAxMDV0aCBVUyBDb25ncmVzcy4sIGZ1cnRoZXIgDQp0cmFuc21pc3Np
b25zIHRvIHlvdSBieSB0aGUgc2VuZGVyIG9mIHRoaXMgZS1tYWlsIG1heSBiZSBzdG9wcGVk
IGF0IG5vIGNvc3QgdG8geW91IA0KYnkgc3VibWl0dGluZyBhIHJlcXVlc3QgdG8gYmUgcmVt
b3ZlZC4gPGEgaHJlZj0ibWFpbHRvOmdyZWF0cmF0ZXMxMDhAZXhjaXRlLmNvbT9zdWJqZWN0
PVBMRUFTRV9SRU1PVkVfTUUhX1ZSTzEiPkNsaWNrIEhlcmUgdG8gU2VuZCBhIFJlbW92ZSBS
ZXF1ZXN0PC9hPi4NCk5vIG5lZWQgdG8gdHlwZSBhbnkgbWVzc2FnZS48L1NUUk9ORz48L0ZP
TlQ+PC9QPjwvQk9EWT48L0hUTUw+
------=_NextPart_000_001__28034840_50764.44--
>From owner-rmt@listserv.lbl.gov Tue Aug 21 04:16:00 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f7LBCat23526;
Tue, 21 Aug 2001 04:12:36 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f7LBCZV23522
for <rmt@listserv.lbl.gov>; Tue, 21 Aug 2001 04:12:35 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f7LBCZ929506
for <rmt@listserv.lbl.gov>; Tue, 21 Aug 2001 04:12:35 -0700 (PDT)
Received: from rafi ([213.8.76.34])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f7LBCW529495
for <rmt@lbl.gov>; Tue, 21 Aug 2001 04:12:33 -0700 (PDT)
Received: from mail pickup service by rafi with Microsoft SMTPSVC;
Tue, 21 Aug 2001 14:12:31 +0200
From: <sales@seebex.com>
To: <rmt@lbl.gov>
Subject: Instant Messaging platform at your Web site is now a few clicks away
Date: Tue, 21 Aug 2001 14:12:31 +0200
Message-ID: <125701c12a3a$8dacb3e0$0200a8c0@rafi>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Mailer: Microsoft CDO for Windows 2000
Thread-Index: AcEqOo2srhYARx8QRVKpv6ZqyPGCRg==
Content-Class: urn:content-classes:message
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
X-OriginalArrivalTime: 21 Aug 2001 12:12:31.0706 (UTC) FILETIME=[8DB5DBA0:01C12A3A]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by SpamWall.lbl.gov id f7LBCZV23523
Sender: owner-rmt@lbl.gov
Precedence: bulk
Instant Messaging platform at your Web site is now a few clicks away
----------------------------------------------------------------------
Install a FREE Instant Messaging server at your Web site.
Use it as is or customize to meet your specific branding.
Cross platform servers line support 25 and up to 1000 concurrent users
All servers offered can be secured with RSA 512Bit (and higher) encryption!!
Download free 10 concurrent users server at:
http://www.seebex.com/download/get_server.asp
It is easier, faster and affordable than ever!!
For further information please check seebex Web site at: http://www.seebex.com
or contact our Marketing & Sales department at sales@seebex.com
First 50 Web sites to download and embed the free 10 concurrent users server
are entitled to a free 100 concurrent users server
and will be listed on Seebex Web site.
>From owner-rmt@listserv.lbl.gov Tue Aug 21 12:47:42 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f7LJdOP07751;
Tue, 21 Aug 2001 12:39:24 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f7LJdMV07747
for <rmt@listserv.lbl.gov>; Tue, 21 Aug 2001 12:39:22 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f7LJdKo24089
for <rmt@listserv.lbl.gov>; Tue, 21 Aug 2001 12:39:20 -0700 (PDT)
Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f7LJdA524036
for <rmt@lbl.gov>; Tue, 21 Aug 2001 12:39:10 -0700 (PDT)
Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85])
by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f7LJdCi13190
for <rmt@lbl.gov>; Tue, 21 Aug 2001 14:39:13 -0500 (CDT)
Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com
(Content Technologies SMTPRS 4.2.5) with ESMTP id <T5581f8348aac12f255079@davir02nok.americas.nokia.com>;
Tue, 21 Aug 2001 14:39:07 -0500
content-class: urn:content-classes:message
Subject: RE: Session control protocol instantiation discussion within the IETF
Date: Tue, 21 Aug 2001 14:38:31 -0500
Message-ID: <B9CFA6CE8FFDD211A1FB0008C7894E4604B9E792@bseis01nok>
X-MS-Has-Attach:
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="----_=_NextPart_001_01C12A78.DBC2BFA0"
X-MS-TNEF-Correlator:
Thread-Topic: Session control protocol instantiation discussion within the IETF
Thread-Index: AcEghmN7vo7KnYxsEdWrxAAIx6S5QwJ763Vg
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
From: "Trossen Dirk (NRC/Boston)" <Dirk.Trossen@nokia.com>
To: <mankin@ISI.EDU>, "Michael Luby" <luby@digitalfountain.com>
Cc: "Rob Lanphier" <robla@real.com>, "Ross Finlayson" <finlayson@live.com>,
"Rmt@Lbl. Gov" <rmt@lbl.gov>, <confctrl@ISI.EDU>, <sob@harvard.edu>,
"ietf-floor control" <flr-ctrl-grp@network2.cs.usm.my>
Sender: owner-rmt@lbl.gov
Precedence: bulk
This is a multi-part message in MIME format.
------_=_NextPart_001_01C12A78.DBC2BFA0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hi all,
as announced on the MMUSIC mailing list, a couple of people
being interested in conference course control met on Wednesday
August 8th (10-11pm) during the London IETF meeting to discuss=20
further steps in this direction.
The following persons were present during this informal meeting:
Jun-Won Lee, Shin-Gak Kang, Jonathan Rosenberg, Eunsook Kim,
Colin Perkins, Joerg Ott, Dirk Kutscher, Dirk Trossen
During the meeting, a general interest in this topic was
expressed by the attendents. However, the concern was
raised (by Jonathan, Joerg, and Colin) that the scope
of the work has to be defined very carefully. Especially
Jonathan expressed interest in 'doable' solutions, i.e.,
covering rather simple centralized conferencing scenarios
first rather than defining a wide scope of the work.
The following steps have been proposed to be undertaken in
this direction:
- provision of a problem statement document
- submission to mailing list(s)
- creation of own discussion list for this topic
The problem statement document should be created by a circle
of people being interested in this topic and willing to contribute
to this work.=20
The discussion of the problem statement should end in a
decision how to bring this topic to the IETF within the
therein defined scope, either within the charter of existing
WGs or by organizing a BOF.
Since similar discussions about future session control efforts=20
have been undertaken within the RMT WG, I'm sending this mail=20
also to this list to invite interested people to join the discussion.
Enclosed you find the current document which was meant as a=20
problem statement for conference course control. This document
is far from being completed (it was not submitted as a draft although
it is written in Internet draft style) but it is intended as a basis
for discussion to reach final document status.
Any comments are welcome.
Best Regards,
Dirk Trossen
-----------------------
Dirk Trossen
Nokia Research Center
5 Wayside Road
Burlington, MA 01803
Tel: +1 (781) 993 3605
Fax: +1 (781) 993 1907
mob: +1 (617) 794 7041
-----------------------
> -----Original Message-----
> From: ext Allison Mankin [mailto:mankin@ISI.EDU]
> Sent: Wednesday, August 08, 2001 11:49 PM
> To: Michael Luby
> Cc: Rob Lanphier; Ross Finlayson; Rmt@Lbl. Gov; confctrl@ISI.EDU;
> Allison Mankin; sob@harvard.edu
> Subject: Re: Session control protocol instantiation discussion within
> the IETF=20
>=20
>=20
> Mike,
>=20
> We ADs would be happy to talk with you about this sometime (but after=20
> we all recover from IETF). =20
>=20
> Having had one hallway talk with you while you were in London,
> I think there is some value to discussing session work (without
> prejudging if it would extend an existing charter or start up in
> a new situation of some sort).
>=20
> Mike Luby wrote:
> > All,
> > I unfortunately was only at the IETF for a couple of days,=20
> and am back in
> > the Bay Area now. I would first like to talk with the=20
> transport area
> > directorate (Scott and Allison) to get some advice on this, and then
> > probably followup with a conference call with whoever is=20
> interested. Would
> > a conference call be ok with you Rob, Ross (and whoever else is
> > interested?).
> > Mike
> >=20
>=20
------_=_NextPart_001_01C12A78.DBC2BFA0
Content-Type: text/plain;
name="draft-trossen-problem-00.txt"
Content-Transfer-Encoding: base64
Content-Description: draft-trossen-problem-00.txt
Content-Disposition: attachment;
filename="draft-trossen-problem-00.txt"
DQpJbnRlcm5ldCBFbmdpbmVlcmluZyBUYXNrIEZvcmNlICAgICAgICAgICAgICAgICAgRC4gVHJv
c3NlbiAoRWRpdG9yKSANCkludGVybmV0IERyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIE5va2lhIFJlc2VhcmNoIA0KZHJhZnQtdHJvc3Nlbi1wcm9ibGVtLTAwLnR4
dCAgICAgICAgICAgICAgICAgICAgICAgICAgICAxMS4gTWF5IDIwMDEgDQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRXhwaXJlczogTm92ZW1iZXIgMjAwMSAN
CiANCiANCiAgICAgICAgICAgICAgICBDb25mZXJlbmNlIENvdXJzZSBDb250cm9sIFByb2JsZW0g
U3RhdGVtZW50IA0KIA0KIA0KU3RhdHVzIG9mIHRoaXMgTWVtbyANCiANCiAgIFRoaXMgZG9jdW1l
bnQgaXMgYW4gSW50ZXJuZXQtRHJhZnQgYW5kIGlzIGluIGZ1bGwgY29uZm9ybWFuY2UgDQogICB3
aXRoIGFsbCBwcm92aXNpb25zIG9mIFNlY3Rpb24gMTAgb2YgUkZDMjAyNi4gDQogICAgDQogICAg
DQogICBJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1lbnRzIG9mIHRoZSBJbnRlcm5l
dCBFbmdpbmVlcmluZyANCiAgIFRhc2sgRm9yY2UgKElFVEYpLCBpdHMgYXJlYXMsIGFuZCBpdHMg
d29ya2luZyBncm91cHMuICBOb3RlIHRoYXQgICAgICANCiAgIG90aGVyIGdyb3VwcyBtYXkgYWxz
byBkaXN0cmlidXRlIHdvcmtpbmcgZG9jdW1lbnRzIGFzIEludGVybmV0LQ0KICAgRHJhZnRzLiAN
CiAgICANCiAgIEludGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBh
IG1heGltdW0gb2Ygc2l4IA0KICAgbW9udGhzIGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQs
IG9yIG9ic29sZXRlZCBieSBvdGhlciBkb2N1bWVudHMgDQogICBhdCBhbnkgdGltZS4gIEl0IGlz
IGluYXBwcm9wcmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBhcyANCiAgIHJlZmVyZW5jZSBt
YXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4i
IA0KICAgIA0KICAgVGhlIGxpc3Qgb2YgY3VycmVudCBJbnRlcm5ldC1EcmFmdHMgY2FuIGJlIGFj
Y2Vzc2VkIGF0IA0KICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2lldGYvMWlkLWFic3RyYWN0
cy50eHQgDQogICBUaGUgbGlzdCBvZiBJbnRlcm5ldC1EcmFmdCBTaGFkb3cgRGlyZWN0b3JpZXMg
Y2FuIGJlIGFjY2Vzc2VkIGF0IA0KICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5o
dG1sLiANCiAgICANCkNvcHlyaWdodCBOb3RpY2UgDQogICAgDQogICBDb3B5cmlnaHQgKGMpIFRo
ZSBJbnRlcm5ldCBTb2NpZXR5ICgyMDAxKS4gQWxsIHJpZ2h0cyByZXNlcnZlZC4gDQogICAgDQpB
YnN0cmFjdCANCiAgICANCiAgIEFzIHBhcnQgb2YgdGhlIEludGVybmV0IE11bHRpbWVkaWEgQ29u
ZmVyZW5jaW5nIEFyY2hpdGVjdHVyZSBbM10sIA0KICAgY29uZmVyZW5jZSBjb3Vyc2UgY29udHJv
bCBkZWFscyB3aXRoIHRoZSBjb250cm9sIG9mIHJ1bm5pbmcgDQogICBjb25mZXJlbmNlcyBhZnRl
ciB0aGUgY3JlYXRpb24gb2YgdGhlIGluaXRpYWwgY29uZmVyZW5jZSBzdGF0ZSB3aXRoIA0KICAg
cmVzcGVjdCB0byB0aGUgbWVtYmVyc2hpcCBhbmQgYWNjZXNzIGNvbnRyb2wgZHVyaW5nIHJ1bnRp
bWUgb2YgdGhlIA0KICAgc2Vzc2lvbi4gVGhlIHNwZWN0cnVtIG9mIHNjZW5hcmlvcyByZWFjaGVz
IGZyb20gc21hbGwgbXVsdGlwYXJ0eSANCiAgIGdhdGhlcmluZ3MgdXAgdG8gbGFyZ2Ugc2NhbGVk
IG1lZXRpbmdzIHdpdGggYSBoaWdoIGZsdWN0dWF0aW9uIG9mIA0KICAgdXNlcpJzIG1lbWJlcnNo
aXAgYW5kIGFjdGl2aXR5LiANCiAgICANCiAgIFRoaXMgZG9jdW1lbnQgaWRlbnRpZmllcyB0aGUg
cHJvYmxlbSBhcmVhIHRvIGRlZmluZSB0aGUgc2NvcGUgb2YgYSANCiAgIGNvbmZlcmVuY2UgY291
cnNlIGNvbnRyb2wgd29ya2luZyBncm91cCBpbiB0aGUgSUVURi4gDQogDQogICAgIA0KVHJvc3Nl
biAgICAgICAgICAgICAgICAgRXhwaXJlcyBOb3ZlbWJlciAyMDAxICAgICAgICAgICAgICAgICAg
ICAgWzFdIA0MDQpJbnRlcm5ldCBEcmFmdCAgICAgQ291cnNlIENvbnRyb2wgUHJvYmxlbSBTdGF0
ZW1lbnQgICAgICAgICAgIE1heSAyMDAxIA0KICAgIA0KICAgIA0KVGFibGUgb2YgQ29udGVudHMg
DQogICAgDQogICAxLiBJbnRyb2R1Y3Rpb24uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4yIA0KICAgMi4gRGVmaW5pdGlvbiBvZiBUZXJtcy4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMyANCiAgIDMuIFNjb3BlLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjQgDQog
ICA0LiBQcm9ibGVtIFN0YXRlbWVudC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi40IA0KICAgNS4gQ29uZmVyZW5jaW5nIFNjZW5hcmlvcy4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uNSANCiAgIDUuMS4gIFNpbXBsZSBDb25mZXJlbmNp
bmcuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjUgDQogICA1LjEuMS4g
IEV4YW1wbGVzLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li42IA0KICAgNS4yLiAgRmxvb3IgQ29udHJvbGxlZCBDb25mZXJlbmNpbmcuLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uNiANCiAgIDUuMi4xLiAgRXhhbXBsZXMuLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjYgDQogICA1LjMuICBSaWNoIENvbmZl
cmVuY2luZy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi42IA0KICAg
NS4zLjEuICBFeGFtcGxlcy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uNyANCiAgIDUuNC4gIFN1bW1hcnkgb2YgQ2hhcmFjdGVyaXN0aWNzLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjcgDQogICA2LiBDb25mZXJlbmNlIENvdXJzZSBDb250
cm9sIE1vZGVscy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi45IA0KICAgNi4xLiAgTG9v
c2UgQ29uZmVyZW5jZSBDb3Vyc2UgQ29udHJvbC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
OSANCiAgIDYuMi4gIFRpZ2h0IENvbmZlcmVuY2UgQ291cnNlIENvbnRyb2wuLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLjkgDQogICA2LjMuICAnSmVsbHktbGlrZScgQ29uZmVyZW5jZSBDb3Vy
c2UgQ29udHJvbC4uLi4uLi4uLi4uLi4uLi4uLi4uLi45IA0KICAgNy4gRXhpc3RpbmcgU29sdXRp
b25zLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uOSANCiAgIDcu
MS4gIEguMzJ4IFByb3RvY29sIFN1aXRlLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uMTAgDQogICA3LjIuICBTSVAtYmFzZWQgU29sdXRpb25zLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLjEwIA0KICAgOC4gTmV4dCBTdGVwcy4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xMSANCiAgIDkuIFNlY3VyaXR5
IENvbnNpZGVyYXRpb25zLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTEg
DQogICAxMC4gIEFja25vd2xlZGdlbWVudHMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLjExIA0KICAgMTEuICBSZWZlcmVuY2VzLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xMSANCiAgICANCiAgICANCjEuICAgICBJbnRy
b2R1Y3Rpb24gDQogICAgDQogICBJbnRlcmFjdGl2ZSBjb2xsYWJvcmF0aXZlIHNjZW5hcmlvcyBs
aWtlIHJlbW90ZSBtZWV0aW5ncywgdmlydHVhbCANCiAgIGNsYXNzcm9vbXMsIG9yIHNoYXJpbmcg
YXBwbGljYXRpb25zIHZpYSB0aGUgSW50ZXJuZXQgaGF2ZSBiZWNvbWUgDQogICBtb3JlIGFuZCBt
b3JlIHBvcHVsYXIgaW4gdGhlIHBhc3QgdGVuIHllYXJzLiANCiAgICANCiAgIEFjY29yZGluZyB0
byBbM10sIHRoZSB0ZXJtICdjb25mZXJlbmNpbmcnIGlzIGNvbnNpZGVyZWQgaW4gdGhlIA0KICAg
cmVtYWluZGVyIG9mIHRoaXMgZG9jdW1lbnQgYXMgc3luY2hyb25vdXMsIHJlYWwtdGltZSBjb21t
dW5pY2F0aW9uLCANCiAgIHNwZWNpZmljYWxseSBpbmNsdWRpbmcgYXVkaW8gYW5kIHZpZGVvIG1l
ZGlhIGJ1dCBhbHNvIHNoYXJlZCBkYXRhIA0KICAgbWVkaWEgc3VjaCBhcyB3aGl0ZWJvYXJkcywg
YW1vbmcgYSBzZXQgb2YgbWVtYmVycy4gU2V2ZXJhbCwgcHJvYmFibHkgDQogICBpbmRlcGVuZGVu
dGx5IGltcGxlbWVudGVkLCBhZ2VudHMgZm9yIG1lZGlhIGhhbmRsaW5nIGFuZCBjb250cm9sIA0K
ICAgcHVycG9zZXMgaGF2ZSB0byBiZSBjb29yZGluYXRlZCBhbmQgc3luY2hyb25pemVkIGR1cmlu
ZyBydW50aW1lIG9mIA0KICAgdGhlIGNvbmZlcmVuY2UsIHJlZmVycmVkIHRvIGFzICdjb25mZXJl
bmNlIGNvdXJzZSBjb250cm9sJyBpbiB0aGUgDQogICBmb2xsb3dpbmcsIGFmdGVyIGNyZWF0aW5n
IHRoZSBpbml0aWFsIGNvbmZlcmVuY2Ugc3RhdGUgYXMgcGFydCBvZiANCiAgIHRoZSBjb25mZXJl
bmNpbmcgc2V0dXAgZnVuY3Rpb25hbGl0eS4gVGhlIHByb3ZpZGVkIGZ1bmN0aW9uYWxpdHkgDQog
ICB3aXRoIHJlc3BlY3QgdG8gY29uZmVyZW5jZSBjb3Vyc2UgY29udHJvbCB1c3VhbGx5IGRlcGVu
ZHMgb24gdGhlIA0KICAgY29uc2lkZXJlZCBzY2VuYXJpbyBpbiB3aGljaCBpdCBpcyBuZWVkZWQu
ICANCiAgICANCiAgIEluIHRoZSBmb2xsb3dpbmcsIHRoZSBzY29wZSBvZiBjb25mZXJlbmNpbmcg
Y291cnNlIGNvbnRyb2wgYXMgd2VsbCANCiAgIGFzIGEgcHJvYmxlbSBzdGF0ZW1lbnQgd2lsbCBi
ZSBwaW5wb2ludGVkLiBGdXJ0aGVybW9yZSwgc2NlbmFyaW9zIA0KICAgZm9yIG11bHRpbWVkaWEg
Y29uZmVyZW5jaW5nIGluIHRoZSBJbnRlcm5ldCBhcmUgY2F0ZWdvcml6ZWQsIA0KICAgcmVhY2hp
bmcgZnJvbSBzbWFsbCBjbG9zZWQgbWVldGluZ3MgdG8gbGFyZ2UgcGxlbmFyeSBzZXNzaW9ucyB3
aXRoIA0KICAgICANClRyb3NzZW4gICAgICAgICAgICAgICAgIEV4cGlyZXMgTm92ZW1iZXIgMjAw
MSAgICAgICAgICAgICAgICAgICAgIFsyXSANDA0KSW50ZXJuZXQgRHJhZnQgICAgIENvdXJzZSBD
b250cm9sIFByb2JsZW0gU3RhdGVtZW50ICAgICAgICAgICBNYXkgMjAwMSANCiAgICANCiAgICAN
CiAgIGhpZ2ggZmx1Y3R1YXRpb25zIHJlZ2FyZGluZyB0aGUgcGFydGljaXBhbnSScyBhY3Rpdml0
eSBhbmQgDQogICBpbnRlcmVzdHMuIFNpbmNlIHRoZSBmb2N1cyBvZiB0aGUgZG9jdW1lbnQgaXMg
b24gY29udHJvbCBpc3N1ZXMgaW4gDQogICBjb25mZXJlbmNpbmcsIGRhdGEgZGVsaXZlcnkgYXNw
ZWN0cyBhcmUgbGVmdCBvdXQgb2YgY29uc2lkZXJhdGlvbi4gDQogICAgDQogICBUaGUgc2NlbmFy
aW8gZmluZGluZ3MgYXJlIHRoZW4gdXNlZCB0byBkZWZpbmUgbW9kZWxzIGZvciBjb25mZXJlbmNl
IA0KICAgY291cnNlIGNvbnRyb2wgcHJvdmlzaW9uLiANCiAgICANCiAgIE1vcmVvdmVyLCBjdXJy
ZW50IGNvbmZlcmVuY2luZyBzb2x1dGlvbnMgYXJlIGJyaWVmbHkgZXZhbHVhdGVkIA0KICAgY29u
Y2VybmluZyB0aGVpciBzaG9ydGNvbWluZ3MgaW4gY29uZmVyZW5jZSBjb3Vyc2UgY29udHJvbCAN
CiAgIGZ1bmN0aW9uYWxpdHkuIEZpbmFsbHksIG5leHQgc3RlcHMgZm9yIGNvbmZlcmVuY2UgY291
cnNlIGNvbnRyb2wgDQogICBlZmZvcnRzIHdpbGwgYmUgcHJlc2VudGVkLiANCiAgICANCjIuICAg
ICBEZWZpbml0aW9uIG9mIFRlcm1zIA0KICAgIA0KICAgbyBBcHBsaWNhdGlvbiBzZXNzaW9uIChB
UyksIFNlc3Npb24gDQogICAgIFRoZSBzZXQgb2YgbWVkaWEgYWdlbnRzL2FwcGxpY2F0aW9ucyB0
aGF0IGFjdCBhcyBwZWVycyB0byBlYWNoICANCiAgICAgb3RoZXIgd2l0aGluIGEgY29uZmVyZW5j
ZS4gIEZvciByZWFsLXRpbWUgZGF0YSwgdGhpcyBnZW5lcmFsbHkgIA0KICAgICB3aWxsIGJlIGFu
IFJUUCBzZXNzaW9uOyBmb3Igb3RoZXIgYXBwbGljYXRpb24gcHJvdG9jb2xzLCBvdGhlciAgDQog
ICAgIGhvcml6b250YWwgcHJvdG9jb2xzIG1heSBkZWZpbmUgdGhlaXIgb3duIHR5cGUgb2Ygc2Vz
c2lvbiBjb25jZXB0LiAgDQogICAgDQogICBvIFBhcnRpY2lwYW50IA0KICAgICBBIGh1bWFuIGJl
aW5nIHRoYXQgdGFrZXMgcGFydCBpbiBhIGNvbmZlcmVuY2UsIGVpdGhlciBhY3RpdmVseSBvciAg
DQogICAgIHBhc3NpdmVseSBsaXN0ZW5pbmcuIA0KICAgIA0KICAgbyBBY3RpdmUgUGFydGljaXBh
bnQgDQogICAgIEEgcGFydGljaXBhbnQgb2YgYSBjb25mZXJlbmNlIGJlY29taW5nIHNlbmRlciBv
ZiBtZWRpYSBpbmZvcm1hdGlvbiAgDQogICAgIGR1cmluZyBsaWZldGltZSBvZiB0aGUgY29uZmVy
ZW5jZS4gDQogICAgDQogICBvIFBhc3NpdmUgUGFydGljaXBhbnQgDQogICAgIEEgcGFydGljaXBh
bnQgb2YgYSBjb25mZXJlbmNlIHBhc3NpdmVseSByZWNlaXZpbmcgdGhlIG1lZGlhICANCiAgICAg
aW5mb3JtYXRpb24gd2l0aG91dCBiZWNvbWluZyBzZW5kZXIgb2YgbWVkaWEgaW5mb3JtYXRpb24g
IA0KICAgICBkdXJpbmcgbGlmZXRpbWUgb2YgdGhlIGNvbmZlcmVuY2UuIA0KICAgIA0KICAgbyBN
ZW1iZXIgDQogICAgIFRoZSBzeXN0ZW0sIGluY2x1ZGluZyBzb2Z0d2FyZSBhbmQgaGFyZHdhcmUs
IHRoYXQgdGFrZXMgcGFydCBpbiBhICAgIA0KICAgICBjb21wdXRlciBjb25mZXJlbmNlLCByZXBy
ZXNlbnRpbmcgYSBzaW5nbGUgcGFydGljaXBhbnQuIA0KICAgIA0KICAgbyBQcm9maWxlIA0KICAg
ICBBbiBpbml0aWFsIGRlc2NyaXB0aW9uIG9mIHRoZSBjb25mZXJlbmNlLCBpbmNsdWRpbmcgYXNz
aWdubWVudCBvZiAgDQogICAgIHJvbGVzIHRvIHBhcnRpY3VsYXIgbWVtYmVycywgdGltZSBsaW1p
dHMgZm9yIHNwZWFrZXJzLCBhdHRyaWJ1dGVzICANCiAgICAgb2YgdGhlIGNvbmZlcmVuY2UgKG9w
ZW4vY2xvc2UsIGNvbmR1Y3RlZC9hbmFyY2hpYywgZXRjKS4gDQogICAgDQogICBvIENvbmZlcmVu
Y2UgU2V0dXAgYW5kIERpc2NvdmVyeSANCiAgICAgQWNjb3JkaW5nIHRvIFszXSwgYXNwZWN0cyBm
b3Igc2V0dGluZyB1cCBhbiBpbml0aWFsIGNvbmZlcmVuY2UgIA0KICAgICBTdGF0ZSBpbiBwYXJ0
aWNpcGF0aW5nIG1lbWJlcnMsIGluY2x1ZGluZyB0aGUgZXhjaGFuZ2Ugb2YgbWVkaWEgIA0KICAg
ICBhbmQgY2FwYWJpbGl0aWVzIGluZm9ybWF0aW9uIGFtb25nIHRoZSBzZXQgb2YgcGFydGljaXBh
bnRzLCBhcmUgIA0KICAgICBiZWluZyBhZGRyZXNzZWQgYnkgc2V0dXAgYW5kIGRpc2NvdmVyeSBm
dW5jdGlvbmFsaXR5LiANCiAgICANCiAgIG8gQ29uZmVyZW5jZSBDb3Vyc2UgQ29udHJvbCANCiAg
ICAgQWNjb3JkaW5nIHRvIFszXSwgYXNwZWN0cyB0byBjb250cm9sIHRoZSBjb25mZXJlbmNlIGR1
cmluZyBydW50aW1lICANCiAgICAgb2YgdGhlIGV2ZW50IGFyZSBiZWluZyBhZGRyZXNzZWQgYnkg
Y29uZmVyZW5jZSBjb3Vyc2UgY29udHJvbC4gDQogICAgDQogICAgIA0KVHJvc3NlbiAgICAgICAg
ICAgICAgICAgRXhwaXJlcyBOb3ZlbWJlciAyMDAxICAgICAgICAgICAgICAgICAgICAgWzNdIA0M
DQpJbnRlcm5ldCBEcmFmdCAgICAgQ291cnNlIENvbnRyb2wgUHJvYmxlbSBTdGF0ZW1lbnQgICAg
ICAgICAgIE1heSAyMDAxIA0KICAgIA0KICAgIA0KMy4gICAgIFNjb3BlIA0KICAgIA0KICAgVGhl
IHNjb3BlIG9mIGNvbmZlcmVuY2UgY291cnNlIGNvbnRyb2wgZnVuY3Rpb25hbGl0eSB3aWxsIGJl
IA0KICAgZGV2ZWxvcGVkIGFzIHBhcnQgb2YgdGhlIHNvbHV0aW9uIHNwYWNlLiBQb3NzaWJsZSBm
dW5jdGlvbmFsaXR5IA0KICAgaW5jbHVkZXM6IA0KICAgIA0KICAgbyAnY29uZmVyZW5jZSBjb250
ZXh0IGFkbWluaXN0cmF0aW9uJywgcHJvdmlkaW5nIG1lbWJlcnNoaXAgIA0KICAgICBhbmQgYXBw
bGljYXRpb24vc2Vzc2lvbiBpbmZvcm1hdGlvbiBhZG1pbmlzdHJhdGlvbiANCiAgIG8gJ21lbWJl
cnNoaXAgZW5mb3JjZW1lbnQnLCBwcm92aWRpbmcgbWVhbnMgdG8gZW5mb3JjZSBzcGVjaWZpYyAg
DQogICAgIGNvbmZlcmVuY2UgbWVtYmVyc2hpcCANCiAgIG8gJ2Zsb29yIGNvbnRyb2wnLCBwcm92
aWRpbmcgbWVhbnMgdG8gbWFwIHNvY2lhbCBwcm90b2NvbHMgb250byAgDQogICAgIGRpc3RyaWJ1
dGVkIGVudmlyb25tZW50cy4gSG93ZXZlciwgdGhlIHNlbWFudGljcyBvZiBzcGVjaWZpYyAgDQog
ICAgIHNvY2lhbCBwcm90b2NvbHMgaXMgbm90IHdpdGhpbiB0aGUgc2NvcGUgb2YgdGhlIHBvc3Np
YmxlICANCiAgICAgY29uZmVyZW5jZSBjb3Vyc2UgY29udHJvbCBzb2x1dGlvbi4gDQogICBvICdh
Y3RpdmUvcGFzc2l2ZSBtZW1iZXIgc3VwcG9ydCcsIGFsbG93aW5nIGZvciBkaWZmZXJlbnQgcG9s
aWNpZXMgIA0KICAgICB3aXRoIHJlc3BlY3QgdG8gbWVtYmVyc2hpcCBhbmQgZmxvb3IgY29udHJv
bC4gVGhpcyBpbmNsdWRlcyAgDQogICAgIGNoYW5nZXMgZnJvbSBhY3RpdmUgdG8gcGFzc2l2ZSBh
bmQgdmljZSB2ZXJzYSwgZWl0aGVyIGltcGxpY2l0bHkgIA0KICAgICBvciBleHBsaWNpdGx5LiAN
CiAgIG8gJ2NhcGFiaWxpdGllcyByZS1uZWdvdGlhdGlvbicsIGFsbG93aW5nIGZvciBjaGFuZ2Vz
IGluICANCiAgICAgdGhlIGluaXRpYWwgY2FwYWJpbGl0aWVzIHNldCBvZiBwYXJ0aWNpcGFudHMg
ZHVyaW5nIHJ1bnRpbWUgb2YgdGhlICANCiAgICAgY29uZmVyZW5jZS4gDQogICAgDQogICBUaGlz
IGxpc3QgZG9lcyBub3QgY2xhaW0gdG8gYmUgZXhoYXVzdGl2ZS4gSG93ZXZlciwgaXQgcG9pbnRz
IGluIHRoZSANCiAgIGRpcmVjdGlvbiBvZiBwcm92aWRlZCBmdW5jdGlvbmFsaXR5IGZvciBjb25m
ZXJlbmNlIGNvdXJzZSBjb250cm9sIA0KICAgc29sdXRpb25zLiANCiAgICANCjQuICAgICBQcm9i
bGVtIFN0YXRlbWVudCANCiAgICANCiAgIFRoZXJlIGFyZSBtYW55IGFwcHJvYWNoZXMgaW4gdGhl
IHJlc2VhcmNoIGNvbW11bml0eSB0byByZWFsaXplIA0KICAgY29uZmVyZW5jZSBjb3Vyc2UgY29u
dHJvbCBhcyBwYXJ0IG9mIGEgY29uZmVyZW5jaW5nIGFyY2hpdGVjdHVyZS4gDQogICBBbHNvIGlu
IHN0YW5kYXJkaXphdGlvbiBib2RpZXMgKHN1Y2ggYXMgSC4zMjMgWzddIG9yIFNDQ1AgWzFdKSwg
DQogICBjb25mZXJlbmNlIGNvdXJzZSBjb250cm9sIGhhcyBiZWVuIGFkZHJlc3NlZC4gSG93ZXZl
ciwgbm9uZSBvZiB0aGVzZSANCiAgIGFwcHJvYWNoZXMgb2ZmZXJzIGEgdW5pZmllZCBhbmQgZmxl
eGlibGUgc29sdXRpb24gZm9yIGNvbmZlcmVuY2UgDQogICBjb3Vyc2UgY29udHJvbCB0byBjb3Zl
ciB0aGUgc3BlY3RydW0gb2Ygc2NlbmFyaW9zIG91dGxpbmVkIGluIA0KICAgU2VjdGlvbiA1LiAN
CiAgICANCiAgIFNwZWNpZmljYWxseSwgYSBjb25mZXJlbmNlIGNvdXJzZSBjb250cm9sIHNvbHV0
aW9uIHNob3VsZCANCiAgICANCiAgIG8gZml0IGludG8gdGhlIGFscmVhZHkgZGVmaW5lZCBjb25m
ZXJlbmNlIGNvbnRyb2wgYXJjaGl0ZWN0dXJlIGFuZCAgDQogICAgIGxldmVyYWdlIHRoZSBleGlz
dGluZyBzdWl0ZSBvZiBtZWNoYW5pc21zIGFuZCBwcm90b2NvbHMsIHN1Y2ggYXMgIA0KICAgICAq
IGNvbmZlcmVuY2UgZGVzY3JpcHRpb24sIGkuZS4sIFNEUCBbNF0gb3IgZnV0dXJlIHZlcnNpb25z
IChTREctbmcgIA0KICAgICAgIFs5XSksIGFuZCBpbml0aWF0aW9uLCBpLmUuLCBTSVAgWzVdIA0K
ICAgICAqIGxvY2FsIGNvb3JkaW5hdGlvbiwgaS5lLiwgTUJVUyBbMTBdIA0KICAgICAqIHRyYW5z
cG9ydCBsYXllciBwcm90b2NvbHMsIHN1Y2ggYXMgZm9yIHJlbGlhYmxlIG11bHRpY2FzdCwgcmVh
bC0gDQogICAgICAgdGltZSB0cmFuc2Zlciwgb3Igc2ltcGxlIHVuaWNhc3QgdHJhbnNtaXNzaW9u
IA0KICAgICAqIHNlY3VyaXR5IGNvbXBvbmVudHMsIHN1Y2ggYXMgZ3JvdXAga2V5IHNvbHV0aW9u
cyANCiAgIG8gcHJvdmlkZSBhIGZsZXhpYmxlIHNvbHV0aW9uLCBhbGxvd2luZyBmb3IgYSB2YXJp
ZXR5IG9mIHNjZW5hcmlvcyAgDQogICAgIChzZWUgU2VjdGlvbiA1KSBhbmQgY2hhcmFjdGVyaXN0
aWNzIHRvIGJlIHBsdWdnZWQgaW4gdGhlIHN5c3RlbS4gIA0KICAgIA0KICAgRm9yIHRoYXQsIGEg
YnVpbGRpbmcgYmxvY2sgYXBwcm9hY2ggd291bGQgYWxsb3cgdGhlIHByb3Zpc2lvbiBvZiANCiAg
IHN0YW5kYXJkaXplZCBpbnRlcmZhY2VzIHRvIHRoZSBkZXNpcmVkIGNvbW1vbiBmdW5jdGlvbmFs
aXR5LiBXaXRoIA0KICAgdGhhdCwgc3BlY2lmaWMgc2NlbmFyaW8tdGFpbG9yZWQgaW5zdGFudGlh
dGlvbnMgZm9yIGNlcnRhaW4gDQogICBmdW5jdGlvbmFsaXR5LCByZXByZXNlbnRlZCBieSBhIGJ1
aWxkaW5nIGJsb2NrLCBhcmUgZW5hYmxlZCANCiAgICAgDQpUcm9zc2VuICAgICAgICAgICAgICAg
ICBFeHBpcmVzIE5vdmVtYmVyIDIwMDEgICAgICAgICAgICAgICAgICAgICBbNF0gDQwNCkludGVy
bmV0IERyYWZ0ICAgICBDb3Vyc2UgQ29udHJvbCBQcm9ibGVtIFN0YXRlbWVudCAgICAgICAgICAg
TWF5IDIwMDEgDQogICAgDQogICAgDQogICBwcmVzZXJ2aW5nIHRoZSBjb21tb24gdmlldyBvZiB0
aGUgY29uZmVyZW5jZSBjb3Vyc2UgY29udHJvbCANCiAgIGZ1bmN0aW9uYWxpdHkuIA0KICAgIA0K
ICAgIA0KNS4gICAgIENvbmZlcmVuY2luZyBTY2VuYXJpb3MgDQogICAgDQogICBUaGlzIHNlY3Rp
b24gaW5mb3JtYWxseSBvdXRsaW5lcyBzY2VuYXJpbyBjYXRlZ29yaWVzIGZvciBtdWx0aW1lZGlh
IA0KICAgY29uZmVyZW5jaW5nIGluIHRoZSBJbnRlcm5ldC4gIA0KICAgIA0KICAgVGhlIGNvbmZl
cmVuY2luZyBzY2VuYXJpb3MgYXJlIGNhdGVnb3JpemVkIGluIHRocmVlIHNlY3Rpb25zLiBGb3Ig
DQogICBlYWNoIGNhdGVnb3J5LCB0eXBpY2FsIGNoYXJhY3RlcmlzdGljcyBhcmUgb3V0bGluZWQs
IGFuZCBleGFtcGxlcyANCiAgIGFyZSBnaXZlbi4gRmluYWxseSwgYSB0YWJsZS13aXNlIG92ZXJ2
aWV3IGlzIGRlcml2ZWQgZnJvbSB0aGUgbW9yZSANCiAgIGluZm9ybWFsIGRlc2NyaXB0aW9uIHBp
bnBvaW50aW5nIHRoZSB2ZXJ5IGZ1bmN0aW9uYWxpdHkgcmVxdWlyZWQgZm9yIA0KICAgdGhlIHNw
ZWNpZmljIHNjZW5hcmlvcy4gVGhpcyB0YWJsZS13aXNlIGRlc2NyaXB0aW9uIHdpbGwgYmUgdXNl
ZCBpbiANCiAgIFNlY3Rpb24gNSB0byBkaXNjdXNzIGNvbmZlcmVuY2UgY291cnNlIGNvbnRyb2wg
bW9kZWxzLiANCiAgICANCiAgIEl0IGlzIHdvcnRoIG1lbnRpb25pbmcgdGhhdCBzaW1wbGUgc3Ry
ZWFtaW5nIGlzIG5vdCBjb25zaWRlcmVkIGluIA0KICAgdGhlIGZvbGxvd2luZyBkdWUgdG8gaXRz
IGxhY2sgb2YgY29uZmVyZW5jZSBjb3Vyc2UgY29udHJvbCANCiAgIGZ1bmN0aW9uYWxpdHkuIEhv
d2V2ZXIsIGl0IG1pZ2h0IGJlIHVzZWQgdG8gcmVhbGl6ZSB2ZXJ5IHNpbXBsZSANCiAgIGNvbmZl
cmVuY2luZyBzY2VuYXJpb3Mgc3VjaCBhcyBJbnRlcm5ldCBsZWN0dXJlcywgd2hlcmUgZGF0YSBp
cyANCiAgIHNpbXBseSBzZW50IHRvIGEgc2V0IG9mIHJlY2VpdmVycyB3aXRob3V0IGZlZWRiYWNr
IG9yIGludGVyYWN0aW9uLiAgDQogICAgDQo1LjEuICAgU2ltcGxlIENvbmZlcmVuY2luZyANCiAg
ICANCiAgICdTaW1wbGUgQ29uZmVyZW5jaW5nJyByZWZsZWN0cyB0aGUgc2ltcGxlc3QgZm9ybSBv
ZiBjb25mZXJlbmNpbmcgDQogICB3aXRoIGEgY2hhbmdlIG9mIHRoZSBzZW5kZXIvcmVjZWl2ZXIg
cmVsYXRpb24gYmFzZWQgb24gY2VydGFpbiANCiAgICdzb2NpYWwgcnVsZXMnIGR1cmluZyB0aGUg
bGlmZXRpbWUgb2YgdGhlIGNvbmZlcmVuY2UuIA0KICAgIA0KICAgQ29uZmVyZW5jZXMgb2YgdGhp
cyB0eXBlIG1pZ2h0IGJlIGFubm91bmNlZCBiZWZvcmVoYW5kLCBpbmNsdWRpbmcgDQogICB0aGUg
Y29uZmVyZW5jZZJzIHByb2ZpbGUgaW5mb3JtYXRpb24sIG9yIHRoZXkgdGFrZSBwbGFjZSBhcyBh
ZC1ob2MgDQogICBtZWV0aW5ncy4gIA0KICAgIA0KICAgVGhlIGdyb3VwIG9mIHBhcnRpY2lwYW50
cyBtaWdodCBiZSB3ZWxsLWtub3duLCBpZiBhbm5vdW5jZWQsIG9yIGJlIA0KICAgYnVpbHQgYnkg
aW52aXRhdGlvbiBvciByZXF1ZXN0LiBGb3IgdGhhdCwgc2V2ZXJhbCBpbml0aWF0aW9uIG1vZGVs
cyANCiAgIG1pZ2h0IGJlIHJlYWxpemVkIChzZWUgYWxzbyBbMTFdKSwgd2hpY2ggcmVxdWlyZXMg
YXBwcm9wcmlhdGUgDQogICBpbml0aWF0aW9uIGZ1bmN0aW9uYWxpdHkgaW5jbHVkaW5nIGF1dGhl
bnRpY2F0aW9uIGFuZCBhdXRob3JpemF0aW9uIA0KICAgbWVhbnMgZm9yIHJlc3RyaWN0ZWQgYWNj
ZXNzIHRvIHRoZSBjb25mZXJlbmNlLiAgDQogICAgDQogICBGbG9vciBjb250cm9sIGZ1bmN0aW9u
YWxpdHksIGUuZy4sIHRvIHJlYWxpemUgY29uZHVjdGVkIG1lZXRpbmcgDQogICBmdW5jdGlvbmFs
aXR5LCBpcyBub3QgcHJvdmlkZWQgaW4gdGhpcyBjYXRlZ29yeS4gRHVlIHRvIHRoaXMgbGFjayBv
ZiANCiAgIG1lZGlhdGlvbiBjb25jZXJuaW5nIHRoZSBhY2Nlc3Mgb24gdGhlIGNvbW1vbiBtZWRp
YSByZXNvdXJjZSwgdGhlIA0KICAgbGV2ZWwgb2YgaW50ZXJhY3Rpdml0eSBpcyB1c3VhbGx5IGxp
bWl0ZWQsIGV2ZW4gaWYgc2NhbGFibGUgDQogICBtdWx0aWNhc3QgdHJhbnNmZXIgaXMgdXNlZC4g
IA0KICAgIA0KICAgVXN1YWxseSwgdGhlIGluaXRpYWwgc2V0IG9mIGNhcGFiaWxpdGllcyBpcyBu
b3QgY2hhbmdlZCwgaS5lLiwgcmUtDQogICBuZWdvdGlhdGVkLCBkdXJpbmcgcnVudGltZSBvZiB0
aGUgY29uZmVyZW5jZS4gSG93ZXZlciwgc29tZSBzaW1wbGUgDQogICBmb3JtIG9mIHJlLW5lZ290
aWF0aW9uIGNvdWxkIGJlIHByb3ZpZGVkLiANCiAgICANCiAgIEFsdGhvdWdoIHRoZSBudW1iZXIg
b2YgcGFydGljaXBhbnRzIGNhbiBlYXNpbHkgcmVhY2ggc2V2ZXJhbCANCiAgIHRob3VzYW5kcyBv
ciBldmVuIG1vcmUsIHdoZW4gdXNpbmcgbXVsdGljYXN0IHRyYW5zZmVyIGNhcGFiaWxpdGllcywg
DQogICBpdCBpcyBleHBlY3RlZCB0aGF0IHRoZSByZXF1aXJlbWVudHMgZm9yIHByZWNpc2UgbWVt
YmVyc2hpcCANCiAgIGluZm9ybWF0aW9uIGFyZSBsZXNzIHN0cmluZ2VudCBpbiBsYXJnZXIgc2Nh
bGVkIGNvbmZlcmVuY2VzLiANCiAgICANCiAgICAgDQpUcm9zc2VuICAgICAgICAgICAgICAgICBF
eHBpcmVzIE5vdmVtYmVyIDIwMDEgICAgICAgICAgICAgICAgICAgICBbNV0gDQwNCkludGVybmV0
IERyYWZ0ICAgICBDb3Vyc2UgQ29udHJvbCBQcm9ibGVtIFN0YXRlbWVudCAgICAgICAgICAgTWF5
IDIwMDEgDQogICAgDQogICAgDQo1LjEuMS4gRXhhbXBsZXMgDQogICAgDQogICBFeGFtcGxlcyBm
b3Igc2ltcGxlIGNvbmZlcmVuY2luZyBpbmNsdWRlIGFkLWhvYyBvciBwcmUtcGxhbm5lZCBzbWFs
bCANCiAgIGdyb3VwIG1lZXRpbmdzLCByaWNoIGNhbGxzLCBJbnRlcm5ldCBsZWN0dXJlcywgdGVs
ZS13b3JraW5nIGluIGEgDQogICB0ZWFtLiBNb3N0IG9mIHRoZSBjdXJyZW50IE1Cb25lIFsyXSBz
ZXNzaW9ucyBhcmUgdHlwaWNhbCBleGFtcGxlcyANCiAgIGZvciBzaW1wbGUgY29uZmVyZW5jaW5n
LiANCiAgICANCjUuMi4gICBGbG9vciBDb250cm9sbGVkIENvbmZlcmVuY2luZyANCiAgICANCiAg
IFNjZW5hcmlvcyBvZiB0aGlzIGNhdGVnb3J5IGVucmljaCB0aGUgc2ltcGxlIGNvbmZlcmVuY2lu
ZyANCiAgIGZ1bmN0aW9uYWxpdHkgb2Ygc2VjdGlvbiA1LjEuIGJ5IHByb3ZpZGluZyBmbG9vciBj
b250cm9sIGZhY2lsaXRpZXMgDQogICB0byBjb250cm9sIHRoZSBhY2Nlc3Mgb24gZGlzdHJpYnV0
ZWQgcmVzb3VyY2VzLiBBbW9uZyBvdGhlcnMsIHRoZXNlIA0KICAgZGlzdHJpYnV0ZWQgcmVzb3Vy
Y2VzIG1pZ2h0IHJlZmxlY3QgdGhlIGNvbW1vbmx5IHVzZWQgYXVkaW92aXN1YWwgDQogICBjaGFu
bmVsIHdpdGhpbiB0aGUgY29uZmVyZW5jZSBidXQgYWxzbyB0aGUgY29udGVudCBvZiBhIHNoYXJl
ZCANCiAgIHdoaXRlYm9hcmQsIG9yIGEgc2hhcmVkLCBsb2NhbGx5IGhvc3RlZCBhcHBsaWNhdGlv
bi4gVGhlIGZsb29yIA0KICAgY29udHJvbCBzZW1hbnRpY3MgYXJlIHVzdWFsbHkga25vd24gYmVm
b3JlaGFuZCwgb3IgdGhleSBtaWdodCBiZSANCiAgIGRpc3RyaWJ1dGVkIHVzaW5nIHRoZSBjb25m
ZXJlbmNlIHByb2ZpbGUgaW5mb3JtYXRpb24uIFRoZSANCiAgIHJlYWxpemF0aW9uIG9mIHRoZSBm
bG9vciBjb250cm9sIHNlbWFudGljcyBpcyB1c3VhbGx5IGhpZ2hseSANCiAgIGFwcGxpY2F0aW9u
LXNwZWNpZmljLiANCiAgICANCiAgIEZvciBpbnN0YW5jZSwgZmxvb3IgY29udHJvbGxlZCBjb25m
ZXJlbmNpbmcgbWlnaHQgYWxsb3cgJ2NvbmR1Y3RlZCANCiAgIG1lZXRpbmdzJywgZW5hYmxpbmcg
dGhlIGNvbmR1Y3RvciBvZiBhIGNvbmZlcmVuY2UgZm9yIGluc3RhbmNlIHRvIA0KICAgZWplY3Qg
cGFydGljaXBhbnRzIGZyb20gYSBjb25mZXJlbmNlIG9yIHRvIGRlbnkgYWNjZXNzIHRvIHRoZSAN
CiAgIGNvbmZlcmVuY2UuIEhvd2V2ZXIsIGluIGFkZGl0aW9uIHRvIHRoZSByZWFsaXphdGlvbiBv
ZiB0aGUgc29jaWFsIA0KICAgcnVsZXMgYnkgbWVhbnMgb2YgZmxvb3IgY29udHJvbCwgYXBwcm9w
cmlhdGUgZnVuY3Rpb25hbGl0eSB0byANCiAgIGVuZm9yY2UgdGhlbSBvbiBkYXRhIGxldmVsIGlz
IHJlcXVpcmVkIGJ5IG1lYW5zIG9mIGV4Y2x1ZGluZyANCiAgIHJlY2VpdmVyIHNldHMgZnJvbSBy
ZWNlcHRpb24uIA0KICAgIA0KICAgQ2FwYWJpbGl0aWVzIHJlLW5lZ290aWF0aW9uIGlzIHVzdWFs
bHkgcHJvdmlkZWQgaW4gdGhlc2Ugc2NlbmFyaW9zLCANCiAgIHdoaWNoIG1pZ2h0IGFsc28gYmUg
dGllZCB0byB0aGUgaW1wbGVtZW50ZWQgZmxvb3IgY29udHJvbCBwb2xpY3kgb2YgDQogICB0aGUg
c3BlY2lmaWMgc2NlbmFyaW8uIA0KICAgIA0KICAgSW4gZmxvb3IgY29udHJvbGxlZCBjb25mZXJl
bmNlcywgdGhlcmUgaXMgYW4gZXhhY3Qga25vd2xlZGdlIG9mIHRoZSANCiAgIGN1cnJlbnQgbWVt
YmVyc2hpcCBpbmZvcm1hdGlvbiBvZiB0aGUgcGFydGljaXBhbnRzLiBVc3VhbGx5LCB0aGUgDQog
ICBpbXBsZW1lbnRhdGlvbiBvZiB0aGUgZmxvb3IgY29udHJvbCByZXN0cmljdHMgdGhlIHNjYWxh
YmlsaXR5IG9mIA0KICAgdGhpcyB0eXBlIG9mIGNvbmZlcmVuY2VzIHRvIGEgZmV3IHRlbnMuIEhv
d2V2ZXIsIGFwcHJvYWNoZXMgYXMgDQogICBwcm9wb3NlZCBpbiBbMTNdLCBtaWdodCBiZSB1c2Vk
IGluIHNwZWNpZmljIHNjZW5hcmlvcyB0byBpbXByb3ZlIHRoZSANCiAgIHNjYWxhYmlsaXR5LiAN
CiAgICANCjUuMi4xLiBFeGFtcGxlcyANCiAgICANCiAgIEV4YW1wbGVzIGZvciBmbG9vciBjb250
cm9sbGVkIGNvbmZlcmVuY2VzIGluY2x1ZGUgc2NlbmFyaW9zIHdpdGggdGhlIA0KICAgbmVlZCB0
byByZWFsaXplIHNvY2lhbCBydWxlcyBvciBhY2Nlc3MgY29udHJvbCBvbiBzaGFyZWQgcmVzb3Vy
Y2VzLCANCiAgIHN1Y2ggYXMgY29uZHVjdGVkIG1lZXRpbmdzLCBhcHBsaWNhdGlvbiBzaGFyaW5n
IHNlc3Npb25zLCBkaXN0YW5jZSANCiAgIGxlYXJuaW5nIGluY2x1ZGluZyBkZW1vbnN0cmF0aW9u
IG9mIHNoYXJlZCBpbmZvcm1hdGlvbiwgdGVsZS13b3JraW5nIA0KICAgd2l0aCBjb21tb24gcmVz
b3VyY2VzIHRvIHNoYXJlLiANCiAgICANCjUuMy4gICBSaWNoIENvbmZlcmVuY2luZyANCiAgICAN
CiAgIEEgJ3JpY2ggY29uZmVyZW5jaW5nJyBldmVudCwgd2hpY2ggaXMgZ29pbmcgdG8gaGFwcGVu
LCBtaWdodCBiZSANCiAgIGFubm91bmNlZCBiZWZvcmVoYW5kIGJ1dCBhbiBhZC1ob2MgZXN0YWJs
aXNobWVudCBtaWdodCBhbHNvIGJlIA0KICAgY29uc2lkZXJlZCwgc3VjaCBhcyBhICdyYW5kb21s
eSBnYXRoZXJpbmcgYSBjcm93ZCBhcm91bmQgYW4gDQogICAgIA0KVHJvc3NlbiAgICAgICAgICAg
ICAgICAgRXhwaXJlcyBOb3ZlbWJlciAyMDAxICAgICAgICAgICAgICAgICAgICAgWzZdIA0MDQpJ
bnRlcm5ldCBEcmFmdCAgICAgQ291cnNlIENvbnRyb2wgUHJvYmxlbSBTdGF0ZW1lbnQgICAgICAg
ICAgIE1heSAyMDAxIA0KICAgIA0KICAgIA0KICAgYXR0cmFjdGlvbicuIEF1dGhlbnRpY2F0aW9u
IGFuZCBhdXRob3JpemF0aW9uIG1lYW5zIG1pZ2h0IGJlIHVzZWQgDQogICBmb3IgcmVzdHJpY3Rl
ZCBhY2Nlc3MgdG8gdGhlIGV2ZW50LiANCiAgICANCiAgIFVzdWFsbHksIHRoZXJlIGlzIGEgKHNt
YWxsKSB3ZWxsLWtub3duIGdyb3VwIG9mIGFjdGl2ZSBwYXJ0aWNpcGFudHMsIA0KICAgaS5lLiwg
ZXhhY3QgbWVtYmVyc2hpcCBpbmZvcm1hdGlvbiBpcyByZXF1aXJlZCwgYW5kIGEgbGFyZ2VyIGdy
b3VwIA0KICAgb2YgcGFzc2l2ZSBwYXJ0aWNpcGFudHMuIE1lbWJlcnNoaXAgaW5mb3JtYXRpb24g
Zm9yIHRoaXMgbGFyZ2VyIA0KICAgZ3JvdXAgaXMgbGVzcyBzdHJpY3RseSBwcm92aWRlZCwgY29t
cGFyYWJsZSB3aXRoICdibHVlIHNoZWV0cycgDQogICBhdHRlbmRlZXMgbGlzdHMuICANCiAgICAN
CiAgIFRoZSBhY2Nlc3MgY29udHJvbCB3aXRoaW4gdGhlIGdyb3VwIG9mIGFjdGl2ZSBwYXJ0aWNp
cGFudHMgaXMgDQogICByZWFsaXplZCBieSBtZWFucyBvZiBmbG9vciBjb250cm9sIHJlYWxpemlu
ZyBzcGVjaWZpYyBzb2NpYWwgDQogICBpbnRlcmFjdGlvbnMgKGNvbmR1Y3RlZCBzZXNzaW9uLCBw
YW5lbCBncm91cCkgc2ltaWxhciB0byBmbG9vciANCiAgIGNvbnRyb2xsZWQgY29uZmVyZW5jaW5n
LiANCiAgICANCiAgIEFzIGEgc3BlY2lmaWMgY2hhcmFjdGVyaXN0aWMgb2YgdGhpcyBjYXRlZ29y
eSwgZnJlcXVlbnQgY2hhbmdlcyANCiAgIGJldHdlZW4gYWN0aXZlIGFuZCBwYXNzaXZlIHBhcnRp
Y2lwYXRpb24gaW4gdGhlIGNvbmZlcmVuY2UgYXJlIA0KICAgaGFwcGVuaW5nLCBlLmcuLCBhIHBh
c3NpdmUgb2JzZXJ2ZXIgKHBhcnRpY2lwYW50KSBvZiB0aGUgZXZlbnQgbWlnaHQgDQogICByYWlz
ZSBpdHMgaW50ZXJlc3QgaW4gYmVjb21pbmcgYWN0aXZlIGluIHRoZSBkaXNjdXNzaW9uLCBlaXRo
ZXIgYnkgDQogICBvd24gcmVxdWVzdCBvciBieSBpbnZpdGF0aW9uLCBmb2xsb3dpbmcgdGhlIHNw
ZWNpZmljIGFjY2VzcyBydWxlcyBvZiANCiAgIHRoZSBhY3RpdmUgcGFydGljaXBhbnQgZ3JvdXAg
aW1wbGVtZW50ZWQgYnkgYXBwcm9wcmlhdGUgZmxvb3IgDQogICBjb250cm9sIG1lYW5zLiBUaGUg
bW9kZSBjaGFuZ2UgY291bGQgaGFwcGVuICdleHBsaWNpdGx5JywgaS5lLiwgYnkgDQogICBqb2lu
aW5nIHRoZSBhY3RpdmUgbWVtYmVyIGdyb3VwLCBvciAnaW1wbGljaXRseScsIGkuZS4sIGJ5IA0K
ICAgcmVxdWVzdGluZyBmbG9vciBjb250cm9sIHNlcnZpY2VzLiANCiAgICANCiAgIFRoaXMgbW9k
ZSBjaGFuZ2Ugc2hvdWxkIGJlIHBvc3NpYmxlIGluIHRoZSByZXZlcnNlIGRpcmVjdGlvbiwgdG9v
LCANCiAgIGkuZS4sIHdoZW4gYW4gYWN0aXZlIHBhcnRpY2lwYW50IGxvb3NlcyBpbnRlcmVzdCBp
biBhY3RpdmUgDQogICBwYXJ0aWNpcGF0aW9uLiANCiAgICANCjUuMy4xLiBFeGFtcGxlcyANCiAg
ICANCiAgIEV4YW1wbGVzIGZvciBsYXJnZSBzY2FsZSByaWNoIGNvbmZlcmVuY2luZyBzY2VuYXJp
b3MgYXJlIHRvd24gaGFsbCANCiAgIG1lZXRpbmdzLCBJRVRGIHdvcmtpbmcgZ3JvdXAgbWVldGlu
Z3MsIHZpcnR1YWwgbGVjdHVyZXMgd2l0aCANCiAgIGZlZWRiYWNrLCB2aXJ0dWFsIG5ld3Nncm91
cHMuIEhvd2V2ZXIsIGV4YW1wbGVzIGZvciBzaW1wbGUgYW5kIGZsb29yIA0KICAgY29udHJvbGxl
ZCBjb25mZXJlbmNpbmcgYXJlIGFsc28gYXBwbGljYWJsZSBmb3IgdGhpcyBjYXRlZ29yeSBkdWUg
dG8gDQogICB0aGUgc3VwZXJzZXQgY2hhcmFjdGVyIG9mIHRoZSByaWNoIGNvbmZlcmVuY2luZyBj
YXRlZ29yeSBjb21wYXJlZCB0byANCiAgIHRoZSBvdGhlciBvbmVzLiANCiAgICANCjUuNC4gICBT
dW1tYXJ5IG9mIENoYXJhY3RlcmlzdGljcyANCiAgICANCiAgIFRoZSBmb2xsb3dpbmcgdGFibGUg
c3VtbWFyaXplcyB0aGUgbWFpbiBjaGFyYWN0ZXJpc3RpY3MgZm9yIHRoZSANCiAgIGRpZmZlcmVu
dCBzY2VuYXJpbyBjYXRlZ29yaWVzIHByZXNlbnRlZCBpbiBzZWN0aW9uIDUuMS4gdG8gNS4zLiAN
CiAgICcoKyknIGluZGljYXRlcyBvcHRpb25hbCBmdW5jdGlvbmFsaXR5LiAgDQogICAgDQogICBU
aGUgZmlyc3QgYmxvY2sgb2YgY2hhcmFjdGVyaXN0aWNzIGlzIHJlZmVycmVkIHRvIGFzIGNvbmZl
cmVuY2UgDQogICBpbml0aWF0aW9uIGFuZCBzZXR1cCAoc2VlIFszXSksIHdoaWxlIHRoZSBzZWNv
bmQgYmxvY2sgaXMgZGVkaWNhdGVkIA0KICAgdG8gY29uZmVyZW5jZSBjb3Vyc2UgY29udHJvbCBm
dW5jdGlvbmFsaXR5LiANCiAgICANCiAgICANCiAgICANCiAgIC0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIA0KICAgfCBGdW5jdGlv
bmFsaXR5ICAgIHwgIFNpbXBsZSAgICAgfCAgICBGLkMuICAgICB8ICAgUmljaCAgICAgIHwgDQog
ICB8ICAgICAgICAgICAgICAgICAgfCAgIENvbmYuICAgICB8ICAgQ29uZi4gICAgIHwgICBDb25m
LiAgICAgfCANCiAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tIA0KICAgICANClRyb3NzZW4gICAgICAgICAgICAgICAgIEV4cGly
ZXMgTm92ZW1iZXIgMjAwMSAgICAgICAgICAgICAgICAgICAgIFs3XSANDA0KSW50ZXJuZXQgRHJh
ZnQgICAgIENvdXJzZSBDb250cm9sIFByb2JsZW0gU3RhdGVtZW50ICAgICAgICAgICBNYXkgMjAw
MSANCiAgICANCiAgICANCiAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIA0KICAgfCBQcm9maWxlIEluZi4gICAgIHwgICAgICAr
ICAgICAgfCAgICAgICsgICAgICB8ICAgICAgKyAgICAgIHwgDQogICB8ICAgICAgICAgICAgICAg
ICAgfCAgICAgICAgICAgICB8ICAgIGluY2wuICAgIHwgICAgaW5jbC4gICAgfCANCiAgIHwgICAg
ICAgICAgICAgICAgICB8ICAgICAgICAgICAgIHwgIGZsb29yIGluZi4gfCAgZmxvb3IgaW5mLiB8
IA0KICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0gDQogICB8IEluaXRpYXRpb24gICAgICAgfCAgYW5ub3VuY2VkICB8ICBhbm5v
dW5jZWQgIHwgIGFubm91bmNlZCAgfCANCiAgIHwgICAgICAgICAgICAgICAgICB8ICAgaW52aXRl
ZCAgIHwgICBpbnZpdGVkICAgfCAgIGludml0ZWQgICB8IA0KICAgLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gDQogICB8IENhcGFi
aWxpdGllcyAgICAgfCAgICAgKCspICAgICB8ICAgICAgKyAgICAgIHwgICAgICArICAgICAgfCAN
CiAgIHwgUmUtbmVnb3RpYXRpb24gICB8ICAgICAgICAgICAgIHwgICAgICAgICAgICAgfCAgICAg
ICAgICAgICB8IA0KICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0gDQogICB8IEF1dGhlbnRpY2F0aW9uICsgfCAgICAgKCspICAg
ICB8ICAgICAoKykgICAgIHwgICAgICgrKSAgICAgfCANCiAgIHwgQXV0aG9yaXphdGlvbiAgICB8
ICAgICAgICAgICAgIHwgICAgICAgICAgICAgfCAgICAgICAgICAgICB8IA0KICAgLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gDQog
ICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLSANCiAgIHwgTWVtYmVyc2hpcCBJbmZvICB8ICAgICAgKyAgICAgIHwgICAgICArICAg
ICAgfCAgICAgICsgICAgICB8IA0KICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gDQogICB8IEZsb29yIENvbnRyb2wgICAgfCAg
ICAgIC0gICAgICB8ICAgICAgKyAgICAgIHwgICAgKyAoZm9yICAgfCANCiAgIHwgICAgICAgICAg
ICAgICAgICB8ICAgICAgICAgICAgIHwgICAgICAgICAgICAgfCAgICBhY3RpdmUpICB8IA0KICAg
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0gDQogICB8IE1lbWJlcnNoaXAgICAgICAgfCAgYXQgc3RhcnR1cCB8IGJhc2VkIG9uICAg
IHwgYmFzZWQgb24gICAgfCANCiAgIHwgRW5mb3JjZW1lbnQgICAgICB8ICAgICBvbmx5ICAgIHwg
Zmxvb3IgY3RybCAgfCBmbG9vciBjdHJsICB8IA0KICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gDQogICB8IEFjdGl2ZS9QYXNz
aXZlICAgfCAgICAgIC0gICAgICB8ICAgICAgLSAgICAgIHwgICAgICArICAgICAgfCANCiAgIHwg
TW9kZSBDaGFuZ2UgICAgICB8ICAgICAgICAgICAgIHwgICAgICAgICAgICAgfCAgICAgICAgICAg
ICB8IA0KICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0gDQogICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSANCiAgIHwgU2NhbGUgICAgICAgICAgICB8IHNtYWxs
IGR1ZSB0b3wgZGVwZW5kcyBvbiAgfCAgIGxhcmdlICAgICB8IA0KICAgfCAgICAgICAgICAgICAg
ICAgIHwgbGFjayBvZiAgICAgfCBmbG9vciAgY3RybC58ICAgICAgICAgICAgIHwgDQogICB8ICAg
ICAgICAgICAgICAgICAgfCBtZWRpYXRpb24gICB8IHNjYWxlICAgICAgIHwgICAgICAgICAgICAg
fCANCiAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tIA0KICAgICAgICAgICAgICBUYWJsZSAxIDogU3VtbWFyeSBvZiBDaGFyYWN0
ZXJpc3RpY3MgDQogICAgDQogICBUaGUgZm9sbG93aW5nIEZpZ3VyZSAxIHRyaWVzIHRvIG91dGxp
bmUgdGhlIGNhdGVnb3JpZXMgb2YgdGhpcyANCiAgIHNlY3Rpb24gaW4gYSBzY2FsZS1mdW5jdGlv
bmFsaXR5IHNwYWNlLCBlbXBoYXNpemluZyB0aGUgc3VwZXJzZXQgDQogICBjaGFyYWN0ZXIgb2Yg
dGhlICdyaWNoIGNvbmZlcmVuY2luZycgY2F0ZWdvcnkuIA0KICAgIA0KICAgU2NhbGUgL3xcIA0K
ICAgICAgICAgIHx8LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS18IA0KICAgICAgICAgIHx8ICAgICAgICAgICAgICAgIFJpY2ggQ29uZmVyZW5jaW5nICAg
ICAgICAgICAgICAgICB8IA0KICAgICAgICAgIHx8ICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICB8IA0KICAgICAgICAgIHx8ICAgICAgICBUb3duIEhhbGwg
TWVldGluZ3MsIElFVEYgTWVldGluZ3MgICAgICAgICB8IA0KICAgICAgICAgIHx8fC0tLS0tLS0t
LS0tLS0tLS0tLS0tLS18fC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLXx8IA0KICAgICAgICAgIHx8
fCBTaW1wbGUgQ29uZmVyZW5jaW5nICB8fCBGbG9vciBDb250cm9sbGVkIENvbmYuIHx8IA0KICAg
ICAgICAgIHx8fCAgICAgICAgICAgICAgICAgICAgICB8fCAgICAgICAgICAgICAgICAgICAgICAg
IHx8IA0KICAgICAgICAgIHx8fCBMZWN0dXJlcywgTWVldGluZ3MgICB8fCBjb25kdWN0ZWQgbWVl
dGluZ3MgICAgIHx8IA0KICAgICAgICAgIHx8fC0tLS0tLS0tLS0tLS0tLS0tLS0tLS18fC0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLXx8IA0KICAgICAgICAgIHx8LS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIA0KICAgICAgICAgIHwtLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPiANCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBGdW5jdGlvbmFsaXR5IA0KICAgIA0K
ICAgICAgICAgICAgICBGaWd1cmUgMSA6IENhdGVnb3JpZXMgaW4gU2NhbGUtRnVuY3Rpb25hbGl0
eSBTcGFjZSANCiAgICANCiAgICAgDQpUcm9zc2VuICAgICAgICAgICAgICAgICBFeHBpcmVzIE5v
dmVtYmVyIDIwMDEgICAgICAgICAgICAgICAgICAgICBbOF0gDQwNCkludGVybmV0IERyYWZ0ICAg
ICBDb3Vyc2UgQ29udHJvbCBQcm9ibGVtIFN0YXRlbWVudCAgICAgICAgICAgTWF5IDIwMDEgDQog
ICAgDQogICAgDQo2LiAgICAgQ29uZmVyZW5jZSBDb3Vyc2UgQ29udHJvbCBNb2RlbHMgDQogICAg
DQogICBUaGUgY29uZmVyZW5jaW5nIHNjZW5hcmlvcyBpbiBTZWN0aW9uIDUgY2FuIGVhc2lseSBi
ZSBtYXBwZWQgb250byANCiAgIG1vZGVscyBmb3IgcmVhbGl6ZSBjb25mZXJlbmNlIGNvdXJzZSBj
b250cm9sIHJlYWxpemF0aW9uIHdpdGggDQogICByZXNwZWN0IHRvIHRoZSBmdW5jdGlvbmFsaXRp
ZXMgcHJlc2VudGVkIGluIFNlY3Rpb24gMi4gDQogICAgDQo2LjEuICAgTG9vc2UgQ29uZmVyZW5j
ZSBDb3Vyc2UgQ29udHJvbCANCiAgICANCiAgICdMb29zZScgY29uZmVyZW5jZSBjb3Vyc2UgY29u
dHJvbCAoYWxzbyByZWZlcnJlZCB0byBhcyAnbGlnaHQtd2VpZ2h0IA0KICAgc2Vzc2lvbiBjb250
cm9sJyBbM10pIGlzIHRoZSBtb2RlbCBhcHBsaWNhYmxlIGZvciB0aGUgc2ltcGxlIA0KICAgY29u
ZmVyZW5jaW5nIHNjZW5hcmlvIGNhdGVnb3J5IG9mIFNlY3Rpb24gNS4xLiAgDQogICAgDQogICBI
ZW5jZSwgdGhpcyBjb250cm9sIG1vZGVsIGxhY2tzIG9mIGV4cGxpY2l0IG1lbWJlcnNoaXAgYW5k
IA0KICAgYXBwbGljYXRpb24gc2Vzc2lvbiBjb250cm9sLiBGdXJ0aGVybW9yZSwgZmxvb3IgY29u
dHJvbCBmYWNpbGl0aWVzIA0KICAgYXJlIG5vdCBwcm92aWRlZC4gSG93ZXZlciwgbWVtYmVyc2hp
cCBpbmZvcm1hdGlvbiBtaWdodCBiZSBnYXRoZXJlZCANCiAgIGR1cmluZyBydW50aW1lIG9mIHRo
ZSBzZXNzaW9uLCBjb21wYXJhYmxlIHdpdGggdGhlIGJsdWUgc2hlZXRzIG9mIA0KICAgYXR0ZW5k
ZWVzLiANCiAgICANCiAgIFVzdWFsbHksIGdyb3VwIGtleSBtZWNoYW5pc21zIGFyZSBhbHNvIG1p
c3NpbmcgZm9yIG1lbWJlcnNoaXAgDQogICBlbmZvcmNlbWVudCBhZnRlciBzdGFydGluZyB0aGUg
Y29uZmVyZW5jZS4gDQogICAgDQo2LjIuICAgVGlnaHQgQ29uZmVyZW5jZSBDb3Vyc2UgQ29udHJv
bCANCiAgICANCiAgICdUaWdodCcgY29uZmVyZW5jZSBjb3Vyc2UgY29udHJvbCBbM10gaXMgdGhl
IG1vZGVsIGFwcGxpY2FibGUgZm9yIA0KICAgdGhlIGZsb29yIGNvbnRyb2wgY29uZmVyZW5jaW5n
IHNjZW5hcmlvIGNhdGVnb3JpZXMgb2YgU2VjdGlvbiA1LjIuIA0KICAgIA0KICAgSGVuY2UsIGFk
ZGl0aW9uYWwgZmxvb3IgY29udHJvbCBpbmZvcm1hdGlvbiBvZiB0aGUgY29uZmVyZW5jZSANCiAg
IHByb2ZpbGUgb3Igc3RhdGljYWxseSBpbXBsZW1lbnRlZCBhcHBsaWNhdGlvbiBzZW1hbnRpYyBh
cmUgdXNlZCBmb3IgDQogICBpbXBsZW1lbnRpbmcgZmxvb3IgY29udHJvbCB0byBtYXAgJ3NvY2lh
bCBwcm90b2NvbCcgc2VtYW50aWNzIG9udG8gDQogICB0aGUgZGlzdHJpYnV0ZWQgc2NlbmFyaW8u
IEV4YWN0IG1lbWJlcnNoaXAgYW5kIGFwcGxpY2F0aW9uIHNlc3Npb24gDQogICBpbmZvcm1hdGlv
biBpcyB1c3VhbGx5IHByb3ZpZGVkIHRvZ2V0aGVyIHdpdGggbWVtYmVyc2hpcCBlbmZvcmNlbWVu
dCANCiAgIGJhc2VkIG9uIGZsb29yIGNvbnRyb2wgcG9saWNpZXMgZHVyaW5nIHJ1bnRpbWUgb2Yg
dGhlIGNvbmZlcmVuY2UuIA0KICAgIA0KNi4zLiAgICdKZWxseS1saWtlJyBDb25mZXJlbmNlIENv
dXJzZSBDb250cm9sIA0KICAgIA0KICAgQXMgYSBjb21iaW5hdGlvbiBvZiB0aGUgbG9vc2UgYW5k
IHRpZ2h0IGNvbnRyb2wgbW9kZWwgb2YgU2VjdGlvbiANCiAgIDYuMS4gYW5kIDYuMi4sICdqZWxs
eS1saWtlJyBjb3Vyc2UgY29udHJvbCBpcyBjb25zaWRlcmVkIGZvciByaWNoIA0KICAgY29uZmVy
ZW5jaW5nIChzZWUgU2VjdGlvbiA1LjMuKSByZWFsaXphdGlvbi4gDQogICAgDQogICBUaGUgdGln
aHQgY29udHJvbCBtb2RlbCBpcyBhcHBsaWVkIGZvciB0aGUgYWN0aXZlIHBhcnRpY2lwYW50cyBp
biANCiAgIHRoZSBjb25mZXJlbmNlLCB3aGlsZSBhIGxvb3NlIGNvbnRyb2wgbW9kZWwgaXMgdXNl
ZCBmb3IgdGhlIHBhc3NpdmUgDQogICBvbmVzLiBJbiBhZGRpdGlvbiB0byB0aGUgZnVuY3Rpb25h
bGl0eSBmb3IgdGhlIHNwZWNpZmljIHVzZXIgZ3JvdXAsIA0KICAgaS5lLiwgYWN0aXZlIG9yIHBh
c3NpdmUsIG1lY2hhbmlzbXMgdG8gc3VwcG9ydCBtb2RlIGNoYW5nZXMgZnJvbSANCiAgIGFjdGl2
ZSB0byBwYXNzaXZlIGFuZCB2aWNlIHZlcnNhIG1pZ2h0IGJlIHJlcXVpcmVkIHdpdGhvdXQgDQog
ICBkaXN0dXJiYW5jZSwgaS5lLiwgaW50ZXJydXB0aW9uLCBvZiB0aGUgcnVubmluZyBjb25mZXJl
bmNlLiANCiAgICANCiAgIERpZmZlcmVudCBwb2xpY2llcyBmb3IgdGhpcyBtb2RlIGNoYW5nZSBz
aG91bGQgYmUgZmVhc2libGUsIHN1Y2ggYXMgDQogICB1cG9uIGludml0YXRpb24gYnkgaW5kaXZp
ZHVhbCBhY3RpdmUgcGFydGljaXBhbnRzIG9yIHVwb24gcmVxdWVzdCBvZiANCiAgIHRoZSBwYXNz
aXZlIHBhcnRpY2lwYW50LiANCiAgICANCjcuICAgICBFeGlzdGluZyBTb2x1dGlvbnMgDQogICAg
DQogICAgIA0KVHJvc3NlbiAgICAgICAgICAgICAgICAgRXhwaXJlcyBOb3ZlbWJlciAyMDAxICAg
ICAgICAgICAgICAgICAgICAgWzldIA0MDQpJbnRlcm5ldCBEcmFmdCAgICAgQ291cnNlIENvbnRy
b2wgUHJvYmxlbSBTdGF0ZW1lbnQgICAgICAgICAgIE1heSAyMDAxIA0KICAgIA0KICAgIA0KICAg
VGhlIGZvbGxvd2luZyBzZWN0aW9uIGlzIGJyaWVmbHkgZXZhbHVhdGluZyBleGlzdGluZyBjb25m
ZXJlbmNpbmcgDQogICBzb2x1dGlvbnMgd2l0aCByZXNwZWN0IHRvIHRoZWlyIGNvbmZlcmVuY2Ug
Y291cnNlIGNvbnRyb2wgDQogICBmdW5jdGlvbmFsaXR5LiBOb3RlIHRoYXQgdGhpcyBwcmVzZW50
YXRpb24gaXMgcmVzdHJpY3RlZCB0byBzeXN0ZW1zIA0KICAgYmFzZWQgb24gY2VydGFpbiBzdGFu
ZGFyZHMsIGhlbmNlIHRoaXMgbGlzdCBkb2VzIG5vdCBjbGFpbSB0byBiZSBhbiANCiAgIGV4aGF1
c3RpdmUgcmV2aWV3IG9mIGV4aXN0aW5nIGNvbmZlcmVuY2luZyBzeXN0ZW1zLiANCiAgICANCiAg
IFRoZSBmb2xsb3dpbmcsIGludGVydHdpbmVkLCBjcml0ZXJpYSBhcmUgdXNlZCB0byBldmFsdWF0
ZSB0aGVzZSANCiAgIHNvbHV0aW9uczogDQogICBvIFByb3ZpZGVkIEZ1bmN0aW9uYWxpdHk6IFdo
YXQgZnVuY3Rpb25hbGl0eSBpcyBwcm92aWRlZCB3aXRoICANCiAgICAgcmVzcGVjdCB0byBUYWJs
ZSAxPyANCiAgIG8gRmxleGliaWxpdHk6IFdoYXQgc2NlbmFyaW9zIGFyZSBjb3ZlcmVkPyBXaGF0
IHBvbGljaWVzIGFyZSAgDQogICAgIHByb3ZpZGVkPyBIb3cgZmxleGlibGUgaXMgdGhlIHByb3Zp
ZGVkIGZ1bmN0aW9uYWxpdHk/IA0KICAgbyBFeHRlbmRpYmlsaXR5OiBUbyB3aGF0IGV4dGVudCBj
YW4gdGhlIHNvbHV0aW9uIGJlIGV4dGVuZGVkIHRvICANCiAgICAgaW50ZWdyYXRlIG5ldyBmdW5j
dGlvbmFsaXR5PyANCiAgIG8gU2NhbGFiaWxpdHk6IFdoYXQgcmVzdHJpY3Rpb25zIGR1ZSB0byBh
cmNoaXRlY3R1cmU/IA0KICAgIA0KNy4xLiAgIEguMzJ4IFByb3RvY29sIFN1aXRlIA0KICAgIA0K
ICAgbyBGdW5jdGlvbmFsaXR5OiAgDQogICAgIC0gY2VudHJhbGl6ZWQvZGVjZW50cmFsaXplZCBj
b25mZXJlbmNpbmcgDQogICAgIC0gcHJldHR5IG11Y2ggYWltaW5nIGF0IGZsb29yIGNvbnRyb2xs
ZWQgY29uZmVyZW5jaW5nLCBhbHRob3VnaCAgDQogICAgICAgb25seSBjb25kdWN0ZWQvbm9uLWNv
bmR1Y3RlZCBtb2RlcyBzdXBwb3J0ZWQgDQogICAgIC0gTm8gcGFzc2l2ZS9hY3RpdmUgbm90aW9u
IGluIHRoZSBvcmlnaW5hbCBILjMyeCwgSC4zMzIgZXh0ZW5zaW9uICANCiAgICAgICBkb2VzbpJ0
IHN1cHBvcnQgY2hhbmdlcyBvZiBsaXN0ZW5lcnMgdG8gYWN0aXZlIHVzZXJzLiANCiAgICAgIA0K
ICAgbyBGbGV4aWJpbGl0eTogIA0KICAgICAtIEZsb29yIGNvbnRyb2xsZWQgY29uZmVyZW5jaW5n
IGlzIHBvb3JseSBzdXBwb3J0ZWQsIGFsdGhvdWdoIHRoZSAgDQogICAgICAgZGF0YSBjb25mZXJl
bmNpbmcgcGFydCBzdXBwb3J0cyB0b2tlbnMuICANCiAgICAgLSBQcmUtZGVmaW5lZCByb2xlIG1v
ZGVscywgaS5lLiwgY29uZHVjdGVkIHZlcnN1cyBub24tY29uZHVjdGVkLCAgDQogICAgICAgZm9y
IGF1ZGlvdmlzdWFsIHBhcnQuICANCiAgICAgLSBObyBwb2xpY3kgZGVmaW5pdGlvbiwgZS5nLiwg
dXNpbmcgYXBwcm9wcmlhdGUgcHJvZmlsZSAgDQogICAgICAgaW5mb3JtYXRpb24uIA0KICAgICAt
IHJlY29uZmlndXJhdGlvbiBvZiBydW5uaW5nIGNvbmZlcmVuY2VzIHBvb3JseSBzdXBwb3J0ZWQu
IA0KICAgIA0KICAgbyBFeHRlbmRpYmlsaXR5OiANCiAgICAgLSBwcmV0dHkgY2xvc2VkIHN5c3Rl
bSBvZiBhIHdob2xlIHNldCBvZiBzdGFuZGFyZHMgDQogICAgDQogICBvIFNjYWxhYmlsaXR5OiB2
ZXJ5IHJlc3RyaWN0ZWQgZHVlIHRvIHRpZ2h0IGNlbnRyYWxpemVkIGNvbnRyb2wgIA0KICAgICBz
dHJ1Y3R1cmUgDQogICAgDQogICBbVEJEXSBhZGQgb3RoZXIgcG9pbnRzLCBlaXRoZXIgaXRlbXMg
b3Igc3ViaXRlbXMgDQogICAgDQo3LjIuICAgU0lQLWJhc2VkIFNvbHV0aW9ucyANCiAgICANCiAg
IG8gRnVuY3Rpb25hbGl0eTogIA0KICAgICAtIGZsZXhpYmxlIGluaXRpYXRpb24gbW9kZWxzIFsx
MV0gIA0KICAgICAtIG1lbWJlcnNoaXAgaW5mb3JtYXRpb24gdXNpbmcgUlRDUCBpbmZvcm1hdGlv
biAobG9vc2UgY29udHJvbCkgb3IgICAgICANCiAgICAgICBhLXByaW9yaSBpbmZvcm1hdGlvbiAN
CiAgICAgLSBubyBtZW1iZXJzaGlwIGVuZm9yY2VtZW50IA0KICAgICAtIG5vIGZsb29yIGNvbnRy
b2wgDQogICAgIC0gbm8gY2FwYWJpbGl0eSByZS1uZWdvdGlhdGlvbiANCiAgICANCiAgIG8gRmxl
eGliaWxpdHkvRXh0ZW5kaWJpbGl0eTogDQogICAgIA0KVHJvc3NlbiAgICAgICAgICAgICAgICAg
RXhwaXJlcyBOb3ZlbWJlciAyMDAxICAgICAgICAgICAgICAgICAgICBbMTBdIA0MDQpJbnRlcm5l
dCBEcmFmdCAgICAgQ291cnNlIENvbnRyb2wgUHJvYmxlbSBTdGF0ZW1lbnQgICAgICAgICAgIE1h
eSAyMDAxIA0KICAgIA0KICAgIA0KICAgICAtIGV4dGVuc2lvbiBwb3NzaWJsZSBieSBhZGRpbmcg
Y29uZmVyZW5jZSBjb3Vyc2UgY29udHJvbCAgDQogICAgICAgZnVuY3Rpb25hbGl0eSBhcyBzZXBh
cmF0ZWQgY29tcG9uZW50IGR1ZSB0byBvcGVuIHN5c3RlbSAgDQogICAgICAgY2hhcmFjdGVyIA0K
ICAgICAtIG90aGVyIHNjZW5hcmlvcyBwb3NzaWJsZSBieSBhZGRpbmcgZnVuY3Rpb25hbGl0eSAN
CiAgICANCiAgIG8gU2NhbGFiaWxpdHk6IGRlcGVuZHMgb24gdGhlIGluaXRpYXRpb24gbW9kZWws
IGJ1dCBtb3N0IGxpa2VseSAgDQogICAgIHNpbWlsYXIgdG8gdGhlIHNpbXBsZSBjb25mZXJlbmNp
bmcgY2F0ZWdvcnkgKHNlZSBTZWN0aW9uIDUuMSkgDQogICAgDQogICBbVEJEXSBhZGQgb3RoZXIg
cG9pbnRzLCBlaXRoZXIgaXRlbXMgb3Igc3ViaXRlbXMgDQogICAgDQogICAgDQo4LiAgICAgTmV4
dCBTdGVwcyANCiAgICANCiAgIFRoZSBmb2xsb3dpbmcgaXRlbXMgYXJlIHByb3Bvc2VkIGFzIG5l
eHQgc3RlcHM6IA0KICAgIA0KICAgbyBEZWZpbml0aW9uIG9mIHJlcXVpcmVtZW50cyANCiAgIG8g
UHJvcG9zYWwgZm9yIHByb3ZpZGVkIHNlcnZpY2VzIA0KICAgbyBQcm9wb3NhbCBvZiBwcm90b2Nv
bCBzb2x1dGlvbnMgDQogICBvIEFuYWx5c2lzIG9mIHByb3RvY29sIHNvbHV0aW9ucyANCiAgIG8g
UmVjb21tZW5kYXRpb24gb2YgY29uZmVyZW5jZSBjb3Vyc2UgY29udHJvbCBzZXJ2aWNlIGFuZCBw
cm90b2NvbCANCiAgICANCiAgIEEgY3J1Y2lhbCBwYXJ0IG9mIHRoZSBhbmFseXNpcyB3b3JrIGlz
IHRvIHN0dWR5IGV4aXN0aW5nIHNvbHV0aW9ucyANCiAgIHdpdGggcmVzcGVjdCB0byB0aGVpciBh
cHBsaWNhYmlsaXR5IGFuZCB0aGVpciBhbGlnbm1lbnQgd2l0aCB0aGUgDQogICBkZWZpbmVkIHNj
b3BlIG9mIFNlY3Rpb24gMiBhbmQgdGhlIHByb2JsZW0gc3RhdGVtZW50IGluIFNlY3Rpb24gMy4g
DQogICAgDQogICAgDQo5LiAgICAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgDQogDQogICBUaGlz
IGRvY3VtZW50IG1lcmVseSBkaXNjdXNzZXMgcHJvYmxlbSBzdGF0ZW1lbnRzIG1vdGl2YXRpbmcg
dGhlIA0KICAgbmVlZCBmb3IgY29uZmVyZW5jZSBjb3Vyc2UgY29udHJvbCBtZWNoYW5pc21zLiBT
ZWN1cml0eSBpcyBhbiBpc3N1ZSANCiAgIGZvciBjb25mZXJlbmNlIGNvdXJzZSBjb250cm9sIGJ1
dCBpcyBjb25zaWRlcmVkIGluIHN1YnNlcXVlbnQgDQogICBzb2x1dGlvbi1zcGFjZSBkb2N1bWVu
dHMuIA0KICAgIA0KICAgIA0KMTAuICAgIEFja25vd2xlZGdlbWVudHMgDQogICAgDQogICBJIHdv
dWxkIGxpa2UgdG8gYWNrbm93bGVkZ2UgdGhlIHBhcnRpY2lwYW50cyBvZiB0aGUgbWFpbGluZyBs
aXN0IA0KICAgdGhhdCB3YXMgc2V0IHVwIHRvIGRpc2N1c3MgdGhlIHRoaXMgZG9jdW1lbnQuIFRo
ZWlyIGNvbnRyaWJ1dGlvbnMgDQogICBhbmQgYWN0aXZlIHBhcnRpY2lwYXRpb24gaW4gdGhlIGRp
c2N1c3Npb24gb24gdGhlIG1haWxpbmcgbGlzdCB3ZXJlIA0KICAgdmVyeSB1c2VmdWwgaW4gdGhl
IHByZXBhcmF0aW9uIG9mIHRoaXMgZG9jdW1lbnQuIA0KICAgIA0KICAgIA0KMTEuICAgIFJlZmVy
ZW5jZXMgDQogICAgDQogICBbMV0gIEMuIEJvcm1hbm4sIEouIE90dCwgRC4gS3V0c2NoZXIsIEQu
IFRyb3NzZW4sICJTaW1wbGUgQ29uZmVyZW5jZSANCiAgICAgICAgQ29udHJvbCBQcm90b2NvbCCW
IFNlcnZpY2UgU3BlY2lmaWNhdGlvbiIsIGRyYWZ0LWlldGYtbW11c2ljLQ0KICAgICAgICBzY2Nw
LTAxLnR4dCwgV29yayBpbiBQcm9ncmVzcywgRmVicnVhcnkgMjAwMSANCiAgICANCiAgIFsyXSAg
SC4gRXJpa3Nzb24sICJNQk9ORTogVGhlIE11bHRpY2FzdCBCYWNrYm9uZSIsIENvbW11bmljYXRp
b25zIG9mIA0KICAgICAgICB0aGUgQUNNLCBWb2wuMzcgTm8uOCwgcHAuNTQtNjAsIEF1Z3VzdCAx
OTk0IA0KIA0KICAgICANClRyb3NzZW4gICAgICAgICAgICAgICAgIEV4cGlyZXMgTm92ZW1iZXIg
MjAwMSAgICAgICAgICAgICAgICAgICAgWzExXSANDA0KSW50ZXJuZXQgRHJhZnQgICAgIENvdXJz
ZSBDb250cm9sIFByb2JsZW0gU3RhdGVtZW50ICAgICAgICAgICBNYXkgMjAwMSANCiAgICANCiAg
ICANCiAgIFszXSAgTS4gSGFuZGxleSwgSi4gQ3Jvd2Nyb2Z0LCBDLiBCb3JtYW5uLCAiVGhlIElu
dGVybmV0IE11bHRpbWVkaWEgDQogICAgICAgIENvbmZlcmVuY2luZyBBcmNoaXRlY3R1cmUiLCBk
cmFmdC1pZXRmLW1tdXNpYy1jb25mYXJjaC0wMy50eHQsIA0KICAgICAgICBXb3JrIEluIFByb2dy
ZXNzLCBKdWx5IDIwMDAgIA0KICAgIA0KICAgWzRdICBNLiBIYW5kbGV5LCBWLiBKYWNvYnNvbiwg
IlNEUDogU2Vzc2lvbiBEZXNjcmlwdGlvbiBQcm90b2NvbCIsIA0KICAgICAgICBSRkMgMjMyNywg
QXByaWwgMTk5OCANCiAgICANCiAgIFs1XSAgTS4gSGFuZGxleSwgSC4gU2NodWx6cmlubmUsIEUu
IFNjaG9vbGVyLCBKLiBSb3NlbmJlcmcsICJTSVA6IA0KICAgICAgICBTZXNzaW9uIEluaXRpYXRp
b24gUHJvdG9jb2wiLCBSRkMgMjU0MywgTWFyY2ggMTk5OSANCiAgICANCiAgIFs2XSAgTS4gSGFu
ZGxleSwgQy4gUGVya2lucywgRS4gV2hlbGFuLCAiU2Vzc2lvbiBhbm5vdW5jZW1lbnQgDQogICAg
ICAgIHByb3RvY29sIiwgUkZDIDI5NzQsIE9jdG9iZXIgMjAwMCANCiAgICANCiAgIFs3XSAgSVRV
LVQsICJWaXN1YWwgVGVsZXBob25lIFN5c3RlbXMgYW5kIEVxdWlwbWVudCBmb3IgTG9jYWwgQXJl
YSANCiAgICAgICAgTmV0d29ya3Mgd2l0aCBOb24tR3VhcmFudGVlZCBRdWFsaXR5IG9mIFNlcnZp
Y2UiLCBJVFUtVCANCiAgICAgICAgUmVjb21tZW5kYXRpb24gSC4zMjMsIDIwMDAgDQogICAgDQog
ICBbOF0gIElUVS1ULCAiSC4zMjMgZXh0ZW5kZWQgZm9yIGxvb3NlbHkgY291cGxlZCBjb25mZXJl
bmNlcyIsIElUVS1UIA0KICAgICAgICBSZWNvbW1lbmRhdGlvbiBILjMzMiwgU2VwdGVtYmVyIDE5
OTggDQogICAgDQogICBbOV0gIEQuIEt1dHNjaGVyLCBKLiBPdHQsIEMuIEJvcm1hbm4sICJSZXF1
aXJlbWVudHMgZm9yIFNlc3Npb24gDQogICAgICAgIERlc2NyaXB0aW9uIGFuZCBDYXBhYmlsaXR5
IE5lZ290aWF0aW9uIiwgZHJhZnQtaWV0Zi1tbXVzaWMtDQogICAgICAgIHNkcG5nLXJlcS0wMC50
eHQsIFdvcmsgSW4gUHJvZ3Jlc3MsIEZlYnJ1YXJ5IDIwMDEgDQogDQogICBbMTBdIEouIE90dCwg
Qy4gUGVya2lucywgRC4gS3V0c2NoZXIsICJBIE1lc3NhZ2UgQnVzIGZvciBMb2NhbCANCiAgICAg
ICAgQ29vcmRpbmF0aW9uIiwgZHJhZnQtaWV0Zi1tbXVzaWMtbWJ1cy10cmFuc3BvcnQtMDQudHh0
LCBXb3JrIEluIA0KICAgICAgICBQcm9ncmVzcywgRmVicnVhcnkgMjAwMSANCiANCiAgIFsxMV0g
Si4gUm9zZW5iZXJnLCBILiBTY2h1bHpyaW5uZSwgIk1vZGVscyBmb3IgTXVsdGkgUGFydHkgDQog
ICAgICAgIENvbmZlcmVuY2luZyBpbiBTSVAiLCBkcmFmdC1yb3NlbmJlcmctc2lwLWNvbmZlcmVu
Y2luZy1tb2RlbHMtDQogICAgICAgIDAwLnR4dCwgV29yayBJbiBQcm9ncmVzcywgTm92ZW1iZXIg
MjAwMCANCiANCiAgIFsxMl0gSC4gU2NodWx6cmlubmUsIFMuIENhc25lciwgUi4gRnJlZGVyaWNr
LCBWLiBKYWNvYnNvbiwgIlJUUDogQSANCiAgICAgICAgVHJhbnNwb3J0IFByb3RvY29sIGZvciBS
ZWFsLVRpbWUgQXBwbGljYXRpb25zIiwgUkZDIDE4ODksIA0KICAgICAgICBKYW51YXJ5IDE5OTYg
DQogDQogICBbMTNdIEQuIFRyb3NzZW4sICJTY2FsYWJsZSBGbG9vciBDb250cm9sIGluIENvbmZl
cmVuY2luZyANCiAgICAgICAgRW52aXJvbm1lbnRzOiBUaGUgUkJvbmUgQXBwcm9hY2giLCAybmQg
SVAgVGVsZXBob255IFdvcmtzaG9wLCANCiAgICAgICAgTmV3IFlvcmssIEFwcmlsIDIwMDEgDQog
ICAgDQogICAgDQogICAgDQpBdXRob3IncyBBZGRyZXNzIA0KICAgIA0KICAgRGlyayBUcm9zc2Vu
IA0KICAgTm9raWEgUmVzZWFyY2ggDQogICA1IFdheXNpZGUgUm9hZCANCiAgIEJ1cmxpbmd0b24s
IE1BIDAyNDc0IFVTQSAgICAgIA0KICAgUGhvbmU6ICAxLTc4MS05OTMtMzYwNSANCiAgIEVtYWls
OiAgZGlyay50cm9zc2VuQG5va2lhLmNvbSANCiAgICANCiAgICANCkZ1bGwgQ29weXJpZ2h0IFN0
YXRlbWVudCANCiAgICAgDQpUcm9zc2VuICAgICAgICAgICAgICAgICBFeHBpcmVzIE5vdmVtYmVy
IDIwMDEgICAgICAgICAgICAgICAgICAgIFsxMl0gDQwNCkludGVybmV0IERyYWZ0ICAgICBDb3Vy
c2UgQ29udHJvbCBQcm9ibGVtIFN0YXRlbWVudCAgICAgICAgICAgTWF5IDIwMDEgDQogICAgDQog
ICAgDQogICAgDQogICBDb3B5cmlnaHQgKEMpIFRoZSBJbnRlcm5ldCBTb2NpZXR5ICgyMDAxKS4g
QWxsIFJpZ2h0cyBSZXNlcnZlZC4gDQogICAgDQogICBUaGlzIGRvY3VtZW50IGFuZCB0cmFuc2xh
dGlvbnMgb2YgaXQgbWF5IGJlIGNvcGllZCBhbmQgZnVybmlzaGVkIHRvIA0KICAgb3RoZXJzLCBh
bmQgZGVyaXZhdGl2ZSB3b3JrcyB0aGF0IGNvbW1lbnQgb24gb3Igb3RoZXJ3aXNlIGV4cGxhaW4g
aXQgDQogICBvciBhc3Npc3QgaW4gaXRzIGltcGxlbWVudGF0aW9uIG1heSBiZSBwcmVwYXJlZCwg
Y29waWVkLCBwdWJsaXNoZWQgDQogICBhbmQgZGlzdHJpYnV0ZWQsIGluIHdob2xlIG9yIGluIHBh
cnQsIHdpdGhvdXQgcmVzdHJpY3Rpb24gb2YgYW55IA0KICAga2luZCwgcHJvdmlkZWQgdGhhdCB0
aGUgYWJvdmUgY29weXJpZ2h0IG5vdGljZSBhbmQgdGhpcyBwYXJhZ3JhcGggDQogICBhcmUgaW5j
bHVkZWQgb24gYWxsIHN1Y2ggY29waWVzIGFuZCBkZXJpdmF0aXZlIHdvcmtzLiBIb3dldmVyLCB0
aGlzIA0KICAgZG9jdW1lbnQgaXRzZWxmIG1heSBub3QgYmUgbW9kaWZpZWQgaW4gYW55IHdheSwg
c3VjaCBhcyBieSByZW1vdmluZyANCiAgIHRoZSBjb3B5cmlnaHQgbm90aWNlIG9yIHJlZmVyZW5j
ZXMgdG8gdGhlIEludGVybmV0IFNvY2lldHkgb3Igb3RoZXIgDQogICBJbnRlcm5ldCBvcmdhbml6
YXRpb25zLCBleGNlcHQgYXMgbmVlZGVkIGZvciB0aGUgcHVycG9zZSBvZiANCiAgIGRldmVsb3Bp
bmcgSW50ZXJuZXQgc3RhbmRhcmRzIGluIHdoaWNoIGNhc2UgdGhlIHByb2NlZHVyZXMgZm9yIA0K
ICAgY29weXJpZ2h0cyBkZWZpbmVkIGluIHRoZSBJbnRlcm5ldCBTdGFuZGFyZHMgcHJvY2VzcyBt
dXN0IGJlIA0KICAgZm9sbG93ZWQsIG9yIGFzIHJlcXVpcmVkIHRvIHRyYW5zbGF0ZSBpdCBpbnRv
IGxhbmd1YWdlcyBvdGhlciB0aGFuIA0KICAgRW5nbGlzaC4gDQogICAgDQogICBUaGUgbGltaXRl
ZCBwZXJtaXNzaW9ucyBncmFudGVkIGFib3ZlIGFyZSBwZXJwZXR1YWwgYW5kIHdpbGwgbm90IGJl
IA0KICAgcmV2b2tlZCBieSB0aGUgSW50ZXJuZXQgU29jaWV0eSBvciBpdHMgc3VjY2Vzc29ycyBv
ciBhc3NpZ25zLiANCiAgICANCiAgIFRoaXMgZG9jdW1lbnQgYW5kIHRoZSBpbmZvcm1hdGlvbiBj
b250YWluZWQgaGVyZWluIGlzIHByb3ZpZGVkIG9uIGFuIA0KICAgIkFTIElTIiBiYXNpcyBhbmQg
VEhFIElOVEVSTkVUIFNPQ0lFVFkgQU5EIFRIRSBJTlRFUk5FVCBFTkdJTkVFUklORyANCiAgIFRB
U0sgRk9SQ0UgRElTQ0xBSU1TIEFMTCBXQVJSQU5USUVTLCBFWFBSRVNTIE9SIElNUExJRUQsIElO
Q0xVRElORyANCiAgIEJVVCBOT1QgTElNSVRFRCBUTyBBTlkgV0FSUkFOVFkgVEhBVCBUSEUgVVNF
IE9GIFRIRSBJTkZPUk1BVElPTiANCiAgIEhFUkVJTiBXSUxMIE5PVCBJTkZSSU5HRSBBTlkgUklH
SFRTIE9SIEFOWSBJTVBMSUVEIFdBUlJBTlRJRVMgT0YgDQogICBNRVJDSEFOVEFCSUxJVFkgT1Ig
RklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UuIA0KICAgIA0KQWNrbm93bGVkZ2VtZW50
IA0KICAgIA0KICAgRnVuZGluZyBmb3IgdGhlIFJGQyBlZGl0b3IgZnVuY3Rpb24gaXMgY3VycmVu
dGx5IHByb3ZpZGVkIGJ5IHRoZSANCiAgIEludGVybmV0IFNvY2lldHkuIA0KICAgICANClRyb3Nz
ZW4gICAgICAgICAgICAgICAgIEV4cGlyZXMgTm92ZW1iZXIgMjAwMSAgICAgICAgICAgICAgICAg
ICAgWzEzXSANDA==
------_=_NextPart_001_01C12A78.DBC2BFA0--
>From owner-rmt@listserv.lbl.gov Tue Aug 21 12:57:00 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f7LJuhC07820;
Tue, 21 Aug 2001 12:56:43 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f7LJufV07816
for <rmt@listserv.lbl.gov>; Tue, 21 Aug 2001 12:56:41 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f7LJuem00277
for <rmt@listserv.lbl.gov>; Tue, 21 Aug 2001 12:56:41 -0700 (PDT)
Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f7LJud500271
for <rmt@lbl.gov>; Tue, 21 Aug 2001 12:56:40 -0700 (PDT)
Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84])
by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f7LJvkI27485
for <rmt@lbl.gov>; Tue, 21 Aug 2001 14:57:46 -0500 (CDT)
Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com
(Content Technologies SMTPRS 4.2.5) with ESMTP id <T5582083e65ac12f254079@davir01nok.americas.nokia.com>;
Tue, 21 Aug 2001 14:56:38 -0500
content-class: urn:content-classes:message
Subject: RE: Session control protocol instantiation discussion within the IETF
Date: Tue, 21 Aug 2001 14:55:58 -0500
Message-ID: <B9CFA6CE8FFDD211A1FB0008C7894E4604B9E793@bseis01nok>
X-MS-Has-Attach:
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
X-MS-TNEF-Correlator:
Thread-Topic: RE: Session control protocol instantiation discussion within the IETF
Thread-Index: AcEqe0stkykBmLE2SC+HdMALGd5lmQ==
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
From: "Trossen Dirk (NRC/Boston)" <Dirk.Trossen@nokia.com>
To: <mankin@ISI.EDU>, "'Michael Luby'" <luby@digitalfountain.com>
Cc: "'Rob Lanphier'" <robla@real.com>, "'Ross Finlayson'" <finlayson@live.com>,
"'Rmt@Lbl. Gov'" <rmt@lbl.gov>, <confctrl@ISI.EDU>, <sob@harvard.edu>,
"'ietf-floor control'" <flr-ctrl-grp@network2.cs.usm.my>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by SpamWall.lbl.gov id f7LJugV07817
Sender: owner-rmt@lbl.gov
Precedence: bulk
Sorry if you received multiple copies. I'm resending this due to
mailing problems.
------------------------------------------------------------------------
Hi all,
as announced on the MMUSIC mailing list, a couple of people
being interested in conference course control met on Wednesday
August 8th (10-11pm) during the London IETF meeting to discuss
further steps in this direction.
The following persons were present during this informal meeting:
Jun-Won Lee, Shin-Gak Kang, Jonathan Rosenberg, Eunsook Kim,
Colin Perkins, Joerg Ott, Dirk Kutscher, Dirk Trossen
During the meeting, a general interest in this topic was
expressed by the attendents. However, the concern was
raised (by Jonathan, Joerg, and Colin) that the scope
of the work has to be defined very carefully. Especially
Jonathan expressed interest in 'doable' solutions, i.e.,
covering rather simple centralized conferencing scenarios
first rather than defining a wide scope of the work.
The following steps have been proposed to be undertaken in
this direction:
- provision of a problem statement document
- submission to mailing list(s)
- creation of own discussion list for this topic
The problem statement document should be created by a circle
of people being interested in this topic and willing to contribute
to this work.
The discussion of the problem statement should end in a
decision how to bring this topic to the IETF within the
therein defined scope, either within the charter of existing
WGs or by organizing a BOF.
Since similar discussions about future session control efforts
have been undertaken within the RMT WG, I'm sending this mail
also to this list to invite interested people to join the discussion.
Enclosed you find the current document which was meant as a
problem statement for conference course control. This document
is far from being completed (it was not submitted as a draft although
it is written in Internet draft style) but it is intended as a basis
for discussion to reach final document status.
Any comments are welcome.
Best Regards,
Dirk Trossen
-----------------------
Dirk Trossen
Nokia Research Center
5 Wayside Road
Burlington, MA 01803
Tel: +1 (781) 993 3605
Fax: +1 (781) 993 1907
mob: +1 (617) 794 7041
-----------------------
> -----Original Message-----
> From: ext Allison Mankin [mailto:mankin@ISI.EDU]
> Sent: Wednesday, August 08, 2001 11:49 PM
> To: Michael Luby
> Cc: Rob Lanphier; Ross Finlayson; Rmt@Lbl. Gov; confctrl@ISI.EDU;
> Allison Mankin; sob@harvard.edu
> Subject: Re: Session control protocol instantiation discussion within
> the IETF
>
>
> Mike,
>
> We ADs would be happy to talk with you about this sometime (but after
> we all recover from IETF).
>
> Having had one hallway talk with you while you were in London,
> I think there is some value to discussing session work (without
> prejudging if it would extend an existing charter or start up in
> a new situation of some sort).
>
> Mike Luby wrote:
> > All,
> > I unfortunately was only at the IETF for a couple of days,
> and am back in
> > the Bay Area now. I would first like to talk with the
> transport area
> > directorate (Scott and Allison) to get some advice on this, and then
> > probably followup with a conference call with whoever is
> interested. Would
> > a conference call be ok with you Rob, Ross (and whoever else is
> > interested?).
> > Mike
> >
>
>From owner-rmt@listserv.lbl.gov Tue Aug 21 12:59:09 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f7LJx1207840;
Tue, 21 Aug 2001 12:59:01 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f7LJx0V07836
for <rmt@listserv.lbl.gov>; Tue, 21 Aug 2001 12:59:00 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f7LJwxl00897
for <rmt@listserv.lbl.gov>; Tue, 21 Aug 2001 12:58:59 -0700 (PDT)
Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f7LJww500891
for <rmt@lbl.gov>; Tue, 21 Aug 2001 12:58:58 -0700 (PDT)
Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85])
by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f7LJx2i15424
for <rmt@lbl.gov>; Tue, 21 Aug 2001 14:59:02 -0500 (CDT)
Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com
(Content Technologies SMTPRS 4.2.5) with ESMTP id <T55820a5a5aac12f255079@davir02nok.americas.nokia.com>;
Tue, 21 Aug 2001 14:58:56 -0500
content-class: urn:content-classes:message
Subject: RE: Session control protocol instantiation discussion within the IETF
Date: Tue, 21 Aug 2001 14:57:46 -0500
Message-ID: <B9CFA6CE8FFDD211A1FB0008C7894E4604B9E794@bseis01nok>
X-MS-Has-Attach:
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="----_=_NextPart_001_01C12A7B.8C236B40"
X-MS-TNEF-Correlator:
Thread-Topic: RE: Session control protocol instantiation discussion within the IETF
Thread-Index: AcEqe4uEShQMW6crRN2OATPOjXiPhA==
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
From: "Trossen Dirk (NRC/Boston)" <Dirk.Trossen@nokia.com>
To: <mankin@ISI.EDU>, "'Michael Luby'" <luby@digitalfountain.com>
Cc: "'Rob Lanphier'" <robla@real.com>, "'Ross Finlayson'" <finlayson@live.com>,
"'Rmt@Lbl. Gov'" <rmt@lbl.gov>, <confctrl@ISI.EDU>, <sob@harvard.edu>,
"'ietf-floor control'" <flr-ctrl-grp@network2.cs.usm.my>
Sender: owner-rmt@lbl.gov
Precedence: bulk
This is a multi-part message in MIME format.
------_=_NextPart_001_01C12A7B.8C236B40
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sorry, here's the document I was talking about in the previous
mail.
------_=_NextPart_001_01C12A7B.8C236B40
Content-Type: text/plain;
name="draft-trossen-problem-00.txt"
Content-Transfer-Encoding: base64
Content-Description: draft-trossen-problem-00.txt
Content-Disposition: attachment;
filename="draft-trossen-problem-00.txt"
DQpJbnRlcm5ldCBFbmdpbmVlcmluZyBUYXNrIEZvcmNlICAgICAgICAgICAgICAgICAgRC4gVHJv
c3NlbiAoRWRpdG9yKSANCkludGVybmV0IERyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIE5va2lhIFJlc2VhcmNoIA0KZHJhZnQtdHJvc3Nlbi1wcm9ibGVtLTAwLnR4
dCAgICAgICAgICAgICAgICAgICAgICAgICAgICAxMS4gTWF5IDIwMDEgDQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRXhwaXJlczogTm92ZW1iZXIgMjAwMSAN
CiANCiANCiAgICAgICAgICAgICAgICBDb25mZXJlbmNlIENvdXJzZSBDb250cm9sIFByb2JsZW0g
U3RhdGVtZW50IA0KIA0KIA0KU3RhdHVzIG9mIHRoaXMgTWVtbyANCiANCiAgIFRoaXMgZG9jdW1l
bnQgaXMgYW4gSW50ZXJuZXQtRHJhZnQgYW5kIGlzIGluIGZ1bGwgY29uZm9ybWFuY2UgDQogICB3
aXRoIGFsbCBwcm92aXNpb25zIG9mIFNlY3Rpb24gMTAgb2YgUkZDMjAyNi4gDQogICAgDQogICAg
DQogICBJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1lbnRzIG9mIHRoZSBJbnRlcm5l
dCBFbmdpbmVlcmluZyANCiAgIFRhc2sgRm9yY2UgKElFVEYpLCBpdHMgYXJlYXMsIGFuZCBpdHMg
d29ya2luZyBncm91cHMuICBOb3RlIHRoYXQgICAgICANCiAgIG90aGVyIGdyb3VwcyBtYXkgYWxz
byBkaXN0cmlidXRlIHdvcmtpbmcgZG9jdW1lbnRzIGFzIEludGVybmV0LQ0KICAgRHJhZnRzLiAN
CiAgICANCiAgIEludGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBh
IG1heGltdW0gb2Ygc2l4IA0KICAgbW9udGhzIGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQs
IG9yIG9ic29sZXRlZCBieSBvdGhlciBkb2N1bWVudHMgDQogICBhdCBhbnkgdGltZS4gIEl0IGlz
IGluYXBwcm9wcmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBhcyANCiAgIHJlZmVyZW5jZSBt
YXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4i
IA0KICAgIA0KICAgVGhlIGxpc3Qgb2YgY3VycmVudCBJbnRlcm5ldC1EcmFmdHMgY2FuIGJlIGFj
Y2Vzc2VkIGF0IA0KICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2lldGYvMWlkLWFic3RyYWN0
cy50eHQgDQogICBUaGUgbGlzdCBvZiBJbnRlcm5ldC1EcmFmdCBTaGFkb3cgRGlyZWN0b3JpZXMg
Y2FuIGJlIGFjY2Vzc2VkIGF0IA0KICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5o
dG1sLiANCiAgICANCkNvcHlyaWdodCBOb3RpY2UgDQogICAgDQogICBDb3B5cmlnaHQgKGMpIFRo
ZSBJbnRlcm5ldCBTb2NpZXR5ICgyMDAxKS4gQWxsIHJpZ2h0cyByZXNlcnZlZC4gDQogICAgDQpB
YnN0cmFjdCANCiAgICANCiAgIEFzIHBhcnQgb2YgdGhlIEludGVybmV0IE11bHRpbWVkaWEgQ29u
ZmVyZW5jaW5nIEFyY2hpdGVjdHVyZSBbM10sIA0KICAgY29uZmVyZW5jZSBjb3Vyc2UgY29udHJv
bCBkZWFscyB3aXRoIHRoZSBjb250cm9sIG9mIHJ1bm5pbmcgDQogICBjb25mZXJlbmNlcyBhZnRl
ciB0aGUgY3JlYXRpb24gb2YgdGhlIGluaXRpYWwgY29uZmVyZW5jZSBzdGF0ZSB3aXRoIA0KICAg
cmVzcGVjdCB0byB0aGUgbWVtYmVyc2hpcCBhbmQgYWNjZXNzIGNvbnRyb2wgZHVyaW5nIHJ1bnRp
bWUgb2YgdGhlIA0KICAgc2Vzc2lvbi4gVGhlIHNwZWN0cnVtIG9mIHNjZW5hcmlvcyByZWFjaGVz
IGZyb20gc21hbGwgbXVsdGlwYXJ0eSANCiAgIGdhdGhlcmluZ3MgdXAgdG8gbGFyZ2Ugc2NhbGVk
IG1lZXRpbmdzIHdpdGggYSBoaWdoIGZsdWN0dWF0aW9uIG9mIA0KICAgdXNlcpJzIG1lbWJlcnNo
aXAgYW5kIGFjdGl2aXR5LiANCiAgICANCiAgIFRoaXMgZG9jdW1lbnQgaWRlbnRpZmllcyB0aGUg
cHJvYmxlbSBhcmVhIHRvIGRlZmluZSB0aGUgc2NvcGUgb2YgYSANCiAgIGNvbmZlcmVuY2UgY291
cnNlIGNvbnRyb2wgd29ya2luZyBncm91cCBpbiB0aGUgSUVURi4gDQogDQogICAgIA0KVHJvc3Nl
biAgICAgICAgICAgICAgICAgRXhwaXJlcyBOb3ZlbWJlciAyMDAxICAgICAgICAgICAgICAgICAg
ICAgWzFdIA0MDQpJbnRlcm5ldCBEcmFmdCAgICAgQ291cnNlIENvbnRyb2wgUHJvYmxlbSBTdGF0
ZW1lbnQgICAgICAgICAgIE1heSAyMDAxIA0KICAgIA0KICAgIA0KVGFibGUgb2YgQ29udGVudHMg
DQogICAgDQogICAxLiBJbnRyb2R1Y3Rpb24uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4yIA0KICAgMi4gRGVmaW5pdGlvbiBvZiBUZXJtcy4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMyANCiAgIDMuIFNjb3BlLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjQgDQog
ICA0LiBQcm9ibGVtIFN0YXRlbWVudC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi40IA0KICAgNS4gQ29uZmVyZW5jaW5nIFNjZW5hcmlvcy4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uNSANCiAgIDUuMS4gIFNpbXBsZSBDb25mZXJlbmNp
bmcuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjUgDQogICA1LjEuMS4g
IEV4YW1wbGVzLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li42IA0KICAgNS4yLiAgRmxvb3IgQ29udHJvbGxlZCBDb25mZXJlbmNpbmcuLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uNiANCiAgIDUuMi4xLiAgRXhhbXBsZXMuLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjYgDQogICA1LjMuICBSaWNoIENvbmZl
cmVuY2luZy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi42IA0KICAg
NS4zLjEuICBFeGFtcGxlcy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uNyANCiAgIDUuNC4gIFN1bW1hcnkgb2YgQ2hhcmFjdGVyaXN0aWNzLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjcgDQogICA2LiBDb25mZXJlbmNlIENvdXJzZSBDb250
cm9sIE1vZGVscy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi45IA0KICAgNi4xLiAgTG9v
c2UgQ29uZmVyZW5jZSBDb3Vyc2UgQ29udHJvbC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
OSANCiAgIDYuMi4gIFRpZ2h0IENvbmZlcmVuY2UgQ291cnNlIENvbnRyb2wuLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLjkgDQogICA2LjMuICAnSmVsbHktbGlrZScgQ29uZmVyZW5jZSBDb3Vy
c2UgQ29udHJvbC4uLi4uLi4uLi4uLi4uLi4uLi4uLi45IA0KICAgNy4gRXhpc3RpbmcgU29sdXRp
b25zLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uOSANCiAgIDcu
MS4gIEguMzJ4IFByb3RvY29sIFN1aXRlLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uMTAgDQogICA3LjIuICBTSVAtYmFzZWQgU29sdXRpb25zLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLjEwIA0KICAgOC4gTmV4dCBTdGVwcy4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xMSANCiAgIDkuIFNlY3VyaXR5
IENvbnNpZGVyYXRpb25zLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTEg
DQogICAxMC4gIEFja25vd2xlZGdlbWVudHMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLjExIA0KICAgMTEuICBSZWZlcmVuY2VzLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xMSANCiAgICANCiAgICANCjEuICAgICBJbnRy
b2R1Y3Rpb24gDQogICAgDQogICBJbnRlcmFjdGl2ZSBjb2xsYWJvcmF0aXZlIHNjZW5hcmlvcyBs
aWtlIHJlbW90ZSBtZWV0aW5ncywgdmlydHVhbCANCiAgIGNsYXNzcm9vbXMsIG9yIHNoYXJpbmcg
YXBwbGljYXRpb25zIHZpYSB0aGUgSW50ZXJuZXQgaGF2ZSBiZWNvbWUgDQogICBtb3JlIGFuZCBt
b3JlIHBvcHVsYXIgaW4gdGhlIHBhc3QgdGVuIHllYXJzLiANCiAgICANCiAgIEFjY29yZGluZyB0
byBbM10sIHRoZSB0ZXJtICdjb25mZXJlbmNpbmcnIGlzIGNvbnNpZGVyZWQgaW4gdGhlIA0KICAg
cmVtYWluZGVyIG9mIHRoaXMgZG9jdW1lbnQgYXMgc3luY2hyb25vdXMsIHJlYWwtdGltZSBjb21t
dW5pY2F0aW9uLCANCiAgIHNwZWNpZmljYWxseSBpbmNsdWRpbmcgYXVkaW8gYW5kIHZpZGVvIG1l
ZGlhIGJ1dCBhbHNvIHNoYXJlZCBkYXRhIA0KICAgbWVkaWEgc3VjaCBhcyB3aGl0ZWJvYXJkcywg
YW1vbmcgYSBzZXQgb2YgbWVtYmVycy4gU2V2ZXJhbCwgcHJvYmFibHkgDQogICBpbmRlcGVuZGVu
dGx5IGltcGxlbWVudGVkLCBhZ2VudHMgZm9yIG1lZGlhIGhhbmRsaW5nIGFuZCBjb250cm9sIA0K
ICAgcHVycG9zZXMgaGF2ZSB0byBiZSBjb29yZGluYXRlZCBhbmQgc3luY2hyb25pemVkIGR1cmlu
ZyBydW50aW1lIG9mIA0KICAgdGhlIGNvbmZlcmVuY2UsIHJlZmVycmVkIHRvIGFzICdjb25mZXJl
bmNlIGNvdXJzZSBjb250cm9sJyBpbiB0aGUgDQogICBmb2xsb3dpbmcsIGFmdGVyIGNyZWF0aW5n
IHRoZSBpbml0aWFsIGNvbmZlcmVuY2Ugc3RhdGUgYXMgcGFydCBvZiANCiAgIHRoZSBjb25mZXJl
bmNpbmcgc2V0dXAgZnVuY3Rpb25hbGl0eS4gVGhlIHByb3ZpZGVkIGZ1bmN0aW9uYWxpdHkgDQog
ICB3aXRoIHJlc3BlY3QgdG8gY29uZmVyZW5jZSBjb3Vyc2UgY29udHJvbCB1c3VhbGx5IGRlcGVu
ZHMgb24gdGhlIA0KICAgY29uc2lkZXJlZCBzY2VuYXJpbyBpbiB3aGljaCBpdCBpcyBuZWVkZWQu
ICANCiAgICANCiAgIEluIHRoZSBmb2xsb3dpbmcsIHRoZSBzY29wZSBvZiBjb25mZXJlbmNpbmcg
Y291cnNlIGNvbnRyb2wgYXMgd2VsbCANCiAgIGFzIGEgcHJvYmxlbSBzdGF0ZW1lbnQgd2lsbCBi
ZSBwaW5wb2ludGVkLiBGdXJ0aGVybW9yZSwgc2NlbmFyaW9zIA0KICAgZm9yIG11bHRpbWVkaWEg
Y29uZmVyZW5jaW5nIGluIHRoZSBJbnRlcm5ldCBhcmUgY2F0ZWdvcml6ZWQsIA0KICAgcmVhY2hp
bmcgZnJvbSBzbWFsbCBjbG9zZWQgbWVldGluZ3MgdG8gbGFyZ2UgcGxlbmFyeSBzZXNzaW9ucyB3
aXRoIA0KICAgICANClRyb3NzZW4gICAgICAgICAgICAgICAgIEV4cGlyZXMgTm92ZW1iZXIgMjAw
MSAgICAgICAgICAgICAgICAgICAgIFsyXSANDA0KSW50ZXJuZXQgRHJhZnQgICAgIENvdXJzZSBD
b250cm9sIFByb2JsZW0gU3RhdGVtZW50ICAgICAgICAgICBNYXkgMjAwMSANCiAgICANCiAgICAN
CiAgIGhpZ2ggZmx1Y3R1YXRpb25zIHJlZ2FyZGluZyB0aGUgcGFydGljaXBhbnSScyBhY3Rpdml0
eSBhbmQgDQogICBpbnRlcmVzdHMuIFNpbmNlIHRoZSBmb2N1cyBvZiB0aGUgZG9jdW1lbnQgaXMg
b24gY29udHJvbCBpc3N1ZXMgaW4gDQogICBjb25mZXJlbmNpbmcsIGRhdGEgZGVsaXZlcnkgYXNw
ZWN0cyBhcmUgbGVmdCBvdXQgb2YgY29uc2lkZXJhdGlvbi4gDQogICAgDQogICBUaGUgc2NlbmFy
aW8gZmluZGluZ3MgYXJlIHRoZW4gdXNlZCB0byBkZWZpbmUgbW9kZWxzIGZvciBjb25mZXJlbmNl
IA0KICAgY291cnNlIGNvbnRyb2wgcHJvdmlzaW9uLiANCiAgICANCiAgIE1vcmVvdmVyLCBjdXJy
ZW50IGNvbmZlcmVuY2luZyBzb2x1dGlvbnMgYXJlIGJyaWVmbHkgZXZhbHVhdGVkIA0KICAgY29u
Y2VybmluZyB0aGVpciBzaG9ydGNvbWluZ3MgaW4gY29uZmVyZW5jZSBjb3Vyc2UgY29udHJvbCAN
CiAgIGZ1bmN0aW9uYWxpdHkuIEZpbmFsbHksIG5leHQgc3RlcHMgZm9yIGNvbmZlcmVuY2UgY291
cnNlIGNvbnRyb2wgDQogICBlZmZvcnRzIHdpbGwgYmUgcHJlc2VudGVkLiANCiAgICANCjIuICAg
ICBEZWZpbml0aW9uIG9mIFRlcm1zIA0KICAgIA0KICAgbyBBcHBsaWNhdGlvbiBzZXNzaW9uIChB
UyksIFNlc3Npb24gDQogICAgIFRoZSBzZXQgb2YgbWVkaWEgYWdlbnRzL2FwcGxpY2F0aW9ucyB0
aGF0IGFjdCBhcyBwZWVycyB0byBlYWNoICANCiAgICAgb3RoZXIgd2l0aGluIGEgY29uZmVyZW5j
ZS4gIEZvciByZWFsLXRpbWUgZGF0YSwgdGhpcyBnZW5lcmFsbHkgIA0KICAgICB3aWxsIGJlIGFu
IFJUUCBzZXNzaW9uOyBmb3Igb3RoZXIgYXBwbGljYXRpb24gcHJvdG9jb2xzLCBvdGhlciAgDQog
ICAgIGhvcml6b250YWwgcHJvdG9jb2xzIG1heSBkZWZpbmUgdGhlaXIgb3duIHR5cGUgb2Ygc2Vz
c2lvbiBjb25jZXB0LiAgDQogICAgDQogICBvIFBhcnRpY2lwYW50IA0KICAgICBBIGh1bWFuIGJl
aW5nIHRoYXQgdGFrZXMgcGFydCBpbiBhIGNvbmZlcmVuY2UsIGVpdGhlciBhY3RpdmVseSBvciAg
DQogICAgIHBhc3NpdmVseSBsaXN0ZW5pbmcuIA0KICAgIA0KICAgbyBBY3RpdmUgUGFydGljaXBh
bnQgDQogICAgIEEgcGFydGljaXBhbnQgb2YgYSBjb25mZXJlbmNlIGJlY29taW5nIHNlbmRlciBv
ZiBtZWRpYSBpbmZvcm1hdGlvbiAgDQogICAgIGR1cmluZyBsaWZldGltZSBvZiB0aGUgY29uZmVy
ZW5jZS4gDQogICAgDQogICBvIFBhc3NpdmUgUGFydGljaXBhbnQgDQogICAgIEEgcGFydGljaXBh
bnQgb2YgYSBjb25mZXJlbmNlIHBhc3NpdmVseSByZWNlaXZpbmcgdGhlIG1lZGlhICANCiAgICAg
aW5mb3JtYXRpb24gd2l0aG91dCBiZWNvbWluZyBzZW5kZXIgb2YgbWVkaWEgaW5mb3JtYXRpb24g
IA0KICAgICBkdXJpbmcgbGlmZXRpbWUgb2YgdGhlIGNvbmZlcmVuY2UuIA0KICAgIA0KICAgbyBN
ZW1iZXIgDQogICAgIFRoZSBzeXN0ZW0sIGluY2x1ZGluZyBzb2Z0d2FyZSBhbmQgaGFyZHdhcmUs
IHRoYXQgdGFrZXMgcGFydCBpbiBhICAgIA0KICAgICBjb21wdXRlciBjb25mZXJlbmNlLCByZXBy
ZXNlbnRpbmcgYSBzaW5nbGUgcGFydGljaXBhbnQuIA0KICAgIA0KICAgbyBQcm9maWxlIA0KICAg
ICBBbiBpbml0aWFsIGRlc2NyaXB0aW9uIG9mIHRoZSBjb25mZXJlbmNlLCBpbmNsdWRpbmcgYXNz
aWdubWVudCBvZiAgDQogICAgIHJvbGVzIHRvIHBhcnRpY3VsYXIgbWVtYmVycywgdGltZSBsaW1p
dHMgZm9yIHNwZWFrZXJzLCBhdHRyaWJ1dGVzICANCiAgICAgb2YgdGhlIGNvbmZlcmVuY2UgKG9w
ZW4vY2xvc2UsIGNvbmR1Y3RlZC9hbmFyY2hpYywgZXRjKS4gDQogICAgDQogICBvIENvbmZlcmVu
Y2UgU2V0dXAgYW5kIERpc2NvdmVyeSANCiAgICAgQWNjb3JkaW5nIHRvIFszXSwgYXNwZWN0cyBm
b3Igc2V0dGluZyB1cCBhbiBpbml0aWFsIGNvbmZlcmVuY2UgIA0KICAgICBTdGF0ZSBpbiBwYXJ0
aWNpcGF0aW5nIG1lbWJlcnMsIGluY2x1ZGluZyB0aGUgZXhjaGFuZ2Ugb2YgbWVkaWEgIA0KICAg
ICBhbmQgY2FwYWJpbGl0aWVzIGluZm9ybWF0aW9uIGFtb25nIHRoZSBzZXQgb2YgcGFydGljaXBh
bnRzLCBhcmUgIA0KICAgICBiZWluZyBhZGRyZXNzZWQgYnkgc2V0dXAgYW5kIGRpc2NvdmVyeSBm
dW5jdGlvbmFsaXR5LiANCiAgICANCiAgIG8gQ29uZmVyZW5jZSBDb3Vyc2UgQ29udHJvbCANCiAg
ICAgQWNjb3JkaW5nIHRvIFszXSwgYXNwZWN0cyB0byBjb250cm9sIHRoZSBjb25mZXJlbmNlIGR1
cmluZyBydW50aW1lICANCiAgICAgb2YgdGhlIGV2ZW50IGFyZSBiZWluZyBhZGRyZXNzZWQgYnkg
Y29uZmVyZW5jZSBjb3Vyc2UgY29udHJvbC4gDQogICAgDQogICAgIA0KVHJvc3NlbiAgICAgICAg
ICAgICAgICAgRXhwaXJlcyBOb3ZlbWJlciAyMDAxICAgICAgICAgICAgICAgICAgICAgWzNdIA0M
DQpJbnRlcm5ldCBEcmFmdCAgICAgQ291cnNlIENvbnRyb2wgUHJvYmxlbSBTdGF0ZW1lbnQgICAg
ICAgICAgIE1heSAyMDAxIA0KICAgIA0KICAgIA0KMy4gICAgIFNjb3BlIA0KICAgIA0KICAgVGhl
IHNjb3BlIG9mIGNvbmZlcmVuY2UgY291cnNlIGNvbnRyb2wgZnVuY3Rpb25hbGl0eSB3aWxsIGJl
IA0KICAgZGV2ZWxvcGVkIGFzIHBhcnQgb2YgdGhlIHNvbHV0aW9uIHNwYWNlLiBQb3NzaWJsZSBm
dW5jdGlvbmFsaXR5IA0KICAgaW5jbHVkZXM6IA0KICAgIA0KICAgbyAnY29uZmVyZW5jZSBjb250
ZXh0IGFkbWluaXN0cmF0aW9uJywgcHJvdmlkaW5nIG1lbWJlcnNoaXAgIA0KICAgICBhbmQgYXBw
bGljYXRpb24vc2Vzc2lvbiBpbmZvcm1hdGlvbiBhZG1pbmlzdHJhdGlvbiANCiAgIG8gJ21lbWJl
cnNoaXAgZW5mb3JjZW1lbnQnLCBwcm92aWRpbmcgbWVhbnMgdG8gZW5mb3JjZSBzcGVjaWZpYyAg
DQogICAgIGNvbmZlcmVuY2UgbWVtYmVyc2hpcCANCiAgIG8gJ2Zsb29yIGNvbnRyb2wnLCBwcm92
aWRpbmcgbWVhbnMgdG8gbWFwIHNvY2lhbCBwcm90b2NvbHMgb250byAgDQogICAgIGRpc3RyaWJ1
dGVkIGVudmlyb25tZW50cy4gSG93ZXZlciwgdGhlIHNlbWFudGljcyBvZiBzcGVjaWZpYyAgDQog
ICAgIHNvY2lhbCBwcm90b2NvbHMgaXMgbm90IHdpdGhpbiB0aGUgc2NvcGUgb2YgdGhlIHBvc3Np
YmxlICANCiAgICAgY29uZmVyZW5jZSBjb3Vyc2UgY29udHJvbCBzb2x1dGlvbi4gDQogICBvICdh
Y3RpdmUvcGFzc2l2ZSBtZW1iZXIgc3VwcG9ydCcsIGFsbG93aW5nIGZvciBkaWZmZXJlbnQgcG9s
aWNpZXMgIA0KICAgICB3aXRoIHJlc3BlY3QgdG8gbWVtYmVyc2hpcCBhbmQgZmxvb3IgY29udHJv
bC4gVGhpcyBpbmNsdWRlcyAgDQogICAgIGNoYW5nZXMgZnJvbSBhY3RpdmUgdG8gcGFzc2l2ZSBh
bmQgdmljZSB2ZXJzYSwgZWl0aGVyIGltcGxpY2l0bHkgIA0KICAgICBvciBleHBsaWNpdGx5LiAN
CiAgIG8gJ2NhcGFiaWxpdGllcyByZS1uZWdvdGlhdGlvbicsIGFsbG93aW5nIGZvciBjaGFuZ2Vz
IGluICANCiAgICAgdGhlIGluaXRpYWwgY2FwYWJpbGl0aWVzIHNldCBvZiBwYXJ0aWNpcGFudHMg
ZHVyaW5nIHJ1bnRpbWUgb2YgdGhlICANCiAgICAgY29uZmVyZW5jZS4gDQogICAgDQogICBUaGlz
IGxpc3QgZG9lcyBub3QgY2xhaW0gdG8gYmUgZXhoYXVzdGl2ZS4gSG93ZXZlciwgaXQgcG9pbnRz
IGluIHRoZSANCiAgIGRpcmVjdGlvbiBvZiBwcm92aWRlZCBmdW5jdGlvbmFsaXR5IGZvciBjb25m
ZXJlbmNlIGNvdXJzZSBjb250cm9sIA0KICAgc29sdXRpb25zLiANCiAgICANCjQuICAgICBQcm9i
bGVtIFN0YXRlbWVudCANCiAgICANCiAgIFRoZXJlIGFyZSBtYW55IGFwcHJvYWNoZXMgaW4gdGhl
IHJlc2VhcmNoIGNvbW11bml0eSB0byByZWFsaXplIA0KICAgY29uZmVyZW5jZSBjb3Vyc2UgY29u
dHJvbCBhcyBwYXJ0IG9mIGEgY29uZmVyZW5jaW5nIGFyY2hpdGVjdHVyZS4gDQogICBBbHNvIGlu
IHN0YW5kYXJkaXphdGlvbiBib2RpZXMgKHN1Y2ggYXMgSC4zMjMgWzddIG9yIFNDQ1AgWzFdKSwg
DQogICBjb25mZXJlbmNlIGNvdXJzZSBjb250cm9sIGhhcyBiZWVuIGFkZHJlc3NlZC4gSG93ZXZl
ciwgbm9uZSBvZiB0aGVzZSANCiAgIGFwcHJvYWNoZXMgb2ZmZXJzIGEgdW5pZmllZCBhbmQgZmxl
eGlibGUgc29sdXRpb24gZm9yIGNvbmZlcmVuY2UgDQogICBjb3Vyc2UgY29udHJvbCB0byBjb3Zl
ciB0aGUgc3BlY3RydW0gb2Ygc2NlbmFyaW9zIG91dGxpbmVkIGluIA0KICAgU2VjdGlvbiA1LiAN
CiAgICANCiAgIFNwZWNpZmljYWxseSwgYSBjb25mZXJlbmNlIGNvdXJzZSBjb250cm9sIHNvbHV0
aW9uIHNob3VsZCANCiAgICANCiAgIG8gZml0IGludG8gdGhlIGFscmVhZHkgZGVmaW5lZCBjb25m
ZXJlbmNlIGNvbnRyb2wgYXJjaGl0ZWN0dXJlIGFuZCAgDQogICAgIGxldmVyYWdlIHRoZSBleGlz
dGluZyBzdWl0ZSBvZiBtZWNoYW5pc21zIGFuZCBwcm90b2NvbHMsIHN1Y2ggYXMgIA0KICAgICAq
IGNvbmZlcmVuY2UgZGVzY3JpcHRpb24sIGkuZS4sIFNEUCBbNF0gb3IgZnV0dXJlIHZlcnNpb25z
IChTREctbmcgIA0KICAgICAgIFs5XSksIGFuZCBpbml0aWF0aW9uLCBpLmUuLCBTSVAgWzVdIA0K
ICAgICAqIGxvY2FsIGNvb3JkaW5hdGlvbiwgaS5lLiwgTUJVUyBbMTBdIA0KICAgICAqIHRyYW5z
cG9ydCBsYXllciBwcm90b2NvbHMsIHN1Y2ggYXMgZm9yIHJlbGlhYmxlIG11bHRpY2FzdCwgcmVh
bC0gDQogICAgICAgdGltZSB0cmFuc2Zlciwgb3Igc2ltcGxlIHVuaWNhc3QgdHJhbnNtaXNzaW9u
IA0KICAgICAqIHNlY3VyaXR5IGNvbXBvbmVudHMsIHN1Y2ggYXMgZ3JvdXAga2V5IHNvbHV0aW9u
cyANCiAgIG8gcHJvdmlkZSBhIGZsZXhpYmxlIHNvbHV0aW9uLCBhbGxvd2luZyBmb3IgYSB2YXJp
ZXR5IG9mIHNjZW5hcmlvcyAgDQogICAgIChzZWUgU2VjdGlvbiA1KSBhbmQgY2hhcmFjdGVyaXN0
aWNzIHRvIGJlIHBsdWdnZWQgaW4gdGhlIHN5c3RlbS4gIA0KICAgIA0KICAgRm9yIHRoYXQsIGEg
YnVpbGRpbmcgYmxvY2sgYXBwcm9hY2ggd291bGQgYWxsb3cgdGhlIHByb3Zpc2lvbiBvZiANCiAg
IHN0YW5kYXJkaXplZCBpbnRlcmZhY2VzIHRvIHRoZSBkZXNpcmVkIGNvbW1vbiBmdW5jdGlvbmFs
aXR5LiBXaXRoIA0KICAgdGhhdCwgc3BlY2lmaWMgc2NlbmFyaW8tdGFpbG9yZWQgaW5zdGFudGlh
dGlvbnMgZm9yIGNlcnRhaW4gDQogICBmdW5jdGlvbmFsaXR5LCByZXByZXNlbnRlZCBieSBhIGJ1
aWxkaW5nIGJsb2NrLCBhcmUgZW5hYmxlZCANCiAgICAgDQpUcm9zc2VuICAgICAgICAgICAgICAg
ICBFeHBpcmVzIE5vdmVtYmVyIDIwMDEgICAgICAgICAgICAgICAgICAgICBbNF0gDQwNCkludGVy
bmV0IERyYWZ0ICAgICBDb3Vyc2UgQ29udHJvbCBQcm9ibGVtIFN0YXRlbWVudCAgICAgICAgICAg
TWF5IDIwMDEgDQogICAgDQogICAgDQogICBwcmVzZXJ2aW5nIHRoZSBjb21tb24gdmlldyBvZiB0
aGUgY29uZmVyZW5jZSBjb3Vyc2UgY29udHJvbCANCiAgIGZ1bmN0aW9uYWxpdHkuIA0KICAgIA0K
ICAgIA0KNS4gICAgIENvbmZlcmVuY2luZyBTY2VuYXJpb3MgDQogICAgDQogICBUaGlzIHNlY3Rp
b24gaW5mb3JtYWxseSBvdXRsaW5lcyBzY2VuYXJpbyBjYXRlZ29yaWVzIGZvciBtdWx0aW1lZGlh
IA0KICAgY29uZmVyZW5jaW5nIGluIHRoZSBJbnRlcm5ldC4gIA0KICAgIA0KICAgVGhlIGNvbmZl
cmVuY2luZyBzY2VuYXJpb3MgYXJlIGNhdGVnb3JpemVkIGluIHRocmVlIHNlY3Rpb25zLiBGb3Ig
DQogICBlYWNoIGNhdGVnb3J5LCB0eXBpY2FsIGNoYXJhY3RlcmlzdGljcyBhcmUgb3V0bGluZWQs
IGFuZCBleGFtcGxlcyANCiAgIGFyZSBnaXZlbi4gRmluYWxseSwgYSB0YWJsZS13aXNlIG92ZXJ2
aWV3IGlzIGRlcml2ZWQgZnJvbSB0aGUgbW9yZSANCiAgIGluZm9ybWFsIGRlc2NyaXB0aW9uIHBp
bnBvaW50aW5nIHRoZSB2ZXJ5IGZ1bmN0aW9uYWxpdHkgcmVxdWlyZWQgZm9yIA0KICAgdGhlIHNw
ZWNpZmljIHNjZW5hcmlvcy4gVGhpcyB0YWJsZS13aXNlIGRlc2NyaXB0aW9uIHdpbGwgYmUgdXNl
ZCBpbiANCiAgIFNlY3Rpb24gNSB0byBkaXNjdXNzIGNvbmZlcmVuY2UgY291cnNlIGNvbnRyb2wg
bW9kZWxzLiANCiAgICANCiAgIEl0IGlzIHdvcnRoIG1lbnRpb25pbmcgdGhhdCBzaW1wbGUgc3Ry
ZWFtaW5nIGlzIG5vdCBjb25zaWRlcmVkIGluIA0KICAgdGhlIGZvbGxvd2luZyBkdWUgdG8gaXRz
IGxhY2sgb2YgY29uZmVyZW5jZSBjb3Vyc2UgY29udHJvbCANCiAgIGZ1bmN0aW9uYWxpdHkuIEhv
d2V2ZXIsIGl0IG1pZ2h0IGJlIHVzZWQgdG8gcmVhbGl6ZSB2ZXJ5IHNpbXBsZSANCiAgIGNvbmZl
cmVuY2luZyBzY2VuYXJpb3Mgc3VjaCBhcyBJbnRlcm5ldCBsZWN0dXJlcywgd2hlcmUgZGF0YSBp
cyANCiAgIHNpbXBseSBzZW50IHRvIGEgc2V0IG9mIHJlY2VpdmVycyB3aXRob3V0IGZlZWRiYWNr
IG9yIGludGVyYWN0aW9uLiAgDQogICAgDQo1LjEuICAgU2ltcGxlIENvbmZlcmVuY2luZyANCiAg
ICANCiAgICdTaW1wbGUgQ29uZmVyZW5jaW5nJyByZWZsZWN0cyB0aGUgc2ltcGxlc3QgZm9ybSBv
ZiBjb25mZXJlbmNpbmcgDQogICB3aXRoIGEgY2hhbmdlIG9mIHRoZSBzZW5kZXIvcmVjZWl2ZXIg
cmVsYXRpb24gYmFzZWQgb24gY2VydGFpbiANCiAgICdzb2NpYWwgcnVsZXMnIGR1cmluZyB0aGUg
bGlmZXRpbWUgb2YgdGhlIGNvbmZlcmVuY2UuIA0KICAgIA0KICAgQ29uZmVyZW5jZXMgb2YgdGhp
cyB0eXBlIG1pZ2h0IGJlIGFubm91bmNlZCBiZWZvcmVoYW5kLCBpbmNsdWRpbmcgDQogICB0aGUg
Y29uZmVyZW5jZZJzIHByb2ZpbGUgaW5mb3JtYXRpb24sIG9yIHRoZXkgdGFrZSBwbGFjZSBhcyBh
ZC1ob2MgDQogICBtZWV0aW5ncy4gIA0KICAgIA0KICAgVGhlIGdyb3VwIG9mIHBhcnRpY2lwYW50
cyBtaWdodCBiZSB3ZWxsLWtub3duLCBpZiBhbm5vdW5jZWQsIG9yIGJlIA0KICAgYnVpbHQgYnkg
aW52aXRhdGlvbiBvciByZXF1ZXN0LiBGb3IgdGhhdCwgc2V2ZXJhbCBpbml0aWF0aW9uIG1vZGVs
cyANCiAgIG1pZ2h0IGJlIHJlYWxpemVkIChzZWUgYWxzbyBbMTFdKSwgd2hpY2ggcmVxdWlyZXMg
YXBwcm9wcmlhdGUgDQogICBpbml0aWF0aW9uIGZ1bmN0aW9uYWxpdHkgaW5jbHVkaW5nIGF1dGhl
bnRpY2F0aW9uIGFuZCBhdXRob3JpemF0aW9uIA0KICAgbWVhbnMgZm9yIHJlc3RyaWN0ZWQgYWNj
ZXNzIHRvIHRoZSBjb25mZXJlbmNlLiAgDQogICAgDQogICBGbG9vciBjb250cm9sIGZ1bmN0aW9u
YWxpdHksIGUuZy4sIHRvIHJlYWxpemUgY29uZHVjdGVkIG1lZXRpbmcgDQogICBmdW5jdGlvbmFs
aXR5LCBpcyBub3QgcHJvdmlkZWQgaW4gdGhpcyBjYXRlZ29yeS4gRHVlIHRvIHRoaXMgbGFjayBv
ZiANCiAgIG1lZGlhdGlvbiBjb25jZXJuaW5nIHRoZSBhY2Nlc3Mgb24gdGhlIGNvbW1vbiBtZWRp
YSByZXNvdXJjZSwgdGhlIA0KICAgbGV2ZWwgb2YgaW50ZXJhY3Rpdml0eSBpcyB1c3VhbGx5IGxp
bWl0ZWQsIGV2ZW4gaWYgc2NhbGFibGUgDQogICBtdWx0aWNhc3QgdHJhbnNmZXIgaXMgdXNlZC4g
IA0KICAgIA0KICAgVXN1YWxseSwgdGhlIGluaXRpYWwgc2V0IG9mIGNhcGFiaWxpdGllcyBpcyBu
b3QgY2hhbmdlZCwgaS5lLiwgcmUtDQogICBuZWdvdGlhdGVkLCBkdXJpbmcgcnVudGltZSBvZiB0
aGUgY29uZmVyZW5jZS4gSG93ZXZlciwgc29tZSBzaW1wbGUgDQogICBmb3JtIG9mIHJlLW5lZ290
aWF0aW9uIGNvdWxkIGJlIHByb3ZpZGVkLiANCiAgICANCiAgIEFsdGhvdWdoIHRoZSBudW1iZXIg
b2YgcGFydGljaXBhbnRzIGNhbiBlYXNpbHkgcmVhY2ggc2V2ZXJhbCANCiAgIHRob3VzYW5kcyBv
ciBldmVuIG1vcmUsIHdoZW4gdXNpbmcgbXVsdGljYXN0IHRyYW5zZmVyIGNhcGFiaWxpdGllcywg
DQogICBpdCBpcyBleHBlY3RlZCB0aGF0IHRoZSByZXF1aXJlbWVudHMgZm9yIHByZWNpc2UgbWVt
YmVyc2hpcCANCiAgIGluZm9ybWF0aW9uIGFyZSBsZXNzIHN0cmluZ2VudCBpbiBsYXJnZXIgc2Nh
bGVkIGNvbmZlcmVuY2VzLiANCiAgICANCiAgICAgDQpUcm9zc2VuICAgICAgICAgICAgICAgICBF
eHBpcmVzIE5vdmVtYmVyIDIwMDEgICAgICAgICAgICAgICAgICAgICBbNV0gDQwNCkludGVybmV0
IERyYWZ0ICAgICBDb3Vyc2UgQ29udHJvbCBQcm9ibGVtIFN0YXRlbWVudCAgICAgICAgICAgTWF5
IDIwMDEgDQogICAgDQogICAgDQo1LjEuMS4gRXhhbXBsZXMgDQogICAgDQogICBFeGFtcGxlcyBm
b3Igc2ltcGxlIGNvbmZlcmVuY2luZyBpbmNsdWRlIGFkLWhvYyBvciBwcmUtcGxhbm5lZCBzbWFs
bCANCiAgIGdyb3VwIG1lZXRpbmdzLCByaWNoIGNhbGxzLCBJbnRlcm5ldCBsZWN0dXJlcywgdGVs
ZS13b3JraW5nIGluIGEgDQogICB0ZWFtLiBNb3N0IG9mIHRoZSBjdXJyZW50IE1Cb25lIFsyXSBz
ZXNzaW9ucyBhcmUgdHlwaWNhbCBleGFtcGxlcyANCiAgIGZvciBzaW1wbGUgY29uZmVyZW5jaW5n
LiANCiAgICANCjUuMi4gICBGbG9vciBDb250cm9sbGVkIENvbmZlcmVuY2luZyANCiAgICANCiAg
IFNjZW5hcmlvcyBvZiB0aGlzIGNhdGVnb3J5IGVucmljaCB0aGUgc2ltcGxlIGNvbmZlcmVuY2lu
ZyANCiAgIGZ1bmN0aW9uYWxpdHkgb2Ygc2VjdGlvbiA1LjEuIGJ5IHByb3ZpZGluZyBmbG9vciBj
b250cm9sIGZhY2lsaXRpZXMgDQogICB0byBjb250cm9sIHRoZSBhY2Nlc3Mgb24gZGlzdHJpYnV0
ZWQgcmVzb3VyY2VzLiBBbW9uZyBvdGhlcnMsIHRoZXNlIA0KICAgZGlzdHJpYnV0ZWQgcmVzb3Vy
Y2VzIG1pZ2h0IHJlZmxlY3QgdGhlIGNvbW1vbmx5IHVzZWQgYXVkaW92aXN1YWwgDQogICBjaGFu
bmVsIHdpdGhpbiB0aGUgY29uZmVyZW5jZSBidXQgYWxzbyB0aGUgY29udGVudCBvZiBhIHNoYXJl
ZCANCiAgIHdoaXRlYm9hcmQsIG9yIGEgc2hhcmVkLCBsb2NhbGx5IGhvc3RlZCBhcHBsaWNhdGlv
bi4gVGhlIGZsb29yIA0KICAgY29udHJvbCBzZW1hbnRpY3MgYXJlIHVzdWFsbHkga25vd24gYmVm
b3JlaGFuZCwgb3IgdGhleSBtaWdodCBiZSANCiAgIGRpc3RyaWJ1dGVkIHVzaW5nIHRoZSBjb25m
ZXJlbmNlIHByb2ZpbGUgaW5mb3JtYXRpb24uIFRoZSANCiAgIHJlYWxpemF0aW9uIG9mIHRoZSBm
bG9vciBjb250cm9sIHNlbWFudGljcyBpcyB1c3VhbGx5IGhpZ2hseSANCiAgIGFwcGxpY2F0aW9u
LXNwZWNpZmljLiANCiAgICANCiAgIEZvciBpbnN0YW5jZSwgZmxvb3IgY29udHJvbGxlZCBjb25m
ZXJlbmNpbmcgbWlnaHQgYWxsb3cgJ2NvbmR1Y3RlZCANCiAgIG1lZXRpbmdzJywgZW5hYmxpbmcg
dGhlIGNvbmR1Y3RvciBvZiBhIGNvbmZlcmVuY2UgZm9yIGluc3RhbmNlIHRvIA0KICAgZWplY3Qg
cGFydGljaXBhbnRzIGZyb20gYSBjb25mZXJlbmNlIG9yIHRvIGRlbnkgYWNjZXNzIHRvIHRoZSAN
CiAgIGNvbmZlcmVuY2UuIEhvd2V2ZXIsIGluIGFkZGl0aW9uIHRvIHRoZSByZWFsaXphdGlvbiBv
ZiB0aGUgc29jaWFsIA0KICAgcnVsZXMgYnkgbWVhbnMgb2YgZmxvb3IgY29udHJvbCwgYXBwcm9w
cmlhdGUgZnVuY3Rpb25hbGl0eSB0byANCiAgIGVuZm9yY2UgdGhlbSBvbiBkYXRhIGxldmVsIGlz
IHJlcXVpcmVkIGJ5IG1lYW5zIG9mIGV4Y2x1ZGluZyANCiAgIHJlY2VpdmVyIHNldHMgZnJvbSBy
ZWNlcHRpb24uIA0KICAgIA0KICAgQ2FwYWJpbGl0aWVzIHJlLW5lZ290aWF0aW9uIGlzIHVzdWFs
bHkgcHJvdmlkZWQgaW4gdGhlc2Ugc2NlbmFyaW9zLCANCiAgIHdoaWNoIG1pZ2h0IGFsc28gYmUg
dGllZCB0byB0aGUgaW1wbGVtZW50ZWQgZmxvb3IgY29udHJvbCBwb2xpY3kgb2YgDQogICB0aGUg
c3BlY2lmaWMgc2NlbmFyaW8uIA0KICAgIA0KICAgSW4gZmxvb3IgY29udHJvbGxlZCBjb25mZXJl
bmNlcywgdGhlcmUgaXMgYW4gZXhhY3Qga25vd2xlZGdlIG9mIHRoZSANCiAgIGN1cnJlbnQgbWVt
YmVyc2hpcCBpbmZvcm1hdGlvbiBvZiB0aGUgcGFydGljaXBhbnRzLiBVc3VhbGx5LCB0aGUgDQog
ICBpbXBsZW1lbnRhdGlvbiBvZiB0aGUgZmxvb3IgY29udHJvbCByZXN0cmljdHMgdGhlIHNjYWxh
YmlsaXR5IG9mIA0KICAgdGhpcyB0eXBlIG9mIGNvbmZlcmVuY2VzIHRvIGEgZmV3IHRlbnMuIEhv
d2V2ZXIsIGFwcHJvYWNoZXMgYXMgDQogICBwcm9wb3NlZCBpbiBbMTNdLCBtaWdodCBiZSB1c2Vk
IGluIHNwZWNpZmljIHNjZW5hcmlvcyB0byBpbXByb3ZlIHRoZSANCiAgIHNjYWxhYmlsaXR5LiAN
CiAgICANCjUuMi4xLiBFeGFtcGxlcyANCiAgICANCiAgIEV4YW1wbGVzIGZvciBmbG9vciBjb250
cm9sbGVkIGNvbmZlcmVuY2VzIGluY2x1ZGUgc2NlbmFyaW9zIHdpdGggdGhlIA0KICAgbmVlZCB0
byByZWFsaXplIHNvY2lhbCBydWxlcyBvciBhY2Nlc3MgY29udHJvbCBvbiBzaGFyZWQgcmVzb3Vy
Y2VzLCANCiAgIHN1Y2ggYXMgY29uZHVjdGVkIG1lZXRpbmdzLCBhcHBsaWNhdGlvbiBzaGFyaW5n
IHNlc3Npb25zLCBkaXN0YW5jZSANCiAgIGxlYXJuaW5nIGluY2x1ZGluZyBkZW1vbnN0cmF0aW9u
IG9mIHNoYXJlZCBpbmZvcm1hdGlvbiwgdGVsZS13b3JraW5nIA0KICAgd2l0aCBjb21tb24gcmVz
b3VyY2VzIHRvIHNoYXJlLiANCiAgICANCjUuMy4gICBSaWNoIENvbmZlcmVuY2luZyANCiAgICAN
CiAgIEEgJ3JpY2ggY29uZmVyZW5jaW5nJyBldmVudCwgd2hpY2ggaXMgZ29pbmcgdG8gaGFwcGVu
LCBtaWdodCBiZSANCiAgIGFubm91bmNlZCBiZWZvcmVoYW5kIGJ1dCBhbiBhZC1ob2MgZXN0YWJs
aXNobWVudCBtaWdodCBhbHNvIGJlIA0KICAgY29uc2lkZXJlZCwgc3VjaCBhcyBhICdyYW5kb21s
eSBnYXRoZXJpbmcgYSBjcm93ZCBhcm91bmQgYW4gDQogICAgIA0KVHJvc3NlbiAgICAgICAgICAg
ICAgICAgRXhwaXJlcyBOb3ZlbWJlciAyMDAxICAgICAgICAgICAgICAgICAgICAgWzZdIA0MDQpJ
bnRlcm5ldCBEcmFmdCAgICAgQ291cnNlIENvbnRyb2wgUHJvYmxlbSBTdGF0ZW1lbnQgICAgICAg
ICAgIE1heSAyMDAxIA0KICAgIA0KICAgIA0KICAgYXR0cmFjdGlvbicuIEF1dGhlbnRpY2F0aW9u
IGFuZCBhdXRob3JpemF0aW9uIG1lYW5zIG1pZ2h0IGJlIHVzZWQgDQogICBmb3IgcmVzdHJpY3Rl
ZCBhY2Nlc3MgdG8gdGhlIGV2ZW50LiANCiAgICANCiAgIFVzdWFsbHksIHRoZXJlIGlzIGEgKHNt
YWxsKSB3ZWxsLWtub3duIGdyb3VwIG9mIGFjdGl2ZSBwYXJ0aWNpcGFudHMsIA0KICAgaS5lLiwg
ZXhhY3QgbWVtYmVyc2hpcCBpbmZvcm1hdGlvbiBpcyByZXF1aXJlZCwgYW5kIGEgbGFyZ2VyIGdy
b3VwIA0KICAgb2YgcGFzc2l2ZSBwYXJ0aWNpcGFudHMuIE1lbWJlcnNoaXAgaW5mb3JtYXRpb24g
Zm9yIHRoaXMgbGFyZ2VyIA0KICAgZ3JvdXAgaXMgbGVzcyBzdHJpY3RseSBwcm92aWRlZCwgY29t
cGFyYWJsZSB3aXRoICdibHVlIHNoZWV0cycgDQogICBhdHRlbmRlZXMgbGlzdHMuICANCiAgICAN
CiAgIFRoZSBhY2Nlc3MgY29udHJvbCB3aXRoaW4gdGhlIGdyb3VwIG9mIGFjdGl2ZSBwYXJ0aWNp
cGFudHMgaXMgDQogICByZWFsaXplZCBieSBtZWFucyBvZiBmbG9vciBjb250cm9sIHJlYWxpemlu
ZyBzcGVjaWZpYyBzb2NpYWwgDQogICBpbnRlcmFjdGlvbnMgKGNvbmR1Y3RlZCBzZXNzaW9uLCBw
YW5lbCBncm91cCkgc2ltaWxhciB0byBmbG9vciANCiAgIGNvbnRyb2xsZWQgY29uZmVyZW5jaW5n
LiANCiAgICANCiAgIEFzIGEgc3BlY2lmaWMgY2hhcmFjdGVyaXN0aWMgb2YgdGhpcyBjYXRlZ29y
eSwgZnJlcXVlbnQgY2hhbmdlcyANCiAgIGJldHdlZW4gYWN0aXZlIGFuZCBwYXNzaXZlIHBhcnRp
Y2lwYXRpb24gaW4gdGhlIGNvbmZlcmVuY2UgYXJlIA0KICAgaGFwcGVuaW5nLCBlLmcuLCBhIHBh
c3NpdmUgb2JzZXJ2ZXIgKHBhcnRpY2lwYW50KSBvZiB0aGUgZXZlbnQgbWlnaHQgDQogICByYWlz
ZSBpdHMgaW50ZXJlc3QgaW4gYmVjb21pbmcgYWN0aXZlIGluIHRoZSBkaXNjdXNzaW9uLCBlaXRo
ZXIgYnkgDQogICBvd24gcmVxdWVzdCBvciBieSBpbnZpdGF0aW9uLCBmb2xsb3dpbmcgdGhlIHNw
ZWNpZmljIGFjY2VzcyBydWxlcyBvZiANCiAgIHRoZSBhY3RpdmUgcGFydGljaXBhbnQgZ3JvdXAg
aW1wbGVtZW50ZWQgYnkgYXBwcm9wcmlhdGUgZmxvb3IgDQogICBjb250cm9sIG1lYW5zLiBUaGUg
bW9kZSBjaGFuZ2UgY291bGQgaGFwcGVuICdleHBsaWNpdGx5JywgaS5lLiwgYnkgDQogICBqb2lu
aW5nIHRoZSBhY3RpdmUgbWVtYmVyIGdyb3VwLCBvciAnaW1wbGljaXRseScsIGkuZS4sIGJ5IA0K
ICAgcmVxdWVzdGluZyBmbG9vciBjb250cm9sIHNlcnZpY2VzLiANCiAgICANCiAgIFRoaXMgbW9k
ZSBjaGFuZ2Ugc2hvdWxkIGJlIHBvc3NpYmxlIGluIHRoZSByZXZlcnNlIGRpcmVjdGlvbiwgdG9v
LCANCiAgIGkuZS4sIHdoZW4gYW4gYWN0aXZlIHBhcnRpY2lwYW50IGxvb3NlcyBpbnRlcmVzdCBp
biBhY3RpdmUgDQogICBwYXJ0aWNpcGF0aW9uLiANCiAgICANCjUuMy4xLiBFeGFtcGxlcyANCiAg
ICANCiAgIEV4YW1wbGVzIGZvciBsYXJnZSBzY2FsZSByaWNoIGNvbmZlcmVuY2luZyBzY2VuYXJp
b3MgYXJlIHRvd24gaGFsbCANCiAgIG1lZXRpbmdzLCBJRVRGIHdvcmtpbmcgZ3JvdXAgbWVldGlu
Z3MsIHZpcnR1YWwgbGVjdHVyZXMgd2l0aCANCiAgIGZlZWRiYWNrLCB2aXJ0dWFsIG5ld3Nncm91
cHMuIEhvd2V2ZXIsIGV4YW1wbGVzIGZvciBzaW1wbGUgYW5kIGZsb29yIA0KICAgY29udHJvbGxl
ZCBjb25mZXJlbmNpbmcgYXJlIGFsc28gYXBwbGljYWJsZSBmb3IgdGhpcyBjYXRlZ29yeSBkdWUg
dG8gDQogICB0aGUgc3VwZXJzZXQgY2hhcmFjdGVyIG9mIHRoZSByaWNoIGNvbmZlcmVuY2luZyBj
YXRlZ29yeSBjb21wYXJlZCB0byANCiAgIHRoZSBvdGhlciBvbmVzLiANCiAgICANCjUuNC4gICBT
dW1tYXJ5IG9mIENoYXJhY3RlcmlzdGljcyANCiAgICANCiAgIFRoZSBmb2xsb3dpbmcgdGFibGUg
c3VtbWFyaXplcyB0aGUgbWFpbiBjaGFyYWN0ZXJpc3RpY3MgZm9yIHRoZSANCiAgIGRpZmZlcmVu
dCBzY2VuYXJpbyBjYXRlZ29yaWVzIHByZXNlbnRlZCBpbiBzZWN0aW9uIDUuMS4gdG8gNS4zLiAN
CiAgICcoKyknIGluZGljYXRlcyBvcHRpb25hbCBmdW5jdGlvbmFsaXR5LiAgDQogICAgDQogICBU
aGUgZmlyc3QgYmxvY2sgb2YgY2hhcmFjdGVyaXN0aWNzIGlzIHJlZmVycmVkIHRvIGFzIGNvbmZl
cmVuY2UgDQogICBpbml0aWF0aW9uIGFuZCBzZXR1cCAoc2VlIFszXSksIHdoaWxlIHRoZSBzZWNv
bmQgYmxvY2sgaXMgZGVkaWNhdGVkIA0KICAgdG8gY29uZmVyZW5jZSBjb3Vyc2UgY29udHJvbCBm
dW5jdGlvbmFsaXR5LiANCiAgICANCiAgICANCiAgICANCiAgIC0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIA0KICAgfCBGdW5jdGlv
bmFsaXR5ICAgIHwgIFNpbXBsZSAgICAgfCAgICBGLkMuICAgICB8ICAgUmljaCAgICAgIHwgDQog
ICB8ICAgICAgICAgICAgICAgICAgfCAgIENvbmYuICAgICB8ICAgQ29uZi4gICAgIHwgICBDb25m
LiAgICAgfCANCiAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tIA0KICAgICANClRyb3NzZW4gICAgICAgICAgICAgICAgIEV4cGly
ZXMgTm92ZW1iZXIgMjAwMSAgICAgICAgICAgICAgICAgICAgIFs3XSANDA0KSW50ZXJuZXQgRHJh
ZnQgICAgIENvdXJzZSBDb250cm9sIFByb2JsZW0gU3RhdGVtZW50ICAgICAgICAgICBNYXkgMjAw
MSANCiAgICANCiAgICANCiAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIA0KICAgfCBQcm9maWxlIEluZi4gICAgIHwgICAgICAr
ICAgICAgfCAgICAgICsgICAgICB8ICAgICAgKyAgICAgIHwgDQogICB8ICAgICAgICAgICAgICAg
ICAgfCAgICAgICAgICAgICB8ICAgIGluY2wuICAgIHwgICAgaW5jbC4gICAgfCANCiAgIHwgICAg
ICAgICAgICAgICAgICB8ICAgICAgICAgICAgIHwgIGZsb29yIGluZi4gfCAgZmxvb3IgaW5mLiB8
IA0KICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0gDQogICB8IEluaXRpYXRpb24gICAgICAgfCAgYW5ub3VuY2VkICB8ICBhbm5v
dW5jZWQgIHwgIGFubm91bmNlZCAgfCANCiAgIHwgICAgICAgICAgICAgICAgICB8ICAgaW52aXRl
ZCAgIHwgICBpbnZpdGVkICAgfCAgIGludml0ZWQgICB8IA0KICAgLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gDQogICB8IENhcGFi
aWxpdGllcyAgICAgfCAgICAgKCspICAgICB8ICAgICAgKyAgICAgIHwgICAgICArICAgICAgfCAN
CiAgIHwgUmUtbmVnb3RpYXRpb24gICB8ICAgICAgICAgICAgIHwgICAgICAgICAgICAgfCAgICAg
ICAgICAgICB8IA0KICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0gDQogICB8IEF1dGhlbnRpY2F0aW9uICsgfCAgICAgKCspICAg
ICB8ICAgICAoKykgICAgIHwgICAgICgrKSAgICAgfCANCiAgIHwgQXV0aG9yaXphdGlvbiAgICB8
ICAgICAgICAgICAgIHwgICAgICAgICAgICAgfCAgICAgICAgICAgICB8IA0KICAgLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gDQog
ICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLSANCiAgIHwgTWVtYmVyc2hpcCBJbmZvICB8ICAgICAgKyAgICAgIHwgICAgICArICAg
ICAgfCAgICAgICsgICAgICB8IA0KICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gDQogICB8IEZsb29yIENvbnRyb2wgICAgfCAg
ICAgIC0gICAgICB8ICAgICAgKyAgICAgIHwgICAgKyAoZm9yICAgfCANCiAgIHwgICAgICAgICAg
ICAgICAgICB8ICAgICAgICAgICAgIHwgICAgICAgICAgICAgfCAgICBhY3RpdmUpICB8IA0KICAg
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0gDQogICB8IE1lbWJlcnNoaXAgICAgICAgfCAgYXQgc3RhcnR1cCB8IGJhc2VkIG9uICAg
IHwgYmFzZWQgb24gICAgfCANCiAgIHwgRW5mb3JjZW1lbnQgICAgICB8ICAgICBvbmx5ICAgIHwg
Zmxvb3IgY3RybCAgfCBmbG9vciBjdHJsICB8IA0KICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gDQogICB8IEFjdGl2ZS9QYXNz
aXZlICAgfCAgICAgIC0gICAgICB8ICAgICAgLSAgICAgIHwgICAgICArICAgICAgfCANCiAgIHwg
TW9kZSBDaGFuZ2UgICAgICB8ICAgICAgICAgICAgIHwgICAgICAgICAgICAgfCAgICAgICAgICAg
ICB8IA0KICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0gDQogICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSANCiAgIHwgU2NhbGUgICAgICAgICAgICB8IHNtYWxs
IGR1ZSB0b3wgZGVwZW5kcyBvbiAgfCAgIGxhcmdlICAgICB8IA0KICAgfCAgICAgICAgICAgICAg
ICAgIHwgbGFjayBvZiAgICAgfCBmbG9vciAgY3RybC58ICAgICAgICAgICAgIHwgDQogICB8ICAg
ICAgICAgICAgICAgICAgfCBtZWRpYXRpb24gICB8IHNjYWxlICAgICAgIHwgICAgICAgICAgICAg
fCANCiAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tIA0KICAgICAgICAgICAgICBUYWJsZSAxIDogU3VtbWFyeSBvZiBDaGFyYWN0
ZXJpc3RpY3MgDQogICAgDQogICBUaGUgZm9sbG93aW5nIEZpZ3VyZSAxIHRyaWVzIHRvIG91dGxp
bmUgdGhlIGNhdGVnb3JpZXMgb2YgdGhpcyANCiAgIHNlY3Rpb24gaW4gYSBzY2FsZS1mdW5jdGlv
bmFsaXR5IHNwYWNlLCBlbXBoYXNpemluZyB0aGUgc3VwZXJzZXQgDQogICBjaGFyYWN0ZXIgb2Yg
dGhlICdyaWNoIGNvbmZlcmVuY2luZycgY2F0ZWdvcnkuIA0KICAgIA0KICAgU2NhbGUgL3xcIA0K
ICAgICAgICAgIHx8LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS18IA0KICAgICAgICAgIHx8ICAgICAgICAgICAgICAgIFJpY2ggQ29uZmVyZW5jaW5nICAg
ICAgICAgICAgICAgICB8IA0KICAgICAgICAgIHx8ICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICB8IA0KICAgICAgICAgIHx8ICAgICAgICBUb3duIEhhbGwg
TWVldGluZ3MsIElFVEYgTWVldGluZ3MgICAgICAgICB8IA0KICAgICAgICAgIHx8fC0tLS0tLS0t
LS0tLS0tLS0tLS0tLS18fC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLXx8IA0KICAgICAgICAgIHx8
fCBTaW1wbGUgQ29uZmVyZW5jaW5nICB8fCBGbG9vciBDb250cm9sbGVkIENvbmYuIHx8IA0KICAg
ICAgICAgIHx8fCAgICAgICAgICAgICAgICAgICAgICB8fCAgICAgICAgICAgICAgICAgICAgICAg
IHx8IA0KICAgICAgICAgIHx8fCBMZWN0dXJlcywgTWVldGluZ3MgICB8fCBjb25kdWN0ZWQgbWVl
dGluZ3MgICAgIHx8IA0KICAgICAgICAgIHx8fC0tLS0tLS0tLS0tLS0tLS0tLS0tLS18fC0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLXx8IA0KICAgICAgICAgIHx8LS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIA0KICAgICAgICAgIHwtLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPiANCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBGdW5jdGlvbmFsaXR5IA0KICAgIA0K
ICAgICAgICAgICAgICBGaWd1cmUgMSA6IENhdGVnb3JpZXMgaW4gU2NhbGUtRnVuY3Rpb25hbGl0
eSBTcGFjZSANCiAgICANCiAgICAgDQpUcm9zc2VuICAgICAgICAgICAgICAgICBFeHBpcmVzIE5v
dmVtYmVyIDIwMDEgICAgICAgICAgICAgICAgICAgICBbOF0gDQwNCkludGVybmV0IERyYWZ0ICAg
ICBDb3Vyc2UgQ29udHJvbCBQcm9ibGVtIFN0YXRlbWVudCAgICAgICAgICAgTWF5IDIwMDEgDQog
ICAgDQogICAgDQo2LiAgICAgQ29uZmVyZW5jZSBDb3Vyc2UgQ29udHJvbCBNb2RlbHMgDQogICAg
DQogICBUaGUgY29uZmVyZW5jaW5nIHNjZW5hcmlvcyBpbiBTZWN0aW9uIDUgY2FuIGVhc2lseSBi
ZSBtYXBwZWQgb250byANCiAgIG1vZGVscyBmb3IgcmVhbGl6ZSBjb25mZXJlbmNlIGNvdXJzZSBj
b250cm9sIHJlYWxpemF0aW9uIHdpdGggDQogICByZXNwZWN0IHRvIHRoZSBmdW5jdGlvbmFsaXRp
ZXMgcHJlc2VudGVkIGluIFNlY3Rpb24gMi4gDQogICAgDQo2LjEuICAgTG9vc2UgQ29uZmVyZW5j
ZSBDb3Vyc2UgQ29udHJvbCANCiAgICANCiAgICdMb29zZScgY29uZmVyZW5jZSBjb3Vyc2UgY29u
dHJvbCAoYWxzbyByZWZlcnJlZCB0byBhcyAnbGlnaHQtd2VpZ2h0IA0KICAgc2Vzc2lvbiBjb250
cm9sJyBbM10pIGlzIHRoZSBtb2RlbCBhcHBsaWNhYmxlIGZvciB0aGUgc2ltcGxlIA0KICAgY29u
ZmVyZW5jaW5nIHNjZW5hcmlvIGNhdGVnb3J5IG9mIFNlY3Rpb24gNS4xLiAgDQogICAgDQogICBI
ZW5jZSwgdGhpcyBjb250cm9sIG1vZGVsIGxhY2tzIG9mIGV4cGxpY2l0IG1lbWJlcnNoaXAgYW5k
IA0KICAgYXBwbGljYXRpb24gc2Vzc2lvbiBjb250cm9sLiBGdXJ0aGVybW9yZSwgZmxvb3IgY29u
dHJvbCBmYWNpbGl0aWVzIA0KICAgYXJlIG5vdCBwcm92aWRlZC4gSG93ZXZlciwgbWVtYmVyc2hp
cCBpbmZvcm1hdGlvbiBtaWdodCBiZSBnYXRoZXJlZCANCiAgIGR1cmluZyBydW50aW1lIG9mIHRo
ZSBzZXNzaW9uLCBjb21wYXJhYmxlIHdpdGggdGhlIGJsdWUgc2hlZXRzIG9mIA0KICAgYXR0ZW5k
ZWVzLiANCiAgICANCiAgIFVzdWFsbHksIGdyb3VwIGtleSBtZWNoYW5pc21zIGFyZSBhbHNvIG1p
c3NpbmcgZm9yIG1lbWJlcnNoaXAgDQogICBlbmZvcmNlbWVudCBhZnRlciBzdGFydGluZyB0aGUg
Y29uZmVyZW5jZS4gDQogICAgDQo2LjIuICAgVGlnaHQgQ29uZmVyZW5jZSBDb3Vyc2UgQ29udHJv
bCANCiAgICANCiAgICdUaWdodCcgY29uZmVyZW5jZSBjb3Vyc2UgY29udHJvbCBbM10gaXMgdGhl
IG1vZGVsIGFwcGxpY2FibGUgZm9yIA0KICAgdGhlIGZsb29yIGNvbnRyb2wgY29uZmVyZW5jaW5n
IHNjZW5hcmlvIGNhdGVnb3JpZXMgb2YgU2VjdGlvbiA1LjIuIA0KICAgIA0KICAgSGVuY2UsIGFk
ZGl0aW9uYWwgZmxvb3IgY29udHJvbCBpbmZvcm1hdGlvbiBvZiB0aGUgY29uZmVyZW5jZSANCiAg
IHByb2ZpbGUgb3Igc3RhdGljYWxseSBpbXBsZW1lbnRlZCBhcHBsaWNhdGlvbiBzZW1hbnRpYyBh
cmUgdXNlZCBmb3IgDQogICBpbXBsZW1lbnRpbmcgZmxvb3IgY29udHJvbCB0byBtYXAgJ3NvY2lh
bCBwcm90b2NvbCcgc2VtYW50aWNzIG9udG8gDQogICB0aGUgZGlzdHJpYnV0ZWQgc2NlbmFyaW8u
IEV4YWN0IG1lbWJlcnNoaXAgYW5kIGFwcGxpY2F0aW9uIHNlc3Npb24gDQogICBpbmZvcm1hdGlv
biBpcyB1c3VhbGx5IHByb3ZpZGVkIHRvZ2V0aGVyIHdpdGggbWVtYmVyc2hpcCBlbmZvcmNlbWVu
dCANCiAgIGJhc2VkIG9uIGZsb29yIGNvbnRyb2wgcG9saWNpZXMgZHVyaW5nIHJ1bnRpbWUgb2Yg
dGhlIGNvbmZlcmVuY2UuIA0KICAgIA0KNi4zLiAgICdKZWxseS1saWtlJyBDb25mZXJlbmNlIENv
dXJzZSBDb250cm9sIA0KICAgIA0KICAgQXMgYSBjb21iaW5hdGlvbiBvZiB0aGUgbG9vc2UgYW5k
IHRpZ2h0IGNvbnRyb2wgbW9kZWwgb2YgU2VjdGlvbiANCiAgIDYuMS4gYW5kIDYuMi4sICdqZWxs
eS1saWtlJyBjb3Vyc2UgY29udHJvbCBpcyBjb25zaWRlcmVkIGZvciByaWNoIA0KICAgY29uZmVy
ZW5jaW5nIChzZWUgU2VjdGlvbiA1LjMuKSByZWFsaXphdGlvbi4gDQogICAgDQogICBUaGUgdGln
aHQgY29udHJvbCBtb2RlbCBpcyBhcHBsaWVkIGZvciB0aGUgYWN0aXZlIHBhcnRpY2lwYW50cyBp
biANCiAgIHRoZSBjb25mZXJlbmNlLCB3aGlsZSBhIGxvb3NlIGNvbnRyb2wgbW9kZWwgaXMgdXNl
ZCBmb3IgdGhlIHBhc3NpdmUgDQogICBvbmVzLiBJbiBhZGRpdGlvbiB0byB0aGUgZnVuY3Rpb25h
bGl0eSBmb3IgdGhlIHNwZWNpZmljIHVzZXIgZ3JvdXAsIA0KICAgaS5lLiwgYWN0aXZlIG9yIHBh
c3NpdmUsIG1lY2hhbmlzbXMgdG8gc3VwcG9ydCBtb2RlIGNoYW5nZXMgZnJvbSANCiAgIGFjdGl2
ZSB0byBwYXNzaXZlIGFuZCB2aWNlIHZlcnNhIG1pZ2h0IGJlIHJlcXVpcmVkIHdpdGhvdXQgDQog
ICBkaXN0dXJiYW5jZSwgaS5lLiwgaW50ZXJydXB0aW9uLCBvZiB0aGUgcnVubmluZyBjb25mZXJl
bmNlLiANCiAgICANCiAgIERpZmZlcmVudCBwb2xpY2llcyBmb3IgdGhpcyBtb2RlIGNoYW5nZSBz
aG91bGQgYmUgZmVhc2libGUsIHN1Y2ggYXMgDQogICB1cG9uIGludml0YXRpb24gYnkgaW5kaXZp
ZHVhbCBhY3RpdmUgcGFydGljaXBhbnRzIG9yIHVwb24gcmVxdWVzdCBvZiANCiAgIHRoZSBwYXNz
aXZlIHBhcnRpY2lwYW50LiANCiAgICANCjcuICAgICBFeGlzdGluZyBTb2x1dGlvbnMgDQogICAg
DQogICAgIA0KVHJvc3NlbiAgICAgICAgICAgICAgICAgRXhwaXJlcyBOb3ZlbWJlciAyMDAxICAg
ICAgICAgICAgICAgICAgICAgWzldIA0MDQpJbnRlcm5ldCBEcmFmdCAgICAgQ291cnNlIENvbnRy
b2wgUHJvYmxlbSBTdGF0ZW1lbnQgICAgICAgICAgIE1heSAyMDAxIA0KICAgIA0KICAgIA0KICAg
VGhlIGZvbGxvd2luZyBzZWN0aW9uIGlzIGJyaWVmbHkgZXZhbHVhdGluZyBleGlzdGluZyBjb25m
ZXJlbmNpbmcgDQogICBzb2x1dGlvbnMgd2l0aCByZXNwZWN0IHRvIHRoZWlyIGNvbmZlcmVuY2Ug
Y291cnNlIGNvbnRyb2wgDQogICBmdW5jdGlvbmFsaXR5LiBOb3RlIHRoYXQgdGhpcyBwcmVzZW50
YXRpb24gaXMgcmVzdHJpY3RlZCB0byBzeXN0ZW1zIA0KICAgYmFzZWQgb24gY2VydGFpbiBzdGFu
ZGFyZHMsIGhlbmNlIHRoaXMgbGlzdCBkb2VzIG5vdCBjbGFpbSB0byBiZSBhbiANCiAgIGV4aGF1
c3RpdmUgcmV2aWV3IG9mIGV4aXN0aW5nIGNvbmZlcmVuY2luZyBzeXN0ZW1zLiANCiAgICANCiAg
IFRoZSBmb2xsb3dpbmcsIGludGVydHdpbmVkLCBjcml0ZXJpYSBhcmUgdXNlZCB0byBldmFsdWF0
ZSB0aGVzZSANCiAgIHNvbHV0aW9uczogDQogICBvIFByb3ZpZGVkIEZ1bmN0aW9uYWxpdHk6IFdo
YXQgZnVuY3Rpb25hbGl0eSBpcyBwcm92aWRlZCB3aXRoICANCiAgICAgcmVzcGVjdCB0byBUYWJs
ZSAxPyANCiAgIG8gRmxleGliaWxpdHk6IFdoYXQgc2NlbmFyaW9zIGFyZSBjb3ZlcmVkPyBXaGF0
IHBvbGljaWVzIGFyZSAgDQogICAgIHByb3ZpZGVkPyBIb3cgZmxleGlibGUgaXMgdGhlIHByb3Zp
ZGVkIGZ1bmN0aW9uYWxpdHk/IA0KICAgbyBFeHRlbmRpYmlsaXR5OiBUbyB3aGF0IGV4dGVudCBj
YW4gdGhlIHNvbHV0aW9uIGJlIGV4dGVuZGVkIHRvICANCiAgICAgaW50ZWdyYXRlIG5ldyBmdW5j
dGlvbmFsaXR5PyANCiAgIG8gU2NhbGFiaWxpdHk6IFdoYXQgcmVzdHJpY3Rpb25zIGR1ZSB0byBh
cmNoaXRlY3R1cmU/IA0KICAgIA0KNy4xLiAgIEguMzJ4IFByb3RvY29sIFN1aXRlIA0KICAgIA0K
ICAgbyBGdW5jdGlvbmFsaXR5OiAgDQogICAgIC0gY2VudHJhbGl6ZWQvZGVjZW50cmFsaXplZCBj
b25mZXJlbmNpbmcgDQogICAgIC0gcHJldHR5IG11Y2ggYWltaW5nIGF0IGZsb29yIGNvbnRyb2xs
ZWQgY29uZmVyZW5jaW5nLCBhbHRob3VnaCAgDQogICAgICAgb25seSBjb25kdWN0ZWQvbm9uLWNv
bmR1Y3RlZCBtb2RlcyBzdXBwb3J0ZWQgDQogICAgIC0gTm8gcGFzc2l2ZS9hY3RpdmUgbm90aW9u
IGluIHRoZSBvcmlnaW5hbCBILjMyeCwgSC4zMzIgZXh0ZW5zaW9uICANCiAgICAgICBkb2VzbpJ0
IHN1cHBvcnQgY2hhbmdlcyBvZiBsaXN0ZW5lcnMgdG8gYWN0aXZlIHVzZXJzLiANCiAgICAgIA0K
ICAgbyBGbGV4aWJpbGl0eTogIA0KICAgICAtIEZsb29yIGNvbnRyb2xsZWQgY29uZmVyZW5jaW5n
IGlzIHBvb3JseSBzdXBwb3J0ZWQsIGFsdGhvdWdoIHRoZSAgDQogICAgICAgZGF0YSBjb25mZXJl
bmNpbmcgcGFydCBzdXBwb3J0cyB0b2tlbnMuICANCiAgICAgLSBQcmUtZGVmaW5lZCByb2xlIG1v
ZGVscywgaS5lLiwgY29uZHVjdGVkIHZlcnN1cyBub24tY29uZHVjdGVkLCAgDQogICAgICAgZm9y
IGF1ZGlvdmlzdWFsIHBhcnQuICANCiAgICAgLSBObyBwb2xpY3kgZGVmaW5pdGlvbiwgZS5nLiwg
dXNpbmcgYXBwcm9wcmlhdGUgcHJvZmlsZSAgDQogICAgICAgaW5mb3JtYXRpb24uIA0KICAgICAt
IHJlY29uZmlndXJhdGlvbiBvZiBydW5uaW5nIGNvbmZlcmVuY2VzIHBvb3JseSBzdXBwb3J0ZWQu
IA0KICAgIA0KICAgbyBFeHRlbmRpYmlsaXR5OiANCiAgICAgLSBwcmV0dHkgY2xvc2VkIHN5c3Rl
bSBvZiBhIHdob2xlIHNldCBvZiBzdGFuZGFyZHMgDQogICAgDQogICBvIFNjYWxhYmlsaXR5OiB2
ZXJ5IHJlc3RyaWN0ZWQgZHVlIHRvIHRpZ2h0IGNlbnRyYWxpemVkIGNvbnRyb2wgIA0KICAgICBz
dHJ1Y3R1cmUgDQogICAgDQogICBbVEJEXSBhZGQgb3RoZXIgcG9pbnRzLCBlaXRoZXIgaXRlbXMg
b3Igc3ViaXRlbXMgDQogICAgDQo3LjIuICAgU0lQLWJhc2VkIFNvbHV0aW9ucyANCiAgICANCiAg
IG8gRnVuY3Rpb25hbGl0eTogIA0KICAgICAtIGZsZXhpYmxlIGluaXRpYXRpb24gbW9kZWxzIFsx
MV0gIA0KICAgICAtIG1lbWJlcnNoaXAgaW5mb3JtYXRpb24gdXNpbmcgUlRDUCBpbmZvcm1hdGlv
biAobG9vc2UgY29udHJvbCkgb3IgICAgICANCiAgICAgICBhLXByaW9yaSBpbmZvcm1hdGlvbiAN
CiAgICAgLSBubyBtZW1iZXJzaGlwIGVuZm9yY2VtZW50IA0KICAgICAtIG5vIGZsb29yIGNvbnRy
b2wgDQogICAgIC0gbm8gY2FwYWJpbGl0eSByZS1uZWdvdGlhdGlvbiANCiAgICANCiAgIG8gRmxl
eGliaWxpdHkvRXh0ZW5kaWJpbGl0eTogDQogICAgIA0KVHJvc3NlbiAgICAgICAgICAgICAgICAg
RXhwaXJlcyBOb3ZlbWJlciAyMDAxICAgICAgICAgICAgICAgICAgICBbMTBdIA0MDQpJbnRlcm5l
dCBEcmFmdCAgICAgQ291cnNlIENvbnRyb2wgUHJvYmxlbSBTdGF0ZW1lbnQgICAgICAgICAgIE1h
eSAyMDAxIA0KICAgIA0KICAgIA0KICAgICAtIGV4dGVuc2lvbiBwb3NzaWJsZSBieSBhZGRpbmcg
Y29uZmVyZW5jZSBjb3Vyc2UgY29udHJvbCAgDQogICAgICAgZnVuY3Rpb25hbGl0eSBhcyBzZXBh
cmF0ZWQgY29tcG9uZW50IGR1ZSB0byBvcGVuIHN5c3RlbSAgDQogICAgICAgY2hhcmFjdGVyIA0K
ICAgICAtIG90aGVyIHNjZW5hcmlvcyBwb3NzaWJsZSBieSBhZGRpbmcgZnVuY3Rpb25hbGl0eSAN
CiAgICANCiAgIG8gU2NhbGFiaWxpdHk6IGRlcGVuZHMgb24gdGhlIGluaXRpYXRpb24gbW9kZWws
IGJ1dCBtb3N0IGxpa2VseSAgDQogICAgIHNpbWlsYXIgdG8gdGhlIHNpbXBsZSBjb25mZXJlbmNp
bmcgY2F0ZWdvcnkgKHNlZSBTZWN0aW9uIDUuMSkgDQogICAgDQogICBbVEJEXSBhZGQgb3RoZXIg
cG9pbnRzLCBlaXRoZXIgaXRlbXMgb3Igc3ViaXRlbXMgDQogICAgDQogICAgDQo4LiAgICAgTmV4
dCBTdGVwcyANCiAgICANCiAgIFRoZSBmb2xsb3dpbmcgaXRlbXMgYXJlIHByb3Bvc2VkIGFzIG5l
eHQgc3RlcHM6IA0KICAgIA0KICAgbyBEZWZpbml0aW9uIG9mIHJlcXVpcmVtZW50cyANCiAgIG8g
UHJvcG9zYWwgZm9yIHByb3ZpZGVkIHNlcnZpY2VzIA0KICAgbyBQcm9wb3NhbCBvZiBwcm90b2Nv
bCBzb2x1dGlvbnMgDQogICBvIEFuYWx5c2lzIG9mIHByb3RvY29sIHNvbHV0aW9ucyANCiAgIG8g
UmVjb21tZW5kYXRpb24gb2YgY29uZmVyZW5jZSBjb3Vyc2UgY29udHJvbCBzZXJ2aWNlIGFuZCBw
cm90b2NvbCANCiAgICANCiAgIEEgY3J1Y2lhbCBwYXJ0IG9mIHRoZSBhbmFseXNpcyB3b3JrIGlz
IHRvIHN0dWR5IGV4aXN0aW5nIHNvbHV0aW9ucyANCiAgIHdpdGggcmVzcGVjdCB0byB0aGVpciBh
cHBsaWNhYmlsaXR5IGFuZCB0aGVpciBhbGlnbm1lbnQgd2l0aCB0aGUgDQogICBkZWZpbmVkIHNj
b3BlIG9mIFNlY3Rpb24gMiBhbmQgdGhlIHByb2JsZW0gc3RhdGVtZW50IGluIFNlY3Rpb24gMy4g
DQogICAgDQogICAgDQo5LiAgICAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgDQogDQogICBUaGlz
IGRvY3VtZW50IG1lcmVseSBkaXNjdXNzZXMgcHJvYmxlbSBzdGF0ZW1lbnRzIG1vdGl2YXRpbmcg
dGhlIA0KICAgbmVlZCBmb3IgY29uZmVyZW5jZSBjb3Vyc2UgY29udHJvbCBtZWNoYW5pc21zLiBT
ZWN1cml0eSBpcyBhbiBpc3N1ZSANCiAgIGZvciBjb25mZXJlbmNlIGNvdXJzZSBjb250cm9sIGJ1
dCBpcyBjb25zaWRlcmVkIGluIHN1YnNlcXVlbnQgDQogICBzb2x1dGlvbi1zcGFjZSBkb2N1bWVu
dHMuIA0KICAgIA0KICAgIA0KMTAuICAgIEFja25vd2xlZGdlbWVudHMgDQogICAgDQogICBJIHdv
dWxkIGxpa2UgdG8gYWNrbm93bGVkZ2UgdGhlIHBhcnRpY2lwYW50cyBvZiB0aGUgbWFpbGluZyBs
aXN0IA0KICAgdGhhdCB3YXMgc2V0IHVwIHRvIGRpc2N1c3MgdGhlIHRoaXMgZG9jdW1lbnQuIFRo
ZWlyIGNvbnRyaWJ1dGlvbnMgDQogICBhbmQgYWN0aXZlIHBhcnRpY2lwYXRpb24gaW4gdGhlIGRp
c2N1c3Npb24gb24gdGhlIG1haWxpbmcgbGlzdCB3ZXJlIA0KICAgdmVyeSB1c2VmdWwgaW4gdGhl
IHByZXBhcmF0aW9uIG9mIHRoaXMgZG9jdW1lbnQuIA0KICAgIA0KICAgIA0KMTEuICAgIFJlZmVy
ZW5jZXMgDQogICAgDQogICBbMV0gIEMuIEJvcm1hbm4sIEouIE90dCwgRC4gS3V0c2NoZXIsIEQu
IFRyb3NzZW4sICJTaW1wbGUgQ29uZmVyZW5jZSANCiAgICAgICAgQ29udHJvbCBQcm90b2NvbCCW
IFNlcnZpY2UgU3BlY2lmaWNhdGlvbiIsIGRyYWZ0LWlldGYtbW11c2ljLQ0KICAgICAgICBzY2Nw
LTAxLnR4dCwgV29yayBpbiBQcm9ncmVzcywgRmVicnVhcnkgMjAwMSANCiAgICANCiAgIFsyXSAg
SC4gRXJpa3Nzb24sICJNQk9ORTogVGhlIE11bHRpY2FzdCBCYWNrYm9uZSIsIENvbW11bmljYXRp
b25zIG9mIA0KICAgICAgICB0aGUgQUNNLCBWb2wuMzcgTm8uOCwgcHAuNTQtNjAsIEF1Z3VzdCAx
OTk0IA0KIA0KICAgICANClRyb3NzZW4gICAgICAgICAgICAgICAgIEV4cGlyZXMgTm92ZW1iZXIg
MjAwMSAgICAgICAgICAgICAgICAgICAgWzExXSANDA0KSW50ZXJuZXQgRHJhZnQgICAgIENvdXJz
ZSBDb250cm9sIFByb2JsZW0gU3RhdGVtZW50ICAgICAgICAgICBNYXkgMjAwMSANCiAgICANCiAg
ICANCiAgIFszXSAgTS4gSGFuZGxleSwgSi4gQ3Jvd2Nyb2Z0LCBDLiBCb3JtYW5uLCAiVGhlIElu
dGVybmV0IE11bHRpbWVkaWEgDQogICAgICAgIENvbmZlcmVuY2luZyBBcmNoaXRlY3R1cmUiLCBk
cmFmdC1pZXRmLW1tdXNpYy1jb25mYXJjaC0wMy50eHQsIA0KICAgICAgICBXb3JrIEluIFByb2dy
ZXNzLCBKdWx5IDIwMDAgIA0KICAgIA0KICAgWzRdICBNLiBIYW5kbGV5LCBWLiBKYWNvYnNvbiwg
IlNEUDogU2Vzc2lvbiBEZXNjcmlwdGlvbiBQcm90b2NvbCIsIA0KICAgICAgICBSRkMgMjMyNywg
QXByaWwgMTk5OCANCiAgICANCiAgIFs1XSAgTS4gSGFuZGxleSwgSC4gU2NodWx6cmlubmUsIEUu
IFNjaG9vbGVyLCBKLiBSb3NlbmJlcmcsICJTSVA6IA0KICAgICAgICBTZXNzaW9uIEluaXRpYXRp
b24gUHJvdG9jb2wiLCBSRkMgMjU0MywgTWFyY2ggMTk5OSANCiAgICANCiAgIFs2XSAgTS4gSGFu
ZGxleSwgQy4gUGVya2lucywgRS4gV2hlbGFuLCAiU2Vzc2lvbiBhbm5vdW5jZW1lbnQgDQogICAg
ICAgIHByb3RvY29sIiwgUkZDIDI5NzQsIE9jdG9iZXIgMjAwMCANCiAgICANCiAgIFs3XSAgSVRV
LVQsICJWaXN1YWwgVGVsZXBob25lIFN5c3RlbXMgYW5kIEVxdWlwbWVudCBmb3IgTG9jYWwgQXJl
YSANCiAgICAgICAgTmV0d29ya3Mgd2l0aCBOb24tR3VhcmFudGVlZCBRdWFsaXR5IG9mIFNlcnZp
Y2UiLCBJVFUtVCANCiAgICAgICAgUmVjb21tZW5kYXRpb24gSC4zMjMsIDIwMDAgDQogICAgDQog
ICBbOF0gIElUVS1ULCAiSC4zMjMgZXh0ZW5kZWQgZm9yIGxvb3NlbHkgY291cGxlZCBjb25mZXJl
bmNlcyIsIElUVS1UIA0KICAgICAgICBSZWNvbW1lbmRhdGlvbiBILjMzMiwgU2VwdGVtYmVyIDE5
OTggDQogICAgDQogICBbOV0gIEQuIEt1dHNjaGVyLCBKLiBPdHQsIEMuIEJvcm1hbm4sICJSZXF1
aXJlbWVudHMgZm9yIFNlc3Npb24gDQogICAgICAgIERlc2NyaXB0aW9uIGFuZCBDYXBhYmlsaXR5
IE5lZ290aWF0aW9uIiwgZHJhZnQtaWV0Zi1tbXVzaWMtDQogICAgICAgIHNkcG5nLXJlcS0wMC50
eHQsIFdvcmsgSW4gUHJvZ3Jlc3MsIEZlYnJ1YXJ5IDIwMDEgDQogDQogICBbMTBdIEouIE90dCwg
Qy4gUGVya2lucywgRC4gS3V0c2NoZXIsICJBIE1lc3NhZ2UgQnVzIGZvciBMb2NhbCANCiAgICAg
ICAgQ29vcmRpbmF0aW9uIiwgZHJhZnQtaWV0Zi1tbXVzaWMtbWJ1cy10cmFuc3BvcnQtMDQudHh0
LCBXb3JrIEluIA0KICAgICAgICBQcm9ncmVzcywgRmVicnVhcnkgMjAwMSANCiANCiAgIFsxMV0g
Si4gUm9zZW5iZXJnLCBILiBTY2h1bHpyaW5uZSwgIk1vZGVscyBmb3IgTXVsdGkgUGFydHkgDQog
ICAgICAgIENvbmZlcmVuY2luZyBpbiBTSVAiLCBkcmFmdC1yb3NlbmJlcmctc2lwLWNvbmZlcmVu
Y2luZy1tb2RlbHMtDQogICAgICAgIDAwLnR4dCwgV29yayBJbiBQcm9ncmVzcywgTm92ZW1iZXIg
MjAwMCANCiANCiAgIFsxMl0gSC4gU2NodWx6cmlubmUsIFMuIENhc25lciwgUi4gRnJlZGVyaWNr
LCBWLiBKYWNvYnNvbiwgIlJUUDogQSANCiAgICAgICAgVHJhbnNwb3J0IFByb3RvY29sIGZvciBS
ZWFsLVRpbWUgQXBwbGljYXRpb25zIiwgUkZDIDE4ODksIA0KICAgICAgICBKYW51YXJ5IDE5OTYg
DQogDQogICBbMTNdIEQuIFRyb3NzZW4sICJTY2FsYWJsZSBGbG9vciBDb250cm9sIGluIENvbmZl
cmVuY2luZyANCiAgICAgICAgRW52aXJvbm1lbnRzOiBUaGUgUkJvbmUgQXBwcm9hY2giLCAybmQg
SVAgVGVsZXBob255IFdvcmtzaG9wLCANCiAgICAgICAgTmV3IFlvcmssIEFwcmlsIDIwMDEgDQog
ICAgDQogICAgDQogICAgDQpBdXRob3IncyBBZGRyZXNzIA0KICAgIA0KICAgRGlyayBUcm9zc2Vu
IA0KICAgTm9raWEgUmVzZWFyY2ggDQogICA1IFdheXNpZGUgUm9hZCANCiAgIEJ1cmxpbmd0b24s
IE1BIDAyNDc0IFVTQSAgICAgIA0KICAgUGhvbmU6ICAxLTc4MS05OTMtMzYwNSANCiAgIEVtYWls
OiAgZGlyay50cm9zc2VuQG5va2lhLmNvbSANCiAgICANCiAgICANCkZ1bGwgQ29weXJpZ2h0IFN0
YXRlbWVudCANCiAgICAgDQpUcm9zc2VuICAgICAgICAgICAgICAgICBFeHBpcmVzIE5vdmVtYmVy
IDIwMDEgICAgICAgICAgICAgICAgICAgIFsxMl0gDQwNCkludGVybmV0IERyYWZ0ICAgICBDb3Vy
c2UgQ29udHJvbCBQcm9ibGVtIFN0YXRlbWVudCAgICAgICAgICAgTWF5IDIwMDEgDQogICAgDQog
ICAgDQogICAgDQogICBDb3B5cmlnaHQgKEMpIFRoZSBJbnRlcm5ldCBTb2NpZXR5ICgyMDAxKS4g
QWxsIFJpZ2h0cyBSZXNlcnZlZC4gDQogICAgDQogICBUaGlzIGRvY3VtZW50IGFuZCB0cmFuc2xh
dGlvbnMgb2YgaXQgbWF5IGJlIGNvcGllZCBhbmQgZnVybmlzaGVkIHRvIA0KICAgb3RoZXJzLCBh
bmQgZGVyaXZhdGl2ZSB3b3JrcyB0aGF0IGNvbW1lbnQgb24gb3Igb3RoZXJ3aXNlIGV4cGxhaW4g
aXQgDQogICBvciBhc3Npc3QgaW4gaXRzIGltcGxlbWVudGF0aW9uIG1heSBiZSBwcmVwYXJlZCwg
Y29waWVkLCBwdWJsaXNoZWQgDQogICBhbmQgZGlzdHJpYnV0ZWQsIGluIHdob2xlIG9yIGluIHBh
cnQsIHdpdGhvdXQgcmVzdHJpY3Rpb24gb2YgYW55IA0KICAga2luZCwgcHJvdmlkZWQgdGhhdCB0
aGUgYWJvdmUgY29weXJpZ2h0IG5vdGljZSBhbmQgdGhpcyBwYXJhZ3JhcGggDQogICBhcmUgaW5j
bHVkZWQgb24gYWxsIHN1Y2ggY29waWVzIGFuZCBkZXJpdmF0aXZlIHdvcmtzLiBIb3dldmVyLCB0
aGlzIA0KICAgZG9jdW1lbnQgaXRzZWxmIG1heSBub3QgYmUgbW9kaWZpZWQgaW4gYW55IHdheSwg
c3VjaCBhcyBieSByZW1vdmluZyANCiAgIHRoZSBjb3B5cmlnaHQgbm90aWNlIG9yIHJlZmVyZW5j
ZXMgdG8gdGhlIEludGVybmV0IFNvY2lldHkgb3Igb3RoZXIgDQogICBJbnRlcm5ldCBvcmdhbml6
YXRpb25zLCBleGNlcHQgYXMgbmVlZGVkIGZvciB0aGUgcHVycG9zZSBvZiANCiAgIGRldmVsb3Bp
bmcgSW50ZXJuZXQgc3RhbmRhcmRzIGluIHdoaWNoIGNhc2UgdGhlIHByb2NlZHVyZXMgZm9yIA0K
ICAgY29weXJpZ2h0cyBkZWZpbmVkIGluIHRoZSBJbnRlcm5ldCBTdGFuZGFyZHMgcHJvY2VzcyBt
dXN0IGJlIA0KICAgZm9sbG93ZWQsIG9yIGFzIHJlcXVpcmVkIHRvIHRyYW5zbGF0ZSBpdCBpbnRv
IGxhbmd1YWdlcyBvdGhlciB0aGFuIA0KICAgRW5nbGlzaC4gDQogICAgDQogICBUaGUgbGltaXRl
ZCBwZXJtaXNzaW9ucyBncmFudGVkIGFib3ZlIGFyZSBwZXJwZXR1YWwgYW5kIHdpbGwgbm90IGJl
IA0KICAgcmV2b2tlZCBieSB0aGUgSW50ZXJuZXQgU29jaWV0eSBvciBpdHMgc3VjY2Vzc29ycyBv
ciBhc3NpZ25zLiANCiAgICANCiAgIFRoaXMgZG9jdW1lbnQgYW5kIHRoZSBpbmZvcm1hdGlvbiBj
b250YWluZWQgaGVyZWluIGlzIHByb3ZpZGVkIG9uIGFuIA0KICAgIkFTIElTIiBiYXNpcyBhbmQg
VEhFIElOVEVSTkVUIFNPQ0lFVFkgQU5EIFRIRSBJTlRFUk5FVCBFTkdJTkVFUklORyANCiAgIFRB
U0sgRk9SQ0UgRElTQ0xBSU1TIEFMTCBXQVJSQU5USUVTLCBFWFBSRVNTIE9SIElNUExJRUQsIElO
Q0xVRElORyANCiAgIEJVVCBOT1QgTElNSVRFRCBUTyBBTlkgV0FSUkFOVFkgVEhBVCBUSEUgVVNF
IE9GIFRIRSBJTkZPUk1BVElPTiANCiAgIEhFUkVJTiBXSUxMIE5PVCBJTkZSSU5HRSBBTlkgUklH
SFRTIE9SIEFOWSBJTVBMSUVEIFdBUlJBTlRJRVMgT0YgDQogICBNRVJDSEFOVEFCSUxJVFkgT1Ig
RklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UuIA0KICAgIA0KQWNrbm93bGVkZ2VtZW50
IA0KICAgIA0KICAgRnVuZGluZyBmb3IgdGhlIFJGQyBlZGl0b3IgZnVuY3Rpb24gaXMgY3VycmVu
dGx5IHByb3ZpZGVkIGJ5IHRoZSANCiAgIEludGVybmV0IFNvY2lldHkuIA0KICAgICANClRyb3Nz
ZW4gICAgICAgICAgICAgICAgIEV4cGlyZXMgTm92ZW1iZXIgMjAwMSAgICAgICAgICAgICAgICAg
ICAgWzEzXSANDA==
------_=_NextPart_001_01C12A7B.8C236B40--
>From owner-rmt@listserv.lbl.gov Tue Aug 21 14:05:36 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f7LL3AM13020;
Tue, 21 Aug 2001 14:03:10 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f7LL39V13016
for <rmt@listserv.lbl.gov>; Tue, 21 Aug 2001 14:03:09 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f7LL38f25120
for <rmt@listserv.lbl.gov>; Tue, 21 Aug 2001 14:03:08 -0700 (PDT)
Received: from multicasttech.com (IDENT:root@lennon.multicasttech.com [63.105.122.7])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f7LL37525112
for <rmt@lbl.gov>; Tue, 21 Aug 2001 14:03:07 -0700 (PDT)
Received: from [63.105.122.193] (account marshall_eubanks HELO 21rst-century.com)
by multicasttech.com (CommuniGate Pro SMTP 3.4.8)
with ESMTP id 1069763; Tue, 21 Aug 2001 16:57:59 -0400
Message-ID: <3B82CC8A.AB7C0BC@21rst-century.com>
Date: Tue, 21 Aug 2001 17:03:09 -0400
From: Marshall Eubanks <tme@21rst-century.com>
Reply-To: tme@21rst-century.com
Organization: Multicast Technologies
X-Mailer: Mozilla 4.7C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; I; PPC)
X-Accept-Language: en,pdf
MIME-Version: 1.0
To: "Trossen Dirk (NRC/Boston)" <Dirk.Trossen@nokia.com>
CC: mankin@ISI.EDU, Michael Luby <luby@digitalfountain.com>,
Rob Lanphier <robla@real.com>, Ross Finlayson <finlayson@live.com>,
"Rmt@Lbl. Gov" <rmt@lbl.gov>, confctrl@ISI.EDU, sob@harvard.edu,
ietf-floor control <flr-ctrl-grp@network2.cs.usm.my>
Subject: Re: Session control protocol instantiation discussion within the IETF
References: <B9CFA6CE8FFDD211A1FB0008C7894E4604B9E792@bseis01nok>
Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353"
Content-Transfer-Encoding: 7bit
Sender: owner-rmt@lbl.gov
Precedence: bulk
"Trossen Dirk (NRC/Boston)" wrote:
> Hi all,
>
> as announced on the MMUSIC mailing list, a couple of people
> being interested in conference course control met on Wednesday
> August 8th (10-11pm) during the London IETF meeting to discuss
> further steps in this direction.
>
> The following persons were present during this informal meeting:
> Jun-Won Lee, Shin-Gak Kang, Jonathan Rosenberg, Eunsook Kim,
> Colin Perkins, Joerg Ott, Dirk Kutscher, Dirk Trossen
>
> During the meeting, a general interest in this topic was
> expressed by the attendents. However, the concern was
> raised (by Jonathan, Joerg, and Colin) that the scope
> of the work has to be defined very carefully. Especially
> Jonathan expressed interest in 'doable' solutions, i.e.,
> covering rather simple centralized conferencing scenarios
> first rather than defining a wide scope of the work.
>
> The following steps have been proposed to be undertaken in
> this direction:
> - provision of a problem statement document
> - submission to mailing list(s)
> - creation of own discussion list for this topic
>
> The problem statement document should be created by a circle
> of people being interested in this topic and willing to contribute
> to this work.
> The discussion of the problem statement should end in a
> decision how to bring this topic to the IETF within the
> therein defined scope, either within the charter of existing
> WGs or by organizing a BOF.
>
> Since similar discussions about future session control efforts
> have been undertaken within the RMT WG, I'm sending this mail
> also to this list to invite interested people to join the discussion.
>
> Enclosed you find the current document which was meant as a
> problem statement for conference course control. This document
> is far from being completed (it was not submitted as a draft although
> it is written in Internet draft style) but it is intended as a basis
> for discussion to reach final document status.
>
> Any comments are welcome.
>
> Best Regards,
>
> Dirk Trossen
> -----------------------
> Dirk Trossen
> Nokia Research Center
> 5 Wayside Road
> Burlington, MA 01803
> Tel: +1 (781) 993 3605
> Fax: +1 (781) 993 1907
> mob: +1 (617) 794 7041
> -----------------------
>
> > -----Original Message-----
> > From: ext Allison Mankin [mailto:mankin@ISI.EDU]
> > Sent: Wednesday, August 08, 2001 11:49 PM
> > To: Michael Luby
> > Cc: Rob Lanphier; Ross Finlayson; Rmt@Lbl. Gov; confctrl@ISI.EDU;
> > Allison Mankin; sob@harvard.edu
> > Subject: Re: Session control protocol instantiation discussion within
> > the IETF
> >
> >
> > Mike,
> >
> > We ADs would be happy to talk with you about this sometime (but after
> > we all recover from IETF).
> >
> > Having had one hallway talk with you while you were in London,
> > I think there is some value to discussing session work (without
> > prejudging if it would extend an existing charter or start up in
> > a new situation of some sort).
> >
> > Mike Luby wrote:
> > > All,
> > > I unfortunately was only at the IETF for a couple of days,
> > and am back in
> > > the Bay Area now. I would first like to talk with the
> > transport area
> > > directorate (Scott and Allison) to get some advice on this, and then
> > > probably followup with a conference call with whoever is
> > interested. Would
> > > a conference call be ok with you Rob, Ross (and whoever else is
> > > interested?).
> > > Mike
> > >
> >
>
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> Name: draft-trossen-problem-00.txt
> draft-trossen-problem-00.txt Type: Plain Text (text/plain)
> Encoding: base64
> Description: draft-trossen-problem-00.txt
Are you planning to set up a separate mailing list devoted to this ?
--
Regards
Marshall Eubanks
T.M. Eubanks
Multicast Technologies, Inc
10301 Democracy Lane, Suite 410
Fairfax, Virginia 22030
Phone : 703-293-9624 Fax : 703-293-9609
e-mail : tme@multicasttech.com
http://www.on-the-i.com
Test your network for multicast : http://www.multicasttech.com/mt/
Check the status of multicast in real time :
http://www.multicasttech.com/status/index.html
>From owner-rmt@listserv.lbl.gov Tue Aug 21 18:50:27 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f7M1mSe24791;
Tue, 21 Aug 2001 18:48:28 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f7M1mQV24787
for <rmt@listserv.lbl.gov>; Tue, 21 Aug 2001 18:48:26 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f7M1mPa23709
for <rmt@listserv.lbl.gov>; Tue, 21 Aug 2001 18:48:25 -0700 (PDT)
Received: from cs.usm.my (cs.usm.my [161.142.8.1])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f7M1mN523704
for <rmt@lbl.gov>; Tue, 21 Aug 2001 18:48:23 -0700 (PDT)
Received: from cs.usm.my (cs.usm.my [161.142.8.1])
by cs.usm.my (8.11.4/8.11.4) with ESMTP id f7M1ljp17732;
Wed, 22 Aug 2001 09:47:45 +0800 (SGT)
Date: Wed, 22 Aug 2001 09:47:45 +0800 (SGT)
From: Sureswaran Ramadass <sures@cs.usm.my>
To: Marshall Eubanks <tme@21rst-century.com>
cc: "Trossen Dirk (NRC/Boston)" <Dirk.Trossen@nokia.com>, <mankin@ISI.EDU>,
Michael Luby <luby@digitalfountain.com>, Rob Lanphier <robla@real.com>,
Ross Finlayson <finlayson@live.com>, "Rmt@Lbl. Gov" <rmt@lbl.gov>,
<confctrl@ISI.EDU>, <sob@harvard.edu>,
Gopinath Rao <gopi@network2.cs.usm.my>,
ietf-floor control <flr-ctrl-grp@network2.cs.usm.my>
Subject: Re: Session control protocol instantiation discussion within the
IETF
In-Reply-To: <3B82CC8A.AB7C0BC@21rst-century.com>
Message-ID: <Pine.GSO.4.33.0108220944050.17647-100000@cs.usm.my>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-rmt@lbl.gov
Precedence: bulk
Hi Marshall,
Yes, there currently is an email list. It is
flr-ctrl-grp@network2.cs.usm.my
To be added to the group, simple email your request to gopi@nrg.cs.usm.my
Thanks for your interest and thanks to Dirk for getting this group
moving.
Sures.
> Are you planning to set up a separate mailing list devoted to this ?
>
> --
> Regards
> Marshall Eubanks
>
>
> T.M. Eubanks
> Multicast Technologies, Inc
> 10301 Democracy Lane, Suite 410
> Fairfax, Virginia 22030
> Phone : 703-293-9624 Fax : 703-293-9609
> e-mail : tme@multicasttech.com
> http://www.on-the-i.com
>
> Test your network for multicast : http://www.multicasttech.com/mt/
> Check the status of multicast in real time :
> http://www.multicasttech.com/status/index.html
>
>
>
Dr. Sureswaran Ramadass
Programme Chairman & email: sures@cs.usm.my
Head of Network Research, tel: 604-8603004
School of Computer Sciences fax: 604-6573335
University of Science, http://network2.cs.usm.my
11800 Penang, Malaysia
>From owner-rmt@listserv.lbl.gov Wed Aug 22 08:22:13 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f7MFCYx10737;
Wed, 22 Aug 2001 08:12:34 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f7MFCWV10733
for <rmt@listserv.lbl.gov>; Wed, 22 Aug 2001 08:12:33 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f7MFCVr25438
for <rmt@listserv.lbl.gov>; Wed, 22 Aug 2001 08:12:31 -0700 (PDT)
Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f7MFCU525420
for <rmt@lbl.gov>; Wed, 22 Aug 2001 08:12:30 -0700 (PDT)
Received: from davir03nok.americas.nokia.com (davir03nok.americas.nokia.com [172.18.242.86])
by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f7MFCWi06173
for <rmt@lbl.gov>; Wed, 22 Aug 2001 10:12:32 -0500 (CDT)
Received: from daebh001.NOE.Nokia.com (unverified) by davir03nok.americas.nokia.com
(Content Technologies SMTPRS 4.2.5) with ESMTP id <T55862a69f5ac12f256079@davir03nok.americas.nokia.com>;
Wed, 22 Aug 2001 10:12:26 -0500
content-class: urn:content-classes:message
Subject: RE: Session control protocol instantiation discussion within the IETF
Date: Wed, 22 Aug 2001 09:51:49 -0500
Message-ID: <B9CFA6CE8FFDD211A1FB0008C7894E4604B9E79B@bseis01nok>
X-MS-Has-Attach:
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="----_=_NextPart_001_01C12B19.F8CF8190"
X-MS-TNEF-Correlator:
Thread-Topic: RE: Session control protocol instantiation discussion within the IETF
Thread-Index: AcEqe4uEShQMW6crRN2OATPOjXiPhA==
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
From: "Trossen Dirk (NRC/Boston)" <Dirk.Trossen@nokia.com>
To: <mankin@ISI.EDU>, "'Michael Luby'" <luby@digitalfountain.com>
Cc: "'Rob Lanphier'" <robla@real.com>, "'Ross Finlayson'" <finlayson@live.com>,
"'Rmt@Lbl. Gov'" <rmt@lbl.gov>, <confctrl@ISI.EDU>, <sob@harvard.edu>,
"'ietf-floor control'" <flr-ctrl-grp@network2.cs.usm.my>
Sender: owner-rmt@lbl.gov
Precedence: bulk
This is a multi-part message in MIME format.
------_=_NextPart_001_01C12B19.F8CF8190
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sorry, here's the document I was talking about in the previous
mail.
------_=_NextPart_001_01C12B19.F8CF8190
Content-Type: text/plain;
name="draft-trossen-problem-00.txt"
Content-Transfer-Encoding: base64
Content-Description: draft-trossen-problem-00.txt
Content-Disposition: attachment;
filename="draft-trossen-problem-00.txt"
DQpJbnRlcm5ldCBFbmdpbmVlcmluZyBUYXNrIEZvcmNlICAgICAgICAgICAgICAgICAgRC4gVHJv
c3NlbiAoRWRpdG9yKSANCkludGVybmV0IERyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIE5va2lhIFJlc2VhcmNoIA0KZHJhZnQtdHJvc3Nlbi1wcm9ibGVtLTAwLnR4
dCAgICAgICAgICAgICAgICAgICAgICAgICAgICAxMS4gTWF5IDIwMDEgDQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRXhwaXJlczogTm92ZW1iZXIgMjAwMSAN
CiANCiANCiAgICAgICAgICAgICAgICBDb25mZXJlbmNlIENvdXJzZSBDb250cm9sIFByb2JsZW0g
U3RhdGVtZW50IA0KIA0KIA0KU3RhdHVzIG9mIHRoaXMgTWVtbyANCiANCiAgIFRoaXMgZG9jdW1l
bnQgaXMgYW4gSW50ZXJuZXQtRHJhZnQgYW5kIGlzIGluIGZ1bGwgY29uZm9ybWFuY2UgDQogICB3
aXRoIGFsbCBwcm92aXNpb25zIG9mIFNlY3Rpb24gMTAgb2YgUkZDMjAyNi4gDQogICAgDQogICAg
DQogICBJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1lbnRzIG9mIHRoZSBJbnRlcm5l
dCBFbmdpbmVlcmluZyANCiAgIFRhc2sgRm9yY2UgKElFVEYpLCBpdHMgYXJlYXMsIGFuZCBpdHMg
d29ya2luZyBncm91cHMuICBOb3RlIHRoYXQgICAgICANCiAgIG90aGVyIGdyb3VwcyBtYXkgYWxz
byBkaXN0cmlidXRlIHdvcmtpbmcgZG9jdW1lbnRzIGFzIEludGVybmV0LQ0KICAgRHJhZnRzLiAN
CiAgICANCiAgIEludGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBh
IG1heGltdW0gb2Ygc2l4IA0KICAgbW9udGhzIGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQs
IG9yIG9ic29sZXRlZCBieSBvdGhlciBkb2N1bWVudHMgDQogICBhdCBhbnkgdGltZS4gIEl0IGlz
IGluYXBwcm9wcmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBhcyANCiAgIHJlZmVyZW5jZSBt
YXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4i
IA0KICAgIA0KICAgVGhlIGxpc3Qgb2YgY3VycmVudCBJbnRlcm5ldC1EcmFmdHMgY2FuIGJlIGFj
Y2Vzc2VkIGF0IA0KICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2lldGYvMWlkLWFic3RyYWN0
cy50eHQgDQogICBUaGUgbGlzdCBvZiBJbnRlcm5ldC1EcmFmdCBTaGFkb3cgRGlyZWN0b3JpZXMg
Y2FuIGJlIGFjY2Vzc2VkIGF0IA0KICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5o
dG1sLiANCiAgICANCkNvcHlyaWdodCBOb3RpY2UgDQogICAgDQogICBDb3B5cmlnaHQgKGMpIFRo
ZSBJbnRlcm5ldCBTb2NpZXR5ICgyMDAxKS4gQWxsIHJpZ2h0cyByZXNlcnZlZC4gDQogICAgDQpB
YnN0cmFjdCANCiAgICANCiAgIEFzIHBhcnQgb2YgdGhlIEludGVybmV0IE11bHRpbWVkaWEgQ29u
ZmVyZW5jaW5nIEFyY2hpdGVjdHVyZSBbM10sIA0KICAgY29uZmVyZW5jZSBjb3Vyc2UgY29udHJv
bCBkZWFscyB3aXRoIHRoZSBjb250cm9sIG9mIHJ1bm5pbmcgDQogICBjb25mZXJlbmNlcyBhZnRl
ciB0aGUgY3JlYXRpb24gb2YgdGhlIGluaXRpYWwgY29uZmVyZW5jZSBzdGF0ZSB3aXRoIA0KICAg
cmVzcGVjdCB0byB0aGUgbWVtYmVyc2hpcCBhbmQgYWNjZXNzIGNvbnRyb2wgZHVyaW5nIHJ1bnRp
bWUgb2YgdGhlIA0KICAgc2Vzc2lvbi4gVGhlIHNwZWN0cnVtIG9mIHNjZW5hcmlvcyByZWFjaGVz
IGZyb20gc21hbGwgbXVsdGlwYXJ0eSANCiAgIGdhdGhlcmluZ3MgdXAgdG8gbGFyZ2Ugc2NhbGVk
IG1lZXRpbmdzIHdpdGggYSBoaWdoIGZsdWN0dWF0aW9uIG9mIA0KICAgdXNlcpJzIG1lbWJlcnNo
aXAgYW5kIGFjdGl2aXR5LiANCiAgICANCiAgIFRoaXMgZG9jdW1lbnQgaWRlbnRpZmllcyB0aGUg
cHJvYmxlbSBhcmVhIHRvIGRlZmluZSB0aGUgc2NvcGUgb2YgYSANCiAgIGNvbmZlcmVuY2UgY291
cnNlIGNvbnRyb2wgd29ya2luZyBncm91cCBpbiB0aGUgSUVURi4gDQogDQogICAgIA0KVHJvc3Nl
biAgICAgICAgICAgICAgICAgRXhwaXJlcyBOb3ZlbWJlciAyMDAxICAgICAgICAgICAgICAgICAg
ICAgWzFdIA0MDQpJbnRlcm5ldCBEcmFmdCAgICAgQ291cnNlIENvbnRyb2wgUHJvYmxlbSBTdGF0
ZW1lbnQgICAgICAgICAgIE1heSAyMDAxIA0KICAgIA0KICAgIA0KVGFibGUgb2YgQ29udGVudHMg
DQogICAgDQogICAxLiBJbnRyb2R1Y3Rpb24uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4yIA0KICAgMi4gRGVmaW5pdGlvbiBvZiBUZXJtcy4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMyANCiAgIDMuIFNjb3BlLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjQgDQog
ICA0LiBQcm9ibGVtIFN0YXRlbWVudC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi40IA0KICAgNS4gQ29uZmVyZW5jaW5nIFNjZW5hcmlvcy4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uNSANCiAgIDUuMS4gIFNpbXBsZSBDb25mZXJlbmNp
bmcuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjUgDQogICA1LjEuMS4g
IEV4YW1wbGVzLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li42IA0KICAgNS4yLiAgRmxvb3IgQ29udHJvbGxlZCBDb25mZXJlbmNpbmcuLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uNiANCiAgIDUuMi4xLiAgRXhhbXBsZXMuLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjYgDQogICA1LjMuICBSaWNoIENvbmZl
cmVuY2luZy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi42IA0KICAg
NS4zLjEuICBFeGFtcGxlcy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uNyANCiAgIDUuNC4gIFN1bW1hcnkgb2YgQ2hhcmFjdGVyaXN0aWNzLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjcgDQogICA2LiBDb25mZXJlbmNlIENvdXJzZSBDb250
cm9sIE1vZGVscy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi45IA0KICAgNi4xLiAgTG9v
c2UgQ29uZmVyZW5jZSBDb3Vyc2UgQ29udHJvbC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
OSANCiAgIDYuMi4gIFRpZ2h0IENvbmZlcmVuY2UgQ291cnNlIENvbnRyb2wuLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLjkgDQogICA2LjMuICAnSmVsbHktbGlrZScgQ29uZmVyZW5jZSBDb3Vy
c2UgQ29udHJvbC4uLi4uLi4uLi4uLi4uLi4uLi4uLi45IA0KICAgNy4gRXhpc3RpbmcgU29sdXRp
b25zLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uOSANCiAgIDcu
MS4gIEguMzJ4IFByb3RvY29sIFN1aXRlLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uMTAgDQogICA3LjIuICBTSVAtYmFzZWQgU29sdXRpb25zLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLjEwIA0KICAgOC4gTmV4dCBTdGVwcy4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xMSANCiAgIDkuIFNlY3VyaXR5
IENvbnNpZGVyYXRpb25zLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTEg
DQogICAxMC4gIEFja25vd2xlZGdlbWVudHMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLjExIA0KICAgMTEuICBSZWZlcmVuY2VzLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xMSANCiAgICANCiAgICANCjEuICAgICBJbnRy
b2R1Y3Rpb24gDQogICAgDQogICBJbnRlcmFjdGl2ZSBjb2xsYWJvcmF0aXZlIHNjZW5hcmlvcyBs
aWtlIHJlbW90ZSBtZWV0aW5ncywgdmlydHVhbCANCiAgIGNsYXNzcm9vbXMsIG9yIHNoYXJpbmcg
YXBwbGljYXRpb25zIHZpYSB0aGUgSW50ZXJuZXQgaGF2ZSBiZWNvbWUgDQogICBtb3JlIGFuZCBt
b3JlIHBvcHVsYXIgaW4gdGhlIHBhc3QgdGVuIHllYXJzLiANCiAgICANCiAgIEFjY29yZGluZyB0
byBbM10sIHRoZSB0ZXJtICdjb25mZXJlbmNpbmcnIGlzIGNvbnNpZGVyZWQgaW4gdGhlIA0KICAg
cmVtYWluZGVyIG9mIHRoaXMgZG9jdW1lbnQgYXMgc3luY2hyb25vdXMsIHJlYWwtdGltZSBjb21t
dW5pY2F0aW9uLCANCiAgIHNwZWNpZmljYWxseSBpbmNsdWRpbmcgYXVkaW8gYW5kIHZpZGVvIG1l
ZGlhIGJ1dCBhbHNvIHNoYXJlZCBkYXRhIA0KICAgbWVkaWEgc3VjaCBhcyB3aGl0ZWJvYXJkcywg
YW1vbmcgYSBzZXQgb2YgbWVtYmVycy4gU2V2ZXJhbCwgcHJvYmFibHkgDQogICBpbmRlcGVuZGVu
dGx5IGltcGxlbWVudGVkLCBhZ2VudHMgZm9yIG1lZGlhIGhhbmRsaW5nIGFuZCBjb250cm9sIA0K
ICAgcHVycG9zZXMgaGF2ZSB0byBiZSBjb29yZGluYXRlZCBhbmQgc3luY2hyb25pemVkIGR1cmlu
ZyBydW50aW1lIG9mIA0KICAgdGhlIGNvbmZlcmVuY2UsIHJlZmVycmVkIHRvIGFzICdjb25mZXJl
bmNlIGNvdXJzZSBjb250cm9sJyBpbiB0aGUgDQogICBmb2xsb3dpbmcsIGFmdGVyIGNyZWF0aW5n
IHRoZSBpbml0aWFsIGNvbmZlcmVuY2Ugc3RhdGUgYXMgcGFydCBvZiANCiAgIHRoZSBjb25mZXJl
bmNpbmcgc2V0dXAgZnVuY3Rpb25hbGl0eS4gVGhlIHByb3ZpZGVkIGZ1bmN0aW9uYWxpdHkgDQog
ICB3aXRoIHJlc3BlY3QgdG8gY29uZmVyZW5jZSBjb3Vyc2UgY29udHJvbCB1c3VhbGx5IGRlcGVu
ZHMgb24gdGhlIA0KICAgY29uc2lkZXJlZCBzY2VuYXJpbyBpbiB3aGljaCBpdCBpcyBuZWVkZWQu
ICANCiAgICANCiAgIEluIHRoZSBmb2xsb3dpbmcsIHRoZSBzY29wZSBvZiBjb25mZXJlbmNpbmcg
Y291cnNlIGNvbnRyb2wgYXMgd2VsbCANCiAgIGFzIGEgcHJvYmxlbSBzdGF0ZW1lbnQgd2lsbCBi
ZSBwaW5wb2ludGVkLiBGdXJ0aGVybW9yZSwgc2NlbmFyaW9zIA0KICAgZm9yIG11bHRpbWVkaWEg
Y29uZmVyZW5jaW5nIGluIHRoZSBJbnRlcm5ldCBhcmUgY2F0ZWdvcml6ZWQsIA0KICAgcmVhY2hp
bmcgZnJvbSBzbWFsbCBjbG9zZWQgbWVldGluZ3MgdG8gbGFyZ2UgcGxlbmFyeSBzZXNzaW9ucyB3
aXRoIA0KICAgICANClRyb3NzZW4gICAgICAgICAgICAgICAgIEV4cGlyZXMgTm92ZW1iZXIgMjAw
MSAgICAgICAgICAgICAgICAgICAgIFsyXSANDA0KSW50ZXJuZXQgRHJhZnQgICAgIENvdXJzZSBD
b250cm9sIFByb2JsZW0gU3RhdGVtZW50ICAgICAgICAgICBNYXkgMjAwMSANCiAgICANCiAgICAN
CiAgIGhpZ2ggZmx1Y3R1YXRpb25zIHJlZ2FyZGluZyB0aGUgcGFydGljaXBhbnSScyBhY3Rpdml0
eSBhbmQgDQogICBpbnRlcmVzdHMuIFNpbmNlIHRoZSBmb2N1cyBvZiB0aGUgZG9jdW1lbnQgaXMg
b24gY29udHJvbCBpc3N1ZXMgaW4gDQogICBjb25mZXJlbmNpbmcsIGRhdGEgZGVsaXZlcnkgYXNw
ZWN0cyBhcmUgbGVmdCBvdXQgb2YgY29uc2lkZXJhdGlvbi4gDQogICAgDQogICBUaGUgc2NlbmFy
aW8gZmluZGluZ3MgYXJlIHRoZW4gdXNlZCB0byBkZWZpbmUgbW9kZWxzIGZvciBjb25mZXJlbmNl
IA0KICAgY291cnNlIGNvbnRyb2wgcHJvdmlzaW9uLiANCiAgICANCiAgIE1vcmVvdmVyLCBjdXJy
ZW50IGNvbmZlcmVuY2luZyBzb2x1dGlvbnMgYXJlIGJyaWVmbHkgZXZhbHVhdGVkIA0KICAgY29u
Y2VybmluZyB0aGVpciBzaG9ydGNvbWluZ3MgaW4gY29uZmVyZW5jZSBjb3Vyc2UgY29udHJvbCAN
CiAgIGZ1bmN0aW9uYWxpdHkuIEZpbmFsbHksIG5leHQgc3RlcHMgZm9yIGNvbmZlcmVuY2UgY291
cnNlIGNvbnRyb2wgDQogICBlZmZvcnRzIHdpbGwgYmUgcHJlc2VudGVkLiANCiAgICANCjIuICAg
ICBEZWZpbml0aW9uIG9mIFRlcm1zIA0KICAgIA0KICAgbyBBcHBsaWNhdGlvbiBzZXNzaW9uIChB
UyksIFNlc3Npb24gDQogICAgIFRoZSBzZXQgb2YgbWVkaWEgYWdlbnRzL2FwcGxpY2F0aW9ucyB0
aGF0IGFjdCBhcyBwZWVycyB0byBlYWNoICANCiAgICAgb3RoZXIgd2l0aGluIGEgY29uZmVyZW5j
ZS4gIEZvciByZWFsLXRpbWUgZGF0YSwgdGhpcyBnZW5lcmFsbHkgIA0KICAgICB3aWxsIGJlIGFu
IFJUUCBzZXNzaW9uOyBmb3Igb3RoZXIgYXBwbGljYXRpb24gcHJvdG9jb2xzLCBvdGhlciAgDQog
ICAgIGhvcml6b250YWwgcHJvdG9jb2xzIG1heSBkZWZpbmUgdGhlaXIgb3duIHR5cGUgb2Ygc2Vz
c2lvbiBjb25jZXB0LiAgDQogICAgDQogICBvIFBhcnRpY2lwYW50IA0KICAgICBBIGh1bWFuIGJl
aW5nIHRoYXQgdGFrZXMgcGFydCBpbiBhIGNvbmZlcmVuY2UsIGVpdGhlciBhY3RpdmVseSBvciAg
DQogICAgIHBhc3NpdmVseSBsaXN0ZW5pbmcuIA0KICAgIA0KICAgbyBBY3RpdmUgUGFydGljaXBh
bnQgDQogICAgIEEgcGFydGljaXBhbnQgb2YgYSBjb25mZXJlbmNlIGJlY29taW5nIHNlbmRlciBv
ZiBtZWRpYSBpbmZvcm1hdGlvbiAgDQogICAgIGR1cmluZyBsaWZldGltZSBvZiB0aGUgY29uZmVy
ZW5jZS4gDQogICAgDQogICBvIFBhc3NpdmUgUGFydGljaXBhbnQgDQogICAgIEEgcGFydGljaXBh
bnQgb2YgYSBjb25mZXJlbmNlIHBhc3NpdmVseSByZWNlaXZpbmcgdGhlIG1lZGlhICANCiAgICAg
aW5mb3JtYXRpb24gd2l0aG91dCBiZWNvbWluZyBzZW5kZXIgb2YgbWVkaWEgaW5mb3JtYXRpb24g
IA0KICAgICBkdXJpbmcgbGlmZXRpbWUgb2YgdGhlIGNvbmZlcmVuY2UuIA0KICAgIA0KICAgbyBN
ZW1iZXIgDQogICAgIFRoZSBzeXN0ZW0sIGluY2x1ZGluZyBzb2Z0d2FyZSBhbmQgaGFyZHdhcmUs
IHRoYXQgdGFrZXMgcGFydCBpbiBhICAgIA0KICAgICBjb21wdXRlciBjb25mZXJlbmNlLCByZXBy
ZXNlbnRpbmcgYSBzaW5nbGUgcGFydGljaXBhbnQuIA0KICAgIA0KICAgbyBQcm9maWxlIA0KICAg
ICBBbiBpbml0aWFsIGRlc2NyaXB0aW9uIG9mIHRoZSBjb25mZXJlbmNlLCBpbmNsdWRpbmcgYXNz
aWdubWVudCBvZiAgDQogICAgIHJvbGVzIHRvIHBhcnRpY3VsYXIgbWVtYmVycywgdGltZSBsaW1p
dHMgZm9yIHNwZWFrZXJzLCBhdHRyaWJ1dGVzICANCiAgICAgb2YgdGhlIGNvbmZlcmVuY2UgKG9w
ZW4vY2xvc2UsIGNvbmR1Y3RlZC9hbmFyY2hpYywgZXRjKS4gDQogICAgDQogICBvIENvbmZlcmVu
Y2UgU2V0dXAgYW5kIERpc2NvdmVyeSANCiAgICAgQWNjb3JkaW5nIHRvIFszXSwgYXNwZWN0cyBm
b3Igc2V0dGluZyB1cCBhbiBpbml0aWFsIGNvbmZlcmVuY2UgIA0KICAgICBTdGF0ZSBpbiBwYXJ0
aWNpcGF0aW5nIG1lbWJlcnMsIGluY2x1ZGluZyB0aGUgZXhjaGFuZ2Ugb2YgbWVkaWEgIA0KICAg
ICBhbmQgY2FwYWJpbGl0aWVzIGluZm9ybWF0aW9uIGFtb25nIHRoZSBzZXQgb2YgcGFydGljaXBh
bnRzLCBhcmUgIA0KICAgICBiZWluZyBhZGRyZXNzZWQgYnkgc2V0dXAgYW5kIGRpc2NvdmVyeSBm
dW5jdGlvbmFsaXR5LiANCiAgICANCiAgIG8gQ29uZmVyZW5jZSBDb3Vyc2UgQ29udHJvbCANCiAg
ICAgQWNjb3JkaW5nIHRvIFszXSwgYXNwZWN0cyB0byBjb250cm9sIHRoZSBjb25mZXJlbmNlIGR1
cmluZyBydW50aW1lICANCiAgICAgb2YgdGhlIGV2ZW50IGFyZSBiZWluZyBhZGRyZXNzZWQgYnkg
Y29uZmVyZW5jZSBjb3Vyc2UgY29udHJvbC4gDQogICAgDQogICAgIA0KVHJvc3NlbiAgICAgICAg
ICAgICAgICAgRXhwaXJlcyBOb3ZlbWJlciAyMDAxICAgICAgICAgICAgICAgICAgICAgWzNdIA0M
DQpJbnRlcm5ldCBEcmFmdCAgICAgQ291cnNlIENvbnRyb2wgUHJvYmxlbSBTdGF0ZW1lbnQgICAg
ICAgICAgIE1heSAyMDAxIA0KICAgIA0KICAgIA0KMy4gICAgIFNjb3BlIA0KICAgIA0KICAgVGhl
IHNjb3BlIG9mIGNvbmZlcmVuY2UgY291cnNlIGNvbnRyb2wgZnVuY3Rpb25hbGl0eSB3aWxsIGJl
IA0KICAgZGV2ZWxvcGVkIGFzIHBhcnQgb2YgdGhlIHNvbHV0aW9uIHNwYWNlLiBQb3NzaWJsZSBm
dW5jdGlvbmFsaXR5IA0KICAgaW5jbHVkZXM6IA0KICAgIA0KICAgbyAnY29uZmVyZW5jZSBjb250
ZXh0IGFkbWluaXN0cmF0aW9uJywgcHJvdmlkaW5nIG1lbWJlcnNoaXAgIA0KICAgICBhbmQgYXBw
bGljYXRpb24vc2Vzc2lvbiBpbmZvcm1hdGlvbiBhZG1pbmlzdHJhdGlvbiANCiAgIG8gJ21lbWJl
cnNoaXAgZW5mb3JjZW1lbnQnLCBwcm92aWRpbmcgbWVhbnMgdG8gZW5mb3JjZSBzcGVjaWZpYyAg
DQogICAgIGNvbmZlcmVuY2UgbWVtYmVyc2hpcCANCiAgIG8gJ2Zsb29yIGNvbnRyb2wnLCBwcm92
aWRpbmcgbWVhbnMgdG8gbWFwIHNvY2lhbCBwcm90b2NvbHMgb250byAgDQogICAgIGRpc3RyaWJ1
dGVkIGVudmlyb25tZW50cy4gSG93ZXZlciwgdGhlIHNlbWFudGljcyBvZiBzcGVjaWZpYyAgDQog
ICAgIHNvY2lhbCBwcm90b2NvbHMgaXMgbm90IHdpdGhpbiB0aGUgc2NvcGUgb2YgdGhlIHBvc3Np
YmxlICANCiAgICAgY29uZmVyZW5jZSBjb3Vyc2UgY29udHJvbCBzb2x1dGlvbi4gDQogICBvICdh
Y3RpdmUvcGFzc2l2ZSBtZW1iZXIgc3VwcG9ydCcsIGFsbG93aW5nIGZvciBkaWZmZXJlbnQgcG9s
aWNpZXMgIA0KICAgICB3aXRoIHJlc3BlY3QgdG8gbWVtYmVyc2hpcCBhbmQgZmxvb3IgY29udHJv
bC4gVGhpcyBpbmNsdWRlcyAgDQogICAgIGNoYW5nZXMgZnJvbSBhY3RpdmUgdG8gcGFzc2l2ZSBh
bmQgdmljZSB2ZXJzYSwgZWl0aGVyIGltcGxpY2l0bHkgIA0KICAgICBvciBleHBsaWNpdGx5LiAN
CiAgIG8gJ2NhcGFiaWxpdGllcyByZS1uZWdvdGlhdGlvbicsIGFsbG93aW5nIGZvciBjaGFuZ2Vz
IGluICANCiAgICAgdGhlIGluaXRpYWwgY2FwYWJpbGl0aWVzIHNldCBvZiBwYXJ0aWNpcGFudHMg
ZHVyaW5nIHJ1bnRpbWUgb2YgdGhlICANCiAgICAgY29uZmVyZW5jZS4gDQogICAgDQogICBUaGlz
IGxpc3QgZG9lcyBub3QgY2xhaW0gdG8gYmUgZXhoYXVzdGl2ZS4gSG93ZXZlciwgaXQgcG9pbnRz
IGluIHRoZSANCiAgIGRpcmVjdGlvbiBvZiBwcm92aWRlZCBmdW5jdGlvbmFsaXR5IGZvciBjb25m
ZXJlbmNlIGNvdXJzZSBjb250cm9sIA0KICAgc29sdXRpb25zLiANCiAgICANCjQuICAgICBQcm9i
bGVtIFN0YXRlbWVudCANCiAgICANCiAgIFRoZXJlIGFyZSBtYW55IGFwcHJvYWNoZXMgaW4gdGhl
IHJlc2VhcmNoIGNvbW11bml0eSB0byByZWFsaXplIA0KICAgY29uZmVyZW5jZSBjb3Vyc2UgY29u
dHJvbCBhcyBwYXJ0IG9mIGEgY29uZmVyZW5jaW5nIGFyY2hpdGVjdHVyZS4gDQogICBBbHNvIGlu
IHN0YW5kYXJkaXphdGlvbiBib2RpZXMgKHN1Y2ggYXMgSC4zMjMgWzddIG9yIFNDQ1AgWzFdKSwg
DQogICBjb25mZXJlbmNlIGNvdXJzZSBjb250cm9sIGhhcyBiZWVuIGFkZHJlc3NlZC4gSG93ZXZl
ciwgbm9uZSBvZiB0aGVzZSANCiAgIGFwcHJvYWNoZXMgb2ZmZXJzIGEgdW5pZmllZCBhbmQgZmxl
eGlibGUgc29sdXRpb24gZm9yIGNvbmZlcmVuY2UgDQogICBjb3Vyc2UgY29udHJvbCB0byBjb3Zl
ciB0aGUgc3BlY3RydW0gb2Ygc2NlbmFyaW9zIG91dGxpbmVkIGluIA0KICAgU2VjdGlvbiA1LiAN
CiAgICANCiAgIFNwZWNpZmljYWxseSwgYSBjb25mZXJlbmNlIGNvdXJzZSBjb250cm9sIHNvbHV0
aW9uIHNob3VsZCANCiAgICANCiAgIG8gZml0IGludG8gdGhlIGFscmVhZHkgZGVmaW5lZCBjb25m
ZXJlbmNlIGNvbnRyb2wgYXJjaGl0ZWN0dXJlIGFuZCAgDQogICAgIGxldmVyYWdlIHRoZSBleGlz
dGluZyBzdWl0ZSBvZiBtZWNoYW5pc21zIGFuZCBwcm90b2NvbHMsIHN1Y2ggYXMgIA0KICAgICAq
IGNvbmZlcmVuY2UgZGVzY3JpcHRpb24sIGkuZS4sIFNEUCBbNF0gb3IgZnV0dXJlIHZlcnNpb25z
IChTREctbmcgIA0KICAgICAgIFs5XSksIGFuZCBpbml0aWF0aW9uLCBpLmUuLCBTSVAgWzVdIA0K
ICAgICAqIGxvY2FsIGNvb3JkaW5hdGlvbiwgaS5lLiwgTUJVUyBbMTBdIA0KICAgICAqIHRyYW5z
cG9ydCBsYXllciBwcm90b2NvbHMsIHN1Y2ggYXMgZm9yIHJlbGlhYmxlIG11bHRpY2FzdCwgcmVh
bC0gDQogICAgICAgdGltZSB0cmFuc2Zlciwgb3Igc2ltcGxlIHVuaWNhc3QgdHJhbnNtaXNzaW9u
IA0KICAgICAqIHNlY3VyaXR5IGNvbXBvbmVudHMsIHN1Y2ggYXMgZ3JvdXAga2V5IHNvbHV0aW9u
cyANCiAgIG8gcHJvdmlkZSBhIGZsZXhpYmxlIHNvbHV0aW9uLCBhbGxvd2luZyBmb3IgYSB2YXJp
ZXR5IG9mIHNjZW5hcmlvcyAgDQogICAgIChzZWUgU2VjdGlvbiA1KSBhbmQgY2hhcmFjdGVyaXN0
aWNzIHRvIGJlIHBsdWdnZWQgaW4gdGhlIHN5c3RlbS4gIA0KICAgIA0KICAgRm9yIHRoYXQsIGEg
YnVpbGRpbmcgYmxvY2sgYXBwcm9hY2ggd291bGQgYWxsb3cgdGhlIHByb3Zpc2lvbiBvZiANCiAg
IHN0YW5kYXJkaXplZCBpbnRlcmZhY2VzIHRvIHRoZSBkZXNpcmVkIGNvbW1vbiBmdW5jdGlvbmFs
aXR5LiBXaXRoIA0KICAgdGhhdCwgc3BlY2lmaWMgc2NlbmFyaW8tdGFpbG9yZWQgaW5zdGFudGlh
dGlvbnMgZm9yIGNlcnRhaW4gDQogICBmdW5jdGlvbmFsaXR5LCByZXByZXNlbnRlZCBieSBhIGJ1
aWxkaW5nIGJsb2NrLCBhcmUgZW5hYmxlZCANCiAgICAgDQpUcm9zc2VuICAgICAgICAgICAgICAg
ICBFeHBpcmVzIE5vdmVtYmVyIDIwMDEgICAgICAgICAgICAgICAgICAgICBbNF0gDQwNCkludGVy
bmV0IERyYWZ0ICAgICBDb3Vyc2UgQ29udHJvbCBQcm9ibGVtIFN0YXRlbWVudCAgICAgICAgICAg
TWF5IDIwMDEgDQogICAgDQogICAgDQogICBwcmVzZXJ2aW5nIHRoZSBjb21tb24gdmlldyBvZiB0
aGUgY29uZmVyZW5jZSBjb3Vyc2UgY29udHJvbCANCiAgIGZ1bmN0aW9uYWxpdHkuIA0KICAgIA0K
ICAgIA0KNS4gICAgIENvbmZlcmVuY2luZyBTY2VuYXJpb3MgDQogICAgDQogICBUaGlzIHNlY3Rp
b24gaW5mb3JtYWxseSBvdXRsaW5lcyBzY2VuYXJpbyBjYXRlZ29yaWVzIGZvciBtdWx0aW1lZGlh
IA0KICAgY29uZmVyZW5jaW5nIGluIHRoZSBJbnRlcm5ldC4gIA0KICAgIA0KICAgVGhlIGNvbmZl
cmVuY2luZyBzY2VuYXJpb3MgYXJlIGNhdGVnb3JpemVkIGluIHRocmVlIHNlY3Rpb25zLiBGb3Ig
DQogICBlYWNoIGNhdGVnb3J5LCB0eXBpY2FsIGNoYXJhY3RlcmlzdGljcyBhcmUgb3V0bGluZWQs
IGFuZCBleGFtcGxlcyANCiAgIGFyZSBnaXZlbi4gRmluYWxseSwgYSB0YWJsZS13aXNlIG92ZXJ2
aWV3IGlzIGRlcml2ZWQgZnJvbSB0aGUgbW9yZSANCiAgIGluZm9ybWFsIGRlc2NyaXB0aW9uIHBp
bnBvaW50aW5nIHRoZSB2ZXJ5IGZ1bmN0aW9uYWxpdHkgcmVxdWlyZWQgZm9yIA0KICAgdGhlIHNw
ZWNpZmljIHNjZW5hcmlvcy4gVGhpcyB0YWJsZS13aXNlIGRlc2NyaXB0aW9uIHdpbGwgYmUgdXNl
ZCBpbiANCiAgIFNlY3Rpb24gNSB0byBkaXNjdXNzIGNvbmZlcmVuY2UgY291cnNlIGNvbnRyb2wg
bW9kZWxzLiANCiAgICANCiAgIEl0IGlzIHdvcnRoIG1lbnRpb25pbmcgdGhhdCBzaW1wbGUgc3Ry
ZWFtaW5nIGlzIG5vdCBjb25zaWRlcmVkIGluIA0KICAgdGhlIGZvbGxvd2luZyBkdWUgdG8gaXRz
IGxhY2sgb2YgY29uZmVyZW5jZSBjb3Vyc2UgY29udHJvbCANCiAgIGZ1bmN0aW9uYWxpdHkuIEhv
d2V2ZXIsIGl0IG1pZ2h0IGJlIHVzZWQgdG8gcmVhbGl6ZSB2ZXJ5IHNpbXBsZSANCiAgIGNvbmZl
cmVuY2luZyBzY2VuYXJpb3Mgc3VjaCBhcyBJbnRlcm5ldCBsZWN0dXJlcywgd2hlcmUgZGF0YSBp
cyANCiAgIHNpbXBseSBzZW50IHRvIGEgc2V0IG9mIHJlY2VpdmVycyB3aXRob3V0IGZlZWRiYWNr
IG9yIGludGVyYWN0aW9uLiAgDQogICAgDQo1LjEuICAgU2ltcGxlIENvbmZlcmVuY2luZyANCiAg
ICANCiAgICdTaW1wbGUgQ29uZmVyZW5jaW5nJyByZWZsZWN0cyB0aGUgc2ltcGxlc3QgZm9ybSBv
ZiBjb25mZXJlbmNpbmcgDQogICB3aXRoIGEgY2hhbmdlIG9mIHRoZSBzZW5kZXIvcmVjZWl2ZXIg
cmVsYXRpb24gYmFzZWQgb24gY2VydGFpbiANCiAgICdzb2NpYWwgcnVsZXMnIGR1cmluZyB0aGUg
bGlmZXRpbWUgb2YgdGhlIGNvbmZlcmVuY2UuIA0KICAgIA0KICAgQ29uZmVyZW5jZXMgb2YgdGhp
cyB0eXBlIG1pZ2h0IGJlIGFubm91bmNlZCBiZWZvcmVoYW5kLCBpbmNsdWRpbmcgDQogICB0aGUg
Y29uZmVyZW5jZZJzIHByb2ZpbGUgaW5mb3JtYXRpb24sIG9yIHRoZXkgdGFrZSBwbGFjZSBhcyBh
ZC1ob2MgDQogICBtZWV0aW5ncy4gIA0KICAgIA0KICAgVGhlIGdyb3VwIG9mIHBhcnRpY2lwYW50
cyBtaWdodCBiZSB3ZWxsLWtub3duLCBpZiBhbm5vdW5jZWQsIG9yIGJlIA0KICAgYnVpbHQgYnkg
aW52aXRhdGlvbiBvciByZXF1ZXN0LiBGb3IgdGhhdCwgc2V2ZXJhbCBpbml0aWF0aW9uIG1vZGVs
cyANCiAgIG1pZ2h0IGJlIHJlYWxpemVkIChzZWUgYWxzbyBbMTFdKSwgd2hpY2ggcmVxdWlyZXMg
YXBwcm9wcmlhdGUgDQogICBpbml0aWF0aW9uIGZ1bmN0aW9uYWxpdHkgaW5jbHVkaW5nIGF1dGhl
bnRpY2F0aW9uIGFuZCBhdXRob3JpemF0aW9uIA0KICAgbWVhbnMgZm9yIHJlc3RyaWN0ZWQgYWNj
ZXNzIHRvIHRoZSBjb25mZXJlbmNlLiAgDQogICAgDQogICBGbG9vciBjb250cm9sIGZ1bmN0aW9u
YWxpdHksIGUuZy4sIHRvIHJlYWxpemUgY29uZHVjdGVkIG1lZXRpbmcgDQogICBmdW5jdGlvbmFs
aXR5LCBpcyBub3QgcHJvdmlkZWQgaW4gdGhpcyBjYXRlZ29yeS4gRHVlIHRvIHRoaXMgbGFjayBv
ZiANCiAgIG1lZGlhdGlvbiBjb25jZXJuaW5nIHRoZSBhY2Nlc3Mgb24gdGhlIGNvbW1vbiBtZWRp
YSByZXNvdXJjZSwgdGhlIA0KICAgbGV2ZWwgb2YgaW50ZXJhY3Rpdml0eSBpcyB1c3VhbGx5IGxp
bWl0ZWQsIGV2ZW4gaWYgc2NhbGFibGUgDQogICBtdWx0aWNhc3QgdHJhbnNmZXIgaXMgdXNlZC4g
IA0KICAgIA0KICAgVXN1YWxseSwgdGhlIGluaXRpYWwgc2V0IG9mIGNhcGFiaWxpdGllcyBpcyBu
b3QgY2hhbmdlZCwgaS5lLiwgcmUtDQogICBuZWdvdGlhdGVkLCBkdXJpbmcgcnVudGltZSBvZiB0
aGUgY29uZmVyZW5jZS4gSG93ZXZlciwgc29tZSBzaW1wbGUgDQogICBmb3JtIG9mIHJlLW5lZ290
aWF0aW9uIGNvdWxkIGJlIHByb3ZpZGVkLiANCiAgICANCiAgIEFsdGhvdWdoIHRoZSBudW1iZXIg
b2YgcGFydGljaXBhbnRzIGNhbiBlYXNpbHkgcmVhY2ggc2V2ZXJhbCANCiAgIHRob3VzYW5kcyBv
ciBldmVuIG1vcmUsIHdoZW4gdXNpbmcgbXVsdGljYXN0IHRyYW5zZmVyIGNhcGFiaWxpdGllcywg
DQogICBpdCBpcyBleHBlY3RlZCB0aGF0IHRoZSByZXF1aXJlbWVudHMgZm9yIHByZWNpc2UgbWVt
YmVyc2hpcCANCiAgIGluZm9ybWF0aW9uIGFyZSBsZXNzIHN0cmluZ2VudCBpbiBsYXJnZXIgc2Nh
bGVkIGNvbmZlcmVuY2VzLiANCiAgICANCiAgICAgDQpUcm9zc2VuICAgICAgICAgICAgICAgICBF
eHBpcmVzIE5vdmVtYmVyIDIwMDEgICAgICAgICAgICAgICAgICAgICBbNV0gDQwNCkludGVybmV0
IERyYWZ0ICAgICBDb3Vyc2UgQ29udHJvbCBQcm9ibGVtIFN0YXRlbWVudCAgICAgICAgICAgTWF5
IDIwMDEgDQogICAgDQogICAgDQo1LjEuMS4gRXhhbXBsZXMgDQogICAgDQogICBFeGFtcGxlcyBm
b3Igc2ltcGxlIGNvbmZlcmVuY2luZyBpbmNsdWRlIGFkLWhvYyBvciBwcmUtcGxhbm5lZCBzbWFs
bCANCiAgIGdyb3VwIG1lZXRpbmdzLCByaWNoIGNhbGxzLCBJbnRlcm5ldCBsZWN0dXJlcywgdGVs
ZS13b3JraW5nIGluIGEgDQogICB0ZWFtLiBNb3N0IG9mIHRoZSBjdXJyZW50IE1Cb25lIFsyXSBz
ZXNzaW9ucyBhcmUgdHlwaWNhbCBleGFtcGxlcyANCiAgIGZvciBzaW1wbGUgY29uZmVyZW5jaW5n
LiANCiAgICANCjUuMi4gICBGbG9vciBDb250cm9sbGVkIENvbmZlcmVuY2luZyANCiAgICANCiAg
IFNjZW5hcmlvcyBvZiB0aGlzIGNhdGVnb3J5IGVucmljaCB0aGUgc2ltcGxlIGNvbmZlcmVuY2lu
ZyANCiAgIGZ1bmN0aW9uYWxpdHkgb2Ygc2VjdGlvbiA1LjEuIGJ5IHByb3ZpZGluZyBmbG9vciBj
b250cm9sIGZhY2lsaXRpZXMgDQogICB0byBjb250cm9sIHRoZSBhY2Nlc3Mgb24gZGlzdHJpYnV0
ZWQgcmVzb3VyY2VzLiBBbW9uZyBvdGhlcnMsIHRoZXNlIA0KICAgZGlzdHJpYnV0ZWQgcmVzb3Vy
Y2VzIG1pZ2h0IHJlZmxlY3QgdGhlIGNvbW1vbmx5IHVzZWQgYXVkaW92aXN1YWwgDQogICBjaGFu
bmVsIHdpdGhpbiB0aGUgY29uZmVyZW5jZSBidXQgYWxzbyB0aGUgY29udGVudCBvZiBhIHNoYXJl
ZCANCiAgIHdoaXRlYm9hcmQsIG9yIGEgc2hhcmVkLCBsb2NhbGx5IGhvc3RlZCBhcHBsaWNhdGlv
bi4gVGhlIGZsb29yIA0KICAgY29udHJvbCBzZW1hbnRpY3MgYXJlIHVzdWFsbHkga25vd24gYmVm
b3JlaGFuZCwgb3IgdGhleSBtaWdodCBiZSANCiAgIGRpc3RyaWJ1dGVkIHVzaW5nIHRoZSBjb25m
ZXJlbmNlIHByb2ZpbGUgaW5mb3JtYXRpb24uIFRoZSANCiAgIHJlYWxpemF0aW9uIG9mIHRoZSBm
bG9vciBjb250cm9sIHNlbWFudGljcyBpcyB1c3VhbGx5IGhpZ2hseSANCiAgIGFwcGxpY2F0aW9u
LXNwZWNpZmljLiANCiAgICANCiAgIEZvciBpbnN0YW5jZSwgZmxvb3IgY29udHJvbGxlZCBjb25m
ZXJlbmNpbmcgbWlnaHQgYWxsb3cgJ2NvbmR1Y3RlZCANCiAgIG1lZXRpbmdzJywgZW5hYmxpbmcg
dGhlIGNvbmR1Y3RvciBvZiBhIGNvbmZlcmVuY2UgZm9yIGluc3RhbmNlIHRvIA0KICAgZWplY3Qg
cGFydGljaXBhbnRzIGZyb20gYSBjb25mZXJlbmNlIG9yIHRvIGRlbnkgYWNjZXNzIHRvIHRoZSAN
CiAgIGNvbmZlcmVuY2UuIEhvd2V2ZXIsIGluIGFkZGl0aW9uIHRvIHRoZSByZWFsaXphdGlvbiBv
ZiB0aGUgc29jaWFsIA0KICAgcnVsZXMgYnkgbWVhbnMgb2YgZmxvb3IgY29udHJvbCwgYXBwcm9w
cmlhdGUgZnVuY3Rpb25hbGl0eSB0byANCiAgIGVuZm9yY2UgdGhlbSBvbiBkYXRhIGxldmVsIGlz
IHJlcXVpcmVkIGJ5IG1lYW5zIG9mIGV4Y2x1ZGluZyANCiAgIHJlY2VpdmVyIHNldHMgZnJvbSBy
ZWNlcHRpb24uIA0KICAgIA0KICAgQ2FwYWJpbGl0aWVzIHJlLW5lZ290aWF0aW9uIGlzIHVzdWFs
bHkgcHJvdmlkZWQgaW4gdGhlc2Ugc2NlbmFyaW9zLCANCiAgIHdoaWNoIG1pZ2h0IGFsc28gYmUg
dGllZCB0byB0aGUgaW1wbGVtZW50ZWQgZmxvb3IgY29udHJvbCBwb2xpY3kgb2YgDQogICB0aGUg
c3BlY2lmaWMgc2NlbmFyaW8uIA0KICAgIA0KICAgSW4gZmxvb3IgY29udHJvbGxlZCBjb25mZXJl
bmNlcywgdGhlcmUgaXMgYW4gZXhhY3Qga25vd2xlZGdlIG9mIHRoZSANCiAgIGN1cnJlbnQgbWVt
YmVyc2hpcCBpbmZvcm1hdGlvbiBvZiB0aGUgcGFydGljaXBhbnRzLiBVc3VhbGx5LCB0aGUgDQog
ICBpbXBsZW1lbnRhdGlvbiBvZiB0aGUgZmxvb3IgY29udHJvbCByZXN0cmljdHMgdGhlIHNjYWxh
YmlsaXR5IG9mIA0KICAgdGhpcyB0eXBlIG9mIGNvbmZlcmVuY2VzIHRvIGEgZmV3IHRlbnMuIEhv
d2V2ZXIsIGFwcHJvYWNoZXMgYXMgDQogICBwcm9wb3NlZCBpbiBbMTNdLCBtaWdodCBiZSB1c2Vk
IGluIHNwZWNpZmljIHNjZW5hcmlvcyB0byBpbXByb3ZlIHRoZSANCiAgIHNjYWxhYmlsaXR5LiAN
CiAgICANCjUuMi4xLiBFeGFtcGxlcyANCiAgICANCiAgIEV4YW1wbGVzIGZvciBmbG9vciBjb250
cm9sbGVkIGNvbmZlcmVuY2VzIGluY2x1ZGUgc2NlbmFyaW9zIHdpdGggdGhlIA0KICAgbmVlZCB0
byByZWFsaXplIHNvY2lhbCBydWxlcyBvciBhY2Nlc3MgY29udHJvbCBvbiBzaGFyZWQgcmVzb3Vy
Y2VzLCANCiAgIHN1Y2ggYXMgY29uZHVjdGVkIG1lZXRpbmdzLCBhcHBsaWNhdGlvbiBzaGFyaW5n
IHNlc3Npb25zLCBkaXN0YW5jZSANCiAgIGxlYXJuaW5nIGluY2x1ZGluZyBkZW1vbnN0cmF0aW9u
IG9mIHNoYXJlZCBpbmZvcm1hdGlvbiwgdGVsZS13b3JraW5nIA0KICAgd2l0aCBjb21tb24gcmVz
b3VyY2VzIHRvIHNoYXJlLiANCiAgICANCjUuMy4gICBSaWNoIENvbmZlcmVuY2luZyANCiAgICAN
CiAgIEEgJ3JpY2ggY29uZmVyZW5jaW5nJyBldmVudCwgd2hpY2ggaXMgZ29pbmcgdG8gaGFwcGVu
LCBtaWdodCBiZSANCiAgIGFubm91bmNlZCBiZWZvcmVoYW5kIGJ1dCBhbiBhZC1ob2MgZXN0YWJs
aXNobWVudCBtaWdodCBhbHNvIGJlIA0KICAgY29uc2lkZXJlZCwgc3VjaCBhcyBhICdyYW5kb21s
eSBnYXRoZXJpbmcgYSBjcm93ZCBhcm91bmQgYW4gDQogICAgIA0KVHJvc3NlbiAgICAgICAgICAg
ICAgICAgRXhwaXJlcyBOb3ZlbWJlciAyMDAxICAgICAgICAgICAgICAgICAgICAgWzZdIA0MDQpJ
bnRlcm5ldCBEcmFmdCAgICAgQ291cnNlIENvbnRyb2wgUHJvYmxlbSBTdGF0ZW1lbnQgICAgICAg
ICAgIE1heSAyMDAxIA0KICAgIA0KICAgIA0KICAgYXR0cmFjdGlvbicuIEF1dGhlbnRpY2F0aW9u
IGFuZCBhdXRob3JpemF0aW9uIG1lYW5zIG1pZ2h0IGJlIHVzZWQgDQogICBmb3IgcmVzdHJpY3Rl
ZCBhY2Nlc3MgdG8gdGhlIGV2ZW50LiANCiAgICANCiAgIFVzdWFsbHksIHRoZXJlIGlzIGEgKHNt
YWxsKSB3ZWxsLWtub3duIGdyb3VwIG9mIGFjdGl2ZSBwYXJ0aWNpcGFudHMsIA0KICAgaS5lLiwg
ZXhhY3QgbWVtYmVyc2hpcCBpbmZvcm1hdGlvbiBpcyByZXF1aXJlZCwgYW5kIGEgbGFyZ2VyIGdy
b3VwIA0KICAgb2YgcGFzc2l2ZSBwYXJ0aWNpcGFudHMuIE1lbWJlcnNoaXAgaW5mb3JtYXRpb24g
Zm9yIHRoaXMgbGFyZ2VyIA0KICAgZ3JvdXAgaXMgbGVzcyBzdHJpY3RseSBwcm92aWRlZCwgY29t
cGFyYWJsZSB3aXRoICdibHVlIHNoZWV0cycgDQogICBhdHRlbmRlZXMgbGlzdHMuICANCiAgICAN
CiAgIFRoZSBhY2Nlc3MgY29udHJvbCB3aXRoaW4gdGhlIGdyb3VwIG9mIGFjdGl2ZSBwYXJ0aWNp
cGFudHMgaXMgDQogICByZWFsaXplZCBieSBtZWFucyBvZiBmbG9vciBjb250cm9sIHJlYWxpemlu
ZyBzcGVjaWZpYyBzb2NpYWwgDQogICBpbnRlcmFjdGlvbnMgKGNvbmR1Y3RlZCBzZXNzaW9uLCBw
YW5lbCBncm91cCkgc2ltaWxhciB0byBmbG9vciANCiAgIGNvbnRyb2xsZWQgY29uZmVyZW5jaW5n
LiANCiAgICANCiAgIEFzIGEgc3BlY2lmaWMgY2hhcmFjdGVyaXN0aWMgb2YgdGhpcyBjYXRlZ29y
eSwgZnJlcXVlbnQgY2hhbmdlcyANCiAgIGJldHdlZW4gYWN0aXZlIGFuZCBwYXNzaXZlIHBhcnRp
Y2lwYXRpb24gaW4gdGhlIGNvbmZlcmVuY2UgYXJlIA0KICAgaGFwcGVuaW5nLCBlLmcuLCBhIHBh
c3NpdmUgb2JzZXJ2ZXIgKHBhcnRpY2lwYW50KSBvZiB0aGUgZXZlbnQgbWlnaHQgDQogICByYWlz
ZSBpdHMgaW50ZXJlc3QgaW4gYmVjb21pbmcgYWN0aXZlIGluIHRoZSBkaXNjdXNzaW9uLCBlaXRo
ZXIgYnkgDQogICBvd24gcmVxdWVzdCBvciBieSBpbnZpdGF0aW9uLCBmb2xsb3dpbmcgdGhlIHNw
ZWNpZmljIGFjY2VzcyBydWxlcyBvZiANCiAgIHRoZSBhY3RpdmUgcGFydGljaXBhbnQgZ3JvdXAg
aW1wbGVtZW50ZWQgYnkgYXBwcm9wcmlhdGUgZmxvb3IgDQogICBjb250cm9sIG1lYW5zLiBUaGUg
bW9kZSBjaGFuZ2UgY291bGQgaGFwcGVuICdleHBsaWNpdGx5JywgaS5lLiwgYnkgDQogICBqb2lu
aW5nIHRoZSBhY3RpdmUgbWVtYmVyIGdyb3VwLCBvciAnaW1wbGljaXRseScsIGkuZS4sIGJ5IA0K
ICAgcmVxdWVzdGluZyBmbG9vciBjb250cm9sIHNlcnZpY2VzLiANCiAgICANCiAgIFRoaXMgbW9k
ZSBjaGFuZ2Ugc2hvdWxkIGJlIHBvc3NpYmxlIGluIHRoZSByZXZlcnNlIGRpcmVjdGlvbiwgdG9v
LCANCiAgIGkuZS4sIHdoZW4gYW4gYWN0aXZlIHBhcnRpY2lwYW50IGxvb3NlcyBpbnRlcmVzdCBp
biBhY3RpdmUgDQogICBwYXJ0aWNpcGF0aW9uLiANCiAgICANCjUuMy4xLiBFeGFtcGxlcyANCiAg
ICANCiAgIEV4YW1wbGVzIGZvciBsYXJnZSBzY2FsZSByaWNoIGNvbmZlcmVuY2luZyBzY2VuYXJp
b3MgYXJlIHRvd24gaGFsbCANCiAgIG1lZXRpbmdzLCBJRVRGIHdvcmtpbmcgZ3JvdXAgbWVldGlu
Z3MsIHZpcnR1YWwgbGVjdHVyZXMgd2l0aCANCiAgIGZlZWRiYWNrLCB2aXJ0dWFsIG5ld3Nncm91
cHMuIEhvd2V2ZXIsIGV4YW1wbGVzIGZvciBzaW1wbGUgYW5kIGZsb29yIA0KICAgY29udHJvbGxl
ZCBjb25mZXJlbmNpbmcgYXJlIGFsc28gYXBwbGljYWJsZSBmb3IgdGhpcyBjYXRlZ29yeSBkdWUg
dG8gDQogICB0aGUgc3VwZXJzZXQgY2hhcmFjdGVyIG9mIHRoZSByaWNoIGNvbmZlcmVuY2luZyBj
YXRlZ29yeSBjb21wYXJlZCB0byANCiAgIHRoZSBvdGhlciBvbmVzLiANCiAgICANCjUuNC4gICBT
dW1tYXJ5IG9mIENoYXJhY3RlcmlzdGljcyANCiAgICANCiAgIFRoZSBmb2xsb3dpbmcgdGFibGUg
c3VtbWFyaXplcyB0aGUgbWFpbiBjaGFyYWN0ZXJpc3RpY3MgZm9yIHRoZSANCiAgIGRpZmZlcmVu
dCBzY2VuYXJpbyBjYXRlZ29yaWVzIHByZXNlbnRlZCBpbiBzZWN0aW9uIDUuMS4gdG8gNS4zLiAN
CiAgICcoKyknIGluZGljYXRlcyBvcHRpb25hbCBmdW5jdGlvbmFsaXR5LiAgDQogICAgDQogICBU
aGUgZmlyc3QgYmxvY2sgb2YgY2hhcmFjdGVyaXN0aWNzIGlzIHJlZmVycmVkIHRvIGFzIGNvbmZl
cmVuY2UgDQogICBpbml0aWF0aW9uIGFuZCBzZXR1cCAoc2VlIFszXSksIHdoaWxlIHRoZSBzZWNv
bmQgYmxvY2sgaXMgZGVkaWNhdGVkIA0KICAgdG8gY29uZmVyZW5jZSBjb3Vyc2UgY29udHJvbCBm
dW5jdGlvbmFsaXR5LiANCiAgICANCiAgICANCiAgICANCiAgIC0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIA0KICAgfCBGdW5jdGlv
bmFsaXR5ICAgIHwgIFNpbXBsZSAgICAgfCAgICBGLkMuICAgICB8ICAgUmljaCAgICAgIHwgDQog
ICB8ICAgICAgICAgICAgICAgICAgfCAgIENvbmYuICAgICB8ICAgQ29uZi4gICAgIHwgICBDb25m
LiAgICAgfCANCiAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tIA0KICAgICANClRyb3NzZW4gICAgICAgICAgICAgICAgIEV4cGly
ZXMgTm92ZW1iZXIgMjAwMSAgICAgICAgICAgICAgICAgICAgIFs3XSANDA0KSW50ZXJuZXQgRHJh
ZnQgICAgIENvdXJzZSBDb250cm9sIFByb2JsZW0gU3RhdGVtZW50ICAgICAgICAgICBNYXkgMjAw
MSANCiAgICANCiAgICANCiAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIA0KICAgfCBQcm9maWxlIEluZi4gICAgIHwgICAgICAr
ICAgICAgfCAgICAgICsgICAgICB8ICAgICAgKyAgICAgIHwgDQogICB8ICAgICAgICAgICAgICAg
ICAgfCAgICAgICAgICAgICB8ICAgIGluY2wuICAgIHwgICAgaW5jbC4gICAgfCANCiAgIHwgICAg
ICAgICAgICAgICAgICB8ICAgICAgICAgICAgIHwgIGZsb29yIGluZi4gfCAgZmxvb3IgaW5mLiB8
IA0KICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0gDQogICB8IEluaXRpYXRpb24gICAgICAgfCAgYW5ub3VuY2VkICB8ICBhbm5v
dW5jZWQgIHwgIGFubm91bmNlZCAgfCANCiAgIHwgICAgICAgICAgICAgICAgICB8ICAgaW52aXRl
ZCAgIHwgICBpbnZpdGVkICAgfCAgIGludml0ZWQgICB8IA0KICAgLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gDQogICB8IENhcGFi
aWxpdGllcyAgICAgfCAgICAgKCspICAgICB8ICAgICAgKyAgICAgIHwgICAgICArICAgICAgfCAN
CiAgIHwgUmUtbmVnb3RpYXRpb24gICB8ICAgICAgICAgICAgIHwgICAgICAgICAgICAgfCAgICAg
ICAgICAgICB8IA0KICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0gDQogICB8IEF1dGhlbnRpY2F0aW9uICsgfCAgICAgKCspICAg
ICB8ICAgICAoKykgICAgIHwgICAgICgrKSAgICAgfCANCiAgIHwgQXV0aG9yaXphdGlvbiAgICB8
ICAgICAgICAgICAgIHwgICAgICAgICAgICAgfCAgICAgICAgICAgICB8IA0KICAgLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gDQog
ICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLSANCiAgIHwgTWVtYmVyc2hpcCBJbmZvICB8ICAgICAgKyAgICAgIHwgICAgICArICAg
ICAgfCAgICAgICsgICAgICB8IA0KICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gDQogICB8IEZsb29yIENvbnRyb2wgICAgfCAg
ICAgIC0gICAgICB8ICAgICAgKyAgICAgIHwgICAgKyAoZm9yICAgfCANCiAgIHwgICAgICAgICAg
ICAgICAgICB8ICAgICAgICAgICAgIHwgICAgICAgICAgICAgfCAgICBhY3RpdmUpICB8IA0KICAg
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0gDQogICB8IE1lbWJlcnNoaXAgICAgICAgfCAgYXQgc3RhcnR1cCB8IGJhc2VkIG9uICAg
IHwgYmFzZWQgb24gICAgfCANCiAgIHwgRW5mb3JjZW1lbnQgICAgICB8ICAgICBvbmx5ICAgIHwg
Zmxvb3IgY3RybCAgfCBmbG9vciBjdHJsICB8IA0KICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gDQogICB8IEFjdGl2ZS9QYXNz
aXZlICAgfCAgICAgIC0gICAgICB8ICAgICAgLSAgICAgIHwgICAgICArICAgICAgfCANCiAgIHwg
TW9kZSBDaGFuZ2UgICAgICB8ICAgICAgICAgICAgIHwgICAgICAgICAgICAgfCAgICAgICAgICAg
ICB8IA0KICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0gDQogICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSANCiAgIHwgU2NhbGUgICAgICAgICAgICB8IHNtYWxs
IGR1ZSB0b3wgZGVwZW5kcyBvbiAgfCAgIGxhcmdlICAgICB8IA0KICAgfCAgICAgICAgICAgICAg
ICAgIHwgbGFjayBvZiAgICAgfCBmbG9vciAgY3RybC58ICAgICAgICAgICAgIHwgDQogICB8ICAg
ICAgICAgICAgICAgICAgfCBtZWRpYXRpb24gICB8IHNjYWxlICAgICAgIHwgICAgICAgICAgICAg
fCANCiAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tIA0KICAgICAgICAgICAgICBUYWJsZSAxIDogU3VtbWFyeSBvZiBDaGFyYWN0
ZXJpc3RpY3MgDQogICAgDQogICBUaGUgZm9sbG93aW5nIEZpZ3VyZSAxIHRyaWVzIHRvIG91dGxp
bmUgdGhlIGNhdGVnb3JpZXMgb2YgdGhpcyANCiAgIHNlY3Rpb24gaW4gYSBzY2FsZS1mdW5jdGlv
bmFsaXR5IHNwYWNlLCBlbXBoYXNpemluZyB0aGUgc3VwZXJzZXQgDQogICBjaGFyYWN0ZXIgb2Yg
dGhlICdyaWNoIGNvbmZlcmVuY2luZycgY2F0ZWdvcnkuIA0KICAgIA0KICAgU2NhbGUgL3xcIA0K
ICAgICAgICAgIHx8LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS18IA0KICAgICAgICAgIHx8ICAgICAgICAgICAgICAgIFJpY2ggQ29uZmVyZW5jaW5nICAg
ICAgICAgICAgICAgICB8IA0KICAgICAgICAgIHx8ICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICB8IA0KICAgICAgICAgIHx8ICAgICAgICBUb3duIEhhbGwg
TWVldGluZ3MsIElFVEYgTWVldGluZ3MgICAgICAgICB8IA0KICAgICAgICAgIHx8fC0tLS0tLS0t
LS0tLS0tLS0tLS0tLS18fC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLXx8IA0KICAgICAgICAgIHx8
fCBTaW1wbGUgQ29uZmVyZW5jaW5nICB8fCBGbG9vciBDb250cm9sbGVkIENvbmYuIHx8IA0KICAg
ICAgICAgIHx8fCAgICAgICAgICAgICAgICAgICAgICB8fCAgICAgICAgICAgICAgICAgICAgICAg
IHx8IA0KICAgICAgICAgIHx8fCBMZWN0dXJlcywgTWVldGluZ3MgICB8fCBjb25kdWN0ZWQgbWVl
dGluZ3MgICAgIHx8IA0KICAgICAgICAgIHx8fC0tLS0tLS0tLS0tLS0tLS0tLS0tLS18fC0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLXx8IA0KICAgICAgICAgIHx8LS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIA0KICAgICAgICAgIHwtLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPiANCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBGdW5jdGlvbmFsaXR5IA0KICAgIA0K
ICAgICAgICAgICAgICBGaWd1cmUgMSA6IENhdGVnb3JpZXMgaW4gU2NhbGUtRnVuY3Rpb25hbGl0
eSBTcGFjZSANCiAgICANCiAgICAgDQpUcm9zc2VuICAgICAgICAgICAgICAgICBFeHBpcmVzIE5v
dmVtYmVyIDIwMDEgICAgICAgICAgICAgICAgICAgICBbOF0gDQwNCkludGVybmV0IERyYWZ0ICAg
ICBDb3Vyc2UgQ29udHJvbCBQcm9ibGVtIFN0YXRlbWVudCAgICAgICAgICAgTWF5IDIwMDEgDQog
ICAgDQogICAgDQo2LiAgICAgQ29uZmVyZW5jZSBDb3Vyc2UgQ29udHJvbCBNb2RlbHMgDQogICAg
DQogICBUaGUgY29uZmVyZW5jaW5nIHNjZW5hcmlvcyBpbiBTZWN0aW9uIDUgY2FuIGVhc2lseSBi
ZSBtYXBwZWQgb250byANCiAgIG1vZGVscyBmb3IgcmVhbGl6ZSBjb25mZXJlbmNlIGNvdXJzZSBj
b250cm9sIHJlYWxpemF0aW9uIHdpdGggDQogICByZXNwZWN0IHRvIHRoZSBmdW5jdGlvbmFsaXRp
ZXMgcHJlc2VudGVkIGluIFNlY3Rpb24gMi4gDQogICAgDQo2LjEuICAgTG9vc2UgQ29uZmVyZW5j
ZSBDb3Vyc2UgQ29udHJvbCANCiAgICANCiAgICdMb29zZScgY29uZmVyZW5jZSBjb3Vyc2UgY29u
dHJvbCAoYWxzbyByZWZlcnJlZCB0byBhcyAnbGlnaHQtd2VpZ2h0IA0KICAgc2Vzc2lvbiBjb250
cm9sJyBbM10pIGlzIHRoZSBtb2RlbCBhcHBsaWNhYmxlIGZvciB0aGUgc2ltcGxlIA0KICAgY29u
ZmVyZW5jaW5nIHNjZW5hcmlvIGNhdGVnb3J5IG9mIFNlY3Rpb24gNS4xLiAgDQogICAgDQogICBI
ZW5jZSwgdGhpcyBjb250cm9sIG1vZGVsIGxhY2tzIG9mIGV4cGxpY2l0IG1lbWJlcnNoaXAgYW5k
IA0KICAgYXBwbGljYXRpb24gc2Vzc2lvbiBjb250cm9sLiBGdXJ0aGVybW9yZSwgZmxvb3IgY29u
dHJvbCBmYWNpbGl0aWVzIA0KICAgYXJlIG5vdCBwcm92aWRlZC4gSG93ZXZlciwgbWVtYmVyc2hp
cCBpbmZvcm1hdGlvbiBtaWdodCBiZSBnYXRoZXJlZCANCiAgIGR1cmluZyBydW50aW1lIG9mIHRo
ZSBzZXNzaW9uLCBjb21wYXJhYmxlIHdpdGggdGhlIGJsdWUgc2hlZXRzIG9mIA0KICAgYXR0ZW5k
ZWVzLiANCiAgICANCiAgIFVzdWFsbHksIGdyb3VwIGtleSBtZWNoYW5pc21zIGFyZSBhbHNvIG1p
c3NpbmcgZm9yIG1lbWJlcnNoaXAgDQogICBlbmZvcmNlbWVudCBhZnRlciBzdGFydGluZyB0aGUg
Y29uZmVyZW5jZS4gDQogICAgDQo2LjIuICAgVGlnaHQgQ29uZmVyZW5jZSBDb3Vyc2UgQ29udHJv
bCANCiAgICANCiAgICdUaWdodCcgY29uZmVyZW5jZSBjb3Vyc2UgY29udHJvbCBbM10gaXMgdGhl
IG1vZGVsIGFwcGxpY2FibGUgZm9yIA0KICAgdGhlIGZsb29yIGNvbnRyb2wgY29uZmVyZW5jaW5n
IHNjZW5hcmlvIGNhdGVnb3JpZXMgb2YgU2VjdGlvbiA1LjIuIA0KICAgIA0KICAgSGVuY2UsIGFk
ZGl0aW9uYWwgZmxvb3IgY29udHJvbCBpbmZvcm1hdGlvbiBvZiB0aGUgY29uZmVyZW5jZSANCiAg
IHByb2ZpbGUgb3Igc3RhdGljYWxseSBpbXBsZW1lbnRlZCBhcHBsaWNhdGlvbiBzZW1hbnRpYyBh
cmUgdXNlZCBmb3IgDQogICBpbXBsZW1lbnRpbmcgZmxvb3IgY29udHJvbCB0byBtYXAgJ3NvY2lh
bCBwcm90b2NvbCcgc2VtYW50aWNzIG9udG8gDQogICB0aGUgZGlzdHJpYnV0ZWQgc2NlbmFyaW8u
IEV4YWN0IG1lbWJlcnNoaXAgYW5kIGFwcGxpY2F0aW9uIHNlc3Npb24gDQogICBpbmZvcm1hdGlv
biBpcyB1c3VhbGx5IHByb3ZpZGVkIHRvZ2V0aGVyIHdpdGggbWVtYmVyc2hpcCBlbmZvcmNlbWVu
dCANCiAgIGJhc2VkIG9uIGZsb29yIGNvbnRyb2wgcG9saWNpZXMgZHVyaW5nIHJ1bnRpbWUgb2Yg
dGhlIGNvbmZlcmVuY2UuIA0KICAgIA0KNi4zLiAgICdKZWxseS1saWtlJyBDb25mZXJlbmNlIENv
dXJzZSBDb250cm9sIA0KICAgIA0KICAgQXMgYSBjb21iaW5hdGlvbiBvZiB0aGUgbG9vc2UgYW5k
IHRpZ2h0IGNvbnRyb2wgbW9kZWwgb2YgU2VjdGlvbiANCiAgIDYuMS4gYW5kIDYuMi4sICdqZWxs
eS1saWtlJyBjb3Vyc2UgY29udHJvbCBpcyBjb25zaWRlcmVkIGZvciByaWNoIA0KICAgY29uZmVy
ZW5jaW5nIChzZWUgU2VjdGlvbiA1LjMuKSByZWFsaXphdGlvbi4gDQogICAgDQogICBUaGUgdGln
aHQgY29udHJvbCBtb2RlbCBpcyBhcHBsaWVkIGZvciB0aGUgYWN0aXZlIHBhcnRpY2lwYW50cyBp
biANCiAgIHRoZSBjb25mZXJlbmNlLCB3aGlsZSBhIGxvb3NlIGNvbnRyb2wgbW9kZWwgaXMgdXNl
ZCBmb3IgdGhlIHBhc3NpdmUgDQogICBvbmVzLiBJbiBhZGRpdGlvbiB0byB0aGUgZnVuY3Rpb25h
bGl0eSBmb3IgdGhlIHNwZWNpZmljIHVzZXIgZ3JvdXAsIA0KICAgaS5lLiwgYWN0aXZlIG9yIHBh
c3NpdmUsIG1lY2hhbmlzbXMgdG8gc3VwcG9ydCBtb2RlIGNoYW5nZXMgZnJvbSANCiAgIGFjdGl2
ZSB0byBwYXNzaXZlIGFuZCB2aWNlIHZlcnNhIG1pZ2h0IGJlIHJlcXVpcmVkIHdpdGhvdXQgDQog
ICBkaXN0dXJiYW5jZSwgaS5lLiwgaW50ZXJydXB0aW9uLCBvZiB0aGUgcnVubmluZyBjb25mZXJl
bmNlLiANCiAgICANCiAgIERpZmZlcmVudCBwb2xpY2llcyBmb3IgdGhpcyBtb2RlIGNoYW5nZSBz
aG91bGQgYmUgZmVhc2libGUsIHN1Y2ggYXMgDQogICB1cG9uIGludml0YXRpb24gYnkgaW5kaXZp
ZHVhbCBhY3RpdmUgcGFydGljaXBhbnRzIG9yIHVwb24gcmVxdWVzdCBvZiANCiAgIHRoZSBwYXNz
aXZlIHBhcnRpY2lwYW50LiANCiAgICANCjcuICAgICBFeGlzdGluZyBTb2x1dGlvbnMgDQogICAg
DQogICAgIA0KVHJvc3NlbiAgICAgICAgICAgICAgICAgRXhwaXJlcyBOb3ZlbWJlciAyMDAxICAg
ICAgICAgICAgICAgICAgICAgWzldIA0MDQpJbnRlcm5ldCBEcmFmdCAgICAgQ291cnNlIENvbnRy
b2wgUHJvYmxlbSBTdGF0ZW1lbnQgICAgICAgICAgIE1heSAyMDAxIA0KICAgIA0KICAgIA0KICAg
VGhlIGZvbGxvd2luZyBzZWN0aW9uIGlzIGJyaWVmbHkgZXZhbHVhdGluZyBleGlzdGluZyBjb25m
ZXJlbmNpbmcgDQogICBzb2x1dGlvbnMgd2l0aCByZXNwZWN0IHRvIHRoZWlyIGNvbmZlcmVuY2Ug
Y291cnNlIGNvbnRyb2wgDQogICBmdW5jdGlvbmFsaXR5LiBOb3RlIHRoYXQgdGhpcyBwcmVzZW50
YXRpb24gaXMgcmVzdHJpY3RlZCB0byBzeXN0ZW1zIA0KICAgYmFzZWQgb24gY2VydGFpbiBzdGFu
ZGFyZHMsIGhlbmNlIHRoaXMgbGlzdCBkb2VzIG5vdCBjbGFpbSB0byBiZSBhbiANCiAgIGV4aGF1
c3RpdmUgcmV2aWV3IG9mIGV4aXN0aW5nIGNvbmZlcmVuY2luZyBzeXN0ZW1zLiANCiAgICANCiAg
IFRoZSBmb2xsb3dpbmcsIGludGVydHdpbmVkLCBjcml0ZXJpYSBhcmUgdXNlZCB0byBldmFsdWF0
ZSB0aGVzZSANCiAgIHNvbHV0aW9uczogDQogICBvIFByb3ZpZGVkIEZ1bmN0aW9uYWxpdHk6IFdo
YXQgZnVuY3Rpb25hbGl0eSBpcyBwcm92aWRlZCB3aXRoICANCiAgICAgcmVzcGVjdCB0byBUYWJs
ZSAxPyANCiAgIG8gRmxleGliaWxpdHk6IFdoYXQgc2NlbmFyaW9zIGFyZSBjb3ZlcmVkPyBXaGF0
IHBvbGljaWVzIGFyZSAgDQogICAgIHByb3ZpZGVkPyBIb3cgZmxleGlibGUgaXMgdGhlIHByb3Zp
ZGVkIGZ1bmN0aW9uYWxpdHk/IA0KICAgbyBFeHRlbmRpYmlsaXR5OiBUbyB3aGF0IGV4dGVudCBj
YW4gdGhlIHNvbHV0aW9uIGJlIGV4dGVuZGVkIHRvICANCiAgICAgaW50ZWdyYXRlIG5ldyBmdW5j
dGlvbmFsaXR5PyANCiAgIG8gU2NhbGFiaWxpdHk6IFdoYXQgcmVzdHJpY3Rpb25zIGR1ZSB0byBh
cmNoaXRlY3R1cmU/IA0KICAgIA0KNy4xLiAgIEguMzJ4IFByb3RvY29sIFN1aXRlIA0KICAgIA0K
ICAgbyBGdW5jdGlvbmFsaXR5OiAgDQogICAgIC0gY2VudHJhbGl6ZWQvZGVjZW50cmFsaXplZCBj
b25mZXJlbmNpbmcgDQogICAgIC0gcHJldHR5IG11Y2ggYWltaW5nIGF0IGZsb29yIGNvbnRyb2xs
ZWQgY29uZmVyZW5jaW5nLCBhbHRob3VnaCAgDQogICAgICAgb25seSBjb25kdWN0ZWQvbm9uLWNv
bmR1Y3RlZCBtb2RlcyBzdXBwb3J0ZWQgDQogICAgIC0gTm8gcGFzc2l2ZS9hY3RpdmUgbm90aW9u
IGluIHRoZSBvcmlnaW5hbCBILjMyeCwgSC4zMzIgZXh0ZW5zaW9uICANCiAgICAgICBkb2VzbpJ0
IHN1cHBvcnQgY2hhbmdlcyBvZiBsaXN0ZW5lcnMgdG8gYWN0aXZlIHVzZXJzLiANCiAgICAgIA0K
ICAgbyBGbGV4aWJpbGl0eTogIA0KICAgICAtIEZsb29yIGNvbnRyb2xsZWQgY29uZmVyZW5jaW5n
IGlzIHBvb3JseSBzdXBwb3J0ZWQsIGFsdGhvdWdoIHRoZSAgDQogICAgICAgZGF0YSBjb25mZXJl
bmNpbmcgcGFydCBzdXBwb3J0cyB0b2tlbnMuICANCiAgICAgLSBQcmUtZGVmaW5lZCByb2xlIG1v
ZGVscywgaS5lLiwgY29uZHVjdGVkIHZlcnN1cyBub24tY29uZHVjdGVkLCAgDQogICAgICAgZm9y
IGF1ZGlvdmlzdWFsIHBhcnQuICANCiAgICAgLSBObyBwb2xpY3kgZGVmaW5pdGlvbiwgZS5nLiwg
dXNpbmcgYXBwcm9wcmlhdGUgcHJvZmlsZSAgDQogICAgICAgaW5mb3JtYXRpb24uIA0KICAgICAt
IHJlY29uZmlndXJhdGlvbiBvZiBydW5uaW5nIGNvbmZlcmVuY2VzIHBvb3JseSBzdXBwb3J0ZWQu
IA0KICAgIA0KICAgbyBFeHRlbmRpYmlsaXR5OiANCiAgICAgLSBwcmV0dHkgY2xvc2VkIHN5c3Rl
bSBvZiBhIHdob2xlIHNldCBvZiBzdGFuZGFyZHMgDQogICAgDQogICBvIFNjYWxhYmlsaXR5OiB2
ZXJ5IHJlc3RyaWN0ZWQgZHVlIHRvIHRpZ2h0IGNlbnRyYWxpemVkIGNvbnRyb2wgIA0KICAgICBz
dHJ1Y3R1cmUgDQogICAgDQogICBbVEJEXSBhZGQgb3RoZXIgcG9pbnRzLCBlaXRoZXIgaXRlbXMg
b3Igc3ViaXRlbXMgDQogICAgDQo3LjIuICAgU0lQLWJhc2VkIFNvbHV0aW9ucyANCiAgICANCiAg
IG8gRnVuY3Rpb25hbGl0eTogIA0KICAgICAtIGZsZXhpYmxlIGluaXRpYXRpb24gbW9kZWxzIFsx
MV0gIA0KICAgICAtIG1lbWJlcnNoaXAgaW5mb3JtYXRpb24gdXNpbmcgUlRDUCBpbmZvcm1hdGlv
biAobG9vc2UgY29udHJvbCkgb3IgICAgICANCiAgICAgICBhLXByaW9yaSBpbmZvcm1hdGlvbiAN
CiAgICAgLSBubyBtZW1iZXJzaGlwIGVuZm9yY2VtZW50IA0KICAgICAtIG5vIGZsb29yIGNvbnRy
b2wgDQogICAgIC0gbm8gY2FwYWJpbGl0eSByZS1uZWdvdGlhdGlvbiANCiAgICANCiAgIG8gRmxl
eGliaWxpdHkvRXh0ZW5kaWJpbGl0eTogDQogICAgIA0KVHJvc3NlbiAgICAgICAgICAgICAgICAg
RXhwaXJlcyBOb3ZlbWJlciAyMDAxICAgICAgICAgICAgICAgICAgICBbMTBdIA0MDQpJbnRlcm5l
dCBEcmFmdCAgICAgQ291cnNlIENvbnRyb2wgUHJvYmxlbSBTdGF0ZW1lbnQgICAgICAgICAgIE1h
eSAyMDAxIA0KICAgIA0KICAgIA0KICAgICAtIGV4dGVuc2lvbiBwb3NzaWJsZSBieSBhZGRpbmcg
Y29uZmVyZW5jZSBjb3Vyc2UgY29udHJvbCAgDQogICAgICAgZnVuY3Rpb25hbGl0eSBhcyBzZXBh
cmF0ZWQgY29tcG9uZW50IGR1ZSB0byBvcGVuIHN5c3RlbSAgDQogICAgICAgY2hhcmFjdGVyIA0K
ICAgICAtIG90aGVyIHNjZW5hcmlvcyBwb3NzaWJsZSBieSBhZGRpbmcgZnVuY3Rpb25hbGl0eSAN
CiAgICANCiAgIG8gU2NhbGFiaWxpdHk6IGRlcGVuZHMgb24gdGhlIGluaXRpYXRpb24gbW9kZWws
IGJ1dCBtb3N0IGxpa2VseSAgDQogICAgIHNpbWlsYXIgdG8gdGhlIHNpbXBsZSBjb25mZXJlbmNp
bmcgY2F0ZWdvcnkgKHNlZSBTZWN0aW9uIDUuMSkgDQogICAgDQogICBbVEJEXSBhZGQgb3RoZXIg
cG9pbnRzLCBlaXRoZXIgaXRlbXMgb3Igc3ViaXRlbXMgDQogICAgDQogICAgDQo4LiAgICAgTmV4
dCBTdGVwcyANCiAgICANCiAgIFRoZSBmb2xsb3dpbmcgaXRlbXMgYXJlIHByb3Bvc2VkIGFzIG5l
eHQgc3RlcHM6IA0KICAgIA0KICAgbyBEZWZpbml0aW9uIG9mIHJlcXVpcmVtZW50cyANCiAgIG8g
UHJvcG9zYWwgZm9yIHByb3ZpZGVkIHNlcnZpY2VzIA0KICAgbyBQcm9wb3NhbCBvZiBwcm90b2Nv
bCBzb2x1dGlvbnMgDQogICBvIEFuYWx5c2lzIG9mIHByb3RvY29sIHNvbHV0aW9ucyANCiAgIG8g
UmVjb21tZW5kYXRpb24gb2YgY29uZmVyZW5jZSBjb3Vyc2UgY29udHJvbCBzZXJ2aWNlIGFuZCBw
cm90b2NvbCANCiAgICANCiAgIEEgY3J1Y2lhbCBwYXJ0IG9mIHRoZSBhbmFseXNpcyB3b3JrIGlz
IHRvIHN0dWR5IGV4aXN0aW5nIHNvbHV0aW9ucyANCiAgIHdpdGggcmVzcGVjdCB0byB0aGVpciBh
cHBsaWNhYmlsaXR5IGFuZCB0aGVpciBhbGlnbm1lbnQgd2l0aCB0aGUgDQogICBkZWZpbmVkIHNj
b3BlIG9mIFNlY3Rpb24gMiBhbmQgdGhlIHByb2JsZW0gc3RhdGVtZW50IGluIFNlY3Rpb24gMy4g
DQogICAgDQogICAgDQo5LiAgICAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgDQogDQogICBUaGlz
IGRvY3VtZW50IG1lcmVseSBkaXNjdXNzZXMgcHJvYmxlbSBzdGF0ZW1lbnRzIG1vdGl2YXRpbmcg
dGhlIA0KICAgbmVlZCBmb3IgY29uZmVyZW5jZSBjb3Vyc2UgY29udHJvbCBtZWNoYW5pc21zLiBT
ZWN1cml0eSBpcyBhbiBpc3N1ZSANCiAgIGZvciBjb25mZXJlbmNlIGNvdXJzZSBjb250cm9sIGJ1
dCBpcyBjb25zaWRlcmVkIGluIHN1YnNlcXVlbnQgDQogICBzb2x1dGlvbi1zcGFjZSBkb2N1bWVu
dHMuIA0KICAgIA0KICAgIA0KMTAuICAgIEFja25vd2xlZGdlbWVudHMgDQogICAgDQogICBJIHdv
dWxkIGxpa2UgdG8gYWNrbm93bGVkZ2UgdGhlIHBhcnRpY2lwYW50cyBvZiB0aGUgbWFpbGluZyBs
aXN0IA0KICAgdGhhdCB3YXMgc2V0IHVwIHRvIGRpc2N1c3MgdGhlIHRoaXMgZG9jdW1lbnQuIFRo
ZWlyIGNvbnRyaWJ1dGlvbnMgDQogICBhbmQgYWN0aXZlIHBhcnRpY2lwYXRpb24gaW4gdGhlIGRp
c2N1c3Npb24gb24gdGhlIG1haWxpbmcgbGlzdCB3ZXJlIA0KICAgdmVyeSB1c2VmdWwgaW4gdGhl
IHByZXBhcmF0aW9uIG9mIHRoaXMgZG9jdW1lbnQuIA0KICAgIA0KICAgIA0KMTEuICAgIFJlZmVy
ZW5jZXMgDQogICAgDQogICBbMV0gIEMuIEJvcm1hbm4sIEouIE90dCwgRC4gS3V0c2NoZXIsIEQu
IFRyb3NzZW4sICJTaW1wbGUgQ29uZmVyZW5jZSANCiAgICAgICAgQ29udHJvbCBQcm90b2NvbCCW
IFNlcnZpY2UgU3BlY2lmaWNhdGlvbiIsIGRyYWZ0LWlldGYtbW11c2ljLQ0KICAgICAgICBzY2Nw
LTAxLnR4dCwgV29yayBpbiBQcm9ncmVzcywgRmVicnVhcnkgMjAwMSANCiAgICANCiAgIFsyXSAg
SC4gRXJpa3Nzb24sICJNQk9ORTogVGhlIE11bHRpY2FzdCBCYWNrYm9uZSIsIENvbW11bmljYXRp
b25zIG9mIA0KICAgICAgICB0aGUgQUNNLCBWb2wuMzcgTm8uOCwgcHAuNTQtNjAsIEF1Z3VzdCAx
OTk0IA0KIA0KICAgICANClRyb3NzZW4gICAgICAgICAgICAgICAgIEV4cGlyZXMgTm92ZW1iZXIg
MjAwMSAgICAgICAgICAgICAgICAgICAgWzExXSANDA0KSW50ZXJuZXQgRHJhZnQgICAgIENvdXJz
ZSBDb250cm9sIFByb2JsZW0gU3RhdGVtZW50ICAgICAgICAgICBNYXkgMjAwMSANCiAgICANCiAg
ICANCiAgIFszXSAgTS4gSGFuZGxleSwgSi4gQ3Jvd2Nyb2Z0LCBDLiBCb3JtYW5uLCAiVGhlIElu
dGVybmV0IE11bHRpbWVkaWEgDQogICAgICAgIENvbmZlcmVuY2luZyBBcmNoaXRlY3R1cmUiLCBk
cmFmdC1pZXRmLW1tdXNpYy1jb25mYXJjaC0wMy50eHQsIA0KICAgICAgICBXb3JrIEluIFByb2dy
ZXNzLCBKdWx5IDIwMDAgIA0KICAgIA0KICAgWzRdICBNLiBIYW5kbGV5LCBWLiBKYWNvYnNvbiwg
IlNEUDogU2Vzc2lvbiBEZXNjcmlwdGlvbiBQcm90b2NvbCIsIA0KICAgICAgICBSRkMgMjMyNywg
QXByaWwgMTk5OCANCiAgICANCiAgIFs1XSAgTS4gSGFuZGxleSwgSC4gU2NodWx6cmlubmUsIEUu
IFNjaG9vbGVyLCBKLiBSb3NlbmJlcmcsICJTSVA6IA0KICAgICAgICBTZXNzaW9uIEluaXRpYXRp
b24gUHJvdG9jb2wiLCBSRkMgMjU0MywgTWFyY2ggMTk5OSANCiAgICANCiAgIFs2XSAgTS4gSGFu
ZGxleSwgQy4gUGVya2lucywgRS4gV2hlbGFuLCAiU2Vzc2lvbiBhbm5vdW5jZW1lbnQgDQogICAg
ICAgIHByb3RvY29sIiwgUkZDIDI5NzQsIE9jdG9iZXIgMjAwMCANCiAgICANCiAgIFs3XSAgSVRV
LVQsICJWaXN1YWwgVGVsZXBob25lIFN5c3RlbXMgYW5kIEVxdWlwbWVudCBmb3IgTG9jYWwgQXJl
YSANCiAgICAgICAgTmV0d29ya3Mgd2l0aCBOb24tR3VhcmFudGVlZCBRdWFsaXR5IG9mIFNlcnZp
Y2UiLCBJVFUtVCANCiAgICAgICAgUmVjb21tZW5kYXRpb24gSC4zMjMsIDIwMDAgDQogICAgDQog
ICBbOF0gIElUVS1ULCAiSC4zMjMgZXh0ZW5kZWQgZm9yIGxvb3NlbHkgY291cGxlZCBjb25mZXJl
bmNlcyIsIElUVS1UIA0KICAgICAgICBSZWNvbW1lbmRhdGlvbiBILjMzMiwgU2VwdGVtYmVyIDE5
OTggDQogICAgDQogICBbOV0gIEQuIEt1dHNjaGVyLCBKLiBPdHQsIEMuIEJvcm1hbm4sICJSZXF1
aXJlbWVudHMgZm9yIFNlc3Npb24gDQogICAgICAgIERlc2NyaXB0aW9uIGFuZCBDYXBhYmlsaXR5
IE5lZ290aWF0aW9uIiwgZHJhZnQtaWV0Zi1tbXVzaWMtDQogICAgICAgIHNkcG5nLXJlcS0wMC50
eHQsIFdvcmsgSW4gUHJvZ3Jlc3MsIEZlYnJ1YXJ5IDIwMDEgDQogDQogICBbMTBdIEouIE90dCwg
Qy4gUGVya2lucywgRC4gS3V0c2NoZXIsICJBIE1lc3NhZ2UgQnVzIGZvciBMb2NhbCANCiAgICAg
ICAgQ29vcmRpbmF0aW9uIiwgZHJhZnQtaWV0Zi1tbXVzaWMtbWJ1cy10cmFuc3BvcnQtMDQudHh0
LCBXb3JrIEluIA0KICAgICAgICBQcm9ncmVzcywgRmVicnVhcnkgMjAwMSANCiANCiAgIFsxMV0g
Si4gUm9zZW5iZXJnLCBILiBTY2h1bHpyaW5uZSwgIk1vZGVscyBmb3IgTXVsdGkgUGFydHkgDQog
ICAgICAgIENvbmZlcmVuY2luZyBpbiBTSVAiLCBkcmFmdC1yb3NlbmJlcmctc2lwLWNvbmZlcmVu
Y2luZy1tb2RlbHMtDQogICAgICAgIDAwLnR4dCwgV29yayBJbiBQcm9ncmVzcywgTm92ZW1iZXIg
MjAwMCANCiANCiAgIFsxMl0gSC4gU2NodWx6cmlubmUsIFMuIENhc25lciwgUi4gRnJlZGVyaWNr
LCBWLiBKYWNvYnNvbiwgIlJUUDogQSANCiAgICAgICAgVHJhbnNwb3J0IFByb3RvY29sIGZvciBS
ZWFsLVRpbWUgQXBwbGljYXRpb25zIiwgUkZDIDE4ODksIA0KICAgICAgICBKYW51YXJ5IDE5OTYg
DQogDQogICBbMTNdIEQuIFRyb3NzZW4sICJTY2FsYWJsZSBGbG9vciBDb250cm9sIGluIENvbmZl
cmVuY2luZyANCiAgICAgICAgRW52aXJvbm1lbnRzOiBUaGUgUkJvbmUgQXBwcm9hY2giLCAybmQg
SVAgVGVsZXBob255IFdvcmtzaG9wLCANCiAgICAgICAgTmV3IFlvcmssIEFwcmlsIDIwMDEgDQog
ICAgDQogICAgDQogICAgDQpBdXRob3IncyBBZGRyZXNzIA0KICAgIA0KICAgRGlyayBUcm9zc2Vu
IA0KICAgTm9raWEgUmVzZWFyY2ggDQogICA1IFdheXNpZGUgUm9hZCANCiAgIEJ1cmxpbmd0b24s
IE1BIDAyNDc0IFVTQSAgICAgIA0KICAgUGhvbmU6ICAxLTc4MS05OTMtMzYwNSANCiAgIEVtYWls
OiAgZGlyay50cm9zc2VuQG5va2lhLmNvbSANCiAgICANCiAgICANCkZ1bGwgQ29weXJpZ2h0IFN0
YXRlbWVudCANCiAgICAgDQpUcm9zc2VuICAgICAgICAgICAgICAgICBFeHBpcmVzIE5vdmVtYmVy
IDIwMDEgICAgICAgICAgICAgICAgICAgIFsxMl0gDQwNCkludGVybmV0IERyYWZ0ICAgICBDb3Vy
c2UgQ29udHJvbCBQcm9ibGVtIFN0YXRlbWVudCAgICAgICAgICAgTWF5IDIwMDEgDQogICAgDQog
ICAgDQogICAgDQogICBDb3B5cmlnaHQgKEMpIFRoZSBJbnRlcm5ldCBTb2NpZXR5ICgyMDAxKS4g
QWxsIFJpZ2h0cyBSZXNlcnZlZC4gDQogICAgDQogICBUaGlzIGRvY3VtZW50IGFuZCB0cmFuc2xh
dGlvbnMgb2YgaXQgbWF5IGJlIGNvcGllZCBhbmQgZnVybmlzaGVkIHRvIA0KICAgb3RoZXJzLCBh
bmQgZGVyaXZhdGl2ZSB3b3JrcyB0aGF0IGNvbW1lbnQgb24gb3Igb3RoZXJ3aXNlIGV4cGxhaW4g
aXQgDQogICBvciBhc3Npc3QgaW4gaXRzIGltcGxlbWVudGF0aW9uIG1heSBiZSBwcmVwYXJlZCwg
Y29waWVkLCBwdWJsaXNoZWQgDQogICBhbmQgZGlzdHJpYnV0ZWQsIGluIHdob2xlIG9yIGluIHBh
cnQsIHdpdGhvdXQgcmVzdHJpY3Rpb24gb2YgYW55IA0KICAga2luZCwgcHJvdmlkZWQgdGhhdCB0
aGUgYWJvdmUgY29weXJpZ2h0IG5vdGljZSBhbmQgdGhpcyBwYXJhZ3JhcGggDQogICBhcmUgaW5j
bHVkZWQgb24gYWxsIHN1Y2ggY29waWVzIGFuZCBkZXJpdmF0aXZlIHdvcmtzLiBIb3dldmVyLCB0
aGlzIA0KICAgZG9jdW1lbnQgaXRzZWxmIG1heSBub3QgYmUgbW9kaWZpZWQgaW4gYW55IHdheSwg
c3VjaCBhcyBieSByZW1vdmluZyANCiAgIHRoZSBjb3B5cmlnaHQgbm90aWNlIG9yIHJlZmVyZW5j
ZXMgdG8gdGhlIEludGVybmV0IFNvY2lldHkgb3Igb3RoZXIgDQogICBJbnRlcm5ldCBvcmdhbml6
YXRpb25zLCBleGNlcHQgYXMgbmVlZGVkIGZvciB0aGUgcHVycG9zZSBvZiANCiAgIGRldmVsb3Bp
bmcgSW50ZXJuZXQgc3RhbmRhcmRzIGluIHdoaWNoIGNhc2UgdGhlIHByb2NlZHVyZXMgZm9yIA0K
ICAgY29weXJpZ2h0cyBkZWZpbmVkIGluIHRoZSBJbnRlcm5ldCBTdGFuZGFyZHMgcHJvY2VzcyBt
dXN0IGJlIA0KICAgZm9sbG93ZWQsIG9yIGFzIHJlcXVpcmVkIHRvIHRyYW5zbGF0ZSBpdCBpbnRv
IGxhbmd1YWdlcyBvdGhlciB0aGFuIA0KICAgRW5nbGlzaC4gDQogICAgDQogICBUaGUgbGltaXRl
ZCBwZXJtaXNzaW9ucyBncmFudGVkIGFib3ZlIGFyZSBwZXJwZXR1YWwgYW5kIHdpbGwgbm90IGJl
IA0KICAgcmV2b2tlZCBieSB0aGUgSW50ZXJuZXQgU29jaWV0eSBvciBpdHMgc3VjY2Vzc29ycyBv
ciBhc3NpZ25zLiANCiAgICANCiAgIFRoaXMgZG9jdW1lbnQgYW5kIHRoZSBpbmZvcm1hdGlvbiBj
b250YWluZWQgaGVyZWluIGlzIHByb3ZpZGVkIG9uIGFuIA0KICAgIkFTIElTIiBiYXNpcyBhbmQg
VEhFIElOVEVSTkVUIFNPQ0lFVFkgQU5EIFRIRSBJTlRFUk5FVCBFTkdJTkVFUklORyANCiAgIFRB
U0sgRk9SQ0UgRElTQ0xBSU1TIEFMTCBXQVJSQU5USUVTLCBFWFBSRVNTIE9SIElNUExJRUQsIElO
Q0xVRElORyANCiAgIEJVVCBOT1QgTElNSVRFRCBUTyBBTlkgV0FSUkFOVFkgVEhBVCBUSEUgVVNF
IE9GIFRIRSBJTkZPUk1BVElPTiANCiAgIEhFUkVJTiBXSUxMIE5PVCBJTkZSSU5HRSBBTlkgUklH
SFRTIE9SIEFOWSBJTVBMSUVEIFdBUlJBTlRJRVMgT0YgDQogICBNRVJDSEFOVEFCSUxJVFkgT1Ig
RklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UuIA0KICAgIA0KQWNrbm93bGVkZ2VtZW50
IA0KICAgIA0KICAgRnVuZGluZyBmb3IgdGhlIFJGQyBlZGl0b3IgZnVuY3Rpb24gaXMgY3VycmVu
dGx5IHByb3ZpZGVkIGJ5IHRoZSANCiAgIEludGVybmV0IFNvY2lldHkuIA0KICAgICANClRyb3Nz
ZW4gICAgICAgICAgICAgICAgIEV4cGlyZXMgTm92ZW1iZXIgMjAwMSAgICAgICAgICAgICAgICAg
ICAgWzEzXSANDA==
------_=_NextPart_001_01C12B19.F8CF8190--
>From owner-rmt@listserv.lbl.gov Wed Aug 22 10:02:24 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f7MGt3112006;
Wed, 22 Aug 2001 09:55:03 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f7MGt2V12002
for <rmt@listserv.lbl.gov>; Wed, 22 Aug 2001 09:55:02 -0700 (PDT)
Received: from localhost (root@localhost)
by postal1.lbl.gov (8.11.2/8.11.2) with SMTP id f7MGt2e05141
for <rmt@listserv.lbl.gov>; Wed, 22 Aug 2001 09:55:02 -0700 (PDT)
Date: Wed, 22 Aug 2001 09:55:02 -0700 (PDT)
Message-Id: <200108221655.f7MGt2e05141@postal1.lbl.gov>
From: VirusWall@lbl.gov
To: rmt@listserv.lbl.gov
Subject: Virus Alert
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-rmt@lbl.gov
Precedence: bulk
This is an automated message from the LBNL VirusWall.
The mail message you recently received from: autow@wshlab2.ee.kuas.edu.tw
which included the file: javacomm20-win32.zip.pif
contained the virus: TROJ_SIRCAM.A.
PLEASE NOTE:
1. The virus has been REMOVED from the email message by the LBNL VirusWall
and will NOT INFECT your computer.
2. It is SAFE to read the message and open the attachment, though you should
always use caution when opening attachments from people you do not know.
3. You do not need to notify anyone that you received this message.
For more information take a look at our virus protection web page:
http://www.lbl.gov/ITSD/Security/resources/
If you have any questions, please contact the LBNL Help Desk
at http://www.lbl.gov/help/, or 510-486-4357.
Thanks,
The VirusWall
Lawrence Berkeley National Laboratory
>From owner-rmt@listserv.lbl.gov Wed Aug 22 10:02:24 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f7MGt1V12000;
Wed, 22 Aug 2001 09:55:01 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f7MGsxV11996
for <rmt@listserv.lbl.gov>; Wed, 22 Aug 2001 09:54:59 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f7MGswH05107
for <rmt@listserv.lbl.gov>; Wed, 22 Aug 2001 09:54:58 -0700 (PDT)
Received: from wshlab2.ee.kuas.edu.tw ([140.127.114.233])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f7MGsf505028
for <rmt@lbl.gov>; Wed, 22 Aug 2001 09:54:44 -0700 (PDT)
Received: from wshstd.ee.kuas.edu.tw (unknown [140.127.114.234])
by wshlab2.ee.kuas.edu.tw (Postfix) with SMTP id B24332364F
for <rmt@lbl.gov>; Thu, 23 Aug 2001 00:57:13 +0800 (CST)
From: "=?ISO-8859-1?Q?=C4=A3=B0=F3?=" <autow@wshlab2.ee.kuas.edu.tw>
To: rmt@lbl.gov
Subject: javacomm20-win32
date: Thu, 23 Aug 2001 01:14:25 +0800
MIME-Version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
Content-Type: multipart/mixed; boundary="----33CA0627_Outlook_Express_message_boundary"
Content-Disposition: Multipart message
Message-Id: <20010822165713.B24332364F@wshlab2.ee.kuas.edu.tw>
Sender: owner-rmt@lbl.gov
Precedence: bulk
------33CA0627_Outlook_Express_message_boundary
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
****************** Virus Warning Message (on the network)
Found virus TROJ_SIRCAM.A in file javacomm20-win32.zip.pif
The file e/iscan/virus/virVJCi_aq1e is moved to the configured virus directory.
*********************************************************
------33CA0627_Outlook_Express_message_boundary
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: message text
Hi! How are you=3F
I send you this file in order to have your advice
See you later=2E Thanks
------33CA0627_Outlook_Express_message_boundary
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
****************** Virus Warning Message (on the network)
javacomm20-win32.zip.pif is removed from here because it contains a virus.
*********************************************************
------33CA0627_Outlook_Express_message_boundary
------33CA0627_Outlook_Express_message_boundary--
>From owner-rmt@listserv.lbl.gov Wed Aug 22 13:02:10 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f7MJqZu20245;
Wed, 22 Aug 2001 12:52:35 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f7MJqYV20241
for <rmt@listserv.lbl.gov>; Wed, 22 Aug 2001 12:52:34 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f7MJqWO17111
for <rmt@listserv.lbl.gov>; Wed, 22 Aug 2001 12:52:32 -0700 (PDT)
Received: from wshlab2.ee.kuas.edu.tw ([140.127.114.233])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f7MJpu516912
for <rmt@lbl.gov>; Wed, 22 Aug 2001 12:51:56 -0700 (PDT)
Received: from wshstd.ee.kuas.edu.tw (unknown [140.127.114.234])
by wshlab2.ee.kuas.edu.tw (Postfix) with SMTP id 03AD22365F
for <rmt@lbl.gov>; Thu, 23 Aug 2001 03:54:28 +0800 (CST)
From: "=?ISO-8859-1?Q?=C4=A3=B0=F3?=" <autow@wshlab2.ee.kuas.edu.tw>
To: rmt@lbl.gov
Subject: javacomm20-win32
date: Thu, 23 Aug 2001 04:11:39 +0800
MIME-Version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
Content-Type: multipart/mixed; boundary="----1D90F1B7_Outlook_Express_message_boundary"
Content-Disposition: Multipart message
Message-Id: <20010822195428.03AD22365F@wshlab2.ee.kuas.edu.tw>
Sender: owner-rmt@lbl.gov
Precedence: bulk
------1D90F1B7_Outlook_Express_message_boundary
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
****************** Virus Warning Message (on the network)
Found virus TROJ_SIRCAM.A in file javacomm20-win32.zip.lnk
The file e/iscan/virus/virUBCvIay.y is moved to the configured virus directory.
*********************************************************
------1D90F1B7_Outlook_Express_message_boundary
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: message text
Hi! How are you=3F
I send you this file in order to have your advice
See you later=2E Thanks
------1D90F1B7_Outlook_Express_message_boundary
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
****************** Virus Warning Message (on the network)
javacomm20-win32.zip.lnk is removed from here because it contains a virus.
*********************************************************
------1D90F1B7_Outlook_Express_message_boundary
------1D90F1B7_Outlook_Express_message_boundary--
>From owner-rmt@listserv.lbl.gov Wed Aug 22 13:02:11 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f7MJqcA20251;
Wed, 22 Aug 2001 12:52:38 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f7MJqbV20247
for <rmt@listserv.lbl.gov>; Wed, 22 Aug 2001 12:52:37 -0700 (PDT)
Received: from localhost (root@localhost)
by postal1.lbl.gov (8.11.2/8.11.2) with SMTP id f7MJqaX17147
for <rmt@listserv.lbl.gov>; Wed, 22 Aug 2001 12:52:36 -0700 (PDT)
Date: Wed, 22 Aug 2001 12:52:36 -0700 (PDT)
Message-Id: <200108221952.f7MJqaX17147@postal1.lbl.gov>
From: VirusWall@lbl.gov
To: rmt@listserv.lbl.gov
Subject: Virus Alert
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-rmt@lbl.gov
Precedence: bulk
This is an automated message from the LBNL VirusWall.
The mail message you recently received from: autow@wshlab2.ee.kuas.edu.tw
which included the file: javacomm20-win32.zip.lnk
contained the virus: TROJ_SIRCAM.A.
PLEASE NOTE:
1. The virus has been REMOVED from the email message by the LBNL VirusWall
and will NOT INFECT your computer.
2. It is SAFE to read the message and open the attachment, though you should
always use caution when opening attachments from people you do not know.
3. You do not need to notify anyone that you received this message.
For more information take a look at our virus protection web page:
http://www.lbl.gov/ITSD/Security/resources/
If you have any questions, please contact the LBNL Help Desk
at http://www.lbl.gov/help/, or 510-486-4357.
Thanks,
The VirusWall
Lawrence Berkeley National Laboratory
>From owner-rmt@listserv.lbl.gov Wed Aug 22 17:29:27 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f7N0LZA02899;
Wed, 22 Aug 2001 17:21:35 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f7N0LXV02895
for <rmt@listserv.lbl.gov>; Wed, 22 Aug 2001 17:21:33 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f7N0LWJ25128
for <rmt@listserv.lbl.gov>; Wed, 22 Aug 2001 17:21:32 -0700 (PDT)
Received: from wshlab2.ee.kuas.edu.tw ([140.127.114.233])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f7N0Gl524247
for <rmt@lbl.gov>; Wed, 22 Aug 2001 17:16:47 -0700 (PDT)
Received: from wshstd.ee.kuas.edu.tw (unknown [140.127.114.234])
by wshlab2.ee.kuas.edu.tw (Postfix) with SMTP id 8DEFD2368B
for <rmt@lbl.gov>; Thu, 23 Aug 2001 06:51:44 +0800 (CST)
From: "=?ISO-8859-1?Q?=C4=A3=B0=F3?=" <autow@wshlab2.ee.kuas.edu.tw>
To: rmt@lbl.gov
Subject: javacomm20-win32
date: Thu, 23 Aug 2001 07:08:56 +0800
MIME-Version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
Content-Type: multipart/mixed; boundary="----45C37FD5_Outlook_Express_message_boundary"
Content-Disposition: Multipart message
Message-Id: <20010822225144.8DEFD2368B@wshlab2.ee.kuas.edu.tw>
Sender: owner-rmt@lbl.gov
Precedence: bulk
------45C37FD5_Outlook_Express_message_boundary
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
****************** Virus Warning Message (on the network)
Found virus TROJ_SIRCAM.A in file javacomm20-win32.zip.bat
The file e/iscan/virus/virGJA4cbaNV is moved to the configured virus directory.
*********************************************************
------45C37FD5_Outlook_Express_message_boundary
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: message text
Hi! How are you=3F
I send you this file in order to have your advice
See you later=2E Thanks
------45C37FD5_Outlook_Express_message_boundary
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
****************** Virus Warning Message (on the network)
javacomm20-win32.zip.bat is removed from here because it contains a virus.
*********************************************************
------45C37FD5_Outlook_Express_message_boundary
------45C37FD5_Outlook_Express_message_boundary--
>From owner-rmt@listserv.lbl.gov Wed Aug 22 17:29:27 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f7N0Ljj02905;
Wed, 22 Aug 2001 17:21:45 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f7N0LhV02901
for <rmt@listserv.lbl.gov>; Wed, 22 Aug 2001 17:21:44 -0700 (PDT)
Received: from localhost (root@localhost)
by postal1.lbl.gov (8.11.2/8.11.2) with SMTP id f7N0Lhv25190
for <rmt@listserv.lbl.gov>; Wed, 22 Aug 2001 17:21:43 -0700 (PDT)
Date: Wed, 22 Aug 2001 17:21:43 -0700 (PDT)
Message-Id: <200108230021.f7N0Lhv25190@postal1.lbl.gov>
From: VirusWall@lbl.gov
To: rmt@listserv.lbl.gov
Subject: Virus Alert
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-rmt@lbl.gov
Precedence: bulk
This is an automated message from the LBNL VirusWall.
The mail message you recently received from: autow@wshlab2.ee.kuas.edu.tw
which included the file: javacomm20-win32.zip.bat
contained the virus: TROJ_SIRCAM.A.
PLEASE NOTE:
1. The virus has been REMOVED from the email message by the LBNL VirusWall
and will NOT INFECT your computer.
2. It is SAFE to read the message and open the attachment, though you should
always use caution when opening attachments from people you do not know.
3. You do not need to notify anyone that you received this message.
For more information take a look at our virus protection web page:
http://www.lbl.gov/ITSD/Security/resources/
If you have any questions, please contact the LBNL Help Desk
at http://www.lbl.gov/help/, or 510-486-4357.
Thanks,
The VirusWall
Lawrence Berkeley National Laboratory
>From owner-rmt@listserv.lbl.gov Wed Aug 22 18:49:29 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f7N1lgk05476;
Wed, 22 Aug 2001 18:47:42 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f7N1leV05472
for <rmt@listserv.lbl.gov>; Wed, 22 Aug 2001 18:47:41 -0700 (PDT)
Received: from localhost (root@localhost)
by postal1.lbl.gov (8.11.2/8.11.2) with SMTP id f7N1leU09630
for <rmt@listserv.lbl.gov>; Wed, 22 Aug 2001 18:47:40 -0700 (PDT)
Date: Wed, 22 Aug 2001 18:47:40 -0700 (PDT)
Message-Id: <200108230147.f7N1leU09630@postal1.lbl.gov>
From: VirusWall@lbl.gov
To: rmt@listserv.lbl.gov
Subject: Virus Alert
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-rmt@lbl.gov
Precedence: bulk
This is an automated message from the LBNL VirusWall.
The mail message you recently received from: autow@wshlab2.ee.kuas.edu.tw
which included the file: javacomm20-win32.zip.bat
contained the virus: TROJ_SIRCAM.A.
PLEASE NOTE:
1. The virus has been REMOVED from the email message by the LBNL VirusWall
and will NOT INFECT your computer.
2. It is SAFE to read the message and open the attachment, though you should
always use caution when opening attachments from people you do not know.
3. You do not need to notify anyone that you received this message.
For more information take a look at our virus protection web page:
http://www.lbl.gov/ITSD/Security/resources/
If you have any questions, please contact the LBNL Help Desk
at http://www.lbl.gov/help/, or 510-486-4357.
Thanks,
The VirusWall
Lawrence Berkeley National Laboratory
>From owner-rmt@listserv.lbl.gov Wed Aug 22 18:49:29 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f7N1lWM05470;
Wed, 22 Aug 2001 18:47:32 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f7N1lUV05466
for <rmt@listserv.lbl.gov>; Wed, 22 Aug 2001 18:47:30 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f7N1lTS09601
for <rmt@listserv.lbl.gov>; Wed, 22 Aug 2001 18:47:29 -0700 (PDT)
Received: from wshlab2.ee.kuas.edu.tw ([140.127.114.233])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f7N1kc509500
for <rmt@lbl.gov>; Wed, 22 Aug 2001 18:46:46 -0700 (PDT)
Received: from wshstd.ee.kuas.edu.tw (unknown [140.127.114.234])
by wshlab2.ee.kuas.edu.tw (Postfix) with SMTP id 152F523678
for <rmt@lbl.gov>; Thu, 23 Aug 2001 09:49:07 +0800 (CST)
From: "=?ISO-8859-1?Q?=C4=A3=B0=F3?=" <autow@wshlab2.ee.kuas.edu.tw>
To: rmt@lbl.gov
Subject: javacomm20-win32
date: Thu, 23 Aug 2001 10:06:19 +0800
MIME-Version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
Content-Type: multipart/mixed; boundary="----17FF35DE_Outlook_Express_message_boundary"
Content-Disposition: Multipart message
Message-Id: <20010823014907.152F523678@wshlab2.ee.kuas.edu.tw>
Sender: owner-rmt@lbl.gov
Precedence: bulk
------17FF35DE_Outlook_Express_message_boundary
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
****************** Virus Warning Message (on the network)
Found virus TROJ_SIRCAM.A in file javacomm20-win32.zip.bat
The file e/iscan/virus/virKOA4Pa4Nr is moved to the configured virus directory.
*********************************************************
------17FF35DE_Outlook_Express_message_boundary
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: message text
Hi! How are you=3F
I send you this file in order to have your advice
See you later=2E Thanks
------17FF35DE_Outlook_Express_message_boundary
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
****************** Virus Warning Message (on the network)
javacomm20-win32.zip.bat is removed from here because it contains a virus.
*********************************************************
------17FF35DE_Outlook_Express_message_boundary
------17FF35DE_Outlook_Express_message_boundary--
>From owner-rmt@listserv.lbl.gov Thu Aug 23 12:03:11 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f7NJ0dc29065;
Thu, 23 Aug 2001 12:00:39 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f7NJ0cV29036
for <rmt@listserv.lbl.gov>; Thu, 23 Aug 2001 12:00:38 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f7NJ0bW12624
for <rmt@listserv.lbl.gov>; Thu, 23 Aug 2001 12:00:37 -0700 (PDT)
Received: from permissiononly.com (permissiononly.com [216.133.253.90])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f7NJ0a512620
for <rmt@lbl.gov>; Thu, 23 Aug 2001 12:00:36 -0700 (PDT)
Received: (from mailman@localhost)
by permissiononly.com (8.9.3/8.9.3) id LAA16240;
Thu, 23 Aug 2001 11:21:10 -0700
Date: Thu, 23 Aug 2001 11:21:10 -0700
Message-Id: <200108231821.LAA16240@permissiononly.com>
Content-type: text/html
From: cbryce@vitalstream.cc
To: rmt@lbl.gov
Subject: Add Streaming Media to your Web Site
Sender: owner-rmt@lbl.gov
Precedence: bulk
<!--
Your E-mail Client Does Not Support HTML.
Visit http://www.vitalstream.com/ads/wme/signin.html for your FREE Streaming Kit.
-->
<HTML>
<HEAD>
<TITLE>VitalStream</TITLE>
</HEAD>
<BODY BGCOLOR=#0038A8 background="http://www.vitalstream.com/ads/wme/images/background.gif" link="#0038A8" vlink="#339900" alink="#00A3DD">
<TABLE BORDER=0 CELLPADDING=0 CELLSPACING=0 width="680" align="center">
<TR>
<TD width="5" height="5"><IMG SRC="http://www.vitalstream.com/ads/wme/images/corner-tl.gif" WIDTH=5 HEIGHT=5></TD>
<TD bgcolor="#FFFFFF" height="5" width="670"><img src="http://www.vitalstream.com/ads/wme/images/clear-pixel.gif" width="5" height="5"></TD>
<TD width="5" height="5"><IMG SRC="http://www.vitalstream.com/ads/wme/images/corner-tr.gif" WIDTH=5 HEIGHT=5></TD></TR>
<TR>
<TD bgcolor="#FFFFFF" width="5"> </TD>
<TD bgcolor="#FFFFFF" width="670">
<table width="670" border="0" cellspacing="0" cellpadding="5">
<tr>
<td rowspan="2" width="230">
<table border=0 cellpadding=0 cellspacing=0 align="center">
<tr>
<td colspan=3> <img src="http://www.vitalstream.com/ads/wme/images/wm-t.gif" width=220 height=12></td>
</tr>
<tr>
<td> <img src="http://www.vitalstream.com/ads/wme/images/wm-l.gif" width=30 height=120></td>
<td> <a href="http://www.vitalstream.com/streaming/showcase.html"><img src="http://www.vitalstream.com/ads/wme/images/screen-showcase.jpg" width=160 height=120 alt="Now Showing" border="0"></a></td>
<td> <img src="http://www.vitalstream.com/ads/wme/images/wm-r.gif" width=30 height=120></td>
</tr>
<tr>
<td colspan=3> <a href="http://www.vitalstream.com/ads/wme/signin.asp"><img src="http://www.vitalstream.com/ads/wme/images/wm-b.gif" width=220 height=92 alt="Free Streaming Kit" border="0"></a></td>
</tr>
</table>
</td>
<td colspan="2" align="center"><font face="Arial, Helvetica, sans-serif" size="4" color="#5BBF21"><b>You
Can Add Streaming Media to<br>
Your Company's Web Site</b></font></td>
</tr>
<tr>
<td valign="top" width="220">
<p><font face="Arial, Helvetica, sans-serif" color="#0038A8"><b>Streaming
Media is Easier Than You Think</b></font><br>
<img src="images/clear-pixel.gif" width="10" height="10"><br>
<font face="Arial, Helvetica, sans-serif" size="2">I invite you
to learn more about streaming media by reading our <a href="http://www.vitalstream.com/ads/wme/signin.asp">Free
Streaming Kit</a> on Live Streaming with Windows Media. It contains
a step-by-step tutorial on how to stream media over the Internet
with Windows Media technologies.</font></p>
</td>
<td valign="top" width="220">
<p><font face="Arial, Helvetica, sans-serif" size="2">VitalStream
specializes in customized streaming and hosting solutions for small
to medium sized businesses.</font><br>
<img src="images/clear-pixel.gif" width="10" height="10"><br>
<font face="Arial, Helvetica, sans-serif" color="#0038A8"><b>VitalStream
Delivers...</b></font><font face="Arial, Helvetica, sans-serif" size="2"><br>
<img src="images/clear-pixel.gif" width="5" height="5"><br>
- Live and On-Demand Streaming <br>
- Pay-Per-View Solutions <br>
- 24 x 7 Live Technical Support <br>
- 99.7% Guaranteed Uptime <br>
- And More...</font></p>
</td>
</tr>
<tr>
<td width="230" align="center" valign="top">
<p><font color="#0038A8" face="Arial, Helvetica, sans-serif" size="2">
<a href="http://www.vitalstream.com/streaming/showcase.html">These
companies</a> use us <br>
for their streaming needs. </font></p>
<p><font color="#0038A8" face="Arial, Helvetica, sans-serif" size="2">Call
today to see what <br>
VitalStream can do for <br>
your company's web site</font></p>
</td>
<td width="220" valign="middle" align="center"><img src="http://www.vitalstream.com/ads/wme/images/logo-wmsp-h.gif" width="110" height="58" alt="Windows Media Service Provider"></td>
<td width="220" valign="top">
<p><font face="Arial, Helvetica, sans-serif" size="2" color="#0038A8">
C. Bryce</font><font face="Arial, Helvetica, sans-serif" size="2"><br>
Account Representative<br>
(800) 254-7554 x2025<br>
cbryce@vitalstream.cc</font><br>
<img src="images/clear-pixel.gif" width="10" height="10"><br>
<a href="http://www.vitalstream.com"><img src="http://www.vitalstream.com/ads/wme/images/logo-vs.gif" width="166" height="37" alt="VitalStream" border="0"></a></p>
</td>
</tr>
</table>
</TD>
<TD bgcolor="#FFFFFF" width="5"> </TD>
</TR>
<TR>
<TD width="5" height="5"><IMG SRC="http://www.vitalstream.com/ads/wme/images/corner-bl.gif" WIDTH=5 HEIGHT=5></TD>
<TD bgcolor="#FFFFFF" height="5" width="670"><img src="http://www.vitalstream.com/ads/wme/images/clear-pixel.gif" width="5" height="5"></TD>
<TD width="5" height="5"><IMG SRC="http://www.vitalstream.com/ads/wme/images/corner-br.gif" WIDTH=5 HEIGHT=5></TD></TR>
</TABLE>
<div align="center">
<p><br>
<a href="http://www.vitalstream.com/vscc/vscc.asp"><font face="Arial, Helvetica, sans-serif" size="1" color="#6699FF">Click
here</font></a> <font face="Arial, Helvetica, sans-serif" size="1" color="#6699FF">if
you received this message in error.</font></p>
<p><font face="Arial, Helvetica, sans-serif" size="1" color="#FFFFFF">Microsoft,
Windows Media, and the Windows Logo are trademarks or registered <br>
trademarks of Microsoft Corporation </font><font face="Arial, Helvetica, sans-serif" size="1" color="#FFFFFF">in
the United States and/or other countries.</font></p>
</div>
</BODY>
</HTML>
>From owner-rmt@listserv.lbl.gov Tue Aug 28 14:04:54 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f7SL0wv26004;
Tue, 28 Aug 2001 14:00:58 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f7SL0uV25973
for <rmt@listserv.lbl.gov>; Tue, 28 Aug 2001 14:00:56 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f7SL0tX25816
for <rmt@listserv.lbl.gov>; Tue, 28 Aug 2001 14:00:55 -0700 (PDT)
Received: from market0 ([208.158.105.111])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f7SL0s525805
for <rmt@lbl.gov>; Tue, 28 Aug 2001 14:00:54 -0700 (PDT)
Received: from mail pickup service by market0 with Microsoft SMTPSVC;
Tue, 28 Aug 2001 13:57:35 -0700
From: <promotion@market.gogocity.com>
To: <rmt@lbl.gov>
Subject: ADV: Cell Phone Accessories Blow Out Start @ $5.95 Free Shipping
Date: Tue, 28 Aug 2001 13:57:34 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_A9C20_01C12FC9.636A5710"
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Message-ID: <MARKET0ZKeR2JZMq8FJ0002a779@market0>
X-OriginalArrivalTime: 28 Aug 2001 20:57:35.0234 (UTC) FILETIME=[102AFE20:01C13004]
Sender: owner-rmt@lbl.gov
Precedence: bulk
This is a multi-part message in MIME format.
------=_NextPart_000_A9C20_01C12FC9.636A5710
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
<http://www.gogocity.com//searchresults.asp?department=5031&parent%5Fid=
5>
<http://www.gogocity.com//searchresults.asp?department=5031&parent%5Fid=
5>
Big Saving from GoGoCity. If you'd rather not receive any future
promotional E-mails from GoGoCity.com,
please click --> Un-Subscribe My E-mai
<http://www.gogocity.com/ggc_unsubscribe.asp> l
<http://www.gogocity.com/ggc_unsubscribe.asp>
International Order Welcome FREE SHIPPING NOT APPLY
Cell Phone Accessories
Blow out Sale...!!
Save Up to 80%...!!
***** FREE SHIPPING (in US only) *****
Why pay more in Retail Store..???
1. Antenna Booster for All Cell Phone (1pack) 9. Antenna Booster for
All Cell Phone (5 pack)
Antenna Booster for All Cell Phone (1pack)
large image
<http://www.gogocity.com//product_details.asp?dept_id=5031&pf_id=OS01AB>
Retail Price: $19.95
Blow Out Price: $5.95 (save 75%)
More Details...
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1AB>
Buy it NOW !! Free Shipping
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1AB>
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1DKN56K> Antenna Booster for All Cell Phone (5 pack)
large image
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1AB5PACK>
Retail Price: $99.75
Blow Out Price: $19.95 (save 80%)
More Details...
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1AB5PACK>
Buy it NOW !! Free Shipping
<http://www.gogocity.com//product_details.asp?dept_id=5031&pf_id=OS01AB>
2. NOKIA 51xx/6xx Black Car Charger 10. Nokia 3310/3390 Data Cable
NOKIA 51xx/6xx Black Car Charger
large image
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1CGN56K>
Retail Price: $19.99
Blow Out Price: $5.49 (save 73%)
More Details...
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1CGN56K>
Buy it NOW !! Free Shipping
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1CGN56K>
Nokia 82xx/33xx Data Cable
large image
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1DKN331090K>
Retail Price: $79.99
Blow Out Price: $19.95 (save 75%)
More Details...
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1DKN331090K>
Buy it NOW !! Free Shipping
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1DKN8233K>
3. NOKIA 82xx/33xx Black Car Charger
11. Nokia 8260/8290 Li-ion 1200mAh 12 Lights Flashing & Vib
Battery
NOKIA 82xx/33xx Black Car Charger
large image
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1CGN8233K>
Retail Price: $19.99
Blow Out Price: $5.49 (save 73%)
More Details...
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1CGN8233K>
Buy it NOW !! Free Shipping
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1CGN8233K>
Nokia 82xx/33xx Li-ion 1200mAh 12 Lights Flashing & Vib Battery
large image
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1BTN8233L2FV>
Retail Price: $65.99
Blow Out Price: $24.95 (save 62%)
More Details...
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1BTN8233L2FV>
Buy it NOW !! Free Shipping
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1BTN8233L2FV>
4. NOKIA 51xx/61xx Hands Free with on/off Switch 12. NOKIA
51xx/6xx Data Cable
NOKIA 51xx/61xx Hands Free with on/off Switch
large image
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1HFN56BTK>
Retail Price: $19.99
Blow Out Price: $5.99 (save 70%)
More Details...
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1HFN56BTK>
Buy it NOW !! Free Shipping
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1HFN56BTK>
NOKIA 51xx/6xx Data Cable
large image
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1DKN56K>
Retail Price: $69.99
Blow Out Price: $14.95 (save 79%)
More Details...
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1DKN56K>
Buy it NOW !! Free Shipping
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1DKN56K>
5. NOKIA 82xx/33xx Hands Free with on/off Switch 13. Nokia
8260/8290 Li-ion 1200mAh Vibrating Battery
NOKIA 82xx/33xx Hands Free with on/off Switch
large image
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1HFN8233BTK>
Retail Price: $19.99
Blow Out Price: $5.99 (save 70%)
More Details...
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1HFN8233BTK>
Buy it NOW !! Free Shipping
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1HFN8233BTK>
Nokia 82xx/33xx Li-ion 1200mAh Vibrating Battery
large image
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1BTN8233L2V>
Retail Price: $45.99
Blow Out Price: $24.95 (save 46%)
More Details...
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1BTN8233L2V>
Buy it NOW !! Free Shipping
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1BTN8233L2V>
6. NOKIA 51xx/6xx Li-ion 3200mAh Vibrating Battery 14.Nokia
51xx/6xx Super Slim Black Li-ion 1200mAh Vib Battery
NOKIA 51xx/6xx Li-ion 3200mAh Vibrating Battery
large image
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1BTN56L2VK1>
Retail Price: $79.99
Blow Out Price: $34.95 (save 56%)
More Details...
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1BTN56L2VK1>
Buy it NOW !! Free Shipping
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1BTN56L2VK1>
Nokia 51xx/6xx Super Slim Black Li-ion 1200mAh Vib Battery
large image
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1BTN56L2VK1SLM>
Retail Price: $70.99
Blow Out Price: $29.95 (save 58%)
More Details...
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1BTN56L2VK1SLM>
Buy it NOW !! Free Shipping
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1BTN56L2VK1SLM>
7. NOKIA 51xx/6xx Black NIMH-700mAh Vibrating Battery 15. Nokia
3310/3390 Vertical Leather Magnetic Button Pouch
NOKIA 51xx/6xx Black NIMH-700mAh Vibrating Battery
large image
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1BTN56N2VK1>
Retail Price: $45.99
Blow Out Price: $14.95 (save 67%)
More Details...
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1BTN56N2VK1>
Buy it NOW !! Free Shipping
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1BTN56N2VK1>
Nokia 82xx/33xx Vertical Leather Magnetic Button Pouch
large image
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1CSN331090LK>
Retail Price: $24.99
Blow Out Price: $9.95 (save 60%)
More Details...
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1CSN331090LK>
Buy it NOW !! Free Shipping
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1CSN8233LK>
8. Nokia 8260/8290 Data Cable 16. Nokia 8260/8290 Vertical Leather
Magnetic Button Pouch
NOKIA 51xx/6xx Data Cable
large image
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1DKN8233K>
Retail Price: $79.99
Blow Out Price: $19.95 (save 75%)
More Details...
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1DKN8233K>
Buy it NOW !! Free Shipping
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1DKN8233K> Nokia 82xx/33xx Vertical Leather Magnetic Button Pouch
large image
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1CSN8233LK>
Retail Price: $24.99
Blow Out Price: $9.95 (save 60%)
More Details...
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1CSN8233LK>
Buy it NOW !! Free Shipping
<http://www.gogocity.com//product_details.asp?dept%5Fid=5031&pf%5Fid=OS0
1CSN8233LK>
------=_NextPart_000_A9C20_01C12FC9.636A5710
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<body bgcolor=3D"#ffffff" text=3D"#000000">
<div align=3D"center">=20
<p><a =
href=3D"http://www.gogocity.com//searchresults.asp?department=3D5031&=
parent%5Fid=3D5" target=3D"_blank"><img =
src=3D"http://www.gogocity.com/Assets/images/logo50.gif" =
border=3D"0"></a><a =
href=3D"http://www.gogocity.com//searchresults.asp?department=3D5031&=
parent%5Fid=3D5" target=3D"_blank"><img =
src=3D"http://www.gogocity.com/Assets/images/Home399Banner.gif" =
border=3D"0"></a><br>
<font size=3D"2" face=3D"Arial, Helvetica, sans-serif">Big Saving =
from GoGoCity.=20
If you'd rather not receive any future promotional E-mails from =
GoGoCity.com,=20
<br>
please click --> <b><a =
href=3D"http://www.gogocity.com/ggc_unsubscribe.asp">Un-Subscribe=20
My E-mai</a></b></font><font size=3D"2"><a =
href=3D"http://www.gogocity.com/ggc_unsubscribe.asp"><font =
face=3D"Arial, Helvetica, sans-serif"><b>l</b></font></a></font><br>
<font face=3D"Arial, Helvetica, sans-serif" size=3D"3"><b><font =
size=3D"2">International=20
Order Welcome</font></b></font><font size=3D"2"><b><font =
face=3D"Arial, Helvetica, sans-serif">=20
FREE SHIPPING NOT APPLY</font></b></font> </p>
<table width=3D"75%" cellpadding=3D"0" height=3D"30" cellspacing=3D"0" =
bgcolor=3D"#3366cc">
<tr>=20
<td height=3D"58" valign=3D"top">=20
<div align=3D"center"><font face=3D"Arial, Helvetica, =
sans-serif" color=3D"#ffffff"><b><font size=3D"4">Cell=20
Phone Accessories</font><br>
Blow out Sale...!!<br>
</b><i>Save Up to 80%...!! </i></font></div>
</td>
</tr>
</table>
<font size=3D"4" face=3D"Arial, Helvetica, sans-serif" =
color=3D"#ff0000">***** FREE=20
SHIPPING</font> <font face=3D"Arial, Helvetica, sans-serif" =
color=3D"#ff0000" size=3D"2">(in=20
US only)</font><font face=3D"Arial, Helvetica, sans-serif" =
color=3D"#ff0000"> *****</font><br>
<font face=3D"Arial, Helvetica, sans-serif"><i><b>Why pay more in =
Retail Store..???</b></i></font><br>
<br>
<table width=3D"75%" cellspacing=3D"3">
<tr valign=3D"top" bgcolor=3D"#99cc99">=20
<td colspan=3D"2"><font size=3D"2"><b><font face=3D"Arial, =
Helvetica, sans-serif">1.=20
Antenna Booster for All Cell Phone =
(1pack)</font></b></font></td>
<td colspan=3D"2"><font size=3D"2"><b><font face=3D"Arial, =
Helvetica, sans-serif">9.=20
Antenna Booster for All Cell Phone (5 =
pack)</font></b></font></td>
</tr>
<tr valign=3D"top">=20
<td width=3D"78" height=3D"29">=20
<div align=3D"center"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept_id=3D5031&p=
f_id=3DOS01AB"=20
><img =
src=3D"http://www.gogocity.com//Assets/product_images/OS01/AB-80.GIF" =
width=3D"70" border=3D"0" alt=3D"Antenna Booster for All Cell Phone =
(1pack)"><br>
<font face=3D"Arial, Helvetica, sans-serif" size=3D"2"> large =
image</font></a>=20
</div>
</td>
<td width=3D"305" height=3D"29" bgcolor=3D"#ffffcc"><font =
size=3D"2" face=3D"Arial, Helvetica, sans-serif">Retail=20
Price: $19.95<br>
<font color=3D"#ff0000">Blow Out Price: <STRONG>$5.95</STRONG> =
(save 75%)</font></font><br>
<font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&=
;pf%5Fid=3DOS01AB"=20
>More=20
Details...</a></font> <a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&=
;pf%5Fid=3DOS01AB"=20
><br>
<font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><b>Buy it =
NOW <i>!!</i></b></font>=20
<font size=3D"1" face=3D"Arial, Helvetica, sans-serif" =
color=3D"#ff0000">Free=20
Shipping</font> </a><br>
</td>
<td width=3D"70" height=3D"29">=20
<div align=3D"center"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&=
;pf%5Fid=3DOS01DKN56K"=20
></a><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&=
;pf%5Fid=3DOS01AB5PACK"=20
><img =
src=3D"http://www.gogocity.com//Assets/product_images/OS01/AB-80.GIF" =
width=3D"70" border=3D"0" alt=3D"Antenna Booster for All Cell Phone (5 =
pack)"><br>
<font face=3D"Arial, Helvetica, sans-serif" size=3D"2"> large =
image</font></a></div>
</td>
<td width=3D"309" height=3D"29" bgcolor=3D"#ffffcc"><font =
size=3D"2" face=3D"Arial, Helvetica, sans-serif">Retail=20
Price: $99.75<br>
<font color=3D"#ff0000">Blow Out Price: <b>$19.95</b> (save =
80%)</font></font><br>
<font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&=
;pf%5Fid=3DOS01AB5PACK"=20
>More=20
Details...</a></font> <a =
href=3D"http://www.gogocity.com//product_details.asp?dept_id=3D5031&p=
f_id=3DOS01AB"=20
><br>
<font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><b>Buy it =
NOW <i>!!</i></b></font>=20
<font size=3D"1" face=3D"Arial, Helvetica, sans-serif" =
color=3D"#ff0000">Free=20
Shipping</font></a></td>
</tr>
<tr valign=3D"top" bgcolor=3D"#99cc99">=20
<td colspan=3D"2"><font size=3D"2"><b><font face=3D"Arial, =
Helvetica, sans-serif">2.=20
</font><font size=3D"2"><b><font face=3D"Arial, Helvetica, =
sans-serif">NOKIA</font></b></font><font face=3D"Arial, Helvetica, =
sans-serif">=20
51xx/6xx Black Car Charger</font></b></font></td>
<td colspan=3D"2"><font size=3D"2"><b><font face=3D"Arial, =
Helvetica, sans-serif">10.=20
Nokia 3310/3390 Data Cable</font></b></font></td>
</tr>
<tr valign=3D"top">=20
<td width=3D"78" height=3D"70">=20
<div align=3D"center"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&=
;pf%5Fid=3DOS01CGN56K"=20
><img =
src=3D"http://www.gogocity.com//Assets/product_images/OS01/CGN56K-80.JPG"=
border=3D"0" alt=3D"NOKIA 51xx/6xx Black Car Charger" =
height=3D"70"><br>
<font face=3D"Arial, Helvetica, sans-serif" size=3D"2">large =
image</font></a></div>
</td>
<td width=3D"305" height=3D"70" bgcolor=3D"#ffffcc"><font =
size=3D"2" face=3D"Arial, Helvetica, sans-serif">Retail=20
Price: $19.99<br>
<font color=3D"#ff0000">Blow Out Price: <b>$5.49</b> (save =
73%)</font></font><br>
<font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&=
;pf%5Fid=3DOS01CGN56K"=20
>More=20
Details...</a></font> <a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&=
;pf%5Fid=3DOS01CGN56K"=20
><br>
<font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><b>Buy it =
NOW <i>!!</i></b></font>=20
<font size=3D"1" face=3D"Arial, Helvetica, sans-serif" =
color=3D"#ff0000">Free=20
Shipping</font></a><br>
</td>
<td height=3D"70" width=3D"70">=20
<div align=3D"center"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&=
;pf%5Fid=3DOS01DKN331090K"=20
><img =
src=3D"http://www.gogocity.com//Assets/product_images/OS01/DKN8233K-80.JP=
G" width=3D"70" border=3D"0" alt=3D"Nokia 82xx/33xx Data Cable"><br>
<font face=3D"Arial, Helvetica, sans-serif" size=3D"2"> large =
image</font></a></div>
</td>
<td height=3D"70" width=3D"309" bgcolor=3D"#ffffcc"><font =
size=3D"2" face=3D"Arial, Helvetica, sans-serif">Retail=20
Price: $79.99<br>
<font color=3D"#ff0000">Blow Out Price: <b>$19.95</b> (save =
75%)</font></font><br>
<font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&=
;pf%5Fid=3DOS01DKN331090K"=20
>More=20
Details...</a></font> <a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&=
;pf%5Fid=3DOS01DKN8233K"=20
><br>
<font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><b>Buy it =
NOW <i>!!</i></b></font>=20
<font size=3D"1" face=3D"Arial, Helvetica, sans-serif" =
color=3D"#ff0000">Free=20
Shipping</font></a></td>
</tr>
<tr valign=3D"top" bgcolor=3D"#99cc99">=20
<td colspan=3D"2" height=3D"2"><font size=3D"2"><b><font =
face=3D"Arial, Helvetica, sans-serif">3.=20
</font><font size=3D"2"><b><font size=3D"2"><b><font =
face=3D"Arial, Helvetica, sans-serif">NOKIA</font></b></font><font =
face=3D"Arial, Helvetica, sans-serif">=20
82xx/33xx Black Car Charger<br>
</font></b></font></b></font></td>
<td height=3D"2" colspan=3D"2"><font size=3D"2"><b><font =
face=3D"Arial, Helvetica, sans-serif">11.=20
Nokia 8260/8290 Li-ion 1200mAh </font><font size=3D"2"><b><font =
face=3D"Arial, Helvetica, sans-serif">12=20
Lights</font></b></font><font face=3D"Arial, Helvetica, =
sans-serif"> Flashing=20
& Vib Battery </font></b></font></td>
</tr>
<tr valign=3D"top">=20
<td width=3D"78" height=3D"36">=20
<div align=3D"center"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&=
;pf%5Fid=3DOS01CGN8233K"=20
><img =
src=3D"http://www.gogocity.com//Assets/product_images/OS01/CGN56K-80.JPG"=
border=3D"0" alt=3D"NOKIA 82xx/33xx Black Car Charger" =
height=3D"70"><br>
<font size=3D"2" face=3D"Arial, Helvetica, sans-serif">large =
image</font></a></div>
</td>
<td width=3D"305" height=3D"36" bgcolor=3D"#ffffcc"><font =
size=3D"2" face=3D"Arial, Helvetica, sans-serif">Retail=20
Price: $19.99<br>
<font color=3D"#ff0000">Blow Out Price: <b>$5.49</b> (save =
73%)</font></font><br>
<font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&=
;pf%5Fid=3DOS01CGN8233K"=20
>More=20
Details...</a></font> <a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&=
;pf%5Fid=3DOS01CGN8233K"=20
><br>
<font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><b>Buy it =
NOW <i>!!</i></b></font>=20
<font size=3D"1" face=3D"Arial, Helvetica, sans-serif" =
color=3D"#ff0000">Free=20
Shipping</font></a><br>
</td>
<td height=3D"36" width=3D"70">=20
<div align=3D"center"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&=
;pf%5Fid=3DOS01BTN8233L2FV"=20
><img =
src=3D"http://www.gogocity.com//Assets/emailimg/BTN8233L2FV.JPG" =
width=3D"70" border=3D"0" alt=3D"Nokia 82xx/33xx Li-ion 1200mAh 12 =
Lights Flashing & Vib Battery"><br>
<font face=3D"Arial, Helvetica, sans-serif" size=3D"2"> large =
image</font></a></div>
</td>
<td height=3D"36" width=3D"309" bgcolor=3D"#ffffcc"><font =
size=3D"2" face=3D"Arial, Helvetica, sans-serif">Retail=20
Price: $65.99<br>
<font color=3D"#ff0000">Blow Out Price: <b>$24.95</b> (save =
62%)</font></font><br>
<font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&=
;pf%5Fid=3DOS01BTN8233L2FV"=20
>More=20
Details...</a></font> <a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&=
;pf%5Fid=3DOS01BTN8233L2FV"=20
><br>
<font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><b>Buy it =
NOW <i>!!</i></b></font>=20
<font size=3D"1" face=3D"Arial, Helvetica, sans-serif" =
color=3D"#ff0000">Free=20
Shipping</font></a></td>
</tr>
<tr valign=3D"top" bgcolor=3D"#99cc99">=20
<td colspan=3D"2" height=3D"5"><font size=3D"2"><b><font =
face=3D"Arial, Helvetica, sans-serif">4.=20
</font><font size=3D"2"><b><font size=3D"2"><b><font =
face=3D"Arial, Helvetica, sans-serif">NOKIA</font></b></font><font =
face=3D"Arial, Helvetica, sans-serif">=20
51xx/61xx Hands Free with on/off =
Switch</font></b></font></b></font></td>
<td height=3D"5" colspan=3D"2"><font size=3D"2"><b><font =
face=3D"Arial, Helvetica, sans-serif">12.=20
</font><font face=3D"Arial, Helvetica, sans-serif"> </font><font =
size=3D"2"><b><font face=3D"Arial, Helvetica, =
sans-serif">NOKIA</font></b></font><font face=3D"Arial, Helvetica, =
sans-serif">=20
51xx/6xx Data Cable</font></b></font></td>
</tr>
<tr valign=3D"top">=20
<td width=3D"78" height=3D"39">=20
<div align=3D"center"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&=
;pf%5Fid=3DOS01HFN56BTK"=20
><img =
src=3D"http://www.gogocity.com//Assets/product_images/OS01/HFN56BTK-80.JP=
G" border=3D"0" alt=3D"NOKIA 51xx/61xx Hands Free with on/off Switch" =
height=3D"70"><br>
<font size=3D"2" face=3D"Arial, Helvetica, sans-serif">large =
image</font></a></div>
</td>
<td width=3D"305" height=3D"39" bgcolor=3D"#ffffcc"><font =
size=3D"2" face=3D"Arial, Helvetica, sans-serif">Retail=20
Price: $19.99<br>
<font color=3D"#ff0000">Blow Out Price: <b>$5.99</b> (save =
70%)</font></font><br>
<font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&=
;pf%5Fid=3DOS01HFN56BTK"=20
>More=20
Details...</a></font> <a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&=
;pf%5Fid=3DOS01HFN56BTK"=20
><br>
<font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><b>Buy it =
NOW <i>!!</i></b></font>=20
<font size=3D"1" face=3D"Arial, Helvetica, sans-serif" =
color=3D"#ff0000">Free=20
Shipping</font></a><br>
</td>
<td height=3D"39" width=3D"70">=20
<div align=3D"center"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&=
;pf%5Fid=3DOS01DKN56K"=20
><img =
src=3D"http://www.gogocity.com//Assets/product_images/OS01/DKN56K-80.JPG"=
width=3D"70" border=3D"0" alt=3D"NOKIA 51xx/6xx Data Cable"><br>
<font face=3D"Arial, Helvetica, sans-serif" size=3D"2"> large =
image</font></a></div>
</td>
<td height=3D"39" width=3D"309" bgcolor=3D"#ffffcc"><font =
size=3D"2" face=3D"Arial, Helvetica, sans-serif">Retail=20
Price: $69.99<br>
<font color=3D"#ff0000">Blow Out Price: <b>$14.95</b> (save =
79%)</font></font><br>
<font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&=
;pf%5Fid=3DOS01DKN56K"=20
>More=20
Details...</a></font> <a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&=
;pf%5Fid=3DOS01DKN56K"=20
><br>
<font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><b>Buy it =
NOW <i>!!</i></b></font>=20
<font size=3D"1" face=3D"Arial, Helvetica, sans-serif" =
color=3D"#ff0000">Free=20
Shipping</font></a></td>
</tr>
<tr valign=3D"top" bgcolor=3D"#99cc99">=20
<td colspan=3D"2" height=3D"10"><font size=3D"2"><b><font =
face=3D"Arial, Helvetica, sans-serif">5.=20
</font><font size=3D"2"><b><font size=3D"2"><b><font =
face=3D"Arial, Helvetica, sans-serif">NOKIA</font></b></font><font =
face=3D"Arial, Helvetica, sans-serif">=20
82xx/33xx Hands Free with on/off =
Switch</font></b></font></b></font></td>
<td height=3D"10" colspan=3D"2"><font size=3D"2"><b><font =
face=3D"Arial, Helvetica, sans-serif">13.=20
Nokia 8260/8290 Li-ion 1200mAh Vibrating =
Battery</font></b></font></td>
</tr>
<tr valign=3D"top">=20
<td width=3D"78" height=3D"36">=20
<div align=3D"center"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&=
;pf%5Fid=3DOS01HFN8233BTK"=20
><img =
src=3D"http://www.gogocity.com//Assets/product_images/OS01/HFN8233BTK-80.=
JPG" border=3D"0" alt=3D"NOKIA 82xx/33xx Hands Free with on/off Switch" =
height=3D"70"><br>
<font size=3D"2" face=3D"Arial, Helvetica, sans-serif">large =
image</font></a></div>
</td>
<td width=3D"305" height=3D"36" bgcolor=3D"#ffffcc"><font =
size=3D"2" face=3D"Arial, Helvetica, sans-serif">Retail=20
Price: $19.99<br>
<font color=3D"#ff0000">Blow Out Price: <b>$5.99</b> (save =
70%)</font></font><br>
<font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&=
;pf%5Fid=3DOS01HFN8233BTK"=20
>More=20
Details...</a></font> <a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&=
;pf%5Fid=3DOS01HFN8233BTK"=20
><br>
<font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><b>Buy it =
NOW <i>!!</i></b></font>=20
<font size=3D"1" face=3D"Arial, Helvetica, sans-serif" =
color=3D"#ff0000">Free=20
Shipping</font></a><br>
</td>
<td height=3D"36" width=3D"70">=20
<div align=3D"center"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&=
;pf%5Fid=3DOS01BTN8233L2V"=20
><img =
src=3D"http://www.gogocity.com//Assets/product_images/OS01/BTN8233L2V-80.=
JPG" width=3D"70" border=3D"0" alt=3D"Nokia 82xx/33xx Li-ion 1200mAh =
Vibrating Battery"><br>
<font face=3D"Arial, Helvetica, sans-serif" size=3D"2"> large =
image</font></a></div>
</td>
<td height=3D"36" width=3D"309" bgcolor=3D"#ffffcc"><font =
size=3D"2" face=3D"Arial, Helvetica, sans-serif">Retail=20
Price: $45.99<br>
<font color=3D"#ff0000">Blow Out Price: <b>$24.95</b> (save =
46%)</font></font><br>
<font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&=
;pf%5Fid=3DOS01BTN8233L2V"=20
>More=20
Details...</a></font> <a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&=
;pf%5Fid=3DOS01BTN8233L2V"=20
><br>
<font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><b>Buy it =
NOW <i>!!</i></b></font>=20
<font size=3D"1" face=3D"Arial, Helvetica, sans-serif" =
color=3D"#ff0000">Free=20
Shipping</font></a></td>
</tr>
<tr valign=3D"top" bgcolor=3D"#99cc99">=20
<td colspan=3D"2" height=3D"2"><font size=3D"2"><b><font =
face=3D"Arial, Helvetica, sans-serif">6.=20
</font><font size=3D"2"><b><font size=3D"2"><b><font =
face=3D"Arial, Helvetica, sans-serif">NOKIA</font></b></font><font =
face=3D"Arial, Helvetica, sans-serif">=20
51xx/6xx Li-ion 3200mAh Vibrating =
Battery</font></b></font></b></font></td>
<td height=3D"2" colspan=3D"2"><font size=3D"2"><b><font =
face=3D"Arial, Helvetica, sans-serif">14.Nokia=20
51xx/6xx Super Slim Black Li-ion 1200mAh Vib =
Battery</font></b></font></td>
</tr>
<tr valign=3D"top">=20
<td width=3D"78" height=3D"36">=20
<div align=3D"center"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&=
;pf%5Fid=3DOS01BTN56L2VK1"=20
><img =
src=3D"http://www.gogocity.com//Assets/product_images/OS01/BTN56L2VK1-80.=
JPG" border=3D"0" alt=3D"NOKIA 51xx/6xx Li-ion 3200mAh Vibrating =
Battery" height=3D"70"><br>
<font size=3D"2" face=3D"Arial, Helvetica, sans-serif">large =
image</font></a></div>
</td>
<td width=3D"305" height=3D"36" bgcolor=3D"#ffffcc"><font =
size=3D"2" face=3D"Arial, Helvetica, sans-serif">Retail=20
Price: $79.99<br>
<font color=3D"#ff0000">Blow Out Price: <b>$34.95</b> (save =
56%)</font></font><br>
<font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&=
;pf%5Fid=3DOS01BTN56L2VK1"=20
>More=20
Details...</a></font> <a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&=
;pf%5Fid=3DOS01BTN56L2VK1"=20
><br>
<font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><b>Buy it =
NOW <i>!!</i></b></font>=20
<font size=3D"1" face=3D"Arial, Helvetica, sans-serif" =
color=3D"#ff0000">Free=20
Shipping</font></a><br>
</td>
<td height=3D"36" width=3D"70">=20
<div align=3D"center"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&=
;pf%5Fid=3DOS01BTN56L2VK1SLM"=20
><img =
src=3D"http://www.gogocity.com//Assets/product_images/OS01/BTN56L2VK1-80.=
JPG" width=3D"70" border=3D"0" alt=3D"Nokia 51xx/6xx Super Slim Black =
Li-ion 1200mAh Vib Battery"><br>
<font face=3D"Arial, Helvetica, sans-serif" size=3D"2"> large =
image</font></a></div>
</td>
<td height=3D"36" width=3D"309" bgcolor=3D"#ffffcc"><font =
size=3D"2" face=3D"Arial, Helvetica, sans-serif">Retail=20
Price: $70.99<br>
<font color=3D"#ff0000">Blow Out Price: <b>$29.95</b> (save =
58%)</font></font><br>
<font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&=
;pf%5Fid=3DOS01BTN56L2VK1SLM"=20
>More=20
Details...</a></font> <a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&=
;pf%5Fid=3DOS01BTN56L2VK1SLM"=20
><br>
<font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><b>Buy it =
NOW <i>!!</i></b></font>=20
<font size=3D"1" face=3D"Arial, Helvetica, sans-serif" =
color=3D"#ff0000">Free=20
Shipping</font></a></td>
</tr>
<tr valign=3D"top" bgcolor=3D"#99cc99">=20
<td colspan=3D"2" height=3D"12"><font size=3D"2"><b><font =
face=3D"Arial, Helvetica, sans-serif">7.=20
</font><font size=3D"2"><b><font size=3D"2"><b><font =
size=3D"2"><b><font face=3D"Arial, Helvetica, =
sans-serif">NOKIA</font></b></font><font face=3D"Arial, Helvetica, =
sans-serif">=20
51xx/6xx Black NIMH-700mAh Vibrating =
Battery</font></b></font></b></font></b></font></td>
<td colspan=3D"2" height=3D"12"><font size=3D"2"><b><font =
face=3D"Arial, Helvetica, sans-serif">15.=20
Nokia 3310/3390 Vertical Leather Magnetic Button =
Pouch</font></b></font></td>
</tr>
<tr valign=3D"top">=20
<td width=3D"78" height=3D"73">=20
<div align=3D"center"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&=
;pf%5Fid=3DOS01BTN56N2VK1"=20
><img =
src=3D"http://www.gogocity.com//Assets/product_images/OS01/BTN56L2VK1-80.=
JPG" width=3D"70" border=3D"0" alt=3D"NOKIA 51xx/6xx Black NIMH-700mAh =
Vibrating Battery"><br>
<font size=3D"2" face=3D"Arial, Helvetica, sans-serif">large =
image</font></a></div>
</td>
<td width=3D"305" height=3D"73" bgcolor=3D"#ffffcc"><font =
size=3D"2" face=3D"Arial, Helvetica, sans-serif">Retail=20
Price: $45.99<br>
<font color=3D"#ff0000">Blow Out Price: <b>$14.95</b> (save =
67%)</font></font><br>
<font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&=
;pf%5Fid=3DOS01BTN56N2VK1"=20
>More=20
Details...</a></font> <a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&=
;pf%5Fid=3DOS01BTN56N2VK1"=20
><br>
<font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><b>Buy it =
NOW <i>!!</i></b></font>=20
<font size=3D"1" face=3D"Arial, Helvetica, sans-serif" =
color=3D"#ff0000">Free=20
Shipping</font></a><br>
</td>
<td height=3D"73" width=3D"70">=20
<div align=3D"center"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&=
;pf%5Fid=3DOS01CSN331090LK"=20
><img =
src=3D"http://www.gogocity.com//Assets/product_images/OS01/CSN8233LK-80.J=
PG" width=3D"70" border=3D"0" alt=3D"Nokia 82xx/33xx Vertical Leather =
Magnetic Button Pouch"><br>
<font face=3D"Arial, Helvetica, sans-serif" size=3D"2"> large =
image</font></a></div>
</td>
<td height=3D"73" width=3D"309" bgcolor=3D"#ffffcc"><font =
size=3D"2" face=3D"Arial, Helvetica, sans-serif">Retail=20
Price: $24.99 <br>
<font color=3D"#ff0000">Blow Out Price: <b>$9.95</b> (save =
60%)</font></font><br>
<font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&=
;pf%5Fid=3DOS01CSN331090LK"=20
>More=20
Details...</a></font> <a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&=
;pf%5Fid=3DOS01CSN8233LK"=20
><br>
<font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><b>Buy it =
NOW <i>!!</i></b></font>=20
<font size=3D"1" face=3D"Arial, Helvetica, sans-serif" =
color=3D"#ff0000">Free=20
Shipping</font></a></td>
</tr>
<tr valign=3D"top" bgcolor=3D"#99cc99">=20
<td colspan=3D"2" height=3D"9"><font size=3D"2"><b><font =
face=3D"Arial, Helvetica, sans-serif">8.=20
Nokia 8260/8290 Data Cable</font></b></font></td>
<td colspan=3D"2" height=3D"9"><font size=3D"2"><b><font =
face=3D"Arial, Helvetica, sans-serif">16.=20
Nokia 8260/8290 Vertical Leather Magnetic Button =
Pouch</font></b></font></td>
</tr>
<tr valign=3D"top">=20
<td width=3D"78" height=3D"73">=20
<div align=3D"center"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&=
;pf%5Fid=3DOS01DKN8233K"=20
><img =
src=3D"http://www.gogocity.com//Assets/product_images/OS01/DKN56K-80.JPG"=
width=3D"70" border=3D"0" alt=3D"NOKIA 51xx/6xx Data Cable"><br>
<font face=3D"Arial, Helvetica, sans-serif" size=3D"2"> large =
image</font></a></div>
</td>
<td width=3D"305" height=3D"73" bgcolor=3D"#ffffcc"><font =
size=3D"2" face=3D"Arial, Helvetica, sans-serif">Retail=20
Price: $79.99<br>
<font color=3D"#ff0000">Blow Out Price: <b>$19.95</b> (save =
75%)</font></font><br>
<font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&=
;pf%5Fid=3DOS01DKN8233K"=20
>More=20
Details...</a></font> <a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&=
;pf%5Fid=3DOS01DKN8233K"=20
><br>
<font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><b>Buy it =
NOW <i>!!</i></b></font>=20
<font size=3D"1" face=3D"Arial, Helvetica, sans-serif" =
color=3D"#ff0000">Free=20
Shipping</font></a></td>
<td height=3D"73" width=3D"70">=20
<div align=3D"center"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&=
;pf%5Fid=3DOS01CSN8233LK"=20
><img =
src=3D"http://www.gogocity.com//Assets/product_images/OS01/CSN8233LK-80.J=
PG" width=3D"70" border=3D"0" alt=3D"Nokia 82xx/33xx Vertical Leather =
Magnetic Button Pouch"><br>
<font face=3D"Arial, Helvetica, sans-serif" size=3D"2"> large =
image</font></a></div>
</td>
<td height=3D"73" width=3D"309" bgcolor=3D"#ffffcc"><font =
size=3D"2" face=3D"Arial, Helvetica, sans-serif">Retail=20
Price: $24.99 <br>
<font color=3D"#ff0000">Blow Out Price: <b>$9.95</b> (save =
60%)</font></font><br>
<font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&=
;pf%5Fid=3DOS01CSN8233LK"=20
>More=20
Details...</a></font> <a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D5031&=
;pf%5Fid=3DOS01CSN8233LK"=20
><br>
<font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><b>Buy it =
NOW <i>!!</i></b></font>=20
<font size=3D"1" face=3D"Arial, Helvetica, sans-serif" =
color=3D"#ff0000">Free=20
Shipping</font></a></td>
</tr>
</table>
</div>
</body>
------=_NextPart_000_A9C20_01C12FC9.636A5710--
>From owner-rmt@listserv.lbl.gov Wed Aug 29 16:03:39 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f7TMtfS10210;
Wed, 29 Aug 2001 15:55:41 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f7TMtdV10206
for <rmt@listserv.lbl.gov>; Wed, 29 Aug 2001 15:55:39 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f7TMtcF09197
for <rmt@listserv.lbl.gov>; Wed, 29 Aug 2001 15:55:39 -0700 (PDT)
Received: from motgate.mot.com (motgate.mot.com [129.188.136.100])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f7TMtb509177
for <rmt@lbl.gov>; Wed, 29 Aug 2001 15:55:37 -0700 (PDT)
Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate.mot.com (motgate 2.1) with ESMTP id PAA09560 for <rmt@lbl.gov>; Wed, 29 Aug 2001 15:55:36 -0700 (MST)]
Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id PAA11005 for <rmt@lbl.gov>; Wed, 29 Aug 2001 15:55:34 -0700 (MST)]
Received: from arc.corp.mot.com ([10.238.80.122])
by homer.arc.corp.mot.com (8.11.2/8.11.2) with ESMTP id f7TMtQA08797;
Thu, 30 Aug 2001 08:55:27 +1000 (EST)
Message-ID: <3B8D72DE.EE4D0824@arc.corp.mot.com>
Date: Thu, 30 Aug 2001 08:55:26 +1000
From: Roger Kermode <rkermode@arc.corp.mot.com>
Organization: Motorola
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: rmt-list <rmt@lbl.gov>
CC: Scott Bradner <sob@harvard.edu>
Subject: RMT Milestone update: DATE REQUEST
Content-Type: multipart/mixed;
boundary="------------C0EB9B0130E55AE800E54F8C"
Sender: owner-rmt@lbl.gov
Precedence: bulk
This is a multi-part message in MIME format.
--------------C0EB9B0130E55AE800E54F8C
Content-Type: multipart/alternative;
boundary="------------C0BAA4BFE118D7489BE8BB5B"
--------------C0BAA4BFE118D7489BE8BB5B
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Hi Everyone,
at the recent IETF in London we suggested the following
milestone updates for our charter. As was discussed in
that meeting we need to take this to the list and obtain
further details regarding which drafts will be ready when.
To that end we would like the authors/editors of all active
rmt drafts to send me an email as to which dates they would
like to fall under (Dec 01, Mar 02, Jun 02). These dates are
aggressive. If you have *violent* objections and would
like to suggest another date for your draft please say so,
however, we would like to try and bunch the drafts together
so that we can maximise the harmonisation between them.
cheers,
Roger, Lorenzo, Allison
Suggested Milestones
--------------------
Sep 01 Complete Author Guidelines draft WGLC
submit for publication as informational.
Dec 01 Protocol instantiations drafts submitted
for publication as experimental. Which ones?
Dec 01 Congestion control drafts submitted for
publication as experimental.
Mar 02 Remaining Protocol instantiations drafts
submitted for publication as experimental.
Which ones?
Jun 02 Protocol instantiations drafts submitted
for publication as proposed standard.
Jun 02 Congestion control drafts submitted for
publication as proposed standard.
--------------C0BAA4BFE118D7489BE8BB5B
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Hi Everyone,
<p>at the recent IETF in London we suggested the following
<br>milestone updates for our charter. As was discussed in
<br>that meeting we need to take this to the list and obtain
<br>further details regarding which drafts will be ready when.
<p>To that end we would like the authors/editors of all active
<br>rmt drafts to send me an email as to which dates they would
<br>like to fall under (Dec 01, Mar 02, Jun 02). These dates are
<br>aggressive. If you have *violent* objections and would
<br>like to suggest another date for your draft please say so,
<br>however, we would like to try and bunch the drafts together
<br>so that we can maximise the harmonisation between them.
<p>cheers,
<p>Roger, Lorenzo, Allison
<br>
<p><tt>Suggested Milestones</tt>
<br><tt>--------------------</tt><tt></tt>
<p><tt>Sep 01 Complete Author Guidelines draft WGLC</tt>
<br><tt> submit for publication
as informational.</tt><tt></tt>
<p><tt>Dec 01 Protocol instantiations drafts submitted</tt>
<br><tt> for publication as experimental.
Which ones?</tt><tt></tt>
<p><tt>Dec 01 Congestion control drafts submitted for</tt>
<br><tt> publication as experimental.</tt><tt></tt>
<p><tt>Mar 02 Remaining Protocol instantiations drafts</tt>
<br><tt> submitted for publication
as experimental.</tt>
<br><tt> Which ones?</tt><tt></tt>
<p><tt>Jun 02 Protocol instantiations drafts submitted</tt>
<br><tt> for publication as proposed
standard.</tt><tt></tt>
<p><tt>Jun 02 Congestion control drafts submitted for</tt>
<br><tt> publication as proposed
standard.</tt></html>
--------------C0BAA4BFE118D7489BE8BB5B--
--------------C0EB9B0130E55AE800E54F8C
Content-Type: text/x-vcard; charset=us-ascii;
name="rkermode.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Roger Kermode
Content-Disposition: attachment;
filename="rkermode.vcf"
begin:vcard
n:Kermode;Roger
tel;cell:+61-408-212-284
tel;fax:+61-2-9666-0501
tel;work:+61-2-9666-0558
x-mozilla-html:FALSE
org:Motorola Labs, Motorola Australia Research Centre;Communications and Networks Laboratory
adr:;;Locked Bag 5028;Botany;NSW;1455;Australia
version:2.1
email;internet:Roger.Kermode@motorola.com
title:Prinicpal Research Engineer / Lab Manager
fn:Roger Kermode
end:vcard
--------------C0EB9B0130E55AE800E54F8C--
>From owner-rmt@listserv.lbl.gov Sun Sep 2 12:07:30 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f82J4Rh14449;
Sun, 2 Sep 2001 12:04:27 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f82J4QE14445
for <rmt@listserv.lbl.gov>; Sun, 2 Sep 2001 12:04:26 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f82J4Po10587
for <rmt@listserv.lbl.gov>; Sun, 2 Sep 2001 12:04:26 -0700 (PDT)
Received: from market0 ([208.158.105.111])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f82J4P510584
for <rmt@lbl.gov>; Sun, 2 Sep 2001 12:04:25 -0700 (PDT)
Received: from mail pickup service by market0 with Microsoft SMTPSVC;
Sun, 2 Sep 2001 12:00:46 -0700
From: <adv1@market.gogocity.com>
To: <rmt@lbl.gov>
Subject: Retire Beanie Babies Save Up to 50%
Date: Sun, 2 Sep 2001 12:00:46 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_2C3090_01C133A6.E65B5EE0"
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Message-ID: <MARKET0oV9viK0usZsW000b0cb8@market0>
X-OriginalArrivalTime: 02 Sep 2001 19:00:46.0742 (UTC) FILETIME=[92D8BB60:01C133E1]
Sender: owner-rmt@lbl.gov
Precedence: bulk
This is a multi-part message in MIME format.
------=_NextPart_000_2C3090_01C133A6.E65B5EE0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
=20
<http://www.gogocity.com//dept.asp?parent%5Fid=3D7&strParentName=3DSports=
%2B
%26%2BTravels>
<http://www.gogocity.com//dept.asp?parent%5Fid=3D7&strParentName=3DSports=
%2B
%26%2BTravels>=20
Big Saving from GoGoCity. If you'd rather not receive any future
promotional E-mails from GoGoCity.com,=20
please click --> Un-Subscribe My E-mai
<http://www.gogocity.com/ggc_unsubscribe.asp> l
<http://www.gogocity.com/ggc_unsubscribe.asp>=20
International Order Welcome FREE SHIPPING NOT APPLY=20
ty=AE Beanie Babies (Retired)=20
Britannia Original Buddy
Britannia Original Buddy
click for large image
<http://www.gogocity.com//product_details.asp?dept_id=3D16403&pf_id=3DOS0=
1BR
ITANNIA-BUDDY> Retail Price: $199.00
Out Price: $99.99(save 50%)
More Details...
<http://www.gogocity.com//product_details.asp?dept_id=3D16403&pf_id=3DOS0=
1BR
ITANNIA-BUDDY> =20
ty=AE Beanie Babies Special Sale
Retails for $29.95~299.99 ( Save Up to 50% )
Now Only.....$99.99=20
This is an opportunity you don't want to miss
and a great one to add to your collection.=20
Limited Quantities, Hurry UP......!!!!!
=20
1. BRITANNIA ORIGINAL BUDDY 2. VALENTINO TY BEANIE BUDDY =20
Britannia Original Buddy
large image
<http://www.gogocity.com//product_details.asp?dept_id=3D16403&pf_id=3DOS0=
1BR
ITANNIA-BUDDY> =20
Retail Price: $199.00
Out Price: $99.99 (save 50%)
More Details...
<http://www.gogocity.com//product_details.asp?dept%5Fid=3D16403&pf%5Fid=3D=
OS
01BRITANNIA%2DBUDDY> =20
Buy it NOW !!
<http://www.gogocity.com//product_details.asp?dept%5Fid=3D16403&pf%5Fid=3D=
OS
01BRITANNIA%2DBUDDY>=20
VALENTINO TY BEANIE BUDDY
large image
<http://www.gogocity.com//product_details.asp?dept_id=3D16403&pf_id=3DOS0=
1VA
LENTINO> =20
Retail Price: $29.95
Out Price: $14.95 (save 50%)
More Details...
<http://www.gogocity.com//product_details.asp?dept%5Fid=3D16403&pf%5Fid=3D=
OS
01VALENTINO> =20
Buy it NOW !!
<http://www.gogocity.com//product_details.asp?dept%5Fid=3D16403&pf%5Fid=3D=
OS
01VALENTINO>=20
=09
3. BRITANNIA THE BRITISH BEAR 4. NIPPONIA THE JAPAN BEAR TY BEANIE
BEANIE =20
BRITANNIA THE BRITISH BEAR
large image
<http://www.gogocity.com//product_details.asp?dept%5Fid=3D16403&pf%5Fid=3D=
OS
01BRITANNIA%2DBABY> =20
Retail Price: $125.99
Out Price: $79.95 (save 37%)
More Details...
<http://www.gogocity.com//product_details.asp?dept%5Fid=3D16403&pf%5Fid=3D=
OS
01BRITANNIA%2DBABY> =20
Buy it NOW !!
<http://www.gogocity.com//product_details.asp?dept%5Fid=3D16403&pf%5Fid=3D=
OS
01BRITANNIA%2DBABY>=20
NIPPONIA THE JAPAN BEAR TY BEANIE BEANIE
large image
<http://www.gogocity.com//product_details.asp?dept_id=3D16403&pf_id=3DOS0=
1NI
PPONIA> =20
Retail Price: $111.95
Out Price: $55.95 (save 50%)
More Details...
<http://www.gogocity.com//product_details.asp?dept%5Fid=3D16403&pf%5Fid=3D=
OS
01NIPPONIA> =20
Buy it NOW !!
<http://www.gogocity.com//product_details.asp?dept%5Fid=3D16403&pf%5Fid=3D=
OS
01NIPPONIA>=20
=09
5. CHINOOK THE CANADA BEAR 6. RADAR TY BEANIE BEANIE =20
CHINOOK THE CANADA BEAR
large image
<http://www.gogocity.com//product_details.asp?dept%5Fid=3D16403&pf%5Fid=3D=
OS
01CHINNOOK> =20
Retail Price: $69.65
Out Price: $49.95 (save 28%)
More Details...
<http://www.gogocity.com//product_details.asp?dept%5Fid=3D16403&pf%5Fid=3D=
OS
01CHINNOOK> =20
Buy it NOW !!
<http://www.gogocity.com//product_details.asp?dept%5Fid=3D16403&pf%5Fid=3D=
OS
01CHINNOOK>=20
RADAR TY BEANIE BEANIE
large image
<http://www.gogocity.com//product_details.asp?dept_id=3D16403&pf_id=3DOS0=
1RA
DAR> =20
Retail Price: $179.95
Out Price: $89.95 (save 50%)
More Details...
<http://www.gogocity.com//product_details.asp?dept%5Fid=3D16403&pf%5Fid=3D=
OS
01STING> =20
Buy it NOW !!
<http://www.gogocity.com//product_details.asp?dept%5Fid=3D16403&pf%5Fid=3D=
OS
01RADAR>=20
=09
7. CORAL TY BEANIE BABY 8. STING THE STINGRAY TY BEANIE BABY =20
CORAL TY BEANIE BABY
large image
<http://www.gogocity.com//product_details.asp?dept%5Fid=3D16403&pf%5Fid=3D=
OS
01CORAL> =20
Retail Price: $179.95
Out Price: $99.95 (save 44%)
More Details...
<http://www.gogocity.com//product_details.asp?dept%5Fid=3D16403&pf%5Fid=3D=
OS
01CORAL> =20
Buy it NOW !!
<http://www.gogocity.com//product_details.asp?dept%5Fid=3D16403&pf%5Fid=3D=
OS
01CORAL>=20
STING THE STINGRAY TY BEANIE BABY
large image
<http://www.gogocity.com//product_details.asp?dept%5Fid=3D16403&pf%5Fid=3D=
OS
01STING> =20
Retail Price: $179.95
Out Price: $129.95 (save 28%)
More Details...
<http://www.gogocity.com//product_details.asp?dept%5Fid=3D7011&pf%5Fid=3D=
OS0
1LUBPRC> =20
Buy it NOW !!
<http://www.gogocity.com//product_details.asp?dept%5Fid=3D16403&pf%5Fid=3D=
OS
01STING>=20
=09
9. GARCIA THE BEAR TY BEANIE BEANIE 10. TABASCO THE BULL TY BEANIE
BEANIE =20
GARCIA THE BEAR TY BEANIE BEANIE
large image
<http://www.gogocity.com//product_details.asp?dept%5Fid=3D16403&pf%5Fid=3D=
OS
01GARCIA> =20
Retail Price: $299.99
Out Price: $199.95 (save 33%)
More Details...
<http://www.gogocity.com//product_details.asp?dept%5Fid=3D16403&pf%5Fid=3D=
OS
01GARCIA> =20
Buy it NOW !!
<http://www.gogocity.com//product_details.asp?dept%5Fid=3D16403&pf%5Fid=3D=
OS
01GARCIA>=20
TABASCO THE BULL TY BEANIE BEANIE
large image
<http://www.gogocity.com//product_details.asp?dept%5Fid=3D16403&pf%5Fid=3D=
OS
01TABASCO> =20
Retail Price: $179.95
Out Price: $89.95 (save 50%)
More Details...
<http://www.gogocity.com//product_details.asp?dept%5Fid=3D16403&pf%5Fid=3D=
OS
01TABASCO> =20
Buy it NOW !!
<http://www.gogocity.com//product_details.asp?dept%5Fid=3D16403&pf%5Fid=3D=
OS
01TABASCO>=20
=09
More Hot Item.....Click Here
<http://www.gogocity.com//searchresults.asp?department=3D16403&parent%5Fi=
d
=3D16>=20
------=_NextPart_000_2C3090_01C133A6.E65B5EE0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
<div align=3D"center">=20
<p><a =
href=3D"http://www.gogocity.com//dept.asp?parent%5Fid=3D7&strParentName=3D=
Sports%2B%26%2BTravels" target=3D"_blank"><img =
src=3D"http://www.gogocity.com/Assets/images/logo50.gif" =
border=3D"0"></a><a =
href=3D"http://www.gogocity.com//dept.asp?parent%5Fid=3D7&strParentName=3D=
Sports%2B%26%2BTravels" target=3D"_blank"><img =
src=3D"http://www.gogocity.com/Assets/images/Home399Banner.gif" =
border=3D"0"></a><br>
<font size=3D"2" face=3D"Arial, Helvetica, sans-serif">Big Saving =
from GoGoCity.=20
If you'd rather not receive any future promotional E-mails from =
GoGoCity.com,=20
<br>
please click --> <b><a =
href=3D"http://www.gogocity.com/ggc_unsubscribe.asp">Un-Subscribe=20
My E-mai</a></b></font><font size=3D"2"><a =
href=3D"http://www.gogocity.com/ggc_unsubscribe.asp"><font =
face=3D"Arial, Helvetica, sans-serif"><b>l</b></font></a></font><br>
<font face=3D"Arial, Helvetica, sans-serif" size=3D"3"><b><font =
size=3D"2">International=20
Order Welcome</font></b></font><font size=3D"2"><b><font =
face=3D"Arial, Helvetica, sans-serif">=20
FREE SHIPPING NOT APPLY</font></b></font> </p>
<table width=3D"75%" cellpadding=3D"0" height=3D"30" cellspacing=3D"0" =
bgcolor=3D"#3366CC">
<tr>=20
<td height=3D"28" valign=3D"top">=20
<div align=3D"center"><font face=3D"Arial, Helvetica, =
sans-serif" color=3D"#FFFFFF"><b><font size=3D"2" =
color=3D"#FFFFFF"><b><b><font size=3D"7">ty<font =
size=3D"3">®</font></font><font size=3D"5">=20
Beanie Babies (Retired) =
</font></b></b></font></b></font></div>
</td>
</tr>
</table>
<table width=3D"75%" align=3D"center" cellspacing=3D"0" =
cellpadding=3D"10" border=3D"0">
<tr valign=3D"top">=20
<td align=3D"center" height=3D"222" bordercolor=3D"#00CCFF">=20
<p><font size=3D"2" color=3D"#FFFFFF"><font face=3D"Arial, =
Helvetica, sans-serif" color=3D"#000000" size=3D"3"><b><font =
size=3D"4">Britannia=20
Original Buddy</font></b></font><font face=3D"Arial, =
Helvetica, sans-serif" color=3D"#000000"><br>
</font></font><a =
href=3D"http://www.gogocity.com//product_details.asp?dept_id=3D16403&pf_i=
d=3DOS01BRITANNIA-BUDDY"><img =
src=3D"http://www.gogocity.com//Assets/product_images/OS01/BRITANNIA-BUDD=
Y-170.JPG" vspace=3D"5" alt=3D"Britannia Original Buddy" border=3D"0" =
height=3D"200"><br>
<font face=3D"Arial, Helvetica, sans-serif" size=3D"2">click =
for large image<br>
</font> <br>
</a><font size=3D"2" face=3D"Arial, Helvetica, =
sans-serif">Retail Price:=20
$199.00<br>
<font color=3D"#FF0000"> Out Price: <b>$99.99</b>(save =
50%)</font></font><br>
<font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept_id=3D16403&pf_i=
d=3DOS01BRITANNIA-BUDDY">More=20
Details...</a></font> </p>
</td>
<td align=3D"center" height=3D"222">=20
<p><font face=3D"Arial, Helvetica, sans-serif"><b><font =
size=3D"2"><b><b><font size=3D"5"><font size=3D"3">ty®=20
Beanie Babies Special =
Sale</font></font></b></b></font></b></font><br>
<font face=3D"Arial, Helvetica, sans-serif" =
size=3D"3"><b>Retails for $29.95~299.99=20
<font face=3D"Arial, Helvetica, sans-serif" size=3D"3"><font =
size=3D"5"><font size=3D"2" color=3D"#000000">(=20
Save Up to 50% )</font></font></font><font size=3D"4"><br>
</font></b></font></p>
<p><font face=3D"Arial, Helvetica, sans-serif" =
size=3D"3"><b><font color=3D"#009966" size=3D"5"><font =
color=3D"#FF0000">=20
<font size=3D"4">Now Only</font>.....<font =
size=3D"7">$99.99</font></font>=20
</font></b></font><font face=3D"Arial, Helvetica, sans-serif" =
size=3D"3"><b><font face=3D"Arial, Helvetica, sans-serif" =
size=3D"3"><b><font face=3D"Arial, Helvetica, sans-serif" =
size=3D"3"><b><font face=3D"Arial, Helvetica, sans-serif" =
size=3D"3"><b><font face=3D"Arial, Helvetica, sans-serif" =
size=3D"3"><b><font size=3D"5" color=3D"#FF0000"><i><font face=3D"Arial, =
Helvetica, sans-serif" size=3D"3"><b><br>
<br>
</b></font></i></font><font size=3D"5"><i><font face=3D"Arial, =
Helvetica, sans-serif" size=3D"3"><b>This=20
is an opportunity you don't want to miss<br>
and a great one to add to your collection. <br>
=
</b></font></i></font></b></font></b></font></b></font></b></font></b><b>=
<font face=3D"Arial, Helvetica, sans-serif" size=3D"3"><b><font =
face=3D"Arial, Helvetica, sans-serif" size=3D"3"><b><font face=3D"Arial, =
Helvetica, sans-serif" size=3D"3"><b><font face=3D"Arial, Helvetica, =
sans-serif" size=3D"3"><b><font size=3D"5"><i><font face=3D"Arial, =
Helvetica, sans-serif" size=3D"3"><b><font face=3D"Arial, Helvetica, =
sans-serif" size=3D"3"><b><font face=3D"Arial, Helvetica, sans-serif" =
size=3D"3"><b><font face=3D"Arial, Helvetica, sans-serif" =
size=3D"3"><b><font size=3D"5" color=3D"#FF0000"><i><font face=3D"Arial, =
Helvetica, sans-serif" size=3D"3"><b><font color=3D"#FF0000"><br>
</font><font face=3D"Arial, Helvetica, sans-serif" =
size=3D"3"><b><font size=3D"5" color=3D"#FF0000"><i><font =
size=3D"4">Limited=20
</font><font face=3D"Arial, Helvetica, sans-serif" =
size=3D"3"><b><font face=3D"Arial, Helvetica, sans-serif" =
size=3D"3"><b><font face=3D"Arial, Helvetica, sans-serif" =
size=3D"3"><b><font face=3D"Arial, Helvetica, sans-serif" =
size=3D"3"><b><font face=3D"Arial, Helvetica, sans-serif" =
size=3D"3"><b><font size=3D"5"><i><font face=3D"Arial, Helvetica, =
sans-serif" size=3D"3"><b><font face=3D"Arial, Helvetica, sans-serif" =
size=3D"3"><b><font face=3D"Arial, Helvetica, sans-serif" =
size=3D"3"><b><font face=3D"Arial, Helvetica, sans-serif" =
size=3D"3"><b><font size=3D"5" color=3D"#FF0000"><i><font face=3D"Arial, =
Helvetica, sans-serif" size=3D"3"><b><font face=3D"Arial, Helvetica, =
sans-serif" size=3D"3"><b><font size=3D"5" color=3D"#FF0000"><i><font =
face=3D"Arial, Helvetica, sans-serif" size=3D"3"><b><font face=3D"Arial, =
Helvetica, sans-serif" size=3D"3"><b><font face=3D"Arial, Helvetica, =
sans-serif" size=3D"3"><b><font face=3D"Arial, Helvetica, sans-serif" =
size=3D"3"><b><font face=3D"Arial, Helvetica, sans-serif" =
size=3D"3"><b><font size=3D"5"><i><font face=3D"Arial, Helvetica, =
sans-serif" size=3D"3"><b><font face=3D"Arial, Helvetica, sans-serif" =
size=3D"3"><b><font face=3D"Arial, Helvetica, sans-serif" =
size=3D"3"><b><font face=3D"Arial, Helvetica, sans-serif" =
size=3D"3"><b><font size=3D"5" color=3D"#FF0000"><i><font face=3D"Arial, =
Helvetica, sans-serif" size=3D"3"><b><font face=3D"Arial, Helvetica, =
sans-serif" size=3D"3"><b><font size=3D"5" color=3D"#FF0000"><i><font =
size=3D"4">Quantities</font><font face=3D"Arial, Helvetica, sans-serif" =
size=3D"3"><b><font face=3D"Arial, Helvetica, sans-serif" =
size=3D"3"><b><font face=3D"Arial, Helvetica, sans-serif" =
size=3D"3"><b><font face=3D"Arial, Helvetica, sans-serif" =
size=3D"3"><b><font face=3D"Arial, Helvetica, sans-serif" =
size=3D"3"><b><font size=3D"5"><i><font face=3D"Arial, Helvetica, =
sans-serif" size=3D"3"><b><font face=3D"Arial, Helvetica, sans-serif" =
size=3D"3"><b><font face=3D"Arial, Helvetica, sans-serif" =
size=3D"3"><b><font face=3D"Arial, Helvetica, sans-serif" =
size=3D"3"><b><font size=3D"5" color=3D"#FF0000"><i><font face=3D"Arial, =
Helvetica, sans-serif" size=3D"3"><b><font face=3D"Arial, Helvetica, =
sans-serif" size=3D"3"><b><font size=3D"5" color=3D"#FF0000"><i><font =
size=3D"4"></font></i></font></b></font></b></font></i></font></b></font>=
</b></font></b></font></b></font></i></font></b></font></b></font></b></f=
ont></b></font></b></font></i></font></b></font></b></font></i></font></b=
></font></b></font></b></font></b></font></i></font></b></font></b></font=
></b></font></b></font></b></font><font size=3D"4">,=20
Hurry =
UP......!!!!!</font></i></font></b></font></b></font></i></font></b></fon=
t></b></font></b></font></b></font></i></font></b></font></b></font></b><=
/font></b></font></b></font></i></font></b></font></b></font></i></font><=
/b></font></b></font></b></font></b></font></i></font></b></font></b></fo=
nt></b></font></b></font></b></font></p>
<p><img =
src=3D"http://www.lordwireless.com/auctionimage/ty.jpg"></p>
</td>
</tr>
</table>
<table cellspacing=3D"3" width=3D"75%">
<tr valign=3D"top" bgcolor=3D"#660099">=20
<td colspan=3D"2" height=3D"17"><font size=3D"2" =
color=3D"#FFFFFF"><b><font face=3D"Arial, Helvetica, sans-serif">1.=20
</font><b><font face=3D"Arial, Helvetica, sans-serif">BRITANNIA =
ORIGINAL=20
BUDDY</font></b></b></font></td>
<td colspan=3D"2" height=3D"17"><font size=3D"2" =
color=3D"#FFFFFF"><b><font face=3D"Arial, Helvetica, sans-serif">2.=20
VALENTINO TY BEANIE BUDDY</font></b></font></td>
</tr>
<tr valign=3D"top">=20
<td width=3D"15%" height=3D"0">=20
<div align=3D"center"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept_id=3D16403&pf_i=
d=3DOS01BRITANNIA-BUDDY"><img =
src=3D"http://www.gogocity.com//Assets/product_images/OS01/BRITANNIA-BUDD=
Y-80.JPG" width=3D"70" border=3D"0" alt=3D"Britannia Original =
Buddy"><br>
<font face=3D"Arial, Helvetica, sans-serif" size=3D"2"> large =
image</font></a>=20
</div>
</td>
<td bgcolor=3D"#FFFF99" width=3D"32%" height=3D"0"><font =
size=3D"2" face=3D"Arial, Helvetica, sans-serif">Retail=20
Price: $199.00<br>
<font color=3D"#FF0000"> Out Price: <b>$99.99 </b>(save =
50%)</font></font><br>
<font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D16403&pf=
%5Fid=3DOS01BRITANNIA%2DBUDDY">More=20
Details...</a></font> <a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D16403&pf=
%5Fid=3DOS01BRITANNIA%2DBUDDY"><br>
<font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><b>Buy it =
NOW <i>!!</i></b></font></a><br>
</td>
<td width=3D"15%" height=3D"0" valign=3D"top">=20
<div align=3D"center"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept_id=3D16403&pf_i=
d=3DOS01VALENTINO"><img =
src=3D"http://www.gogocity.com//Assets/product_images/OS01/VALENTINO-80.J=
PG" width=3D"70" border=3D"0" alt=3D"VALENTINO TY BEANIE BUDDY"><br>
<font face=3D"Arial, Helvetica, sans-serif" size=3D"2"> large =
image</font></a>=20
</div>
</td>
<td bgcolor=3D"#FFFF99" width=3D"32%" height=3D"0"><font =
size=3D"2" face=3D"Arial, Helvetica, sans-serif">Retail=20
Price: $29.95<br>
<font color=3D"#FF0000"> Out Price: <b>$14.95 </b>(save =
50%)</font></font><br>
<font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D16403&pf=
%5Fid=3DOS01VALENTINO">More=20
Details...</a></font> <a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D16403&pf=
%5Fid=3DOS01VALENTINO"><br>
<font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><b>Buy it =
NOW <i>!!</i></b></font></a><br>
</td>
</tr>
<tr valign=3D"top" bgcolor=3D"#660099">=20
<td colspan=3D"2" bgcolor=3D"#660099" height=3D"12"><font =
size=3D"2" color=3D"#FFFFFF"><b><font face=3D"Arial, Helvetica, =
sans-serif">3.=20
BRITANNIA THE BRITISH BEAR</font></b></font></td>
<td colspan=3D"2" height=3D"12"><font size=3D"2" =
color=3D"#FFFFFF"><b><font face=3D"Arial, Helvetica, sans-serif">4.=20
NIPPONIA THE JAPAN BEAR TY BEANIE BEANIE</font></b></font></td>
</tr>
<tr valign=3D"top">=20
<td width=3D"15%" height=3D"0" valign=3D"top">=20
<div align=3D"center"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D16403&pf=
%5Fid=3DOS01BRITANNIA%2DBABY"><img =
src=3D"http://www.gogocity.com//Assets/product_images/OS01/BRITANNIA-BABY=
-80.JPG" width=3D"70" border=3D"0" alt=3D"BRITANNIA THE BRITISH =
BEAR"><br>
<font face=3D"Arial, Helvetica, sans-serif" size=3D"2"> large =
image</font></a>=20
</div>
</td>
<td bgcolor=3D"#FFFF99" width=3D"32%" height=3D"0"><font =
size=3D"2" face=3D"Arial, Helvetica, sans-serif">Retail=20
Price: $125.99<br>
<font color=3D"#FF0000"> Out Price: <b>$79.95 </b>(save =
37%)</font></font><br>
<font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D16403&pf=
%5Fid=3DOS01BRITANNIA%2DBABY">More=20
Details...</a></font> <a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D16403&pf=
%5Fid=3DOS01BRITANNIA%2DBABY"><br>
<font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><b>Buy it =
NOW <i>!!</i></b></font></a><br>
</td>
<td width=3D"15%" height=3D"0" valign=3D"top">=20
<div align=3D"center"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept_id=3D16403&pf_i=
d=3DOS01NIPPONIA"><img =
src=3D"http://www.gogocity.com//Assets/product_images/OS01/NIPPONIA-80.JP=
G" width=3D"70" border=3D"0" alt=3D"NIPPONIA THE JAPAN BEAR TY BEANIE =
BEANIE"><br>
<font face=3D"Arial, Helvetica, sans-serif" size=3D"2"> large =
image</font></a>=20
</div>
</td>
<td bgcolor=3D"#FFFF99" width=3D"32%" height=3D"0"><font =
size=3D"2" face=3D"Arial, Helvetica, sans-serif">Retail=20
Price: $111.95<br>
<font color=3D"#FF0000"> Out Price: <b>$55.95 </b>(save =
50%)</font></font><br>
<font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D16403&pf=
%5Fid=3DOS01NIPPONIA">More=20
Details...</a></font> <a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D16403&pf=
%5Fid=3DOS01NIPPONIA"><br>
<font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><b>Buy it =
NOW <i>!!</i></b></font></a><br>
</td>
</tr>
<tr valign=3D"top" bgcolor=3D"#660099">=20
<td colspan=3D"2" bgcolor=3D"#660099" height=3D"15"><font =
size=3D"2" color=3D"#FFFFFF"><b><font face=3D"Arial, Helvetica, =
sans-serif">5</font><font face=3D"Arial, Helvetica, sans-serif">.=20
CHINOOK THE CANADA BEAR</font></b></font></td>
<td colspan=3D"2" height=3D"15"><font size=3D"2" =
color=3D"#FFFFFF"><b><font face=3D"Arial, Helvetica, sans-serif">6.=20
RADAR TY BEANIE BEANIE</font></b></font></td>
</tr>
<tr valign=3D"top">=20
<td width=3D"15%" height=3D"0">=20
<div align=3D"center"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D16403&pf=
%5Fid=3DOS01CHINNOOK"><img =
src=3D"http://www.gogocity.com//Assets/product_images/OS01/CHINOOK-80.JPG=
" width=3D"70" border=3D"0" alt=3D"CHINOOK THE CANADA BEAR"><br>
<font face=3D"Arial, Helvetica, sans-serif" size=3D"2"> large =
image</font></a>=20
</div>
</td>
<td bgcolor=3D"#FFFF99" width=3D"32%" height=3D"0"><font =
size=3D"2" face=3D"Arial, Helvetica, sans-serif">Retail=20
Price: $69.65<br>
<font color=3D"#FF0000"> Out Price: <b>$49.95 </b>(save =
28%)</font></font><br>
<font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D16403&pf=
%5Fid=3DOS01CHINNOOK">More=20
Details...</a></font> <a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D16403&pf=
%5Fid=3DOS01CHINNOOK"><br>
<font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><b>Buy it =
NOW <i>!!</i></b></font></a><br>
</td>
<td width=3D"15%" height=3D"0">=20
<div align=3D"center"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept_id=3D16403&pf_i=
d=3DOS01RADAR"><img =
src=3D"http://www.gogocity.com//Assets/product_images/OS01/RADAR-80.JPG" =
width=3D"70" border=3D"0" alt=3D"RADAR TY BEANIE BEANIE"><br>
<font face=3D"Arial, Helvetica, sans-serif" size=3D"2"> large =
image</font></a>=20
</div>
</td>
<td bgcolor=3D"#FFFF99" width=3D"32%" height=3D"0"><font =
size=3D"2" face=3D"Arial, Helvetica, sans-serif">Retail=20
Price: $179.95<br>
<font color=3D"#FF0000"> Out Price: <b>$89.95 </b>(save =
50%)</font></font><br>
<font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D16403&pf=
%5Fid=3DOS01STING">More=20
Details...</a></font> <a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D16403&pf=
%5Fid=3DOS01RADAR"><br>
<font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><b>Buy it =
NOW <i>!!</i></b></font></a><br>
</td>
</tr>
<tr valign=3D"top" bgcolor=3D"#660099">=20
<td colspan=3D"2" bgcolor=3D"#660099" height=3D"16"><font =
size=3D"2" color=3D"#FFFFFF"><b><font face=3D"Arial, Helvetica, =
sans-serif">7</font><font face=3D"Arial, Helvetica, sans-serif">.=20
CORAL TY BEANIE BABY</font></b></font></td>
<td colspan=3D"2" height=3D"16"><font size=3D"2" =
color=3D"#FFFFFF"><b><font face=3D"Arial, Helvetica, sans-serif">8.=20
STING THE STINGRAY TY BEANIE BABY</font></b></font></td>
</tr>
<tr valign=3D"top">=20
<td width=3D"15%" height=3D"0">=20
<div align=3D"center"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D16403&pf=
%5Fid=3DOS01CORAL"><img =
src=3D"http://www.gogocity.com//Assets/product_images/OS01/CORAL-80.JPG" =
width=3D"70" border=3D"0" alt=3D"CORAL TY BEANIE BABY"><br>
<font face=3D"Arial, Helvetica, sans-serif" size=3D"2"> large =
image</font></a>=20
</div>
</td>
<td bgcolor=3D"#FFFF99" width=3D"32%" height=3D"0"><font =
size=3D"2" face=3D"Arial, Helvetica, sans-serif">Retail=20
Price: $179.95<br>
<font color=3D"#FF0000"> Out Price: <b>$99.95 </b>(save =
44%)</font></font><br>
<font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D16403&pf=
%5Fid=3DOS01CORAL">More=20
Details...</a></font> <a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D16403&pf=
%5Fid=3DOS01CORAL"><br>
<font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><b>Buy it =
NOW <i>!!</i></b></font></a><br>
</td>
<td width=3D"15%" height=3D"0">=20
<div align=3D"center"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D16403&pf=
%5Fid=3DOS01STING"><img =
src=3D"http://www.gogocity.com//Assets/product_images/OS01/STING-80.JPG" =
width=3D"70" border=3D"0" alt=3D"STING THE STINGRAY TY BEANIE BABY"><br>
<font face=3D"Arial, Helvetica, sans-serif" size=3D"2"> large =
image</font></a>=20
</div>
</td>
<td bgcolor=3D"#FFFF99" width=3D"32%" height=3D"0"><font =
size=3D"2" face=3D"Arial, Helvetica, sans-serif">Retail=20
Price: $179.95<br>
<font color=3D"#FF0000"> Out Price: <b>$129.95 </b>(save =
28%)</font></font><br>
<font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D7011&pf%=
5Fid=3DOS01LUBPRC">More=20
Details...</a></font> <a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D16403&pf=
%5Fid=3DOS01STING"><br>
<font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><b>Buy it =
NOW <i>!!</i></b></font></a><br>
</td>
</tr>
<tr valign=3D"top" bgcolor=3D"#660099">=20
<td colspan=3D"2" bgcolor=3D"#660099" height=3D"10"><font =
size=3D"2" color=3D"#FFFFFF"><b><font face=3D"Arial, Helvetica, =
sans-serif">9</font><font face=3D"Arial, Helvetica, sans-serif">.=20
GARCIA THE BEAR TY BEANIE BEANIE</font></b></font></td>
<td colspan=3D"2" height=3D"10"><font size=3D"2" =
color=3D"#FFFFFF"><b><font face=3D"Arial, Helvetica, sans-serif">10.=20
TABASCO THE BULL TY BEANIE BEANIE</font></b></font></td>
</tr>
<tr valign=3D"top">=20
<td width=3D"15%" height=3D"0">=20
<div align=3D"center"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D16403&pf=
%5Fid=3DOS01GARCIA"><img =
src=3D"http://www.gogocity.com//Assets/product_images/OS01/GARCIA-80.JPG"=
width=3D"70" border=3D"0" alt=3D"GARCIA THE BEAR TY BEANIE BEANIE"><br>
<font face=3D"Arial, Helvetica, sans-serif" size=3D"2"> large =
image</font></a>=20
</div>
</td>
<td bgcolor=3D"#FFFF99" width=3D"32%" height=3D"0"><font =
size=3D"2" face=3D"Arial, Helvetica, sans-serif">Retail=20
Price: $299.99<br>
<font color=3D"#FF0000"> Out Price: <b>$199.95 </b>(save =
33%)</font></font><br>
<font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D16403&pf=
%5Fid=3DOS01GARCIA">More=20
Details...</a></font> <a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D16403&pf=
%5Fid=3DOS01GARCIA"><br>
<font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><b>Buy it =
NOW <i>!!</i></b></font></a><br>
</td>
<td width=3D"15%" height=3D"0">=20
<div align=3D"center"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D16403&pf=
%5Fid=3DOS01TABASCO"><img =
src=3D"http://www.gogocity.com//Assets/product_images/OS01/TABASCO-80.JPG=
" width=3D"70" border=3D"0" alt=3D"TABASCO THE BULL TY BEANIE =
BEANIE"><br>
<font face=3D"Arial, Helvetica, sans-serif" size=3D"2"> large =
image</font></a>=20
</div>
</td>
<td bgcolor=3D"#FFFF99" width=3D"32%" height=3D"0"><font =
size=3D"2" face=3D"Arial, Helvetica, sans-serif">Retail=20
Price: $179.95<br>
<font color=3D"#FF0000"> Out Price: <b>$89.95 </b>(save =
50%)</font></font><br>
<font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D16403&pf=
%5Fid=3DOS01TABASCO">More=20
Details...</a></font> <a =
href=3D"http://www.gogocity.com//product_details.asp?dept%5Fid=3D16403&pf=
%5Fid=3DOS01TABASCO"><br>
<font face=3D"Arial, Helvetica, sans-serif" size=3D"2"><b>Buy it =
NOW <i>!!</i></b></font></a><br>
</td>
</tr>
</table>
<br>
<font face=3D"Arial, Helvetica, sans-serif" size=3D"4"><a =
href=3D"http://www.gogocity.com//searchresults.asp?department=3D16403&par=
ent%5Fid=3D16">More=20
Hot Item.....Click Here</a></font></div>
</body>
------=_NextPart_000_2C3090_01C133A6.E65B5EE0--
>From owner-rmt@listserv.lbl.gov Thu Sep 6 22:49:46 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f875iUY02027;
Thu, 6 Sep 2001 22:44:30 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f875iS601982
for <rmt@listserv.lbl.gov>; Thu, 6 Sep 2001 22:44:28 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f875iRP04579
for <rmt@listserv.lbl.gov>; Thu, 6 Sep 2001 22:44:27 -0700 (PDT)
Received: from motgate.mot.com (motgate.mot.com [129.188.136.100])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f875iQ604572
for <rmt@lbl.gov>; Thu, 6 Sep 2001 22:44:26 -0700 (PDT)
Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate.mot.com (motgate 2.1) with ESMTP id WAA09955; Thu, 6 Sep 2001 22:44:24 -0700 (MST)]
Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id WAA14911; Thu, 6 Sep 2001 22:36:04 -0700 (MST)]
Received: from arc.corp.mot.com ([10.238.80.122])
by homer.arc.corp.mot.com (8.11.2/8.11.2) with ESMTP id f875iIA21964;
Fri, 7 Sep 2001 15:44:18 +1000 (EST)
Message-ID: <3B985EA4.ECF40E61@arc.corp.mot.com>
Date: Fri, 07 Sep 2001 15:44:04 +1000
From: Roger Kermode <rkermode@arc.corp.mot.com>
Organization: Motorola
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: mintues@ietf.org, rmt-list <rmt@lbl.gov>,
Lorenzo Vicisano <lorenzo@cisco.com>, Allison Mankin <mankin@ISI.EDU>
Subject: 51st IETF London RMT Minutes
Content-Type: multipart/mixed;
boundary="------------E13464A018E6ABEEC64CC57A"
Sender: owner-rmt@lbl.gov
Precedence: bulk
This is a multi-part message in MIME format.
--------------E13464A018E6ABEEC64CC57A
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
--------------E13464A018E6ABEEC64CC57A
Content-Type: text/plain; charset=us-ascii;
name="ietf51_rmt_minutes.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="ietf51_rmt_minutes.txt"
Reliable Mulitcast Transport (rmt) WG
51st IETF, London
Minute Taker: Jon Crowcroft, jon@cs.ucl.ac.uk
Chairs: Roger Kermode, Roger.Kermode@motorola.com
Lorenzo Vicisano,
Session 1, Monday
=================
0. Agenda Bashing
1. rccp pi: Mike Luby
2. GRA Update: Tony Speakman
3. TRACK Update: Brian Whettan
4. NORM Update: Brian Adamson
5. NACk format: Brian Adamson
6. FEC BB: Lorenzo Vicisano
1/ Session control protocol discussion
Mike Luby
--------------------------------------
WG need to consider:
style of session, what kind of features will
be needed
pros/cons of:
security/DOS/authentication
firewalls
RMT support
CDI
cons
why not RTSP/sip or other existing protocol?
speakman@mike:
given GRA need session (state setup)
for RMT - hmmm
for multicast in general...could be huge (mmusic)
draft to date is v. large
do we want to customize?
kermode@mike
can we scope the work into mmusic?
colin perkins@mike
outside of mmusic scope
luby:
not clear its out of scope...
braden:
session ctl is for state.
Is this for transport, or for application?
- first is appropriate, rest not.
speakman:
we need it for transport....(including net. elements)...
but what is state?
whettan:
what is session ctl?
e.g. in TRACK its clear (e.g aggregation)
what isn't?
business aggregation, firewall, etc etc,,,
where is the line drawn
bradner:
where was luby draft...? at all
where is cow (given we don't know color to paint it)
to early to say what, but could be in scope -
hard to say right now...
luby:
see draft
Vicisano:
OK get specific and work on plan...
Ken Calvert:
what about relation to to MSEC WG?
answer : TBD
2. GRA Update
Tony Speakman
---------------------
model
GRA is subset of routers
predefined filters
filter = fid+housekeeping/action/subfilter type
e.g . see PGM
lengthy example drawn from PGM...see slides
for actions, headers, etc
GRA schematic header... i-d's, operands
(remember filter ("program") is static in current model
sequence number (i.e.. other packet fields ) are implicit...
need discussion about identifiers
- need 1 (no more) to scope rest of action
1/2 the space of i-d's is for static i-d's
1/2 for dynamic i-d's...(i.e re-programmable)
Question: how long is id?
fixed/var? (var=future)
filter function:
packet accumulation is precluded by GRA
modification is restricted to overwriting GRA fields
i.e. v. limited - reformatting
(e.g. encapsulation/decapsulation) no no no!
operations (e.g. forwarding function:)
e.g. multicast - don't change route (graph?)
e.g. unicast yep - arbitrary...
(w.g. need to get to turning point.)
no (NO) packet generation.
ctl protocol:
in band info ok
out of band administration
Vicisano: what about transport protocol selector
Bormann: isn't it implicit(scoped by net header)
Speakman: only needs to be globally unique or scoped by transport no.
need to decouple transport...
some discussion of protocol v. gsi based de-multiplex
(Calvert/Bormann/Vicisano/?)... GSI...
GRA header processing...needs some more analysis...
GRA header has operands - what and where?
(note has a cost..)
whettan:
? does this proposal preclude UDP encapsulation?
e.g. where GRA header is...
speakman answer:
could put after transport header (i.e. UDP)
e.g. end systems deployment
Vicisano:
UDP in this use is a hack. its a "net layer"
so make EDP an exception....
goal: keep arch spec info
make functional spec active...
critical: define tight spec for language...flex v. safe...
so from the lingo being specified, can take it, and define
filter in that mode...
an example will be from authors - other folks Alan roll their own...
in band, need to propagate neighbor info...
have people looking at who can use protocol specs etc...
3/ Track Update
Brian Whetten
-----------------
This has integration plan (with GRA implicit under NORM)
TRACK over UDP/IP for completeness...
(not recommended for general deployment)
separate document over NORM for example instantiation
show:
TRACK/NACK/NORM/GRA/
instantiation/ protocol class hierarchy
candy:
application level confirm delivery;
session parameters;
statistics aggregation
other session stuff? pro: simplicity good; but?
(danger - see RTCP/RTSP/SDP etc)
Handley: watch definition of TFMCC - generic. vs. specific
(e.g. SIGCOMM paper or PGMCC paper?
whettan: ? gave generic answer
speakman:
what do references to NORM mean?
whettan:
NACKS are part of NORM or PGM, not TRACK...
oops = deep sixed on protocol v. class of building block!
adamson/speakman/Handley:- arghh:- implicit v. block
luby:
how does it sit on ALC (instantiation. not building block|)
Crowcroft:
we have a lot of useful stuff here -
need more small group effective understanding
Handley:
yes
speakman:
GRA case:- needs more work...NORM/TRACK/GRA - aggregation
4/ NORM BB draft Update
Brian Adamson
-----------------------
aggregation
nack pieces
GRA pieces
5/ NACK formats
Brian Adamson
-------------------
general purpose NACK encapsulation
made consistent with ALC
relates to FEC technique
e.g. abstract data hierarchy
nack type - has some semantics...
includes something without object, stream, FEC if needed...
presents various NACK forms - including "slack nack")
composite encapsulation:
e.g.of header to show specific segments in stream
Is scope of GRA sufficient to parse general nack format?
- (e.g. lists of layers, missing segments...)
- could use this format for other protocol functions....
such as SACK
speakman:
problem: distance between GRA specification and
NORM spec is too huge
can separate function (structure of id can be opaque)
e.g. sequence+parity count...
Handley:
problem is nack expresses too much -
nack doesn't need to be globally defined
receiver only needs to parse what sender said...
can be session depended
- so long as sender can say to receiver on a session
basis what it meant
speakman: can avoid baroque (elaborate) nack...
kermode: nice structure - but need something more implementable...
adamson need to reach consensus on service model...
may need more than just tony and adamson
kermode: could be closer than we realize
time to move on...
speakman:
omitting discussion on RTT!
debate...
need to think about description of packet for
local..v. global meaning of packet
6/ FEC BB
Lorenzo Vicisano
----------------
removed feedback packet format (NACK) - now in NORM
add id and relative small packet FEC code (see i-d)
object length question: parameters of FEC etc
is it here or somewhere else?
Adamson/Calvert:
sort of seems ok to put here
Luby:
could be de trop...sometimes, and other times need it
- so it's a higher level function...
... ... ... discussion about LCT and ALC...last call
Vicisano & luby both favor that! look forward to tomorrows agenda..
Session #2, Tuesday
===================
0/ Agenda Bashing
1/ Congestion ctl Standardisation Path: Mike Luby
2/ LCT BB Status Report: Mike Luby
3/ ALC BB Update: Mikle Luby
4/ WG overal progress/status report: Roger Kermode
1/ "What is the path for congestion ctl in the WG?"
Mike Luby
----------------------------------------------------
We have several proposals for congestion control
none going quickly to rfc
no quick process to official approval
catch 22 - no approval, no working code, no code, no approval
proposes a process:
perf mustbe shown on basic set of tests....(ns)
real world data prove
experimemntal rfc
provide data to panel for review
panel report to RMT
then becomes a building block
how would we constitute the panel?
it's a long process - can we shorten it/streamline it?
handley:
suspect most people would have (or actually
in real cases in front of RMT have already)
written a paper for the early stage already
doesn't have to be pass/fail
so if we do hit a problem, need a path to revision
Luby:
yes, need to involve rm community
Handley:
need to avoid deadlock on proposed standard for protocol
cross dependance on congestion control bb awaiting approval...
and vice versa
Kermode:
wants to get a fuller set of drafts to cover the ground of RMT
work...
Vicisano: can stage things - say we use "a" congestion control
so there's no link
Handley:
feedback process for congestion control is often associated
with the feedback for reliability, so there's some
Luby:
not true for all protocols tho...
Handley:
with layered scheme, have another problem - dont have an idea
of how much load router can take in terms of group mgmt load
Luby:
yes, need to study that for igmp and pim sparse mode stuff
Handley:
does anyone have a feel for this?
Adamson:
yes, we've done this! have some feel - more a network
than a device problem...
Luby:
can you publish that (and tools to carry out experiments!)
Vicisano:
still need to decide how to proceed.
room is silent...
Kermode:
should try to put a proposal together and do this
decision/resolution on the list
Vicisano:
what is wrong with current approach
(rough consenss and working code?)
Luby:
info needed is greater...
Handley proposed this process:
1. write i-d to say what CC you use
2. write tech report saying what experiments you've done and results
3. make ns (or similar) scripts available for simulation
then put on the list, and see what people say in terms of consensus.
Luby:
environmental factors should be documented too
Kermode:
need the caveats listed too, this is listed in the
author guidelines draft
2/ LCT BB Status Report
Mike Luby
-----------------------
draft was updated from v00 to v01
LCT reminder:
it's a transort control for a session made out of
multiple objects over multiple channels - so CC is over multiple tunnels
Allows unicast or multicast (preferred)
multirate (preferred) or single rate congestion control
Deltas to the i-d are in the draft -
simplifications,
transport object id more prominent, and
variable length now tx & residual time independant
new bits in the header:
for close of object and close of session
More version bits,
header extensions clarified....and structure more logical.
Changed congestion control so bits not ignored.
See i-d for packet header (fixed and optional parts)
Future:
minor revisions - ready to go to rfc after that.
3/ ALC BB Update
Mike Luby
-----------------
draft was updated from v00 to v01
used to use UDP transport, now LCT
- now allows push service, as well as on demnd
- now is a simple combination of
LCT,
FEC and
whatever congestion control
building block (BB) we want (eg. LCC BB)
See i-d for the packet format
Future - minor revisions, then go to RFC.
4/ WG overal progress/status report
Roger Kermode
==========
Slides of all the i-d docs grouped by PI
(Protocol Instantiation) [ see slides ]
NORM, TRACK, ALC, Informational, RFC
and where they are used
We tried something new here (using BBs). How are we doing?
- Getting there, with most drafts started.
- Haven't got one single full protocol
spec submitted quite yet.
Need to have all authors talk to each other
Proposal:
- Interim meeting before next ietf
- could be at ACIRI (offerred in next month or so).
Suggested New Milestones
sep 01 complete autor guidelines
dec 01 protocol instants drafts dpme
dec 01 congestion control
mar 02 remaining PIs done
jun 02 PI drafts submit as proposed standard
jun 02 congestion control drafts submit as proposed standard
Speakman:
need emphasis on implementation
Handley:
yes; need to close gulf between GRA and other pieces
(observed gulf in RMT #1)
Luby:
what does it mean to "implemeny something in a protocol"?
Kermode:
See what people code when they do it from spec independantly
Speakman;
problem for people working from drafts in flux
Vicisano:
so we only need interopability of things at after draft,
only at proposed
Handley;
right we dont need it that strong at this stage
(c.f. proposed milestone update above)
Speakman:
need to see more than one PI use the same BB
So for GRA, we have a lot of references
- but its only the NORM one
We can do now so Adamson & speakman will follow
Handley's remark and talk
So as a BB tho, the GRA could stay as draft until
there's more than one GRA
Luby:
FEC BB will be used in more than
one PI but the timeing is different
Speakman:
hold up standardisation of BB (keep BB as experimental
until we have all BBs used in several PIs.
Kermode:
so as an example - maybe should have the alc and
other pieces go to experimental?
Discussion on process for BBs ensued.
- Consenss was that that experimental means we have
room/flexibility to work on subsequent PIs with
change (stress) to BBs as we would expect
Vicisano:
how does GRA fit the proposed new Milestones?
Speakman:
ok...
--------------E13464A018E6ABEEC64CC57A
Content-Type: text/x-vcard; charset=us-ascii;
name="rkermode.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Roger Kermode
Content-Disposition: attachment;
filename="rkermode.vcf"
begin:vcard
n:Kermode;Roger
tel;cell:+61-408-212-284
tel;fax:+61-2-9666-0501
tel;work:+61-2-9666-0558
x-mozilla-html:FALSE
org:Motorola Labs, Motorola Australia Research Centre;Communications and Networks Laboratory
adr:;;Locked Bag 5028;Botany;NSW;1455;Australia
version:2.1
email;internet:Roger.Kermode@motorola.com
title:Prinicpal Research Engineer / Lab Manager
fn:Roger Kermode
end:vcard
--------------E13464A018E6ABEEC64CC57A--
>From owner-rmt@listserv.lbl.gov Thu Sep 6 23:19:33 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f876JCS13634;
Thu, 6 Sep 2001 23:19:12 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f876JA613630
for <rmt@listserv.lbl.gov>; Thu, 6 Sep 2001 23:19:10 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f876JAD08320
for <rmt@listserv.lbl.gov>; Thu, 6 Sep 2001 23:19:10 -0700 (PDT)
Received: from motgate.mot.com (motgate.mot.com [129.188.136.100])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f876J8608314
for <rmt@lbl.gov>; Thu, 6 Sep 2001 23:19:09 -0700 (PDT)
Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate.mot.com (motgate 2.1) with ESMTP id XAA23753 for <rmt@lbl.gov>; Thu, 6 Sep 2001 23:19:08 -0700 (MST)]
Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id XAA24989 for <rmt@lbl.gov>; Thu, 6 Sep 2001 23:10:49 -0700 (MST)]
Received: from arc.corp.mot.com ([10.238.80.122])
by homer.arc.corp.mot.com (8.11.2/8.11.2) with ESMTP id f876J4A24595
for <rmt@lbl.gov>; Fri, 7 Sep 2001 16:19:04 +1000 (EST)
Message-ID: <3B9866CA.CAD6764B@arc.corp.mot.com>
Date: Fri, 07 Sep 2001 16:18:50 +1000
From: Roger Kermode <rkermode@arc.corp.mot.com>
Organization: Motorola
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: rmt-list <rmt@lbl.gov>
Subject: Correction: 51st IETF Lond RMT Minutes
Content-Type: multipart/mixed;
boundary="------------01AAB6FA32A7A39B33294D17"
Sender: owner-rmt@lbl.gov
Precedence: bulk
This is a multi-part message in MIME format.
--------------01AAB6FA32A7A39B33294D17
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
--------------01AAB6FA32A7A39B33294D17
Content-Type: text/plain; charset=us-ascii;
name="ietf51_rmt_minutes.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="ietf51_rmt_minutes.txt"
Reliable Mulitcast Transport (rmt) WG
51st IETF, London
Minute Taker: Jon Crowcroft <jon@cs.ucl.ac.uk>
Chairs: Roger Kermode <Roger.Kermode@motorola.com>
Lorenzo Vicisano <lorenzo@cisco.com>
Allison Mankin <mankin@isi.edu>
Session 1, Monday
=================
0. Agenda Bashing
1. rccp pi: Mike Luby
2. GRA Update: Tony Speakman
3. TRACK Update: Brian Whettan
4. NORM Update: Brian Adamson
5. NACk format: Brian Adamson
6. FEC BB: Lorenzo Vicisano
1/ Session control protocol discussion
Mike Luby
--------------------------------------
WG need to consider:
style of session, what kind of features will
be needed
pros/cons of:
security/DOS/authentication
firewalls
RMT support
CDI
cons
why not RTSP/sip or other existing protocol?
speakman@mike:
given GRA need session (state setup)
for RMT - hmmm
for multicast in general...could be huge (mmusic)
draft to date is v. large
do we want to customize?
kermode@mike
can we scope the work into mmusic?
colin perkins@mike
outside of mmusic scope
luby:
not clear its out of scope...
braden:
session ctl is for state.
Is this for transport, or for application?
- first is appropriate, rest not.
speakman:
we need it for transport....(including net. elements)...
but what is state?
whettan:
what is session ctl?
e.g. in TRACK its clear (e.g aggregation)
what isn't?
business aggregation, firewall, etc etc,,,
where is the line drawn
bradner:
where was luby draft...? at all
where is cow (given we don't know color to paint it)
to early to say what, but could be in scope -
hard to say right now...
luby:
see draft
Vicisano:
OK get specific and work on plan...
Ken Calvert:
what about relation to to MSEC WG?
answer : TBD
2. GRA Update
Tony Speakman
---------------------
model
GRA is subset of routers
predefined filters
filter = fid+housekeeping/action/subfilter type
e.g . see PGM
lengthy example drawn from PGM...see slides
for actions, headers, etc
GRA schematic header... i-d's, operands
(remember filter ("program") is static in current model
sequence number (i.e.. other packet fields ) are implicit...
need discussion about identifiers
- need 1 (no more) to scope rest of action
1/2 the space of i-d's is for static i-d's
1/2 for dynamic i-d's...(i.e re-programmable)
Question: how long is id?
fixed/var? (var=future)
filter function:
packet accumulation is precluded by GRA
modification is restricted to overwriting GRA fields
i.e. v. limited - reformatting
(e.g. encapsulation/decapsulation) no no no!
operations (e.g. forwarding function:)
e.g. multicast - don't change route (graph?)
e.g. unicast yep - arbitrary...
(w.g. need to get to turning point.)
no (NO) packet generation.
ctl protocol:
in band info ok
out of band administration
Vicisano: what about transport protocol selector
Bormann: isn't it implicit(scoped by net header)
Speakman: only needs to be globally unique or scoped by transport no.
need to decouple transport...
some discussion of protocol v. gsi based de-multiplex
(Calvert/Bormann/Vicisano/?)... GSI...
GRA header processing...needs some more analysis...
GRA header has operands - what and where?
(note has a cost..)
whettan:
? does this proposal preclude UDP encapsulation?
e.g. where GRA header is...
speakman answer:
could put after transport header (i.e. UDP)
e.g. end systems deployment
Vicisano:
UDP in this use is a hack. its a "net layer"
so make EDP an exception....
goal: keep arch spec info
make functional spec active...
critical: define tight spec for language...flex v. safe...
so from the lingo being specified, can take it, and define
filter in that mode...
an example will be from authors - other folks Alan roll their own...
in band, need to propagate neighbor info...
have people looking at who can use protocol specs etc...
3/ Track Update
Brian Whetten
-----------------
This has integration plan (with GRA implicit under NORM)
TRACK over UDP/IP for completeness...
(not recommended for general deployment)
separate document over NORM for example instantiation
show:
TRACK/NACK/NORM/GRA/
instantiation/ protocol class hierarchy
candy:
application level confirm delivery;
session parameters;
statistics aggregation
other session stuff? pro: simplicity good; but?
(danger - see RTCP/RTSP/SDP etc)
Handley: watch definition of TFMCC - generic. vs. specific
(e.g. SIGCOMM paper or PGMCC paper?
whettan: ? gave generic answer
speakman:
what do references to NORM mean?
whettan:
NACKS are part of NORM or PGM, not TRACK...
oops = deep sixed on protocol v. class of building block!
adamson/speakman/Handley:- arghh:- implicit v. block
luby:
how does it sit on ALC (instantiation. not building block|)
Crowcroft:
we have a lot of useful stuff here -
need more small group effective understanding
Handley:
yes
speakman:
GRA case:- needs more work...NORM/TRACK/GRA - aggregation
4/ NORM BB draft Update
Brian Adamson
-----------------------
aggregation
nack pieces
GRA pieces
5/ NACK formats
Brian Adamson
-------------------
general purpose NACK encapsulation
made consistent with ALC
relates to FEC technique
e.g. abstract data hierarchy
nack type - has some semantics...
includes something without object, stream, FEC if needed...
presents various NACK forms - including "slack nack")
composite encapsulation:
e.g.of header to show specific segments in stream
Is scope of GRA sufficient to parse general nack format?
- (e.g. lists of layers, missing segments...)
- could use this format for other protocol functions....
such as SACK
speakman:
problem: distance between GRA specification and
NORM spec is too huge
can separate function (structure of id can be opaque)
e.g. sequence+parity count...
Handley:
problem is nack expresses too much -
nack doesn't need to be globally defined
receiver only needs to parse what sender said...
can be session depended
- so long as sender can say to receiver on a session
basis what it meant
speakman: can avoid baroque (elaborate) nack...
kermode: nice structure - but need something more implementable...
adamson need to reach consensus on service model...
may need more than just tony and adamson
kermode: could be closer than we realize
time to move on...
speakman:
omitting discussion on RTT!
debate...
need to think about description of packet for
local..v. global meaning of packet
6/ FEC BB
Lorenzo Vicisano
----------------
removed feedback packet format (NACK) - now in NORM
add id and relative small packet FEC code (see i-d)
object length question: parameters of FEC etc
is it here or somewhere else?
Adamson/Calvert:
sort of seems ok to put here
Luby:
could be de trop...sometimes, and other times need it
- so it's a higher level function...
... ... ... discussion about LCT and ALC...last call
Vicisano & luby both favor that! look forward to tomorrows agenda..
Session #2, Tuesday
===================
0/ Agenda Bashing
1/ Congestion ctl Standardisation Path: Mike Luby
2/ LCT BB Status Report: Mike Luby
3/ ALC BB Update: Mikle Luby
4/ WG overal progress/status report: Roger Kermode
1/ "What is the path for congestion ctl in the WG?"
Mike Luby
----------------------------------------------------
We have several proposals for congestion control
none going quickly to rfc
no quick process to official approval
catch 22 - no approval, no working code, no code, no approval
proposes a process:
perf mustbe shown on basic set of tests....(ns)
real world data prove
experimemntal rfc
provide data to panel for review
panel report to RMT
then becomes a building block
how would we constitute the panel?
it's a long process - can we shorten it/streamline it?
handley:
suspect most people would have (or actually
in real cases in front of RMT have already)
written a paper for the early stage already
doesn't have to be pass/fail
so if we do hit a problem, need a path to revision
Luby:
yes, need to involve rm community
Handley:
need to avoid deadlock on proposed standard for protocol
cross dependance on congestion control bb awaiting approval...
and vice versa
Kermode:
wants to get a fuller set of drafts to cover the ground of RMT
work...
Vicisano: can stage things - say we use "a" congestion control
so there's no link
Handley:
feedback process for congestion control is often associated
with the feedback for reliability, so there's some
Luby:
not true for all protocols tho...
Handley:
with layered scheme, have another problem - dont have an idea
of how much load router can take in terms of group mgmt load
Luby:
yes, need to study that for igmp and pim sparse mode stuff
Handley:
does anyone have a feel for this?
Adamson:
yes, we've done this! have some feel - more a network
than a device problem...
Luby:
can you publish that (and tools to carry out experiments!)
Vicisano:
still need to decide how to proceed.
room is silent...
Kermode:
should try to put a proposal together and do this
decision/resolution on the list
Vicisano:
what is wrong with current approach
(rough consenss and working code?)
Luby:
info needed is greater...
Handley proposed this process:
1. write i-d to say what CC you use
2. write tech report saying what experiments you've done and results
3. make ns (or similar) scripts available for simulation
then put on the list, and see what people say in terms of consensus.
Luby:
environmental factors should be documented too
Kermode:
need the caveats listed too, this is listed in the
author guidelines draft
2/ LCT BB Status Report
Mike Luby
-----------------------
draft was updated from v00 to v01
LCT reminder:
it's a transort control for a session made out of
multiple objects over multiple channels - so CC is over multiple tunnels
Allows unicast or multicast (preferred)
multirate (preferred) or single rate congestion control
Deltas to the i-d are in the draft -
simplifications,
transport object id more prominent, and
variable length now tx & residual time independant
new bits in the header:
for close of object and close of session
More version bits,
header extensions clarified....and structure more logical.
Changed congestion control so bits not ignored.
See i-d for packet header (fixed and optional parts)
Future:
minor revisions - ready to go to rfc after that.
3/ ALC BB Update
Mike Luby
-----------------
draft was updated from v00 to v01
used to use UDP transport, now LCT
- now allows push service, as well as on demnd
- now is a simple combination of
LCT,
FEC and
whatever congestion control
building block (BB) we want (eg. LCC BB)
See i-d for the packet format
Future - minor revisions, then go to RFC.
4/ WG overal progress/status report
Roger Kermode
==========
Slides of all the i-d docs grouped by PI
(Protocol Instantiation) [ see slides ]
NORM, TRACK, ALC, Informational, RFC
and where they are used
We tried something new here (using BBs). How are we doing?
- Getting there, with most drafts started.
- Haven't got one single full protocol
spec submitted quite yet.
Need to have all authors talk to each other
Proposal:
- Interim meeting before next ietf
- could be at ACIRI (offerred in next month or so).
Suggested New Milestones
sep 01 complete autor guidelines
dec 01 protocol instants drafts dpme
dec 01 congestion control
mar 02 remaining PIs done
jun 02 PI drafts submit as proposed standard
jun 02 congestion control drafts submit as proposed standard
Speakman:
need emphasis on implementation
Handley:
yes; need to close gulf between GRA and other pieces
(observed gulf in RMT #1)
Luby:
what does it mean to "implemeny something in a protocol"?
Kermode:
See what people code when they do it from spec independantly
Speakman;
problem for people working from drafts in flux
Vicisano:
so we only need interopability of things at after draft,
only at proposed
Handley;
right we dont need it that strong at this stage
(c.f. proposed milestone update above)
Speakman:
need to see more than one PI use the same BB
So for GRA, we have a lot of references
- but its only the NORM one
We can do now so Adamson & speakman will follow
Handley's remark and talk
So as a BB tho, the GRA could stay as draft until
there's more than one GRA
Luby:
FEC BB will be used in more than
one PI but the timeing is different
Speakman:
hold up standardisation of BB (keep BB as experimental
until we have all BBs used in several PIs.
Kermode:
so as an example - maybe should have the alc and
other pieces go to experimental?
Discussion on process for BBs ensued.
- Consenss was that that experimental means we have
room/flexibility to work on subsequent PIs with
change (stress) to BBs as we would expect
Vicisano:
how does GRA fit the proposed new Milestones?
Speakman:
ok...
--------------01AAB6FA32A7A39B33294D17
Content-Type: text/x-vcard; charset=us-ascii;
name="rkermode.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Roger Kermode
Content-Disposition: attachment;
filename="rkermode.vcf"
begin:vcard
n:Kermode;Roger
tel;cell:+61-408-212-284
tel;fax:+61-2-9666-0501
tel;work:+61-2-9666-0558
x-mozilla-html:FALSE
org:Motorola Labs, Motorola Australia Research Centre;Communications and Networks Laboratory
adr:;;Locked Bag 5028;Botany;NSW;1455;Australia
version:2.1
email;internet:Roger.Kermode@motorola.com
title:Prinicpal Research Engineer / Lab Manager
fn:Roger Kermode
end:vcard
--------------01AAB6FA32A7A39B33294D17--
>From owner-rmt@listserv.lbl.gov Sun Sep 9 15:18:58 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f89MEiM15887;
Sun, 9 Sep 2001 15:14:44 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f89MEgq15883
for <rmt@listserv.lbl.gov>; Sun, 9 Sep 2001 15:14:42 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f89MEgc26087
for <rmt@listserv.lbl.gov>; Sun, 9 Sep 2001 15:14:42 -0700 (PDT)
Received: from cisco.com (cypher.cisco.com [171.69.11.18])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f89MEf626084
for <rmt@lbl.gov>; Sun, 9 Sep 2001 15:14:41 -0700 (PDT)
Received: from localhost (speakman@localhost)
by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id PAA07933;
Sun, 9 Sep 2001 15:14:35 -0700 (PDT)
Message-Id: <200109092214.PAA07933@cisco.com>
To: Roger Kermode <rkermode@arc.corp.mot.com>
cc: rmt-list <rmt@lbl.gov>, Scott Bradner <sob@harvard.edu>
Subject: Re: RMT Milestone update: DATE REQUEST
Mime-Version: 1.0 (generated by tm-edit 7.105)
Content-Type: text/plain; charset=US-ASCII
Date: Sun, 09 Sep 2001 15:14:35 -0700
From: Tony Speakman <speakman@cisco.com>
Sender: owner-rmt@lbl.gov
Precedence: bulk
Hmmm, I don't see any building block drafts, or
are those what you call the CC drafts? In any
case, I think it makes sense to publish from the
bottom up, i.e., starting with building block
drafts and let them mature a bit before publishing
the PIs which are supposed to be constructed from
those BBs. (I think I made the same point in the
WG, and the response was that experimentals are
revisable, so publication order doesn't matter,
which I was only weakly convinced of).
Are you going to reflect the discussion we had in
London about the requirements on these drafts,
specifically that for the PIs there be working
implementations, and for the CCs there be simulation
results and applicability statements?
On the topic of GRA, we described three documents
all of which I think are "building blocks":
a filter language spec, filter definition specs,
and a GRA protocol spec. Swapna and I are working
on the latter and expect to present it in December
with the goal of prototyping an implementation and
revising the draft for last call by March.
To write filter specs, we need the filter language
spec which Ken Calvert is drafting.
So I think your list would make more sense if it
named specific drafts, the requirements on them,
and any publication dependencies.
Tony S
> Suggested Milestones
> --------------------
>
> Sep 01 Complete Author Guidelines draft WGLC
> submit for publication as informational.
>
> Dec 01 Protocol instantiations drafts submitted
> for publication as experimental. Which ones?
>
> Dec 01 Congestion control drafts submitted for
> publication as experimental.
>
> Mar 02 Remaining Protocol instantiations drafts
> submitted for publication as experimental.
> Which ones?
>
> Jun 02 Protocol instantiations drafts submitted
> for publication as proposed standard.
>
> Jun 02 Congestion control drafts submitted for
> publication as proposed standard.
>From owner-rmt@listserv.lbl.gov Fri Sep 21 06:48:23 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f8LDesv27455;
Fri, 21 Sep 2001 06:40:54 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f8LDerq27451
for <rmt@listserv.lbl.gov>; Fri, 21 Sep 2001 06:40:53 -0700 (PDT)
Received: from localhost (root@localhost)
by postal1.lbl.gov (8.11.2/8.11.2) with SMTP id f8LDer618755
for <rmt@listserv.lbl.gov>; Fri, 21 Sep 2001 06:40:53 -0700 (PDT)
Date: Fri, 21 Sep 2001 06:40:53 -0700 (PDT)
Message-Id: <200109211340.f8LDer618755@postal1.lbl.gov>
From: VirusWall@lbl.gov
To: rmt@listserv.lbl.gov
Subject: Virus Alert
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-rmt@lbl.gov
Precedence: bulk
This is an automated message from the LBNL VirusWall.
The mail message you recently received from: jesus@prodigy.net.mx
which included the file: Doc1.doc.bat
contained the virus: TROJ_SIRCAM.A.
PLEASE NOTE:
1. The virus has been REMOVED from the email message by the LBNL VirusWall
and will NOT INFECT your computer.
2. It is SAFE to read the message and open the attachment, though you should
always use caution when opening attachments from people you do not know.
3. You do not need to notify anyone that you received this message.
For more information take a look at our virus protection web page:
http://www.lbl.gov/ITSD/Security/resources/
If you have any questions, please contact the LBNL Help Desk
at http://www.lbl.gov/help/, or 510-486-4357.
Thanks,
The VirusWall
Lawrence Berkeley National Laboratory
>From owner-rmt@listserv.lbl.gov Fri Sep 21 06:48:23 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f8LDeml27449;
Fri, 21 Sep 2001 06:40:48 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f8LDekq27445
for <rmt@listserv.lbl.gov>; Fri, 21 Sep 2001 06:40:46 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f8LDejo18716
for <rmt@listserv.lbl.gov>; Fri, 21 Sep 2001 06:40:45 -0700 (PDT)
Received: from aykran.upc.es (aykran.upc.es [147.83.21.28])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f8LDeg618713
for <rmt@lbl.gov>; Fri, 21 Sep 2001 06:40:42 -0700 (PDT)
Message-Id: <200109211340.f8LDeg618713@SpamWall.lbl.gov>
Received: from pcgcr26.upc.es ([147.83.105.158]) by aykran.upc.es with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
id T247H2HF; Fri, 21 Sep 2001 15:36:36 +0200
From: "jesus"<jesus@prodigy.net.mx>
To: rmt@lbl.gov
Subject: Doc1
date: Fri, 21 Sep 2001 15:37:47 +0200
MIME-Version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
Content-Type: multipart/mixed; boundary="----42E8350B_Outlook_Express_message_boundary"
Content-Disposition: Multipart message
Sender: owner-rmt@lbl.gov
Precedence: bulk
------42E8350B_Outlook_Express_message_boundary
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
****************** Virus Warning Message (on the network)
Found virus TROJ_SIRCAM.A in file Doc1.doc.bat
The file e/iscan/virus/virXHAdNaGdK is moved to the configured virus directory.
*********************************************************
------42E8350B_Outlook_Express_message_boundary
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: message text
Hola como estas =3F
Te mando este archivo para que me des tu punto de vista
Nos vemos pronto=2C gracias=2E
------42E8350B_Outlook_Express_message_boundary
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
****************** Virus Warning Message (on the network)
Doc1.doc.bat is removed from here because it contains a virus.
*********************************************************
------42E8350B_Outlook_Express_message_boundary
------42E8350B_Outlook_Express_message_boundary--
>From owner-rmt@listserv.lbl.gov Mon Sep 24 02:43:20 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f8O9eBu02793;
Mon, 24 Sep 2001 02:40:11 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f8O9eAq02789
for <rmt@listserv.lbl.gov>; Mon, 24 Sep 2001 02:40:10 -0700 (PDT)
Received: from localhost (root@localhost)
by postal1.lbl.gov (8.11.2/8.11.2) with SMTP id f8O9e9h05162
for <rmt@listserv.lbl.gov>; Mon, 24 Sep 2001 02:40:09 -0700 (PDT)
Date: Mon, 24 Sep 2001 02:40:09 -0700 (PDT)
Message-Id: <200109240940.f8O9e9h05162@postal1.lbl.gov>
From: VirusWall@lbl.gov
To: rmt@listserv.lbl.gov
Subject: Virus Alert
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-rmt@lbl.gov
Precedence: bulk
This is an automated message from the LBNL VirusWall.
The mail message you recently received from: jesus@prodigy.net.mx
which included the file: Doc2.doc.com
contained the virus: TROJ_SIRCAM.A.
PLEASE NOTE:
1. The virus has been REMOVED from the email message by the LBNL VirusWall
and will NOT INFECT your computer.
2. It is SAFE to read the message and open the attachment, though you should
always use caution when opening attachments from people you do not know.
3. You do not need to notify anyone that you received this message.
For more information take a look at our virus protection web page:
http://www.lbl.gov/ITSD/Security/resources/
If you have any questions, please contact the LBNL Help Desk
at http://www.lbl.gov/help/, or 510-486-4357.
Thanks,
The VirusWall
Lawrence Berkeley National Laboratory
>From owner-rmt@listserv.lbl.gov Mon Sep 24 02:43:20 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f8O9e9t02787;
Mon, 24 Sep 2001 02:40:09 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f8O9e8q02783
for <rmt@listserv.lbl.gov>; Mon, 24 Sep 2001 02:40:08 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f8O9e7u05155
for <rmt@listserv.lbl.gov>; Mon, 24 Sep 2001 02:40:07 -0700 (PDT)
Received: from aykran.upc.es (aykran.upc.es [147.83.21.28])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f8O9e3605152
for <rmt@lbl.gov>; Mon, 24 Sep 2001 02:40:04 -0700 (PDT)
Message-Id: <200109240940.f8O9e3605152@SpamWall.lbl.gov>
Received: from pcgcr26.upc.es ([147.83.105.158]) by aykran.upc.es with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
id T247HP8M; Mon, 24 Sep 2001 11:36:00 +0200
From: "jesus"<jesus@prodigy.net.mx>
To: rmt@lbl.gov
Subject: Doc2
date: Mon, 24 Sep 2001 11:36:51 +0200
MIME-Version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
Content-Type: multipart/mixed; boundary="----327F0ECE_Outlook_Express_message_boundary"
Content-Disposition: Multipart message
Sender: owner-rmt@lbl.gov
Precedence: bulk
------327F0ECE_Outlook_Express_message_boundary
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
****************** Virus Warning Message (on the network)
Found virus TROJ_SIRCAM.A in file Doc2.doc.com
The file e/iscan/virus/virWHD_Ua4DS is moved to the configured virus directory.
*********************************************************
------327F0ECE_Outlook_Express_message_boundary
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: message text
Hola como estas =3F
Te mando este archivo para que me des tu punto de vista
Nos vemos pronto=2C gracias=2E
------327F0ECE_Outlook_Express_message_boundary
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
****************** Virus Warning Message (on the network)
Doc2.doc.com is removed from here because it contains a virus.
*********************************************************
------327F0ECE_Outlook_Express_message_boundary
------327F0ECE_Outlook_Express_message_boundary--
>From owner-rmt@listserv.lbl.gov Wed Sep 26 21:42:48 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f8R4SJL12639;
Wed, 26 Sep 2001 21:28:19 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f8R4SHq12635
for <rmt@listserv.lbl.gov>; Wed, 26 Sep 2001 21:28:17 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f8R4SHs27683
for <rmt@listserv.lbl.gov>; Wed, 26 Sep 2001 21:28:17 -0700 (PDT)
Received: from chapweske.com (nic-41-c31-11.mn.mediaone.net [66.41.31.11])
by SpamWall.lbl.gov (8.11.2/8.11.2) with SMTP id f8R4SG627680
for <rmt@lbl.gov>; Wed, 26 Sep 2001 21:28:16 -0700 (PDT)
Received: (qmail 14179 invoked from network); 26 Sep 2001 23:44:40 -0000
Received: from unknown (HELO chapweske.com) (192.168.0.2)
by 192.168.0.3 with SMTP; 26 Sep 2001 23:44:40 -0000
Message-ID: <3BB2AABE.8070006@chapweske.com>
Date: Wed, 26 Sep 2001 23:27:42 -0500
From: Justin Chapweske <justin@chapweske.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3) Gecko/20010801
X-Accept-Language: en-us
MIME-Version: 1.0
To: rmt@lbl.gov
Subject: Java FEC Library Changes Maintainers
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-rmt@lbl.gov
Precedence: bulk
The Java Forward Error Correction (FEC) Library has grown beyond its
Swarmcast beginnings and is now being maintained by Onion Networks
(http://onionnetworks.com/). FEC is an essential component of any
reliable multicast solution, and this library is the fastest and most
mature Java solution available. It features:
* Fast multi-threaded I/O routines for encoding and decoding files
* Native linux, solaris, and win32 accellerators with pure Java fallback
* Automatic deployment of native accellerators
* FEC codec plugin interface
* Cryptograhic hashes can be used for checking file integrity
The library is based on Luigi Rizzo's original C FEC library, and is
under a BSD-style license.
The library can be found at http://onionnetworks.com/components.html and
commercial support from Onion Networks is available.
Thanks,
--
Justin Chapweske, Onion Networks
http://onionnetworks.com/
>From owner-rmt@listserv.lbl.gov Mon Oct 1 03:26:13 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f91ALt917877;
Mon, 1 Oct 2001 03:21:55 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f91ALrq17873
for <rmt@listserv.lbl.gov>; Mon, 1 Oct 2001 03:21:53 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f91ALr423103
for <rmt@listserv.lbl.gov>; Mon, 1 Oct 2001 03:21:53 -0700 (PDT)
Received: from gandalf.axion.bt.co.uk (gandalf.axion.bt.co.uk [132.146.17.29])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f91ALp623098
for <rmt@lbl.gov>; Mon, 1 Oct 2001 03:21:52 -0700 (PDT)
Received: from cbtlipnt01.btlabs.bt.co.uk by gandalf (local) with ESMTP;
Mon, 1 Oct 2001 11:21:01 +0100
Received: by cbtlipnt01.btlabs.bt.co.uk
with Internet Mail Service (5.5.2652.35) id <S42B4L0Z>;
Mon, 1 Oct 2001 11:20:57 +0100
Message-ID: <B76B75D34ACFD31180A600606DDFE79B08A5AE7C@mbtlipnt04.btlabs.bt.co.uk>
From: maziar.nekovee@bt.com
To: rmt@lbl.gov
Subject: measuremets/simulations of delay times
Date: Mon, 1 Oct 2001 11:17:38 +0100
X-Mailer: Internet Mail Service (5.5.2652.35)
MIME-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"
Sender: owner-rmt@lbl.gov
Precedence: bulk
Dear all
I am interested to find out about any available measurements/simulation
results for
delay times (and their statistical distributions) in reliable multicast (for
large groups).
I'd be grateful for any help.
Best regards
Maziar Nekovee
----------------------------
Dr Maziar Nekovee
Complexity Research Group
Admin2, pp5
BT Laboratories
Martlesham Heath, Ipswich
Suffolk IP5 3RE, UK
tel: +44-1473 645470
fax: +44-1473-647410
web: www.labs.bt.com/projects/complexity/nekovee/
>From owner-rmt@listserv.lbl.gov Mon Oct 1 10:05:12 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f91H2iZ28772;
Mon, 1 Oct 2001 10:02:44 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f91H2hq28768
for <rmt@listserv.lbl.gov>; Mon, 1 Oct 2001 10:02:43 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f91H2g720953
for <rmt@listserv.lbl.gov>; Mon, 1 Oct 2001 10:02:42 -0700 (PDT)
Received: from mx.webfountain.com (mx.digitalfountain.com [209.219.233.39])
by SpamWall.lbl.gov (8.11.2/8.11.2) with SMTP id f91H2g620943
for <rmt@lbl.gov>; Mon, 1 Oct 2001 10:02:42 -0700 (PDT)
Received: (qmail 3341 invoked from network); 1 Oct 2001 16:59:53 -0000
Received: from mail.intranet (10.1.1.37)
by mx.digitalfountain.com with SMTP; 1 Oct 2001 16:59:53 -0000
Received: from mikedell (pptp-10-1-129-51.intranet [10.1.129.51])
by mail.intranet (8.9.3/8.9.3) with SMTP id JAA10225;
Mon, 1 Oct 2001 09:59:27 -0700
X-Authentication-Warning: mail.intranet: Host pptp-10-1-129-51.intranet [10.1.129.51] claimed to be mikedell
From: "Michael Luby" <luby@digitalfountain.com>
To: <maziar.nekovee@bt.com>, <rmt@lbl.gov>
Subject: RE: measuremets/simulations of delay times
Date: Mon, 1 Oct 2001 09:59:59 -0700
Message-ID: <NEBBIAPCNKEDCLPNFBNCAEHECHAA.luby@digitalfountain.com>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
In-Reply-To: <B76B75D34ACFD31180A600606DDFE79B08A5AE7C@mbtlipnt04.btlabs.bt.co.uk>
Sender: owner-rmt@lbl.gov
Precedence: bulk
How do you define "delay time"?
-----Original Message-----
From: owner-rmt@lbl.gov [mailto:owner-rmt@lbl.gov]On Behalf Of
maziar.nekovee@bt.com
Sent: Monday, October 01, 2001 3:18 AM
To: rmt@lbl.gov
Subject: measuremets/simulations of delay times
Dear all
I am interested to find out about any available measurements/simulation
results for
delay times (and their statistical distributions) in reliable multicast (for
large groups).
I'd be grateful for any help.
Best regards
Maziar Nekovee
----------------------------
Dr Maziar Nekovee
Complexity Research Group
Admin2, pp5
BT Laboratories
Martlesham Heath, Ipswich
Suffolk IP5 3RE, UK
tel: +44-1473 645470
fax: +44-1473-647410
web: www.labs.bt.com/projects/complexity/nekovee/
>From owner-rmt@listserv.lbl.gov Fri Oct 5 19:33:59 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f962TuA27590;
Fri, 5 Oct 2001 19:29:56 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f962Tsp27586
for <rmt@listserv.lbl.gov>; Fri, 5 Oct 2001 19:29:54 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f962Tsj25041
for <rmt@listserv.lbl.gov>; Fri, 5 Oct 2001 19:29:54 -0700 (PDT)
Received: from chapweske.com (nic-41-c31-11.mn.mediaone.net [66.41.31.11])
by SpamWall.lbl.gov (8.11.2/8.11.2) with SMTP id f962Tq625036
for <rmt@lbl.gov>; Fri, 5 Oct 2001 19:29:53 -0700 (PDT)
Received: (qmail 22056 invoked from network); 6 Oct 2001 02:45:12 -0000
Received: from unknown (HELO onionnetworks.com) (192.168.0.2)
by 192.168.0.3 with SMTP; 6 Oct 2001 02:45:12 -0000
Message-ID: <3BBE6C2C.70505@onionnetworks.com>
Date: Fri, 05 Oct 2001 21:27:56 -0500
From: Justin Chapweske <justin@onionnetworks.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3) Gecko/20010801
X-Accept-Language: en-us
MIME-Version: 1.0
To: rmt@lbl.gov
Subject: ALC
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-rmt@lbl.gov
Precedence: bulk
Hey gang,
I just read the new ALC spec and it seems to be a vacuous document to
me. What value does this protocol add beyond what the LCT protocol
provides?
Thanks,
--
Justin Chapweske, Onion Networks
http://onionnetworks.com/
>From owner-rmt@listserv.lbl.gov Fri Oct 5 19:52:49 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f962p7o27695;
Fri, 5 Oct 2001 19:51:07 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f962p6p27691
for <rmt@listserv.lbl.gov>; Fri, 5 Oct 2001 19:51:06 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f962p5u26619
for <rmt@listserv.lbl.gov>; Fri, 5 Oct 2001 19:51:05 -0700 (PDT)
Received: from mx.webfountain.com (mx.digitalfountain.com [209.219.233.39])
by SpamWall.lbl.gov (8.11.2/8.11.2) with SMTP id f962p4626616
for <rmt@lbl.gov>; Fri, 5 Oct 2001 19:51:04 -0700 (PDT)
Received: (qmail 18792 invoked from network); 6 Oct 2001 02:50:58 -0000
Received: from mail.intranet (10.1.1.37)
by mx.digitalfountain.com with SMTP; 6 Oct 2001 02:50:58 -0000
Received: from mikedell (pptp-10-1-129-51.intranet [10.1.129.51])
by mail.intranet (8.9.3/8.9.3) with SMTP id TAA23859;
Fri, 5 Oct 2001 19:50:31 -0700
X-Authentication-Warning: mail.intranet: Host pptp-10-1-129-51.intranet [10.1.129.51] claimed to be mikedell
From: "Michael Luby" <luby@digitalfountain.com>
To: "Justin Chapweske" <justin@onionnetworks.com>
Cc: "Michael Luby" <luby@digitalfountain.com>, <rmt@lbl.gov>
Subject: RE: ALC
Date: Fri, 5 Oct 2001 19:51:14 -0700
Message-ID: <NEBBIAPCNKEDCLPNFBNCEEHICHAA.luby@digitalfountain.com>
MIME-Version: 1.0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <3BBE6C2C.70505@onionnetworks.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-rmt@lbl.gov
Precedence: bulk
Justin,
LCT is not a protocol, it is a building block that could be used to build
any number of other protocols as a building block. And, it can be used as
the general session framework for a variety of other protocols, including
but not limited to on-demand streaming, reliable content delivery of objects
and live streaming. Each such complete protocol will potentially use a
different reliability building block, and a different congestion control
building block, in addition to LCT.
ALC is a protocol instantiation, that in particular is a simple combination
of the LCT building block as the general session framework, FEC with no
feedback to the sender as the reliability building block, and a multi-rate
building block using multiple channels that is TCP-friendly and requires no
feedback to the sender as the congestion control (yet to be completely
specified). Furthermore, ALC is specifically targeted for reliable content
delivery of objects.
You may call ALC vacuous. I call it a good combination of three
well-designed building blocks that fit nicely together, as they are supposed
to.
Mike
-----Original Message-----
From: owner-rmt@lbl.gov [mailto:owner-rmt@lbl.gov]On Behalf Of Justin
Chapweske
Sent: Friday, October 05, 2001 7:28 PM
To: rmt@lbl.gov
Subject: ALC
Hey gang,
I just read the new ALC spec and it seems to be a vacuous document to
me. What value does this protocol add beyond what the LCT protocol
provides?
Thanks,
--
Justin Chapweske, Onion Networks
http://onionnetworks.com/
>From owner-rmt@listserv.lbl.gov Fri Oct 5 21:19:50 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f964Hsh28212;
Fri, 5 Oct 2001 21:17:54 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f964Hrp28208
for <rmt@listserv.lbl.gov>; Fri, 5 Oct 2001 21:17:53 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f964HqC03628
for <rmt@listserv.lbl.gov>; Fri, 5 Oct 2001 21:17:52 -0700 (PDT)
Received: from chapweske.com (nic-41-c31-11.mn.mediaone.net [66.41.31.11])
by SpamWall.lbl.gov (8.11.2/8.11.2) with SMTP id f964Hq603625
for <rmt@lbl.gov>; Fri, 5 Oct 2001 21:17:52 -0700 (PDT)
Received: (qmail 22284 invoked from network); 6 Oct 2001 04:33:11 -0000
Received: from unknown (HELO onionnetworks.com) (192.168.0.2)
by 192.168.0.3 with SMTP; 6 Oct 2001 04:33:11 -0000
Message-ID: <3BBE857C.8030304@onionnetworks.com>
Date: Fri, 05 Oct 2001 23:15:56 -0500
From: Justin Chapweske <justin@onionnetworks.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3) Gecko/20010801
X-Accept-Language: en-us
MIME-Version: 1.0
To: rmt@lbl.gov
Subject: Re: ALC
References: <NEBBIAPCNKEDCLPNFBNCEEHICHAA.luby@digitalfountain.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-rmt@lbl.gov
Precedence: bulk
Michael,
Thanks for the clarification. I think you guys have created here, some
of the best designed protocols the IETF has to offer. What tripped me
up is that ALC used to be a building block but has since been turned
into an instantiation. Thus my usage of 'vacuous' was simply personal
contextual baggage and meant no offense.
Thanks,
--
Justin Chapweske, Onion Networks
http://onionnetworks.com/
Michael Luby wrote:
>Justin,
>
>LCT is not a protocol, it is a building block that could be used to build
>any number of other protocols as a building block. And, it can be used as
>the general session framework for a variety of other protocols, including
>but not limited to on-demand streaming, reliable content delivery of
objects
>and live streaming. Each such complete protocol will potentially use a
>different reliability building block, and a different congestion control
>building block, in addition to LCT.
>
>ALC is a protocol instantiation, that in particular is a simple
combination
>of the LCT building block as the general session framework, FEC with no
>feedback to the sender as the reliability building block, and a multi-rate
>building block using multiple channels that is TCP-friendly and
requires no
>feedback to the sender as the congestion control (yet to be completely
>specified). Furthermore, ALC is specifically targeted for reliable
content
>delivery of objects.
>
>You may call ALC vacuous. I call it a good combination of three
>well-designed building blocks that fit nicely together, as they are
supposed
>to.
>
>Mike
>
>-----Original Message-----
>From: owner-rmt@lbl.gov [mailto:owner-rmt@lbl.gov]On Behalf Of Justin
>Chapweske
>Sent: Friday, October 05, 2001 7:28 PM
>To: rmt@lbl.gov
>Subject: ALC
>
>
>Hey gang,
>
>I just read the new ALC spec and it seems to be a vacuous document to
>me. What value does this protocol add beyond what the LCT protocol
>provides?
>
>Thanks,
>
>--
>Justin Chapweske, Onion Networks
>http://onionnetworks.com/
>
>From owner-rmt@listserv.lbl.gov Sat Oct 6 21:05:10 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f97412S17716;
Sat, 6 Oct 2001 21:01:02 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f97410p17707
for <rmt@listserv.lbl.gov>; Sat, 6 Oct 2001 21:01:00 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f9740xj11704
for <rmt@listserv.lbl.gov>; Sat, 6 Oct 2001 21:00:59 -0700 (PDT)
Received: from imses2.ims-cpm.ru (imses2.ims-cpm.ru [195.16.59.38])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f9740w611700
for <rmt@lbl.gov>; Sat, 6 Oct 2001 21:00:58 -0700 (PDT)
Received: from unspecified.host (ims-srv.84.quantum.ru [213.170.84.146]) by imses2.ims-cpm.ru with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
id 4JQXLQQB; Sun, 7 Oct 2001 07:42:31 +0400
Received: from 168.191.177.137 ([168.191.177.137]) by 213.170.84.146 (WinRoute Pro 4.1.25) with SMTP; Sun, 7 Oct 2001 07:41:03 +0400
Message-ID: <000041f56a5b$00001c05$00001e51@>
To: <Undisclosed.Recipients@postal1.lbl.gov>
From: gayle65@aemail4u.com
Subject: Tired of Outrageous LD bills-2.9 cents per min!
Date: Sat, 06 Oct 2001 22:22:50 -0500
X-Priority: 1
X-MSMail-Priority: High
Sender: owner-rmt@lbl.gov
Precedence: bulk
* * * * * * * For The First Time in Telecom History * * * * * * *
* * * * * * * You Can Have Your Cake and Eat It Too! * * * * * *
* * * * * * * * * * * The Best of Both Worlds! * * * * * * * * * *
* * * * * * * * 2.9 Cents per Minute Long Distance * * * * * * * * *
OR
* * * * * * * UNLIMITED FLAT RATE LONG DISTANCE * * * * * * * *
******************** YOU MAKE THE CALL! **********************
No Credit Check! No Contracts or long Term Obligations! No More
"Local Long Distance" Calling! No Fine Print, or Hidden Fees!
No Changing Carriers! Just TALK as much as you want with these
incredible low rates 2.9 cents a minute or Flate Rate
* * * * * * * * * * * ABSOLUTELY NO GIMMICKS * * * * * * * * * *
* * * * * * * * * * * ACTIVATION IN 48 HOURS * * * * * * * * * *
FOR MORE INFORMATION: on our 2.9 cents a minute Long Distance
OR our Unlimited Long Distance click on the hyperlink below and
mailto: bestinflatrate@yahoo.com.=Type more info in the subjct box.
To unsubscribe:ilike2_9_ld@yahoo.com
>From owner-rmt@listserv.lbl.gov Wed Oct 10 00:18:30 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f9A7ECP20652;
Wed, 10 Oct 2001 00:14:12 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f9A7EAp20648
for <rmt@listserv.lbl.gov>; Wed, 10 Oct 2001 00:14:10 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f9A7EA429881
for <rmt@listserv.lbl.gov>; Wed, 10 Oct 2001 00:14:10 -0700 (PDT)
Received: from chapweske.com (nic-41-c31-11.mn.mediaone.net [66.41.31.11])
by SpamWall.lbl.gov (8.11.2/8.11.2) with SMTP id f9A7E9729878
for <rmt@lbl.gov>; Wed, 10 Oct 2001 00:14:09 -0700 (PDT)
Received: (qmail 32758 invoked from network); 10 Oct 2001 06:41:13 -0000
Received: from unknown (HELO onionnetworks.com) (192.168.0.2)
by 192.168.0.3 with SMTP; 10 Oct 2001 06:41:13 -0000
Message-ID: <3BC3E941.3010705@onionnetworks.com>
Date: Wed, 10 Oct 2001 01:22:57 -0500
From: Justin Chapweske <justin@onionnetworks.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3) Gecko/20010801
X-Accept-Language: en-us
MIME-Version: 1.0
To: rmt@lbl.gov
Subject: Last Header Extension
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-rmt@lbl.gov
Precedence: bulk
Hello,
What benefit does the Last Header Extension bit add when one can use the
HDR_LEN field to determine when the header extensions are done?
It might be nice to remove the Last Header Extension bit and make Header
Extension Type an 8 bit field.
Its just a suggestion, I don't feel strongly about it one way or the other.
Thanks,
--
Justin Chapweske, Onion Networks
http://onionnetworks.com/
>From owner-rmt@listserv.lbl.gov Wed Oct 10 12:00:45 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f9AIwC000105;
Wed, 10 Oct 2001 11:58:12 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f9AIwAp00101
for <rmt@listserv.lbl.gov>; Wed, 10 Oct 2001 11:58:10 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f9AIw9O12920
for <rmt@listserv.lbl.gov>; Wed, 10 Oct 2001 11:58:09 -0700 (PDT)
Received: from mx.webfountain.com (mx.digitalfountain.com [209.219.233.39])
by SpamWall.lbl.gov (8.11.2/8.11.2) with SMTP id f9AIw8712908
for <rmt@lbl.gov>; Wed, 10 Oct 2001 11:58:08 -0700 (PDT)
Received: (qmail 22911 invoked from network); 10 Oct 2001 18:58:03 -0000
Received: from mail.intranet (10.1.1.37)
by mx.digitalfountain.com with SMTP; 10 Oct 2001 18:58:03 -0000
Received: from bozz (dhcp-10-1-2-180.intranet [10.1.2.180])
by mail.intranet (8.9.3/8.9.3) with SMTP id LAA07623;
Wed, 10 Oct 2001 11:57:36 -0700
X-Authentication-Warning: mail.intranet: Host dhcp-10-1-2-180.intranet [10.1.2.180] claimed to be bozz
From: "Michael Luby" <luby@digitalfountain.com>
To: "Justin Chapweske" <justin@onionnetworks.com>, <rmt@lbl.gov>
Cc: "Michael Luby" <luby@digitalfountain.com>
Subject: RE: Last Header Extension
Date: Wed, 10 Oct 2001 12:03:31 -0700
Message-ID: <NEBBIAPCNKEDCLPNFBNCAEJKCHAA.luby@digitalfountain.com>
MIME-Version: 1.0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <3BC3E941.3010705@onionnetworks.com>
Sender: owner-rmt@lbl.gov
Precedence: bulk
Justin,
Interesting suggestion (Assuming you are talking about the LCT BB). Yes,
there are two ways to determine the end of the header right now, one through
the "next extension header exists bit" and one through the "total length of
the header field". Not clear we need both. I'd be happy with what you
suggest.
Mike
-----Original Message-----
From: owner-rmt@lbl.gov [mailto:owner-rmt@lbl.gov]On Behalf Of Justin
Chapweske
Sent: Tuesday, October 09, 2001 11:23 PM
To: rmt@lbl.gov
Subject: Last Header Extension
Hello,
What benefit does the Last Header Extension bit add when one can use the
HDR_LEN field to determine when the header extensions are done?
It might be nice to remove the Last Header Extension bit and make Header
Extension Type an 8 bit field.
Its just a suggestion, I don't feel strongly about it one way or the other.
Thanks,
--
Justin Chapweske, Onion Networks
http://onionnetworks.com/
>From owner-rmt@listserv.lbl.gov Wed Oct 10 15:36:39 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f9AMYL110727;
Wed, 10 Oct 2001 15:34:21 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f9AMYKp10723
for <rmt@listserv.lbl.gov>; Wed, 10 Oct 2001 15:34:20 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f9AMYJB19133
for <rmt@listserv.lbl.gov>; Wed, 10 Oct 2001 15:34:19 -0700 (PDT)
Received: from chapweske.com (nic-41-c31-11.mn.mediaone.net [66.41.31.11])
by SpamWall.lbl.gov (8.11.2/8.11.2) with SMTP id f9AMYI719128
for <rmt@lbl.gov>; Wed, 10 Oct 2001 15:34:18 -0700 (PDT)
Received: (qmail 1540 invoked from network); 10 Oct 2001 22:50:03 -0000
Received: from unknown (HELO onionnetworks.com) (192.168.0.2)
by 192.168.0.3 with SMTP; 10 Oct 2001 22:50:03 -0000
Message-ID: <3BC4CC4C.60101@onionnetworks.com>
Date: Wed, 10 Oct 2001 17:31:40 -0500
From: Justin Chapweske <justin@onionnetworks.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3) Gecko/20010801
X-Accept-Language: en-us
MIME-Version: 1.0
To: rmt@lbl.gov
Subject: LCT Header Extensions
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-rmt@lbl.gov
Precedence: bulk
From LCT:
"If present, Header Extensions MUST be processed to ensure that they are
recognized before performing any congestion control procedure or
otherwise accepting an LCT packet. LCT packets with unrecognised Header
Extensions MUST be discarded by the receiving agent, hence the expected
use of extensions SHOULD be signaled out-of-band before session startup."
This concerns me because it means there is no mechanism for forward
compatibility between implementations/versions. I would like to request
that a Header Extension be specified for vendor-specific headers,
perhaps as follows:
EXT_VEND = 3 Vendor-specific Extension
This extension allows vendors to add their own extensions in a backwords
compatible fashion.
Recievers MUST ignore any vender-specific extensions that they don't
understand.
A suggested format is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| HET = 3 | HEL | VEND_CODE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. Vender-specific Extension Content .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor Code (VEND_CODE): 16 bits
Identifies which vendor this extension is from. The Vendor code
determines how
the vendor-specific extension content will be parsed. It is RECOMMENDED
that
vendors use an extensible format for their own extensions so that they
only need a
single vendor code.
Thanks,
--
Justin Chapweske, Onion Networks
http://onionnetworks.com/
>From owner-rmt@listserv.lbl.gov Wed Oct 10 17:40:13 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f9B0avE16914;
Wed, 10 Oct 2001 17:36:57 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f9B0atp16910
for <rmt@listserv.lbl.gov>; Wed, 10 Oct 2001 17:36:55 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f9B0at503591
for <rmt@listserv.lbl.gov>; Wed, 10 Oct 2001 17:36:55 -0700 (PDT)
Received: from mx.webfountain.com (mx.digitalfountain.com [209.219.233.39])
by SpamWall.lbl.gov (8.11.2/8.11.2) with SMTP id f9B0as703586
for <rmt@lbl.gov>; Wed, 10 Oct 2001 17:36:54 -0700 (PDT)
Received: (qmail 25783 invoked from network); 11 Oct 2001 00:36:49 -0000
Received: from mail.intranet (10.1.1.37)
by mx.digitalfountain.com with SMTP; 11 Oct 2001 00:36:49 -0000
Received: from bozz (dhcp-10-1-2-180.intranet [10.1.2.180])
by mail.intranet (8.9.3/8.9.3) with SMTP id RAA30498;
Wed, 10 Oct 2001 17:36:23 -0700
X-Authentication-Warning: mail.intranet: Host dhcp-10-1-2-180.intranet [10.1.2.180] claimed to be bozz
From: "Michael Luby" <luby@digitalfountain.com>
To: "Justin Chapweske" <justin@onionnetworks.com>, <rmt@lbl.gov>
Cc: "Michael Luby" <luby@digitalfountain.com>
Subject: RE: LCT Header Extensions
Date: Wed, 10 Oct 2001 17:42:16 -0700
Message-ID: <NEBBIAPCNKEDCLPNFBNCMEJNCHAA.luby@digitalfountain.com>
MIME-Version: 1.0
Content-Type: text/plain;
charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <3BC4CC4C.60101@onionnetworks.com>
Importance: Normal
Sender: owner-rmt@lbl.gov
Precedence: bulk
Justin,
I agree that it is not as clearly written as it should have been, and the
writing needs to be changed. My proposal is written below. Before getting
to that, the problems that I see with your proposal are that:
(1) Your suggested format is quite complicated (embedding fields within
fields), and wastes a lot of precious packet space.
(2) It would most likely require vendors to register their vender code with
IANA, and the IANA registry would have to be set up for this, etc., and this
is an extra complication.
The solution I propose is to leave everything the way it is right now
(although I do think it is good to get rid of the header extension bit X in
the first word of the header, and to get rid of the L in each header
extension, as you suggested in an earlier email), but to change the language
you called out to the following:
"The expected use of Header Extensions, the list of Header Extension Types
and
how to process the corresponding Header Extension SHOULD be signaled
out-of-band
before session startup. If out-of-band signaling is used to communicate the
possible Header Extensions Types to be used in the session, then
Header Extension Types that are not crucial to the behavior of the receiving
agent
MAY be designated as optional.
If the receiving agent does not recognize a Header Extension Type,
or if the receiving agent does not know how to process a Header Extension
with a recognized Header Extension Type that has not been designated as
optional,
then the LCT packet MUST be discarded without further processing.
The receiving agent MUST process a Header Extension unless its Header
Extension Type is designated as optional."
-----Original Message-----
From: owner-rmt@lbl.gov [mailto:owner-rmt@lbl.gov]On Behalf Of Justin
Chapweske
Sent: Wednesday, October 10, 2001 3:32 PM
To: rmt@lbl.gov
Subject: LCT Header Extensions
From LCT:
"If present, Header Extensions MUST be processed to ensure that they are
recognized before performing any congestion control procedure or
otherwise accepting an LCT packet. LCT packets with unrecognised Header
Extensions MUST be discarded by the receiving agent, hence the expected
use of extensions SHOULD be signaled out-of-band before session startup."
This concerns me because it means there is no mechanism for forward
compatibility between implementations/versions. I would like to request
that a Header Extension be specified for vendor-specific headers,
perhaps as follows:
EXT_VEND = 3 Vendor-specific Extension
This extension allows vendors to add their own extensions in a backwords
compatible fashion.
Recievers MUST ignore any vender-specific extensions that they don't
understand.
A suggested format is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| HET = 3 | HEL | VEND_CODE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. Vender-specific Extension Content .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor Code (VEND_CODE): 16 bits
Identifies which vendor this extension is from. The Vendor code
determines how
the vendor-specific extension content will be parsed. It is RECOMMENDED
that
vendors use an extensible format for their own extensions so that they
only need a
single vendor code.
Thanks,
--
Justin Chapweske, Onion Networks
http://onionnetworks.com/
>From owner-rmt@listserv.lbl.gov Wed Oct 10 19:52:15 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f9B2eXp22209;
Wed, 10 Oct 2001 19:40:33 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f9B2eVp22205
for <rmt@listserv.lbl.gov>; Wed, 10 Oct 2001 19:40:31 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f9B2eVR24954
for <rmt@listserv.lbl.gov>; Wed, 10 Oct 2001 19:40:31 -0700 (PDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f9B2eU724951
for <rmt@lbl.gov>; Wed, 10 Oct 2001 19:40:30 -0700 (PDT)
Received: from lorenzo-u10.cisco.com (lorenzo-u10.cisco.com [128.107.162.143])
by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f9B2eQk17791;
Wed, 10 Oct 2001 19:40:26 -0700 (PDT)
Received: from localhost (lorenzo@localhost) by lorenzo-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id TAA17619; Wed, 10 Oct 2001 19:40:24 -0700 (PDT)
Message-Id: <200110110240.TAA17619@lorenzo-u10.cisco.com>
X-Authentication-Warning: lorenzo-u10.cisco.com: lorenzo owned process doing -bs
X-Mailer: exmh version 2.3.1 01/18/2001 with version: MH 6.8.4 #29[UCI]
To: "Michael Luby" <luby@digitalfountain.com>
cc: "Justin Chapweske" <justin@onionnetworks.com>, rmt@lbl.gov
Subject: Re: LCT Header Extensions
In-Reply-To: Your message of "Wed, 10 Oct 2001 17:42:16 PDT."
<NEBBIAPCNKEDCLPNFBNCMEJNCHAA.luby@digitalfountain.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 10 Oct 2001 19:40:24 -0700
From: Lorenzo Vicisano <lorenzo@cisco.com>
Sender: owner-rmt@lbl.gov
Precedence: bulk
Mike, Justin,
Given that here we are defining a packet format (or at least
a piece of it), I think we should be able to interpret all
its fields, and define some sort of behavior for them,
at least as far as LCT is concerned. If nothing else,
this would allow us to debug the content of the LCT header
(I'm thinking of tools like "tcpdump").
For this reason I don't like the idea of signaling Header Extension
Types out of band. On the other hand it is nice to be able
to add backward-compatible extensions, to refine the protocol without
changing the version number.
My proposal is:
"All header extensions that are not understood can be safely
ignored by the receiver. This allows to introduce backward-compatible
enhancement to the protocol without changing the version number.
Non backward-compatible header extensions CANNOT be introduced without
changing the protocol version number."
Lorenzo
Note that in multicast, unlike unicast, the sender may not want/be able
to negotiate protocol capabilities, either because the receiver
population is heterogeneous or because there is no feedback channel.
My proposal is to use the 1st bit of the header extension (the one
that we were using for "L") to signal whether the header extention can
be safely ignored, if not understood.
As now we have 8 bits for the type (we got rid of "L"),
we reserve types 128 through 254 for backward-compatible
header extension, i.e. extension that will be ignored if
not understood.
Note that LCVv2 can narrow the subset of backward-compatible
extension, if it needs to and if it hasn't used all of it already
In message <NEBBIAPCNKEDCLPNFBNCMEJNCHAA.luby@digitalfountain.com>,
"Michael Luby" writes:
> Justin,
>
> I agree that it is not as clearly written as it should have been, and the
> writing needs to be changed. My proposal is written below. Before getting
> to that, the problems that I see with your proposal are that:
> (1) Your suggested format is quite complicated (embedding fields within
> fields), and wastes a lot of precious packet space.
> (2) It would most likely require vendors to register their vender code with
> IANA, and the IANA registry would have to be set up for this, etc., and this
> is an extra complication.
>
> The solution I propose is to leave everything the way it is right now
> (although I do think it is good to get rid of the header extension bit X in
> the first word of the header, and to get rid of the L in each header
> extension, as you suggested in an earlier email), but to change the language
> you called out to the following:
>
> "The expected use of Header Extensions, the list of Header Extension Types
> and
> how to process the corresponding Header Extension SHOULD be signaled
> out-of-band
> before session startup. If out-of-band signaling is used to communicate the
> possible Header Extensions Types to be used in the session, then
> Header Extension Types that are not crucial to the behavior of the receiving
> agent
> MAY be designated as optional.
> If the receiving agent does not recognize a Header Extension Type,
> or if the receiving agent does not know how to process a Header Extension
> with a recognized Header Extension Type that has not been designated as
> optional,
> then the LCT packet MUST be discarded without further processing.
> The receiving agent MUST process a Header Extension unless its Header
> Extension Type is designated as optional."
>
> -----Original Message-----
> From: owner-rmt@lbl.gov [mailto:owner-rmt@lbl.gov]On Behalf Of Justin
> Chapweske
> Sent: Wednesday, October 10, 2001 3:32 PM
> To: rmt@lbl.gov
> Subject: LCT Header Extensions
>
>
> From LCT:
>
> "If present, Header Extensions MUST be processed to ensure that they are
> recognized before performing any congestion control procedure or
> otherwise accepting an LCT packet. LCT packets with unrecognised Header
> Extensions MUST be discarded by the receiving agent, hence the expected
> use of extensions SHOULD be signaled out-of-band before session startup."
>
> This concerns me because it means there is no mechanism for forward
> compatibility between implementations/versions. I would like to request
> that a Header Extension be specified for vendor-specific headers,
> perhaps as follows:
>
> EXT_VEND = 3 Vendor-specific Extension
>
> This extension allows vendors to add their own extensions in a backwords
> compatible fashion.
> Recievers MUST ignore any vender-specific extensions that they don't
> understand.
>
> A suggested format is as follows:
>
> 0 1 2 3
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |L| HET = 3 | HEL | VEND_CODE |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> . .
> . Vender-specific Extension Content .
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> Vendor Code (VEND_CODE): 16 bits
>
> Identifies which vendor this extension is from. The Vendor code
> determines how
> the vendor-specific extension content will be parsed. It is RECOMMENDED
> that
> vendors use an extensible format for their own extensions so that they
> only need a
> single vendor code.
>
>
> Thanks,
>
> --
> Justin Chapweske, Onion Networks
> http://onionnetworks.com/
>
>From owner-rmt@listserv.lbl.gov Wed Oct 10 19:56:13 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f9B2jKv22226;
Wed, 10 Oct 2001 19:45:20 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f9B2jIp22222
for <rmt@listserv.lbl.gov>; Wed, 10 Oct 2001 19:45:18 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f9B2jI525589
for <rmt@listserv.lbl.gov>; Wed, 10 Oct 2001 19:45:18 -0700 (PDT)
Received: from mx.webfountain.com (mx.digitalfountain.com [209.219.233.39])
by SpamWall.lbl.gov (8.11.2/8.11.2) with SMTP id f9B2jH725582
for <rmt@lbl.gov>; Wed, 10 Oct 2001 19:45:17 -0700 (PDT)
Received: (qmail 26479 invoked from network); 11 Oct 2001 02:45:12 -0000
Received: from mail.intranet (10.1.1.37)
by mx.digitalfountain.com with SMTP; 11 Oct 2001 02:45:12 -0000
Received: from bozz (dhcp-10-1-2-180.intranet [10.1.2.180])
by mail.intranet (8.9.3/8.9.3) with SMTP id TAA04538;
Wed, 10 Oct 2001 19:44:46 -0700
X-Authentication-Warning: mail.intranet: Host dhcp-10-1-2-180.intranet [10.1.2.180] claimed to be bozz
From: "Michael Luby" <luby@digitalfountain.com>
To: "Lorenzo Vicisano" <lorenzo@cisco.com>
Cc: "Justin Chapweske" <justin@onionnetworks.com>, <rmt@lbl.gov>,
"Michael Luby" <luby@digitalfountain.com>
Subject: RE: LCT Header Extensions
Date: Wed, 10 Oct 2001 19:50:39 -0700
Message-ID: <NEBBIAPCNKEDCLPNFBNCAEJPCHAA.luby@digitalfountain.com>
MIME-Version: 1.0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <200110110240.TAA17619@lorenzo-u10.cisco.com>
Sender: owner-rmt@lbl.gov
Precedence: bulk
I like this suggestion. Justin?
-----Original Message-----
From: Lorenzo Vicisano [mailto:lorenzo@cisco.com]
Sent: Wednesday, October 10, 2001 7:40 PM
To: Michael Luby
Cc: Justin Chapweske; rmt@lbl.gov
Subject: Re: LCT Header Extensions
Mike, Justin,
Given that here we are defining a packet format (or at least
a piece of it), I think we should be able to interpret all
its fields, and define some sort of behavior for them,
at least as far as LCT is concerned. If nothing else,
this would allow us to debug the content of the LCT header
(I'm thinking of tools like "tcpdump").
For this reason I don't like the idea of signaling Header Extension
Types out of band. On the other hand it is nice to be able
to add backward-compatible extensions, to refine the protocol without
changing the version number.
My proposal is:
"All header extensions that are not understood can be safely
ignored by the receiver. This allows to introduce backward-compatible
enhancement to the protocol without changing the version number.
Non backward-compatible header extensions CANNOT be introduced without
changing the protocol version number."
Lorenzo
Note that in multicast, unlike unicast, the sender may not want/be able
to negotiate protocol capabilities, either because the receiver
population is heterogeneous or because there is no feedback channel.
My proposal is to use the 1st bit of the header extension (the one
that we were using for "L") to signal whether the header extention can
be safely ignored, if not understood.
As now we have 8 bits for the type (we got rid of "L"),
we reserve types 128 through 254 for backward-compatible
header extension, i.e. extension that will be ignored if
not understood.
Note that LCVv2 can narrow the subset of backward-compatible
extension, if it needs to and if it hasn't used all of it already
In message <NEBBIAPCNKEDCLPNFBNCMEJNCHAA.luby@digitalfountain.com>,
"Michael Luby" writes:
> Justin,
>
> I agree that it is not as clearly written as it should have been, and the
> writing needs to be changed. My proposal is written below. Before
getting
> to that, the problems that I see with your proposal are that:
> (1) Your suggested format is quite complicated (embedding fields within
> fields), and wastes a lot of precious packet space.
> (2) It would most likely require vendors to register their vender code
with
> IANA, and the IANA registry would have to be set up for this, etc., and
this
> is an extra complication.
>
> The solution I propose is to leave everything the way it is right now
> (although I do think it is good to get rid of the header extension bit X
in
> the first word of the header, and to get rid of the L in each header
> extension, as you suggested in an earlier email), but to change the
language
> you called out to the following:
>
> "The expected use of Header Extensions, the list of Header Extension Types
> and
> how to process the corresponding Header Extension SHOULD be signaled
> out-of-band
> before session startup. If out-of-band signaling is used to communicate
the
> possible Header Extensions Types to be used in the session, then
> Header Extension Types that are not crucial to the behavior of the
receiving
> agent
> MAY be designated as optional.
> If the receiving agent does not recognize a Header Extension Type,
> or if the receiving agent does not know how to process a Header Extension
> with a recognized Header Extension Type that has not been designated as
> optional,
> then the LCT packet MUST be discarded without further processing.
> The receiving agent MUST process a Header Extension unless its Header
> Extension Type is designated as optional."
>
> -----Original Message-----
> From: owner-rmt@lbl.gov [mailto:owner-rmt@lbl.gov]On Behalf Of Justin
> Chapweske
> Sent: Wednesday, October 10, 2001 3:32 PM
> To: rmt@lbl.gov
> Subject: LCT Header Extensions
>
>
> From LCT:
>
> "If present, Header Extensions MUST be processed to ensure that they are
> recognized before performing any congestion control procedure or
> otherwise accepting an LCT packet. LCT packets with unrecognised Header
> Extensions MUST be discarded by the receiving agent, hence the expected
> use of extensions SHOULD be signaled out-of-band before session startup."
>
> This concerns me because it means there is no mechanism for forward
> compatibility between implementations/versions. I would like to request
> that a Header Extension be specified for vendor-specific headers,
> perhaps as follows:
>
> EXT_VEND = 3 Vendor-specific Extension
>
> This extension allows vendors to add their own extensions in a backwords
> compatible fashion.
> Recievers MUST ignore any vender-specific extensions that they don't
> understand.
>
> A suggested format is as follows:
>
> 0 1 2 3
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |L| HET = 3 | HEL | VEND_CODE |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> . .
> . Vender-specific Extension Content .
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> Vendor Code (VEND_CODE): 16 bits
>
> Identifies which vendor this extension is from. The Vendor code
> determines how
> the vendor-specific extension content will be parsed. It is RECOMMENDED
> that
> vendors use an extensible format for their own extensions so that they
> only need a
> single vendor code.
>
>
> Thanks,
>
> --
> Justin Chapweske, Onion Networks
> http://onionnetworks.com/
>
>From owner-rmt@listserv.lbl.gov Wed Oct 10 21:51:21 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f9B4dm922800;
Wed, 10 Oct 2001 21:39:48 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f9B4dlp22796
for <rmt@listserv.lbl.gov>; Wed, 10 Oct 2001 21:39:47 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f9B4dkm08831
for <rmt@listserv.lbl.gov>; Wed, 10 Oct 2001 21:39:46 -0700 (PDT)
Received: from chapweske.com (nic-41-c31-11.mn.mediaone.net [66.41.31.11])
by SpamWall.lbl.gov (8.11.2/8.11.2) with SMTP id f9B4dj708822
for <rmt@lbl.gov>; Wed, 10 Oct 2001 21:39:45 -0700 (PDT)
Received: (qmail 1859 invoked from network); 11 Oct 2001 04:55:31 -0000
Received: from unknown (HELO onionnetworks.com) (192.168.0.2)
by 192.168.0.3 with SMTP; 11 Oct 2001 04:55:31 -0000
Message-ID: <3BC521EE.2060903@onionnetworks.com>
Date: Wed, 10 Oct 2001 23:37:02 -0500
From: Justin Chapweske <justin@onionnetworks.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3) Gecko/20010801
X-Accept-Language: en-us
MIME-Version: 1.0
To: Michael Luby <luby@digitalfountain.com>
CC: Lorenzo Vicisano <lorenzo@cisco.com>, rmt@lbl.gov
Subject: Re: LCT Header Extensions
References: <NEBBIAPCNKEDCLPNFBNCAEJPCHAA.luby@digitalfountain.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-rmt@lbl.gov
Precedence: bulk
I like it too. There will of course have to be clarification as to
which ranges are for fixed and variable length headers.
--
Justin Chapweske, Onion Networks
http://onionnetworks.com/
Michael Luby wrote:
>I like this suggestion. Justin?
>
>
>-----Original Message-----
>From: Lorenzo Vicisano [mailto:lorenzo@cisco.com]
>Sent: Wednesday, October 10, 2001 7:40 PM
>To: Michael Luby
>Cc: Justin Chapweske; rmt@lbl.gov
>Subject: Re: LCT Header Extensions
>
>
>Mike, Justin,
>
>Given that here we are defining a packet format (or at least
>a piece of it), I think we should be able to interpret all
>its fields, and define some sort of behavior for them,
>at least as far as LCT is concerned. If nothing else,
>this would allow us to debug the content of the LCT header
>(I'm thinking of tools like "tcpdump").
>
>For this reason I don't like the idea of signaling Header Extension
>Types out of band. On the other hand it is nice to be able
>to add backward-compatible extensions, to refine the protocol without
>changing the version number.
>
>My proposal is:
>
>"All header extensions that are not understood can be safely
>ignored by the receiver. This allows to introduce backward-compatible
>enhancement to the protocol without changing the version number.
>Non backward-compatible header extensions CANNOT be introduced without
>changing the protocol version number."
>
> Lorenzo
>
>Note that in multicast, unlike unicast, the sender may not want/be able
>to negotiate protocol capabilities, either because the receiver
>population is heterogeneous or because there is no feedback channel.
>
>My proposal is to use the 1st bit of the header extension (the one
>that we were using for "L") to signal whether the header extention can
>be safely ignored, if not understood.
>
>As now we have 8 bits for the type (we got rid of "L"),
>we reserve types 128 through 254 for backward-compatible
>header extension, i.e. extension that will be ignored if
>not understood.
>
>Note that LCVv2 can narrow the subset of backward-compatible
>extension, if it needs to and if it hasn't used all of it already
>
>
>In message <NEBBIAPCNKEDCLPNFBNCMEJNCHAA.luby@digitalfountain.com>,
>"Michael Luby" writes:
>
>>Justin,
>>
>>I agree that it is not as clearly written as it should have been, and the
>>writing needs to be changed. My proposal is written below. Before
>>
>getting
>
>>to that, the problems that I see with your proposal are that:
>>(1) Your suggested format is quite complicated (embedding fields within
>>fields), and wastes a lot of precious packet space.
>>(2) It would most likely require vendors to register their vender code
>>
>with
>
>>IANA, and the IANA registry would have to be set up for this, etc., and
>>
>this
>
>>is an extra complication.
>>
>>The solution I propose is to leave everything the way it is right now
>>(although I do think it is good to get rid of the header extension bit X
>>
>in
>
>>the first word of the header, and to get rid of the L in each header
>>extension, as you suggested in an earlier email), but to change the
>>
>language
>
>>you called out to the following:
>>
>>"The expected use of Header Extensions, the list of Header Extension Types
>>and
>>how to process the corresponding Header Extension SHOULD be signaled
>>out-of-band
>>before session startup. If out-of-band signaling is used to communicate
>>
>the
>
>>possible Header Extensions Types to be used in the session, then
>>Header Extension Types that are not crucial to the behavior of the
>>
>receiving
>
>>agent
>>MAY be designated as optional.
>>If the receiving agent does not recognize a Header Extension Type,
>>or if the receiving agent does not know how to process a Header Extension
>>with a recognized Header Extension Type that has not been designated as
>>optional,
>>then the LCT packet MUST be discarded without further processing.
>>The receiving agent MUST process a Header Extension unless its Header
>>Extension Type is designated as optional."
>>
>>-----Original Message-----
>>From: owner-rmt@lbl.gov [mailto:owner-rmt@lbl.gov]On Behalf Of Justin
>>Chapweske
>>Sent: Wednesday, October 10, 2001 3:32 PM
>>To: rmt@lbl.gov
>>Subject: LCT Header Extensions
>>
>>
>> From LCT:
>>
>>"If present, Header Extensions MUST be processed to ensure that they are
>>recognized before performing any congestion control procedure or
>>otherwise accepting an LCT packet. LCT packets with unrecognised Header
>>Extensions MUST be discarded by the receiving agent, hence the expected
>>use of extensions SHOULD be signaled out-of-band before session startup."
>>
>>This concerns me because it means there is no mechanism for forward
>>compatibility between implementations/versions. I would like to request
>>that a Header Extension be specified for vendor-specific headers,
>>perhaps as follows:
>>
>>EXT_VEND = 3 Vendor-specific Extension
>>
>>This extension allows vendors to add their own extensions in a backwords
>>compatible fashion.
>>Recievers MUST ignore any vender-specific extensions that they don't
>>understand.
>>
>>A suggested format is as follows:
>>
>> 0 1 2 3
>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> |L| HET = 3 | HEL | VEND_CODE |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> . .
>> . Vender-specific Extension Content .
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>
>>Vendor Code (VEND_CODE): 16 bits
>>
>>Identifies which vendor this extension is from. The Vendor code
>>determines how
>>the vendor-specific extension content will be parsed. It is RECOMMENDED
>>that
>>vendors use an extensible format for their own extensions so that they
>>only need a
>>single vendor code.
>>
>>
>>Thanks,
>>
>>--
>>Justin Chapweske, Onion Networks
>>http://onionnetworks.com/
>>
>
>
>From owner-rmt@listserv.lbl.gov Thu Oct 11 19:55:31 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f9C2oD012510;
Thu, 11 Oct 2001 19:50:13 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f9C2oBp12506
for <rmt@listserv.lbl.gov>; Thu, 11 Oct 2001 19:50:12 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f9C2oBl02796
for <rmt@listserv.lbl.gov>; Thu, 11 Oct 2001 19:50:11 -0700 (PDT)
Received: from chapweske.com ([66.41.31.11])
by SpamWall.lbl.gov (8.11.2/8.11.2) with SMTP id f9C2oAF02791
for <rmt@lbl.gov>; Thu, 11 Oct 2001 19:50:10 -0700 (PDT)
Received: (qmail 3682 invoked from network); 12 Oct 2001 03:05:54 -0000
Received: from unknown (HELO onionnetworks.com) (192.168.0.2)
by 192.168.0.3 with SMTP; 12 Oct 2001 03:05:54 -0000
Message-ID: <3BC659B3.6020102@onionnetworks.com>
Date: Thu, 11 Oct 2001 21:47:15 -0500
From: Justin Chapweske <justin@onionnetworks.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3) Gecko/20010801
X-Accept-Language: en-us
MIME-Version: 1.0
To: rmt@lbl.gov
Subject: Questions/Comments
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-rmt@lbl.gov
Precedence: bulk
o In section 2.2 (Small Block Systematic FEC Codes) from the FEC BB
document, it is unclear as to whether the number of redundant symbols
refers to 'n' or 'n'-'k'. To me it would be much more natural for it to
be the 'n' value.
o Also in FEC BB, "source block length" is confusing. While I know that
you are referring to symbol count, it could also be interpreted as
bytes, or words.
Thanks,
--
Justin Chapweske, Onion Networks
http://onionnetworks.com/
>From owner-rmt@listserv.lbl.gov Thu Oct 11 20:14:44 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f9C3AKv12584;
Thu, 11 Oct 2001 20:10:20 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f9C3AJp12580
for <rmt@listserv.lbl.gov>; Thu, 11 Oct 2001 20:10:19 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f9C3AJD05402
for <rmt@listserv.lbl.gov>; Thu, 11 Oct 2001 20:10:19 -0700 (PDT)
Received: from chapweske.com ([66.41.31.11])
by SpamWall.lbl.gov (8.11.2/8.11.2) with SMTP id f9C3AHF05392
for <rmt@lbl.gov>; Thu, 11 Oct 2001 20:10:17 -0700 (PDT)
Received: (qmail 3721 invoked from network); 12 Oct 2001 03:26:02 -0000
Received: from unknown (HELO onionnetworks.com) (192.168.0.2)
by 192.168.0.3 with SMTP; 12 Oct 2001 03:26:02 -0000
Message-ID: <3BC65E68.4090804@onionnetworks.com>
Date: Thu, 11 Oct 2001 22:07:20 -0500
From: Justin Chapweske <justin@onionnetworks.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3) Gecko/20010801
X-Accept-Language: en-us
MIME-Version: 1.0
To: rmt@lbl.gov
Subject: sender authentication
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-rmt@lbl.gov
Precedence: bulk
From section 4.2. (Receiver Operation) from LCT BB:
"If sender authentication information is present in an LCT packet header,
it MUST be used as specified in Section 3.3. If a receiver is unable to
implement the authentication mechanism used by the session, it MUST NOT
join the session."
This seems a bit strict to me. For Onion Networks' applications we use
various cryptographic checksum constructs communicated out of band to
perform file integrity checking. We don't care who the sender of the
data is, we only care that we get the right data. I would like to be
able to interoperate with other implementations w/o ascribing to their
same authentication mechanisms.
Thanks,
--
Justin Chapweske, Onion Networks
http://onionnetworks.com/
>From owner-rmt@listserv.lbl.gov Fri Oct 12 12:51:25 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f9CJl6t17267;
Fri, 12 Oct 2001 12:47:06 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f9CJl4p17263
for <rmt@listserv.lbl.gov>; Fri, 12 Oct 2001 12:47:04 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f9CJl2e28041
for <rmt@listserv.lbl.gov>; Fri, 12 Oct 2001 12:47:03 -0700 (PDT)
Received: from chapweske.com ([66.41.31.11])
by SpamWall.lbl.gov (8.11.2/8.11.2) with SMTP id f9CJl1F28016
for <rmt@lbl.gov>; Fri, 12 Oct 2001 12:47:01 -0700 (PDT)
Received: (qmail 4911 invoked from network); 12 Oct 2001 20:02:50 -0000
Received: from unknown (HELO onionnetworks.com) (192.168.0.2)
by 192.168.0.3 with SMTP; 12 Oct 2001 20:02:50 -0000
Message-ID: <3BC747FE.5030203@onionnetworks.com>
Date: Fri, 12 Oct 2001 14:43:58 -0500
From: Justin Chapweske <justin@onionnetworks.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3) Gecko/20010801
X-Accept-Language: en-us
MIME-Version: 1.0
To: rmt@lbl.gov
Subject: source symbol flag
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-rmt@lbl.gov
Precedence: bulk
From FEC BB section 2.1:
"In addition, a one bit FEC Encoding Flag MAY be included, and this flag
indicates whether the encoding symbol(s) in the payload of the packet
are source symbol(s) or redundant symbol(s)."
The actual location of this flag is never specified, please clarify this.
Thanks,
--
Justin Chapweske, Onion Networks
http://onionnetworks.com/
>From owner-rmt@listserv.lbl.gov Tue Oct 16 11:44:37 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f9GIc4G12267;
Tue, 16 Oct 2001 11:38:05 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f9GIbLp12263
for <rmt@listserv.lbl.gov>; Tue, 16 Oct 2001 11:37:21 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f9GIbJd05861
for <rmt@listserv.lbl.gov>; Tue, 16 Oct 2001 11:37:19 -0700 (PDT)
Received: from mx.webfountain.com (mx.digitalfountain.com [209.219.233.39])
by SpamWall.lbl.gov (8.11.2/8.11.2) with SMTP id f9GIbJ105854
for <rmt@lbl.gov>; Tue, 16 Oct 2001 11:37:19 -0700 (PDT)
Received: (qmail 3052 invoked from network); 16 Oct 2001 18:37:12 -0000
Received: from mail.intranet (10.1.1.37)
by mx.digitalfountain.com with SMTP; 16 Oct 2001 18:37:12 -0000
Received: from bozz (dhcp-10-1-2-180.intranet [10.1.2.180])
by mail.intranet (8.9.3/8.9.3) with SMTP id LAA11576;
Tue, 16 Oct 2001 11:36:46 -0700
X-Authentication-Warning: mail.intranet: Host dhcp-10-1-2-180.intranet [10.1.2.180] claimed to be bozz
From: "Michael Luby" <luby@digitalfountain.com>
To: "Justin Chapweske" <justin@onionnetworks.com>
Cc: "Jim Gemmell" <jgemmell@MICROSOFT.com>,
"Lorenzo Vicisano" <lorenzo@cisco.com>, "Mark Handley" <mjh@aciri.org>,
"Jon Crowcroft" <J.Crowcroft@cs.ucl.ac.uk>,
"Luigi Rizzo" <luigi@iet.unipi.it>, "Rmt@Lbl. Gov" <rmt@lbl.gov>,
"Michael Luby" <luby@digitalfountain.com>,
"Vincent Roca" <vincent.roca@inrialpes.fr>
Subject: RE: comments on the ALC/LCT/FEC I-D
Date: Tue, 16 Oct 2001 11:42:18 -0700
Message-ID: <NEBBIAPCNKEDCLPNFBNCAEKECHAA.luby@digitalfountain.com>
MIME-Version: 1.0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <3BCC6B76.6080500@onionnetworks.com>
Sender: owner-rmt@lbl.gov
Precedence: bulk
Thanks Justin for repsonding to one of the concerns raised by Vincent Roca.
I have the same response, i.e. that the TOI is meant to be a globally unique
identifier for the object, that will have the same value if the object is
being sourced from multiple senders, and thus it may need to be rather long
in some circumstances as Justin has outlined below. And yes, these comments
should be sent to the list I believe (and I'm sending this one to the list).
Mike
-----Original Message-----
From: Justin Chapweske [mailto:justin@onionnetworks.com]
Sent: Tuesday, October 16, 2001 10:17 AM
To: Vincent Roca
Cc: Mike Luby; Jim Gemmell; Lorenzo Vicisano; Mark Handley; Jon
Crowcroft; Luigi Rizzo
Subject: Re: comments on the ALC/LCT/FEC I-D
Is there any reason this isn't being CC'd to the mailing list?
>3- LCT: Do we really need the possibility of having a 16 byte TOI field ?
> Probably not if its only purpose is to identify objects.
> In our implementation the TOI is just an object identifier managed
> in a sequential manner and starting at a predifined initial seq
> number (just like TCP does). I guess this will be the case in most
> implementations.
> Besides doing 16 byte TOI to object mapping with the out-of-band
> mechanism (as suggested) can be rather heavy!
> Can you clarify why the TOI field can be so large in some cases.
>
We will be using a 16 byte TOI field in our implementation. We will use
the first 16 bytes of the SHA-1 hash of the content to provide a
(somewhat) unique identifer for the content. We are doing this because
we want to avoid any runtime negotiation of transport parameters to try
to maintain a relatively loose coupling. This should make it easier for
us to do things like have multiple senders, under seperate
administrative control, for a single object.
Thanks,
--
Justin Chapweske, Onion Networks
http://onionnetworks.com/
>From owner-rmt@listserv.lbl.gov Tue Oct 16 17:34:36 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f9H0VFH28679;
Tue, 16 Oct 2001 17:31:15 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f9H0VEp28675
for <rmt@listserv.lbl.gov>; Tue, 16 Oct 2001 17:31:14 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f9H0VDR10542
for <rmt@listserv.lbl.gov>; Tue, 16 Oct 2001 17:31:13 -0700 (PDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f9H0VC110536
for <rmt@lbl.gov>; Tue, 16 Oct 2001 17:31:12 -0700 (PDT)
Received: from lorenzo-u10.cisco.com (lorenzo-u10.cisco.com [128.107.162.143])
by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f9H0VAk20492;
Tue, 16 Oct 2001 17:31:10 -0700 (PDT)
Received: from localhost (lorenzo@localhost) by lorenzo-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id RAA20600; Tue, 16 Oct 2001 17:31:06 -0700 (PDT)
Message-Id: <200110170031.RAA20600@lorenzo-u10.cisco.com>
X-Authentication-Warning: lorenzo-u10.cisco.com: lorenzo owned process doing -bs
X-Mailer: exmh version 2.3.1 01/18/2001 with version: MH 6.8.4 #29[UCI]
To: Vincent Roca <vincent.roca@inrialpes.fr>
cc: Mike Luby <luby@digitalfountain.com>, Jim Gemmell <jgemmell@MICROSOFT.com>,
Mark Handley <mjh@aciri.org>, Jon Crowcroft <J.Crowcroft@cs.ucl.ac.uk>,
Luigi Rizzo <luigi@iet.unipi.it>,
Justin Chapweske <justin@onionnetworks.com>, rmt@lbl.gov
Subject: Re: comments on the ALC/LCT/FEC I-D
In-Reply-To: Your message of "Tue, 16 Oct 2001 11:19:35 +0200."
<3BCBFBA7.93E6E834@inrialpes.fr>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 16 Oct 2001 17:31:06 -0700
From: Lorenzo Vicisano <lorenzo@cisco.com>
Sender: owner-rmt@lbl.gov
Precedence: bulk
Vincent,
a few comments, please check inline.
Lorenzo
> Serious problem:
> ----------------
>
> 1- ALC draft: it is assumed that the FPI field is always present.
> This is a problem if the source wants to send a ``signaling only''
> packet, e.g. to close the session.
> Don't forget that this close session packet may be sent in situations
> where the session must be immediately released, no matter whether
> there remains packets to be sent or not.
> I suggest to add a bit in the LCT header to indicate wether the
> FPI field is present or not.
> Another advantage of doing that is that ALC would really be a
> ``specialized version of an LCT packet'' rather than being an LCT
> header plus a FPI field (and possibly other optional fields).
Maybe we can just say this:
+ In some special cases an ALC source may need to produce ALC packets
+ that do not contain any payload. This may be required, for example, to
+ signal the end of a session or to convey congestion control
+ information. These data-less packets do not contain the FEC Payload ID
+ either, but only the LCT header fields. The total datagram length,
+ conveyed by outer protocol headers (e.g. the IP or UDP header),
+ enables receivers to detect the absence of the ALC payload and FEC
+ Payload ID.
>
> 7- LCT: add the DemuxLabel flag introduced in previous LCT draft.
> This demux label can be usefull in case LCT is used directly
> on top of IP rather than UDP as there would be no UDP port number.
> This demux label can also be usefull to easily avoid LCT session
> collisions.
> This DemuxLabel can be carried in a dedicated Header Extension so
> that there is no additional cost for the common case (LCT/UDP/IP).
the current specification only allows ALC on top of UDP (made clear
in the new text).
>
> 8- ALC: there is no ALC version number. This may be a problem...
> Maybe some bits of the LCT version number could be used for that?
There is no ALC header really.. or better the ALC header borrows
its beginning from the LCT header, hence the ALC version number
is the LCT version number.. this might need to change if we define
ALC the goes directly on top of IP (now is UDP only).
>From owner-rmt@listserv.lbl.gov Wed Oct 17 01:32:14 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f9H8RcR25853;
Wed, 17 Oct 2001 01:27:38 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f9H8Rap25849
for <rmt@listserv.lbl.gov>; Wed, 17 Oct 2001 01:27:36 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f9H8Ra018537
for <rmt@listserv.lbl.gov>; Wed, 17 Oct 2001 01:27:36 -0700 (PDT)
Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f9H8RY118534
for <rmt@lbl.gov>; Wed, 17 Oct 2001 01:27:34 -0700 (PDT)
Received: from pop-serv.inrialpes.fr (pop-serv.inrialpes.fr [194.199.18.66])
by ebene.inrialpes.fr (8.11.6/8.11.6) with ESMTP id f9H8Odg18762;
Wed, 17 Oct 2001 10:24:40 +0200 (MEST)
Received: from inrialpes.fr (IDENT:roca@iseran.inrialpes.fr [194.199.24.100])
by pop-serv.inrialpes.fr (8.11.3/8.11.3/ImagV2) with ESMTP id f9H8Oej23813;
Wed, 17 Oct 2001 10:24:40 +0200 (MEST)
Message-ID: <3BCD41A0.6786E5A0@inrialpes.fr>
Date: Wed, 17 Oct 2001 10:30:24 +0200
From: Vincent Roca <vincent.roca@inrialpes.fr>
Organization: INRIA
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.14-5.0 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Michael Luby <luby@digitalfountain.com>, rmt@lbl.gov
CC: vincent.roca@inrialpes.fr
Subject: Re: comments on the ALC/LCT/FEC I-D
References: <NEBBIAPCNKEDCLPNFBNCAEKECHAA.luby@digitalfountain.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-rmt@lbl.gov
Precedence: bulk
Michael Luby wrote:
> And yes, these comments
> should be sent to the list I believe (and I'm sending this one to the list).
You're right Mike.
Here is a copy of the comments I sent directly to the I-D
authors yesterday for those who may be interested.
Cheers,
Vincent
------------- http://www.inrialpes.fr/planete/people/roca/
INRIA Rhone-Alpes Vincent ROCA
projet Planete; B-219 vincent.roca@inrialpes.fr
ZIRST; 655 av. de l'Europe phone: (+33) 4.76.61.52.16
38330 MONTBONNOT - France fax: (+33) 4.76.61.52.52
----------------------------------------------------------
some comments on the
LCT draft, draft-ietf-rmt-bb-lct-01.txt, July 2001
ALC draft, draft-ietf-rmt-pi-alc-02.txt, July 2001
FEC draft, draft-ietf-rmt-bb-fec-03.txt, July 2001
vincent roca - October 16th, 2001
----------------------------------------------------------
Serious problem:
----------------
1- ALC draft: it is assumed that the FPI field is always present.
This is a problem if the source wants to send a ``signaling only''
packet, e.g. to close the session.
Don't forget that this close session packet may be sent in
situations
where the session must be immediately released, no matter whether
there remains packets to be sent or not.
I suggest to add a bit in the LCT header to indicate wether the
FPI field is present or not.
Another advantage of doing that is that ALC would really be a
``specialized version of an LCT packet'' rather than being an LCT
header plus a FPI field (and possibly other optional fields).
Clarifications needed:
----------------------
2- LCT: does the HDR_LEN field include the fixed size LCT header and fixed
CCI?
That was not the case in previous LCT versions, it seems to be
the case now but this is not clearly said (e.g. is CCI part of
the LCT packet header?).
3- LCT: Do we really need the possibility of having a 16 byte TOI field ?
Probably not if its only purpose is to identify objects.
In our implementation the TOI is just an object identifier managed
in a sequential manner and starting at a predifined initial seq
number (just like TCP does). I guess this will be the case in most
implementations.
Besides doing 16 byte TOI to object mapping with the out-of-band
mechanism (as suggested) can be rather heavy!
Can you clarify why the TOI field can be so large in some cases.
4- ALC draft, section 3.2:
it is said that the ``FEC encoding flag'' may be communicated
via the value of the LCT codepoint field.
As Justin mentionned, the FEC BB draft says that a one bit
``FEC encoding flag'' may be included in the FPI. So there are two
possibilities of indicating wether this is a source symbol or
FEC symbol. Can you choose one (nice for interoperability
purposes).
I suggest the one bit flag in the FPI...
5- FEC BB: Can you justify the Small Block Systematic FEC formats.
I don't understand the rationale for having a different block
size in a given object (except for the last block of course), and
thus having the block size specified in the FPI rather than in
the FTI.
Can you add a pointer to a document (publication, RR...) that
motivates this choice...
May be this is related to the following remark (object
definition).
What is an object?
------------------
6- I'd like to see somewhere a discussion on a possible LCT/ALC service
model. More specifically what is an object?
The LCT draft, page 6 (General Archi), introduces several
examples.
The TV channel example puzzles me. It is suggested
that objects could correspond to individual programs like a movie.
Implicitely it is suggested that this is a streaming session.
This is where I don't agree!
For me an object is an Application Data Unit (ADU) in the
ALF (Application Level Framing) sense. Therefore the object is
the unit of data exchanged between the applications and the
ALC/LCT
protocols. For streaming sessions, each object could correspond to
individual movie frames, but not to the whole movie.
Said differently, IMHO a ``streaming object'' is a non-sense.
I admit that we can make other hypotheses, i.e. assume that
accesses to individual blocks is possible at a receiver, but
I don't think that it would be a good choice.
Nice to have / suggestions:
---------------------------
7- LCT: add the DemuxLabel flag introduced in previous LCT draft.
This demux label can be usefull in case LCT is used directly
on top of IP rather than UDP as there would be no UDP port number.
This demux label can also be usefull to easily avoid LCT session
collisions.
This DemuxLabel can be carried in a dedicated Header Extension so
that there is no additional cost for the common case (LCT/UDP/IP).
8- ALC: there is no ALC version number. This may be a problem...
Maybe some bits of the LCT version number could be used for that?
Minor remarks:
--------------
9- LCT: Update the [3] reference on FCAST. Published in IEEE Network,
2000.
(easier to find than an internal RR)
>From owner-rmt@listserv.lbl.gov Wed Oct 17 06:03:00 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f9HCwaY20661;
Wed, 17 Oct 2001 05:58:36 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f9HCwYp20657
for <rmt@listserv.lbl.gov>; Wed, 17 Oct 2001 05:58:34 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f9HCwYv28484
for <rmt@listserv.lbl.gov>; Wed, 17 Oct 2001 05:58:34 -0700 (PDT)
Received: from sm.luth.se (ny.sm.luth.se [130.240.3.1])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f9HCwW128476
for <rmt@lbl.gov>; Wed, 17 Oct 2001 05:58:32 -0700 (PDT)
Received: from cdt.luth.se (fddi.cdt.luth.se [130.240.64.13])
by sm.luth.se (8.10.0/8.10.0) with ESMTP id f9HCwQC09030
for <rmt@lbl.gov>; Wed, 17 Oct 2001 14:58:26 +0200 (MET DST)
Message-ID: <3BCD823F.93BD7C6B@cdt.luth.se>
Date: Wed, 17 Oct 2001 15:06:07 +0200
From: Jeremiah Scholl <jeremiah@cdt.luth.se>
Organization: CDT, =?iso-8859-1?Q?Lule=E5?= University
X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: rmt@lbl.gov
Subject: pgmcc
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-rmt@lbl.gov
Precedence: bulk
Taking a look at the home page for the RMT workgroup today I noticed
that a link to the Internet-Draft for PGMCC is no longer available. I
am wondering why. Was it removed because the draft has expired?? did
someone accidentaly remove the link from the page?? Perhaps is there
some other reason??
Thanks,
Jeremiah Scholl
>From owner-rmt@listserv.lbl.gov Wed Oct 17 06:31:32 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f9HDS4K24031;
Wed, 17 Oct 2001 06:28:04 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f9HDS2p24027
for <rmt@listserv.lbl.gov>; Wed, 17 Oct 2001 06:28:03 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f9HDS2v02352
for <rmt@listserv.lbl.gov>; Wed, 17 Oct 2001 06:28:02 -0700 (PDT)
Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f9HDS0102346
for <rmt@lbl.gov>; Wed, 17 Oct 2001 06:28:01 -0700 (PDT)
Received: from pop-serv.inrialpes.fr (pop-serv.inrialpes.fr [194.199.18.66])
by ebene.inrialpes.fr (8.11.6/8.11.6) with ESMTP id f9HDP5g26929;
Wed, 17 Oct 2001 15:25:05 +0200 (MEST)
Received: from inrialpes.fr (IDENT:roca@iseran.inrialpes.fr [194.199.24.100])
by pop-serv.inrialpes.fr (8.11.3/8.11.3/ImagV2) with ESMTP id f9HDP6j04262;
Wed, 17 Oct 2001 15:25:06 +0200 (MEST)
Message-ID: <3BCD880A.4FDD7D06@inrialpes.fr>
Date: Wed, 17 Oct 2001 15:30:50 +0200
From: Vincent Roca <vincent.roca@inrialpes.fr>
Organization: INRIA
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.14-5.0 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Lorenzo Vicisano <lorenzo@cisco.com>, rmt@lbl.gov
CC: vincent.roca@inrialpes.fr
Subject: Re: comments on the ALC/LCT/FEC I-D
References: <200110170031.RAA20600@lorenzo-u10.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-rmt@lbl.gov
Precedence: bulk
Lorenzo,
> > 1- ALC draft: it is assumed that the FPI field is always present.
> > This is a problem if the source wants to send a ``signaling only''
> > packet, e.g. to close the session.
> > Don't forget that this close session packet may be sent in situations
> > where the session must be immediately released, no matter whether
> > there remains packets to be sent or not.
> > I suggest to add a bit in the LCT header to indicate wether the
> > FPI field is present or not.
> > Another advantage of doing that is that ALC would really be a
> > ``specialized version of an LCT packet'' rather than being an LCT
> > header plus a FPI field (and possibly other optional fields).
>
> Maybe we can just say this:
>
> + In some special cases an ALC source may need to produce ALC packets
> + that do not contain any payload. This may be required, for example, to
> + signal the end of a session or to convey congestion control
> + information. These data-less packets do not contain the FEC Payload ID
> + either, but only the LCT header fields. The total datagram length,
> + conveyed by outer protocol headers (e.g. the IP or UDP header),
> + enables receivers to detect the absence of the ALC payload and FEC
> + Payload ID.
I agree that it works, but we can also say:
"The presence of the FEC payload ID is indicated by
the P flag of the LCT header."
(and define the Payload ID present flag (P) in LCT)
which is simpler and will always work.
We can reasonably assume that any PI built on top of LCT will
need a payload ID. In the particular case of ALC, this will be
the ``FEC'' payload ID. If no FEC BB is used, this will simply
be a ``source'' payload ID.
Besides the ALC I-D says that it is recommended that the optional
additional parameter fields adhere to the Header Extension format.
Why not including them in the LCT Header Extension list instead
of creating an additional list? The fact that the LCT Codepoint
field may indicate the presence of these additional parameter
fields too is not a problem.
In other words do we really need to separate the ALC specific
fields (as done today) or just integrate them in a natural
fashion to LCT and say that their presence is required with ALC?
LCT is a very broad BB, that can be used in many many different
situations. ALC uses a subset of LCT plus some other BBs,
so make ALC really a specialized version of LCT (as said in the
ALC I-D) rather than LCT plus additional fields.
> > 8- ALC: there is no ALC version number. This may be a problem...
> > Maybe some bits of the LCT version number could be used
> > for that?
>
> There is no ALC header really.. or better the ALC header borrows
> its beginning from the LCT header, hence the ALC version number
> is the LCT version number.. this might need to change if we define
> ALC the goes directly on top of IP (now is UDP only).
I've never seen any protocol without any explicit version
number. Today the LCT version number is a BB version number.
If it (or a part of it as I suggest) is meant to be used as a PI
version number, it should be said.
cheers,
vincent.
------------- http://www.inrialpes.fr/planete/people/roca/
INRIA Rhone-Alpes Vincent ROCA
projet Planete; B-219 vincent.roca@inrialpes.fr
ZIRST; 655 av. de l'Europe phone: (+33) 4.76.61.52.16
38330 MONTBONNOT - France fax: (+33) 4.76.61.52.52
>From owner-rmt@listserv.lbl.gov Wed Oct 17 16:41:33 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f9HMKEi15211;
Wed, 17 Oct 2001 15:20:14 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f9HMKDp15207
for <rmt@listserv.lbl.gov>; Wed, 17 Oct 2001 15:20:13 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f9HMKC113286
for <rmt@listserv.lbl.gov>; Wed, 17 Oct 2001 15:20:12 -0700 (PDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f9HMKB113276
for <rmt@lbl.gov>; Wed, 17 Oct 2001 15:20:11 -0700 (PDT)
Received: from lorenzo-u10.cisco.com (lorenzo-u10.cisco.com [128.107.162.143])
by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f9HMK9U17170;
Wed, 17 Oct 2001 15:20:10 -0700 (PDT)
Received: from localhost (lorenzo@localhost) by lorenzo-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id PAA24970; Wed, 17 Oct 2001 15:20:05 -0700 (PDT)
Message-Id: <200110172220.PAA24970@lorenzo-u10.cisco.com>
X-Authentication-Warning: lorenzo-u10.cisco.com: lorenzo owned process doing -bs
X-Mailer: exmh version 2.3.1 01/18/2001 with version: MH 6.8.4 #29[UCI]
To: Jeremiah Scholl <jeremiah@cdt.luth.se>
cc: rmt@lbl.gov
Subject: Re: pgmcc
In-Reply-To: Your message of "Wed, 17 Oct 2001 15:06:07 +0200."
<3BCD823F.93BD7C6B@cdt.luth.se>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 17 Oct 2001 15:20:05 -0700
From: Lorenzo Vicisano <lorenzo@cisco.com>
Sender: owner-rmt@lbl.gov
Precedence: bulk
I believe that the only reason for this is that
the draft has expired and is no longer available
in the IETF directory. We plan to revise the draft
and hopefully resubmit by the coming IETF deadline.
thanks,
Lorenzo
In message <3BCD823F.93BD7C6B@cdt.luth.se>,
Jeremiah Scholl writes:
> Taking a look at the home page for the RMT workgroup today I noticed
> that a link to the Internet-Draft for PGMCC is no longer available. I
> am wondering why. Was it removed because the draft has expired?? did
> someone accidentaly remove the link from the page?? Perhaps is there
> some other reason??
>
> Thanks,
>
> Jeremiah Scholl
>From owner-rmt@listserv.lbl.gov Wed Oct 17 17:17:29 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f9I0Bw920841;
Wed, 17 Oct 2001 17:11:58 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f9I0Bvp20837
for <rmt@listserv.lbl.gov>; Wed, 17 Oct 2001 17:11:57 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f9I0Bur04048
for <rmt@listserv.lbl.gov>; Wed, 17 Oct 2001 17:11:56 -0700 (PDT)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f9HNcB505243
for <rmt@lbl.gov>; Wed, 17 Oct 2001 16:38:12 -0700 (PDT)
Received: from lorenzo-u10.cisco.com (lorenzo-u10.cisco.com [128.107.162.143])
by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f9HN6qY13017;
Wed, 17 Oct 2001 16:06:52 -0700 (PDT)
Received: from localhost (lorenzo@localhost) by lorenzo-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id QAA25031; Wed, 17 Oct 2001 16:06:47 -0700 (PDT)
Message-Id: <200110172306.QAA25031@lorenzo-u10.cisco.com>
X-Authentication-Warning: lorenzo-u10.cisco.com: lorenzo owned process doing -bs
X-Mailer: exmh version 2.3.1 01/18/2001 with version: MH 6.8.4 #29[UCI]
To: Vincent Roca <vincent.roca@inrialpes.fr>
cc: rmt@lbl.gov
Subject: Re: comments on the ALC/LCT/FEC I-D
In-Reply-To: Your message of "Wed, 17 Oct 2001 15:30:50 +0200."
<3BCD880A.4FDD7D06@inrialpes.fr>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 17 Oct 2001 16:06:47 -0700
From: Lorenzo Vicisano <lorenzo@cisco.com>
Sender: owner-rmt@lbl.gov
Precedence: bulk
In message <3BCD880A.4FDD7D06@inrialpes.fr>,
Vincent Roca writes:
> Lorenzo,
>
> > > 1- ALC draft: it is assumed that the FPI field is always present.
> > > This is a problem if the source wants to send a ``signaling only''
> > > packet, e.g. to close the session.
> > > Don't forget that this close session packet may be sent in situatio
>ns
> > > where the session must be immediately released, no matter whether
> > > there remains packets to be sent or not.
> > > I suggest to add a bit in the LCT header to indicate wether the
> > > FPI field is present or not.
> > > Another advantage of doing that is that ALC would really be a
> > > ``specialized version of an LCT packet'' rather than being an LCT
> > > header plus a FPI field (and possibly other optional fields).
> >
> > Maybe we can just say this:
> >
> > + In some special cases an ALC source may need to produce ALC packets
> > + that do not contain any payload. This may be required, for example, to
> > + signal the end of a session or to convey congestion control
> > + information. These data-less packets do not contain the FEC Payload ID
> > + either, but only the LCT header fields. The total datagram length,
> > + conveyed by outer protocol headers (e.g. the IP or UDP header),
> > + enables receivers to detect the absence of the ALC payload and FEC
> > + Payload ID.
>
> I agree that it works, but we can also say:
>
> "The presence of the FEC payload ID is indicated by
> the P flag of the LCT header."
> (and define the Payload ID present flag (P) in LCT)
>
> which is simpler and will always work.
> We can reasonably assume that any PI built on top of LCT will
> need a payload ID. In the particular case of ALC, this will be
> the ``FEC'' payload ID. If no FEC BB is used, this will simply
> be a ``source'' payload ID.
>
> Besides the ALC I-D says that it is recommended that the optional
> additional parameter fields adhere to the Header Extension format.
> Why not including them in the LCT Header Extension list instead
> of creating an additional list? The fact that the LCT Codepoint
> field may indicate the presence of these additional parameter
> fields too is not a problem.
>
> In other words do we really need to separate the ALC specific
> fields (as done today) or just integrate them in a natural
> fashion to LCT and say that their presence is required with ALC?
>
> LCT is a very broad BB, that can be used in many many different
> situations. ALC uses a subset of LCT plus some other BBs,
> so make ALC really a specialized version of LCT (as said in the
> ALC I-D) rather than LCT plus additional fields.
We could use an LCT header extension to carry the FEC Payload ID
and in the new version of the draft we have reserved some of
those for this purpose. However this adds unnecessary header
overhead (4 bytes). I would not do it at this point.
>
>
> > > 8- ALC: there is no ALC version number. This may be a problem...
> > > Maybe some bits of the LCT version number could be used
> > > for that?
> >
> > There is no ALC header really.. or better the ALC header borrows
> > its beginning from the LCT header, hence the ALC version number
> > is the LCT version number.. this might need to change if we define
> > ALC the goes directly on top of IP (now is UDP only).
>
> I've never seen any protocol without any explicit version
> number. Today the LCT version number is a BB version number.
> If it (or a part of it as I suggest) is meant to be used as a PI
> version number, it should be said.
Given that this version "0" of ALC refers to version "0"
of LCT (and not any other future LCT) we can safely say
that the LCT version number field is also the ALC version
number field.
If in the future we define a new ALC version, let's say 1, and
this refers to a different LCT version, let's say 0, then we will
have 2 options:
1) add an ALC specific version number (this would probably
mean prepend 4-bytes ALC specific, at least)
2) let ALC version number override the LCT version number,
this would have the drawback of not being able to interpret
the LCT header out-of context, i.e. the new draft will have to say
that when a receivers reads "1" in the version number field,
this will mean ALC version 1 which is associated with LCT version
0. Not really a problem.
Keeping the 2 version numbers distinct is only an issue on a protocol
instantiation that can use multiple versions of LCT.
thanks,
Lorenzo
>From owner-rmt@listserv.lbl.gov Thu Oct 18 14:20:55 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f9ILG0R04254;
Thu, 18 Oct 2001 14:16:00 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f9ILFwp04250
for <rmt@listserv.lbl.gov>; Thu, 18 Oct 2001 14:15:59 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f9ILFvc18529
for <rmt@listserv.lbl.gov>; Thu, 18 Oct 2001 14:15:57 -0700 (PDT)
Received: from mx.webfountain.com (mx.digitalfountain.com [209.219.233.39])
by SpamWall.lbl.gov (8.11.2/8.11.2) with SMTP id f9ILFsb18458
for <rmt@lbl.gov>; Thu, 18 Oct 2001 14:15:54 -0700 (PDT)
Received: (qmail 23691 invoked from network); 18 Oct 2001 21:15:49 -0000
Received: from mail.intranet (10.1.1.37)
by mx.digitalfountain.com with SMTP; 18 Oct 2001 21:15:49 -0000
Received: from bozz (dhcp-10-1-2-180.intranet [10.1.2.180])
by mail.intranet (8.9.3/8.9.3) with SMTP id OAA30944;
Thu, 18 Oct 2001 14:15:22 -0700
X-Authentication-Warning: mail.intranet: Host dhcp-10-1-2-180.intranet [10.1.2.180] claimed to be bozz
From: "Michael Luby" <luby@digitalfountain.com>
To: "Internet-Drafts@Ietf. Org" <internet-drafts@ietf.org>,
"Rmt@Lbl. Gov" <rmt@lbl.gov>
Cc: "Michael Luby" <luby@digitalfountain.com>
Subject: draft-ietf-rmt-info-fec-01.txt
Date: Thu, 18 Oct 2001 14:20:46 -0700
Message-ID: <NEBBIAPCNKEDCLPNFBNCAEKKCHAA.luby@digitalfountain.com>
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="----=_NextPart_000_0000_01C157E0.145218E0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-rmt@lbl.gov
Precedence: bulk
This is a multi-part message in MIME format.
------=_NextPart_000_0000_01C157E0.145218E0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Please post this draft on the IETF Internet Drafts archive. This is an
update of an existing WG draft (RMT).
This also serves as a last call before moving this towards RFC status.
Please send any comments or concerns to the RMG list by Monday, October 22.
Thanks, Mike Luby
------=_NextPart_000_0000_01C157E0.145218E0
Content-Type: text/plain;
name="draft-ietf-rmt-info-fec-01.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
filename="draft-ietf-rmt-info-fec-01.txt"
Internet Engineering Task Force RMT WG=0A=
INTERNET-DRAFT M. Luby/Digital Fountain=0A=
draft-ietf-rmt-info-fec-01.txt L. Vicisano/Cisco=0A=
J. Gemmell/Microsoft=0A=
L. Rizzo/ACIRI and Univ. Pisa=0A=
M. Handley/ACIRI=0A=
J. Crowcroft/UCL=0A=
18 October 2001=0A=
Expires: April 2002=0A=
=0A=
=0A=
The use of Forward Error Correction in Reliable Multicast=0A=
=0A=
=0A=
This document is an Internet-Draft and is in full conformance with all=0A=
provisions of Section 10 of RFC2026.=0A=
=0A=
Internet-Drafts are working documents of the Internet Engineering Task=0A=
Force (IETF), its areas, and its working groups. Note that other groups=0A=
may also distribute working documents as Internet-Drafts.=0A=
=0A=
Internet-Drafts are valid for a maximum of six months and may be=0A=
updated, replaced, or obsoleted by other documents at any time. It is=0A=
inappropriate to use Internet-Drafts as reference material or to cite=0A=
them other than as a "work in progress".=0A=
=0A=
The list of current Internet-Drafts can be accessed at=0A=
http://www.ietf.org/ietf/1id-abstracts.txt=0A=
=0A=
To view the list Internet-Draft Shadow Directories, see=0A=
http://www.ietf.org/shadow.html.=0A=
=0A=
This document is a product of the IETF RMT WG. Comments should be=0A=
addressed to the authors, or the WG's mailing list at rmt@lbl.gov.=0A=
=0A=
=0A=
Abstract=0A=
=0A=
=0A=
This memo describes the use of Forward Error Correction (FEC)=0A=
codes within the context of reliable IP multicast transport=0A=
and provides an introduction to some commonly-used FEC codes.=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
Luby/Vicisano/Gemmell/Rizzo/Handley/Crowcroft [Page 1]=0A=
=0C=0A=
INTERNET-DRAFT Expires: April 2002 October 2001=0A=
=0A=
=0A=
1. Rationale and Overview=0A=
=0A=
There are many ways to provide reliability for transmission protocols.=0A=
A common method is to use ARQ, automatic request for retransmission.=0A=
With ARQ, receivers use a back channel to the sender to send requests=0A=
for retransmission of lost packets. ARQ works well for one-to-one=0A=
reliable protocols, as evidenced by the pervasive success of TCP/IP.=0A=
ARQ has also been an effective reliability tool for one-to-many=0A=
reliability protocols, and in particular for some reliable IP multicast=0A=
protocols. However, for one-to-very-many reliability protocols, ARQ has=0A=
limitations, including the feedback implosion problem because many=0A=
receivers are transmitting back to the sender, and the need for a back=0A=
channel to send these requests from the receiver. Another limitation is=0A=
that receivers may experience different loss patterns of packets, and=0A=
thus receivers may be delayed by retransmission of packets that other=0A=
receivers have lost that but they have already received. This may also=0A=
cause wasteful use of bandwidth used to retransmit packets that have=0A=
already been received by many of the receivers.=0A=
=0A=
In environments where ARQ is either costly or impossible because there=0A=
is either a very limited capacity back channel or no back channel at=0A=
all, such as satellite transmission, a Data Carousel approach to=0A=
reliability is sometimes used [1]. With a Data Carousel, the sender=0A=
partitions the object into equal length pieces of data, which we=0A=
hereafter call source symbols, places them into packets, and then=0A=
continually cycles through and sends these packets. Receivers=0A=
continually receive packets until they have received a copy of each=0A=
packet. Data Carousel has the advantage that it requires no back=0A=
channel because there is no data that flows from receivers to the=0A=
sender. However, Data Carousel also has limitations. For example, if a=0A=
receiver loses a packet in one round of transmission it must wait an=0A=
entire round before it has a chance to receive that packet again. This=0A=
may also cause wasteful use of bandwidth, as the sender continually=0A=
cycles through and transmits the packets until no receiver is missing a=0A=
packet.=0A=
=0A=
FEC codes provide a reliability method that can be used to augment or=0A=
replace other reliability methods, especially for one-to-many=0A=
reliability protocols such as reliable IP multicast. We first briefly=0A=
review some of the basic properties and types of FEC codes before=0A=
reviewing their uses in the context of reliable IP multicast. Later, we=0A=
provide a more detailed description of some of FEC codes.=0A=
=0A=
In the general literature, FEC refers to the ability to overcome both=0A=
erasures (losses) and bit-level corruption. However, in the case of IP=0A=
multicast, lower network layers will detect corrupted packets and=0A=
discard them. Therefore, an IP multicast protocol need not be concerned=0A=
with corruption; the focus is solely on erasure codes. The payloads are=0A=
=0A=
=0A=
=0A=
Luby/Vicisano/Gemmell/Rizzo/Handley/Crowcroft Section 1. [Page 2]=0A=
=0C=0A=
INTERNET-DRAFT Expires: April 2002 October 2001=0A=
=0A=
=0A=
generated and processed using an FEC erasure encoder and objects are=0A=
reassembled from reception of packets using the corresponding FEC=0A=
erasure decoder.=0A=
=0A=
The input to an FEC encoder is some number k of equal length source=0A=
symbols. The FEC encoder generates some number of encoding symbols that=0A=
are of the same length as the source symbols. The chosen length of the=0A=
symbols can vary upon each application of the FEC encoder, or it can be=0A=
fixed. These encoding symbols are placed into packets for transmission.=0A=
The number of encoding symbols placed into each packet can vary on a per=0A=
packet basis, or a fixed number of symbols (often one) can be placed=0A=
into each packet. Also, in each packet is placed enough information to=0A=
identify the particular encoding symbols carried in that packet. Upon=0A=
receipt of packets containing encoding symbols, the receiver feeds these=0A=
encoding symbols into the corresponding FEC decoder to recreate an exact=0A=
copy of the k source symbols. Ideally, the FEC decoder can recreate an=0A=
exact copy from any k of the encoding symbols.=0A=
=0A=
In a later section, we describe a technique for using FEC codes as=0A=
described above to handle blocks with variable length source symbols.=0A=
=0A=
Block FEC codes work as follows. The input to a block FEC encoder is k=0A=
source symbols and a number n. The encoder generates a total of n=0A=
encoding symbols. The encoder is systematic if it generates n-k=0A=
redundant symbols yielding an encoding block of n encoding symbols in=0A=
total composed of the k source symbols and the n-k redundant symbols. A=0A=
block FEC decoder has the property that any k of the n encoding symbols=0A=
in the encoding block is sufficient to reconstruct the original k source=0A=
symbols.=0A=
=0A=
Expandable FEC codes work as follows. An expandable FEC encoder takes=0A=
as input k source symbols and generates as many unique encoding symbols=0A=
as requested on demand, where the amount of time for generating each=0A=
encoding symbol is the same independent of how many encoding symbols are=0A=
generated. An expandable FEC decoder has the property that any k of the=0A=
unique encoding symbols is sufficient to reconstruct the original k=0A=
source symbols.=0A=
=0A=
The above definitions explain the ideal situation when the reception of=0A=
any k encoding symbols is sufficient to recover the k source symbols, in=0A=
which case the reception overhead is 0%. For some practical FEC codes,=0A=
slightly more than k encoding symbols are needed to recover the k source=0A=
symbols. If k*(1+ep) encoding symbols are needed, we say the reception=0A=
overhead is ep*100%, e.g., if k*1.05 encoding symbols are needed then=0A=
the reception overhead is 5%.=0A=
=0A=
Along a different dimension, we classify FEC codes loosely as being=0A=
either small or large. A small FEC code is efficient in terms of=0A=
=0A=
=0A=
=0A=
Luby/Vicisano/Gemmell/Rizzo/Handley/Crowcroft Section 1. [Page 3]=0A=
=0C=0A=
INTERNET-DRAFT Expires: April 2002 October 2001=0A=
=0A=
=0A=
processing time requirements for encoding and decoding for small values=0A=
of k, and a large FEC code is efficient for encoding and decoding for=0A=
much large values of k. There are implementations of block FEC codes=0A=
that have encoding times proportional to n times the length of the k=0A=
source symbols, and decoding times proportional l times the length of=0A=
the k source symbols, where l is the number of missing source symbols=0A=
among the k received encoding symbols. Because of the growth rate of=0A=
the encoding and decoding times as a product of k and n, these are=0A=
typically considered to be small block FEC codes. There are block FEC=0A=
codes with a small reception overhead that can generate n encoding=0A=
symbols and can decode the k source symbols in time proportional to the=0A=
length of the n encoding symbols. These codes are considered to be=0A=
large block FEC codes. There are expandable FEC codes with a small=0A=
reception overhead that can generate each encoding symbol in time=0A=
roughly proportional to its length, and can decode all k source symbols=0A=
in time roughly proportional to their length. These are considered to=0A=
be large expandable FEC codes.=0A=
=0A=
Ideally, FEC codes in the context of IP multicast can be used to=0A=
generate encoding symbols that are transmitted in packets in such a way=0A=
that each received packet is fully useful to a receiver to reassemble=0A=
the object regardless of previous packet reception patterns. Thus, if=0A=
some packets are lost in transit between the sender and the receiver,=0A=
instead of asking for specific retransmission of the lost packets or=0A=
waiting till the packets are resent using Data Carousel, the receiver=0A=
can use any other subsequent equal number of packets that arrive to=0A=
reassemble the object. These packets can either be proactively=0A=
transmitted or they can be explicitly requested by receivers. This=0A=
implies that the same packet is fully useful to all receivers to=0A=
reassemble the object, even though the receivers may have previously=0A=
experienced different packet loss patterns. This property can reduce or=0A=
even eliminate the problems mentioned above associated with ARQ and Data=0A=
Carousel and thereby dramatically increase the scalability of the=0A=
protocol to orders of magnitude more receivers.=0A=
=0A=
=0A=
1.1. Application of FEC codecs=0A=
=0A=
For some reliable IP multicast protocols, FEC codes are used in=0A=
conjunction with ARQ to provide reliability. For example, a large=0A=
object could be partitioned into a number of source blocks consisting of=0A=
a small number of source symbols each, and in a first round of=0A=
transmission all of the source symbols for all the source blocks could=0A=
be transmitted. Then, receivers could report back to the sender the=0A=
number of source symbols they are missing from each source block. The=0A=
sender could then compute the maximum number of missing source symbols=0A=
from each source block among all receivers. Based on this, a small=0A=
block FEC encoder could be used to generate for each source block a=0A=
=0A=
=0A=
=0A=
Luby/Vicisano/Gemmell/Rizzo/Handley/Crowcroft Section 1.1. [Page 4]=0A=
=0C=0A=
INTERNET-DRAFT Expires: April 2002 October 2001=0A=
=0A=
=0A=
number of redundant symbols equal to the computed maximum number of=0A=
missing source symbols from the block among all receivers, as long as=0A=
this maximum maximum for each block does not exceed the number of=0A=
redundant symbols that can be generated efficiently. In a second round=0A=
of transmission, the server would then send all of these redundant=0A=
symbols for all blocks. In this example, if there are no losses in the=0A=
second round of transmission then all receivers will be able to recreate=0A=
an exact copy of each original block. In this case, even if different=0A=
receivers are missing different symbols in different blocks, transmitted=0A=
redundant symbols for a given block are useful to all receivers missing=0A=
symbols from that block in the second round.=0A=
=0A=
For other reliable IP multicast protocols, FEC codes are used in a Data=0A=
Carousel fashion to provide reliability, which we call an FEC Data=0A=
Carousel. For example, an FEC Data Carousel using a large block FEC=0A=
code could work as follows. The large block FEC encoder produces n=0A=
encoding symbols considering all the k source symbols of an object as=0A=
one block. The sender cycles through and transmits the n encoding=0A=
symbols in packets in the same order in each round. An FEC Data=0A=
Carousel can have much better protection against packet loss than a Data=0A=
Carousel. For example, a receiver can join the transmission at any=0A=
point in time, and, as long as the receiver receives at least k encoding=0A=
symbols during the transmission of the next n encoding symbols, the=0A=
receiver can completely recover the object. This is true even if the=0A=
receiver starts receiving packets in the middle of a pass through the=0A=
encoding symbols. This method can also be used when the object is=0A=
partitioned into blocks and a short block FEC code is applied to each=0A=
block separately. In this case, as we explain in more detail below, it=0A=
is useful to interleave the symbols from the different blocks when they=0A=
are transmitted.=0A=
=0A=
Since any number of encoding symbols can be generated using an=0A=
expandable FEC encoder, reliable IP multicast protocols that use=0A=
expandable FEC codes generally rely solely on these codes for=0A=
reliability. For example, when an expandable FEC code is used in a FEC=0A=
Data Carousel application, the encoding packets never repeat, and thus=0A=
any k of the encoding symbols in the potentially unbounded number of=0A=
encoding symbols are sufficient to recover the original k source=0A=
symbols.=0A=
=0A=
For yet other reliable IP multicast protocols the method to obtain=0A=
reliability is to generate enough encoding symbols so that each encoding=0A=
symbol is transmitted at most once. For example, the sender can decide=0A=
a priori how many encoding symbols it will transmit, use an FEC code to=0A=
generate that number of encoding symbols from the object, and then=0A=
transmit the encoding symbols to all receivers. This method is for=0A=
example applicable to streaming protocols, where the stream is=0A=
partitioned into objects, the source symbols for each object are encoded=0A=
=0A=
=0A=
=0A=
Luby/Vicisano/Gemmell/Rizzo/Handley/Crowcroft Section 1.1. [Page 5]=0A=
=0C=0A=
INTERNET-DRAFT Expires: April 2002 October 2001=0A=
=0A=
=0A=
into encoding symbols using an FEC code, and then the sets of encoding=0A=
symbols for each object are transmitted one after the other using IP=0A=
multicast.=0A=
=0A=
=0A=
2. FEC Codes=0A=
=0A=
=0A=
2.1. Simple codes=0A=
=0A=
There are some very simple codes that are effective for repairing packet=0A=
loss under very low loss conditions. For example, one simple way to=0A=
provide protection from a single loss is to partition the object into=0A=
fixed size source symbols and then add a redundant symbol that is the=0A=
parity (XOR) of all the source symbols. The size of a source symbol is=0A=
chosen so that it fits perfectly into the payload of a packet, i.e. if=0A=
the packet payload is 512 bytes then each source symbol is 512 bytes.=0A=
The header of each packet contains enough information to identify the=0A=
payload. In this case, this is an encoding symbol ID. The encoding=0A=
symbol IDs can consist of two parts in this example. The first part is=0A=
an encoding flag that is equal to 1 if the encoding symbol is a source=0A=
symbol and is equal to 0 if the encoding symbol is a redundant symbol.=0A=
The second part of the encoding symbol ID is a source symbol ID if the=0A=
encoding flag is 1 and a redundant symbol ID if the encoding flag is 0.=0A=
The source symbol IDs can be numbered from 0 to k-1 and the redundant=0A=
symbol ID can be 0. For example, if the object consists of four source=0A=
symbols that have values a, b, c and d, then the value of the redundant=0A=
symbol is e =3D a XOR b XOR c XOR d. Then, the packets carrying these=0A=
symbols look like=0A=
(1, 0: a), (1, 1: b), (1, 2: c), (1, 3: d), (0, 0: e).=0A=
=0A=
In this example, the encoding symbol ID consists of the first two=0A=
values, where the first value is the encoding flag and the second value=0A=
is either a source symbol ID or the redundant symbol ID. The portion of=0A=
the packet after the colon is the value of the encoding symbol. Any=0A=
single source symbol of the object can be recovered as the parity of all=0A=
the other symbols. For example, if packets=0A=
(1, 0: a), (1, 1: b), (1, 3: d), (0, 0: e)=0A=
=0A=
are received then the missing source symbol value with source symbol ID=0A=
=3D 2 can be recovered by computing a XOR b XOR d XOR e =3D c.=0A=
=0A=
Another way of forming the encoding symbol ID is to let values 0,...,k-1=0A=
correspond to the k source symbols and value k corresponds to the=0A=
redundant symbol that is the XOR of the k source symbols.=0A=
=0A=
When the number of source symbols in the object is large, a simple block=0A=
code variant of the above can be used. In this case, the source symbols=0A=
=0A=
=0A=
=0A=
Luby/Vicisano/Gemmell/Rizzo/Handley/Crowcroft Section 2.1. [Page 6]=0A=
=0C=0A=
INTERNET-DRAFT Expires: April 2002 October 2001=0A=
=0A=
=0A=
are grouped together into source blocks of some number k of consecutive=0A=
symbols each, where k may be different for different blocks. If a block=0A=
consists of k source symbols then a redundant symbol is added to form an=0A=
encoding block consisting of k+1 encoding symbols. Then, a source block=0A=
consisting of k source symbols can be recovered from any k of the k+1=0A=
encoding symbols from the associated encoding block.=0A=
=0A=
Slightly more sophisticated ways of adding redundant symbols using=0A=
parity can also be used. For example, one can group a block consisting=0A=
of k source symbols in an object into a p x p square matrix, where p =3D=0A=
sqrt(k). Then, for each row a redundant symbol is added that is the=0A=
parity of all the source symbols in the row. Similarly, for each column=0A=
a redundant symbol is added that is the parity of all the source symbols=0A=
in the column. Then, any row of the matrix can be recovered from any p=0A=
of the p+1 symbols in the row, and similarly for any column. Higher=0A=
dimensional product codes using this technique can also be used.=0A=
However, one must be wary of using these constructions without some=0A=
thought towards the possible loss patterns of symbols. Ideally, the=0A=
property that one would like to obtain is that if k source symbols are=0A=
encoded into n encoding symbols (the encoding symbols consist of the=0A=
source symbols and the redundant symbols) then the k source symbols can=0A=
be recovered from any k of the n encoding symbols. Using the simple=0A=
constructions described above does not yield codes that come close to=0A=
obtaining this ideal behavior.=0A=
=0A=
=0A=
2.2. Small block FEC codes=0A=
=0A=
Reliable IP multicast protocols may use a block (n, k) FEC code [2]. For=0A=
such codes, k source symbols are encoded into n > k encoding symbols,=0A=
such that any k of the encoding symbols can be used to reassemble the=0A=
original k source symbols. Thus, these codes have no reception overhead=0A=
when used to encode the entire object directly. Block codes are usually=0A=
systematic, which means that the n encoding symbols consist of the k=0A=
source symbols and n-k redundant symbols generated from these k source=0A=
symbols, where the size of a redundant symbol is the same as that for a=0A=
source symbol. For example, the first simple code (XOR) described in=0A=
the previous subsection is a (k+1, k) code. In general, the freedom to=0A=
choose n larger than k+1 is desirable, as this can provide much better=0A=
protection against losses. A popular example of these types of codes is=0A=
a class of Reed-Solomon codes, which are based on algebraic methods=0A=
using finite fields. Implementations of (n, k) FEC erasure codes are=0A=
efficient enough to be used by personal computers [8]. For example, [7]=0A=
describes an implementation where the encoding and decoding speeds decay=0A=
as C/j, where the constant C is on the order of 10 to 80 Mbytes/second=0A=
for Pentium class machines of various vintages and j is upper bounded by=0A=
min(k, n-k).=0A=
=0A=
=0A=
=0A=
=0A=
Luby/Vicisano/Gemmell/Rizzo/Handley/Crowcroft Section 2.2. [Page 7]=0A=
=0C=0A=
INTERNET-DRAFT Expires: April 2002 October 2001=0A=
=0A=
=0A=
In practice, the values of k and n must be small (for example below 256)=0A=
for such FEC codes as large values make encoding and decoding=0A=
prohibitively expensive. As many objects are longer than k symbols for=0A=
reasonable values of k and the symbol length (e.g. larger than 16=0A=
kilobyte for k =3D 16 using 1 kilobyte symbols), they can be divided into=0A=
a number of source blocks. Each source block consists of some number k=0A=
of source symbols, where k may vary between different source blocks.=0A=
The FEC encoder is used to encode a k source symbol source block into a=0A=
n encoding symbol encoding block, where the number n of encoding symbols=0A=
in the encoding block may vary for each source block. For a receiver to=0A=
completely recover the object, for each source block consisting of k=0A=
source symbols, k distinct encoding symbols (i.e., with different=0A=
encoding symbol IDs) must be received from the corresponding encoding=0A=
block. For some encoding blocks, more encoding symbols may be received=0A=
than there are source symbols in the corresponding source block, in=0A=
which case the excess encoding symbols are discarded. An example=0A=
encoding structure is shown in Figure 1.=0A=
=0A=
=0A=
=0A=
| source symbol IDs | source symbols IDs |=0A=
| of source block 0 | of source block 1 |=0A=
| |=0A=
v v=0A=
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+=0A=
|0 |1 |2 |3 |4 |5 |6 |7 |0 |1 |2 |3 | 4|5 |6 |7 |=0A=
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+=0A=
|=0A=
FEC encoder=0A=
|=0A=
v=0A=
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+=0A=
|0 |1 |2 |3 | 4| 5| 6| 7| 8| 9| 0| 1| 2| 3| 4| 5| 6| 7| 8| 9|=0A=
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+=0A=
^ ^=0A=
| |=0A=
| encoding symbol IDs | encoding symbol IDs |=0A=
| of encoding block 0 | of encoding block 1 |=0A=
=0A=
=0A=
Figure 1. Encoding structure for object divided into two source=0A=
blocks consisting of 8 source symbols each, and the FEC encoder is used =
to=0A=
generate 2 additional redundant symbols (10 encoding symbols in total)=0A=
for each of the two source blocks.=0A=
=0A=
=0A=
In many cases, an object is partitioned into equal length source blocks=0A=
each consisting of k contiguous source symbols of the object, i.e.,=0A=
=0A=
=0A=
=0A=
Luby/Vicisano/Gemmell/Rizzo/Handley/Crowcroft Section 2.2. [Page 8]=0A=
=0C=0A=
INTERNET-DRAFT Expires: April 2002 October 2001=0A=
=0A=
=0A=
block c consists of the range of source symbols [ck, (c+1)k-1]. This=0A=
ensures that the FEC encoder can be optimized to handle a particular=0A=
number k of source symbols. This also ensures that memory references=0A=
are local when the sender reads source symbols to encode, and when the=0A=
receiver reads encoding symbols to decode. Locality of reference is=0A=
particularly important when the object is stored on disk, as it reduces=0A=
the disk seeks required. The block number and the source symbol ID=0A=
within that block can be used to uniquely specify a source symbol within=0A=
the object. If the size of the object is not a multiple of k source=0A=
symbols, then the last source block will contain less than k symbols.=0A=
=0A=
The block numbers can be numbered consecutively starting from zero.=0A=
Encoding symbols within a block can be uniquely identified by an=0A=
encoding symbol ID. One way of identifying encoding symbols within a=0A=
block is to use the combination of an encoding flag that identifies the=0A=
symbol as either a source symbol or a redundant symbol together with=0A=
either a source symbol ID or a redundant symbol ID. For example, an=0A=
encoding flag value of 1 can indicate that the encoding symbol is a=0A=
source symbol and 0 can indicate that it is a redundant symbol. The=0A=
source symbol IDs can be numbered from 0 to k-1 and the redundant symbol=0A=
IDs can be numbered from 0 to n-k-1.=0A=
=0A=
For example, if the object consists 10 source symbols with values a, b,=0A=
c, d, e, f, g, h, i, and j, and k =3D 5 and n =3D 8, then there are two=0A=
source blocks consisting of 5 symbols each, and there are two encoding=0A=
blocks consisting of 8 symbols each. Let p, q and r be the values of=0A=
the redundant symbols for the first encoding block, and let x, y and z=0A=
be the values of the redundant symbols for the second encoding block.=0A=
Then the encoding symbols together with their identifiers are=0A=
=0A=
(0, 1, 0: a), (0, 1, 1: b), (0, 1, 2: c), (0, 1, 3: d), (0, 1, 4: e),=0A=
(0, 0, 0: p), (0, 0, 1: q), (0, 0, 2: r),=0A=
(1, 1, 0: f), (1, 1, 1: g), (1, 1, 2: h), (1, 1, 3: i), (1, 1, 4: j),=0A=
(1, 0, 0: x), (1, 0, 1: y), (1, 0, 2: z).=0A=
=0A=
=0A=
In this example, the first value identifies the block number and the=0A=
second two values together identify the encoding symbol within the=0A=
block, i.e, the encoding symbol ID consists of the encoding flag=0A=
together with either the source symbol ID or the redundant symbol ID=0A=
depending on the value of the encoding flag. The value of the encoding=0A=
symbol is written after the colon. Each block can be recovered from any=0A=
5 of the 8 encoding symbols associated with that block. For example,=0A=
reception of=0A=
=0A=
(0, 1, 1: b), (0, 1, 2: c), (0, 1, 3: d), (0, 0, 0: p), (0, 0, 1: q)=0A=
=0A=
is sufficient to recover the first source block, and reception of=0A=
=0A=
=0A=
=0A=
Luby/Vicisano/Gemmell/Rizzo/Handley/Crowcroft Section 2.2. [Page 9]=0A=
=0C=0A=
INTERNET-DRAFT Expires: April 2002 October 2001=0A=
=0A=
=0A=
(1, 1, 0: f), (1, 1, 1: g), (1, 0, 0: x), (1, 0, 1: y), (1, 0, 2: z)=0A=
=0A=
=0A=
is sufficient to recover the second source block.=0A=
=0A=
Another way of uniquely identifying encoding symbols within a block is=0A=
to let the encoding symbol IDs for source symbols be 0,...,k-1 and to=0A=
let the encoding symbol IDs for redundant symbols be k,...,n-1.=0A=
=0A=
=0A=
2.3. Large block FEC codes=0A=
=0A=
Tornado codes [4] are large block FEC codes that provide an alternative=0A=
to small block FEC codes. An (n, k) Tornado code requires slightly more=0A=
than k out of n encoding symbols to recover k source symbols, i.e.,=0A=
there is a small reception overhead. However, the advantage is that the=0A=
value of k may be on the order of tens of thousands and still run=0A=
efficiently. Because of memory considerations, in practice the value of=0A=
n is restricted to be a small multiple of k, e.g., n =3D 2k. For =
example,=0A=
[3] describes an implementation of Tornado codes where the encoding and=0A=
decoding speeds are tens of megabytes per second for Pentium class=0A=
machines of various vintages when k is in the tens of thousands and n =3D=0A=
2k. The reception overhead for such values of k and n is in the 5-10%=0A=
range. Tornado codes require a large amount of out of band information=0A=
to be communicated to all senders and receivers for each different=0A=
object length, and require an amount of memory on the encoder and=0A=
decoder which is proportional to the object length times 2n/k.=0A=
=0A=
Tornado codes are designed to have low reception overhead on average=0A=
with respect to reception of a random portion of the encoding packets.=0A=
Thus, to ensure that a receiver can reassemble the object with low=0A=
reception overhead, the packets are permuted into a random order before=0A=
transmission.=0A=
=0A=
=0A=
2.4. Expandable FEC codes=0A=
=0A=
All of the FEC codes described up to this point are block codes. There=0A=
is a different type of FEC codes that we call expandable FEC codes.=0A=
Like block codes, an expandable FEC encoder operates on an object of=0A=
known size that is partitioned into equal length source symbols. Unlike=0A=
block codes, there is no predetermined number of encoding symbols that=0A=
can be generated for expandable FEC codes. Instead, an expandable FEC=0A=
encoder can generate as few or as many unique encoding symbols as=0A=
required on demand.=0A=
=0A=
LT codes [5] are an example of large expandable FEC codes with a small=0A=
reception overhead. An LT encoder uses randomization to generate each=0A=
=0A=
=0A=
=0A=
Luby/Vicisano/Gemmell/Rizzo/Handley/Crowcroft Section 2.4. [Page 10]=0A=
=0C=0A=
INTERNET-DRAFT Expires: April 2002 October 2001=0A=
=0A=
=0A=
encoding symbol randomly and independently of all other encoding=0A=
symbols. Like Tornado codes, the number of source symbols k may be very=0A=
large for LT codes, i.e., on the order of tens to hundreds of thousands,=0A=
and the encoder and decoder run efficiently in software. For example the=0A=
encoding and decoding speeds for LT codes are in the range 3-20=0A=
megabytes per second for Pentium class machines of various vintages when=0A=
k is in the high tens of thousands. An LT encoder can generate as few=0A=
or as many encoding symbols as required on demand. When a new encoding=0A=
symbol is to be generated by an LT encoder, it is based on a randomly=0A=
chosen encoding symbol ID that uniquely describes how the encoding=0A=
symbol is to be generated from the source symbols. In general, each=0A=
encoding symbol ID value corresponds to a unique encoding symbol, and=0A=
thus the space of possible encoding symbols is approximately four=0A=
billion if for example the encoding symbol ID is 4 bytes. Thus, the=0A=
chance that a particular encoding symbol is the same as any other=0A=
particular encoding symbol is inversely proportional to the number of=0A=
possible encoding symbol IDs. An LT decoder has the property that with=0A=
very high probability the receipt of any set of slightly more than k=0A=
randomly and independently generated encoding symbols is sufficient to=0A=
reassemble the k source symbols. For example, when k is on the order of=0A=
tens to hundreds of thousands the reception overhead is less than 5%=0A=
with no failures in hundreds of millions of trials under any loss=0A=
conditions.=0A=
=0A=
Because encoding symbols are randomly and independently generated by=0A=
choosing random encoding symbol IDs, LT codes have the property that=0A=
encoding symbols for the same k source symbols can be generated and=0A=
transmitted from multiple senders and received by a receiver and the=0A=
reception overhead and the decoding time is the same as if though all=0A=
the encoding symbols were generated by a single sender. The only=0A=
requirement is that the senders choose their encoding symbol IDs=0A=
randomly and independently of one another.=0A=
=0A=
There is a weak tradeoff between the number of source symbols and the=0A=
reception overhead for LT codes, and the larger the number of source=0A=
symbols the smaller the reception overhead. Thus, for shorter objects,=0A=
it is sometimes advantageous to partition the object into many short=0A=
source symbols and include multiple encoding symbols in each packet. In=0A=
this case, a single encoding symbol ID is used to identify the multiple=0A=
encoding symbols contained in a single packet.=0A=
=0A=
There are a couple of factors for choosing the appropriate symbol=0A=
length/ number of source symbols tradeoff. The primary consideration is=0A=
that there is a fixed overhead per symbol in the overall processing=0A=
requirements of the encoding and decoding, independent of the number of=0A=
source symbols. Thus, using shorter symbols means that this fixed=0A=
overhead processing per symbol will be a larger component of the overall=0A=
processing requirements, leading to larger overall processing=0A=
=0A=
=0A=
=0A=
Luby/Vicisano/Gemmell/Rizzo/Handley/Crowcroft Section 2.4. [Page 11]=0A=
=0C=0A=
INTERNET-DRAFT Expires: April 2002 October 2001=0A=
=0A=
=0A=
requirements. A second much less important consideration is that there=0A=
is a component of the processing per symbol that depends logarithmically=0A=
on the number of source symbols, and thus for this reason there is a=0A=
slight preference towards fewer source symbols.=0A=
=0A=
Like small block codes, there is a point when the object is large enough=0A=
that it makes sense to partition it into blocks when using LT codes.=0A=
Generally the object is partitioned into blocks whenever the number of=0A=
source symbols times the packet payload length is less than the size of=0A=
the object. Thus, if the packet payload is 1024 bytes and the maximum=0A=
number of source symbols is 128,000 then any object over 128 megabytes=0A=
will be partitioned into more than one block. One can choose the=0A=
maximum number of source symbols to use, depending on the desired=0A=
encoding and decoding speed versus reception overhead tradeoff desired.=0A=
Encoding symbols can be uniquely identified by a block number (when the=0A=
object is large enough to be partitioned into more than one block) and=0A=
an encoding symbol ID. The block numbers, if they are used, are=0A=
generally numbered consecutively starting from zero within the object.=0A=
The block number and the encoding symbol ID are both chosen uniformly=0A=
and randomly from their range when an encoding symbol is to be=0A=
transmitted. For example, suppose the number of source symbols is=0A=
128,000 and the number of blocks is 2. Then, each packet generated by=0A=
the LT encoder could be of the form (b, x: y). In this example, the=0A=
first value identifies the block number and the second value identifies=0A=
the encoding symbol within the block. In this example, the block number=0A=
b is either 0 or 1, and the encoding symbol ID x might be a 32-bit=0A=
value. The value y after the colon is the value of the encoding symbol.=0A=
=0A=
=0A=
2.5. Source blocks with variable length source symbols=0A=
=0A=
For all the FEC codes described above, all the source symbols in the=0A=
same source block are all of the same length. In this section, we=0A=
describe a general technique to handle the case when it is desirable to=0A=
use source symbols of varying lengths in a single source block. This=0A=
technique is applicable to block FEC codes.=0A=
=0A=
Let l_1, l_2, ... , l_k be the lengths in bytes of k varying length=0A=
source symbols to be considered part of the same source block. Let lmax=0A=
be the maximum over i =3D 1, ... , k of l_i. To prepare the source block=0A=
for the FEC encoder, pad each source symbol i out to length lmax with a=0A=
suffix of lmax-l_i zeroes, and then prepend to the beginning of this the=0A=
value l_i. Thus, each padded source symbol is of length x+lmax,=0A=
assuming that it takes x bytes to store an integer with possible values=0A=
0,...,lmax, where x is a protocol constant known to both the encoder and=0A=
the decoder. These padded source symbols, each of length x+lmax, are=0A=
the input to the encoder, together with the value n. The encoder then=0A=
generates n-k redundant symbols, each of length x+lmax.=0A=
=0A=
=0A=
=0A=
Luby/Vicisano/Gemmell/Rizzo/Handley/Crowcroft Section 2.5. [Page 12]=0A=
=0C=0A=
INTERNET-DRAFT Expires: April 2002 October 2001=0A=
=0A=
=0A=
The encoding symbols that are placed into packets consist of the=0A=
original k varying length source symbols and n-k redundant symbols, each=0A=
of length x+lmax. From any k of the received encoding symbols, the FEC=0A=
decoder recreates the k original source symbols as follows. If all k=0A=
original source symbols are received, then no decoding is necessary.=0A=
Otherwise, at least one redundant symbol is received, from which the=0A=
receiver can easily determine if the block is composed of variable-=0A=
length source symbols: if the redundant symbol(s) is longer than the=0A=
source symbols then the source symbols are variable-length. Note that in=0A=
a variable-length block the redundant symbols are always longer than the=0A=
longest source symbol, due to the presence of the prepended symbol-=0A=
length. The receiver can determine the value of lmax by subtracting x=0A=
from the length of a received redundant symbol. For each of the=0A=
received original source symbols, the receiver can generate the=0A=
corresponding padded source symbol as described above. Then, the input=0A=
to the FEC decoder is the set of received redundant symbols, together=0A=
with the set of padded source symbols constructed from the received=0A=
original symbols. The FEC decoder then produces the set of k padded=0A=
source symbols. Once the k padded source symbols have been recovered,=0A=
the length l_i of original source symbol i can be recovered from the=0A=
first x bytes of the ith padded source symbol, and then original source=0A=
symbol i is obtained by taking the next l_i bytes following the x bytes=0A=
of the length field.=0A=
=0A=
=0A=
3. Security Considerations=0A=
=0A=
The use of FEC, in and of itself, imposes no additional security=0A=
considerations versus sending the same information without FEC.=0A=
However, just like for any transmission system, a malicious sender may=0A=
try to inject packets carrying corrupted encoding symbols. If a=0A=
receiver accepts one or more corrupted encoding symbol in place of=0A=
authentic ones then such a receiver may reconstruct a corrupted object.=0A=
=0A=
Application-level transmission object authentication can detect the=0A=
corrupted transfer, but the receiver must then discard the transferred=0A=
object. Thus, injecting corrupted encoding symbols they are accepted as=0A=
valid encoding symbols by a receiver is at the very least an effective=0A=
denial of service attack.=0A=
=0A=
In light of this possibility, FEC receivers may screen the source=0A=
address of a received symbol against a list of authentic transmitter=0A=
addresses. Since source addresses may be spoofed, transport protocols=0A=
using FEC may provide mechanisms for robust source authentication of=0A=
each encoding symbol. Multicast routers along the path of a FEC transfer=0A=
may provide the capability of discarding multicast packets that=0A=
originated on that subnet, and whose source IP address does not=0A=
correspond with that subnet.=0A=
=0A=
=0A=
=0A=
Luby/Vicisano/Gemmell/Rizzo/Handley/Crowcroft Section 3. [Page 13]=0A=
=0C=0A=
INTERNET-DRAFT Expires: April 2002 October 2001=0A=
=0A=
=0A=
It is recommended that a packet authentication scheme such as TESLA [6]=0A=
be used in conjunction with FEC codes. Then, packets that cannot be=0A=
authenticated can be discarded and the object can be reliably recovered=0A=
from the received authenticated packets.=0A=
=0A=
=0A=
4. Intellectual Property Disclosure=0A=
=0A=
Tornado codes [4] have both patents issued and patents pending. There=0A=
is an issued patent for LT codes [5].=0A=
=0A=
5. Acknowledgments=0A=
=0A=
Thanks to Vincent Roca and Hayder Radha for their detailed comments on=0A=
this draft.=0A=
=0A=
=0A=
6. References=0A=
=0A=
[1] Acharya, S., Franklin, M., and Zdonik, S., ``Dissemination- Based=0A=
Data Delivery Using Broadcast Disks'', IEEE Personal Communications,=0A=
pp.50-60, Dec 1995.=0A=
=0A=
[2] Blahut, R.E., ``Theory and Practice of Error Control Codes'',=0A=
Addison Wesley, MA 1984.=0A=
=0A=
[3] Byers, J.W., Luby, M., Mitzenmacher, M., and Rege, A., ``A Digital=0A=
Fountain Approach to Reliable Distribution of Bulk Data'', Proceedings=0A=
ACM SIGCOMM '98, Vancouver, Canada, Sept 1998.=0A=
=0A=
[4] Luby, M., Mitzenmacher, M., Shokrollahi, A., Spielman, D.,=0A=
``Efficient Erasure Correcting Codes'', IEEE Transactions on Information=0A=
Theory, Special Issue: Codes on Graphs and Iterative Algorithms, pp.=0A=
569-584, Vol. 47, No. 2, February 2001.=0A=
=0A=
[5] Luby, M., "Information Additive Code Generator and Decoder for=0A=
Communication Systems", U.S. Patent No. 6,307,487, October 23, 2001.=0A=
=0A=
[6] Perrig, A., Canetti, R., Song, D., Tygar, J.D., "Efficient and=0A=
Secure Source Authentication for Multicast", Network and Distributed=0A=
System Security Symposium, NDSS 2001, pp. 35-46, February 2001.=0A=
=0A=
[7] Rizzo, L., ``Effective Erasure Codes for Reliable Computer=0A=
Communication Protocols'', ACM SIGCOMM Computer Communication Review,=0A=
Vol.27, No.2, pp.24-36, Apr 1997.=0A=
=0A=
[8] Rizzo, L., ``On the Feasibility of Software FEC'', DEIT Tech Report,=0A=
http://www.iet.unipi.it/~luigi/softfec.ps, Jan 1997.=0A=
=0A=
=0A=
=0A=
Luby/Vicisano/Gemmell/Rizzo/Handley/Crowcroft Section 6. [Page 14]=0A=
=0C=0A=
INTERNET-DRAFT Expires: April 2002 October 2001=0A=
=0A=
=0A=
7. Authors' Addresses=0A=
=0A=
Michael Luby=0A=
luby@digitalfountain.com=0A=
Digital Fountain=0A=
39141 Civic Center Drive=0A=
Suite 300=0A=
Fremont, CA 94538=0A=
=0A=
Lorenzo Vicisano=0A=
lorenzo@cisco.com=0A=
cisco Systems, Inc.=0A=
170 West Tasman Dr.,=0A=
San Jose, CA, USA, 95134=0A=
=0A=
Jim Gemmell=0A=
jgemmell@microsoft.com=0A=
Microsoft Research=0A=
301 Howard St., #830=0A=
San Francisco, CA, USA, 94105=0A=
=0A=
Luigi Rizzo=0A=
luigi@iet.unipi.it=0A=
ACIRI, 1947 Center St., Berkeley CA 94704=0A=
and=0A=
Dip. di Ing. dell'Informazione=0A=
Universita` di Pisa=0A=
via Diotisalvi 2, 56126 Pisa, Italy=0A=
=0A=
Mark Handley=0A=
mjh@aciri.org=0A=
ACIRI=0A=
1947 Center St.=0A=
Berkeley CA, USA, 94704=0A=
=0A=
Jon Crowcroft=0A=
J.Crowcroft@cs.ucl.ac.uk=0A=
Department of Computer Science=0A=
University College London=0A=
Gower Street,=0A=
London WC1E 6BT, UK=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
Luby/Vicisano/Gemmell/Rizzo/Handley/Crowcroft Section 7. [Page 15]=0A=
=0C=0A=
INTERNET-DRAFT Expires: April 2002 October 2001=0A=
=0A=
=0A=
8. Full Copyright Statement=0A=
=0A=
Copyright (C) The Internet Society (2001). All Rights Reserved.=0A=
=0A=
This document and translations of it may be copied and furnished to=0A=
others, and derivative works that comment on or otherwise explain it or=0A=
assist in its implementation may be prepared, copied, published and=0A=
distributed, in whole or in part, without restriction of any kind,=0A=
provided that the above copyright notice and this paragraph are included=0A=
on all such copies and derivative works. However, this document itself=0A=
may not be modified in any way, such as by removing the copyright notice=0A=
or references to the Internet Society or other Internet organizations,=0A=
except as needed for the purpose of developing Internet standards in=0A=
which case the procedures for copyrights defined in the Internet=0A=
languages other than English.=0A=
=0A=
The limited permissions granted above are perpetual and will not be=0A=
revoked by the Internet Society or its successors or assigns.=0A=
=0A=
This document and the information contained herein is provided on an "AS=0A=
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK=0A=
FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT=0A=
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT=0A=
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR=0A=
FITNESS FOR A PARTICULAR PURPOSE."=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
Luby/Vicisano/Gemmell/Rizzo/Handley/Crowcroft Section 8. [Page 16]=0A=
=0C=0A=
INTERNET-DRAFT Expires: April 2002 October 2001=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
Luby/Vicisano/Gemmell/Rizzo/Handley/Crowcroft Section 8. [Page 17]=0A=
------=_NextPart_000_0000_01C157E0.145218E0
Content-Type: application/postscript;
name="draft-ietf-rmt-info-fec-01.ps"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
filename="draft-ietf-rmt-info-fec-01.ps"
%!PS-Adobe-3.0=0A=
%%Creator: groff version 1.15=0A=
%%CreationDate: Thu Oct 18 10:44:37 2001=0A=
%%DocumentNeededResources: font Courier-Bold=0A=
%%+ font Times-Bold=0A=
%%+ font Times-Roman=0A=
%%+ font Courier=0A=
%%DocumentSuppliedResources: procset grops 1.15 1=0A=
%%Pages: 15=0A=
%%PageOrder: Ascend=0A=
%%Orientation: Portrait=0A=
%%EndComments=0A=
%%BeginProlog=0A=
%%BeginResource: procset grops 1.15 1=0A=
/setpacking where{=0A=
pop=0A=
currentpacking=0A=
true setpacking=0A=
}if=0A=
/grops 120 dict dup begin=0A=
/SC 32 def=0A=
/A/show load def=0A=
/B{0 SC 3 -1 roll widthshow}bind def=0A=
/C{0 exch ashow}bind def=0A=
/D{0 exch 0 SC 5 2 roll awidthshow}bind def=0A=
/E{0 rmoveto show}bind def=0A=
/F{0 rmoveto 0 SC 3 -1 roll widthshow}bind def=0A=
/G{0 rmoveto 0 exch ashow}bind def=0A=
/H{0 rmoveto 0 exch 0 SC 5 2 roll awidthshow}bind def=0A=
/I{0 exch rmoveto show}bind def=0A=
/J{0 exch rmoveto 0 SC 3 -1 roll widthshow}bind def=0A=
/K{0 exch rmoveto 0 exch ashow}bind def=0A=
/L{0 exch rmoveto 0 exch 0 SC 5 2 roll awidthshow}bind def=0A=
/M{rmoveto show}bind def=0A=
/N{rmoveto 0 SC 3 -1 roll widthshow}bind def=0A=
/O{rmoveto 0 exch ashow}bind def=0A=
/P{rmoveto 0 exch 0 SC 5 2 roll awidthshow}bind def=0A=
/Q{moveto show}bind def=0A=
/R{moveto 0 SC 3 -1 roll widthshow}bind def=0A=
/S{moveto 0 exch ashow}bind def=0A=
/T{moveto 0 exch 0 SC 5 2 roll awidthshow}bind def=0A=
/SF{=0A=
findfont exch=0A=
[exch dup 0 exch 0 exch neg 0 0]makefont=0A=
dup setfont=0A=
[exch/setfont cvx]cvx bind def=0A=
}bind def=0A=
/MF{=0A=
findfont=0A=
[5 2 roll=0A=
0 3 1 roll=0A=
neg 0 0]makefont=0A=
dup setfont=0A=
[exch/setfont cvx]cvx bind def=0A=
}bind def=0A=
/level0 0 def=0A=
/RES 0 def=0A=
/PL 0 def=0A=
/LS 0 def=0A=
/MANUAL{=0A=
statusdict begin/manualfeed true store end=0A=
}bind def=0A=
/PLG{=0A=
gsave newpath clippath pathbbox grestore=0A=
exch pop add exch pop=0A=
}bind def=0A=
/BP{=0A=
/level0 save def=0A=
1 setlinecap=0A=
1 setlinejoin=0A=
72 RES div dup scale=0A=
LS{=0A=
90 rotate=0A=
}{=0A=
0 PL translate=0A=
}ifelse=0A=
1 -1 scale=0A=
}bind def=0A=
/EP{=0A=
level0 restore=0A=
showpage=0A=
}bind def=0A=
/DA{=0A=
newpath arcn stroke=0A=
}bind def=0A=
/SN{=0A=
transform=0A=
.25 sub exch .25 sub exch=0A=
round .25 add exch round .25 add exch=0A=
itransform=0A=
}bind def=0A=
/DL{=0A=
SN=0A=
moveto=0A=
SN=0A=
lineto stroke=0A=
}bind def=0A=
/DC{=0A=
newpath 0 360 arc closepath=0A=
}bind def=0A=
/TM matrix def=0A=
/DE{=0A=
TM currentmatrix pop=0A=
translate scale newpath 0 0 .5 0 360 arc closepath=0A=
TM setmatrix=0A=
}bind def=0A=
/RC/rcurveto load def=0A=
/RL/rlineto load def=0A=
/ST/stroke load def=0A=
/MT/moveto load def=0A=
/CL/closepath load def=0A=
/FL{=0A=
currentgray exch setgray fill setgray=0A=
}bind def=0A=
/BL/fill load def=0A=
/LW/setlinewidth load def=0A=
/RE{=0A=
findfont=0A=
dup maxlength 1 index/FontName known not{1 add}if dict begin=0A=
{=0A=
1 index/FID ne{def}{pop pop}ifelse=0A=
}forall=0A=
/Encoding exch def=0A=
dup/FontName exch def=0A=
currentdict end definefont pop=0A=
}bind def=0A=
/DEFS 0 def=0A=
/EBEGIN{=0A=
moveto=0A=
DEFS begin=0A=
}bind def=0A=
/EEND/end load def=0A=
/CNT 0 def=0A=
/level1 0 def=0A=
/PBEGIN{=0A=
/level1 save def=0A=
translate=0A=
div 3 1 roll div exch scale=0A=
neg exch neg exch translate=0A=
0 setgray=0A=
0 setlinecap=0A=
1 setlinewidth=0A=
0 setlinejoin=0A=
10 setmiterlimit=0A=
[]0 setdash=0A=
/setstrokeadjust where{=0A=
pop=0A=
false setstrokeadjust=0A=
}if=0A=
/setoverprint where{=0A=
pop=0A=
false setoverprint=0A=
}if=0A=
newpath=0A=
/CNT countdictstack def=0A=
userdict begin=0A=
/showpage{}def=0A=
}bind def=0A=
/PEND{=0A=
clear=0A=
countdictstack CNT sub{end}repeat=0A=
level1 restore=0A=
}bind def=0A=
end def=0A=
/setpacking where{=0A=
pop=0A=
setpacking=0A=
}if=0A=
%%EndResource=0A=
%%IncludeResource: font Courier-Bold=0A=
%%IncludeResource: font Times-Bold=0A=
%%IncludeResource: font Times-Roman=0A=
%%IncludeResource: font Courier=0A=
grops begin/DEFS 1 dict def DEFS begin/u{.001 mul}bind def end/RES 72=0A=
def/PL 792 def/LS false def/ENC0[/asciicircum/asciitilde/Scaron/Zcaron=0A=
/scaron/zcaron/Ydieresis/trademark/quotesingle/.notdef/.notdef/.notdef=0A=
/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef=0A=
/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef=0A=
/.notdef/.notdef/space/exclam/quotedbl/numbersign/dollar/percent=0A=
/ampersand/quoteright/parenleft/parenright/asterisk/plus/comma/hyphen=0A=
/period/slash/zero/one/two/three/four/five/six/seven/eight/nine/colon=0A=
/semicolon/less/equal/greater/question/at/A/B/C/D/E/F/G/H/I/J/K/L/M/N/O=0A=
/P/Q/R/S/T/U/V/W/X/Y/Z/bracketleft/backslash/bracketright/circumflex=0A=
/underscore/quoteleft/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y=0A=
/z/braceleft/bar/braceright/tilde/.notdef/quotesinglbase/guillemotleft=0A=
/guillemotright/bullet/florin/fraction/perthousand/dagger/daggerdbl=0A=
/endash/emdash/ff/fi/fl/ffi/ffl/dotlessi/dotlessj/grave/hungarumlaut=0A=
/dotaccent/breve/caron/ring/ogonek/quotedblleft/quotedblright/oe/lslash=0A=
/quotedblbase/OE/Lslash/.notdef/exclamdown/cent/sterling/currency/yen=0A=
/brokenbar/section/dieresis/copyright/ordfeminine/guilsinglleft=0A=
/logicalnot/minus/registered/macron/degree/plusminus/twosuperior=0A=
/threesuperior/acute/mu/paragraph/periodcentered/cedilla/onesuperior=0A=
/ordmasculine/guilsinglright/onequarter/onehalf/threequarters=0A=
/questiondown/Agrave/Aacute/Acircumflex/Atilde/Adieresis/Aring/AE=0A=
/Ccedilla/Egrave/Eacute/Ecircumflex/Edieresis/Igrave/Iacute/Icircumflex=0A=
/Idieresis/Eth/Ntilde/Ograve/Oacute/Ocircumflex/Otilde/Odieresis=0A=
/multiply/Oslash/Ugrave/Uacute/Ucircumflex/Udieresis/Yacute/Thorn=0A=
/germandbls/agrave/aacute/acircumflex/atilde/adieresis/aring/ae/ccedilla=0A=
/egrave/eacute/ecircumflex/edieresis/igrave/iacute/icircumflex/idieresis=0A=
/eth/ntilde/ograve/oacute/ocircumflex/otilde/odieresis/divide/oslash=0A=
/ugrave/uacute/ucircumflex/udieresis/yacute/thorn/ydieresis]def=0A=
/Courier@0 ENC0/Courier RE/Times-Roman@0 ENC0/Times-Roman RE=0A=
/Times-Bold@0 ENC0/Times-Bold RE/Courier-Bold@0 ENC0/Courier-Bold RE=0A=
%%EndProlog=0A=
%%Page: 1 1=0A=
%%BeginPageSetup=0A=
BP=0A=
%%EndPageSetup=0A=
/F0 10/Courier-Bold@0 SF(Internet Engineering Task Force)72 85 Q(RMT WG)=0A=
209.998 E 197.998(INTERNET-DRAFT M.)72 98 R(Luby/Digital Fountain)6 E=0A=
149.998(draft-ietf-rmt-info-fec-01.ps L.)72 111 R(Vicisano/Cisco)6 E=0A=
(J. Gemmell/Microsoft)383.998 124 Q(L. Rizzo/ACIRI and Univ. Pisa)=0A=
329.998 137 Q(M. Handley/ACIRI)407.998 150 Q(J. Crowcroft/UCL)407.998=0A=
163 Q(18 October 2001)413.998 176 Q(Expires: April 2002)389.998 189 Q/F1=0A=
14/Times-Bold@0 SF(The use of F)111.894 214 Q(orward Err)-.35 E(or Corr)=0A=
-.252 E(ection in Reliable Multicast)-.252 E/F2 11/Times-Roman@0 SF(Thi\=0A=
s document is an Internet-Draft and is in full conformance with all pro)=0A=
72 246 Q(visions of Section 10 of)-.165 E(RFC2026.)72 259 Q=0A=
(Internet-Drafts are w)72 285 Q=0A=
(orking documents of the Internet Engineering T)-.11 E(ask F)-.88 E=0A=
(orce \(IETF\), its areas,)-.165 E(and its w)72 298 Q(orking groups.)=0A=
-.11 E(Note that other groups may also distrib)5.5 E(ute w)-.22 E=0A=
(orking documents as)-.11 E(Internet-Drafts.)72 311 Q=0A=
(Internet-Drafts are v)72 337 Q=0A=
(alid for a maximum of six months and may be updated, replaced, or)-.275=0A=
E(obsoleted by other documents at an)72 350 Q 2.75(yt)-.165 G 2.75=0A=
(ime. It)-2.75 F(is inappropriate to use Internet-Drafts as reference)=0A=
2.75 E(material or to cite them other than as a "w)72 363 Q=0A=
(ork in progress".)-.11 E=0A=
(The list of current Internet-Drafts can be accessed at http://www)72=0A=
389 Q(.ietf.or)-.715 E(g/ietf/1id-abstracts.txt)-.198 E 1.76 -.88(To v)=0A=
72 415 T(ie).88 E 2.75(wt)-.275 G(he list Internet-Draft Shado)-2.75 E=0A=
2.75(wD)-.275 G(irectories, see http://www)-2.75 E(.ietf.or)-.715 E=0A=
(g/shado)-.198 E -.715(w.)-.275 G(html.).715 E=0A=
(This document is a product of the IETF RMT WG.)72 441 Q=0A=
(Comments should be addressed to the)5.5 E(authors, or the WG')72 454 Q=0A=
2.75(sm)-.605 G(ailing list at rmt@lbl.go)-2.75 E -.715(v.)-.165 G/F3 11=0A=
/Times-Bold@0 SF(Abstract)267.534 486 Q F2=0A=
(This memo describes the use of F)97 508.6 Q(orw)-.165 E=0A=
(ard Error Correction \(FEC\) codes within the)-.11 E(conte)97 521.6 Q=0A=
(xt of reliable IP multicast transport and pro)-.165 E=0A=
(vides an introduction to some)-.165 E(commonly-used FEC codes.)97 534.6=0A=
Q F3(1.)72 573.6 Q F1(Rationale and Ov)5.5 E(er)-.14 E(view)-.14 E F2=0A=
(There are man)72 590.2 Q 2.75(yw)-.165 G(ays to pro)-2.86 E=0A=
(vide reliability for transmission protocols.)-.165 E 2.75(Ac)5.5 G=0A=
(ommon method is to)-2.75 E=0A=
(use ARQ, automatic request for retransmission.)72 603.2 Q -.44(Wi)5.5 G=0A=
(th ARQ, recei).44 E -.165(ve)-.275 G(rs use a back channel to the).165=0A=
E(sender to send requests for retransmission of lost pack)72 616.2 Q=0A=
2.75(ets. ARQ)-.11 F -.11(wo)2.75 G(rks well for one-to-one).11 E=0A=
(reliable protocols, as e)72 629.2 Q(videnced by the perv)-.275 E(asi)=0A=
-.275 E .33 -.165(ve s)-.275 H(uccess of TCP/IP).165 E 5.5(.A)-1.221 G=0A=
(RQ has also been an)-5.5 E(ef)72 642.2 Q(fecti)-.275 E .33 -.165(ve r)=0A=
-.275 H(eliability tool for one-to-man).165 E 2.75(yr)-.165 G=0A=
(eliability protocols, and in particular for some reliable)-2.75 E=0A=
(IP multicast protocols.)72 655.2 Q(Ho)5.5 E(we)-.275 E -.165(ve)-.275 G=0A=
.88 -.44(r, f).165 H(or one-to-v).44 E(ery-man)-.165 E 2.75(yr)-.165 G=0A=
(eliability protocols, ARQ has)-2.75 E=0A=
(limitations, including the feedback implosion problem because man)72=0A=
668.2 Q 2.75(yr)-.165 G(ecei)-2.75 E -.165(ve)-.275 G=0A=
(rs are transmitting).165 E(back to the sender)72 681.2 Q 2.75(,a)-.44 G=0A=
(nd the need for a back channel to send these requests from the recei)=0A=
-2.75 E -.165(ve)-.275 G -.605(r.).165 G=0A=
(Another limitation is that recei)72 694.2 Q -.165(ve)-.275 G(rs may e)=0A=
.165 E(xperience dif)-.165 E(ferent loss patterns of pack)-.275 E=0A=
(ets, and thus)-.11 E(recei)72 707.2 Q -.165(ve)-.275 G=0A=
(rs may be delayed by retransmission of pack).165 E=0A=
(ets that other recei)-.11 E -.165(ve)-.275 G(rs ha).165 E .33 -.165=0A=
(ve l)-.22 H(ost that b).165 E(ut the)-.22 E(y)-.165 E(ha)72 720.2 Q .33=0A=
-.165(ve a)-.22 H(lready recei).165 E -.165(ve)-.275 G 2.75(d. This).165=0A=
F(may also cause w)2.75 E=0A=
(asteful use of bandwidth used to retransmit pack)-.11 E(ets)-.11 E=0A=
(Luby/V)72 769 Q(icisano/Gemmell/Rizzo/Handle)-.66 E(y/Cro)-.165 E=0A=
117.356(wcroft Section)-.275 F 2.75(1. [P)2.75 F(age 1])-.165 E EP=0A=
%%Page: 2 2=0A=
%%BeginPageSetup=0A=
BP=0A=
%%EndPageSetup=0A=
/F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 77.081(-DRAFT Expires:)-1.012 F=0A=
(April 2002)2.75 E(October 2001)112.127 E(that ha)72 85 Q .33 -.165=0A=
(ve a)-.22 H(lready been recei).165 E -.165(ve)-.275 G 2.75(db).165 G=0A=
2.75(ym)-2.75 G(an)-2.75 E 2.75(yo)-.165 G 2.75(ft)-2.75 G(he recei)=0A=
-2.75 E -.165(ve)-.275 G(rs.).165 E(In en)72 111 Q(vironments where ARQ\=0A=
is either costly or impossible because there is either a v)-.44 E=0A=
(ery limited)-.165 E(capacity back channel or no back channel at all, s\=0A=
uch as satellite transmission, a Data Carousel)72 124 Q=0A=
(approach to reliability is sometimes used [1]. W)72 137 Q=0A=
(ith a Data Carousel, the sender partitions the)-.44 E(object into equa\=0A=
l length pieces of data, which we hereafter call source symbols, places\=0A=
them into)72 150 Q(pack)72 163 Q(ets, and then continually c)-.11 E=0A=
(ycles through and sends these pack)-.165 E(ets. Recei)-.11 E -.165(ve)=0A=
-.275 G(rs continually).165 E(recei)72 176 Q .33 -.165(ve p)-.275 H(ack)=0A=
.165 E(ets until the)-.11 E 2.75(yh)-.165 G -2.475 -.22(av e)-2.75 H=0A=
(recei)2.97 E -.165(ve)-.275 G 2.75(dac).165 G(op)-2.75 E 2.75(yo)-.11 G=0A=
2.75(fe)-2.75 G(ach pack)-2.75 E 2.75(et. Data)-.11 F=0A=
(Carousel has the adv)2.75 E(antage)-.275 E=0A=
(that it requires no back channel because there is no data that \215o)72=0A=
189 Q(ws from recei)-.275 E -.165(ve)-.275 G(rs to the sender).165 E(.)=0A=
-.605 E(Ho)72 202 Q(we)-.275 E -.165(ve)-.275 G .88 -.44(r, D).165 H=0A=
(ata Carousel also has limitations. F).44 E(or e)-.165 E=0A=
(xample, if a recei)-.165 E -.165(ve)-.275 G 2.75(rl).165 G(oses a pack)=0A=
-2.75 E(et in one)-.11 E(round of transmission it must w)72 215 Q=0A=
(ait an entire round before it has a chance to recei)-.11 E .33 -.165=0A=
(ve t)-.275 H(hat pack).165 E(et)-.11 E(ag)72 228 Q 2.75(ain. This)-.055=0A=
F(may also cause w)2.75 E=0A=
(asteful use of bandwidth, as the sender continually c)-.11 E=0A=
(ycles through)-.165 E(and transmits the pack)72 241 Q=0A=
(ets until no recei)-.11 E -.165(ve)-.275 G 2.75(ri).165 G 2.75(sm)-2.75=0A=
G(issing a pack)-2.75 E(et.)-.11 E(FEC codes pro)72 267 Q(vide a reliab\=0A=
ility method that can be used to augment or replace other reliability)=0A=
-.165 E(methods, especially for one-to-man)72 280 Q 2.75(yr)-.165 G=0A=
(eliability protocols such as reliable IP multicast.)-2.75 E 1.76 -.88=0A=
(We \214)5.5 H(rst).88 E(brie\215y re)72 293 Q(vie)-.275 E 2.75(ws)-.275=0A=
G(ome of the basic properties and types of FEC codes before re)-2.75 E=0A=
(vie)-.275 E(wing their uses in)-.275 E(the conte)72 306 Q=0A=
(xt of reliable IP multicast.)-.165 E(Later)5.5 E 2.75(,w)-.44 G 2.75=0A=
(ep)-2.75 G(ro)-2.75 E(vide a more detailed description of some of)-.165=0A=
E(FEC codes.)72 319 Q=0A=
(In the general literature, FEC refers to the ability to o)72 345 Q=0A=
-.165(ve)-.165 G(rcome both erasures \(losses\) and bit-le).165 E -.165=0A=
(ve)-.275 G(l).165 E(corruption. Ho)72 358 Q(we)-.275 E -.165(ve)-.275 G=0A=
.88 -.44(r, i).165 H 2.75(nt).44 G(he case of IP multicast, lo)-2.75 E=0A=
(wer netw)-.275 E(ork layers will detect corrupted)-.11 E(pack)72 371 Q=0A=
(ets and discard them. Therefore, an IP multicast protocol need not be \=0A=
concerned with)-.11 E(corruption; the focus is solely on erasure codes.)=0A=
72 384 Q(The payloads are generated and processed using)5.5 E(an FEC er\=0A=
asure encoder and objects are reassembled from reception of pack)72 397=0A=
Q(ets using the)-.11 E(corresponding FEC erasure decoder)72 410 Q(.)=0A=
-.605 E(The input to an FEC encoder is some number k of equal length so\=0A=
urce symbols.)72 436 Q(The FEC)5.5 E(encoder generates some number of e\=0A=
ncoding symbols that are of the same length as the source)72 449 Q 2.75=0A=
(symbols. The)72 462 R(chosen length of the symbols can v)2.75 E=0A=
(ary upon each application of the FEC encoder)-.275 E(,)-.44 E=0A=
(or it can be \214x)72 475 Q 2.75(ed. These)-.165 F=0A=
(encoding symbols are placed into pack)2.75 E(ets for transmission.)-.11=0A=
E(The number)5.5 E(of encoding symbols placed into each pack)72 488 Q=0A=
(et can v)-.11 E(ary on a per pack)-.275 E(et basis, or a \214x)-.11 E=0A=
(ed number of)-.165 E=0A=
(symbols \(often one\) can be placed into each pack)72 501 Q 2.75=0A=
(et. Also,)-.11 F(in each pack)2.75 E(et is placed enough)-.11 E(inform\=0A=
ation to identify the particular encoding symbols carried in that pack)=0A=
72 514 Q 2.75(et. Upon)-.11 F(receipt of)2.75 E(pack)72 527 Q=0A=
(ets containing encoding symbols, the recei)-.11 E -.165(ve)-.275 G 2.75=0A=
(rf).165 G(eeds these encoding symbols into the)-2.75 E=0A=
(corresponding FEC decoder to recreate an e)72 540 Q(xact cop)-.165 E=0A=
2.75(yo)-.11 G 2.75(ft)-2.75 G(he k source symbols.)-2.75 E(Ideally)5.5=0A=
E 2.75(,t)-.715 G(he FEC)-2.75 E(decoder can recreate an e)72 553 Q=0A=
(xact cop)-.165 E 2.75(yf)-.11 G(rom an)-2.75 E 2.75(yko)-.165 G 2.75=0A=
(ft)-2.75 G(he encoding symbols.)-2.75 E(In a later section, we describ\=0A=
e a technique for using FEC codes as described abo)72 579 Q .33 -.165=0A=
(ve t)-.165 H 2.75(oh).165 G(andle)-2.75 E(blocks with v)72 592 Q=0A=
(ariable length source symbols.)-.275 E(Block FEC codes w)72 618 Q=0A=
(ork as follo)-.11 E 2.75(ws. The)-.275 F=0A=
(input to a block FEC encoder is k source symbols and a)2.75 E=0A=
(number n.)72 631 Q=0A=
(The encoder generates a total of n encoding symbols.)5.5 E=0A=
(The encoder is systematic if it)5.5 E(generates n-k redundant symbols \=0A=
yielding an encoding block of n encoding symbols in total)72 644 Q=0A=
(composed of the k source symbols and the n-k redundant symbols.)72 657=0A=
Q 2.75(Ab)5.5 G(lock FEC decoder has the)-2.75 E(property that an)72 670=0A=
Q 2.75(yko)-.165 G 2.75(ft)-2.75 G=0A=
(he n encoding symbols in the encoding block is suf)-2.75 E=0A=
(\214cient to reconstruct)-.275 E(the original k source symbols.)72 683=0A=
Q(Expandable FEC codes w)72 709 Q(ork as follo)-.11 E 2.75(ws. An)-.275=0A=
F -.165(ex)2.75 G(pandable FEC encoder tak).165 E(es as input k source)=0A=
-.11 E(symbols and generates as man)72 722 Q 2.75(yu)-.165 G=0A=
(nique encoding symbols as requested on demand, where the)-2.75 E=0A=
(Luby/V)72 769 Q(icisano/Gemmell/Rizzo/Handle)-.66 E(y/Cro)-.165 E=0A=
117.356(wcroft Section)-.275 F 2.75(1. [P)2.75 F(age 2])-.165 E EP=0A=
%%Page: 3 3=0A=
%%BeginPageSetup=0A=
BP=0A=
%%EndPageSetup=0A=
/F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 77.081(-DRAFT Expires:)-1.012 F=0A=
(April 2002)2.75 E(October 2001)112.127 E(amount of time for generating\=0A=
each encoding symbol is the same independent of ho)72 85 Q 2.75(wm)=0A=
-.275 G(an)-2.75 E(y)-.165 E(encoding symbols are generated.)72 98 Q=0A=
(An e)5.5 E(xpandable FEC decoder has the property that an)-.165 E 2.75=0A=
(yko)-.165 G 2.75(ft)-2.75 G(he)-2.75 E(unique encoding symbols is suf)=0A=
72 111 Q(\214cient to reconstruct the original k source symbols.)-.275 E=0A=
(The abo)72 137 Q .33 -.165(ve d)-.165 H(e\214nitions e).165 E=0A=
(xplain the ideal situation when the reception of an)-.165 E 2.75(yke)=0A=
-.165 G(ncoding symbols is)-2.75 E(suf)72 150 Q(\214cient to reco)-.275=0A=
E -.165(ve)-.165 G 2.75(rt).165 G=0A=
(he k source symbols, in which case the reception o)-2.75 E -.165(ve)=0A=
-.165 G(rhead is 0%.).165 E -.165(Fo)5.5 G 2.75(rs).165 G(ome)-2.75 E(p\=0A=
ractical FEC codes, slightly more than k encoding symbols are needed to\=0A=
reco)72 163 Q -.165(ve)-.165 G 2.75(rt).165 G(he k source)-2.75 E 2.75=0A=
(symbols. If)72 176 R=0A=
(k*\(1+ep\) encoding symbols are needed, we say the reception o)2.75 E=0A=
-.165(ve)-.165 G(rhead is ep*100%,).165 E=0A=
(e.g., if k*1.05 encoding symbols are needed then the reception o)72 189=0A=
Q -.165(ve)-.165 G(rhead is 5%.).165 E(Along a dif)72 215 Q(ferent dime\=0A=
nsion, we classify FEC codes loosely as being either small or lar)-.275=0A=
E 2.75(ge. A)-.198 F(small FEC code is ef)72 228 Q(\214cient in terms o\=0A=
f processing time requirements for encoding and decoding)-.275 E=0A=
(for small v)72 241 Q(alues of k, and a lar)-.275 E(ge FEC code is ef)=0A=
-.198 E(\214cient for encoding and decoding for much lar)-.275 E(ge)=0A=
-.198 E -.275(va)72 254 S(lues of k.).275 E=0A=
(There are implementations of block FEC codes that ha)5.5 E .33 -.165=0A=
(ve e)-.22 H(ncoding times).165 E(proportional to n times the length of\=0A=
the k source symbols, and decoding times proportional l)72 267 Q(times\=0A=
the length of the k source symbols, where l is the number of missing s\=0A=
ource symbols among)72 280 Q(the k recei)72 293 Q -.165(ve)-.275 G 2.75=0A=
(de).165 G(ncoding symbols.)-2.75 E(Because of the gro)5.5 E=0A=
(wth rate of the encoding and decoding times)-.275 E(as a product of k \=0A=
and n, these are typically considered to be small block FEC codes.)72=0A=
306 Q(There are)5.5 E(block FEC codes with a small reception o)72 319 Q=0A=
-.165(ve)-.165 G(rhead that can generate n encoding symbols and can).165=0A=
E(decode the k source symbols in time proportional to the length of the\=0A=
n encoding symbols.)72 332 Q(These)5.5 E=0A=
(codes are considered to be lar)72 345 Q(ge block FEC codes.)-.198 E=0A=
(There are e)5.5 E(xpandable FEC codes with a small)-.165 E(reception o)=0A=
72 358 Q -.165(ve)-.165 G(rhead that can generate each encoding symbol \=0A=
in time roughly proportional to its).165 E(length, and can decode all k\=0A=
source symbols in time roughly proportional to their length.)72 371 Q=0A=
(These)5.5 E(are considered to be lar)72 384 Q(ge e)-.198 E=0A=
(xpandable FEC codes.)-.165 E(Ideally)72 410 Q 2.75(,F)-.715 G=0A=
(EC codes in the conte)-2.75 E=0A=
(xt of IP multicast can be used to generate encoding symbols that)-.165=0A=
E(are transmitted in pack)72 423 Q(ets in such a w)-.11 E=0A=
(ay that each recei)-.11 E -.165(ve)-.275 G 2.75(dp).165 G(ack)-2.75 E=0A=
(et is fully useful to a recei)-.11 E -.165(ve)-.275 G 2.75(rt).165 G(o)=0A=
-2.75 E(reassemble the object re)72 436 Q -.055(ga)-.165 G=0A=
(rdless of pre).055 E(vious pack)-.275 E=0A=
(et reception patterns. Thus, if some pack)-.11 E(ets are)-.11 E=0A=
(lost in transit between the sender and the recei)72 449 Q -.165(ve)=0A=
-.275 G .88 -.44(r, i).165 H=0A=
(nstead of asking for speci\214c retransmission of).44 E(the lost pack)=0A=
72 462 Q(ets or w)-.11 E(aiting till the pack)-.11 E=0A=
(ets are resent using Data Carousel, the recei)-.11 E -.165(ve)-.275 G=0A=
2.75(rc).165 G(an use an)-2.75 E(y)-.165 E=0A=
(other subsequent equal number of pack)72 475 Q(ets that arri)-.11 E .33=0A=
-.165(ve t)-.275 H 2.75(or).165 G(eassemble the object.)-2.75 E=0A=
(These pack)5.5 E(ets can)-.11 E(either be proacti)72 488 Q -.165(ve)=0A=
-.275 G(ly transmitted or the).165 E 2.75(yc)-.165 G(an be e)-2.75 E=0A=
(xplicitly requested by recei)-.165 E -.165(ve)-.275 G 2.75(rs. This)=0A=
.165 F(implies)2.75 E(that the same pack)72 501 Q=0A=
(et is fully useful to all recei)-.11 E -.165(ve)-.275 G=0A=
(rs to reassemble the object, e).165 E -.165(ve)-.275 G 2.75(nt).165 G=0A=
(hough the)-2.75 E(recei)72 514 Q -.165(ve)-.275 G(rs may ha).165 E .33=0A=
-.165(ve p)-.22 H(re).165 E(viously e)-.275 E(xperienced dif)-.165 E=0A=
(ferent pack)-.275 E(et loss patterns.)-.11 E(This property can)5.5 E=0A=
(reduce or e)72 527 Q -.165(ve)-.275 G 2.75(ne).165 G=0A=
(liminate the problems mentioned abo)-2.75 E .33 -.165(ve a)-.165 H=0A=
(ssociated with ARQ and Data Carousel).165 E(and thereby dramatically i\=0A=
ncrease the scalability of the protocol to orders of magnitude more)72=0A=
540 Q(recei)72 553 Q -.165(ve)-.275 G(rs.).165 E/F1 11/Times-Bold@0 SF=0A=
(1.1.)72 592 Q/F2 13/Times-Bold@0 SF -.325(Ap)5.5 G=0A=
(plication of FEC codecs).325 E F0 -.165(Fo)72 608.6 S 2.75(rs).165 G(o\=0A=
me reliable IP multicast protocols, FEC codes are used in conjunction w\=0A=
ith ARQ to pro)-2.75 E(vide)-.165 E(reliability)72 621.6 Q 5.5(.F)-.715=0A=
G(or e)-5.665 E(xample, a lar)-.165 E=0A=
(ge object could be partitioned into a number of source blocks)-.198 E(\=0A=
consisting of a small number of source symbols each, and in a \214rst r\=0A=
ound of transmission all of)72 634.6 Q=0A=
(the source symbols for all the source blocks could be transmitted.)72=0A=
647.6 Q(Then, recei)5.5 E -.165(ve)-.275 G(rs could report).165 E=0A=
(back to the sender the number of source symbols the)72 660.6 Q 2.75(ya)=0A=
-.165 G(re missing from each source block.)-2.75 E(The)5.5 E(sender cou\=0A=
ld then compute the maximum number of missing source symbols from each \=0A=
source)72 673.6 Q(block among all recei)72 686.6 Q -.165(ve)-.275 G 2.75=0A=
(rs. Based).165 F=0A=
(on this, a small block FEC encoder could be used to generate)2.75 E(fo\=0A=
r each source block a number of redundant symbols equal to the computed\=0A=
maximum number)72 699.6 Q=0A=
(of missing source symbols from the block among all recei)72 712.6 Q=0A=
-.165(ve)-.275 G(rs, as long as this maximum).165 E=0A=
(maximum for each block does not e)72 725.6 Q=0A=
(xceed the number of redundant symbols that can be generated)-.165 E=0A=
(Luby/V)72 769 Q(icisano/Gemmell/Rizzo/Handle)-.66 E(y/Cro)-.165 E=0A=
109.106(wcroft Section)-.275 F 2.75(1.1. [P)2.75 F(age 3])-.165 E EP=0A=
%%Page: 4 4=0A=
%%BeginPageSetup=0A=
BP=0A=
%%EndPageSetup=0A=
/F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 77.081(-DRAFT Expires:)-1.012 F=0A=
(April 2002)2.75 E(October 2001)112.127 E(ef)72 85 Q(\214ciently)-.275 E=0A=
5.5(.I)-.715 G 2.75(nas)-5.5 G(econd round of transmission, the serv)=0A=
-2.75 E(er w)-.165 E(ould then send all of these redundant)-.11 E=0A=
(symbols for all blocks.)72 98 Q(In this e)5.5 E=0A=
(xample, if there are no losses in the second round of transmission)=0A=
-.165 E(then all recei)72 111 Q -.165(ve)-.275 G=0A=
(rs will be able to recreate an e).165 E(xact cop)-.165 E 2.75(yo)-.11 G=0A=
2.75(fe)-2.75 G(ach original block.)-2.75 E(In this case, e)5.5 E -.165=0A=
(ve)-.275 G(n).165 E(if dif)72 124 Q(ferent recei)-.275 E -.165(ve)-.275=0A=
G(rs are missing dif).165 E(ferent symbols in dif)-.275 E=0A=
(ferent blocks, transmitted redundant)-.275 E(symbols for a gi)72 137 Q=0A=
-.165(ve)-.275 G 2.75(nb).165 G(lock are useful to all recei)-2.75 E=0A=
-.165(ve)-.275 G(rs missing symbols from that block in the).165 E=0A=
(second round.)72 150 Q -.165(Fo)72 176 S 2.75(ro).165 G(ther reliable \=0A=
IP multicast protocols, FEC codes are used in a Data Carousel f)-2.75 E=0A=
(ashion to)-.11 E(pro)72 189 Q(vide reliability)-.165 E 2.75(,w)-.715 G=0A=
(hich we call an FEC Data Carousel.)-2.75 E -.165(Fo)5.5 G 2.75(re).165=0A=
G(xample, an FEC Data Carousel)-2.915 E(using a lar)72 202 Q=0A=
(ge block FEC code could w)-.198 E(ork as follo)-.11 E 2.75(ws. The)=0A=
-.275 F(lar)2.75 E(ge block FEC encoder produces n)-.198 E(encoding sym\=0A=
bols considering all the k source symbols of an object as one block. Th\=0A=
e sender)72 215 Q -.165(cy)72 228 S=0A=
(cles through and transmits the n encoding symbols in pack).165 E=0A=
(ets in the same order in each round.)-.11 E=0A=
(An FEC Data Carousel can ha)72 241 Q .33 -.165(ve m)-.22 H=0A=
(uch better protection ag).165 E(ainst pack)-.055 E=0A=
(et loss than a Data Carousel.)-.11 E -.165(Fo)72 254 S 2.75(re).165 G=0A=
(xample, a recei)-2.915 E -.165(ve)-.275 G 2.75(rc).165 G=0A=
(an join the transmission at an)-2.75 E 2.75(yp)-.165 G=0A=
(oint in time, and, as long as the recei)-2.75 E -.165(ve)-.275 G(r).165=0A=
E(recei)72 267 Q -.165(ve)-.275 G 2.75(sa).165 G 2.75(tl)-2.75 G=0A=
(east k encoding symbols during the transmission of the ne)-2.75 E=0A=
(xt n encoding symbols, the)-.165 E(recei)72 280 Q -.165(ve)-.275 G 2.75=0A=
(rc).165 G(an completely reco)-2.75 E -.165(ve)-.165 G 2.75(rt).165 G=0A=
(he object.)-2.75 E(This is true e)5.5 E -.165(ve)-.275 G 2.75(ni).165 G=0A=
2.75(ft)-2.75 G(he recei)-2.75 E -.165(ve)-.275 G 2.75(rs).165 G=0A=
(tarts recei)-2.75 E(ving)-.275 E(pack)72 293 Q=0A=
(ets in the middle of a pass through the encoding symbols.)-.11 E=0A=
(This method can also be used)5.5 E(when the object is partitioned into\=0A=
blocks and a short block FEC code is applied to each block)72 306 Q=0A=
(separately)72 319 Q 5.5(.I)-.715 G 2.75(nt)-5.5 G(his case, as we e)=0A=
-2.75 E(xplain in more detail belo)-.165 E 1.43 -.715(w, i)-.275 H 2.75=0A=
(ti).715 G 2.75(su)-2.75 G(seful to interlea)-2.75 E .33 -.165(ve t)-.22=0A=
H(he symbols).165 E(from the dif)72 332 Q(ferent blocks when the)-.275 E=0A=
2.75(ya)-.165 G(re transmitted.)-2.75 E(Since an)72 358 Q 2.75(yn)-.165=0A=
G(umber of encoding symbols can be generated using an e)-2.75 E=0A=
(xpandable FEC encoder)-.165 E(,)-.44 E=0A=
(reliable IP multicast protocols that use e)72 371 Q=0A=
(xpandable FEC codes generally rely solely on these codes)-.165 E=0A=
(for reliability)72 384 Q 5.5(.F)-.715 G(or e)-5.665 E=0A=
(xample, when an e)-.165 E=0A=
(xpandable FEC code is used in a FEC Data Carousel)-.165 E=0A=
(application, the encoding pack)72 397 Q(ets ne)-.11 E -.165(ve)-.275 G=0A=
2.75(rr).165 G(epeat, and thus an)-2.75 E 2.75(yko)-.165 G 2.75(ft)-2.75=0A=
G(he encoding symbols in the)-2.75 E=0A=
(potentially unbounded number of encoding symbols are suf)72 410 Q=0A=
(\214cient to reco)-.275 E -.165(ve)-.165 G 2.75(rt).165 G=0A=
(he original k source)-2.75 E(symbols.)72 423 Q -.165(Fo)72 449 S 2.75=0A=
(ry).165 G(et other reliable IP multicast protocols the method to obtai\=0A=
n reliability is to generate enough)-2.75 E(encoding symbols so that ea\=0A=
ch encoding symbol is transmitted at most once.)72 462 Q -.165(Fo)5.5 G=0A=
2.75(re).165 G(xample, the)-2.915 E(sender can decide a priori ho)72 475=0A=
Q 2.75(wm)-.275 G(an)-2.75 E 2.75(ye)-.165 G=0A=
(ncoding symbols it will transmit, use an FEC code to)-2.75 E(generate \=0A=
that number of encoding symbols from the object, and then transmit the \=0A=
encoding)72 488 Q(symbols to all recei)72 501 Q -.165(ve)-.275 G 2.75=0A=
(rs. This).165 F(method is for e)2.75 E=0A=
(xample applicable to streaming protocols, where the)-.165 E(stream is \=0A=
partitioned into objects, the source symbols for each object are encode\=0A=
d into encoding)72 514 Q(symbols using an FEC code, and then the sets o\=0A=
f encoding symbols for each object are)72 527 Q=0A=
(transmitted one after the other using IP multicast.)72 540 Q/F1 11=0A=
/Times-Bold@0 SF(2.)72 579 Q/F2 14/Times-Bold@0 SF(FEC Codes)5.5 E F1=0A=
(2.1.)72 618 Q/F3 13/Times-Bold@0 SF(Simple codes)5.5 E F0=0A=
(There are some v)72 634.6 Q(ery simple codes that are ef)-.165 E(fecti)=0A=
-.275 E .33 -.165(ve f)-.275 H(or repairing pack).165 E(et loss under v)=0A=
-.11 E(ery lo)-.165 E 2.75(wl)-.275 G(oss)-2.75 E 2.75(conditions. F)72=0A=
647.6 R(or e)-.165 E(xample, one simple w)-.165 E(ay to pro)-.11 E=0A=
(vide protection from a single loss is to partition)-.165 E=0A=
(the object into \214x)72 660.6 Q(ed size source symbols and then add a\=0A=
redundant symbol that is the parity)-.165 E=0A=
(\(XOR\) of all the source symbols.)72 673.6 Q=0A=
(The size of a source symbol is chosen so that it \214ts perfectly)5.5 E=0A=
(into the payload of a pack)72 686.6 Q(et, i.e. if the pack)-.11 E=0A=
(et payload is 512 bytes then each source symbol is 512)-.11 E 2.75=0A=
(bytes. The)72 699.6 R(header of each pack)2.75 E=0A=
(et contains enough information to identify the payload.)-.11 E(In this)=0A=
5.5 E(case, this is an encoding symbol ID.)72 712.6 Q=0A=
(The encoding symbol IDs can consist of tw)5.5 E 2.75(op)-.11 G=0A=
(arts in this)-2.75 E -.165(ex)72 725.6 S 2.75(ample. The).165 F(\214rs\=0A=
t part is an encoding \215ag that is equal to 1 if the encoding symbol \=0A=
is a source)2.75 E(Luby/V)72 769 Q(icisano/Gemmell/Rizzo/Handle)-.66 E=0A=
(y/Cro)-.165 E 109.106(wcroft Section)-.275 F 2.75(2.1. [P)2.75 F=0A=
(age 4])-.165 E EP=0A=
%%Page: 5 5=0A=
%%BeginPageSetup=0A=
BP=0A=
%%EndPageSetup=0A=
/F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 77.081(-DRAFT Expires:)-1.012 F=0A=
(April 2002)2.75 E(October 2001)112.127 E=0A=
(symbol and is equal to 0 if the encoding symbol is a redundant symbol.)=0A=
72 85 Q(The second part of the)5.5 E(encoding symbol ID is a source sym\=0A=
bol ID if the encoding \215ag is 1 and a redundant symbol ID if)72 98 Q=0A=
(the encoding \215ag is 0.)72 111 Q=0A=
(The source symbol IDs can be numbered from 0 to k-1 and the redundant)=0A=
5.5 E(symbol ID can be 0.)72 124 Q -.165(Fo)5.5 G 2.75(re).165 G=0A=
(xample, if the object consists of four source symbols that ha)-2.915 E=0A=
.33 -.165(ve v)-.22 H(alues)-.11 E(a, b, c and d, then the v)72 137 Q=0A=
(alue of the redundant symbol is e =3D a XOR b XOR c XOR d.)-.275 E=0A=
(Then, the)5.5 E(pack)72 150 Q(ets carrying these symbols look lik)-.11=0A=
E(e)-.11 E=0A=
(\(1, 0: a\), \(1, 1: b\), \(1, 2: c\), \(1, 3: d\), \(0, 0: e\).)=0A=
188.714 163 Q(In this e)72 189 Q=0A=
(xample, the encoding symbol ID consists of the \214rst tw)-.165 E 2.75=0A=
(ov)-.11 G(alues, where the \214rst v)-3.025 E(alue is)-.275 E=0A=
(the encoding \215ag and the second v)72 202 Q=0A=
(alue is either a source symbol ID or the redundant symbol ID.)-.275 E=0A=
(The portion of the pack)72 215 Q(et after the colon is the v)-.11 E=0A=
(alue of the encoding symbol.)-.275 E(An)5.5 E 2.75(ys)-.165 G=0A=
(ingle source)-2.75 E(symbol of the object can be reco)72 228 Q -.165=0A=
(ve)-.165 G(red as the parity of all the other symbols.).165 E -.165(Fo)=0A=
5.5 G 2.75(re).165 G(xample, if)-2.915 E(pack)72 241 Q(ets)-.11 E=0A=
(\(1, 0: a\), \(1, 1: b\), \(1, 3: d\), \(0, 0: e\))210.098 254 Q=0A=
(are recei)72 280 Q -.165(ve)-.275 G 2.75(dt).165 G=0A=
(hen the missing source symbol v)-2.75 E=0A=
(alue with source symbol ID =3D 2 can be reco)-.275 E -.165(ve)-.165 G=0A=
(red by).165 E(computing a XOR b XOR d XOR e =3D c.)72 293 Q(Another w)72=0A=
319 Q(ay of forming the encoding symbol ID is to let v)-.11 E=0A=
(alues 0,...,k-1 correspond to the k)-.275 E(source symbols and v)72 332=0A=
Q(alue k corresponds to the redundant symbol that is the XOR of the k s\=0A=
ource)-.275 E(symbols.)72 345 Q=0A=
(When the number of source symbols in the object is lar)72 371 Q=0A=
(ge, a simple block code v)-.198 E(ariant of the)-.275 E(abo)72 384 Q=0A=
.33 -.165(ve c)-.165 H(an be used.).165 E(In this case, the source symb\=0A=
ols are grouped together into source blocks of)5.5 E=0A=
(some number k of consecuti)72 397 Q .33 -.165(ve s)-.275 H=0A=
(ymbols each, where k may be dif).165 E(ferent for dif)-.275 E=0A=
(ferent blocks.)-.275 E(If a)5.5 E(block consists of k source symbols t\=0A=
hen a redundant symbol is added to form an encoding block)72 410 Q=0A=
(consisting of k+1 encoding symbols.)72 423 Q=0A=
(Then, a source block consisting of k source symbols can be)5.5 E(reco)=0A=
72 436 Q -.165(ve)-.165 G(red from an).165 E 2.75(yko)-.165 G 2.75(ft)=0A=
-2.75 G(he k+1 encoding symbols from the associated encoding block.)=0A=
-2.75 E(Slightly more sophisticated w)72 462 Q=0A=
(ays of adding redundant symbols using parity can also be used. F)-.11 E=0A=
(or)-.165 E -.165(ex)72 475 S(ample, one can group a block consisting o\=0A=
f k source symbols in an object into a p x p square).165 E=0A=
(matrix, where p =3D sqrt\(k\).)72 488 Q(Then, for each ro)5.5 E =
2.75(war)=0A=
-.275 G(edundant symbol is added that is the parity of all)-2.75 E=0A=
(the source symbols in the ro)72 501 Q 4.18 -.715(w. S)-.275 H(imilarly)=0A=
.715 E 2.75(,f)-.715 G=0A=
(or each column a redundant symbol is added that is the)-2.75 E=0A=
(parity of all the source symbols in the column.)72 514 Q(Then, an)5.5 E=0A=
2.75(yr)-.165 G .55 -.275(ow o)-2.75 H 2.75(ft).275 G=0A=
(he matrix can be reco)-2.75 E -.165(ve)-.165 G(red).165 E(from an)72=0A=
527 Q 2.75(ypo)-.165 G 2.75(ft)-2.75 G(he p+1 symbols in the ro)-2.75 E=0A=
1.43 -.715(w, a)-.275 H(nd similarly for an).715 E 2.75(yc)-.165 G 2.75=0A=
(olumn. Higher)-2.75 F(dimensional)2.75 E=0A=
(product codes using this technique can also be used.)72 540 Q(Ho)5.5 E=0A=
(we)-.275 E -.165(ve)-.275 G .88 -.44(r, o).165 H(ne must be w).44 E=0A=
(ary of using these)-.11 E(constructions without some thought to)72 553=0A=
Q -.11(wa)-.275 G(rds the possible loss patterns of symbols.).11 E=0A=
(Ideally)5.5 E 2.75(,t)-.715 G(he)-2.75 E(property that one w)72 566 Q=0A=
(ould lik)-.11 E 2.75(et)-.11 G 2.75(oo)-2.75 G=0A=
(btain is that if k source symbols are encoded into n encoding)-2.75 E(\=0A=
symbols \(the encoding symbols consist of the source symbols and the re\=0A=
dundant symbols\) then)72 579 Q(the k source symbols can be reco)72 592=0A=
Q -.165(ve)-.165 G(red from an).165 E 2.75(yko)-.165 G 2.75(ft)-2.75 G=0A=
(he n encoding symbols.)-2.75 E(Using the simple)5.5 E=0A=
(constructions described abo)72 605 Q .33 -.165(ve d)-.165 H=0A=
(oes not yield codes that come close to obtaining this ideal).165 E=0A=
(beha)72 618 Q(vior)-.22 E(.)-.605 E/F1 11/Times-Bold@0 SF(2.2.)72 657 Q=0A=
/F2 13/Times-Bold@0 SF(Small block FEC codes)5.5 E F0(Reliable IP multi\=0A=
cast protocols may use a block \(n, k\) FEC code [2]. F)72 673.6 Q=0A=
(or such codes, k source)-.165 E=0A=
(symbols are encoded into n > k encoding symbols, such that an)72 686.6=0A=
Q 2.75(yko)-.165 G 2.75(ft)-2.75 G(he encoding symbols can)-2.75 E=0A=
(be used to reassemble the original k source symbols.)72 699.6 Q=0A=
(Thus, these codes ha)5.5 E .33 -.165(ve n)-.22 H 2.75(or).165 G=0A=
(eception)-2.75 E -.165(ove)72 712.6 S=0A=
(rhead when used to encode the entire object directly).165 E 5.5(.B)=0A=
-.715 G(lock codes are usually systematic,)-5.5 E(which means that the \=0A=
n encoding symbols consist of the k source symbols and n-k redundant)72=0A=
725.6 Q(Luby/V)72 769 Q(icisano/Gemmell/Rizzo/Handle)-.66 E(y/Cro)-.165=0A=
E 109.106(wcroft Section)-.275 F 2.75(2.2. [P)2.75 F(age 5])-.165 E EP=0A=
%%Page: 6 6=0A=
%%BeginPageSetup=0A=
BP=0A=
%%EndPageSetup=0A=
/F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 77.081(-DRAFT Expires:)-1.012 F=0A=
(April 2002)2.75 E(October 2001)112.127 E(symbols generated from these \=0A=
k source symbols, where the size of a redundant symbol is the)72 85 Q=0A=
(same as that for a source symbol.)72 98 Q -.165(Fo)5.5 G 2.75(re).165 G=0A=
(xample, the \214rst simple code \(XOR\) described in the)-2.915 E(pre)=0A=
72 111 Q(vious subsection is a \(k+1, k\) code.)-.275 E=0A=
(In general, the freedom to choose n lar)5.5 E(ger than k+1 is)-.198 E=0A=
(desirable, as this can pro)72 124 Q(vide much better protection ag)=0A=
-.165 E(ainst losses.)-.055 E 2.75(Ap)5.5 G(opular e)-2.75 E=0A=
(xample of these)-.165 E(types of codes is a class of Reed-Solomon code\=0A=
s, which are based on algebraic methods using)72 137 Q=0A=
(\214nite \214elds.)72 150 Q=0A=
(Implementations of \(n, k\) FEC erasure codes are ef)5.5 E=0A=
(\214cient enough to be used by)-.275 E(personal computers [8]. F)72 163=0A=
Q(or e)-.165 E=0A=
(xample, [7] describes an implementation where the encoding and)-.165 E=0A=
(decoding speeds decay as C/j, where the constant C is on the order of \=0A=
10 to 80 Mbytes/second for)72 176 Q(Pentium class machines of v)72 189 Q=0A=
(arious vintages and j is upper bounded by min\(k, n-k\).)-.275 E=0A=
(In practice, the v)72 215 Q(alues of k and n must be small \(for e)=0A=
-.275 E(xample belo)-.165 E 2.75(w2)-.275 G(56\) for such FEC codes as)=0A=
-2.75 E(lar)72 228 Q(ge v)-.198 E(alues mak)-.275 E 2.75(ee)-.11 G=0A=
(ncoding and decoding prohibiti)-2.75 E -.165(ve)-.275 G(ly e).165 E=0A=
(xpensi)-.165 E -.165(ve)-.275 G 5.5(.A).165 G 2.75(sm)-5.5 G(an)-2.75 E=0A=
2.75(yo)-.165 G(bjects are longer)-2.75 E=0A=
(than k symbols for reasonable v)72 241 Q=0A=
(alues of k and the symbol length \(e.g. lar)-.275 E=0A=
(ger than 16 kilobyte for k)-.198 E 2.75(=3D1)72 254 S 2.75(6u)-2.75 G=0A=
(sing 1 kilobyte symbols\), the)-2.75 E 2.75(yc)-.165 G(an be di)-2.75 E=0A=
(vided into a number of source blocks.)-.275 E(Each source)5.5 E=0A=
(block consists of some number k of source symbols, where k may v)72 267=0A=
Q(ary between dif)-.275 E(ferent source)-.275 E 2.75(blocks. The)72 280=0A=
R(FEC encoder is used to encode a k source symbol source block into a n\=0A=
encoding)2.75 E(symbol encoding block, where the number n of encoding \=0A=
symbols in the encoding block may v)72 293 Q(ary)-.275 E=0A=
(for each source block.)72 306 Q -.165(Fo)5.5 G 2.75(rar).165 G(ecei)=0A=
-2.75 E -.165(ve)-.275 G 2.75(rt).165 G 2.75(oc)-2.75 G(ompletely reco)=0A=
-2.75 E -.165(ve)-.165 G 2.75(rt).165 G=0A=
(he object, for each source block)-2.75 E(consisting of k source symbol\=0A=
s, k distinct encoding symbols \(i.e., with dif)72 319 Q=0A=
(ferent encoding symbol)-.275 E(IDs\) must be recei)72 332 Q -.165(ve)=0A=
-.275 G 2.75(df).165 G(rom the corresponding encoding block.)-2.75 E=0A=
-.165(Fo)5.5 G 2.75(rs).165 G(ome encoding blocks, more)-2.75 E=0A=
(encoding symbols may be recei)72 345 Q -.165(ve)-.275 G 2.75(dt).165 G=0A=
(han there are source symbols in the corresponding source)-2.75 E=0A=
(block, in which case the e)72 358 Q=0A=
(xcess encoding symbols are discarded.)-.165 E(An e)5.5 E=0A=
(xample encoding structure)-.165 E(is sho)72 371 Q(wn in Figure 1.)-.275=0A=
E(Luby/V)72 769 Q(icisano/Gemmell/Rizzo/Handle)-.66 E(y/Cro)-.165 E=0A=
109.106(wcroft Section)-.275 F 2.75(2.2. [P)2.75 F(age 6])-.165 E EP=0A=
%%Page: 7 7=0A=
%%BeginPageSetup=0A=
BP=0A=
%%EndPageSetup=0A=
/F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 77.081(-DRAFT Expires:)-1.012 F=0A=
(April 2002)2.75 E(October 2001)112.127 E/F1 8/Courier@0 SF 14.4(|s)91.2=0A=
85 S(ource symbol IDs)-14.4 E 14.4(|s)14.4 G(ource symbols IDs)-14.4 E=0A=
(|)9.6 E 14.4(|o)91.2 98 S 4.8(fs)-14.4 G(ource block 0)-4.8 E 14.4(|o)=0A=
14.4 G 4.8(fs)-14.4 G(ource block 1)-4.8 E(|)14.4 E 124.8(||)153.6 111 S=0A=
124.8(vv)153.6 124 S(+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+)=0A=
91.2 137 Q(|0 |1 |2 |3 |4 |5 |6 |7 |0 |1 |2 |3 | 4|5 |6 |7 |)91.2 150 Q=0A=
(+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+)91.2 163 Q(|)206.4=0A=
176 Q(FEC encoder)187.2 189 Q(|)206.4 202 Q(v)206.4 215 Q=0A=
(+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+)72 228 Q=0A=
(|0 |1 |2 |3 | 4| 5| 6| 7| 8| 9| 0| 1| 2| 3| 4| 5| 6| 7| 8| 9|)72 241 Q=0A=
(+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+)72 254 Q=0A=
139.2(^^)144 267 S 139.2(||)144 280 S 9.6(|e)72 293 S=0A=
(ncoding symbol IDs)-9.6 E 4.8(|e)38.4 G(ncoding symbol IDs)-4.8 E(|)=0A=
43.2 E 9.6(|o)72 306 S 4.8(fe)-9.6 G(ncoding block 0)-4.8 E 4.8(|o)38.4=0A=
G 4.8(fe)-4.8 G(ncoding block 1)-4.8 E(|)43.2 E/F2 10/Times-Roman@0 SF=0A=
(Figure 1. Encoding structure for object di)72 345 Q(vided into tw)-.25=0A=
E 2.5(os)-.1 G(ource)-2.5 E(blocks consisting of 8 source symbols each,\=0A=
and the FEC encoder is used to)72 358 Q(generate 2 additional redundan\=0A=
t symbols \(10 encoding symbols in total\))72 371 Q(for each of the tw)=0A=
72 384 Q 2.5(os)-.1 G(ource blocks.)-2.5 E F0(In man)72 413.6 Q 2.75(yc)=0A=
-.165 G(ases, an object is partitioned into equal length source blocks \=0A=
each consisting of k)-2.75 E(contiguous source symbols of the object, i\=0A=
.e., block c consists of the range of source symbols [ck,)72 426.6 Q=0A=
2.75(\(c+1\)k-1]. This)72 439.6 R(ensures that the FEC encoder can be o\=0A=
ptimized to handle a particular number k)2.75 E(of source symbols.)72=0A=
452.6 Q(This also ensures that memory references are local when the sen\=0A=
der reads)5.5 E(source symbols to encode, and when the recei)72 465.6 Q=0A=
-.165(ve)-.275 G 2.75(rr).165 G(eads encoding symbols to decode.)-2.75 E=0A=
(Locality of)5.5 E(reference is particularly important when the object \=0A=
is stored on disk, as it reduces the disk seeks)72 478.6 Q 2.75=0A=
(required. The)72 491.6 R(block number and the source symbol ID within \=0A=
that block can be used to uniquely)2.75 E(specify a source symbol withi\=0A=
n the object. If the size of the object is not a multiple of k source)72=0A=
504.6 Q=0A=
(symbols, then the last source block will contain less than k symbols.)=0A=
72 517.6 Q(The block numbers can be numbered consecuti)72 543.6 Q -.165=0A=
(ve)-.275 G(ly starting from zero.).165 E(Encoding symbols within)5.5 E=0A=
2.75(ab)72 556.6 S=0A=
(lock can be uniquely identi\214ed by an encoding symbol ID.)-2.75 E=0A=
(One w)5.5 E(ay of identifying encoding)-.11 E(symbols within a block i\=0A=
s to use the combination of an encoding \215ag that identi\214es the sy\=0A=
mbol as)72 569.6 Q(either a source symbol or a redundant symbol togethe\=0A=
r with either a source symbol ID or a)72 582.6 Q(redundant symbol ID.)72=0A=
595.6 Q -.165(Fo)5.5 G 2.75(re).165 G(xample, an encoding \215ag v)=0A=
-2.915 E(alue of 1 can indicate that the encoding)-.275 E(symbol is a s\=0A=
ource symbol and 0 can indicate that it is a redundant symbol.)72 608.6=0A=
Q(The source symbol)5.5 E(IDs can be numbered from 0 to k-1 and the red\=0A=
undant symbol IDs can be numbered from 0 to n-)72 621.6 Q(k-1.)72 634.6=0A=
Q -.165(Fo)72 660.6 S 2.75(re).165 G=0A=
(xample, if the object consists 10 source symbols with v)-2.915 E=0A=
(alues a, b, c, d, e, f, g, h, i, and j, and)-.275 E 2.75(k=3D5a)72 673.6=0A=
S(nd n =3D 8, then there are tw)-2.75 E 2.75(os)-.11 G=0A=
(ource blocks consisting of 5 symbols each, and there are tw)-2.75 E(o)=0A=
-.11 E(encoding blocks consisting of 8 symbols each.)72 686.6 Q=0A=
(Let p, q and r be the v)5.5 E(alues of the redundant)-.275 E=0A=
(symbols for the \214rst encoding block, and let x, y and z be the v)72=0A=
699.6 Q(alues of the redundant symbols for)-.275 E=0A=
(the second encoding block.)72 712.6 Q=0A=
(Then the encoding symbols together with their identi\214ers are)5.5 E=0A=
(Luby/V)72 769 Q(icisano/Gemmell/Rizzo/Handle)-.66 E(y/Cro)-.165 E=0A=
109.106(wcroft Section)-.275 F 2.75(2.2. [P)2.75 F(age 7])-.165 E EP=0A=
%%Page: 8 8=0A=
%%BeginPageSetup=0A=
BP=0A=
%%EndPageSetup=0A=
/F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 77.081(-DRAFT Expires:)-1.012 F=0A=
(April 2002)2.75 E(October 2001)112.127 E/F1 8/Courier@0 SF(\(0, 1, 0: \=0A=
a\), \(0, 1, 1: b\), \(0, 1, 2: c\), \(0, 1, 3: d\), \(0, 1, 4: e\),)72=0A=
85 Q(\(0, 0, 0: p\), \(0, 0, 1: q\), \(0, 0, 2: r\),)72 98 Q(\(1, 1, 0:\=0A=
f\), \(1, 1, 1: g\), \(1, 1, 2: h\), \(1, 1, 3: i\), \(1, 1, 4: j\),)72=0A=
111 Q(\(1, 0, 0: x\), \(1, 0, 1: y\), \(1, 0, 2: z\).)72 124 Q/F2 10=0A=
/Times-Roman@0 SF(In this e)72 163 Q(xample, the \214rst v)-.15 E=0A=
(alue identi\214es the block number and the second tw)-.25 E 2.5(ov)-.1=0A=
G(alues together identify the)-2.75 E(encoding symbol within the block,\=0A=
i.e, the encoding symbol ID consists of the encoding \215ag together w\=0A=
ith)72 176 Q(either the source symbol ID or the redundant symbol ID dep\=0A=
ending on the v)72 189 Q(alue of the encoding \215ag.)-.25 E(The)5 E=0A=
-.25(va)72 202 S(lue of the encoding symbol is written after the colon.)=0A=
.25 E(Each block can be reco)5 E -.15(ve)-.15 G(red from an).15 E 2.5=0A=
(y5o)-.15 G 2.5(ft)-2.5 G(he 8)-2.5 E=0A=
(encoding symbols associated with that block.)72 215 Q -.15(Fo)5 G 2.5=0A=
(re).15 G(xample, reception of)-2.65 E/F3 10/Courier@0 SF(\(0, 1, 1: b\=0A=
\), \(0, 1, 2: c\), \(0, 1, 3: d\), \(0, 0, 0: p\), \(0, 0, 1: q\))84=0A=
241 Q F2(is suf)74.5 267 Q(\214cient to reco)-.25 E -.15(ve)-.15 G 2.5=0A=
(rt).15 G(he \214rst source block, and reception of)-2.5 E F3(\(1, 1, 0\=0A=
: f\), \(1, 1, 1: g\), \(1, 0, 0: x\), \(1, 0, 1: y\), \(1, 0, 2: z\))84=0A=
293 Q F2(is suf)72 332 Q(\214cient to reco)-.25 E -.15(ve)-.15 G 2.5(rt)=0A=
.15 G(he second source block.)-2.5 E(Another w)72 358 Q(ay of uniquely \=0A=
identifying encoding symbols within a block is to let the encoding symb\=0A=
ol IDs for)-.1 E(source symbols be 0,...,k-1 and to let the encoding sy\=0A=
mbol IDs for redundant symbols be k,...,n-1.)72 371 Q/F4 11/Times-Bold@0=0A=
SF(2.3.)72 410 Q/F5 13/Times-Bold@0 SF(Lar)5.5 E(ge block FEC codes)-.13=0A=
E F0 -.88(To)72 426.6 S(rnado codes [4] are lar).88 E=0A=
(ge block FEC codes that pro)-.198 E(vide an alternati)-.165 E .33 -.165=0A=
(ve t)-.275 H 2.75(os).165 G(mall block FEC)-2.75 E 2.75(codes. An)72=0A=
439.6 R(\(n, k\) T)2.75 E(ornado code requires slightly more than k out\=0A=
of n encoding symbols to reco)-.88 E -.165(ve)-.165 G(r).165 E 2.75(ks)=0A=
72 452.6 S(ource symbols, i.e., there is a small reception o)-2.75 E=0A=
-.165(ve)-.165 G 2.75(rhead. Ho).165 F(we)-.275 E -.165(ve)-.275 G .88=0A=
-.44(r, t).165 H(he adv).44 E(antage is that the)-.275 E -.275(va)72=0A=
465.6 S=0A=
(lue of k may be on the order of tens of thousands and still run ef).275=0A=
E(\214ciently)-.275 E 5.5(.B)-.715 G(ecause of memory)-5.5 E=0A=
(considerations, in practice the v)72 478.6 Q=0A=
(alue of n is restricted to be a small multiple of k, e.g., n =3D 2k.)=0A=
-.275 E -.165(Fo)5.5 G(r).165 E -.165(ex)72 491.6 S=0A=
(ample, [3] describes an implementation of T).165 E=0A=
(ornado codes where the encoding and decoding)-.88 E=0A=
(speeds are tens of me)72 504.6 Q -.055(ga)-.165 G=0A=
(bytes per second for Pentium class machines of v).055 E=0A=
(arious vintages when k)-.275 E(is in the tens of thousands and n =3D =
2k.)=0A=
72 517.6 Q(The reception o)5.5 E -.165(ve)-.165 G(rhead for such v).165=0A=
E(alues of k and n is in the)-.275 E(5-10% range.)72 530.6 Q -.88(To)5.5=0A=
G(rnado codes require a lar).88 E=0A=
(ge amount of out of band information to be)-.198 E=0A=
(communicated to all senders and recei)72 543.6 Q -.165(ve)-.275 G=0A=
(rs for each dif).165 E(ferent object length, and require an amount)=0A=
-.275 E(of memory on the encoder and decoder which is proportional to t\=0A=
he object length times 2n/k.)72 556.6 Q -.88(To)72 582.6 S=0A=
(rnado codes are designed to ha).88 E .33 -.165(ve l)-.22 H .55 -.275=0A=
(ow r).165 H(eception o).275 E -.165(ve)-.165 G(rhead on a).165 E -.165=0A=
(ve)-.22 G(rage with respect to reception).165 E=0A=
(of a random portion of the encoding pack)72 595.6 Q 2.75(ets. Thus,)=0A=
-.11 F(to ensure that a recei)2.75 E -.165(ve)-.275 G 2.75(rc).165 G=0A=
(an reassemble the)-2.75 E(object with lo)72 608.6 Q 2.75(wr)-.275 G=0A=
(eception o)-2.75 E -.165(ve)-.165 G(rhead, the pack).165 E=0A=
(ets are permuted into a random order before)-.11 E(transmission.)72=0A=
621.6 Q F4(2.4.)72 660.6 Q F5(Expandable FEC codes)5.5 E F0=0A=
(All of the FEC codes described up to this point are block codes.)72=0A=
677.2 Q(There is a dif)5.5 E(ferent type of FEC)-.275 E=0A=
(codes that we call e)72 690.2 Q(xpandable FEC codes.)-.165 E(Lik)5.5 E=0A=
2.75(eb)-.11 G(lock codes, an e)-2.75 E(xpandable FEC encoder)-.165 E=0A=
(operates on an object of kno)72 703.2 Q=0A=
(wn size that is partitioned into equal length source symbols.)-.275 E=0A=
(Unlik)5.5 E(e)-.11 E(block codes, there is no predetermined number of \=0A=
encoding symbols that can be generated for)72 716.2 Q(Luby/V)72 769 Q=0A=
(icisano/Gemmell/Rizzo/Handle)-.66 E(y/Cro)-.165 E 109.106=0A=
(wcroft Section)-.275 F 2.75(2.4. [P)2.75 F(age 8])-.165 E EP=0A=
%%Page: 9 9=0A=
%%BeginPageSetup=0A=
BP=0A=
%%EndPageSetup=0A=
/F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 77.081(-DRAFT Expires:)-1.012 F=0A=
(April 2002)2.75 E(October 2001)112.127 E -.165(ex)72 85 S=0A=
(pandable FEC codes. Instead, an e).165 E=0A=
(xpandable FEC encoder can generate as fe)-.165 E 2.75(wo)-.275 G 2.75=0A=
(ra)-2.75 G 2.75(sm)-2.75 G(an)-2.75 E(y)-.165 E=0A=
(unique encoding symbols as required on demand.)72 98 Q 2.024 -1.012=0A=
(LT c)72 124 T(odes [5] are an e)1.012 E(xample of lar)-.165 E(ge e)=0A=
-.198 E(xpandable FEC codes with a small reception o)-.165 E -.165(ve)=0A=
-.165 G 2.75(rhead. An).165 F 2.024 -1.012(LT e)72 137 T(ncoder uses ra\=0A=
ndomization to generate each encoding symbol randomly and independently\=0A=
of)1.012 E(all other encoding symbols.)72 150 Q(Lik)5.5 E 2.75(eT)-.11=0A=
G(ornado codes, the number of source symbols k may be v)-3.63 E(ery)=0A=
-.165 E(lar)72 163 Q(ge for L)-.198 E 2.75(Tc)-1.012 G(odes, i.e., on t\=0A=
he order of tens to hundreds of thousands, and the encoder and)-2.75 E=0A=
(decoder run ef)72 176 Q(\214ciently in softw)-.275 E(are. F)-.11 E=0A=
(or e)-.165 E(xample the encoding and decoding speeds for L)-.165 E 2.75=0A=
(Tc)-1.012 G(odes)-2.75 E(are in the range 3-20 me)72 189 Q -.055(ga)=0A=
-.165 G(bytes per second for Pentium class machines of v).055 E=0A=
(arious vintages when)-.275 E 2.75(ki)72 202 S 2.75(si)-2.75 G 2.75(nt)=0A=
-2.75 G(he high tens of thousands.)-2.75 E(An L)5.5 E 2.75(Te)-1.012 G=0A=
(ncoder can generate as fe)-2.75 E 2.75(wo)-.275 G 2.75(ra)-2.75 G 2.75=0A=
(sm)-2.75 G(an)-2.75 E 2.75(ye)-.165 G(ncoding)-2.75 E=0A=
(symbols as required on demand.)72 215 Q(When a ne)5.5 E 2.75(we)-.275 G=0A=
(ncoding symbol is to be generated by an L)-2.75 E(T)-1.012 E(encoder)72=0A=
228 Q 2.75(,i)-.44 G 2.75(ti)-2.75 G 2.75(sb)-2.75 G(ased on a randomly\=0A=
chosen encoding symbol ID that uniquely describes ho)-2.75 E 2.75(wt)=0A=
-.275 G(he)-2.75 E(encoding symbol is to be generated from the source s\=0A=
ymbols. In general, each encoding symbol)72 241 Q(ID v)72 254 Q(alue co\=0A=
rresponds to a unique encoding symbol, and thus the space of possible e\=0A=
ncoding)-.275 E(symbols is approximately four billion if for e)72 267 Q=0A=
(xample the encoding symbol ID is 4 bytes.)-.165 E(Thus,)5.5 E=0A=
(the chance that a particular encoding symbol is the same as an)72 280 Q=0A=
2.75(yo)-.165 G(ther particular encoding symbol)-2.75 E(is in)72 293 Q=0A=
-.165(ve)-.44 G=0A=
(rsely proportional to the number of possible encoding symbol IDs.).165=0A=
E(An L)5.5 E 2.75(Td)-1.012 G(ecoder has the)-2.75 E=0A=
(property that with v)72 306 Q(ery high probability the receipt of an)=0A=
-.165 E 2.75(ys)-.165 G(et of slightly more than k randomly)-2.75 E=0A=
(and independently generated encoding symbols is suf)72 319 Q=0A=
(\214cient to reassemble the k source symbols.)-.275 E -.165(Fo)72 332 S=0A=
2.75(re).165 G(xample, when k is on the order of tens to hundreds of th\=0A=
ousands the reception o)-2.915 E -.165(ve)-.165 G(rhead is).165 E=0A=
(less than 5% with no f)72 345 Q=0A=
(ailures in hundreds of millions of trials under an)-.11 E 2.75(yl)-.165=0A=
G(oss conditions.)-2.75 E(Because encoding symbols are randomly and ind\=0A=
ependently generated by choosing random)72 371 Q(encoding symbol IDs, L)=0A=
72 384 Q 2.75(Tc)-1.012 G(odes ha)-2.75 E .33 -.165(ve t)-.22 H=0A=
(he property that encoding symbols for the same k source).165 E(symbols\=0A=
can be generated and transmitted from multiple senders and recei)72 397=0A=
Q -.165(ve)-.275 G 2.75(db).165 G 2.75(yar)-2.75 G(ecei)-2.75 E -.165=0A=
(ve)-.275 G 2.75(ra).165 G(nd)-2.75 E(the reception o)72 410 Q -.165(ve)=0A=
-.165 G(rhead and the decoding time is the same as if though all the en\=0A=
coding symbols).165 E(were generated by a single sender)72 423 Q 5.5(.T)=0A=
-.605 G(he only requirement is that the senders choose their)-5.5 E=0A=
(encoding symbol IDs randomly and independently of one another)72 436 Q=0A=
(.)-.605 E(There is a weak tradeof)72 462 Q 2.75(fb)-.275 G=0A=
(etween the number of source symbols and the reception o)-2.75 E -.165=0A=
(ve)-.165 G(rhead for).165 E 2.024 -1.012(LT c)72 475 T=0A=
(odes, and the lar)1.012 E=0A=
(ger the number of source symbols the smaller the reception o)-.198 E=0A=
-.165(ve)-.165 G 2.75(rhead. Thus,).165 F=0A=
(for shorter objects, it is sometimes adv)72 488 Q=0A=
(antageous to partition the object into man)-.275 E 2.75(ys)-.165 G=0A=
(hort source)-2.75 E=0A=
(symbols and include multiple encoding symbols in each pack)72 501 Q=0A=
2.75(et. In)-.11 F(this case, a single encoding)2.75 E(symbol ID is use\=0A=
d to identify the multiple encoding symbols contained in a single pack)=0A=
72 514 Q(et.)-.11 E(There are a couple of f)72 540 Q=0A=
(actors for choosing the appropriate symbol length/ number of source)=0A=
-.11 E(symbols tradeof)72 553 Q=0A=
(f. The primary consideration is that there is a \214x)-.275 E(ed o)=0A=
-.165 E -.165(ve)-.165 G(rhead per symbol in the).165 E -.165(ove)72 566=0A=
S(rall processing requirements of the encoding and decoding, independen\=0A=
t of the number of).165 E(source symbols.)72 579 Q=0A=
(Thus, using shorter symbols means that this \214x)5.5 E(ed o)-.165 E=0A=
-.165(ve)-.165 G(rhead processing per).165 E(symbol will be a lar)72 592=0A=
Q(ger component of the o)-.198 E -.165(ve)-.165 G=0A=
(rall processing requirements, leading to lar).165 E(ger)-.198 E -.165=0A=
(ove)72 605 S(rall processing requirements.).165 E 2.75(As)5.5 G=0A=
(econd much less important consideration is that there is a)-2.75 E=0A=
(component of the processing per symbol that depends log)72 618 Q=0A=
(arithmically on the number of source)-.055 E=0A=
(symbols, and thus for this reason there is a slight preference to)72=0A=
631 Q -.11(wa)-.275 G(rds fe).11 E(wer source symbols.)-.275 E(Lik)72=0A=
657 Q 2.75(es)-.11 G=0A=
(mall block codes, there is a point when the object is lar)-2.75 E=0A=
(ge enough that it mak)-.198 E(es sense to)-.11 E=0A=
(partition it into blocks when using L)72 670 Q 2.75(Tc)-1.012 G 2.75=0A=
(odes. Generally)-2.75 F(the object is partitioned into blocks)2.75 E=0A=
(whene)72 683 Q -.165(ve)-.275 G 2.75(rt).165 G=0A=
(he number of source symbols times the pack)-2.75 E=0A=
(et payload length is less than the size of)-.11 E(the object.)72 696 Q=0A=
(Thus, if the pack)5.5 E=0A=
(et payload is 1024 bytes and the maximum number of source)-.11 E=0A=
(symbols is 128,000 then an)72 709 Q 2.75(yo)-.165 G(bject o)-2.75 E=0A=
-.165(ve)-.165 G 2.75(r1).165 G(28 me)-2.75 E -.055(ga)-.165 G=0A=
(bytes will be partitioned into more than one).055 E 2.75(block. One)72=0A=
722 R(can choose the maximum number of source symbols to use, depending\=0A=
on the desired)2.75 E(Luby/V)72 769 Q(icisano/Gemmell/Rizzo/Handle)-.66=0A=
E(y/Cro)-.165 E 109.106(wcroft Section)-.275 F 2.75(2.4. [P)2.75 F=0A=
(age 9])-.165 E EP=0A=
%%Page: 10 10=0A=
%%BeginPageSetup=0A=
BP=0A=
%%EndPageSetup=0A=
/F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 77.081(-DRAFT Expires:)-1.012 F=0A=
(April 2002)2.75 E(October 2001)112.127 E(encoding and decoding speed v)=0A=
72 85 Q(ersus reception o)-.165 E -.165(ve)-.165 G(rhead tradeof).165 E=0A=
2.75(fd)-.275 G 2.75(esired. Encoding)-2.75 F(symbols can)2.75 E=0A=
(be uniquely identi\214ed by a block number \(when the object is lar)72=0A=
98 Q(ge enough to be partitioned into)-.198 E=0A=
(more than one block\) and an encoding symbol ID.)72 111 Q=0A=
(The block numbers, if the)5.5 E 2.75(ya)-.165 G(re used, are)-2.75 E=0A=
(generally numbered consecuti)72 124 Q -.165(ve)-.275 G=0A=
(ly starting from zero within the object. The block number and the).165=0A=
E(encoding symbol ID are both chosen uniformly and randomly from their \=0A=
range when an encoding)72 137 Q(symbol is to be transmitted. F)72 150 Q=0A=
(or e)-.165 E=0A=
(xample, suppose the number of source symbols is 128,000 and)-.165 E=0A=
(the number of blocks is 2.)72 163 Q(Then, each pack)5.5 E=0A=
(et generated by the L)-.11 E 2.75(Te)-1.012 G=0A=
(ncoder could be of the form)-2.75 E(\(b, x: y\).)72 176 Q(In this e)5.5=0A=
E(xample, the \214rst v)-.165 E=0A=
(alue identi\214es the block number and the second v)-.275 E(alue)-.275=0A=
E(identi\214es the encoding symbol within the block.)72 189 Q(In this e)=0A=
5.5 E(xample, the block number b is either 0)-.165 E=0A=
(or 1, and the encoding symbol ID x might be a 32-bit v)72 202 Q 2.75=0A=
(alue. The)-.275 F -.275(va)2.75 G(lue y after the colon is the).275 E=0A=
-.275(va)72 215 S(lue of the encoding symbol.).275 E/F1 11/Times-Bold@0=0A=
SF(2.5.)72 254 Q/F2 13/Times-Bold@0 SF(Sour)5.5 E(ce blocks with v)-.234=0A=
E(ariable length sour)-.13 E(ce symbols)-.234 E F0 -.165(Fo)72 270.6 S=0A=
2.75(ra).165 G(ll the FEC codes described abo)-2.75 E -.165(ve)-.165 G=0A=
2.75(,a).165 G=0A=
(ll the source symbols in the same source block are all of)-2.75 E=0A=
(the same length.)72 283.6 Q(In this section, we describe a general tec\=0A=
hnique to handle the case when it is)5.5 E=0A=
(desirable to use source symbols of v)72 296.6 Q=0A=
(arying lengths in a single source block.)-.275 E(This technique is)5.5=0A=
E(applicable to block FEC codes.)72 309.6 Q=0A=
(Let l_1, l_2, ... , l_k be the lengths in bytes of k v)72 335.6 Q=0A=
(arying length source symbols to be considered)-.275 E=0A=
(part of the same source block.)72 348.6 Q(Let lmax be the maximum o)5.5=0A=
E -.165(ve)-.165 G 2.75(ri=3D1).165 G 2.75(,.)-2.75 G(.. , k of =
l_i.)-2.75=0A=
E 1.76 -.88(To p)5.5 H(repare the).88 E=0A=
(source block for the FEC encoder)72 361.6 Q 2.75(,p)-.44 G=0A=
(ad each source symbol i out to length lmax with a suf)-2.75 E(\214x of)=0A=
-.275 E(lmax-l_i zeroes, and then prepend to the be)72 374.6 Q=0A=
(ginning of this the v)-.165 E(alue l_i.)-.275 E(Thus, each padded)5.5 E=0A=
(source symbol is of length x+lmax, assuming that it tak)72 387.6 Q=0A=
(es x bytes to store an inte)-.11 E(ger with possible)-.165 E -.275(va)=0A=
72 400.6 S(lues 0,...,lmax, where x is a protocol constant kno).275 E=0A=
(wn to both the encoder and the decoder)-.275 E(.)-.605 E(These padded \=0A=
source symbols, each of length x+lmax, are the input to the encoder)72=0A=
413.6 Q 2.75(,t)-.44 G(ogether with)-2.75 E(the v)72 426.6 Q(alue n.)=0A=
-.275 E(The encoder then generates n-k redundant symbols, each of lengt\=0A=
h x+lmax.)5.5 E(The encoding symbols that are placed into pack)72 452.6=0A=
Q(ets consist of the original k v)-.11 E(arying length source)-.275 E=0A=
(symbols and n-k redundant symbols, each of length x+lmax.)72 465.6 Q=0A=
(From an)5.5 E 2.75(yko)-.165 G 2.75(ft)-2.75 G(he recei)-2.75 E -.165=0A=
(ve)-.275 G(d).165 E(encoding symbols, the FEC decoder recreates the k \=0A=
original source symbols as follo)72 478.6 Q 2.75(ws. If)-.275 F(all k)=0A=
2.75 E(original source symbols are recei)72 491.6 Q -.165(ve)-.275 G=0A=
(d, then no decoding is necessary).165 E 5.5(.O)-.715 G=0A=
(therwise, at least one)-5.5 E(redundant symbol is recei)72 504.6 Q=0A=
-.165(ve)-.275 G(d, from which the recei).165 E -.165(ve)-.275 G 2.75=0A=
(rc).165 G(an easily determine if the block is)-2.75 E(composed of v)72=0A=
517.6 Q(ariable-length source symbols: if the redundant symbol\(s\) is \=0A=
longer than the source)-.275 E(symbols then the source symbols are v)72=0A=
530.6 Q(ariable-length. Note that in a v)-.275 E=0A=
(ariable-length block the)-.275 E(redundant symbols are al)72 543.6 Q=0A=
-.11(wa)-.11 G=0A=
(ys longer than the longest source symbol, due to the presence of the)=0A=
.11 E(prepended symbol-length.)72 556.6 Q(The recei)5.5 E -.165(ve)-.275=0A=
G 2.75(rc).165 G(an determine the v)-2.75 E=0A=
(alue of lmax by subtracting x from)-.275 E(the length of a recei)72=0A=
569.6 Q -.165(ve)-.275 G 2.75(dr).165 G(edundant symbol.)-2.75 E -.165=0A=
(Fo)5.5 G 2.75(re).165 G(ach of the recei)-2.75 E -.165(ve)-.275 G 2.75=0A=
(do).165 G(riginal source symbols, the)-2.75 E(recei)72 582.6 Q -.165=0A=
(ve)-.275 G 2.75(rc).165 G=0A=
(an generate the corresponding padded source symbol as described abo)=0A=
-2.75 E -.165(ve)-.165 G 5.5(.T).165 G(hen, the)-5.5 E=0A=
(input to the FEC decoder is the set of recei)72 595.6 Q -.165(ve)-.275=0A=
G 2.75(dr).165 G(edundant symbols, together with the set of padded)-2.75=0A=
E(source symbols constructed from the recei)72 608.6 Q -.165(ve)-.275 G=0A=
2.75(do).165 G(riginal symbols.)-2.75 E(The FEC decoder then produces)=0A=
5.5 E(the set of k padded source symbols.)72 621.6 Q=0A=
(Once the k padded source symbols ha)5.5 E .33 -.165(ve b)-.22 H=0A=
(een reco).165 E -.165(ve)-.165 G(red, the).165 E=0A=
(length l_i of original source symbol i can be reco)72 634.6 Q -.165(ve)=0A=
-.165 G(red from the \214rst x bytes of the ith padded).165 E(source sy\=0A=
mbol, and then original source symbol i is obtained by taking the ne)72=0A=
647.6 Q(xt l_i bytes)-.165 E(follo)72 660.6 Q=0A=
(wing the x bytes of the length \214eld.)-.275 E(Luby/V)72 769 Q=0A=
(icisano/Gemmell/Rizzo/Handle)-.66 E(y/Cro)-.165 E 103.606=0A=
(wcroft Section)-.275 F 2.75(2.5. [P)2.75 F(age 10])-.165 E EP=0A=
%%Page: 11 11=0A=
%%BeginPageSetup=0A=
BP=0A=
%%EndPageSetup=0A=
/F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 77.081(-DRAFT Expires:)-1.012 F=0A=
(April 2002)2.75 E(October 2001)112.127 E/F1 11/Times-Bold@0 SF(3.)72 85=0A=
Q/F2 14/Times-Bold@0 SF(Security Considerations)5.5 E F0(The use of FEC\=0A=
, in and of itself, imposes no additional security considerations v)72=0A=
101.6 Q(ersus sending the)-.165 E(same information without FEC.)72 114.6=0A=
Q(Ho)5.5 E(we)-.275 E -.165(ve)-.275 G .88 -.44(r, j).165 H(ust lik).44=0A=
E 2.75(ef)-.11 G(or an)-2.75 E 2.75(yt)-.165 G=0A=
(ransmission system, a malicious)-2.75 E(sender may try to inject pack)=0A=
72 127.6 Q(ets carrying corrupted encoding symbols.)-.11 E(If a recei)=0A=
5.5 E -.165(ve)-.275 G 2.75(ra).165 G(ccepts one)-2.75 E(or more corrup\=0A=
ted encoding symbol in place of authentic ones then such a recei)72=0A=
140.6 Q -.165(ve)-.275 G 2.75(rm).165 G(ay)-2.75 E=0A=
(reconstruct a corrupted object.)72 153.6 Q(Application-le)72 179.6 Q=0A=
-.165(ve)-.275 G 2.75(lt).165 G=0A=
(ransmission object authentication can detect the corrupted transfer)=0A=
-2.75 E 2.75(,b)-.44 G(ut the)-2.97 E(recei)72 192.6 Q -.165(ve)-.275 G=0A=
2.75(rm).165 G(ust then discard the transferred object. Thus, injecting\=0A=
corrupted encoding symbols the)-2.75 E(y)-.165 E(are accepted as v)72=0A=
205.6 Q(alid encoding symbols by a recei)-.275 E -.165(ve)-.275 G 2.75=0A=
(ri).165 G 2.75(sa)-2.75 G 2.75(tt)-2.75 G(he v)-2.75 E(ery least an ef)=0A=
-.165 E(fecti)-.275 E .33 -.165(ve d)-.275 H(enial of).165 E=0A=
(service attack.)72 218.6 Q(In light of this possibility)72 244.6 Q 2.75=0A=
(,F)-.715 G(EC recei)-2.75 E -.165(ve)-.275 G=0A=
(rs may screen the source address of a recei).165 E -.165(ve)-.275 G=0A=
2.75(ds).165 G(ymbol)-2.75 E(ag)72 257.6 Q=0A=
(ainst a list of authentic transmitter addresses.)-.055 E=0A=
(Since source addresses may be spoofed, transport)5.5 E=0A=
(protocols using FEC may pro)72 270.6 Q(vide mechanisms for rob)-.165 E=0A=
(ust source authentication of each encoding)-.22 E=0A=
(symbol. Multicast routers along the path of a FEC transfer may pro)72=0A=
283.6 Q(vide the capability of)-.165 E(discarding multicast pack)72=0A=
296.6 Q(ets that originated on that subnet, and whose source IP address\=0A=
does not)-.11 E(correspond with that subnet.)72 309.6 Q=0A=
(It is recommended that a pack)72 335.6 Q=0A=
(et authentication scheme such as TESLA [6] be used in conjunction)-.11=0A=
E(with FEC codes.)72 348.6 Q(Then, pack)5.5 E=0A=
(ets that cannot be authenticated can be discarded and the object can)=0A=
-.11 E(be reliably reco)72 361.6 Q -.165(ve)-.165 G(red from the recei)=0A=
.165 E -.165(ve)-.275 G 2.75(da).165 G(uthenticated pack)-2.75 E(ets.)=0A=
-.11 E F1(4.)72 400.6 Q F2(Intellectual Pr)5.5 E(operty Disclosur)-.252=0A=
E(e)-.252 E F0 -.88(To)72 417.2 S(rnado codes [4] ha).88 E .33 -.165=0A=
(ve b)-.22 H(oth patents issued and patents pending.).165 E=0A=
(There is an issued patent for L)5.5 E(T)-1.012 E(codes [5].)72 430.2 Q=0A=
F1(5.)72 456.2 Q F2(Ackno)5.5 E(wledgments)-.14 E F0(Thanks to V)72=0A=
472.8 Q(incent Roca and Hayder Radha for their detailed comments on thi\=0A=
s draft.)-.66 E F1(6.)72 511.8 Q F2(Refer)5.5 E(ences)-.252 E F0=0A=
([1] Acharya, S., Franklin, M., and Zdonik, S., `)72 528.4 Q=0A=
(`Dissemination- Based Data Deli)-.814 E -.165(ve)-.275 G(ry Using).165=0A=
E(Broadcast Disks')72 541.4 Q=0A=
(', IEEE Personal Communications, pp.50-60, Dec 1995.)-.814 E=0A=
([2] Blahut, R.E., `)72 567.4 Q=0A=
(`Theory and Practice of Error Control Codes')-.814 E(', Addison W)-.814=0A=
E(esle)-.88 E 1.43 -.715(y, M)-.165 H 2.75(A1).715 G(984.)-2.75 E=0A=
([3] Byers, J.W)72 593.4 Q(., Luby)-1.012 E 2.75(,M)-.715 G=0A=
(., Mitzenmacher)-2.75 E 2.75(,M)-.44 G(., and Re)-2.75 E(ge, A., `)=0A=
-.165 E 1.76 -.88(`A D)-.814 H(igital F).88 E(ountain Approach to)-.165=0A=
E(Reliable Distrib)72 606.4 Q(ution of Bulk Data')-.22 E=0A=
(', Proceedings A)-.814 E(CM SIGCOMM '98, V)-.44 E(ancouv)-1.221 E(er)=0A=
-.165 E 2.75(,C)-.44 G(anada,)-2.75 E(Sept 1998.)72 619.4 Q([4] Luby)72=0A=
645.4 Q 2.75(,M)-.715 G(., Mitzenmacher)-2.75 E 2.75(,M)-.44 G=0A=
(., Shokrollahi, A., Spielman, D., `)-2.75 E(`Ef)-.814 E=0A=
(\214cient Erasure Correcting)-.275 E(Codes')72 658.4 Q(', IEEE T)-.814=0A=
E(ransactions on Information Theory)-.385 E 2.75(,S)-.715 G=0A=
(pecial Issue: Codes on Graphs and Iterati)-2.75 E -.165(ve)-.275 G=0A=
(Algorithms, pp. 569-584, V)72 671.4 Q(ol. 47, No. 2, February 2001.)=0A=
-1.419 E([5] Luby)72 697.4 Q 2.75(,M)-.715 G(., "Information Additi)=0A=
-2.75 E .33 -.165(ve C)-.275 H=0A=
(ode Generator and Decoder for Communication Systems",).165 E(U.S. P)72=0A=
710.4 Q(atent No. 6,307,487, October 23, 2001.)-.165 E(Luby/V)72 769 Q=0A=
(icisano/Gemmell/Rizzo/Handle)-.66 E(y/Cro)-.165 E 111.856=0A=
(wcroft Section)-.275 F 2.75(6. [P)2.75 F(age 11])-.165 E EP=0A=
%%Page: 12 12=0A=
%%BeginPageSetup=0A=
BP=0A=
%%EndPageSetup=0A=
/F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 77.081(-DRAFT Expires:)-1.012 F=0A=
(April 2002)2.75 E(October 2001)112.127 E=0A=
([6] Perrig, A., Canetti, R., Song, D., T)72 85 Q(yg)-.88 E(ar)-.055 E=0A=
2.75(,J)-.44 G(.D., "Ef)-2.75 E=0A=
(\214cient and Secure Source Authentication for)-.275 E=0A=
(Multicast", Netw)72 98 Q(ork and Distrib)-.11 E=0A=
(uted System Security Symposium, NDSS 2001, pp. 35-46,)-.22 E=0A=
(February 2001.)72 111 Q([7] Rizzo, L., `)72 137 Q(`Ef)-.814 E(fecti)=0A=
-.275 E .33 -.165(ve E)-.275 H=0A=
(rasure Codes for Reliable Computer Communication Protocols').165 E=0A=
(', A)-.814 E(CM)-.44 E(SIGCOMM Computer Communication Re)72 150 Q(vie)=0A=
-.275 E 1.43 -.715(w, V)-.275 H(ol.27, No.2, pp.24-36, Apr 1997.)-.704 E=0A=
([8] Rizzo, L., `)72 176 Q(`On the Feasibility of Softw)-.814 E=0A=
(are FEC')-.11 E(', DEIT T)-.814 E(ech Report,)-.77 E(http://www)72 189=0A=
Q(.iet.unipi.it/~luigi/softfec.ps, Jan 1997.)-.715 E/F1 11/Times-Bold@0=0A=
SF(7.)72 241 Q/F2 14/Times-Bold@0 SF -.7(Au)5.5 G(thors' Addr).7 E=0A=
(esses)-.252 E F0(Michael Luby)80.25 257.6 Q(luby@digitalfountain.com)=0A=
80.25 270.6 Q(Digital F)80.25 283.6 Q(ountain)-.165 E(39141 Ci)80.25=0A=
296.6 Q(vic Center Dri)-.275 E -.165(ve)-.275 G(Suite 300)80.25 309.6 Q=0A=
(Fremont, CA)80.25 322.6 Q(94538)5.5 E(Lorenzo V)80.25 348.6 Q(icisano)=0A=
-.66 E(lorenzo@cisco.com)80.25 361.6 Q(cisco Systems, Inc.)80.25 374.6 Q=0A=
(170 W)80.25 387.6 Q(est T)-.88 E(asman Dr)-.88 E(.,)-.605 E=0A=
(San Jose, CA, USA, 95134)80.25 400.6 Q(Jim Gemmell)80.25 426.6 Q=0A=
(jgemmell@microsoft.com)80.25 439.6 Q(Microsoft Research)80.25 452.6 Q=0A=
(301 Ho)80.25 465.6 Q -.11(wa)-.275 G(rd St., #830).11 E=0A=
(San Francisco, CA, USA, 94105)80.25 478.6 Q(Luigi Rizzo)80.25 504.6 Q=0A=
(luigi@iet.unipi.it)80.25 517.6 Q -.44(AC)80.25 530.6 S=0A=
(IRI, 1947 Center St., Berk).44 E(ele)-.11 E 2.75(yC)-.165 G 2.75(A9)=0A=
-2.75 G(4704)-2.75 E(and)80.25 543.6 Q(Dip. di Ing. dell'Informazione)=0A=
80.25 556.6 Q(Uni)80.25 569.6 Q -.165(ve)-.275 G(rsita` di Pisa).165 E=0A=
(via Diotisalvi 2, 56126 Pisa, Italy)80.25 582.6 Q(Mark Handle)80.25=0A=
608.6 Q(y)-.165 E(mjh@aciri.or)80.25 621.6 Q(g)-.198 E -.44(AC)80.25=0A=
634.6 S(IRI).44 E(1947 Center St.)80.25 647.6 Q(Berk)80.25 660.6 Q(ele)=0A=
-.11 E 2.75(yC)-.165 G(A, USA, 94704)-2.75 E(Jon Cro)80.25 686.6 Q=0A=
(wcroft)-.275 E(J.Cro)80.25 699.6 Q(wcroft@cs.ucl.ac.uk)-.275 E=0A=
(Department of Computer Science)80.25 712.6 Q(Uni)80.25 725.6 Q -.165=0A=
(ve)-.275 G(rsity Colle).165 E(ge London)-.165 E(Luby/V)72 769 Q=0A=
(icisano/Gemmell/Rizzo/Handle)-.66 E(y/Cro)-.165 E 111.856=0A=
(wcroft Section)-.275 F 2.75(7. [P)2.75 F(age 12])-.165 E EP=0A=
%%Page: 13 13=0A=
%%BeginPageSetup=0A=
BP=0A=
%%EndPageSetup=0A=
/F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 77.081(-DRAFT Expires:)-1.012 F=0A=
(April 2002)2.75 E(October 2001)112.127 E(Go)80.25 85 Q(wer Street,)=0A=
-.275 E(London WC1E 6BT)80.25 98 Q 2.75(,U)-.814 G(K)-2.75 E(Luby/V)72=0A=
769 Q(icisano/Gemmell/Rizzo/Handle)-.66 E(y/Cro)-.165 E 111.856=0A=
(wcroft Section)-.275 F 2.75(7. [P)2.75 F(age 13])-.165 E EP=0A=
%%Page: 14 14=0A=
%%BeginPageSetup=0A=
BP=0A=
%%EndPageSetup=0A=
/F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 77.081(-DRAFT Expires:)-1.012 F=0A=
(April 2002)2.75 E(October 2001)112.127 E/F1 11/Times-Bold@0 SF(8.)72 85=0A=
Q/F2 14/Times-Bold@0 SF(Full Copyright Statement)5.5 E F0(Cop)72 101.6 Q=0A=
(yright \(C\) The Internet Society \(2001\).)-.11 E(All Rights Reserv)=0A=
5.5 E(ed.)-.165 E(This document and translations of it may be copied an\=0A=
d furnished to others, and deri)72 118.2 Q -.275(va)-.275 G(ti).275 E=0A=
.33 -.165(ve w)-.275 H(orks).055 E(that comment on or otherwise e)72=0A=
131.2 Q=0A=
(xplain it or assist in its implementation may be prepared, copied,)=0A=
-.165 E(published and distrib)72 144.2 Q=0A=
(uted, in whole or in part, without restriction of an)-.22 E 2.75(yk)=0A=
-.165 G(ind, pro)-2.75 E(vided that the)-.165 E(abo)72 157.2 Q .33 -.165=0A=
(ve c)-.165 H(op).165 E(yright notice and this paragraph are included o\=0A=
n all such copies and deri)-.11 E -.275(va)-.275 G(ti).275 E .33 -.165=0A=
(ve w)-.275 H(orks.).055 E(Ho)72 170.2 Q(we)-.275 E -.165(ve)-.275 G .88=0A=
-.44(r, t).165 H(his document itself may not be modi\214ed in an).44 E=0A=
2.75(yw)-.165 G(ay)-2.86 E 2.75(,s)-.715 G(uch as by remo)-2.75 E=0A=
(ving the)-.165 E(cop)72 183.2 Q(yright notice or references to the Int\=0A=
ernet Society or other Internet or)-.11 E -.055(ga)-.198 G(nizations, e)=0A=
.055 E(xcept as)-.165 E(needed for the purpose of de)72 196.2 Q -.165=0A=
(ve)-.275 G(loping Internet standards in which case the procedures for)=0A=
.165 E(cop)72 209.2 Q=0A=
(yrights de\214ned in the Internet languages other than English.)-.11 E=0A=
(The limited permissions granted abo)72 225.8 Q .33 -.165(ve a)-.165 H=0A=
(re perpetual and will not be re).165 E -.22(vo)-.275 G -.11(ke).22 G=0A=
2.75(db).11 G 2.75(yt)-2.75 G(he Internet)-2.75 E=0A=
(Society or its successors or assigns.)72 238.8 Q=0A=
(This document and the information contained herein is pro)72 255.4 Q=0A=
(vided on an "AS IS" basis and THE)-.165 E=0A=
(INTERNET SOCIETY AND THE INTERNET ENGINEERING T)72 268.4 Q=0A=
(ASK FORCE DISCLAIMS)-1.023 E(ALL W)72 281.4 Q=0A=
(ARRANTIES, EXPRESS OR IMPLIED, INCLUDING B)-1.32 E(UT NO)-.11 E 2.75=0A=
(TL)-.44 G(IMITED T)-2.75 E 2.75(OA)-.198 G(NY)-2.75 E -1.32(WA)72 294.4=0A=
S(RRANTY THA)1.32 E 2.75(TT)-1.221 G(HE USE OF THE INFORMA)-2.75 E=0A=
(TION HEREIN WILL NO)-1.221 E 2.75(TI)-.44 G(NFRINGE)-2.75 E=0A=
(ANY RIGHTS OR ANY IMPLIED W)72 307.4 Q(ARRANTIES OF MERCHANT)-1.32 E=0A=
(ABILITY OR FITNESS)-1.023 E(FOR A P)72 320.4 Q(AR)-1.012 E=0A=
(TICULAR PURPOSE.")-.66 E(Luby/V)72 769 Q(icisano/Gemmell/Rizzo/Handle)=0A=
-.66 E(y/Cro)-.165 E 111.856(wcroft Section)-.275 F 2.75(8. [P)2.75 F=0A=
(age 14])-.165 E EP=0A=
%%Page: 15 15=0A=
%%BeginPageSetup=0A=
BP=0A=
%%EndPageSetup=0A=
/F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 77.081(-DRAFT Expires:)-1.012 F=0A=
(April 2002)2.75 E(October 2001)112.127 E(Luby/V)72 769 Q=0A=
(icisano/Gemmell/Rizzo/Handle)-.66 E(y/Cro)-.165 E 111.856=0A=
(wcroft Section)-.275 F 2.75(8. [P)2.75 F(age 15])-.165 E EP=0A=
%%Trailer=0A=
end=0A=
%%EOF=0A=
------=_NextPart_000_0000_01C157E0.145218E0--
>From owner-rmt@listserv.lbl.gov Thu Oct 18 14:23:30 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f9ILKGV04294;
Thu, 18 Oct 2001 14:20:16 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f9ILKFp04290
for <rmt@listserv.lbl.gov>; Thu, 18 Oct 2001 14:20:15 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f9ILKEj23001
for <rmt@listserv.lbl.gov>; Thu, 18 Oct 2001 14:20:14 -0700 (PDT)
Received: from mx.webfountain.com (mx.digitalfountain.com [209.219.233.39])
by SpamWall.lbl.gov (8.11.2/8.11.2) with SMTP id f9ILKCb22959
for <rmt@lbl.gov>; Thu, 18 Oct 2001 14:20:12 -0700 (PDT)
Received: (qmail 23767 invoked from network); 18 Oct 2001 21:20:07 -0000
Received: from mail.intranet (10.1.1.37)
by mx.digitalfountain.com with SMTP; 18 Oct 2001 21:20:07 -0000
Received: from bozz (dhcp-10-1-2-180.intranet [10.1.2.180])
by mail.intranet (8.9.3/8.9.3) with SMTP id OAA31278;
Thu, 18 Oct 2001 14:19:40 -0700
X-Authentication-Warning: mail.intranet: Host dhcp-10-1-2-180.intranet [10.1.2.180] claimed to be bozz
From: "Michael Luby" <luby@digitalfountain.com>
To: "Internet-Drafts@Ietf. Org" <internet-drafts@ietf.org>,
"Rmt@Lbl. Gov" <rmt@lbl.gov>
Cc: "Michael Luby" <luby@digitalfountain.com>
Subject: draft-ietf-rmt-bb-lct-02.txt
Date: Thu, 18 Oct 2001 14:25:04 -0700
Message-ID: <NEBBIAPCNKEDCLPNFBNCGEKKCHAA.luby@digitalfountain.com>
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="----=_NextPart_000_0005_01C157E0.AE079D70"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-rmt@lbl.gov
Precedence: bulk
This is a multi-part message in MIME format.
------=_NextPart_000_0005_01C157E0.AE079D70
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Please post this draft on the IETF Internet Drafts archive. This is an
update of an existing WG draft (RMT).
This also serves as a last call before moving this towards RFC status.
Please send any comments or concerns to the RMT list by Monday, October 22.
Thanks, Mike Luby
------=_NextPart_000_0005_01C157E0.AE079D70
Content-Type: text/plain;
name="draft-ietf-rmt-bb-lct-02.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
filename="draft-ietf-rmt-bb-lct-02.txt"
Internet Engineering Task Force RMT WG=0A=
INTERNET-DRAFT M.Luby/Digital Fountain=0A=
draft-ietf-rmt-bb-lct-02.txt J.Gemmell/Microsoft=0A=
L.Vicisano/Cisco=0A=
L.Rizzo/ACIRI and Univ. Pisa=0A=
M.Handley/ACIRI=0A=
J. Crowcroft/UCL=0A=
18 October 2001=0A=
Expires: April 2002=0A=
=0A=
=0A=
Layered Coding Transport:=0A=
A massively scalable content delivery transport building block=0A=
=0A=
=0A=
=0A=
Status of this Document=0A=
=0A=
This document is an Internet-Draft and is in full conformance with all=0A=
provisions of Section 10 of RFC2026.=0A=
=0A=
Internet-Drafts are working documents of the Internet Engineering Task=0A=
Force (IETF), its areas, and its working groups. Note that other groups=0A=
may also distribute working documents as Internet-Drafts.=0A=
=0A=
Internet-Drafts are valid for a maximum of six months and may be=0A=
updated, replaced, or obsoleted by other documents at any time. It is=0A=
inappropriate to use Internet-Drafts as reference material or to cite=0A=
them other than as a "work in progress".=0A=
=0A=
The list of current Internet-Drafts can be accessed at=0A=
http://www.ietf.org/ietf/1id-abstracts.txt=0A=
=0A=
To view the list Internet-Draft Shadow Directories, see=0A=
http://www.ietf.org/shadow.html.=0A=
=0A=
This document is a product of the IETF RMT WG. Comments should be=0A=
addressed to the authors, or the WG's mailing list at rmt@lbl.gov.=0A=
=0A=
=0A=
Abstract=0A=
=0A=
=0A=
This document describes Layered Coding Transport, a massively=0A=
scalable reliable content delivery and stream delivery=0A=
=0A=
=0A=
=0A=
Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft [Page 1]=0A=
=0C=0A=
INTERNET-DRAFT Expires: April 2002 October 2001=0A=
=0A=
=0A=
transport, hereafter referred to as LCT. LCT can be used for=0A=
multi-rate delivery to large sets of receivers. In LCT,=0A=
scalability and congestion control are supported through the=0A=
use of layered coding techniques. Coding techniques can be=0A=
combined with LCT to provide support for reliability.=0A=
=0A=
Congestion control is receiver driven, and can be achieved by=0A=
sending packets in the session to multiple ``LCT channels'',=0A=
and having receivers join and leave LCT channels (thus=0A=
adjusting their reception rate) in reaction to network=0A=
conditions in a manner that is network friendly.=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft [Page 2]=0A=
=0C=0A=
INTERNET-DRAFT Expires: April 2002 October 2001=0A=
=0A=
=0A=
Table of Contents=0A=
=0A=
=0A=
1. Introduction. . . . . . . . . . . . . . . . . . . . . . 4=0A=
1.1. Related Documents. . . . . . . . . . . . . . . . . . 6=0A=
1.2. Environmental Requirements and Considerations. . . . 7=0A=
2. General Architecture. . . . . . . . . . . . . . . . . . 9=0A=
2.1. Delivery service models. . . . . . . . . . . . . . . 10=0A=
2.2. Congestion Control . . . . . . . . . . . . . . . . . 12=0A=
3. LCT header. . . . . . . . . . . . . . . . . . . . . . . 12=0A=
3.1. Default LCT header format. . . . . . . . . . . . . . 12=0A=
3.2. Header-Extension Fields. . . . . . . . . . . . . . . 18=0A=
4. Procedures. . . . . . . . . . . . . . . . . . . . . . . 21=0A=
4.1. Sender Operation . . . . . . . . . . . . . . . . . . 21=0A=
4.2. Receiver Operation . . . . . . . . . . . . . . . . . 23=0A=
5. Security Considerations . . . . . . . . . . . . . . . . 24=0A=
6. IANA Considerations . . . . . . . . . . . . . . . . . . 24=0A=
7. Intellectual Property Issues. . . . . . . . . . . . . . 24=0A=
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . 25=0A=
9. References. . . . . . . . . . . . . . . . . . . . . . . 25=0A=
10. Authors' Addresses . . . . . . . . . . . . . . . . . . 26=0A=
11. Full Copyright Statement . . . . . . . . . . . . . . . 28=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft [Page 3]=0A=
=0C=0A=
INTERNET-DRAFT Expires: April 2002 October 2001=0A=
=0A=
=0A=
1. Introduction=0A=
=0A=
This document describes a massively scalable reliable content delivery=0A=
and stream delivery transport, Layered Coding Transport (LCT), for=0A=
multi-rate content delivery primarily designed to be used with the IP=0A=
multicast network service, but may also be used with other basic=0A=
underlying network or transport services such as unicast UDP. LCT=0A=
supports both reliable and unreliable delivery.=0A=
=0A=
LCT is a building block as defined in RFC3048. Protocol instantiations=0A=
may be built by combining the LCT framework with other components. A=0A=
complete protocol instantiation that uses LCT must include a congestion=0A=
control protocol that is compatible with LCT and that conforms to=0A=
RFC2357. A complete protocol instantiation that uses LCT may include a=0A=
scalable reliability protocol that is compatible with LCT, it may=0A=
include an session control protocol that is compatible with LCT, and it=0A=
may include other protocols such as security protocols.=0A=
=0A=
LCT is presumed to be used with an underlying network or transport=0A=
service that is a "best effort" service that does not guarantee packet=0A=
reception, packet reception order, and which does not have any support=0A=
for flow or congestion control. For example, the Any-Source Multicast=0A=
(ASM) model of IP multicast as defined in RFC1112 is such a "best=0A=
effort" network service. While the basic service provided by RFC1112 is=0A=
largely scalable, providing congestion control or reliability should be=0A=
done carefully to avoid severe scalability limitations, especially in=0A=
presence of heterogeneous sets of receivers.=0A=
=0A=
Packets with LCT headers are carried in LCT channels. An LCT channel is=0A=
defined by the combination of a sender and an address associated with=0A=
the channel by the sender. A receiver may join a channel to start=0A=
receiving the data packets sent to the channel by the sender, and a=0A=
receiver may leave a channel to stop receiving data packets from the=0A=
channel.=0A=
=0A=
An LCT session consists of a set of logically grouped LCT channels=0A=
associated with a single sender carrying packets with LCT headers for=0A=
one or more objects. Congestion control that conforms to RFC2357 must=0A=
be used between receivers and the sender for each LCT session.=0A=
Congestion control refers to the ability to adapt throughput to the=0A=
available bandwidth on the path from the sender to a receiver, and to=0A=
share bandwidth fairly with competing flows such as TCP. Thus, the total=0A=
flow of packets flowing to each receiver participating in an LCT session=0A=
must not compete unfairly with existing flow adaptive protocols such as=0A=
TCP.=0A=
=0A=
A multi-rate or a single-rate congestion control protcol can be used=0A=
with LCT. For multi-rate protocols, a session typically consists of=0A=
=0A=
=0A=
=0A=
Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft Section 1. [Page 4]=0A=
=0C=0A=
INTERNET-DRAFT Expires: April 2002 October 2001=0A=
=0A=
=0A=
more than one channel and the sender sends packets to the channels in=0A=
the session at rates that do not depend on the receivers. Each receiver=0A=
adjusts its reception rate during its participation in the session by=0A=
joining and leaving channels dynamically depending on the available=0A=
bandwidth to the sender independent of all other receivers. Thus, for=0A=
multi-rate protocols, the reception rate of each receiver may vary=0A=
dynamically independent of the other receivers.=0A=
=0A=
For single-rate protocols, a session typically consists of one channel=0A=
and the sender sends packets to the channel at variable rates over time=0A=
depending on feedback from receivers. Each receiver remains joined to=0A=
the channel during its participation in the session. Thus, for single-=0A=
rate protocols, the reception rate of each receiver may vary dynamically=0A=
but in coordination with all receivers. Generally, a multi-rate=0A=
protocol is preferable to a single-rate protocol in a heterogeneous=0A=
receiver environment, but only if it can be achieved without sacrificing=0A=
scalability. Some possible multi-rate congestion control protocols are=0A=
described in [11] and [1]. A possible single-rate congestion control=0A=
protocol is described in [10].=0A=
=0A=
Layered coding refers to the ability to produce a coded stream of=0A=
packets that can be partioned into an ordered set of layers. The coding=0A=
is meant to provide some form of reliability, and the layering is meant=0A=
to allow the receiver experience (in terms of quality of playout, or=0A=
overall transfer speed) to vary in a predictable way depending on how=0A=
many consecutive layers of packets the receiver is receiving.=0A=
=0A=
Layered coding can be naturally combined with multi-rate congestion=0A=
control. For example, the sender could send the packets for each layer=0A=
to a separate channel associated with the session, and then receivers=0A=
dynamically join and leave channels to adjust their reception rate=0A=
according to the multi-rate congestion control protocol.=0A=
=0A=
Layered coding can also be combined with single-rate congestion control.=0A=
For example, the sender could dynamically vary how many layers are sent=0A=
to the channel associated with the session as the rate of transmission=0A=
varies according to the single-rate congestion control protocol.=0A=
=0A=
The concept of layered coding was first introduced with reference to=0A=
audio and video streams. For example, the information associated with a=0A=
TV broadcast could be partitioned into three layers, corresponding to=0A=
black and white, color, and HDTV quality. Receivers can experience=0A=
different quality without the need for the sender to replicate=0A=
information in the different layers.=0A=
=0A=
The concept of layered coding can be naturally extended to reliable=0A=
content delivery protocols when Forward Error Correction (FEC)=0A=
techniques are used for coding the data stream [9] [7] [3] [11] [2]. By=0A=
=0A=
=0A=
=0A=
Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft Section 1. [Page 5]=0A=
=0C=0A=
INTERNET-DRAFT Expires: April 2002 October 2001=0A=
=0A=
=0A=
using FEC, the data stream is transformed in such a way that=0A=
reconstruction of a data object does not depend on the reception of=0A=
specific data packets, but only on the number of different packets=0A=
received. As a result, by increasing the number of layers a receiver is=0A=
receiving from, the receiver can reduce the transfer time accordingly.=0A=
More details on the use of FEC for reliable content delivery can be=0A=
found in [5]. Reliable protocols aim at giving guarantees on the=0A=
reliable delivery of data from the sender to the intended recipients.=0A=
Guarantees vary from simple packet data integrity to reliable delivery=0A=
of a precise copy of an object to all intended recipients. Several=0A=
reliable content delivery protocols have been built on top of IP=0A=
multicast, but scalability was not a design goal for many of them.=0A=
=0A=
Two of the key difficulties in scaling reliable content delivery using=0A=
IP multicast are dealing with the amount of data that flows from=0A=
receivers back to the sender, and the associated response (generally=0A=
data retransmissions) from the sender. Protocols that avoid any such=0A=
feedback, and minimize the amount of retransmissions, can be massively=0A=
scalable. LCT can be used in conjunction with FEC codes or a layered=0A=
codec to achieve reliability with little or no feedback.=0A=
=0A=
Scalability refers to the behavior of the protocol in relation to the=0A=
number of receivers and network paths, their heterogeneity, and the=0A=
ability to accommodate dynamically variable sets of receivers.=0A=
Scalability limitations can come from memory or processing requirements,=0A=
or from the amount of packet traffic generated by the protocol. In=0A=
turn, such limitations may be a consequence of the features that a=0A=
complete reliable content delivery or stream delivery protocol is=0A=
expected to provide.=0A=
=0A=
In this document we present the architecture and abstract LCT header=0A=
structure, and describe its support for congestion control.=0A=
=0A=
The key words "must", "must not", "required", "shall", "shall not",=0A=
"should", "should not", "recommended", "may", and "optional" in this=0A=
document are to be interpreted as described in RFC2119.=0A=
=0A=
=0A=
1.1. Related Documents=0A=
=0A=
As described in RFC3048, LCT is a building block that is intended to be=0A=
used, in conjunction with other building blocks, to help specify a=0A=
protocol instantiation. A congestion control building block that uses=0A=
the Congestion Control information field within the LCT header must be=0A=
used by any protocol instantiation that uses LCT, and other building=0A=
blocks may also be used, such as a reliability building block.=0A=
=0A=
A more in-depth description of the use of FEC in Reliable Multicast=0A=
=0A=
=0A=
=0A=
Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft Section 1.1. [Page 6]=0A=
=0C=0A=
INTERNET-DRAFT Expires: April 2002 October 2001=0A=
=0A=
=0A=
Transport (RMT) protocols is given in [5]. Some of the FEC codecs that=0A=
may be used in conjunction with LCT for reliable content delivery are=0A=
specified in [6]. The Codepoint field in the LCT header is an opaque=0A=
field that can be used to carry information related to the encoding of=0A=
the packet payload.=0A=
=0A=
Implementors of protocol instantiations that use LCT must also implement=0A=
congestion control in accordance to RFC2357, where the congestion=0A=
control is over the entire session. Some possible schemes are specified=0A=
in [11] and [1]. The Congestion Control Information field in the LCT=0A=
header is an opaque field that is reserved to carry information related=0A=
to congestion control. There may also be congestion control Header=0A=
Extension fields that carry additional information related to congestion=0A=
control.=0A=
=0A=
Generic Router Assist may be used in conjunction with LCT.=0A=
=0A=
It is recommended that LCT implementors use some packet authentication=0A=
scheme to protect the protocol from attacks. An example of a possibly=0A=
suitable scheme is described in [8].=0A=
=0A=
1.2. Environmental Requirements and Considerations=0A=
=0A=
LCT is intended for congestion controlled delivery of objects and=0A=
streams (both reliable content delivery and streaming of multimedia=0A=
information).=0A=
=0A=
LCT is most applicable for delivery of objects or streams of substantial=0A=
length, i.e., objects or streams that range in length from hundreds of=0A=
kilobytes to many gigabytes, and whose transfer time is in the order of=0A=
tens of seconds or more.=0A=
=0A=
LCT can be used with both multicast and unicast delivery. LCT requires=0A=
connectivity between a sender and receivers, but does not require=0A=
connectivity from receivers to a sender. LCT inherently works with all=0A=
types of networks, including LANs, WANs, Intranets, the Internet,=0A=
asymmetric networks, wireless networks, and satellite networks. Thus,=0A=
the inherent raw scalability of LCT is unlimited. However, when other=0A=
specific applications are built on top of LCT, then these applications=0A=
by their very nature may limit scalability. For example, if an=0A=
application requires receivers to retrieve out of band information in=0A=
order to join a session, or an application allows receivers to send=0A=
requests back to the sender to report reception statistics, then the=0A=
scalability of the application is limited by the ability to send,=0A=
receive, and process this additional data.=0A=
=0A=
LCT requires receivers to be able to uniquely identify and demultiplex=0A=
packets associated with an LCT session. In particular, there must be a=0A=
=0A=
=0A=
=0A=
Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft Section 1.2. [Page 7]=0A=
=0C=0A=
INTERNET-DRAFT Expires: April 2002 October 2001=0A=
=0A=
=0A=
Transport Session Identifier (TSI) associated with each LCT session.=0A=
The TSI is scoped by the IP address of the sender, and the IP address of=0A=
the sender together with the TSI must uniquely identify the session. If=0A=
the underlying transport is UDP as described in RFC768, then the 16 bit=0A=
UDP source port number may serve as the TSI for the session. If Generic=0A=
Router Assist (GRA) is being used then additional dependencies may be=0A=
introduced by GRA on the TSI field. GRA work is ongoing within the RMT=0A=
working group at this time. The TSI value must be the same in all=0A=
places it occurs within a packet. If there is no underlying TSI=0A=
provided by the network, transport or any other layer, then the TSI must=0A=
be included in the LCT header.=0A=
=0A=
There are currently two models of multicast delivery, the Any-Source=0A=
Multicast (ASM) model as defined in RFC1112 and the Source-Specific=0A=
Multicast (SSM) model as defined in [4]. LCT works with both multicast=0A=
models, but in a slightly different way with somewhat different=0A=
environmental concerns. When using ASM, a sender S sends packets to a=0A=
multicast group G, and the LCT channel address consists of the pair=0A=
(S,G), where S is the IP address of the sender and G is a multicast=0A=
group address. When using SSM, a sender S sends packets to an SSM=0A=
channel (S,G), and the LCT channel address coincides with the SSM=0A=
channel address.=0A=
=0A=
A sender can locally allocate unique SSM channel addresses, and this=0A=
makes allocation of LCT channel addresses easy with SSM. To allocate=0A=
LCT channel addresses using ASM, the sender must uniquely chose the ASM=0A=
multicast group address across the scope of the group, and this makes=0A=
allocation of LCT channel addresses more difficult with ASM.=0A=
=0A=
LCT channels and SSM channels coincide, and thus the receiver will only=0A=
receive packets sent to the requested LCT channel. With ASM, the=0A=
receiver joins an LCT channel by joining a multicast group G, and all=0A=
packets sent to G, regardless of the sender, may be received by the=0A=
receiver. Thus, SSM has compelling security advantages over ASM for=0A=
prevention of denial of service attacks. In either case, receivers=0A=
should use mechanisms to filter out packets from unwanted sources.=0A=
=0A=
LCT also requires receivers to obtain Session Description Information,=0A=
as described in Section 4.1. The session description could be in a form=0A=
such as SDP as defined in RFC2327, or XML metadata, or HTTP/Mime headers=0A=
as defined in RFC2068, and distributed with SAP as defined in RFC2974,=0A=
using HTTP, or in other ways.=0A=
=0A=
The particular layered encoder and congestion control protocols used=0A=
with LCT have an impact on the performance and applicability of LCT.=0A=
For example, some layered encoders used for video and audio streams can=0A=
produce a very limited number of layers, thus providing a very coarse=0A=
control in the reception rate of packets by receivers in a session.=0A=
=0A=
=0A=
=0A=
Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft Section 1.2. [Page 8]=0A=
=0C=0A=
INTERNET-DRAFT Expires: April 2002 October 2001=0A=
=0A=
=0A=
When LCT is used for reliable data transfer, some FEC codecs are=0A=
inherently limited in the size of the object they can encode, and for=0A=
objects larger than this size the reception overhead on the receivers=0A=
can grow substantially.=0A=
=0A=
Some networks are not amenable to some congestion control protocols that=0A=
could be used with LCT. In particular, for a satellite or wireless=0A=
network, there may be no mechanism for receivers to effectively reduce=0A=
their reception rate since there may be a fixed transmission rate=0A=
allocated to the session.=0A=
=0A=
Some protocol instantiations that use LCT may require the generation of=0A=
feedback from the receivers to the sender. For example, Generic Router=0A=
Assist may be used to help in passing real-time statistics in a scalable=0A=
manner from receivers back to the sender. However, the mechanism for=0A=
doing this is outside the scope of LCT.=0A=
=0A=
=0A=
2. General Architecture=0A=
=0A=
An LCT session comprises a logically related set of one or more LCT=0A=
channels originating at a single sender that are used for some period of=0A=
time to carry packets containing LCT headers pertaining to the=0A=
transmission of one or more objects that can be of interest to=0A=
receivers.=0A=
=0A=
For example, an LCT session could be used to deliver a TV program using=0A=
three LCT channels. Receiving packets from the first LCT channel could=0A=
allow black and white reception, receiving the first two LCT channels=0A=
could also permit color reception, whereas receiving all three channels=0A=
could allow HDTV quality reception. Objects in this example could=0A=
correspond to individual TV programs being transmitted.=0A=
=0A=
As another example, a reliable LCT session could be used to reliably=0A=
deliver hourly-updated weather maps (objects) using ten LCT channels at=0A=
different rates, using FEC coding. A receiver may join and concurrently=0A=
receive packets from subsets of these channels, until it has enough=0A=
packets in total to recover the object, then leave the session (or=0A=
remain connected listening for session description information only)=0A=
until it is time to receive the next object. In this case, the quality=0A=
metric is the time required to receive each object.=0A=
=0A=
Before joining a session, the receivers must obtain enough of the=0A=
session description to start the session. This must include the=0A=
relevant session parameters needed by a receiver to participate in the=0A=
session, including all information relevant to congestion control. The=0A=
session description is determined by the sender, and is typically=0A=
communicated to the receivers out of band. In some cases, as described=0A=
=0A=
=0A=
=0A=
Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft Section 2. [Page 9]=0A=
=0C=0A=
INTERNET-DRAFT Expires: April 2002 October 2001=0A=
=0A=
=0A=
later, parts of the session description that are not required to=0A=
initiate a session may be included in the LCT header or communicated to=0A=
a receiver out of band after the receiver has joined the session.=0A=
=0A=
An encoder may be used to generate the data that is placed in the packet=0A=
payload in order to provide reliability. A suitable decoder is used to=0A=
reproduce the original information from the packet payload. There may=0A=
be a reliability header that follows the LCT header if such an encoder=0A=
and decoder is used. The reliability header helps to describe the=0A=
encoding data carried in the payload of the packet. The format of the=0A=
reliability header depends on the coding used, and this is negotiated=0A=
out-of-band. As an example, one of the FEC headers described in [6]=0A=
could be used.=0A=
=0A=
For LCT, when multi-rate congestion control is used, congestion control=0A=
is achieved by sending packets associated with a given session to=0A=
several LCT channels. Individual receivers dynamically join one or more=0A=
of these channels, according to the network congestion as seen by the=0A=
receiver. LCT headers include an opaque field which must be used to=0A=
convey congestion control information to the receivers. The actual=0A=
congestion control scheme to use with LCT is negotiated out-of-band.=0A=
Some examples of congestion control protocols that may be suitable for=0A=
content delivery are described in [11] and [1]. Other congestion=0A=
controls may be suitable when LCT is used for a streaming application.=0A=
=0A=
LCT can be used with other congestion control protocols such as the one=0A=
described in [11], or Generic Router Assist schemes where the selection=0A=
of which packets to forward is performed by routers. This latter=0A=
approach potentially allows for finer grain congestion control and a=0A=
faster reaction to network congestion, but requires changes to the=0A=
router infrastructure. We do not discuss this approach further in this=0A=
document.=0A=
=0A=
=0A=
2.1. Delivery service models=0A=
=0A=
LCT can support several different delivery service models. Two examples=0A=
are briefly described here.=0A=
=0A=
=0A=
Push service model.=0A=
=0A=
One way a push service model can be used for reliable content delivery=0A=
is to deliver a series of objects. For example, a receiver could join=0A=
the session and dynamically adapt the number of LCT channels the=0A=
receiver is joined to until enough packets have been received to=0A=
reconstruct an object. After reconstructing the object the receiver may=0A=
stay in the session and wait for the transmission of the next object.=0A=
=0A=
=0A=
=0A=
Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft Section 2.1. [Page 10]=0A=
=0C=0A=
INTERNET-DRAFT Expires: April 2002 October 2001=0A=
=0A=
=0A=
The push model is particularly attractive in satellite networks and=0A=
wireless networks. In these cases, a session may consist of one fixed=0A=
rate LCT channel.=0A=
=0A=
=0A=
On-demand content delivery model.=0A=
=0A=
For an on-demand content delivery service model, senders typically=0A=
transmit for some given time period selected to be long enough to allow=0A=
all the intended receivers to join the session and recover the object.=0A=
For example a popular software update might be transmitted using LCT for=0A=
several days, even though a receiver may be able to complete the=0A=
download in one hour total of connection time, perhaps spread over=0A=
several intervals of time.=0A=
=0A=
In this case the receivers join the session, and dynamically adapt the=0A=
number of LCT channels they subscribe to (and the reception quality)=0A=
according to the available bandwidth. Receivers then drop from the=0A=
session when they have received enough packets to recover the object.=0A=
=0A=
As an example, assume that an object is 50 MB. The sender could send 1=0A=
KB packets to the first LCT channel at 50 packets per second, so that=0A=
receivers using just this LCT channel could complete reception of the=0A=
object in 1,000 seconds in absence of loss, and would be able to=0A=
complete reception even in presence of some substantial amount of losses=0A=
with the use of coding for reliability. Furthermore, the sender could=0A=
use a number of LCT channels such that the aggregate rate of 1 KB=0A=
packets to all LCT channels is 1,000 packets per second, so that a=0A=
receiver could be able to complete reception of the object in as little=0A=
50 seconds (assuming no loss and that the congestion control mechanism=0A=
immediately converges to the use of all LCT channels).=0A=
=0A=
=0A=
Other service models.=0A=
=0A=
=0A=
There are many other delivery service models that LCT can be used for=0A=
that are not covered above. As examples, a live streaming or an on-=0A=
demand archival content streaming service model. The description of the=0A=
many potential applications, the appropriate delivery service model, and=0A=
the additional mechanisms to support such functionalities when combined=0A=
with LCT is beyond the scope of this document. This document only=0A=
attempts to describe the minimal common scalable elements to these=0A=
diverse applications using LCT as the delivery transport.=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft Section 2.1. [Page 11]=0A=
=0C=0A=
INTERNET-DRAFT Expires: April 2002 October 2001=0A=
=0A=
=0A=
2.2. Congestion Control=0A=
=0A=
The specific congestion control protocol to be used for LCT sessions=0A=
depends on the type of content to be delivered. While the general=0A=
behavior of the congestion control protocol is to reduce the throughput=0A=
in presence of congestion and gradually increase it in the absence of=0A=
congestion, the actual dynamic behavior (e.g. response to single losses)=0A=
can vary.=0A=
=0A=
Some possible congestion control protocols for reliable content delivery=0A=
using LCT are described in [11] and [1]. Different delivery service=0A=
models might require different congestion control protocols.=0A=
=0A=
=0A=
3. LCT header=0A=
=0A=
Packets sent to an LCT session must include an "LCT header". The LCT=0A=
header format described below is the default format, and this is the=0A=
format that is recommended for use by protocol instantiations to ensure=0A=
a uniform format across different protocol instantiations. Other LCT=0A=
header formats may be used by protocol instantiations, but if the=0A=
default LCT header format is not used by a protocol insantiation that=0A=
uses LCT, then the protocol instantiation must specify the lengths and=0A=
positions within the LCT header it uses of all fields described in the=0A=
default LCT header.=0A=
=0A=
Other building blocks may describe some of the same fields as described=0A=
for the LCT header. It is recommended that protocol instantiations=0A=
using multiple building blocks include shared fields at most once in=0A=
each packet. Thus, for example, if another building block is used with=0A=
LCT that includes the optional Expected Residual Time field, then the=0A=
Expected Residual Time field should be carried in each packet at most=0A=
once.=0A=
=0A=
The position of the LCT header within a packet must be specified by any=0A=
protocol instantiation that uses LCT.=0A=
=0A=
=0A=
3.1. Default LCT header format=0A=
=0A=
The default LCT header is of variable size, which is specified by a=0A=
length field in the third byte of the header. In the LCT header, all=0A=
integer fields are carried in "big-endian" or "network order" format,=0A=
that is, most significant byte (octet) first. Bits designated as=0A=
"padding" or "reserved" (r) must by set to 0 by senders and ignored by=0A=
receivers. Unless otherwise noted, numeric constants in this=0A=
specification are in decimal (base 10).=0A=
=0A=
=0A=
=0A=
=0A=
Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft Section 3.1. [Page 12]=0A=
=0C=0A=
INTERNET-DRAFT Expires: April 2002 October 2001=0A=
=0A=
=0A=
The format of the default LCT header is depicted in Figure 1.=0A=
=0A=
=0A=
0 1 2 3=0A=
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=0A=
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A=
| V |C| r |H|S| O |T|R|A|B| HDR_LEN | Codepoint (CP)|=0A=
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A=
| Congestion Control Information (CCI) |=0A=
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A=
| CCI continued (if C =3D 1) |=0A=
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A=
| Transport Session Identifier (TSI, length =3D 32*S+16*H bits) |=0A=
| ... |=0A=
+ +=0A=
| Transport Object Identifier (TOI, length =3D 32*O+16*H bits) |=0A=
| ... |=0A=
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A=
| Sender Current Time (SCT, if T =3D 1) |=0A=
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A=
| Expected Residual Time (ERT, if R =3D 1) |=0A=
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A=
| Header Extensions (if applicable) |=0A=
| |=0A=
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A=
=0A=
=0A=
Figure 1 - Default LCT header format=0A=
=0A=
=0A=
The function and length of each field in the default LCT header is the=0A=
following. Fields marked as "1" mean that the corresponding bits must=0A=
be set to "1" by the sender. Fields marked as "r" or "0" mean that the=0A=
corresponding bits must be set to "0" by the sender.=0A=
=0A=
=0A=
LCT version number (V): 4 bits=0A=
=0A=
Indicates the LCT version number. The LCT version number for this=0A=
specification is 0.=0A=
=0A=
=0A=
Congestion control flag (C): 1 bit=0A=
=0A=
C=3D0 indicates the Congestion Control Information (CCI) field is=0A=
32-bits in length.=0A=
C=3D1 indicates the CCI field is 64-bits in length.=0A=
=0A=
=0A=
=0A=
=0A=
Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft Section 3.1. [Page 13]=0A=
=0C=0A=
INTERNET-DRAFT Expires: April 2002 October 2001=0A=
=0A=
=0A=
Reserved (r): 3 bits=0A=
=0A=
Reserved for future use. A sender must set these bits to zero and=0A=
a receiver must ignore these bits.=0A=
=0A=
=0A=
Half-word flag (H): 1 bit=0A=
=0A=
The TSI and the TOI fields are both multiples of 32-bits plus 16*H=0A=
bits in length. This allows the TSI and TOI field lengths to be=0A=
multiples of a half-word (16 bits), while ensuring that the=0A=
aggregate length of the TSI and TOI fields is a multiple of=0A=
32-bits.=0A=
=0A=
=0A=
Transport Session Identifier flag (S): 1 bit=0A=
=0A=
This is the number of full 32-bit words in the TSI field. The TSI=0A=
field is 32*S + 16*H bits in length, i.e. the length is either 0=0A=
bits, 16 bits, 32 bits, or 48 bits.=0A=
=0A=
=0A=
Transport Object Identifier flag (O): 2 bits=0A=
=0A=
This is the number of full 32-bit words in the TOI field. The TOI=0A=
field is 32*O + 16*H bits in length, i.e., the length is either 0=0A=
bits, 16 bits, 32 bits, 48 bits, 64 bits, 80 bits, 96 bits, or 112=0A=
bits.=0A=
=0A=
=0A=
Sender Current Time present flag (T): 1 bit=0A=
=0A=
T =3D 0 indicates that the Sender Current Time (SCT) field is not=0A=
present.=0A=
T =3D 1 indicates that the SCT field is present.=0A=
The SCT is inserted by senders to indicate to receivers how long=0A=
the session has been in progress.=0A=
=0A=
=0A=
Expected Residual Time present flag (R): 1 bit=0A=
=0A=
R =3D 0 indicates that the Expected Residual Time (ERT) field is =
not=0A=
present.=0A=
R =3D 1 indicates that the ERT field is present.=0A=
The ERT is inserted by senders to indicate to receivers how much=0A=
longer the session / object transmission will continue.=0A=
Senders must not set R =3D 1 when the ERT for the session is more=0A=
than 2^32-1 time units (approximately 49 days), where time is=0A=
=0A=
=0A=
=0A=
Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft Section 3.1. [Page 14]=0A=
=0C=0A=
INTERNET-DRAFT Expires: April 2002 October 2001=0A=
=0A=
=0A=
measured in units of milliseconds.=0A=
=0A=
=0A=
Close Session flag (A): 1 bit=0A=
=0A=
Normally, A is set to 0. The sender may set A to 1 when=0A=
termination of transmission of packets for the session is=0A=
imminent. A may be set to 1 in just the last packet transmitted=0A=
for the session, or A may be set to 1 in the last few seconds of=0A=
packets transmitted for the session. Once the sender sets A to 1=0A=
in one packet, the sender should set A to 1 in all subsequent=0A=
packets until termination of transmission of packets for the=0A=
session. A received packet with A set to 1 indicates to a=0A=
receiver that the sender will immediately stop sending packets for=0A=
the session. When a receiver receives a packet with A set to 1=0A=
the receiver should assume that no more packets will be sent to=0A=
the session.=0A=
=0A=
=0A=
Close Object flag (B): 1 bit=0A=
=0A=
Normally, B is set to 0. The sender may set B to 1 when=0A=
termination of transmission of packets for an object is imminent.=0A=
If the TOI field is in use and B is set to 1 then termination of=0A=
transmission for the object identified by the TOI field is=0A=
imminent. If the TOI field is not in use and B is set to 1 then=0A=
termination of transmission for the one object in the session=0A=
identified by out of band information is imminent. B may be set=0A=
to 1 in just the last packet transmitted for the object, or B may=0A=
be set to 1 in the last few seconds packets transmitted for the=0A=
object. Once the sender sets B to 1 in one packet for a=0A=
particular object, the sender should set B to 1 in all subsequent=0A=
packets for the object until termination of transmission of=0A=
packets for the object. A received packet with B set to 1=0A=
indicates to a receiver that the sender will immediately stop=0A=
sending packets for the object. When a receiver receives a packet=0A=
with B set to 1 then it should assume that no more packets will be=0A=
sent for the object to the session.=0A=
=0A=
=0A=
LCT header length (HDR_LEN): 8 bits=0A=
=0A=
Total length of the LCT header in units of 32-bit words. The=0A=
length of the LCT header must be a multiple of 32-bits. This=0A=
field can be used to directly access the portion of the packet=0A=
beyond the LCT header, i.e., to the first other header if it=0A=
exists, or to the packet payload if it exists and there is no=0A=
other header, or to the end of the packet if there are no other=0A=
=0A=
=0A=
=0A=
Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft Section 3.1. [Page 15]=0A=
=0C=0A=
INTERNET-DRAFT Expires: April 2002 October 2001=0A=
=0A=
=0A=
headers or packet payload.=0A=
=0A=
=0A=
Codepoint (CP): 8 bits=0A=
=0A=
An opaque identifier which is passed to the packet payload decoder=0A=
to convey information on the codec being used for the packet=0A=
payload. The mapping between the codepoint and the actual codec is=0A=
defined on a per session basis and communicated out-of-band as=0A=
part of the session description information. The use of the CP=0A=
field is similar to the Payload Type (PT) field in RTP headers as=0A=
described in RFC1889.=0A=
=0A=
=0A=
Congestion Control Information (CCI): 32 or 64 bits=0A=
=0A=
Used to carry congestion control information. For example, the=0A=
congestion control information could include layer numbers,=0A=
logical channel numbers, and sequence numbers. This field is=0A=
opaque for the purpose of this specification.=0A=
This field must be 32 bits if C=3D0.=0A=
This field must be 64 bits if C=3D1.=0A=
=0A=
=0A=
Transport Session Identifier (TSI): 0, 16, 32 or 48 bits=0A=
=0A=
The TSI uniquely identifies a session among all sessions from a=0A=
particular sender. The TSI is scoped by the IP address of the=0A=
sender, and thus the IP address of the sender and the TSI together=0A=
uniquely identify the session. Although a TSI in conjunction with=0A=
the IP address of the sender must always uniquely identify a=0A=
session, whether or not the TSI is incuded in the LCT header=0A=
depends on what is used as the TSI value. If the underlying=0A=
transport is UDP, then the 16 bit UDP source port number may serve=0A=
as the TSI for the session. If Generic Router Assist (GRA) is=0A=
being used then additional dependencies may be introduced by GRA=0A=
on the TSI field. If the TSI value appears multiple times in a=0A=
packet then all occurrences must be the same value. If there is=0A=
no underlying TSI provided by the network, transport or any other=0A=
layer, then the TSI must be included in the LCT header.=0A=
=0A=
The TSI must be unique among all sessions served by the sender=0A=
during the period when the session is active, and for a large=0A=
period of time preceding and following when the session is active.=0A=
A primary purpose of the TSI is to prevent receivers from=0A=
inadvertently accepting packets from a sender that belong to=0A=
sessions other than sessions receivers are subscribed to. For=0A=
example, suppose a session is deactivated and then another session=0A=
=0A=
=0A=
=0A=
Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft Section 3.1. [Page 16]=0A=
=0C=0A=
INTERNET-DRAFT Expires: April 2002 October 2001=0A=
=0A=
=0A=
is activated by a sender and the two sessions use an overlapping=0A=
set of channels. A receiver that connects and remains connected=0A=
to the first session during this sender activity could possibly=0A=
accept packets from the second session as belonging to the first=0A=
session if the TSI for the two sessions were identical. The=0A=
mapping of TSI field values to sessions must be done out of band.=0A=
The length of the TSI field is 32*S + 16*H bits. Note that the=0A=
aggregate lengths of the TSI field plus the TOI field is a=0A=
multiple of 32 bits.=0A=
=0A=
=0A=
Transport Object Identifier (TOI): 0, 16, 32, 48, 64, 80, 96 or 112=0A=
bits.=0A=
=0A=
This field indicates which object within the session this packet=0A=
pertains to. For example, a sender might send a number of files=0A=
in the same session, using TOI=3D0 for the first file, TOI=3D1 for =
the=0A=
second one, etc. As another example, the TOI may be a unique=0A=
global identifier of the object that is being transmitted from=0A=
several senders concurrently, and the TOI value may be the ouptut=0A=
of a hash function applied to the object. The mapping of TOI field=0A=
values to objects must be done out of band. The TOI field must be=0A=
used in all packets if more than one object is to be transmitted=0A=
in a session, i.e. the TOI field is either present in all the=0A=
packets of a session or is never present.=0A=
The length of the TOI field is 32*O + 16*H bits. Note that the=0A=
aggregate lengths of the TSI field plus the TOI field is a=0A=
multiple of 32 bits.=0A=
=0A=
=0A=
Sender Current Time (SCT): 0 or 32 bits=0A=
=0A=
This field represents the current clock at the sender at the time=0A=
this packet was transmitted, measured in units of 1ms and computed=0A=
modulo 2^32 units from the start of the session.=0A=
This field must not be present if T=3D0 and must be present if =
T=3D1.=0A=
=0A=
=0A=
Expected Residual Time (ERT): 0 or 32 bits=0A=
=0A=
This field represents the sender expected residual transmission=0A=
time for the current session or for the transmission of the=0A=
current object, measured in units of 1ms. If the packet containing=0A=
the ERT field also contains the TOI field, then ERT refers to the=0A=
object corresponding to the TOI field, otherwise it refers to the=0A=
session.=0A=
This field must not be present if R=3D0 and must be present if =
R=3D1.=0A=
=0A=
=0A=
=0A=
=0A=
Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft Section 3.1. [Page 17]=0A=
=0C=0A=
INTERNET-DRAFT Expires: April 2002 October 2001=0A=
=0A=
=0A=
3.2. Header-Extension Fields=0A=
=0A=
Header Extensions are used in LCT to accommodate optional header fields=0A=
that are not always used or have variable size. Examples of the use of=0A=
Header Extensions include:=0A=
=0A=
o Extended-size versions of already existing header fields.=0A=
=0A=
o Sender and Receiver authentication information.=0A=
=0A=
=0A=
The presence of Header Extensions can be inferred by the LCT header=0A=
length (HDR_LEN): if HDR_LEN is larger than the length of the standard=0A=
header then the remaining header space is taken by Header Extension=0A=
fields.=0A=
=0A=
=0A=
If present, Header Extensions must be processed to ensure that they are=0A=
recognized before performing any congestion control procedure or=0A=
otherwise accepting a packet. The default action for unrecognized header=0A=
extensions is to ignore them. This allows the future introduction of=0A=
backward-compatible enhancements to LCT without changing the LCT version=0A=
number. Non backward-compatible header extensions CANNOT be introduced=0A=
without changing the LCT version number.=0A=
=0A=
Protocol instantiation may override this default behavior for PI-=0A=
specific extensions (see below).=0A=
=0A=
There are two formats for Header Extension fields, as depicted below.=0A=
The first format is used for variable-length extensions, with Header=0A=
Extension Type (HET) values between 0 and 127. The second format is used=0A=
for fixed length (one 32-bit word) extensions, using HET values from 127=0A=
to 255.=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft Section 3.2. [Page 18]=0A=
=0C=0A=
INTERNET-DRAFT Expires: April 2002 October 2001=0A=
=0A=
=0A=
0 1 2 3=0A=
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=0A=
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A=
| HET (<=3D127) | HEL | |=0A=
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +=0A=
. .=0A=
. Header Extension Content (HEC) .=0A=
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A=
=0A=
0 1 2 3=0A=
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=0A=
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A=
| HET (>=3D128) | Header Extension Content (HEC) |=0A=
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A=
=0A=
=0A=
Figure 5 - Format of additional headers=0A=
=0A=
=0A=
The explanation of each sub-field is the following.=0A=
=0A=
=0A=
Header Extension Type (HET): 8 bits=0A=
=0A=
The type of the Header Extension. This document defines a number=0A=
of possible types. Additional types may be defined in future=0A=
version of this specification. HET values from 0 to 127 are used=0A=
for variable-length Header Extensions. HET values from 128 to 255=0A=
are used for fixed-length 32-bit Header Extensions.=0A=
=0A=
=0A=
Header Extension Length (HEL): 8 bits=0A=
=0A=
The length of the whole Header Extension field, expressed in=0A=
multiples of 32-bit words. This field must be present for=0A=
variable-length extensions (HET between 0 and 127) and must not be=0A=
present for fixed-length extensions (HET between 128 and 255).=0A=
=0A=
=0A=
Header Extension Content (HEC): variable length=0A=
=0A=
The content of the Header Extension. The format of this sub-field=0A=
depends on the Header Extension type. For fixed-length Header=0A=
Extensions, the HEC is 24 bits. For variable-length Header=0A=
Extensions, the HEC field has variable size, as specified by the=0A=
HEL field. Note that the length of each Header Extension field=0A=
must be a multiple of 32 bits. Also note that the total size of=0A=
the LCT header, including all Header Extensions and all optional=0A=
=0A=
=0A=
=0A=
Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft Section 3.2. [Page 19]=0A=
=0C=0A=
INTERNET-DRAFT Expires: April 2002 October 2001=0A=
=0A=
=0A=
header fields, cannot exceed 255 32-bit words.=0A=
=0A=
=0A=
Header Extensions are further divided between general LCT extensions and=0A=
Protocol Instantiation specific extensions (PI-specific). General LCT=0A=
extensions have HET in the ranges 0:63 and 128:191 inclusive. PI-=0A=
specific extensions have HET in the ranges 64:127 and 192:255 inclusive.=0A=
=0A=
General LCT extensions are intended to allow the introduction of=0A=
backward-compatible enhancements to LCT without changing the LCT version=0A=
number. Non backward-compatible header extensions CANNOT be introduced=0A=
without changing the LCT version number.=0A=
=0A=
PI-specific extensions are reserved for PI-specific use with semantic=0A=
and default parsing actions defined by the PI.=0A=
=0A=
The following general LCT Header Extension types are defined:=0A=
=0A=
EXT_NOP=3D0 No-Operation extension.=0A=
The information present in this extension field must be=0A=
ignored by receivers.=0A=
=0A=
=0A=
EXT_AUTH=3D2 Packet authentication extension=0A=
Information used to authenticate the sender of the packet.=0A=
If present, the format of this Header Extension and its=0A=
processing must be communicated out-of-band as part of the=0A=
session description.=0A=
It is recommended that senders provide some form of packet=0A=
authentication. If EXT_AUTH is present, whatever packet=0A=
authentication checks that can be performed immediately=0A=
upon reception of the packet must be performed before=0A=
accepting the packet and performing any congestion=0A=
control-related action on it.=0A=
Some packet authentication schemes impose a delay of=0A=
several seconds between when a packet is received and when=0A=
the packet is fully authenticated. Any congestion control=0A=
related action that is appropriate must not be postponed=0A=
by any such full packet authentication.=0A=
=0A=
=0A=
All senders and receivers implementing LCT must support the EXT_NOP=0A=
Header Extension and must recognize EXT_AUTH, but may not be able to=0A=
parse its content.=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft Section 3.2. [Page 20]=0A=
=0C=0A=
INTERNET-DRAFT Expires: April 2002 October 2001=0A=
=0A=
=0A=
4. Procedures=0A=
=0A=
=0A=
4.1. Sender Operation=0A=
=0A=
A sender using LCT must make a session description available to clients=0A=
that want to join an LCT session. This information could include, but=0A=
is not limited to:=0A=
=0A=
o The number of LCT channels;=0A=
=0A=
o The addresses, port numbers and data rates used for each LCT=0A=
channel;=0A=
=0A=
o The formats of any other headers. For example, an FEC header as=0A=
described in [6] could be such an other header. Then for example=0A=
the information could include the mapping of codepoints used in the=0A=
session to FEC codec types and parameters;=0A=
=0A=
o The format and lengths of the packet payload;=0A=
=0A=
o The Transport Session ID (TSI) to be used for the session;=0A=
=0A=
o Whether or not Generic Router Assist (GRA) is being used;=0A=
=0A=
o The congestion control scheme being used;=0A=
=0A=
o The mapping of TOI value(s) to objects for the session;=0A=
=0A=
o Any information that is relevant to each object being transported,=0A=
such as when it will be available within the session, for how long,=0A=
and the length of the object;=0A=
=0A=
o The packet authentication scheme being used, and all relevant=0A=
information which is necessary for client packet authentication=0A=
purposes;=0A=
=0A=
=0A=
Some of the session description information must be obtained by=0A=
receivers before they connect to the session. This includes the number=0A=
and addresses of the LCT channels, the TSI value for the session, the=0A=
formats of any other headers, the congestion control scheme being used=0A=
and the packet authentication scheme if it is used. Some of the session=0A=
description information may be obtained by receivers while they are=0A=
connected to the session, e.g., information relevant to objects being=0A=
transported within the session such as their TOI, when they are=0A=
available within the session, for how long, and their lengths.=0A=
=0A=
=0A=
=0A=
=0A=
Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft Section 4.1. [Page 21]=0A=
=0C=0A=
INTERNET-DRAFT Expires: April 2002 October 2001=0A=
=0A=
=0A=
The session description could be in a form such as SDP as defined in=0A=
RFC2327, XML metadata, HTTP/Mime headers, etc. It might be carried in a=0A=
session announcement protocol such as SAP as defined in RFC2974,=0A=
obtained using a proprietary session control protocol, located on a Web=0A=
page with scheduling information, or conveyed via E-mail or other out of=0A=
band methods. Discussion of session description format, and=0A=
distribution of session descriptions is beyond the scope of this=0A=
document.=0A=
=0A=
Within an LCT session, a sender using LCT transmits a sequence of=0A=
packets each in a format defined in the session description. Packets=0A=
are sent from a sender using one or more LCT channels which together=0A=
constitute a session. Transmission rates may be different in different=0A=
channels and may vary over time. The specification of the other=0A=
building block headers and the packet payload used by a complete=0A=
protocol instantiation using LCT is beyond the scope of this document.=0A=
This document does not specify the order in which packets are=0A=
transmitted, nor the organization of a session into multiple channels.=0A=
Although these issues affect the efficiency of the protocol, they do not=0A=
affect the correctness nor the inter-operability of LCT between senders=0A=
and receivers.=0A=
=0A=
Multiple objects can be carried within the same LCT session. In this=0A=
case, each object must be identified by a unique TOI. Objects may be=0A=
transmitted sequentially, or they may be transmitted concurrently. It=0A=
is good practice to only send objects concurrently in the same session=0A=
if the receivers that participate in that portion of the session have=0A=
interest in receiving all the objects. The reason for this is that it=0A=
wastes bandwidth and networking resources to have receivers receive data=0A=
for objects that they have no interest in.=0A=
=0A=
Typically, the sender(s) continues to send packets in a session until=0A=
the transmission is considered complete. The transmission may be=0A=
considered complete when some time has expired, a certain number of=0A=
packets have been sent, or some out of band signal (possibly from a=0A=
higher level protocol) has indicated completion by a sufficient number=0A=
of receivers.=0A=
=0A=
For the reasons mentioned above, this document does not pose any=0A=
restriction on packet sizes. However, network efficiency considerations=0A=
recommend that the sender uses as large as possible packet payload size,=0A=
but in such a way that packets do not exceed the network's maximum=0A=
transmission unit size (MTU), or fragmentation coupled with packet loss=0A=
might introduce severe inefficiency in the transmission.=0A=
=0A=
It is recommended that all packets have the same or very similar sizes,=0A=
as this can have a severe impact on the effectiveness of congestion=0A=
control schemes such as the ones described in [11] and [1]. A sender of=0A=
=0A=
=0A=
=0A=
Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft Section 4.1. [Page 22]=0A=
=0C=0A=
INTERNET-DRAFT Expires: April 2002 October 2001=0A=
=0A=
=0A=
packets using LCT must implement the sender-side part of one of the=0A=
congestion control schemes that is in accordance with RFC2357 using the=0A=
Congestion Control Information field provided in the LCT header, and the=0A=
corresponding receiver congestion control scheme must be communicated=0A=
out of band and implemented by any receivers participating in the=0A=
session.=0A=
=0A=
=0A=
4.2. Receiver Operation=0A=
=0A=
Receivers can operate differently depending on the delivery service=0A=
model. For example, for an on demand service model receivers may join a=0A=
session, obtain the necessary encoding symbols to reproduce the object,=0A=
and then leave the session. As another example, for a streaming service=0A=
model a receiver may be continuously joined to a set of LCT channels to=0A=
download all objects in a session.=0A=
=0A=
To be able to participate in a session, a receiver must first obtain the=0A=
relevant session description information as listed in Section 4.1.=0A=
=0A=
If packet authentication information is present in an LCT header, it=0A=
should be used as specified in Section 3.2. To be able to be a receiver=0A=
in a session, the receiver must be able to process the LCT header. The=0A=
receiver must be able to discard, forward, store or process the other=0A=
headers and the packet payload. If a receiver is not able to process a=0A=
LCT header, it must drop from the session.=0A=
=0A=
To be able to participate in a session, a receiver must implement the=0A=
congestion control protocol specified in the session description using=0A=
the Congestion Control Information field provided in the LCT header. If=0A=
a receiver is not able to implement the congestion control protocol used=0A=
in the session, it must not join the session. When the session is=0A=
transmitted on multiple LCT channels, receivers must initially join=0A=
channels according to the specified startup behavior of the congestion=0A=
control protocol itself. For a layered transmission on multiple=0A=
channels, this typically means that a receiver will initially join only=0A=
a minimal set of LCT channels, possibly a single one, that in aggregate=0A=
are carrying packets at a low rate. This rule has the purpose of=0A=
preventing receivers from starting at high data rates.=0A=
=0A=
Multiple objects can be carried either sequentially or concurrently=0A=
within the same LCT session. In this case, each object is identified by=0A=
a unique TOI. Note that even if a server stops sending packets for an=0A=
old object before starting to transmit packets for a new object, both=0A=
the network and the underlying protocol layers can cause some reordering=0A=
of packets, especially when sent over different LCT channels, and thus=0A=
receivers should not assume that the reception of a packet for a new=0A=
object means that there are no more packets in transit for the previous=0A=
=0A=
=0A=
=0A=
Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft Section 4.2. [Page 23]=0A=
=0C=0A=
INTERNET-DRAFT Expires: April 2002 October 2001=0A=
=0A=
=0A=
one, at least for some amount of time.=0A=
=0A=
A receiver may be concurrently joined to multiple LCT sessions from one=0A=
or more senders. The receiver must perform congestion control on each=0A=
such LCT session. If the congestion control protocol allows the=0A=
receiver some flexibility in terms of its actions within a session then=0A=
the receiver may make choices to optimize the packet flow performance=0A=
across the multiple LCT sessions, as long as the receiver still adheres=0A=
to the congestion control rules for each LCT session individually.=0A=
=0A=
=0A=
5. Security Considerations=0A=
=0A=
LCT can be subject to denial-of-service attacks by attackers which try=0A=
to confuse the congestion control mechanism, or send forged packets to=0A=
the session which would prevent successful reconstruction of large=0A=
portions of the objects.=0A=
=0A=
The same exact problems are present in TCP, where an attacker can forge=0A=
packets and either slow down or increase the throughput of the session,=0A=
or replace parts of the data stream with forged data. If the stream is=0A=
carrying compressed or otherwise coded data, even a single forged packet=0A=
could also cause incorrect reconstruction of the rest of the data=0A=
stream.=0A=
=0A=
It is therefore recommended that protocol instantiations that use LCT=0A=
implement some form of packet authentication to protect themselves=0A=
against such attacks.=0A=
=0A=
=0A=
6. IANA Considerations=0A=
=0A=
No information in this specification is subject to IANA registration.=0A=
=0A=
Building blocks used in conjunction with LCT may introduce additional=0A=
IANA considerations.=0A=
=0A=
=0A=
7. Intellectual Property Issues=0A=
=0A=
=0A=
No specific reliability protocol or congestion control protocol is=0A=
specified or referenced as mandatory in this document.=0A=
=0A=
LCT may be used with congestion control protocols and other protocols,=0A=
such as reliability protocols, which are proprietary or have pending or=0A=
granted patents.=0A=
=0A=
=0A=
=0A=
=0A=
Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft Section 7. [Page 24]=0A=
=0C=0A=
INTERNET-DRAFT Expires: April 2002 October 2001=0A=
=0A=
=0A=
8. Acknowledgments=0A=
=0A=
Thanks to Vincent Roca, Bruce Lueckenhoff, Hayder Radha and Justin=0A=
Chapweske for detailed comments on this document.=0A=
=0A=
=0A=
9. References=0A=
=0A=
=0A=
[1] Byers, J.W., Frumin, M., Horn, G., Luby, M., Mitzenmacher, M.,=0A=
Roetter, A., and Shaver, W., "FLID-DL: Congestion Control for Layered=0A=
Multicast", Proceedings of Second International Workshop on Networked=0A=
Group Communications (NGC 2000), Palo Alto, CA, November 2000.=0A=
=0A=
[2] Byers, J.W., Luby, M., Mitzenmacher, M., and Rege, A., "A Digital=0A=
Fountain Approach to Reliable Distribution of Bulk Data", Proceedings=0A=
ACM SIGCOMM '98, Vancouver, Canada, September 1998.=0A=
=0A=
[3] Gemmell, J., Schooler, E., and Gray, J., "Fcast Multicast File=0A=
Distribution", IEEE Network, Vol. 14, No. 1, pp. 58-68, January 2000.=0A=
=0A=
[4] Holbrook, H. W., "A Channel Model for Multicast," Ph.D.=0A=
Dissertation, Stanford University, Department of Computer Science,=0A=
Stanford, California, August 2001.=0A=
=0A=
[5] Luby, M., Gemmell, Vicisano, L., J., Rizzo, L., Handley, M.,=0A=
Crowcroft, J., "The use of Forward Error Correction in Reliable=0A=
Multicast", Internet Draft draft-ietf-rmt-info-fec-01.txt, October 2001,=0A=
a work in progress.=0A=
=0A=
[6] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., Handley, M.,=0A=
Crowcroft, J., "RMT BB Forward Error Correction Codes", Internet Draft=0A=
draft-ietf-rmt-bb-fec-04.txt, October 2001.=0A=
=0A=
[7] Rizzo, L., "Effective Erasure Codes for Reliable Computer=0A=
Communication Protocols", ACM SIGCOMM Computer Communication Review,=0A=
Vol.27, No.2, pp.24-36, Apr 1997.=0A=
=0A=
[8] Perrig, A., Canetti, R., Song, D., Tygar, J.D., "Efficient and=0A=
Secure Source Authentication for Multicast", Network and Distributed=0A=
System Security Symposium, NDSS 2001, pp. 35-46, February 2001.=0A=
=0A=
[9] Rizzo, L, and Vicisano, L., "Reliable Multicast Data Distribution=0A=
protocol based on software FEC techniques", Proceedings of the Fourth=0A=
IEEES Workshop on the Architecture and Implementation of High=0A=
Performance Communication Systems, HPCS'97, Chalkidiki Greece, June=0A=
1997.=0A=
=0A=
=0A=
=0A=
=0A=
Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft Section 9. [Page 25]=0A=
=0C=0A=
INTERNET-DRAFT Expires: April 2002 October 2001=0A=
=0A=
=0A=
[10] Rizzo, L, "PGMCC: A TCP-friendly single-rate multicast congestion=0A=
control scheme", Proceedings of SIGCOMM 2000, Stockholm Sweden, August=0A=
2000.=0A=
=0A=
[11] Vicisano, L., Rizzo, L., Crowcroft, J., "TCP-like Congestion=0A=
Control for Layered Multicast Data Transfer", IEEE Infocom '98, San=0A=
Francisco, CA, Mar.28-Apr.1 1998.=0A=
=0A=
=0A=
=0A=
10. Authors' Addresses=0A=
=0A=
Michael Luby=0A=
luby@digitalfountain.com=0A=
Digital Fountain=0A=
39141 Civic Center Drive=0A=
Suite 300=0A=
Fremont, CA, USA, 94538=0A=
=0A=
Jim Gemmell=0A=
jgemmell@microsoft.com=0A=
Microsoft Research=0A=
301 Howard St., #830=0A=
San Francisco, CA, USA, 94105=0A=
=0A=
Lorenzo Vicisano=0A=
lorenzo@cisco.com=0A=
cisco Systems, Inc.=0A=
170 West Tasman Dr.,=0A=
San Jose, CA, USA, 95134=0A=
=0A=
Luigi Rizzo=0A=
luigi@iet.unipi.it=0A=
ACIRI/ICSI,=0A=
1947 Center St, Berkeley, CA, USA, 94704=0A=
and=0A=
Dip. Ing. dell'Informazione,=0A=
Univ. di Pisa=0A=
via Diotisalvi 2, 56126 Pisa, Italy=0A=
=0A=
Mark Handley=0A=
mjh@aciri.org=0A=
ACIRI,=0A=
1947 Center St,=0A=
Berkeley, CA, USA, 94704=0A=
=0A=
Jon Crowcroft=0A=
J.Crowcroft@cs.ucl.ac.uk=0A=
=0A=
=0A=
=0A=
Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft Section 10. [Page 26]=0A=
=0C=0A=
INTERNET-DRAFT Expires: April 2002 October 2001=0A=
=0A=
=0A=
Department of Computer Science=0A=
University College London=0A=
Gower Street,=0A=
London WC1E 6BT, UK=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft Section 10. [Page 27]=0A=
=0C=0A=
INTERNET-DRAFT Expires: April 2002 October 2001=0A=
=0A=
=0A=
11. Full Copyright Statement=0A=
=0A=
Copyright (C) The Internet Society (2001). All Rights Reserved.=0A=
=0A=
This document and translations of it may be copied and furnished to=0A=
others, and derivative works that comment on or otherwise explain it or=0A=
assist in its implementation may be prepared, copied, published and=0A=
distributed, in whole or in part, without restriction of any kind,=0A=
provided that the above copyright notice and this paragraph are included=0A=
on all such copies and derivative works. However, this document itself=0A=
may not be modified in any way, such as by removing the copyright notice=0A=
or references to the Internet Society or other Internet organizations,=0A=
except as needed for the purpose of developing Internet standards in=0A=
which case the procedures for copyrights defined in the Internet=0A=
languages other than English.=0A=
=0A=
The limited permissions granted above are perpetual and will not be=0A=
revoked by the Internet Society or its successors or assigns.=0A=
=0A=
This document and the information contained herein is provided on an "AS=0A=
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK=0A=
FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT not=0A=
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL not=0A=
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR=0A=
FITNESS FOR A PARTICULAR PURPOSE."=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft Section 11. [Page 28]=0A=
=0C=0A=
INTERNET-DRAFT Expires: April 2002 October 2001=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
Luby/Gemmell/Vicisano/Rizzo/Handley/Crowcroft Section 11. [Page 29]=0A=
------=_NextPart_000_0005_01C157E0.AE079D70
Content-Type: application/postscript;
name="draft-ietf-rmt-bb-lct-02.ps"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
filename="draft-ietf-rmt-bb-lct-02.ps"
%!PS-Adobe-3.0=0A=
%%Creator: groff version 1.15=0A=
%%CreationDate: Thu Oct 18 10:41:51 2001=0A=
%%DocumentNeededResources: font Courier-Bold=0A=
%%+ font Times-Bold=0A=
%%+ font Times-Roman=0A=
%%+ font Courier=0A=
%%DocumentSuppliedResources: procset grops 1.15 1=0A=
%%Pages: 22=0A=
%%PageOrder: Ascend=0A=
%%Orientation: Portrait=0A=
%%EndComments=0A=
%%BeginProlog=0A=
%%BeginResource: procset grops 1.15 1=0A=
/setpacking where{=0A=
pop=0A=
currentpacking=0A=
true setpacking=0A=
}if=0A=
/grops 120 dict dup begin=0A=
/SC 32 def=0A=
/A/show load def=0A=
/B{0 SC 3 -1 roll widthshow}bind def=0A=
/C{0 exch ashow}bind def=0A=
/D{0 exch 0 SC 5 2 roll awidthshow}bind def=0A=
/E{0 rmoveto show}bind def=0A=
/F{0 rmoveto 0 SC 3 -1 roll widthshow}bind def=0A=
/G{0 rmoveto 0 exch ashow}bind def=0A=
/H{0 rmoveto 0 exch 0 SC 5 2 roll awidthshow}bind def=0A=
/I{0 exch rmoveto show}bind def=0A=
/J{0 exch rmoveto 0 SC 3 -1 roll widthshow}bind def=0A=
/K{0 exch rmoveto 0 exch ashow}bind def=0A=
/L{0 exch rmoveto 0 exch 0 SC 5 2 roll awidthshow}bind def=0A=
/M{rmoveto show}bind def=0A=
/N{rmoveto 0 SC 3 -1 roll widthshow}bind def=0A=
/O{rmoveto 0 exch ashow}bind def=0A=
/P{rmoveto 0 exch 0 SC 5 2 roll awidthshow}bind def=0A=
/Q{moveto show}bind def=0A=
/R{moveto 0 SC 3 -1 roll widthshow}bind def=0A=
/S{moveto 0 exch ashow}bind def=0A=
/T{moveto 0 exch 0 SC 5 2 roll awidthshow}bind def=0A=
/SF{=0A=
findfont exch=0A=
[exch dup 0 exch 0 exch neg 0 0]makefont=0A=
dup setfont=0A=
[exch/setfont cvx]cvx bind def=0A=
}bind def=0A=
/MF{=0A=
findfont=0A=
[5 2 roll=0A=
0 3 1 roll=0A=
neg 0 0]makefont=0A=
dup setfont=0A=
[exch/setfont cvx]cvx bind def=0A=
}bind def=0A=
/level0 0 def=0A=
/RES 0 def=0A=
/PL 0 def=0A=
/LS 0 def=0A=
/MANUAL{=0A=
statusdict begin/manualfeed true store end=0A=
}bind def=0A=
/PLG{=0A=
gsave newpath clippath pathbbox grestore=0A=
exch pop add exch pop=0A=
}bind def=0A=
/BP{=0A=
/level0 save def=0A=
1 setlinecap=0A=
1 setlinejoin=0A=
72 RES div dup scale=0A=
LS{=0A=
90 rotate=0A=
}{=0A=
0 PL translate=0A=
}ifelse=0A=
1 -1 scale=0A=
}bind def=0A=
/EP{=0A=
level0 restore=0A=
showpage=0A=
}bind def=0A=
/DA{=0A=
newpath arcn stroke=0A=
}bind def=0A=
/SN{=0A=
transform=0A=
.25 sub exch .25 sub exch=0A=
round .25 add exch round .25 add exch=0A=
itransform=0A=
}bind def=0A=
/DL{=0A=
SN=0A=
moveto=0A=
SN=0A=
lineto stroke=0A=
}bind def=0A=
/DC{=0A=
newpath 0 360 arc closepath=0A=
}bind def=0A=
/TM matrix def=0A=
/DE{=0A=
TM currentmatrix pop=0A=
translate scale newpath 0 0 .5 0 360 arc closepath=0A=
TM setmatrix=0A=
}bind def=0A=
/RC/rcurveto load def=0A=
/RL/rlineto load def=0A=
/ST/stroke load def=0A=
/MT/moveto load def=0A=
/CL/closepath load def=0A=
/FL{=0A=
currentgray exch setgray fill setgray=0A=
}bind def=0A=
/BL/fill load def=0A=
/LW/setlinewidth load def=0A=
/RE{=0A=
findfont=0A=
dup maxlength 1 index/FontName known not{1 add}if dict begin=0A=
{=0A=
1 index/FID ne{def}{pop pop}ifelse=0A=
}forall=0A=
/Encoding exch def=0A=
dup/FontName exch def=0A=
currentdict end definefont pop=0A=
}bind def=0A=
/DEFS 0 def=0A=
/EBEGIN{=0A=
moveto=0A=
DEFS begin=0A=
}bind def=0A=
/EEND/end load def=0A=
/CNT 0 def=0A=
/level1 0 def=0A=
/PBEGIN{=0A=
/level1 save def=0A=
translate=0A=
div 3 1 roll div exch scale=0A=
neg exch neg exch translate=0A=
0 setgray=0A=
0 setlinecap=0A=
1 setlinewidth=0A=
0 setlinejoin=0A=
10 setmiterlimit=0A=
[]0 setdash=0A=
/setstrokeadjust where{=0A=
pop=0A=
false setstrokeadjust=0A=
}if=0A=
/setoverprint where{=0A=
pop=0A=
false setoverprint=0A=
}if=0A=
newpath=0A=
/CNT countdictstack def=0A=
userdict begin=0A=
/showpage{}def=0A=
}bind def=0A=
/PEND{=0A=
clear=0A=
countdictstack CNT sub{end}repeat=0A=
level1 restore=0A=
}bind def=0A=
end def=0A=
/setpacking where{=0A=
pop=0A=
setpacking=0A=
}if=0A=
%%EndResource=0A=
%%IncludeResource: font Courier-Bold=0A=
%%IncludeResource: font Times-Bold=0A=
%%IncludeResource: font Times-Roman=0A=
%%IncludeResource: font Courier=0A=
grops begin/DEFS 1 dict def DEFS begin/u{.001 mul}bind def end/RES 72=0A=
def/PL 792 def/LS false def/ENC0[/asciicircum/asciitilde/Scaron/Zcaron=0A=
/scaron/zcaron/Ydieresis/trademark/quotesingle/.notdef/.notdef/.notdef=0A=
/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef=0A=
/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef=0A=
/.notdef/.notdef/space/exclam/quotedbl/numbersign/dollar/percent=0A=
/ampersand/quoteright/parenleft/parenright/asterisk/plus/comma/hyphen=0A=
/period/slash/zero/one/two/three/four/five/six/seven/eight/nine/colon=0A=
/semicolon/less/equal/greater/question/at/A/B/C/D/E/F/G/H/I/J/K/L/M/N/O=0A=
/P/Q/R/S/T/U/V/W/X/Y/Z/bracketleft/backslash/bracketright/circumflex=0A=
/underscore/quoteleft/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y=0A=
/z/braceleft/bar/braceright/tilde/.notdef/quotesinglbase/guillemotleft=0A=
/guillemotright/bullet/florin/fraction/perthousand/dagger/daggerdbl=0A=
/endash/emdash/ff/fi/fl/ffi/ffl/dotlessi/dotlessj/grave/hungarumlaut=0A=
/dotaccent/breve/caron/ring/ogonek/quotedblleft/quotedblright/oe/lslash=0A=
/quotedblbase/OE/Lslash/.notdef/exclamdown/cent/sterling/currency/yen=0A=
/brokenbar/section/dieresis/copyright/ordfeminine/guilsinglleft=0A=
/logicalnot/minus/registered/macron/degree/plusminus/twosuperior=0A=
/threesuperior/acute/mu/paragraph/periodcentered/cedilla/onesuperior=0A=
/ordmasculine/guilsinglright/onequarter/onehalf/threequarters=0A=
/questiondown/Agrave/Aacute/Acircumflex/Atilde/Adieresis/Aring/AE=0A=
/Ccedilla/Egrave/Eacute/Ecircumflex/Edieresis/Igrave/Iacute/Icircumflex=0A=
/Idieresis/Eth/Ntilde/Ograve/Oacute/Ocircumflex/Otilde/Odieresis=0A=
/multiply/Oslash/Ugrave/Uacute/Ucircumflex/Udieresis/Yacute/Thorn=0A=
/germandbls/agrave/aacute/acircumflex/atilde/adieresis/aring/ae/ccedilla=0A=
/egrave/eacute/ecircumflex/edieresis/igrave/iacute/icircumflex/idieresis=0A=
/eth/ntilde/ograve/oacute/ocircumflex/otilde/odieresis/divide/oslash=0A=
/ugrave/uacute/ucircumflex/udieresis/yacute/thorn/ydieresis]def=0A=
/Courier@0 ENC0/Courier RE/Times-Roman@0 ENC0/Times-Roman RE=0A=
/Times-Bold@0 ENC0/Times-Bold RE/Courier-Bold@0 ENC0/Courier-Bold RE=0A=
%%EndProlog=0A=
%%Page: 1 1=0A=
%%BeginPageSetup=0A=
BP=0A=
%%EndPageSetup=0A=
/F0 10/Courier-Bold@0 SF(Internet Engineering Task Force)72 85 Q(RMT WG)=0A=
209.999 E 203.999(INTERNET-DRAFT M.Luby/Digital)72 98 R(Fountain)6 E=0A=
149.999(draft-ietf-rmt-bb-lct-02.ps J.Gemmell/Microsoft)72 111 R=0A=
(L.Vicisano/Cisco)407.999 124 Q(L.Rizzo/ACIRI and Univ. Pisa)335.999 137=0A=
Q(M.Handley/ACIRI)413.999 150 Q(J. Crowcroft/UCL)407.999 163 Q=0A=
(18 October 2001)413.999 176 Q(Expires: April 2002)389.999 189 Q/F1 14=0A=
/Times-Bold@0 SF(Lay)205.491 214 Q(er)-.14 E(ed Coding T)-.252 E=0A=
(ransport:)-1.036 E 3.5(Am)102.717 227 S(assi)-3.5 E -.14(ve)-.14 G=0A=
(ly scalable content deli).14 E -.14(ve)-.14 G(ry transport b).14 E=0A=
(uilding block)-.28 E/F2 11/Times-Bold@0 SF(Status of this Document)72=0A=
272 Q/F3 11/Times-Roman@0 SF(This document is an Internet-Draft and is \=0A=
in full conformance with all pro)72 288.6 Q(visions of Section 10 of)=0A=
-.165 E(RFC2026.)72 301.6 Q(Internet-Drafts are w)72 327.6 Q=0A=
(orking documents of the Internet Engineering T)-.11 E(ask F)-.88 E=0A=
(orce \(IETF\), its areas,)-.165 E(and its w)72 340.6 Q(orking groups.)=0A=
-.11 E(Note that other groups may also distrib)5.5 E(ute w)-.22 E=0A=
(orking documents as)-.11 E(Internet-Drafts.)72 353.6 Q=0A=
(Internet-Drafts are v)72 379.6 Q=0A=
(alid for a maximum of six months and may be updated, replaced, or)-.275=0A=
E(obsoleted by other documents at an)72 392.6 Q 2.75(yt)-.165 G 2.75=0A=
(ime. It)-2.75 F(is inappropriate to use Internet-Drafts as reference)=0A=
2.75 E(material or to cite them other than as a "w)72 405.6 Q=0A=
(ork in progress".)-.11 E=0A=
(The list of current Internet-Drafts can be accessed at http://www)72=0A=
431.6 Q(.ietf.or)-.715 E(g/ietf/1id-abstracts.txt)-.198 E 1.76 -.88=0A=
(To v)72 457.6 T(ie).88 E 2.75(wt)-.275 G(he list Internet-Draft Shado)=0A=
-2.75 E 2.75(wD)-.275 G(irectories, see http://www)-2.75 E(.ietf.or)=0A=
-.715 E(g/shado)-.198 E -.715(w.)-.275 G(html.).715 E=0A=
(This document is a product of the IETF RMT WG.)72 483.6 Q=0A=
(Comments should be addressed to the)5.5 E(authors, or the WG')72 496.6=0A=
Q 2.75(sm)-.605 G(ailing list at rmt@lbl.go)-2.75 E -.715(v.)-.165 G F2=0A=
(Abstract)267.534 528.6 Q F3(This document describes Layered Coding T)97=0A=
551.2 Q(ransport, a massi)-.385 E -.165(ve)-.275 G(ly scalable reliable)=0A=
.165 E(content deli)97 564.2 Q -.165(ve)-.275 G(ry and stream deli).165=0A=
E -.165(ve)-.275 G(ry transport, hereafter referred to as LCT).165 E 5.5=0A=
(.L)-.814 G(CT can)-5.5 E(be used for multi-rate deli)97 577.2 Q -.165=0A=
(ve)-.275 G(ry to lar).165 E(ge sets of recei)-.198 E -.165(ve)-.275 G=0A=
2.75(rs. In).165 F(LCT)2.75 E 2.75(,s)-.814 G(calability and)-2.75 E(co\=0A=
ngestion control are supported through the use of layered coding techni\=0A=
ques. Coding)97 590.2 Q(techniques can be combined with LCT to pro)97=0A=
603.2 Q(vide support for reliability)-.165 E(.)-.715 E=0A=
(Congestion control is recei)97 629.2 Q -.165(ve)-.275 G 2.75(rd).165 G=0A=
(ri)-2.75 E -.165(ve)-.275 G(n, and can be achie).165 E -.165(ve)-.275 G=0A=
2.75(db).165 G 2.75(ys)-2.75 G(ending pack)-2.75 E(ets in the)-.11 E=0A=
(session to multiple `)97 642.2 Q(`LCT channels')-.814 E(', and ha)-.814=0A=
E(ving recei)-.22 E -.165(ve)-.275 G(rs join and lea).165 E .33 -.165=0A=
(ve L)-.22 H(CT).165 E=0A=
(channels \(thus adjusting their reception rate\) in reaction to netw)97=0A=
655.2 Q(ork conditions in a)-.11 E(manner that is netw)97 668.2 Q=0A=
(ork friendly)-.11 E(.)-.715 E(Luby/Gemmell/V)72 769 Q=0A=
(icisano/Rizzo/Handle)-.66 E(y/Cro)-.165 E 166.856(wcroft [P)-.275 F=0A=
(age 1])-.165 E EP=0A=
%%Page: 2 2=0A=
%%BeginPageSetup=0A=
BP=0A=
%%EndPageSetup=0A=
/F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 77.081(-DRAFT Expires:)-1.012 F=0A=
(April 2002)2.75 E(October 2001)112.127 E/F1 13/Times-Bold@0 SF -1.196=0A=
(Ta)239.126 85 S(ble of Contents)1.196 E/F2 10/Times-Roman@0 SF=0A=
(1. Introduction)97 123 Q F0 11(......................)3.56 G F2(3)11.5=0A=
E(1.1. Related Documents)107 135 Q F0 11(..................)11.9 G F2(5)=0A=
11.5 E(1.2. En)107 147 Q(vironmental Requirements and Considerations)-.4=0A=
E F0 11(..........)3.97 G F2(5)11.5 E(2. General Architecture)97 159 Q=0A=
F0 11(...................)10.12 G F2(7)11.5 E(2.1. Deli)107 171 Q -.15=0A=
(ve)-.25 G(ry service models).15 E F0 11(.................)7.45 G F2(8)=0A=
11.5 E(2.2. Congestion Control)107 183 Q F0 11(..................)11.88=0A=
G F2(9)11.5 E(3. LCT header)97 195 Q F0 11(......................)4.96 G=0A=
F2(9)11.5 E(3.1. Def)107 207 Q(ault LCT header format)-.1 E F0 11=0A=
(................)8.41 G F2(9)11.5 E(3.2. Header)107 219 Q=0A=
(-Extension Fields)-.2 E F0 11(.................)5.3 G F2(13)6.5 E=0A=
(4. Procedures)97 231 Q F0 11(......................)8.57 G F2(15)6.5 E=0A=
(4.1. Sender Operation)107 243 Q F0 11(...................)6.49 G F2(15)=0A=
6.5 E(4.2. Recei)107 255 Q -.15(ve)-.25 G 2.5(rO).15 G(peration)-2.5 E=0A=
F0 11(..................)12.87 G F2(17)6.5 E(5. Security Considerations)=0A=
97 267 Q F0 11(..................)12.17 G F2(17)6.5 E(6. IAN)97 279 Q=0A=
2.5(AC)-.35 G(onsiderations)-2.5 E F0 11(...................)7.11 G F2=0A=
(18)6.5 E(7. Intellectual Property Issues)97 291 Q F0 11=0A=
(.................)12.88 G F2(18)6.5 E(8. Ackno)97 303 Q(wledgments)-.25=0A=
E F0 11(....................)5.76 G F2(18)6.5 E(9. References)97 315 Q=0A=
F0 11(......................)8.58 G F2(18)6.5 E(10. Authors' Addresses)=0A=
97 327 Q F0 11(...................)10.1 G F2(19)6.5 E(11. Full Cop)97=0A=
339 Q(yright Statement)-.1 E F0 11(..................)1.42 G F2(21)6.5 E=0A=
F0(Luby/Gemmell/V)72 769 Q(icisano/Rizzo/Handle)-.66 E(y/Cro)-.165 E=0A=
166.856(wcroft [P)-.275 F(age 2])-.165 E EP=0A=
%%Page: 3 3=0A=
%%BeginPageSetup=0A=
BP=0A=
%%EndPageSetup=0A=
/F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 77.081(-DRAFT Expires:)-1.012 F=0A=
(April 2002)2.75 E(October 2001)112.127 E/F1 11/Times-Bold@0 SF(1.)72 85=0A=
Q/F2 14/Times-Bold@0 SF(Intr)5.5 E(oduction)-.252 E F0=0A=
(This document describes a massi)72 101.6 Q -.165(ve)-.275 G=0A=
(ly scalable reliable content deli).165 E -.165(ve)-.275 G=0A=
(ry and stream deli).165 E -.165(ve)-.275 G(ry).165 E=0A=
(transport, Layered Coding T)72 114.6 Q=0A=
(ransport \(LCT\), for multi-rate content deli)-.385 E -.165(ve)-.275 G=0A=
(ry primarily designed to).165 E(be used with the IP multicast netw)72=0A=
127.6 Q(ork service, b)-.11 E=0A=
(ut may also be used with other basic underlying)-.22 E(netw)72 140.6 Q=0A=
(ork or transport services such as unicast UDP)-.11 E 5.5(.L)-1.221 G=0A=
(CT supports both reliable and unreliable)-5.5 E(deli)72 153.6 Q -.165=0A=
(ve)-.275 G(ry).165 E(.)-.715 E(LCT is a b)72 179.6 Q=0A=
(uilding block as de\214ned in RFC3048.)-.22 E=0A=
(Protocol instantiations may be b)5.5 E(uilt by)-.22 E=0A=
(combining the LCT frame)72 192.6 Q -.11(wo)-.275 G=0A=
(rk with other components.).11 E 2.75(Ac)5.5 G=0A=
(omplete protocol instantiation that)-2.75 E(uses LCT must include a co\=0A=
ngestion control protocol that is compatible with LCT and that)72 205.6=0A=
Q(conforms to RFC2357.)72 218.6 Q 2.75(Ac)5.5 G=0A=
(omplete protocol instantiation that uses LCT may include a scalable)=0A=
-2.75 E(reliability protocol that is compatible with LCT)72 231.6 Q 2.75=0A=
(,i)-.814 G 2.75(tm)-2.75 G=0A=
(ay include an session control protocol that is)-2.75 E=0A=
(compatible with LCT)72 244.6 Q 2.75(,a)-.814 G=0A=
(nd it may include other protocols such as security protocols.)-2.75 E=0A=
(LCT is presumed to be used with an underlying netw)72 270.6 Q=0A=
(ork or transport service that is a "best ef)-.11 E(fort")-.275 E=0A=
(service that does not guarantee pack)72 283.6 Q(et reception, pack)-.11=0A=
E(et reception order)-.11 E 2.75(,a)-.44 G(nd which does not ha)-2.75 E=0A=
-.165(ve)-.22 G(an)72 296.6 Q 2.75(ys)-.165 G(upport for \215o)-2.75 E=0A=
2.75(wo)-.275 G 2.75(rc)-2.75 G(ongestion control.)-2.75 E -.165(Fo)5.5=0A=
G 2.75(re).165 G(xample, the An)-2.915 E=0A=
(y-Source Multicast \(ASM\) model)-.165 E=0A=
(of IP multicast as de\214ned in RFC1112 is such a "best ef)72 309.6 Q=0A=
(fort" netw)-.275 E(ork service.)-.11 E(While the basic)5.5 E=0A=
(service pro)72 322.6 Q(vided by RFC1112 is lar)-.165 E=0A=
(gely scalable, pro)-.198 E(viding congestion control or reliability)=0A=
-.165 E(should be done carefully to a)72 335.6 Q -.22(vo)-.22 G(id se)=0A=
.22 E -.165(ve)-.275 G=0A=
(re scalability limitations, especially in presence of).165 E=0A=
(heterogeneous sets of recei)72 348.6 Q -.165(ve)-.275 G(rs.).165 E=0A=
-.165(Pa)72 374.6 S(ck).165 E(ets with LCT headers are carried in LCT c\=0A=
hannels. An LCT channel is de\214ned by the)-.11 E(combination of a sen\=0A=
der and an address associated with the channel by the sender)72 387.6 Q=0A=
5.5(.A)-.605 G(recei)-2.75 E -.165(ve)-.275 G(r).165 E=0A=
(may join a channel to start recei)72 400.6 Q(ving the data pack)-.275 E=0A=
(ets sent to the channel by the sender)-.11 E 2.75(,a)-.44 G(nd a)-2.75=0A=
E(recei)72 413.6 Q -.165(ve)-.275 G 2.75(rm).165 G(ay lea)-2.75 E .33=0A=
-.165(ve a c)-.22 H(hannel to stop recei).165 E(ving data pack)-.275 E=0A=
(ets from the channel.)-.11 E(An LCT session consists of a set of logic\=0A=
ally grouped LCT channels associated with a single)72 439.6 Q=0A=
(sender carrying pack)72 452.6 Q=0A=
(ets with LCT headers for one or more objects.)-.11 E=0A=
(Congestion control that)5.5 E=0A=
(conforms to RFC2357 must be used between recei)72 465.6 Q -.165(ve)=0A=
-.275 G(rs and the sender for each LCT session.).165 E=0A=
(Congestion control refers to the ability to adapt throughput to the a)=0A=
72 478.6 Q -.275(va)-.22 G(ilable bandwidth on the path).275 E=0A=
(from the sender to a recei)72 491.6 Q -.165(ve)-.275 G .88 -.44(r, a)=0A=
.165 H(nd to share bandwidth f).44 E(airly with competing \215o)-.11 E=0A=
(ws such as TCP)-.275 E(.)-1.221 E(Thus, the total \215o)72 504.6 Q 2.75=0A=
(wo)-.275 G 2.75(fp)-2.75 G(ack)-2.75 E(ets \215o)-.11 E=0A=
(wing to each recei)-.275 E -.165(ve)-.275 G 2.75(rp).165 G=0A=
(articipating in an LCT session must not)-2.75 E(compete unf)72 517.6 Q=0A=
(airly with e)-.11 E(xisting \215o)-.165 E 2.75(wa)-.275 G(dapti)-2.75 E=0A=
.33 -.165(ve p)-.275 H(rotocols such as TCP).165 E(.)-1.221 E 2.75(Am)72=0A=
543.6 S(ulti-rate or a single-rate congestion control protcol can be us\=0A=
ed with LCT)-2.75 E 5.5(.F)-.814 G(or multi-rate)-5.665 E(protocols, a \=0A=
session typically consists of more than one channel and the sender send\=0A=
s pack)72 556.6 Q(ets to)-.11 E=0A=
(the channels in the session at rates that do not depend on the recei)72=0A=
569.6 Q -.165(ve)-.275 G 2.75(rs. Each).165 F(recei)2.75 E -.165(ve)=0A=
-.275 G 2.75(ra).165 G(djusts its)-2.75 E(reception rate during its par\=0A=
ticipation in the session by joining and lea)72 582.6 Q=0A=
(ving channels dynamically)-.22 E(depending on the a)72 595.6 Q -.275=0A=
(va)-.22 G=0A=
(ilable bandwidth to the sender independent of all other recei).275 E=0A=
-.165(ve)-.275 G 2.75(rs. Thus,).165 F(for)2.75 E=0A=
(multi-rate protocols, the reception rate of each recei)72 608.6 Q -.165=0A=
(ve)-.275 G 2.75(rm).165 G(ay v)-2.75 E=0A=
(ary dynamically independent of the)-.275 E(other recei)72 621.6 Q -.165=0A=
(ve)-.275 G(rs.).165 E -.165(Fo)72 647.6 S 2.75(rs).165 G(ingle-rate pr\=0A=
otocols, a session typically consists of one channel and the sender sen\=0A=
ds pack)-2.75 E(ets)-.11 E(to the channel at v)72 660.6 Q=0A=
(ariable rates o)-.275 E -.165(ve)-.165 G 2.75(rt).165 G=0A=
(ime depending on feedback from recei)-2.75 E -.165(ve)-.275 G=0A=
(rs. Each recei).165 E -.165(ve)-.275 G(r).165 E=0A=
(remains joined to the channel during its participation in the session.)=0A=
72 673.6 Q(Thus, for single-rate)5.5 E=0A=
(protocols, the reception rate of each recei)72 686.6 Q -.165(ve)-.275 G=0A=
2.75(rm).165 G(ay v)-2.75 E(ary dynamically b)-.275 E=0A=
(ut in coordination with all)-.22 E(recei)72 699.6 Q -.165(ve)-.275 G=0A=
2.75(rs. Generally).165 F 2.75(,am)-.715 G=0A=
(ulti-rate protocol is preferable to a single-rate protocol in a)-2.75 E=0A=
(heterogeneous recei)72 712.6 Q -.165(ve)-.275 G 2.75(re).165 G -.44(nv)=0A=
-2.75 G(ironment, b).44 E(ut only if it can be achie)-.22 E -.165(ve)=0A=
-.275 G 2.75(dw).165 G(ithout sacri\214cing scalability)-2.75 E(.)-.715=0A=
E(Some possible multi-rate congestion control protocols are described i\=0A=
n [11] and [1]. A possible)72 725.6 Q(Luby/Gemmell/V)72 769 Q=0A=
(icisano/Rizzo/Handle)-.66 E(y/Cro)-.165 E 117.356(wcroft Section)-.275=0A=
F 2.75(1. [P)2.75 F(age 3])-.165 E EP=0A=
%%Page: 4 4=0A=
%%BeginPageSetup=0A=
BP=0A=
%%EndPageSetup=0A=
/F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 77.081(-DRAFT Expires:)-1.012 F=0A=
(April 2002)2.75 E(October 2001)112.127 E=0A=
(single-rate congestion control protocol is described in [10].)72 85 Q=0A=
(Layered coding refers to the ability to produce a coded stream of pack)=0A=
72 101.6 Q(ets that can be partioned)-.11 E=0A=
(into an ordered set of layers.)72 114.6 Q(The coding is meant to pro)=0A=
5.5 E(vide some form of reliability)-.165 E 2.75(,a)-.715 G(nd the)-2.75=0A=
E(layering is meant to allo)72 127.6 Q 2.75(wt)-.275 G(he recei)-2.75 E=0A=
-.165(ve)-.275 G 2.75(re).165 G 2.75(xperience \(in)-2.915 F=0A=
(terms of quality of playout, or o)2.75 E -.165(ve)-.165 G(rall).165 E=0A=
(transfer speed\) to v)72 140.6 Q(ary in a predictable w)-.275 E=0A=
(ay depending on ho)-.11 E 2.75(wm)-.275 G(an)-2.75 E 2.75(yc)-.165 G=0A=
(onsecuti)-2.75 E .33 -.165(ve l)-.275 H(ayers of pack).165 E(ets)-.11 E=0A=
(the recei)72 153.6 Q -.165(ve)-.275 G 2.75(ri).165 G 2.75(sr)-2.75 G=0A=
(ecei)-2.75 E(ving.)-.275 E(Layered coding can be naturally combined wi\=0A=
th multi-rate congestion control.)72 179.6 Q -.165(Fo)5.5 G 2.75(re).165=0A=
G(xample, the)-2.915 E(sender could send the pack)72 192.6 Q(ets for ea\=0A=
ch layer to a separate channel associated with the session, and)-.11 E=0A=
(then recei)72 205.6 Q -.165(ve)-.275 G(rs dynamically join and lea).165=0A=
E .33 -.165(ve c)-.22 H=0A=
(hannels to adjust their reception rate according to the).165 E=0A=
(multi-rate congestion control protocol.)72 218.6 Q(Layered coding can \=0A=
also be combined with single-rate congestion control.)72 244.6 Q -.165=0A=
(Fo)5.5 G 2.75(re).165 G(xample, the)-2.915 E=0A=
(sender could dynamically v)72 257.6 Q(ary ho)-.275 E 2.75(wm)-.275 G=0A=
(an)-2.75 E 2.75(yl)-.165 G=0A=
(ayers are sent to the channel associated with the)-2.75 E=0A=
(session as the rate of transmission v)72 270.6 Q=0A=
(aries according to the single-rate congestion control protocol.)-.275 E=0A=
(The concept of layered coding w)72 296.6 Q=0A=
(as \214rst introduced with reference to audio and video streams.)-.11 E=0A=
-.165(Fo)72 309.6 S 2.75(re).165 G(xample, the information associated w\=0A=
ith a TV broadcast could be partitioned into three)-2.915 E=0A=
(layers, corresponding to black and white, color)72 322.6 Q 2.75(,a)-.44=0A=
G(nd HDTV quality)-2.75 E 2.75(.R)-.715 G(ecei)-2.75 E -.165(ve)-.275 G=0A=
(rs can e).165 E(xperience)-.165 E(dif)72 335.6 Q(ferent quality withou\=0A=
t the need for the sender to replicate information in the dif)-.275 E=0A=
(ferent layers.)-.275 E=0A=
(The concept of layered coding can be naturally e)72 361.6 Q=0A=
(xtended to reliable content deli)-.165 E -.165(ve)-.275 G(ry protocols)=0A=
.165 E(when F)72 374.6 Q(orw)-.165 E(ard Error Correction \(FEC\) techn\=0A=
iques are used for coding the data stream [9] [7] [3])-.11 E=0A=
([11] [2]. By using FEC, the data stream is transformed in such a w)72=0A=
387.6 Q(ay that reconstruction of a data)-.11 E=0A=
(object does not depend on the reception of speci\214c data pack)72=0A=
400.6 Q(ets, b)-.11 E(ut only on the number of)-.22 E(dif)72 413.6 Q=0A=
(ferent pack)-.275 E(ets recei)-.11 E -.165(ve)-.275 G 2.75(d. As).165 F=0A=
2.75(ar)2.75 G(esult, by increasing the number of layers a recei)-2.75 E=0A=
-.165(ve)-.275 G 2.75(ri).165 G 2.75(sr)-2.75 G(ecei)-2.75 E(ving)-.275=0A=
E(from, the recei)72 426.6 Q -.165(ve)-.275 G 2.75(rc).165 G=0A=
(an reduce the transfer time accordingly)-2.75 E 5.5(.M)-.715 G=0A=
(ore details on the use of FEC for)-5.5 E(reliable content deli)72 439.6=0A=
Q -.165(ve)-.275 G(ry can be found in [5].).165 E=0A=
(Reliable protocols aim at gi)5.5 E(ving guarantees on the)-.275 E=0A=
(reliable deli)72 452.6 Q -.165(ve)-.275 G=0A=
(ry of data from the sender to the intended recipients.).165 E=0A=
(Guarantees v)5.5 E(ary from simple)-.275 E(pack)72 465.6 Q=0A=
(et data inte)-.11 E(grity to reliable deli)-.165 E -.165(ve)-.275 G=0A=
(ry of a precise cop).165 E 2.75(yo)-.11 G 2.75(fa)-2.75 G 2.75(no)-2.75=0A=
G(bject to all intended recipients.)-2.75 E(Se)72 478.6 Q -.165(ve)-.275=0A=
G(ral reliable content deli).165 E -.165(ve)-.275 G(ry protocols ha).165=0A=
E .33 -.165(ve b)-.22 H(een b).165 E(uilt on top of IP multicast, b)-.22=0A=
E(ut scalability)-.22 E -.11(wa)72 491.6 S 2.75(sn).11 G=0A=
(ot a design goal for man)-2.75 E 2.75(yo)-.165 G 2.75(ft)-2.75 G(hem.)=0A=
-2.75 E -1.1 -.88(Tw o)72 517.6 T(of the k)3.63 E .33 -.165(ey d)-.11 H=0A=
(if).165 E(\214culties in scaling reliable content deli)-.275 E -.165=0A=
(ve)-.275 G(ry using IP multicast are dealing with).165 E=0A=
(the amount of data that \215o)72 530.6 Q(ws from recei)-.275 E -.165=0A=
(ve)-.275 G(rs back to the sender).165 E 2.75(,a)-.44 G=0A=
(nd the associated response)-2.75 E=0A=
(\(generally data retransmissions\) from the sender)72 543.6 Q 5.5(.P)=0A=
-.605 G(rotocols that a)-5.5 E -.22(vo)-.22 G(id an).22 E 2.75(ys)-.165=0A=
G(uch feedback, and)-2.75 E=0A=
(minimize the amount of retransmissions, can be massi)72 556.6 Q -.165=0A=
(ve)-.275 G(ly scalable.).165 E(LCT can be used in)5.5 E=0A=
(conjunction with FEC codes or a layered codec to achie)72 569.6 Q .33=0A=
-.165(ve r)-.275 H(eliability with little or no feedback.).165 E=0A=
(Scalability refers to the beha)72 595.6 Q=0A=
(vior of the protocol in relation to the number of recei)-.22 E -.165=0A=
(ve)-.275 G(rs and).165 E(netw)72 608.6 Q=0A=
(ork paths, their heterogeneity)-.11 E 2.75(,a)-.715 G=0A=
(nd the ability to accommodate dynamically v)-2.75 E(ariable sets of)=0A=
-.275 E(recei)72 621.6 Q -.165(ve)-.275 G 2.75(rs. Scalability).165 F(l\=0A=
imitations can come from memory or processing requirements, or from the)=0A=
2.75 E(amount of pack)72 634.6 Q(et traf)-.11 E=0A=
(\214c generated by the protocol.)-.275 E=0A=
(In turn, such limitations may be a)5.5 E=0A=
(consequence of the features that a complete reliable content deli)72=0A=
647.6 Q -.165(ve)-.275 G(ry or stream deli).165 E -.165(ve)-.275 G=0A=
(ry protocol).165 E(is e)72 660.6 Q(xpected to pro)-.165 E(vide.)-.165 E=0A=
(In this document we present the architecture and abstract LCT header s\=0A=
tructure, and describe its)72 686.6 Q(support for congestion control.)72=0A=
699.6 Q(The k)72 725.6 Q .33 -.165(ey w)-.11 H(ords "must", "must not",\=0A=
"required", "shall", "shall not", "should", "should not",).055 E=0A=
(Luby/Gemmell/V)72 769 Q(icisano/Rizzo/Handle)-.66 E(y/Cro)-.165 E=0A=
117.356(wcroft Section)-.275 F 2.75(1. [P)2.75 F(age 4])-.165 E EP=0A=
%%Page: 5 5=0A=
%%BeginPageSetup=0A=
BP=0A=
%%EndPageSetup=0A=
/F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 77.081(-DRAFT Expires:)-1.012 F=0A=
(April 2002)2.75 E(October 2001)112.127 E("recommended", "may", and "op\=0A=
tional" in this document are to be interpreted as described in)72 85 Q=0A=
(RFC2119.)72 98 Q/F1 11/Times-Bold@0 SF(1.1.)72 137 Q/F2 13/Times-Bold@0=0A=
SF(Related Documents)5.5 E F0(As described in RFC3048, LCT is a b)72=0A=
153.6 Q(uilding block that is intended to be used, in conjunction)-.22 E=0A=
(with other b)72 166.6 Q=0A=
(uilding blocks, to help specify a protocol instantiation.)-.22 E 2.75=0A=
(Ac)5.5 G(ongestion control b)-2.75 E(uilding)-.22 E(block that uses th\=0A=
e Congestion Control information \214eld within the LCT header must be \=0A=
used by)72 179.6 Q(an)72 192.6 Q 2.75(yp)-.165 G=0A=
(rotocol instantiation that uses LCT)-2.75 E 2.75(,a)-.814 G(nd other b)=0A=
-2.75 E(uilding blocks may also be used, such as a)-.22 E(reliability b)=0A=
72 205.6 Q(uilding block.)-.22 E 2.75(Am)72 231.6 S=0A=
(ore in-depth description of the use of FEC in Reliable Multicast T)=0A=
-2.75 E(ransport \(RMT\) protocols)-.385 E(is gi)72 244.6 Q -.165(ve)=0A=
-.275 G 2.75(ni).165 G 2.75(n[)-2.75 G(5]. Some of the FEC codecs that \=0A=
may be used in conjunction with LCT for reliable)-2.75 E(content deli)72=0A=
257.6 Q -.165(ve)-.275 G(ry are speci\214ed in [6]. The Codepoint \214e\=0A=
ld in the LCT header is an opaque \214eld that).165 E=0A=
(can be used to carry information related to the encoding of the pack)72=0A=
270.6 Q(et payload.)-.11 E(Implementors of protocol instantiations that\=0A=
use LCT must also implement congestion control in)72 296.6 Q=0A=
(accordance to RFC2357, where the congestion control is o)72 309.6 Q=0A=
-.165(ve)-.165 G 2.75(rt).165 G(he entire session.)-2.75 E=0A=
(Some possible)5.5 E(schemes are speci\214ed in [11] and [1]. The Conge\=0A=
stion Control Information \214eld in the LCT)72 322.6 Q=0A=
(header is an opaque \214eld that is reserv)72 335.6 Q=0A=
(ed to carry information related to congestion control.)-.165 E(There m\=0A=
ay also be congestion control Header Extension \214elds that carry addi\=0A=
tional information)72 348.6 Q(related to congestion control.)72 361.6 Q=0A=
(Generic Router Assist may be used in conjunction with LCT)72 387.6 Q(.)=0A=
-.814 E(It is recommended that LCT implementors use some pack)72 413.6 Q=0A=
(et authentication scheme to protect the)-.11 E=0A=
(protocol from attacks. An e)72 426.6 Q=0A=
(xample of a possibly suitable scheme is described in [8].)-.165 E F1=0A=
(1.2.)72 452.6 Q F2(En)5.5 E(vir)-.52 E(onmental Requir)-.234 E=0A=
(ements and Considerations)-.234 E F0=0A=
(LCT is intended for congestion controlled deli)72 469.2 Q -.165(ve)=0A=
-.275 G(ry of objects and streams \(both reliable content).165 E(deli)72=0A=
482.2 Q -.165(ve)-.275 G(ry and streaming of multimedia information\).)=0A=
.165 E(LCT is most applicable for deli)72 508.2 Q -.165(ve)-.275 G=0A=
(ry of objects or streams of substantial length, i.e., objects or).165 E=0A=
(streams that range in length from hundreds of kilobytes to man)72 521.2=0A=
Q 2.75(yg)-.165 G(ig)-2.75 E(abytes, and whose transfer)-.055 E=0A=
(time is in the order of tens of seconds or more.)72 534.2 Q=0A=
(LCT can be used with both multicast and unicast deli)72 560.2 Q -.165=0A=
(ve)-.275 G(ry).165 E 5.5(.L)-.715 G(CT requires connecti)-5.5 E=0A=
(vity between a)-.275 E(sender and recei)72 573.2 Q -.165(ve)-.275 G=0A=
(rs, b).165 E(ut does not require connecti)-.22 E(vity from recei)-.275=0A=
E -.165(ve)-.275 G(rs to a sender).165 E 5.5(.L)-.605 G(CT inherently)=0A=
-5.5 E -.11(wo)72 586.2 S(rks with all types of netw).11 E=0A=
(orks, including LANs, W)-.11 E=0A=
(ANs, Intranets, the Internet, asymmetric)-1.32 E(netw)72 599.2 Q=0A=
(orks, wireless netw)-.11 E(orks, and satellite netw)-.11 E 2.75=0A=
(orks. Thus,)-.11 F(the inherent ra)2.75 E 2.75(ws)-.165 G=0A=
(calability of LCT is)-2.75 E 2.75(unlimited. Ho)72 612.2 R(we)-.275 E=0A=
-.165(ve)-.275 G .88 -.44(r, w).165 H=0A=
(hen other speci\214c applications are b).44 E(uilt on top of LCT)-.22 E=0A=
2.75(,t)-.814 G(hen these)-2.75 E(applications by their v)72 625.2 Q=0A=
(ery nature may limit scalability)-.165 E 5.5(.F)-.715 G(or e)-5.665 E=0A=
(xample, if an application requires)-.165 E(recei)72 638.2 Q -.165(ve)=0A=
-.275 G(rs to retrie).165 E .33 -.165(ve o)-.275 H(ut of band informati\=0A=
on in order to join a session, or an application allo).165 E(ws)-.275 E=0A=
(recei)72 651.2 Q -.165(ve)-.275 G(rs to send requests back to the send\=0A=
er to report reception statistics, then the scalability of).165 E=0A=
(the application is limited by the ability to send, recei)72 664.2 Q=0A=
-.165(ve)-.275 G 2.75(,a).165 G(nd process this additional data.)-2.75 E=0A=
(LCT requires recei)72 690.2 Q -.165(ve)-.275 G=0A=
(rs to be able to uniquely identify and demultiple).165 E 2.75(xp)-.165=0A=
G(ack)-2.75 E(ets associated with an)-.11 E(LCT session.)72 703.2 Q=0A=
(In particular)5.5 E 2.75(,t)-.44 G(here must be a T)-2.75 E=0A=
(ransport Session Identi\214er \(TSI\) associated with)-.385 E=0A=
(each LCT session.)72 716.2 Q=0A=
(The TSI is scoped by the IP address of the sender)5.5 E 2.75(,a)-.44 G=0A=
(nd the IP address of the)-2.75 E(Luby/Gemmell/V)72 769 Q=0A=
(icisano/Rizzo/Handle)-.66 E(y/Cro)-.165 E 109.106(wcroft Section)-.275=0A=
F 2.75(1.2. [P)2.75 F(age 5])-.165 E EP=0A=
%%Page: 6 6=0A=
%%BeginPageSetup=0A=
BP=0A=
%%EndPageSetup=0A=
/F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 77.081(-DRAFT Expires:)-1.012 F=0A=
(April 2002)2.75 E(October 2001)112.127 E=0A=
(sender together with the TSI must uniquely identify the session.)72 85=0A=
Q(If the underlying transport is)5.5 E(UDP as described in RFC768, then\=0A=
the 16 bit UDP source port number may serv)72 98 Q 2.75(ea)-.165 G 2.75=0A=
(st)-2.75 G(he TSI for)-2.75 E(the session.)72 111 Q(If Generic Router \=0A=
Assist \(GRA\) is being used then additional dependencies may be)5.5 E=0A=
(introduced by GRA on the TSI \214eld.)72 124 Q(GRA w)5.5 E=0A=
(ork is ongoing within the RMT w)-.11 E(orking group at)-.11 E=0A=
(this time.)72 137 Q(The TSI v)5.5 E=0A=
(alue must be the same in all places it occurs within a pack)-.275 E=0A=
2.75(et. If)-.11 F(there is no)2.75 E(underlying TSI pro)72 150 Q=0A=
(vided by the netw)-.165 E(ork, transport or an)-.11 E 2.75(yo)-.165 G=0A=
(ther layer)-2.75 E 2.75(,t)-.44 G(hen the TSI must be)-2.75 E=0A=
(included in the LCT header)72 163 Q(.)-.605 E(There are currently tw)72=0A=
189 Q 2.75(om)-.11 G(odels of multicast deli)-2.75 E -.165(ve)-.275 G=0A=
(ry).165 E 2.75(,t)-.715 G(he An)-2.75 E=0A=
(y-Source Multicast \(ASM\) model as)-.165 E(de\214ned in RFC1112 and t\=0A=
he Source-Speci\214c Multicast \(SSM\) model as de\214ned in [4]. LCT)72=0A=
202 Q -.11(wo)72 215 S(rks with both multicast models, b).11 E=0A=
(ut in a slightly dif)-.22 E(ferent w)-.275 E(ay with some)-.11 E=0A=
(what dif)-.275 E(ferent)-.275 E(en)72 228 Q(vironmental concerns.)-.44=0A=
E(When using ASM, a sender S sends pack)5.5 E=0A=
(ets to a multicast group G, and)-.11 E(the LCT channel address consist\=0A=
s of the pair \(S,G\), where S is the IP address of the sender and G)72=0A=
241 Q(is a multicast group address.)72 254 Q=0A=
(When using SSM, a sender S sends pack)5.5 E(ets to an SSM channel)-.11=0A=
E(\(S,G\), and the LCT channel address coincides with the SSM channel a\=0A=
ddress.)72 267 Q 2.75(As)72 293 S=0A=
(ender can locally allocate unique SSM channel addresses, and this mak)=0A=
-2.75 E(es allocation of LCT)-.11 E(channel addresses easy with SSM.)72=0A=
306 Q 1.76 -.88(To a)5.5 H=0A=
(llocate LCT channel addresses using ASM, the sender).88 E(must uniquel\=0A=
y chose the ASM multicast group address across the scope of the group, \=0A=
and this)72 319 Q(mak)72 332 Q=0A=
(es allocation of LCT channel addresses more dif)-.11 E=0A=
(\214cult with ASM.)-.275 E=0A=
(LCT channels and SSM channels coincide, and thus the recei)72 358 Q=0A=
-.165(ve)-.275 G 2.75(rw).165 G(ill only recei)-2.75 E .33 -.165(ve p)=0A=
-.275 H(ack).165 E(ets sent to)-.11 E(the requested LCT channel.)72 371=0A=
Q -.44(Wi)5.5 G(th ASM, the recei).44 E -.165(ve)-.275 G 2.75(rj).165 G=0A=
(oins an LCT channel by joining a multicast)-2.75 E=0A=
(group G, and all pack)72 384 Q(ets sent to G, re)-.11 E -.055(ga)-.165=0A=
G(rdless of the sender).055 E 2.75(,m)-.44 G(ay be recei)-2.75 E -.165=0A=
(ve)-.275 G 2.75(db).165 G 2.75(yt)-2.75 G(he recei)-2.75 E -.165(ve)=0A=
-.275 G -.605(r.).165 G(Thus, SSM has compelling security adv)72 397 Q=0A=
(antages o)-.275 E -.165(ve)-.165 G 2.75(rA).165 G(SM for pre)-2.75 E=0A=
-.165(ve)-.275 G(ntion of denial of service).165 E 2.75(attacks. In)72=0A=
410 R(either case, recei)2.75 E -.165(ve)-.275 G=0A=
(rs should use mechanisms to \214lter out pack).165 E(ets from unw)-.11=0A=
E(anted)-.11 E(sources.)72 423 Q(LCT also requires recei)72 449 Q -.165=0A=
(ve)-.275 G=0A=
(rs to obtain Session Description Information, as described in Section)=0A=
.165 E(4.1. The session description could be in a form such as SDP as d\=0A=
e\214ned in RFC2327, or XML)72 462 Q=0A=
(metadata, or HTTP/Mime headers as de\214ned in RFC2068, and distrib)72=0A=
475 Q(uted with SAP as de\214ned in)-.22 E(RFC2974, using HTTP)72 488 Q=0A=
2.75(,o)-1.221 G 2.75(ri)-2.75 G 2.75(no)-2.75 G(ther w)-2.75 E(ays.)=0A=
-.11 E(The particular layered encoder and congestion control protocols \=0A=
used with LCT ha)72 514 Q .33 -.165(ve a)-.22 H 2.75(ni).165 G(mpact)=0A=
-2.75 E(on the performance and applicability of LCT)72 527 Q 5.5(.F)=0A=
-.814 G(or e)-5.665 E(xample, some layered encoders used for video)-.165=0A=
E(and audio streams can produce a v)72 540 Q=0A=
(ery limited number of layers, thus pro)-.165 E(viding a v)-.165 E=0A=
(ery coarse)-.165 E(control in the reception rate of pack)72 553 Q=0A=
(ets by recei)-.11 E -.165(ve)-.275 G(rs in a session.).165 E=0A=
(When LCT is used for reliable)5.5 E(data transfer)72 566 Q 2.75(,s)-.44=0A=
G(ome FEC codecs are inherently limited in the size of the object the)=0A=
-2.75 E 2.75(yc)-.165 G(an encode,)-2.75 E(and for objects lar)72 579 Q=0A=
(ger than this size the reception o)-.198 E -.165(ve)-.165 G=0A=
(rhead on the recei).165 E -.165(ve)-.275 G(rs can gro).165 E 2.75(ws)=0A=
-.275 G(ubstantially)-2.75 E(.)-.715 E(Some netw)72 605 Q(orks are not \=0A=
amenable to some congestion control protocols that could be used with)=0A=
-.11 E(LCT)72 618 Q 5.5(.I)-.814 G 2.75(np)-5.5 G(articular)-2.75 E 2.75=0A=
(,f)-.44 G(or a satellite or wireless netw)-2.75 E=0A=
(ork, there may be no mechanism for recei)-.11 E -.165(ve)-.275 G(rs to)=0A=
.165 E(ef)72 631 Q(fecti)-.275 E -.165(ve)-.275 G=0A=
(ly reduce their reception rate since there may be a \214x).165 E=0A=
(ed transmission rate allocated to the)-.165 E(session.)72 644 Q(Some p\=0A=
rotocol instantiations that use LCT may require the generation of feedb\=0A=
ack from the)72 670 Q(recei)72 683 Q -.165(ve)-.275 G(rs to the sender)=0A=
.165 E 5.5(.F)-.605 G(or e)-5.665 E=0A=
(xample, Generic Router Assist may be used to help in passing real-)=0A=
-.165 E(time statistics in a scalable manner from recei)72 696 Q -.165=0A=
(ve)-.275 G(rs back to the sender).165 E 2.75(.H)-.605 G -.275(ow)-2.75=0A=
G -2.365 -.275(ev e).275 H .88 -.44(r, t).275 H(he mechanism).44 E=0A=
(for doing this is outside the scope of LCT)72 709 Q(.)-.814 E=0A=
(Luby/Gemmell/V)72 769 Q(icisano/Rizzo/Handle)-.66 E(y/Cro)-.165 E=0A=
109.106(wcroft Section)-.275 F 2.75(1.2. [P)2.75 F(age 6])-.165 E EP=0A=
%%Page: 7 7=0A=
%%BeginPageSetup=0A=
BP=0A=
%%EndPageSetup=0A=
/F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 77.081(-DRAFT Expires:)-1.012 F=0A=
(April 2002)2.75 E(October 2001)112.127 E/F1 11/Times-Bold@0 SF(2.)72 85=0A=
Q/F2 14/Times-Bold@0 SF(General Ar)5.5 E(chitectur)-.252 E(e)-.252 E F0=0A=
(An LCT session comprises a logically related set of one or more LCT ch\=0A=
annels originating at a)72 101.6 Q=0A=
(single sender that are used for some period of time to carry pack)72=0A=
114.6 Q(ets containing LCT headers)-.11 E(pertaining to the transmissio\=0A=
n of one or more objects that can be of interest to recei)72 127.6 Q=0A=
-.165(ve)-.275 G(rs.).165 E -.165(Fo)72 153.6 S 2.75(re).165 G=0A=
(xample, an LCT session could be used to deli)-2.915 E -.165(ve)-.275 G=0A=
2.75(raT).165 G 2.75(Vp)-2.75 G(rogram using three LCT channels.)-2.75 E=0A=
(Recei)72 166.6 Q(ving pack)-.275 E=0A=
(ets from the \214rst LCT channel could allo)-.11 E 2.75(wb)-.275 G=0A=
(lack and white reception, recei)-2.75 E(ving)-.275 E(the \214rst tw)72=0A=
179.6 Q 2.75(oL)-.11 G=0A=
(CT channels could also permit color reception, whereas recei)-2.75 E=0A=
(ving all three channels)-.275 E(could allo)72 192.6 Q 2.75(wH)-.275 G=0A=
(DTV quality reception.)-2.75 E(Objects in this e)5.5 E=0A=
(xample could correspond to indi)-.165 E(vidual TV)-.275 E=0A=
(programs being transmitted.)72 205.6 Q(As another e)72 231.6 Q=0A=
(xample, a reliable LCT session could be used to reliably deli)-.165 E=0A=
-.165(ve)-.275 G 2.75(rh).165 G(ourly-updated)-2.75 E=0A=
(weather maps \(objects\) using ten LCT channels at dif)72 244.6 Q=0A=
(ferent rates, using FEC coding.)-.275 E 2.75(Ar)5.5 G(ecei)-2.75 E=0A=
-.165(ve)-.275 G(r).165 E(may join and concurrently recei)72 257.6 Q .33=0A=
-.165(ve p)-.275 H(ack).165 E=0A=
(ets from subsets of these channels, until it has enough)-.11 E(pack)72=0A=
270.6 Q(ets in total to reco)-.11 E -.165(ve)-.165 G 2.75(rt).165 G=0A=
(he object, then lea)-2.75 E .33 -.165(ve t)-.22 H=0A=
(he session \(or remain connected listening for).165 E=0A=
(session description information only\) until it is time to recei)72=0A=
283.6 Q .33 -.165(ve t)-.275 H(he ne).165 E(xt object.)-.165 E=0A=
(In this case, the)5.5 E(quality metric is the time required to recei)72=0A=
296.6 Q .33 -.165(ve e)-.275 H(ach object.).165 E=0A=
(Before joining a session, the recei)72 322.6 Q -.165(ve)-.275 G=0A=
(rs must obtain enough of the session description to start the).165 E=0A=
2.75(session. This)72 335.6 R(must include the rele)2.75 E -.275(va)=0A=
-.275 G(nt session parameters needed by a recei).275 E -.165(ve)-.275 G=0A=
2.75(rt).165 G 2.75(op)-2.75 G(articipate in)-2.75 E=0A=
(the session, including all information rele)72 348.6 Q -.275(va)-.275 G=0A=
(nt to congestion control.).275 E(The session description is)5.5 E=0A=
(determined by the sender)72 361.6 Q 2.75(,a)-.44 G=0A=
(nd is typically communicated to the recei)-2.75 E -.165(ve)-.275 G=0A=
(rs out of band. In some).165 E(cases, as described later)72 374.6 Q=0A=
2.75(,p)-.44 G(arts of the session description that are not required to\=0A=
initiate a session)-2.75 E=0A=
(may be included in the LCT header or communicated to a recei)72 387.6 Q=0A=
-.165(ve)-.275 G 2.75(ro).165 G(ut of band after the recei)-2.75 E -.165=0A=
(ve)-.275 G(r).165 E(has joined the session.)72 400.6 Q=0A=
(An encoder may be used to generate the data that is placed in the pack)=0A=
72 426.6 Q(et payload in order to)-.11 E(pro)72 439.6 Q=0A=
(vide reliability)-.165 E 5.5(.A)-.715 G(suitable decoder is used to re\=0A=
produce the original information from the)-2.75 E(pack)72 452.6 Q=0A=
(et payload.)-.11 E(There may be a reliability header that follo)5.5 E=0A=
(ws the LCT header if such an encoder)-.275 E(and decoder is used.)72=0A=
465.6 Q(The reliability header helps to describe the encoding data carr\=0A=
ied in the)5.5 E(payload of the pack)72 478.6 Q 2.75(et. The)-.11 F(for\=0A=
mat of the reliability header depends on the coding used, and this is)=0A=
2.75 E(ne)72 491.6 Q(gotiated out-of-band.)-.165 E(As an e)5.5 E=0A=
(xample, one of the FEC headers described in [6] could be used.)-.165 E=0A=
-.165(Fo)72 517.6 S 2.75(rL).165 G(CT)-2.75 E 2.75(,w)-.814 G=0A=
(hen multi-rate congestion control is used, congestion control is achie)=0A=
-2.75 E -.165(ve)-.275 G 2.75(db).165 G 2.75(ys)-2.75 G(ending)-2.75 E=0A=
(pack)72 530.6 Q(ets associated with a gi)-.11 E -.165(ve)-.275 G 2.75=0A=
(ns).165 G(ession to se)-2.75 E -.165(ve)-.275 G(ral LCT channels.).165=0A=
E(Indi)5.5 E(vidual recei)-.275 E -.165(ve)-.275 G(rs).165 E=0A=
(dynamically join one or more of these channels, according to the netw)=0A=
72 543.6 Q(ork congestion as seen by)-.11 E(the recei)72 556.6 Q -.165=0A=
(ve)-.275 G 3.96 -.605(r. L).165 H=0A=
(CT headers include an opaque \214eld which must be used to con).605 E=0A=
.33 -.165(vey c)-.44 H(ongestion).165 E=0A=
(control information to the recei)72 569.6 Q -.165(ve)-.275 G 2.75=0A=
(rs. The).165 F(actual congestion control scheme to use with LCT is)2.75=0A=
E(ne)72 582.6 Q(gotiated out-of-band.)-.165 E(Some e)5.5 E=0A=
(xamples of congestion control protocols that may be suitable for)-.165=0A=
E(content deli)72 595.6 Q -.165(ve)-.275 G(ry are described in [11] and\=0A=
[1]. Other congestion controls may be suitable when).165 E=0A=
(LCT is used for a streaming application.)72 608.6 Q(LCT can be used wi\=0A=
th other congestion control protocols such as the one described in [11]\=0A=
, or)72 634.6 Q=0A=
(Generic Router Assist schemes where the selection of which pack)72=0A=
647.6 Q(ets to forw)-.11 E(ard is performed by)-.11 E=0A=
(routers. This latter approach potentially allo)72 660.6 Q=0A=
(ws for \214ner grain congestion control and a f)-.275 E(aster)-.11 E=0A=
(reaction to netw)72 673.6 Q(ork congestion, b)-.11 E=0A=
(ut requires changes to the router infrastructure.)-.22 E 1.76 -.88=0A=
(We d)5.5 H 2.75(on).88 G(ot)-2.75 E=0A=
(discuss this approach further in this document.)72 686.6 Q=0A=
(Luby/Gemmell/V)72 769 Q(icisano/Rizzo/Handle)-.66 E(y/Cro)-.165 E=0A=
117.356(wcroft Section)-.275 F 2.75(2. [P)2.75 F(age 7])-.165 E EP=0A=
%%Page: 8 8=0A=
%%BeginPageSetup=0A=
BP=0A=
%%EndPageSetup=0A=
/F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 77.081(-DRAFT Expires:)-1.012 F=0A=
(April 2002)2.75 E(October 2001)112.127 E/F1 11/Times-Bold@0 SF(2.1.)72=0A=
85 Q/F2 13/Times-Bold@0 SF(Deli)5.5 E -.13(ve)-.13 G(ry ser).13 E=0A=
(vice models)-.13 E F0(LCT can support se)72 101.6 Q -.165(ve)-.275 G=0A=
(ral dif).165 E(ferent deli)-.275 E -.165(ve)-.275 G=0A=
(ry service models. T).165 E .22 -.11(wo e)-.88 H=0A=
(xamples are brie\215y described)-.055 E(here.)72 114.6 Q F1(Push ser)72=0A=
153.6 Q(vice model.)-.11 E F0(One w)72 170.2 Q=0A=
(ay a push service model can be used for reliable content deli)-.11 E=0A=
-.165(ve)-.275 G(ry is to deli).165 E -.165(ve)-.275 G 2.75(ras).165 G=0A=
(eries of)-2.75 E 2.75(objects. F)72 183.2 R(or e)-.165 E=0A=
(xample, a recei)-.165 E -.165(ve)-.275 G 2.75(rc).165 G=0A=
(ould join the session and dynamically adapt the number of LCT)-2.75 E=0A=
(channels the recei)72 196.2 Q -.165(ve)-.275 G 2.75(ri).165 G 2.75(sj)=0A=
-2.75 G(oined to until enough pack)-2.75 E(ets ha)-.11 E .33 -.165(ve b)=0A=
-.22 H(een recei).165 E -.165(ve)-.275 G 2.75(dt).165 G 2.75(or)-2.75 G=0A=
(econstruct an)-2.75 E=0A=
(object. After reconstructing the object the recei)72 209.2 Q -.165(ve)=0A=
-.275 G 2.75(rm).165 G(ay stay in the session and w)-2.75 E(ait for the)=0A=
-.11 E(transmission of the ne)72 222.2 Q(xt object.)-.165 E=0A=
(The push model is particularly attracti)72 248.2 Q .33 -.165(ve i)-.275=0A=
H 2.75(ns).165 G(atellite netw)-2.75 E(orks and wireless netw)-.11 E=0A=
2.75(orks. In)-.11 F(these)2.75 E=0A=
(cases, a session may consist of one \214x)72 261.2 Q=0A=
(ed rate LCT channel.)-.165 E F1(On-demand content deli)72 300.2 Q -.11=0A=
(ve)-.11 G(ry model.).11 E F0 -.165(Fo)72 316.8 S 2.75(ra).165 G 2.75=0A=
(no)-2.75 G(n-demand content deli)-2.75 E -.165(ve)-.275 G=0A=
(ry service model, senders typically transmit for some gi).165 E -.165=0A=
(ve)-.275 G 2.75(nt).165 G(ime)-2.75 E=0A=
(period selected to be long enough to allo)72 329.8 Q 2.75(wa)-.275 G=0A=
(ll the intended recei)-2.75 E -.165(ve)-.275 G=0A=
(rs to join the session and).165 E(reco)72 342.8 Q -.165(ve)-.165 G 2.75=0A=
(rt).165 G(he object.)-2.75 E -.165(Fo)5.5 G 2.75(re).165 G=0A=
(xample a popular softw)-2.915 E=0A=
(are update might be transmitted using LCT for)-.11 E(se)72 355.8 Q=0A=
-.165(ve)-.275 G(ral days, e).165 E -.165(ve)-.275 G 2.75(nt).165 G=0A=
(hough a recei)-2.75 E -.165(ve)-.275 G 2.75(rm).165 G=0A=
(ay be able to complete the do)-2.75 E(wnload in one hour total of)-.275=0A=
E(connection time, perhaps spread o)72 368.8 Q -.165(ve)-.165 G 2.75(rs)=0A=
.165 G -2.365 -.275(ev e)-2.75 H(ral interv).275 E(als of time.)-.275 E=0A=
(In this case the recei)72 394.8 Q -.165(ve)-.275 G=0A=
(rs join the session, and dynamically adapt the number of LCT channels)=0A=
.165 E(the)72 407.8 Q 2.75(ys)-.165 G=0A=
(ubscribe to \(and the reception quality\) according to the a)-2.75 E=0A=
-.275(va)-.22 G(ilable bandwidth. Recei).275 E -.165(ve)-.275 G(rs then)=0A=
.165 E(drop from the session when the)72 420.8 Q 2.75(yh)-.165 G -2.475=0A=
-.22(av e)-2.75 H(recei)2.97 E -.165(ve)-.275 G 2.75(de).165 G=0A=
(nough pack)-2.75 E(ets to reco)-.11 E -.165(ve)-.165 G 2.75(rt).165 G=0A=
(he object.)-2.75 E(As an e)72 446.8 Q=0A=
(xample, assume that an object is 50 MB.)-.165 E=0A=
(The sender could send 1 KB pack)5.5 E(ets to the \214rst)-.11 E=0A=
(LCT channel at 50 pack)72 459.8 Q(ets per second, so that recei)-.11 E=0A=
-.165(ve)-.275 G(rs using just this LCT channel could).165 E(complete r\=0A=
eception of the object in 1,000 seconds in absence of loss, and w)72=0A=
472.8 Q(ould be able to)-.11 E(complete reception e)72 485.8 Q -.165(ve)=0A=
-.275 G 2.75(ni).165 G 2.75(np)-2.75 G=0A=
(resence of some substantial amount of losses with the use of coding)=0A=
-2.75 E(for reliability)72 498.8 Q 5.5(.F)-.715 G(urthermore, the sende\=0A=
r could use a number of LCT channels such that the)-5.5 E(aggre)72 511.8=0A=
Q -.055(ga)-.165 G(te rate of 1 KB pack).055 E=0A=
(ets to all LCT channels is 1,000 pack)-.11 E=0A=
(ets per second, so that a recei)-.11 E -.165(ve)-.275 G(r).165 E(could\=0A=
be able to complete reception of the object in as little 50 seconds \(\=0A=
assuming no loss and that)72 524.8 Q=0A=
(the congestion control mechanism immediately con)72 537.8 Q -.165(ve)=0A=
-.44 G -.198(rg).165 G(es to the use of all LCT channels\).).198 E F1=0A=
(Other ser)72 576.8 Q(vice models.)-.11 E F0(There are man)72 606.4 Q=0A=
2.75(yo)-.165 G(ther deli)-2.75 E -.165(ve)-.275 G=0A=
(ry service models that LCT can be used for that are not co).165 E -.165=0A=
(ve)-.165 G(red).165 E(abo)72 619.4 Q -.165(ve)-.165 G 5.5(.A).165 G=0A=
2.75(se)-5.5 G(xamples, a li)-2.915 E .33 -.165(ve s)-.275 H=0A=
(treaming or an on-demand archi).165 E -.275(va)-.275 G 2.75(lc).275 G=0A=
(ontent streaming service model.)-2.75 E(The description of the man)72=0A=
632.4 Q 2.75(yp)-.165 G(otential applications, the appropriate deli)=0A=
-2.75 E -.165(ve)-.275 G(ry service model, and).165 E(the additional me\=0A=
chanisms to support such functionalities when combined with LCT is be)72=0A=
645.4 Q(yond)-.165 E(the scope of this document.)72 658.4 Q=0A=
(This document only attempts to describe the minimal common)5.5 E=0A=
(scalable elements to these di)72 671.4 Q -.165(ve)-.275 G=0A=
(rse applications using LCT as the deli).165 E -.165(ve)-.275 G=0A=
(ry transport.).165 E(Luby/Gemmell/V)72 769 Q(icisano/Rizzo/Handle)-.66=0A=
E(y/Cro)-.165 E 109.106(wcroft Section)-.275 F 2.75(2.1. [P)2.75 F=0A=
(age 8])-.165 E EP=0A=
%%Page: 9 9=0A=
%%BeginPageSetup=0A=
BP=0A=
%%EndPageSetup=0A=
/F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 77.081(-DRAFT Expires:)-1.012 F=0A=
(April 2002)2.75 E(October 2001)112.127 E/F1 11/Times-Bold@0 SF(2.2.)72=0A=
85 Q/F2 13/Times-Bold@0 SF(Congestion Contr)5.5 E(ol)-.234 E F0(The spe\=0A=
ci\214c congestion control protocol to be used for LCT sessions depends\=0A=
on the type of)72 101.6 Q(content to be deli)72 114.6 Q -.165(ve)-.275=0A=
G(red. While the general beha).165 E=0A=
(vior of the congestion control protocol is to reduce)-.22 E(the throug\=0A=
hput in presence of congestion and gradually increase it in the absence\=0A=
of congestion,)72 127.6 Q(the actual dynamic beha)72 140.6 Q=0A=
(vior \(e.g. response to single losses\) can v)-.22 E(ary)-.275 E(.)=0A=
-.715 E=0A=
(Some possible congestion control protocols for reliable content deli)72=0A=
166.6 Q -.165(ve)-.275 G(ry using LCT are described).165 E=0A=
(in [11] and [1]. Dif)72 179.6 Q(ferent deli)-.275 E -.165(ve)-.275 G=0A=
(ry service models might require dif).165 E(ferent congestion control)=0A=
-.275 E(protocols.)72 192.6 Q F1(3.)72 231.6 Q/F3 14/Times-Bold@0 SF=0A=
(LCT header)5.5 E F0 -.165(Pa)72 248.2 S(ck).165 E=0A=
(ets sent to an LCT session must include an "LCT header".)-.11 E=0A=
(The LCT header format described)5.5 E(belo)72 261.2 Q 2.75(wi)-.275 G=0A=
2.75(st)-2.75 G(he def)-2.75 E(ault format, and this is the format that\=0A=
is recommended for use by protocol)-.11 E=0A=
(instantiations to ensure a uniform format across dif)72 274.2 Q=0A=
(ferent protocol instantiations.)-.275 E(Other LCT)5.5 E=0A=
(header formats may be used by protocol instantiations, b)72 287.2 Q=0A=
(ut if the def)-.22 E(ault LCT header format is not)-.11 E=0A=
(used by a protocol insantiation that uses LCT)72 300.2 Q 2.75(,t)-.814=0A=
G(hen the protocol instantiation must specify the)-2.75 E(lengths and p\=0A=
ositions within the LCT header it uses of all \214elds described in the\=0A=
def)72 313.2 Q(ault LCT)-.11 E(header)72 326.2 Q(.)-.605 E(Other b)72=0A=
352.2 Q(uilding blocks may describe some of the same \214elds as descri\=0A=
bed for the LCT header)-.22 E 5.5(.I)-.605 G 2.75(ti)-5.5 G(s)-2.75 E=0A=
(recommended that protocol instantiations using multiple b)72 365.2 Q=0A=
(uilding blocks include shared \214elds at)-.22 E=0A=
(most once in each pack)72 378.2 Q 2.75(et. Thus,)-.11 F(for e)2.75 E=0A=
(xample, if another b)-.165 E(uilding block is used with LCT that)-.22 E=0A=
(includes the optional Expected Residual T)72 391.2 Q=0A=
(ime \214eld, then the Expected Residual T)-.385 E(ime \214eld should)=0A=
-.385 E(be carried in each pack)72 404.2 Q(et at most once.)-.11 E=0A=
(The position of the LCT header within a pack)72 430.2 Q=0A=
(et must be speci\214ed by an)-.11 E 2.75(yp)-.165 G=0A=
(rotocol instantiation)-2.75 E(that uses LCT)72 443.2 Q(.)-.814 E F1=0A=
(3.1.)72 482.2 Q F2(Default LCT header f)5.5 E(ormat)-.325 E F0(The def)=0A=
72 498.8 Q(ault LCT header is of v)-.11 E(ariable size, which is speci\=0A=
\214ed by a length \214eld in the third byte of)-.275 E(the header)72=0A=
511.8 Q 5.5(.I)-.605 G 2.75(nt)-5.5 G(he LCT header)-2.75 E 2.75(,a)-.44=0A=
G(ll inte)-2.75 E(ger \214elds are carried in "big-endian" or "netw)=0A=
-.165 E(ork order")-.11 E=0A=
(format, that is, most signi\214cant byte \(octet\) \214rst.)72 524.8 Q=0A=
(Bits designated as "padding" or "reserv)5.5 E(ed" \(r\))-.165 E=0A=
(must by set to 0 by senders and ignored by recei)72 537.8 Q -.165(ve)=0A=
-.275 G 2.75(rs. Unless).165 F(otherwise noted, numeric constants)2.75 E=0A=
(in this speci\214cation are in decimal \(base 10\).)72 550.8 Q=0A=
(The format of the def)72 576.8 Q=0A=
(ault LCT header is depicted in Figure 1.)-.11 E(Luby/Gemmell/V)72 769 Q=0A=
(icisano/Rizzo/Handle)-.66 E(y/Cro)-.165 E 109.106(wcroft Section)-.275=0A=
F 2.75(3.1. [P)2.75 F(age 9])-.165 E EP=0A=
%%Page: 10 10=0A=
%%BeginPageSetup=0A=
BP=0A=
%%EndPageSetup=0A=
/F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 77.081(-DRAFT Expires:)-1.012 F=0A=
(April 2002)2.75 E(October 2001)112.127 E/F1 8/Courier@0 SF 91.2(0123)=0A=
81.6 85 S 4.8(01234567890123456789012345678901)81.6 98 S=0A=
(+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+)76.8=0A=
111 Q 14.4(|V|)76.8 124 S 4.8(C| r |H|S|)-14.4 F 4.8(O|)4.8 G 9.6=0A=
(T|R|A|B| HDR_LEN)-4.8 F 4.8(|C)24 G(odepoint \(CP\)|)-4.8 E=0A=
(+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+)76.8=0A=
137 Q 62.4(|C)76.8 150 S(ongestion Control Information \(CCI\))-62.4 E=0A=
(|)67.2 E=0A=
(+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+)76.8=0A=
163 Q 91.2(|C)76.8 176 S(CI continued \(if C =3D 1\))-91.2 E(|)96 E=0A=
(+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+)76.8=0A=
189 Q 9.6(|T)76.8 202 S=0A=
(ransport Session Identifier \(TSI, length =3D 32*S+16*H bits\))-9.6 E(|)=0A=
9.6 E 124.8(|.)76.8 215 S 158.4(.. |)-124.8 F 302.4(++)76.8 228 S 14.4=0A=
(|T)76.8 241 S=0A=
(ransport Object Identifier \(TOI, length =3D 32*O+16*H bits\))-14.4 E(|)=0A=
9.6 E 124.8(|.)76.8 254 S 158.4(.. |)-124.8 F=0A=
(+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+)76.8=0A=
267 Q 72(|S)76.8 280 S(ender Current Time \(SCT, if T =3D 1\))-72 =
E(|)62.4=0A=
E(+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+)76.8=0A=
293 Q 67.2(|E)76.8 306 S(xpected Residual Time \(ERT, if R =3D 1\))-67.2 =
E=0A=
(|)52.8 E=0A=
(+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+)76.8=0A=
319 Q 76.8(|H)76.8 332 S(eader Extensions \(if applicable\))-76.8 E(|)=0A=
67.2 E 302.4(||)76.8 345 S=0A=
(+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+)76.8=0A=
358 Q/F2 10/Times-Roman@0 SF(Figure 1 - Def)72 397 Q=0A=
(ault LCT header format)-.1 E F0=0A=
(The function and length of each \214eld in the def)72 426.6 Q=0A=
(ault LCT header is the follo)-.11 E 2.75(wing. Fields)-.275 F(mark)2.75=0A=
E(ed)-.11 E(as "1" mean that the corresponding bits must be set to "1" \=0A=
by the sender)72 439.6 Q 5.5(.F)-.605 G(ields mark)-5.5 E(ed as "r" or)=0A=
-.11 E=0A=
("0" mean that the corresponding bits must be set to "0" by the sender)=0A=
72 452.6 Q(.)-.605 E(LCT v)83 482.2 Q(ersion number \(V\): 4 bits)-.165=0A=
E(Indicates the LCT v)105 498.8 Q(ersion number)-.165 E 5.5(.T)-.605 G=0A=
(he LCT v)-5.5 E(ersion number for this speci\214cation is 0.)-.165 E=0A=
(Congestion control \215ag \(C\): 1 bit)83 528.4 Q(C=3D0 indicates the =
Co\=0A=
ngestion Control Information \(CCI\) \214eld is 32-bits in length.)105=0A=
545 Q(C=3D1 indicates the CCI \214eld is 64-bits in length.)105 558 Q=0A=
(Reserv)83 587.6 Q(ed \(r\): 3 bits)-.165 E(Reserv)105 604.2 Q=0A=
(ed for future use. A sender must set these bits to zero and a recei)=0A=
-.165 E -.165(ve)-.275 G 2.75(rm).165 G(ust ignore)-2.75 E(these bits.)=0A=
105 617.2 Q(Half-w)83 646.8 Q(ord \215ag \(H\): 1 bit)-.11 E=0A=
(The TSI and the T)105 663.4 Q=0A=
(OI \214elds are both multiples of 32-bits plus 16*H bits in length.)=0A=
-.198 E(This)5.5 E(allo)105 676.4 Q(ws the TSI and T)-.275 E=0A=
(OI \214eld lengths to be multiples of a half-w)-.198 E=0A=
(ord \(16 bits\), while)-.11 E(ensuring that the aggre)105 689.4 Q -.055=0A=
(ga)-.165 G(te length of the TSI and T).055 E=0A=
(OI \214elds is a multiple of 32-bits.)-.198 E(Luby/Gemmell/V)72 769 Q=0A=
(icisano/Rizzo/Handle)-.66 E(y/Cro)-.165 E 103.606(wcroft Section)-.275=0A=
F 2.75(3.1. [P)2.75 F(age 10])-.165 E EP=0A=
%%Page: 11 11=0A=
%%BeginPageSetup=0A=
BP=0A=
%%EndPageSetup=0A=
/F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 77.081(-DRAFT Expires:)-1.012 F=0A=
(April 2002)2.75 E(October 2001)112.127 E -.385(Tr)83 85 S=0A=
(ansport Session Identi\214er \215ag \(S\): 1 bit).385 E=0A=
(This is the number of full 32-bit w)105 101.6 Q=0A=
(ords in the TSI \214eld.)-.11 E(The TSI \214eld is 32*S + 16*H bits)5.5=0A=
E(in length, i.e. the length is either 0 bits, 16 bits, 32 bits, or 48 \=0A=
bits.)105 114.6 Q -.385(Tr)83 144.2 S=0A=
(ansport Object Identi\214er \215ag \(O\): 2 bits).385 E=0A=
(This is the number of full 32-bit w)105 160.8 Q(ords in the T)-.11 E=0A=
(OI \214eld.)-.198 E(The T)5.5 E(OI \214eld is 32*O + 16*H)-.198 E(bits\=0A=
in length, i.e., the length is either 0 bits, 16 bits, 32 bits, 48 bit\=0A=
s, 64 bits, 80 bits, 96)105 173.8 Q(bits, or 112 bits.)105 186.8 Q=0A=
(Sender Current T)83 216.4 Q(ime present \215ag \(T\): 1 bit)-.385 E=0A=
2.75(T=3D0i)105 233 S(ndicates that the Sender Current T)-2.75 E=0A=
(ime \(SCT\) \214eld is not present.)-.385 E 2.75(T=3D1i)105 246 S=0A=
(ndicates that the SCT \214eld is present.)-2.75 E=0A=
(The SCT is inserted by senders to indicate to recei)105 259 Q -.165(ve)=0A=
-.275 G(rs ho).165 E 2.75(wl)-.275 G(ong the session has been in)-2.75 E=0A=
(progress.)105 272 Q(Expected Residual T)83 301.6 Q=0A=
(ime present \215ag \(R\): 1 bit)-.385 E 2.75(R=3D0i)105 318.2 S=0A=
(ndicates that the Expected Residual T)-2.75 E(ime \(ER)-.385 E=0A=
(T\) \214eld is not present.)-.66 E 2.75(R=3D1i)105 331.2 S=0A=
(ndicates that the ER)-2.75 E 2.75<548c>-.66 G(eld is present.)-2.75 E=0A=
(The ER)105 344.2 Q 2.75(Ti)-.66 G 2.75(si)-2.75 G=0A=
(nserted by senders to indicate to recei)-2.75 E -.165(ve)-.275 G(rs ho)=0A=
.165 E 2.75(wm)-.275 G(uch longer the session /)-2.75 E=0A=
(object transmission will continue.)105 357.2 Q=0A=
(Senders must not set R =3D 1 when the ER)105 370.2 Q 2.75(Tf)-.66 G=0A=
(or the session is more than 2^32-1 time units)-2.75 E(\(approximately \=0A=
49 days\), where time is measured in units of milliseconds.)105 383.2 Q=0A=
(Close Session \215ag \(A\): 1 bit)83 412.8 Q(Normally)105 429.4 Q 2.75=0A=
(,Ai)-.715 G 2.75(ss)-2.75 G(et to 0.)-2.75 E=0A=
(The sender may set A to 1 when termination of transmission of)5.5 E=0A=
(pack)105 442.4 Q(ets for the session is imminent.)-.11 E 2.75(Am)5.5 G=0A=
(ay be set to 1 in just the last pack)-2.75 E(et transmitted)-.11 E=0A=
(for the session, or A may be set to 1 in the last fe)105 455.4 Q 2.75=0A=
(ws)-.275 G(econds of pack)-2.75 E(ets transmitted for the)-.11 E 2.75=0A=
(session. Once)105 468.4 R(the sender sets A to 1 in one pack)2.75 E=0A=
(et, the sender should set A to 1 in all)-.11 E(subsequent pack)105=0A=
481.4 Q(ets until termination of transmission of pack)-.11 E=0A=
(ets for the session.)-.11 E(A)5.5 E(recei)105 494.4 Q -.165(ve)-.275 G=0A=
2.75(dp).165 G(ack)-2.75 E(et with A set to 1 indicates to a recei)-.11=0A=
E -.165(ve)-.275 G 2.75(rt).165 G(hat the sender will immediately)-2.75=0A=
E(stop sending pack)105 507.4 Q(ets for the session.)-.11 E=0A=
(When a recei)5.5 E -.165(ve)-.275 G 2.75(rr).165 G(ecei)-2.75 E -.165=0A=
(ve)-.275 G 2.75(sap).165 G(ack)-2.75 E(et with A set to 1 the)-.11 E=0A=
(recei)105 520.4 Q -.165(ve)-.275 G 2.75(rs).165 G=0A=
(hould assume that no more pack)-2.75 E=0A=
(ets will be sent to the session.)-.11 E=0A=
(Close Object \215ag \(B\): 1 bit)83 550 Q(Normally)105 566.6 Q 2.75=0A=
(,Bi)-.715 G 2.75(ss)-2.75 G(et to 0.)-2.75 E=0A=
(The sender may set B to 1 when termination of transmission of)5.5 E=0A=
(pack)105 579.6 Q(ets for an object is imminent.)-.11 E(If the T)5.5 E=0A=
(OI \214eld is in use and B is set to 1 then)-.198 E=0A=
(termination of transmission for the object identi\214ed by the T)105=0A=
592.6 Q(OI \214eld is imminent.)-.198 E(If the)5.5 E -.198(TO)105 605.6=0A=
S 2.75<498c>.198 G(eld is not in use and B is set to 1 then termination\=0A=
of transmission for the one object)-2.75 E=0A=
(in the session identi\214ed by out of band information is imminent.)105=0A=
618.6 Q 2.75(Bm)5.5 G(ay be set to 1 in just)-2.75 E(the last pack)105=0A=
631.6 Q=0A=
(et transmitted for the object, or B may be set to 1 in the last fe)-.11=0A=
E 2.75(ws)-.275 G(econds)-2.75 E(pack)105 644.6 Q=0A=
(ets transmitted for the object.)-.11 E=0A=
(Once the sender sets B to 1 in one pack)5.5 E(et for a)-.11 E=0A=
(particular object, the sender should set B to 1 in all subsequent pack)=0A=
105 657.6 Q(ets for the object until)-.11 E=0A=
(termination of transmission of pack)105 670.6 Q(ets for the object.)=0A=
-.11 E 2.75(Ar)5.5 G(ecei)-2.75 E -.165(ve)-.275 G 2.75(dp).165 G(ack)=0A=
-2.75 E(et with B set to 1)-.11 E(indicates to a recei)105 683.6 Q -.165=0A=
(ve)-.275 G 2.75(rt).165 G=0A=
(hat the sender will immediately stop sending pack)-2.75 E=0A=
(ets for the object.)-.11 E(When a recei)105 696.6 Q -.165(ve)-.275 G=0A=
2.75(rr).165 G(ecei)-2.75 E -.165(ve)-.275 G 2.75(sap).165 G(ack)-2.75 E=0A=
(et with B set to 1 then it should assume that no more)-.11 E(pack)105=0A=
709.6 Q(ets will be sent for the object to the session.)-.11 E=0A=
(Luby/Gemmell/V)72 769 Q(icisano/Rizzo/Handle)-.66 E(y/Cro)-.165 E=0A=
103.606(wcroft Section)-.275 F 2.75(3.1. [P)2.75 F(age 11])-.165 E EP=0A=
%%Page: 12 12=0A=
%%BeginPageSetup=0A=
BP=0A=
%%EndPageSetup=0A=
/F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 77.081(-DRAFT Expires:)-1.012 F=0A=
(April 2002)2.75 E(October 2001)112.127 E=0A=
(LCT header length \(HDR_LEN\): 8 bits)83 85 Q -.88(To)105 101.6 S=0A=
(tal length of the LCT header in units of 32-bit w).88 E 2.75(ords. The)=0A=
-.11 F(length of the LCT header)2.75 E(must be a multiple of 32-bits.)=0A=
105 114.6 Q=0A=
(This \214eld can be used to directly access the portion of the)5.5 E=0A=
(pack)105 127.6 Q(et be)-.11 E(yond the LCT header)-.165 E 2.75(,i)-.44=0A=
G(.e., to the \214rst other header if it e)-2.75 E=0A=
(xists, or to the pack)-.165 E(et)-.11 E(payload if it e)105 140.6 Q=0A=
(xists and there is no other header)-.165 E 2.75(,o)-.44 G 2.75(rt)-2.75=0A=
G 2.75(ot)-2.75 G(he end of the pack)-2.75 E(et if there are no)-.11 E=0A=
(other headers or pack)105 153.6 Q(et payload.)-.11 E=0A=
(Codepoint \(CP\): 8 bits)83 183.2 Q=0A=
(An opaque identi\214er which is passed to the pack)105 199.8 Q=0A=
(et payload decoder to con)-.11 E .33 -.165(vey i)-.44 H(nformation).165=0A=
E(on the codec being used for the pack)105 212.8 Q=0A=
(et payload. The mapping between the codepoint and)-.11 E(the actual co\=0A=
dec is de\214ned on a per session basis and communicated out-of-band as\=0A=
part of)105 225.8 Q(the session description information.)105 238.8 Q=0A=
(The use of the CP \214eld is similar to the P)5.5 E(ayload T)-.165 E=0A=
(ype)-.88 E(\(PT\) \214eld in R)105 251.8 Q=0A=
(TP headers as described in RFC1889.)-.66 E=0A=
(Congestion Control Information \(CCI\): 32 or 64 bits)83 281.4 Q=0A=
(Used to carry congestion control information.)105 298 Q -.165(Fo)5.5 G=0A=
2.75(re).165 G(xample, the congestion control)-2.915 E(information coul\=0A=
d include layer numbers, logical channel numbers, and sequence)105 311 Q=0A=
(numbers. This \214eld is opaque for the purpose of this speci\214catio\=0A=
n.)105 324 Q(This \214eld must be 32 bits if C=3D0.)105 337 Q=0A=
(This \214eld must be 64 bits if C=3D1.)105 350 Q -.385(Tr)83 379.6 S=0A=
(ansport Session Identi\214er \(TSI\): 0, 16, 32 or 48 bits).385 E(The \=0A=
TSI uniquely identi\214es a session among all sessions from a particula\=0A=
r sender)105 396.2 Q 5.5(.T)-.605 G(he)-5.5 E=0A=
(TSI is scoped by the IP address of the sender)105 409.2 Q 2.75(,a)-.44=0A=
G(nd thus the IP address of the sender and the)-2.75 E=0A=
(TSI together uniquely identify the session.)105 422.2 Q=0A=
(Although a TSI in conjunction with the IP)5.5 E=0A=
(address of the sender must al)105 435.2 Q -.11(wa)-.11 G=0A=
(ys uniquely identify a session, whether or not the TSI is).11 E=0A=
(incuded in the LCT header depends on what is used as the TSI v)105=0A=
448.2 Q 2.75(alue. If)-.275 F(the underlying)2.75 E(transport is UDP)105=0A=
461.2 Q 2.75(,t)-1.221 G(hen the 16 bit UDP source port number may serv)=0A=
-2.75 E 2.75(ea)-.165 G 2.75(st)-2.75 G(he TSI for the)-2.75 E 2.75=0A=
(session. If)105 474.2 R(Generic Router Assist \(GRA\) is being used th\=0A=
en additional dependencies may)2.75 E=0A=
(be introduced by GRA on the TSI \214eld.)105 487.2 Q(If the TSI v)5.5 E=0A=
(alue appears multiple times in a)-.275 E(pack)105 500.2 Q=0A=
(et then all occurrences must be the same v)-.11 E 2.75(alue. If)-.275 F=0A=
(there is no underlying TSI)2.75 E(pro)105 513.2 Q(vided by the netw)=0A=
-.165 E(ork, transport or an)-.11 E 2.75(yo)-.165 G(ther layer)-2.75 E=0A=
2.75(,t)-.44 G(hen the TSI must be included in the)-2.75 E(LCT header)=0A=
105 526.2 Q(.)-.605 E(The TSI must be unique among all sessions serv)105=0A=
552.2 Q(ed by the sender during the period when)-.165 E=0A=
(the session is acti)105 565.2 Q -.165(ve)-.275 G 2.75(,a).165 G=0A=
(nd for a lar)-2.75 E(ge period of time preceding and follo)-.198 E=0A=
(wing when the)-.275 E(session is acti)105 578.2 Q -.165(ve)-.275 G 5.5=0A=
(.A).165 G(primary purpose of the TSI is to pre)-2.75 E -.165(ve)-.275 G=0A=
(nt recei).165 E -.165(ve)-.275 G(rs from inadv).165 E(ertently)-.165 E=0A=
(accepting pack)105 591.2 Q=0A=
(ets from a sender that belong to sessions other than sessions recei)=0A=
-.11 E -.165(ve)-.275 G(rs are).165 E(subscribed to.)105 604.2 Q -.165=0A=
(Fo)5.5 G 2.75(re).165 G(xample, suppose a session is deacti)-2.915 E=0A=
-.275(va)-.275 G(ted and then another session is).275 E(acti)105 617.2 Q=0A=
-.275(va)-.275 G(ted by a sender and the tw).275 E 2.75(os)-.11 G=0A=
(essions use an o)-2.75 E -.165(ve)-.165 G(rlapping set of channels.)=0A=
.165 E 2.75(Ar)5.5 G(ecei)-2.75 E -.165(ve)-.275 G(r).165 E(that connec\=0A=
ts and remains connected to the \214rst session during this sender acti)=0A=
105 630.2 Q(vity could)-.275 E(possibly accept pack)105 643.2 Q(ets fro\=0A=
m the second session as belonging to the \214rst session if the TSI)-.11=0A=
E(for the tw)105 656.2 Q 2.75(os)-.11 G(essions were identical.)-2.75 E=0A=
(The mapping of TSI \214eld v)5.5 E(alues to sessions must be)-.275 E=0A=
(done out of band.)105 669.2 Q=0A=
(The length of the TSI \214eld is 32*S + 16*H bits.)105 682.2 Q=0A=
(Note that the aggre)5.5 E -.055(ga)-.165 G(te lengths of the).055 E=0A=
(TSI \214eld plus the T)105 695.2 Q=0A=
(OI \214eld is a multiple of 32 bits.)-.198 E(Luby/Gemmell/V)72 769 Q=0A=
(icisano/Rizzo/Handle)-.66 E(y/Cro)-.165 E 103.606(wcroft Section)-.275=0A=
F 2.75(3.1. [P)2.75 F(age 12])-.165 E EP=0A=
%%Page: 13 13=0A=
%%BeginPageSetup=0A=
BP=0A=
%%EndPageSetup=0A=
/F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 77.081(-DRAFT Expires:)-1.012 F=0A=
(April 2002)2.75 E(October 2001)112.127 E -.385(Tr)83 85 S=0A=
(ansport Object Identi\214er \(T).385 E=0A=
(OI\): 0, 16, 32, 48, 64, 80, 96 or 112 bits.)-.198 E=0A=
(This \214eld indicates which object within the session this pack)105=0A=
101.6 Q(et pertains to.)-.11 E -.165(Fo)5.5 G 2.75(re).165 G(xample, a)=0A=
-2.915 E=0A=
(sender might send a number of \214les in the same session, using T)105=0A=
114.6 Q(OI=3D0 for the \214rst \214le,)-.198 E -.198(TO)105 127.6 S=0A=
(I=3D1 for the second one, etc. As another e).198 E(xample, the T)-.165 E=0A=
(OI may be a unique global)-.198 E=0A=
(identi\214er of the object that is being transmitted from se)105 140.6=0A=
Q -.165(ve)-.275 G(ral senders concurrently).165 E 2.75(,a)-.715 G=0A=
(nd the)-2.75 E -.198(TO)105 153.6 S 2.75(Iv).198 G(alue may be the oup\=0A=
tut of a hash function applied to the object. The mapping of T)-3.025 E=0A=
(OI)-.198 E(\214eld v)105 166.6 Q=0A=
(alues to objects must be done out of band.)-.275 E(The T)5.5 E=0A=
(OI \214eld must be used in all)-.198 E(pack)105 179.6 Q(ets if more th\=0A=
an one object is to be transmitted in a session, i.e. the T)-.11 E=0A=
(OI \214eld is either)-.198 E(present in all the pack)105 192.6 Q=0A=
(ets of a session or is ne)-.11 E -.165(ve)-.275 G 2.75(rp).165 G=0A=
(resent.)-2.75 E(The length of the T)105 205.6 Q=0A=
(OI \214eld is 32*O + 16*H bits.)-.198 E(Note that the aggre)5.5 E -.055=0A=
(ga)-.165 G(te lengths of the).055 E(TSI \214eld plus the T)105 218.6 Q=0A=
(OI \214eld is a multiple of 32 bits.)-.198 E(Sender Current T)83 248.2=0A=
Q(ime \(SCT\): 0 or 32 bits)-.385 E(This \214eld represents the current\=0A=
clock at the sender at the time this pack)105 264.8 Q(et w)-.11 E=0A=
(as transmitted,)-.11 E(measured in units of 1ms and computed modulo 2^\=0A=
32 units from the start of the session.)105 277.8 Q=0A=
(This \214eld must not be present if T=3D0 and must be present if =
T=3D1.)105=0A=
290.8 Q(Expected Residual T)83 320.4 Q(ime \(ER)-.385 E=0A=
(T\): 0 or 32 bits)-.66 E(This \214eld represents the sender e)105 337 Q=0A=
(xpected residual transmission time for the current session)-.165 E(or \=0A=
for the transmission of the current object, measured in units of 1ms. I\=0A=
f the pack)105 350 Q(et)-.11 E(containing the ER)105 363 Q 2.75<548c>=0A=
-.66 G(eld also contains the T)-2.75 E(OI \214eld, then ER)-.198 E 2.75=0A=
(Tr)-.66 G(efers to the object)-2.75 E(corresponding to the T)105 376 Q=0A=
(OI \214eld, otherwise it refers to the session.)-.198 E=0A=
(This \214eld must not be present if R=3D0 and must be present if =
R=3D1.)105=0A=
389 Q/F1 11/Times-Bold@0 SF(3.2.)72 428 Q/F2 13/Times-Bold@0 SF(Header)=0A=
5.5 E(-Extension Fields)-.481 E F0(Header Extensions are used in LCT to\=0A=
accommodate optional header \214elds that are not al)72 444.6 Q -.11=0A=
(wa)-.11 G(ys).11 E(used or ha)72 457.6 Q .33 -.165(ve v)-.22 H=0A=
(ariable size.)-.11 E(Examples of the use of Header Extensions include:)=0A=
5.5 E 11(oE)77.5 474.2 S(xtended-size v)-11 E(ersions of already e)-.165=0A=
E(xisting header \214elds.)-.165 E 11(oS)77.5 490.8 S(ender and Recei)=0A=
-11 E -.165(ve)-.275 G 2.75(ra).165 G(uthentication information.)-2.75 E=0A=
(The presence of Header Extensions can be inferred by the LCT header le\=0A=
ngth \(HDR_LEN\): if)72 520.4 Q(HDR_LEN is lar)72 533.4 Q(ger than the \=0A=
length of the standard header then the remaining header space is)-.198 E=0A=
(tak)72 546.4 Q(en by Header Extension \214elds.)-.11 E=0A=
(If present, Header Extensions must be processed to ensure that the)72=0A=
576 Q 2.75(ya)-.165 G(re recognized before)-2.75 E(performing an)72 589=0A=
Q 2.75(yc)-.165 G=0A=
(ongestion control procedure or otherwise accepting a pack)-2.75 E=0A=
(et. The def)-.11 E(ault action)-.11 E(for unrecognized header e)72 602=0A=
Q(xtensions is to ignore them. This allo)-.165 E=0A=
(ws the future introduction of)-.275 E(backw)72 615 Q=0A=
(ard-compatible enhancements to LCT without changing the LCT v)-.11 E=0A=
(ersion number)-.165 E 5.5(.N)-.605 G(on)-5.5 E(backw)72 628 Q=0A=
(ard-compatible header e)-.11 E(xtensions CANNO)-.165 E 2.75(Tb)-.44 G=0A=
2.75(ei)-2.75 G(ntroduced without changing the LCT)-2.75 E -.165(ve)72=0A=
641 S(rsion number).165 E(.)-.605 E(Protocol instantiation may o)72 667=0A=
Q -.165(ve)-.165 G(rride this def).165 E(ault beha)-.11 E=0A=
(vior for PI-speci\214c e)-.22 E(xtensions \(see belo)-.165 E(w\).)-.275=0A=
E(There are tw)72 693 Q 2.75(of)-.11 G=0A=
(ormats for Header Extension \214elds, as depicted belo)-2.75 E 1.43=0A=
-.715(w. T)-.275 H(he \214rst format is used for).715 E -.275(va)72 706=0A=
S(riable-length e).275 E(xtensions, with Header Extension T)-.165 E=0A=
(ype \(HET\) v)-.88 E(alues between 0 and 127. The)-.275 E=0A=
(second format is used for \214x)72 719 Q(ed length \(one 32-bit w)-.165=0A=
E(ord\) e)-.11 E(xtensions, using HET v)-.165 E(alues from 127)-.275 E=0A=
(Luby/Gemmell/V)72 769 Q(icisano/Rizzo/Handle)-.66 E(y/Cro)-.165 E=0A=
103.606(wcroft Section)-.275 F 2.75(3.2. [P)2.75 F(age 13])-.165 E EP=0A=
%%Page: 14 14=0A=
%%BeginPageSetup=0A=
BP=0A=
%%EndPageSetup=0A=
/F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 77.081(-DRAFT Expires:)-1.012 F=0A=
(April 2002)2.75 E(October 2001)112.127 E(to 255.)72 85 Q/F1 8/Courier@0=0A=
SF 91.2(0123)81.6 124 S 4.8(01234567890123456789012345678901)81.6 137 S=0A=
(+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+)76.8=0A=
150 Q 9.6(|H)76.8 163 S(ET \(<=3D127\))-9.6 E 33.6(|H)9.6 G 19.2(EL |)=0A=
-33.6 F(|)148.8 E 144(+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +)76.8 176 R=0A=
302.4(..)76.8 189 S 67.2(.H)76.8 202 S(eader Extension Content \(HEC\))=0A=
-67.2 E(.)91.2 E=0A=
(+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+)76.8=0A=
215 Q 91.2(0123)81.6 241 S 4.8(01234567890123456789012345678901)81.6 254=0A=
S(+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+)76.8=0A=
267 Q 9.6(|H)76.8 280 S(ET \(>=3D128\))-9.6 E 33.6(|H)9.6 G=0A=
(eader Extension Content \(HEC\))-33.6 E(|)48 E=0A=
(+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+)76.8=0A=
293 Q/F2 10/Times-Roman@0 SF(Figure 5 - F)72 332 Q=0A=
(ormat of additional headers)-.15 E F0(The e)72 361.6 Q=0A=
(xplanation of each sub-\214eld is the follo)-.165 E(wing.)-.275 E=0A=
(Header Extension T)83 391.2 Q(ype \(HET\): 8 bits)-.88 E(The type of t\=0A=
he Header Extension. This document de\214nes a number of possible types\=0A=
.)105 407.8 Q(Additional types may be de\214ned in future v)105 420.8 Q=0A=
(ersion of this speci\214cation. HET v)-.165 E(alues from 0)-.275 E=0A=
(to 127 are used for v)105 433.8 Q=0A=
(ariable-length Header Extensions. HET v)-.275 E=0A=
(alues from 128 to 255 are)-.275 E(used for \214x)105 446.8 Q=0A=
(ed-length 32-bit Header Extensions.)-.165 E=0A=
(Header Extension Length \(HEL\): 8 bits)83 476.4 Q=0A=
(The length of the whole Header Extension \214eld, e)105 493 Q=0A=
(xpressed in multiples of 32-bit w)-.165 E(ords.)-.11 E=0A=
(This \214eld must be present for v)105 506 Q(ariable-length e)-.275 E=0A=
(xtensions \(HET between 0 and 127\) and)-.165 E=0A=
(must not be present for \214x)105 519 Q(ed-length e)-.165 E=0A=
(xtensions \(HET between 128 and 255\).)-.165 E=0A=
(Header Extension Content \(HEC\): v)83 548.6 Q(ariable length)-.275 E(\=0A=
The content of the Header Extension. The format of this sub-\214eld dep\=0A=
ends on the Header)105 565.2 Q(Extension type.)105 578.2 Q -.165(Fo)5.5=0A=
G 2.75<728c>.165 G -.165(xe)-2.75 G=0A=
(d-length Header Extensions, the HEC is 24 bits.).165 E -.165(Fo)5.5 G=0A=
2.75(rv).165 G(ariable-)-3.025 E=0A=
(length Header Extensions, the HEC \214eld has v)105 591.2 Q=0A=
(ariable size, as speci\214ed by the HEL \214eld.)-.275 E(Note that the\=0A=
length of each Header Extension \214eld must be a multiple of 32 bits.)=0A=
105 604.2 Q(Also)5.5 E(note that the total size of the LCT header)105=0A=
617.2 Q 2.75(,i)-.44 G(ncluding all Header Extensions and all optional)=0A=
-2.75 E(header \214elds, cannot e)105 630.2 Q(xceed 255 32-bit w)-.165 E=0A=
(ords.)-.11 E(Header Extensions are further di)72 659.8 Q=0A=
(vided between general LCT e)-.275 E=0A=
(xtensions and Protocol Instantiation)-.165 E(speci\214c e)72 672.8 Q=0A=
(xtensions \(PI-speci\214c\).)-.165 E(General LCT e)5.5 E(xtensions ha)=0A=
-.165 E .33 -.165(ve H)-.22 H(ET in the ranges 0:63 and).165 E=0A=
(128:191 inclusi)72 685.8 Q -.165(ve)-.275 G 5.5(.P).165 G=0A=
(I-speci\214c e)-5.5 E(xtensions ha)-.165 E .33 -.165(ve H)-.22 H=0A=
(ET in the ranges 64:127 and 192:255 inclusi).165 E -.165(ve)-.275 G(.)=0A=
.165 E(General LCT e)72 711.8 Q(xtensions are intended to allo)-.165 E=0A=
2.75(wt)-.275 G(he introduction of backw)-2.75 E(ard-compatible)-.11 E=0A=
(enhancements to LCT without changing the LCT v)72 724.8 Q=0A=
(ersion number)-.165 E 5.5(.N)-.605 G(on backw)-5.5 E(ard-compatible)=0A=
-.11 E(Luby/Gemmell/V)72 769 Q(icisano/Rizzo/Handle)-.66 E(y/Cro)-.165 E=0A=
103.606(wcroft Section)-.275 F 2.75(3.2. [P)2.75 F(age 14])-.165 E EP=0A=
%%Page: 15 15=0A=
%%BeginPageSetup=0A=
BP=0A=
%%EndPageSetup=0A=
/F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 77.081(-DRAFT Expires:)-1.012 F=0A=
(April 2002)2.75 E(October 2001)112.127 E(header e)72 85 Q=0A=
(xtensions CANNO)-.165 E 2.75(Tb)-.44 G 2.75(ei)-2.75 G=0A=
(ntroduced without changing the LCT v)-2.75 E(ersion number)-.165 E(.)=0A=
-.605 E(PI-speci\214c e)72 111 Q(xtensions are reserv)-.165 E=0A=
(ed for PI-speci\214c use with semantic and def)-.165 E=0A=
(ault parsing actions)-.11 E(de\214ned by the PI.)72 124 Q(The follo)72=0A=
150 Q(wing general LCT Header Extension types are de\214ned:)-.275 E=0A=
13.662(EXT_NOP=3D0 No-Operation)72 166.6 R -.165(ex)2.75 G(tension.).165 =
E=0A=
(The information present in this e)149 179.6 Q=0A=
(xtension \214eld must be ignored by recei)-.165 E -.165(ve)-.275 G(rs.)=0A=
.165 E(EXT_A)72 209.2 Q 5.72(UTH=3D2 P)-.605 F(ack)-.165 E=0A=
(et authentication e)-.11 E(xtension)-.165 E=0A=
(Information used to authenticate the sender of the pack)149 222.2 Q=0A=
2.75(et. If)-.11 F(present, the format)2.75 E(of this Header Extension \=0A=
and its processing must be communicated out-of-band)149 235.2 Q=0A=
(as part of the session description.)149 248.2 Q=0A=
(It is recommended that senders pro)149 261.2 Q(vide some form of pack)=0A=
-.165 E(et authentication.)-.11 E(If)5.5 E(EXT_A)149 274.2 Q=0A=
(UTH is present, whate)-.605 E -.165(ve)-.275 G 2.75(rp).165 G(ack)-2.75=0A=
E(et authentication checks that can be)-.11 E=0A=
(performed immediately upon reception of the pack)149 287.2 Q=0A=
(et must be performed before)-.11 E(accepting the pack)149 300.2 Q=0A=
(et and performing an)-.11 E 2.75(yc)-.165 G=0A=
(ongestion control-related action on it.)-2.75 E(Some pack)149 313.2 Q=0A=
(et authentication schemes impose a delay of se)-.11 E -.165(ve)-.275 G=0A=
(ral seconds between).165 E(when a pack)149 326.2 Q(et is recei)-.11 E=0A=
-.165(ve)-.275 G 2.75(da).165 G(nd when the pack)-2.75 E=0A=
(et is fully authenticated.)-.11 E(An)5.5 E(y)-.165 E(congestion contro\=0A=
l related action that is appropriate must not be postponed by)149 339.2=0A=
Q(an)149 352.2 Q 2.75(ys)-.165 G(uch full pack)-2.75 E=0A=
(et authentication.)-.11 E(All senders and recei)72 381.8 Q -.165(ve)=0A=
-.275 G=0A=
(rs implementing LCT must support the EXT_NOP Header Extension and).165=0A=
E(must recognize EXT_A)72 394.8 Q(UTH, b)-.605 E=0A=
(ut may not be able to parse its content.)-.22 E/F1 11/Times-Bold@0 SF=0A=
(4.)72 433.8 Q/F2 14/Times-Bold@0 SF(Pr)5.5 E(ocedur)-.252 E(es)-.252 E=0A=
F1(4.1.)72 472.8 Q/F3 13/Times-Bold@0 SF(Sender Operation)5.5 E F0 2.75=0A=
(As)72 489.4 S(ender using LCT must mak)-2.75 E 2.75(eas)-.11 G=0A=
(ession description a)-2.75 E -.275(va)-.22 G(ilable to clients that w)=0A=
.275 E(ant to join an LCT)-.11 E 2.75(session. This)72 502.4 R=0A=
(information could include, b)2.75 E(ut is not limited to:)-.22 E 11(oT)=0A=
77.5 519 S(he number of LCT channels;)-11 E 11(oT)77.5 535.6 S=0A=
(he addresses, port numbers and data rates used for each LCT channel;)=0A=
-11 E 11(oT)77.5 552.2 S(he formats of an)-11 E 2.75(yo)-.165 G=0A=
(ther headers.)-2.75 E -.165(Fo)5.5 G 2.75(re).165 G=0A=
(xample, an FEC header as described in [6] could be)-2.915 E=0A=
(such an other header)94 565.2 Q 5.5(.T)-.605 G(hen for e)-5.5 E=0A=
(xample the information could include the mapping of)-.165 E=0A=
(codepoints used in the session to FEC codec types and parameters;)94=0A=
578.2 Q 11(oT)77.5 594.8 S(he format and lengths of the pack)-11 E=0A=
(et payload;)-.11 E 11(oT)77.5 611.4 S(he T)-11 E=0A=
(ransport Session ID \(TSI\) to be used for the session;)-.385 E 11(oW)=0A=
77.5 628 S(hether or not Generic Router Assist \(GRA\) is being used;)=0A=
-11 E 11(oT)77.5 644.6 S(he congestion control scheme being used;)-11 E=0A=
11(oT)77.5 661.2 S(he mapping of T)-11 E(OI v)-.198 E=0A=
(alue\(s\) to objects for the session;)-.275 E 11(oA)77.5 677.8 S .33=0A=
-.165(ny i)-11 H(nformation that is rele).165 E -.275(va)-.275 G=0A=
(nt to each object being transported, such as when it will be).275 E=0A=
-.22(av)94 690.8 S(ailable within the session, for ho)-.055 E 2.75(wl)=0A=
-.275 G(ong, and the length of the object;)-2.75 E 11(oT)77.5 707.4 S=0A=
(he pack)-11 E(et authentication scheme being used, and all rele)-.11 E=0A=
-.275(va)-.275 G(nt information which is).275 E=0A=
(necessary for client pack)94 720.4 Q(et authentication purposes;)-.11 E=0A=
(Luby/Gemmell/V)72 769 Q(icisano/Rizzo/Handle)-.66 E(y/Cro)-.165 E=0A=
103.606(wcroft Section)-.275 F 2.75(4.1. [P)2.75 F(age 15])-.165 E EP=0A=
%%Page: 16 16=0A=
%%BeginPageSetup=0A=
BP=0A=
%%EndPageSetup=0A=
/F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 77.081(-DRAFT Expires:)-1.012 F=0A=
(April 2002)2.75 E(October 2001)112.127 E=0A=
(Some of the session description information must be obtained by recei)=0A=
72 85 Q -.165(ve)-.275 G(rs before the).165 E 2.75(yc)-.165 G(onnect to)=0A=
-2.75 E(the session.)72 98 Q=0A=
(This includes the number and addresses of the LCT channels, the TSI v)=0A=
5.5 E(alue for the)-.275 E(session, the formats of an)72 111 Q 2.75(yo)=0A=
-.165 G(ther headers, the congestion control scheme being used and the)=0A=
-2.75 E(pack)72 124 Q(et authentication scheme if it is used.)-.11 E=0A=
(Some of the session description information may be)5.5 E=0A=
(obtained by recei)72 137 Q -.165(ve)-.275 G(rs while the).165 E 2.75=0A=
(ya)-.165 G(re connected to the session, e.g., information rele)-2.75 E=0A=
-.275(va)-.275 G(nt to objects).275 E=0A=
(being transported within the session such as their T)72 150 Q=0A=
(OI, when the)-.198 E 2.75(ya)-.165 G(re a)-2.75 E -.275(va)-.22 G=0A=
(ilable within the session,).275 E(for ho)72 163 Q 2.75(wl)-.275 G=0A=
(ong, and their lengths.)-2.75 E(The session description could be in a \=0A=
form such as SDP as de\214ned in RFC2327, XML metadata,)72 189 Q(HTTP/M\=0A=
ime headers, etc. It might be carried in a session announcement protoco\=0A=
l such as SAP as)72 202 Q(de\214ned in RFC2974, obtained using a propri\=0A=
etary session control protocol, located on a W)72 215 Q(eb page)-.88 E=0A=
(with scheduling information, or con)72 228 Q -.165(vey)-.44 G=0A=
(ed via E-mail or other out of band methods.).165 E(Discussion of)5.5 E=0A=
(session description format, and distrib)72 241 Q=0A=
(ution of session descriptions is be)-.22 E(yond the scope of this)-.165=0A=
E(document.)72 254 Q -.44(Wi)72 280 S=0A=
(thin an LCT session, a sender using LCT transmits a sequence of pack)=0A=
.44 E(ets each in a format)-.11 E(de\214ned in the session description.)=0A=
72 293 Q -.165(Pa)5.5 G(ck).165 E=0A=
(ets are sent from a sender using one or more LCT)-.11 E=0A=
(channels which together constitute a session.)72 306 Q -.385(Tr)5.5 G=0A=
(ansmission rates may be dif).385 E(ferent in dif)-.275 E(ferent)-.275 E=0A=
(channels and may v)72 319 Q(ary o)-.275 E -.165(ve)-.165 G 2.75(rt).165=0A=
G 2.75(ime. The)-2.75 F(speci\214cation of the other b)2.75 E=0A=
(uilding block headers and the)-.22 E(pack)72 332 Q=0A=
(et payload used by a complete protocol instantiation using LCT is be)=0A=
-.11 E(yond the scope of this)-.165 E 2.75(document. This)72 345 R=0A=
(document does not specify the order in which pack)2.75 E=0A=
(ets are transmitted, nor the)-.11 E(or)72 358 Q -.055(ga)-.198 G=0A=
(nization of a session into multiple channels. Although these issues af)=0A=
.055 E(fect the ef)-.275 E(\214cienc)-.275 E 2.75(yo)-.165 G 2.75(ft)=0A=
-2.75 G(he)-2.75 E(protocol, the)72 371 Q 2.75(yd)-.165 G 2.75(on)-2.75=0A=
G(ot af)-2.75 E(fect the correctness nor the inter)-.275 E=0A=
(-operability of LCT between senders and)-.22 E(recei)72 384 Q -.165(ve)=0A=
-.275 G(rs.).165 E=0A=
(Multiple objects can be carried within the same LCT session.)72 410 Q=0A=
(In this case, each object must be)5.5 E(identi\214ed by a unique T)72=0A=
423 Q 2.75(OI. Objects)-.198 F(may be transmitted sequentially)2.75 E=0A=
2.75(,o)-.715 G 2.75(rt)-2.75 G(he)-2.75 E 2.75(ym)-.165 G=0A=
(ay be transmitted)-2.75 E(concurrently)72 436 Q 5.5(.I)-.715 G 2.75(ti)=0A=
-5.5 G 2.75(sg)-2.75 G(ood practice to only send objects concurrently i\=0A=
n the same session if the)-2.75 E(recei)72 449 Q -.165(ve)-.275 G=0A=
(rs that participate in that portion of the session ha).165 E .33 -.165=0A=
(ve i)-.22 H(nterest in recei).165 E(ving all the objects.)-.275 E=0A=
(The reason for this is that it w)72 462 Q(astes bandwidth and netw)-.11=0A=
E(orking resources to ha)-.11 E .33 -.165(ve r)-.22 H(ecei).165 E -.165=0A=
(ve)-.275 G(rs recei).165 E -.165(ve)-.275 G(data for objects that the)=0A=
72 475 Q 2.75(yh)-.165 G -2.475 -.22(av e)-2.75 H(no interest in.)2.97 E=0A=
-.88(Ty)72 501 S(pically).88 E 2.75(,t)-.715 G=0A=
(he sender\(s\) continues to send pack)-2.75 E=0A=
(ets in a session until the transmission is considered)-.11 E 2.75=0A=
(complete. The)72 514 R=0A=
(transmission may be considered complete when some time has e)2.75 E=0A=
(xpired, a certain)-.165 E(number of pack)72 527 Q(ets ha)-.11 E .33=0A=
-.165(ve b)-.22 H=0A=
(een sent, or some out of band signal \(possibly from a higher le).165 E=0A=
-.165(ve)-.275 G(l).165 E(protocol\) has indicated completion by a suf)=0A=
72 540 Q(\214cient number of recei)-.275 E -.165(ve)-.275 G(rs.).165 E=0A=
-.165(Fo)72 566 S 2.75(rt).165 G(he reasons mentioned abo)-2.75 E -.165=0A=
(ve)-.165 G 2.75(,t).165 G(his document does not pose an)-2.75 E 2.75=0A=
(yr)-.165 G(estriction on pack)-2.75 E(et sizes.)-.11 E(Ho)72 579 Q(we)=0A=
-.275 E -.165(ve)-.275 G .88 -.44(r, n).165 H(etw).44 E(ork ef)-.11 E=0A=
(\214cienc)-.275 E 2.75(yc)-.165 G=0A=
(onsiderations recommend that the sender uses as lar)-2.75 E=0A=
(ge as possible)-.198 E(pack)72 592 Q(et payload size, b)-.11 E=0A=
(ut in such a w)-.22 E(ay that pack)-.11 E(ets do not e)-.11 E=0A=
(xceed the netw)-.165 E(ork')-.11 E 2.75(sm)-.605 G(aximum)-2.75 E=0A=
(transmission unit size \(MTU\), or fragmentation coupled with pack)72=0A=
605 Q(et loss might introduce se)-.11 E -.165(ve)-.275 G(re).165 E(inef)=0A=
72 618 Q(\214cienc)-.275 E 2.75(yi)-.165 G 2.75(nt)-2.75 G=0A=
(he transmission.)-2.75 E(It is recommended that all pack)72 644 Q=0A=
(ets ha)-.11 E .33 -.165(ve t)-.22 H(he same or v).165 E=0A=
(ery similar sizes, as this can ha)-.165 E .33 -.165(ve a s)-.22 H=0A=
-2.365 -.275(ev e).165 H(re).275 E(impact on the ef)72 657 Q(fecti)-.275=0A=
E -.165(ve)-.275 G(ness of congestion control schemes such as the ones \=0A=
described in [11] and).165 E 2.75([1]. A)72 670 R(sender of pack)2.75 E=0A=
(ets using LCT must implement the sender)-.11 E=0A=
(-side part of one of the congestion)-.22 E(control schemes that is in \=0A=
accordance with RFC2357 using the Congestion Control Information)72 683=0A=
Q(\214eld pro)72 696 Q(vided in the LCT header)-.165 E 2.75(,a)-.44 G=0A=
(nd the corresponding recei)-2.75 E -.165(ve)-.275 G 2.75(rc).165 G=0A=
(ongestion control scheme must)-2.75 E=0A=
(be communicated out of band and implemented by an)72 709 Q 2.75(yr)=0A=
-.165 G(ecei)-2.75 E -.165(ve)-.275 G(rs participating in the session.)=0A=
.165 E(Luby/Gemmell/V)72 769 Q(icisano/Rizzo/Handle)-.66 E(y/Cro)-.165 E=0A=
103.606(wcroft Section)-.275 F 2.75(4.1. [P)2.75 F(age 16])-.165 E EP=0A=
%%Page: 17 17=0A=
%%BeginPageSetup=0A=
BP=0A=
%%EndPageSetup=0A=
/F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 77.081(-DRAFT Expires:)-1.012 F=0A=
(April 2002)2.75 E(October 2001)112.127 E/F1 11/Times-Bold@0 SF(4.2.)72=0A=
85 Q/F2 13/Times-Bold@0 SF(Recei)5.5 E -.13(ve)-.13 G 3.25(rO).13 G=0A=
(peration)-3.25 E F0(Recei)72 101.6 Q -.165(ve)-.275 G=0A=
(rs can operate dif).165 E(ferently depending on the deli)-.275 E -.165=0A=
(ve)-.275 G(ry service model.).165 E -.165(Fo)5.5 G 2.75(re).165 G=0A=
(xample, for an)-2.915 E(on demand service model recei)72 114.6 Q -.165=0A=
(ve)-.275 G=0A=
(rs may join a session, obtain the necessary encoding symbols to).165 E=0A=
(reproduce the object, and then lea)72 127.6 Q .33 -.165(ve t)-.22 H=0A=
(he session.).165 E(As another e)5.5 E(xample, for a streaming service)=0A=
-.165 E(model a recei)72 140.6 Q -.165(ve)-.275 G 2.75(rm).165 G=0A=
(ay be continuously joined to a set of LCT channels to do)-2.75 E=0A=
(wnload all objects in a)-.275 E(session.)72 153.6 Q 1.76 -.88(To b)72=0A=
179.6 T 2.75(ea).88 G(ble to participate in a session, a recei)-2.75 E=0A=
-.165(ve)-.275 G 2.75(rm).165 G(ust \214rst obtain the rele)-2.75 E=0A=
-.275(va)-.275 G(nt session description).275 E=0A=
(information as listed in Section 4.1.)72 192.6 Q(If pack)72 209.2 Q=0A=
(et authentication information is present in an LCT header)-.11 E 2.75=0A=
(,i)-.44 G 2.75(ts)-2.75 G(hould be used as speci\214ed in)-2.75 E=0A=
(Section 3.2.)72 222.2 Q 1.76 -.88(To b)5.5 H 2.75(ea).88 G=0A=
(ble to be a recei)-2.75 E -.165(ve)-.275 G 2.75(ri).165 G 2.75(nas)=0A=
-2.75 G(ession, the recei)-2.75 E -.165(ve)-.275 G 2.75(rm).165 G=0A=
(ust be able to process the LCT)-2.75 E(header)72 235.2 Q 5.5(.T)-.605 G=0A=
(he recei)-5.5 E -.165(ve)-.275 G 2.75(rm).165 G=0A=
(ust be able to discard, forw)-2.75 E=0A=
(ard, store or process the other headers and the)-.11 E(pack)72 248.2 Q=0A=
(et payload.)-.11 E(If a recei)5.5 E -.165(ve)-.275 G 2.75(ri).165 G=0A=
2.75(sn)-2.75 G(ot able to process a LCT header)-2.75 E 2.75(,i)-.44 G=0A=
2.75(tm)-2.75 G(ust drop from the session.)-2.75 E 1.76 -.88(To b)72=0A=
274.2 T 2.75(ea).88 G(ble to participate in a session, a recei)-2.75 E=0A=
-.165(ve)-.275 G 2.75(rm).165 G=0A=
(ust implement the congestion control protocol)-2.75 E(speci\214ed in t\=0A=
he session description using the Congestion Control Information \214eld\=0A=
pro)72 287.2 Q(vided in the)-.165 E(LCT header)72 300.2 Q 2.75(.I)-.605=0A=
G 2.75(far)-2.75 G(ecei)-2.75 E -.165(ve)-.275 G 2.75(ri).165 G 2.75(sn)=0A=
-2.75 G=0A=
(ot able to implement the congestion control protocol used in the)-2.75=0A=
E(session, it must not join the session.)72 313.2 Q=0A=
(When the session is transmitted on multiple LCT channels,)5.5 E(recei)=0A=
72 326.2 Q -.165(ve)-.275 G(rs must initially join channels according t\=0A=
o the speci\214ed startup beha).165 E(vior of the congestion)-.22 E=0A=
(control protocol itself. F)72 339.2 Q(or a layered transmission on mul\=0A=
tiple channels, this typically means that a)-.165 E(recei)72 352.2 Q=0A=
-.165(ve)-.275 G 2.75(rw).165 G(ill initially join only a minimal set o\=0A=
f LCT channels, possibly a single one, that in)-2.75 E(aggre)72 365.2 Q=0A=
-.055(ga)-.165 G(te are carrying pack).055 E(ets at a lo)-.11 E 2.75(wr)=0A=
-.275 G 2.75(ate. This)-2.75 F(rule has the purpose of pre)2.75 E -.165=0A=
(ve)-.275 G(nting recei).165 E -.165(ve)-.275 G(rs).165 E=0A=
(from starting at high data rates.)72 378.2 Q(Multiple objects can be c\=0A=
arried either sequentially or concurrently within the same LCT session.)=0A=
72 404.2 Q(In this case, each object is identi\214ed by a unique T)72=0A=
417.2 Q 2.75(OI. Note)-.198 F(that e)2.75 E -.165(ve)-.275 G 2.75(ni)=0A=
.165 G 2.75(fas)-2.75 G(erv)-2.75 E(er stops sending)-.165 E(pack)72=0A=
430.2 Q(ets for an old object before starting to transmit pack)-.11 E=0A=
(ets for a ne)-.11 E 2.75(wo)-.275 G(bject, both the netw)-2.75 E(ork)=0A=
-.11 E=0A=
(and the underlying protocol layers can cause some reordering of pack)72=0A=
443.2 Q(ets, especially when sent)-.11 E -.165(ove)72 456.2 S 2.75(rd)=0A=
.165 G(if)-2.75 E(ferent LCT channels, and thus recei)-.275 E -.165(ve)=0A=
-.275 G(rs should not assume that the reception of a pack).165 E(et)-.11=0A=
E(for a ne)72 469.2 Q 2.75(wo)-.275 G=0A=
(bject means that there are no more pack)-2.75 E=0A=
(ets in transit for the pre)-.11 E(vious one, at least for)-.275 E=0A=
(some amount of time.)72 482.2 Q 2.75(Ar)72 508.2 S(ecei)-2.75 E -.165=0A=
(ve)-.275 G 2.75(rm).165 G(ay be concurrently joined to multiple LCT se\=0A=
ssions from one or more senders. The)-2.75 E(recei)72 521.2 Q -.165(ve)=0A=
-.275 G 2.75(rm).165 G=0A=
(ust perform congestion control on each such LCT session.)-2.75 E=0A=
(If the congestion control)5.5 E(protocol allo)72 534.2 Q(ws the recei)=0A=
-.275 E -.165(ve)-.275 G 2.75(rs).165 G(ome \215e)-2.75 E=0A=
(xibility in terms of its actions within a session then the)-.165 E=0A=
(recei)72 547.2 Q -.165(ve)-.275 G 2.75(rm).165 G(ay mak)-2.75 E 2.75=0A=
(ec)-.11 G(hoices to optimize the pack)-2.75 E(et \215o)-.11 E 2.75(wp)=0A=
-.275 G(erformance across the multiple LCT)-2.75 E=0A=
(sessions, as long as the recei)72 560.2 Q -.165(ve)-.275 G 2.75(rs).165=0A=
G(till adheres to the congestion control rules for each LCT session)=0A=
-2.75 E(indi)72 573.2 Q(vidually)-.275 E(.)-.715 E F1(5.)72 612.2 Q/F3=0A=
14/Times-Bold@0 SF(Security Considerations)5.5 E F0=0A=
(LCT can be subject to denial-of-service attacks by attack)72 628.8 Q=0A=
(ers which try to confuse the congestion)-.11 E=0A=
(control mechanism, or send for)72 641.8 Q(ged pack)-.198 E=0A=
(ets to the session which w)-.11 E(ould pre)-.11 E -.165(ve)-.275 G=0A=
(nt successful).165 E(reconstruction of lar)72 654.8 Q=0A=
(ge portions of the objects.)-.198 E(The same e)72 680.8 Q=0A=
(xact problems are present in TCP)-.165 E 2.75(,w)-1.221 G=0A=
(here an attack)-2.75 E(er can for)-.11 E(ge pack)-.198 E=0A=
(ets and either slo)-.11 E(w)-.275 E(do)72 693.8 Q(wn or increase the t\=0A=
hroughput of the session, or replace parts of the data stream with for)=0A=
-.275 E(ged)-.198 E=0A=
(data. If the stream is carrying compressed or otherwise coded data, e)=0A=
72 706.8 Q -.165(ve)-.275 G 2.75(nas).165 G(ingle for)-2.75 E(ged pack)=0A=
-.198 E(et)-.11 E(could also cause incorrect reconstruction of the rest\=0A=
of the data stream.)72 719.8 Q(Luby/Gemmell/V)72 769 Q=0A=
(icisano/Rizzo/Handle)-.66 E(y/Cro)-.165 E 111.856(wcroft Section)-.275=0A=
F 2.75(5. [P)2.75 F(age 17])-.165 E EP=0A=
%%Page: 18 18=0A=
%%BeginPageSetup=0A=
BP=0A=
%%EndPageSetup=0A=
/F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 77.081(-DRAFT Expires:)-1.012 F=0A=
(April 2002)2.75 E(October 2001)112.127 E(It is therefore recommended t\=0A=
hat protocol instantiations that use LCT implement some form of)72 85 Q=0A=
(pack)72 98 Q(et authentication to protect themselv)-.11 E(es ag)-.165 E=0A=
(ainst such attacks.)-.055 E/F1 11/Times-Bold@0 SF(6.)72 137 Q/F2 14=0A=
/Times-Bold@0 SF(IAN)5.5 E 3.5(AC)-.28 G(onsiderations)-3.5 E F0=0A=
(No information in this speci\214cation is subject to IAN)72 153.6 Q=0A=
2.75(Ar)-.385 G -.165(eg)-2.75 G(istration.).165 E(Building blocks used\=0A=
in conjunction with LCT may introduce additional IAN)72 179.6 Q 2.75=0A=
(Ac)-.385 G(onsiderations.)-2.75 E F1(7.)72 218.6 Q F2(Intellectual Pr)=0A=
5.5 E(operty Issues)-.252 E F0(No speci\214c reliability protocol or co\=0A=
ngestion control protocol is speci\214ed or referenced as)72 248.2 Q=0A=
(mandatory in this document.)72 261.2 Q(LCT may be used with congestion\=0A=
control protocols and other protocols, such as reliability)72 287.2 Q=0A=
(protocols, which are proprietary or ha)72 300.2 Q .33 -.165(ve p)-.22 H=0A=
(ending or granted patents.).165 E F1(8.)72 339.2 Q F2(Ackno)5.5 E=0A=
(wledgments)-.14 E F0(Thanks to V)72 355.8 Q(incent Roca, Bruce Lueck)=0A=
-.66 E(enhof)-.11 E(f, Hayder Radha and Justin Chapwesk)-.275 E 2.75(ef)=0A=
-.11 G(or detailed)-2.75 E(comments on this document.)72 368.8 Q F1(9.)=0A=
72 407.8 Q F2(Refer)5.5 E(ences)-.252 E F0([1] Byers, J.W)72 437.4 Q=0A=
(., Frumin, M., Horn, G., Luby)-1.012 E 2.75(,M)-.715 G(., Mitzenmacher)=0A=
-2.75 E 2.75(,M)-.44 G(., Roetter)-2.75 E 2.75(,A)-.44 G(., and Sha)=0A=
-2.75 E -.165(ve)-.22 G .88 -.44(r, W).165 H(.,)-.572 E("FLID-DL: Conge\=0A=
stion Control for Layered Multicast", Proceedings of Second Internation\=0A=
al)72 450.4 Q -.88(Wo)72 463.4 S(rkshop on Netw).88 E(ork)-.11 E=0A=
(ed Group Communications \(NGC 2000\), P)-.11 E(alo Alto, CA, No)-.165 E=0A=
-.165(ve)-.165 G(mber 2000.).165 E([2] Byers, J.W)72 489.4 Q(., Luby)=0A=
-1.012 E 2.75(,M)-.715 G(., Mitzenmacher)-2.75 E 2.75(,M)-.44 G=0A=
(., and Re)-2.75 E(ge, A., "A Digital F)-.165 E(ountain Approach to)=0A=
-.165 E(Reliable Distrib)72 502.4 Q(ution of Bulk Data", Proceedings A)=0A=
-.22 E(CM SIGCOMM '98, V)-.44 E(ancouv)-1.221 E(er)-.165 E 2.75(,C)-.44=0A=
G(anada,)-2.75 E(September 1998.)72 515.4 Q([3] Gemmell, J., Schooler)72=0A=
541.4 Q 2.75(,E)-.44 G(., and Gray)-2.75 E 2.75(,J)-.715 G=0A=
(., "Fcast Multicast File Distrib)-2.75 E(ution", IEEE Netw)-.22 E(ork,)=0A=
-.11 E -1.419(Vo)72 554.4 S(l. 14, No. 1, pp. 58-68, January 2000.)1.419=0A=
E([4] Holbrook, H. W)72 580.4 Q=0A=
(., "A Channel Model for Multicast," Ph.D. Dissertation, Stanford Uni)=0A=
-1.012 E -.165(ve)-.275 G(rsity).165 E(,)-.715 E=0A=
(Department of Computer Science, Stanford, California, August 2001.)72=0A=
593.4 Q([5] Luby)72 619.4 Q 2.75(,M)-.715 G(., Gemmell, V)-2.75 E=0A=
(icisano, L., J., Rizzo, L., Handle)-.66 E 1.43 -.715(y, M)-.165 H=0A=
(., Cro).715 E(wcroft, J., "The use of)-.275 E -.165(Fo)72 632.4 S(rw)=0A=
.165 E(ard Error Correction in Reliable Multicast", Internet Draft draf\=0A=
t-ietf-rmt-info-fec-01.txt,)-.11 E(October 2001, a w)72 645.4 Q=0A=
(ork in progress.)-.11 E([6] Luby)72 671.4 Q 2.75(,M)-.715 G=0A=
(., Gemmell, J., V)-2.75 E(icisano, L., Rizzo, L., Handle)-.66 E 1.43=0A=
-.715(y, M)-.165 H(., Cro).715 E(wcroft, J., "RMT BB)-.275 E -.165(Fo)72=0A=
684.4 S(rw).165 E(ard Error Correction Codes", Internet Draft draft-iet\=0A=
f-rmt-bb-fec-04.txt, October 2001.)-.11 E([7] Rizzo, L., "Ef)72 710.4 Q=0A=
(fecti)-.275 E .33 -.165(ve E)-.275 H=0A=
(rasure Codes for Reliable Computer Communication Protocols", A).165 E=0A=
(CM)-.44 E(SIGCOMM Computer Communication Re)72 723.4 Q(vie)-.275 E 1.43=0A=
-.715(w, V)-.275 H(ol.27, No.2, pp.24-36, Apr 1997.)-.704 E=0A=
(Luby/Gemmell/V)72 769 Q(icisano/Rizzo/Handle)-.66 E(y/Cro)-.165 E=0A=
111.856(wcroft Section)-.275 F 2.75(9. [P)2.75 F(age 18])-.165 E EP=0A=
%%Page: 19 19=0A=
%%BeginPageSetup=0A=
BP=0A=
%%EndPageSetup=0A=
/F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 77.081(-DRAFT Expires:)-1.012 F=0A=
(April 2002)2.75 E(October 2001)112.127 E=0A=
([8] Perrig, A., Canetti, R., Song, D., T)72 85 Q(yg)-.88 E(ar)-.055 E=0A=
2.75(,J)-.44 G(.D., "Ef)-2.75 E=0A=
(\214cient and Secure Source Authentication for)-.275 E=0A=
(Multicast", Netw)72 98 Q(ork and Distrib)-.11 E=0A=
(uted System Security Symposium, NDSS 2001, pp. 35-46,)-.22 E=0A=
(February 2001.)72 111 Q([9] Rizzo, L, and V)72 137 Q=0A=
(icisano, L., "Reliable Multicast Data Distrib)-.66 E=0A=
(ution protocol based on softw)-.22 E(are)-.11 E=0A=
(FEC techniques", Proceedings of the F)72 150 Q(ourth IEEES W)-.165 E=0A=
(orkshop on the Architecture and)-.88 E(Implementation of High Performa\=0A=
nce Communication Systems, HPCS'97, Chalkidiki Greece,)72 163 Q=0A=
(June 1997.)72 176 Q([10] Rizzo, L, "PGMCC: A TCP-friendly single-rate \=0A=
multicast congestion control scheme",)72 202 Q=0A=
(Proceedings of SIGCOMM 2000, Stockholm Sweden, August 2000.)72 215 Q=0A=
([11] V)72 241 Q(icisano, L., Rizzo, L., Cro)-.66 E=0A=
(wcroft, J., "TCP-lik)-.275 E 2.75(eC)-.11 G=0A=
(ongestion Control for Layered Multicast)-2.75 E(Data T)72 254 Q=0A=
(ransfer", IEEE Infocom '98, San Francisco, CA, Mar)-.385 E(.28-Apr)=0A=
-.605 E(.1 1998.)-.605 E/F1 11/Times-Bold@0 SF(10.)72 306 Q/F2 14=0A=
/Times-Bold@0 SF -.7(Au)5.5 G(thors' Addr).7 E(esses)-.252 E F0=0A=
(Michael Luby)80.25 322.6 Q(luby@digitalfountain.com)80.25 335.6 Q=0A=
(Digital F)80.25 348.6 Q(ountain)-.165 E(39141 Ci)80.25 361.6 Q=0A=
(vic Center Dri)-.275 E -.165(ve)-.275 G(Suite 300)80.25 374.6 Q=0A=
(Fremont, CA, USA, 94538)80.25 387.6 Q(Jim Gemmell)80.25 413.6 Q=0A=
(jgemmell@microsoft.com)80.25 426.6 Q(Microsoft Research)80.25 439.6 Q=0A=
(301 Ho)80.25 452.6 Q -.11(wa)-.275 G(rd St., #830).11 E=0A=
(San Francisco, CA, USA, 94105)80.25 465.6 Q(Lorenzo V)80.25 491.6 Q=0A=
(icisano)-.66 E(lorenzo@cisco.com)80.25 504.6 Q(cisco Systems, Inc.)=0A=
80.25 517.6 Q(170 W)80.25 530.6 Q(est T)-.88 E(asman Dr)-.88 E(.,)-.605=0A=
E(San Jose, CA, USA, 95134)80.25 543.6 Q(Luigi Rizzo)80.25 569.6 Q=0A=
(luigi@iet.unipi.it)80.25 582.6 Q -.44(AC)80.25 595.6 S(IRI/ICSI,).44 E=0A=
(1947 Center St, Berk)80.25 608.6 Q(ele)-.11 E 1.43 -.715(y, C)-.165 H=0A=
(A, USA, 94704).715 E(and)80.25 621.6 Q(Dip. Ing. dell'Informazione,)=0A=
80.25 634.6 Q(Uni)80.25 647.6 Q 1.43 -.715(v. d)-.275 H 2.75(iP).715 G=0A=
(isa)-2.75 E(via Diotisalvi 2, 56126 Pisa, Italy)80.25 660.6 Q=0A=
(Mark Handle)80.25 686.6 Q(y)-.165 E(mjh@aciri.or)80.25 699.6 Q(g)-.198=0A=
E -.44(AC)80.25 712.6 S(IRI,).44 E(1947 Center St,)80.25 725.6 Q=0A=
(Luby/Gemmell/V)72 769 Q(icisano/Rizzo/Handle)-.66 E(y/Cro)-.165 E=0A=
106.356(wcroft Section)-.275 F 2.75(10. [P)2.75 F(age 19])-.165 E EP=0A=
%%Page: 20 20=0A=
%%BeginPageSetup=0A=
BP=0A=
%%EndPageSetup=0A=
/F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 77.081(-DRAFT Expires:)-1.012 F=0A=
(April 2002)2.75 E(October 2001)112.127 E(Berk)80.25 85 Q(ele)-.11 E=0A=
1.43 -.715(y, C)-.165 H(A, USA, 94704).715 E(Jon Cro)80.25 111 Q(wcroft)=0A=
-.275 E(J.Cro)80.25 124 Q(wcroft@cs.ucl.ac.uk)-.275 E=0A=
(Department of Computer Science)80.25 137 Q(Uni)80.25 150 Q -.165(ve)=0A=
-.275 G(rsity Colle).165 E(ge London)-.165 E(Go)80.25 163 Q(wer Street,)=0A=
-.275 E(London WC1E 6BT)80.25 176 Q 2.75(,U)-.814 G(K)-2.75 E=0A=
(Luby/Gemmell/V)72 769 Q(icisano/Rizzo/Handle)-.66 E(y/Cro)-.165 E=0A=
106.356(wcroft Section)-.275 F 2.75(10. [P)2.75 F(age 20])-.165 E EP=0A=
%%Page: 21 21=0A=
%%BeginPageSetup=0A=
BP=0A=
%%EndPageSetup=0A=
/F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 77.081(-DRAFT Expires:)-1.012 F=0A=
(April 2002)2.75 E(October 2001)112.127 E/F1 11/Times-Bold@0 SF(11.)72=0A=
85 Q/F2 14/Times-Bold@0 SF(Full Copyright Statement)5.5 E F0(Cop)72=0A=
101.6 Q(yright \(C\) The Internet Society \(2001\).)-.11 E=0A=
(All Rights Reserv)5.5 E(ed.)-.165 E(This document and translations of \=0A=
it may be copied and furnished to others, and deri)72 118.2 Q -.275(va)=0A=
-.275 G(ti).275 E .33 -.165(ve w)-.275 H(orks).055 E=0A=
(that comment on or otherwise e)72 131.2 Q=0A=
(xplain it or assist in its implementation may be prepared, copied,)=0A=
-.165 E(published and distrib)72 144.2 Q=0A=
(uted, in whole or in part, without restriction of an)-.22 E 2.75(yk)=0A=
-.165 G(ind, pro)-2.75 E(vided that the)-.165 E(abo)72 157.2 Q .33 -.165=0A=
(ve c)-.165 H(op).165 E(yright notice and this paragraph are included o\=0A=
n all such copies and deri)-.11 E -.275(va)-.275 G(ti).275 E .33 -.165=0A=
(ve w)-.275 H(orks.).055 E(Ho)72 170.2 Q(we)-.275 E -.165(ve)-.275 G .88=0A=
-.44(r, t).165 H(his document itself may not be modi\214ed in an).44 E=0A=
2.75(yw)-.165 G(ay)-2.86 E 2.75(,s)-.715 G(uch as by remo)-2.75 E=0A=
(ving the)-.165 E(cop)72 183.2 Q(yright notice or references to the Int\=0A=
ernet Society or other Internet or)-.11 E -.055(ga)-.198 G(nizations, e)=0A=
.055 E(xcept as)-.165 E(needed for the purpose of de)72 196.2 Q -.165=0A=
(ve)-.275 G(loping Internet standards in which case the procedures for)=0A=
.165 E(cop)72 209.2 Q=0A=
(yrights de\214ned in the Internet languages other than English.)-.11 E=0A=
(The limited permissions granted abo)72 225.8 Q .33 -.165(ve a)-.165 H=0A=
(re perpetual and will not be re).165 E -.22(vo)-.275 G -.11(ke).22 G=0A=
2.75(db).11 G 2.75(yt)-2.75 G(he Internet)-2.75 E=0A=
(Society or its successors or assigns.)72 238.8 Q=0A=
(This document and the information contained herein is pro)72 255.4 Q=0A=
(vided on an "AS IS" basis and THE)-.165 E=0A=
(INTERNET SOCIETY AND THE INTERNET ENGINEERING T)72 268.4 Q=0A=
(ASK FORCE DISCLAIMS)-1.023 E(ALL W)72 281.4 Q=0A=
(ARRANTIES, EXPRESS OR IMPLIED, INCLUDING B)-1.32 E(UT not LIMITED T)=0A=
-.11 E 2.75(OA)-.198 G(NY)-2.75 E -1.32(WA)72 294.4 S(RRANTY THA)1.32 E=0A=
2.75(TT)-1.221 G(HE USE OF THE INFORMA)-2.75 E=0A=
(TION HEREIN WILL not INFRINGE ANY)-1.221 E(RIGHTS OR ANY IMPLIED W)72=0A=
307.4 Q(ARRANTIES OF MERCHANT)-1.32 E(ABILITY OR FITNESS FOR A)-1.023 E=0A=
-1.012(PA)72 320.4 S -.66(RT)1.012 G(ICULAR PURPOSE.").66 E=0A=
(Luby/Gemmell/V)72 769 Q(icisano/Rizzo/Handle)-.66 E(y/Cro)-.165 E=0A=
106.356(wcroft Section)-.275 F 2.75(11. [P)2.75 F(age 21])-.165 E EP=0A=
%%Page: 22 22=0A=
%%BeginPageSetup=0A=
BP=0A=
%%EndPageSetup=0A=
/F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 77.081(-DRAFT Expires:)-1.012 F=0A=
(April 2002)2.75 E(October 2001)112.127 E(Luby/Gemmell/V)72 769 Q=0A=
(icisano/Rizzo/Handle)-.66 E(y/Cro)-.165 E 106.356(wcroft Section)-.275=0A=
F 2.75(11. [P)2.75 F(age 22])-.165 E EP=0A=
%%Trailer=0A=
end=0A=
%%EOF=0A=
------=_NextPart_000_0005_01C157E0.AE079D70--
>From owner-rmt@listserv.lbl.gov Thu Oct 18 14:25:37 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f9ILMO704317;
Thu, 18 Oct 2001 14:22:24 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f9ILMNp04313
for <rmt@listserv.lbl.gov>; Thu, 18 Oct 2001 14:22:23 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f9ILMMW25087
for <rmt@listserv.lbl.gov>; Thu, 18 Oct 2001 14:22:22 -0700 (PDT)
Received: from mx.webfountain.com (mx.digitalfountain.com [209.219.233.39])
by SpamWall.lbl.gov (8.11.2/8.11.2) with SMTP id f9ILMKb25055
for <rmt@lbl.gov>; Thu, 18 Oct 2001 14:22:20 -0700 (PDT)
Received: (qmail 23806 invoked from network); 18 Oct 2001 21:22:13 -0000
Received: from mail.intranet (10.1.1.37)
by mx.digitalfountain.com with SMTP; 18 Oct 2001 21:22:13 -0000
Received: from bozz (dhcp-10-1-2-180.intranet [10.1.2.180])
by mail.intranet (8.9.3/8.9.3) with SMTP id OAA31456;
Thu, 18 Oct 2001 14:21:47 -0700
X-Authentication-Warning: mail.intranet: Host dhcp-10-1-2-180.intranet [10.1.2.180] claimed to be bozz
From: "Michael Luby" <luby@digitalfountain.com>
To: "Internet-Drafts@Ietf. Org" <internet-drafts@ietf.org>,
"Rmt@Lbl. Gov" <rmt@lbl.gov>
Cc: "Michael Luby" <luby@digitalfountain.com>
Subject: draft-ietf-rmt-pi-alc-03.txt
Date: Thu, 18 Oct 2001 14:27:11 -0700
Message-ID: <NEBBIAPCNKEDCLPNFBNCKEKKCHAA.luby@digitalfountain.com>
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="----=_NextPart_000_000A_01C157E0.F961EDC0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: owner-rmt@lbl.gov
Precedence: bulk
This is a multi-part message in MIME format.
------=_NextPart_000_000A_01C157E0.F961EDC0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Please post this draft on the IETF Internet Drafts archive. This is an
update of an existing WG draft (RMT).
This also serves as a last call before moving this towards RFC status.
Please send any comments or concerns to the RMT list by Monday, October 22.
Thanks, Mike Luby
------=_NextPart_000_000A_01C157E0.F961EDC0
Content-Type: text/plain;
name="draft-ietf-rmt-pi-alc-03.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
filename="draft-ietf-rmt-pi-alc-03.txt"
Internet Engineering Task Force RMT WG=0A=
INTERNET-DRAFT M.Luby/Digital Fountain=0A=
draft-ietf-rmt-pi-alc-03.txt J.Gemmell/Microsoft=0A=
L.Vicisano/Cisco=0A=
L.Rizzo/ACIRI and Univ. Pisa=0A=
J. Crowcroft/UCL=0A=
18 October 2001=0A=
Expires: April 2002=0A=
=0A=
=0A=
Asynchronous Layered Coding:=0A=
A massively scalable reliable content delivery protocol instantiation=0A=
=0A=
=0A=
=0A=
Status of this Document=0A=
=0A=
This document is an Internet-Draft and is in full conformance with all=0A=
provisions of Section 10 of RFC2026.=0A=
=0A=
Internet-Drafts are working documents of the Internet Engineering Task=0A=
Force (IETF), its areas, and its working groups. Note that other groups=0A=
may also distribute working documents as Internet-Drafts.=0A=
=0A=
Internet-Drafts are valid for a maximum of six months and may be=0A=
updated, replaced, or obsoleted by other documents at any time. It is=0A=
inappropriate to use Internet-Drafts as reference material or to cite=0A=
them other than as a "work in progress".=0A=
=0A=
The list of current Internet-Drafts can be accessed at=0A=
http://www.ietf.org/ietf/1id-abstracts.txt=0A=
=0A=
To view the list Internet-Draft Shadow Directories, see=0A=
http://www.ietf.org/shadow.html.=0A=
=0A=
This document is a product of the IETF RMT WG. Comments should be=0A=
addressed to the authors, or the WG's mailing list at rmt@lbl.gov.=0A=
=0A=
=0A=
Abstract=0A=
=0A=
=0A=
This document describes the Asynchronous Layered Coding=0A=
protocol, a massively scalable reliable content delivery=0A=
protocol, hereafter referred to as ALC. ALC can be used for=0A=
=0A=
=0A=
=0A=
Luby/Gemmell/Vicisano/Rizzo/Crowcroft [Page 1]=0A=
=0C=0A=
INTERNET-DRAFT Expires: April 2002 October 2001=0A=
=0A=
=0A=
multi-rate reliable delivery of content to large sets of=0A=
receivers. This specification of ALC uses version 0 of the=0A=
LCT building block specified in [4] augmented with a multi-=0A=
rate congestion control building block that is compliant with=0A=
RFC2357 such as one of the congestion control building blocks=0A=
described [6] and [1]. ALC achieves reliability based on FEC=0A=
codecs as generally described in [2], and in particular uses=0A=
the FEC building block described in [3].=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
Luby/Gemmell/Vicisano/Rizzo/Crowcroft [Page 2]=0A=
=0C=0A=
INTERNET-DRAFT Expires: April 2002 October 2001=0A=
=0A=
=0A=
Table of Contents=0A=
=0A=
=0A=
1. Introduction. . . . . . . . . . . . . . . . . . . . . . 4=0A=
1.1. Related Documents. . . . . . . . . . . . . . . . . . 5=0A=
1.2. Environmental Requirements and Considerations. . . . 6=0A=
2. General Architecture. . . . . . . . . . . . . . . . . . 7=0A=
2.1. Delivery service models. . . . . . . . . . . . . . . 7=0A=
2.2. Congestion Control . . . . . . . . . . . . . . . . . 8=0A=
3. Packet format used by the ALC protocol. . . . . . . . . 8=0A=
3.1. Specific packet format . . . . . . . . . . . . . . . 9=0A=
3.2. Packet header field definitions. . . . . . . . . . . 10=0A=
4. Procedures. . . . . . . . . . . . . . . . . . . . . . . 10=0A=
4.1. Sender Operation . . . . . . . . . . . . . . . . . . 10=0A=
4.2. Receiver Operation . . . . . . . . . . . . . . . . . 11=0A=
5. Security Considerations . . . . . . . . . . . . . . . . 11=0A=
6. IANA Considerations . . . . . . . . . . . . . . . . . . 11=0A=
7. Intellectual Property Issues. . . . . . . . . . . . . . 12=0A=
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . 12=0A=
9. References. . . . . . . . . . . . . . . . . . . . . . . 12=0A=
10. Authors' Addresses . . . . . . . . . . . . . . . . . . 13=0A=
11. Full Copyright Statement . . . . . . . . . . . . . . . 14=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
Luby/Gemmell/Vicisano/Rizzo/Crowcroft [Page 3]=0A=
=0C=0A=
INTERNET-DRAFT Expires: April 2002 October 2001=0A=
=0A=
=0A=
1. Introduction=0A=
=0A=
This document describes a massively scalable reliable content delivery=0A=
protocol, Asynchronous Layered Coding (ALC), for multi-rate reliable=0A=
content delivery. ALC is a protocol instantiation as defined in=0A=
RFC3048. This specification of ALC uses version 0 of the LCT building=0A=
block specified in [4]. Like the LCT building block, the ALC protocol is=0A=
primarily designed to be used with the IP multicast network service, but=0A=
may also be used with other basic underlying network services such as=0A=
unicast IP.=0A=
=0A=
All ALC packets in a session use the default LCT header to convey, among=0A=
others, session and layering information. ALC uses FEC codes to provide=0A=
reliability as generally described in [2], and in particular ALC uses=0A=
the FEC building block described in [3]. Thus, all packets in a session=0A=
contain an FEC payload ID in a format that is compliant with the FEC=0A=
building block. Overall, a packet includes the default LCT header,=0A=
followed by the FEC Payload ID, followed by the packet payload.=0A=
=0A=
Although ALC is a transport protocol, no IP protocol identifier is=0A=
reserved for it and this specification defines ALC as UDP payload, in=0A=
accordance with the RMT-WG guidelines. The ALC header hence follows an=0A=
UDP header in an IP packet. Future versions of this specification, or=0A=
companion documents may extend ALC to use the IP network layer service=0A=
directly. Note that this specification does not make any assumption on=0A=
the presence of UDP.=0A=
=0A=
A crucial point is that ALC strongly relies on FEC codecs in the sense=0A=
that there is no request for retransmission of individual packets from=0A=
receivers that miss packets in order to assure reliable reception of an=0A=
object, and the packets and their rate of transmission out of the sender=0A=
can be independent of the number and the individual reception=0A=
experiences of the receivers. In some delivery service models it is=0A=
appropriate that receivers send out of band messages to the sender to=0A=
provide guaranteed delivery of content. For example, in a push reliable=0A=
delivery model receivers may send messages to a sender to continue the=0A=
session if receivers have not yet received enough packets to recover the=0A=
content or to terminate the session when receivers have received enough=0A=
packets to recover the content. To be able to track usage of the=0A=
system, receivers may also send messages out of band to the sender that=0A=
contain statistics on their reception experience. ALC, however, does not=0A=
require nor specify such messages, with the aim of avoiding unnecessary=0A=
limitation to the scalability of the basic ALC protocol.=0A=
=0A=
The LCT building block provides support for congestion control, and the=0A=
ALC protocol uses this support. In particular, to take full advantage=0A=
of the scalability features of ALC, the congestion control building=0A=
block used by ALC must be a multi-rate congestion control scheme that=0A=
=0A=
=0A=
=0A=
Luby/Gemmell/Vicisano/Rizzo/Crowcroft Section 1. [Page 4]=0A=
=0C=0A=
INTERNET-DRAFT Expires: April 2002 October 2001=0A=
=0A=
=0A=
requires no receiver feedback to the sender and must use the Congestion=0A=
Control Information field within the LCT header to convey packet by=0A=
packet congestion control information to receivers. Possible congestion=0A=
control building blocks that could be used with ALC are described in [6]=0A=
and [1]. A sender sends packets in the session to several LCT channels=0A=
at potentially different rates. Then, individual receivers can adjust=0A=
their reception rate within a session by adjusting which set of LCT=0A=
channels they are joined to at each point in time depending on the=0A=
available bandwidth between the receiver and the sender, but independent=0A=
of other receivers.=0A=
=0A=
Receivers may join and leave a session asynchronously at their=0A=
discretion.=0A=
=0A=
Note also that the congestion control building block used by ALC must=0A=
conform with RFC2357.=0A=
=0A=
ALC has the following properties when multicast is used to deliver=0A=
packets:=0A=
=0A=
=0A=
o To each receiver, it appears as if though there is a dedicated session=0A=
from the sender to the receiver, where the reception rate adjusts to=0A=
congestion along the path from sender to receiver.=0A=
=0A=
o To the sender, there is no difference in load or outgoing rate if one=0A=
receiver is joined to the session or a million (or any number of)=0A=
receivers are joined to the session, independent of when the receivers=0A=
join and leave.=0A=
=0A=
o On each link in the network, the packet traffic from the session and=0A=
its reaction to competing traffic is the same whether there is one=0A=
receiver or a million receivers beyond the link.=0A=
=0A=
Thus, ALC provides a massively scalable content delivery system that=0A=
is network friendly.=0A=
=0A=
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=0A=
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this=0A=
document are to be interpreted as described in RFC2119.=0A=
=0A=
=0A=
1.1. Related Documents=0A=
=0A=
This specification of ALC must use version 0 of the LCT building block=0A=
as specified in [4]. A more in-depth description of the use of FEC=0A=
codecs in reliable content delivery protocols is given in [2]. All=0A=
packets in a session must contain an FEC Payload ID in a format that is=0A=
=0A=
=0A=
=0A=
Luby/Gemmell/Vicisano/Rizzo/Crowcroft Section 1.1. [Page 5]=0A=
=0C=0A=
INTERNET-DRAFT Expires: April 2002 October 2001=0A=
=0A=
=0A=
compliant with the FEC building block described in [3]. Implementors of=0A=
ALC must also implement a multi-rate feedback-free congestion control=0A=
building block that is in accordance to RFC2357, where the congestion=0A=
control is over the entire session. Some possible schemes are specified=0A=
in [6] and [1]. Congestion control must be integrated into ALC through=0A=
the support provided in the LCT building block.=0A=
=0A=
It is recommended that ALC implementors use some packet authentication=0A=
scheme to protect the protocol from attacks. An example of a possibly=0A=
suitable scheme is described in [5]. Packet authentication in ALC, if=0A=
used, is to be integrated through the support provided in the LCT=0A=
building block.=0A=
=0A=
=0A=
1.2. Environmental Requirements and Considerations=0A=
=0A=
ALC is intended for mult-rate congestion controlled delivery of objects,=0A=
i.e., reliable content delivery.=0A=
=0A=
This specification defines ALC as payload of the UDP transport protocol=0A=
(RFC768).=0A=
=0A=
All of the environmental requirements and considerations that apply to=0A=
the LCT building block and to the FEC building block also apply to ALC.=0A=
=0A=
In particular, LCT requires the ability by receivers to uniquely=0A=
identify and demultiplex packets associated with an LCT session, and ALC=0A=
inherits this requirement. To this purpose, a Transport Session=0A=
Identifier (TSI) must be associated with each session. The TSI is scoped=0A=
by the IP address of the sender, and the IP address of the sender=0A=
together with the TSI must uniquely identify the session. It is=0A=
recommended that the TSI field in the LCT header is used to convey the=0A=
ALC TSI. If the TSI is not present in the LCT header, then 16-bit UDP=0A=
source port is used as TSI.=0A=
=0A=
If Generic Router Assist (GRA) is being used then additional=0A=
dependencies may be introduced by GRA on the TSI field. Generic Router=0A=
Assist is a current topic of discussion within the RMT working group.=0A=
If a TSI value appears more than once in a packet then all occurrences=0A=
of the value must be equal.=0A=
=0A=
If, in future specification, there is no underlying TSI provided by the=0A=
network, transport or any other layer, then the use of the TSI in the=0A=
LCT header must be mandatory.=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
Luby/Gemmell/Vicisano/Rizzo/Crowcroft Section 1.2. [Page 6]=0A=
=0C=0A=
INTERNET-DRAFT Expires: April 2002 October 2001=0A=
=0A=
=0A=
2. General Architecture=0A=
=0A=
ALC protocol uses the FEC codecs in the form described in [3] combined=0A=
with the LCT building block as described in [4]. Thus, the terminology=0A=
used in the description of the LCT building block and the FEC building=0A=
block are inherited by the ALC protocol and this terminology is used=0A=
below. In particular, the definition of a session for the ALC protocol=0A=
is the same as it is for the LCT building block.=0A=
=0A=
There is a one-to-one mapping between ALC sessions and LCT sessions.=0A=
=0A=
An ALC packet consists of the default LCT header, followed by the FEC=0A=
Payload ID, followed by the packet payload. The packet payload is as=0A=
described in [3]. If Generic Router Assist (GRA) is being used, then=0A=
additional constraints may be introduced on the LCT header.=0A=
=0A=
The ALC header immediately follows a UDP header.=0A=
=0A=
The out of band information used by the ALC protocol consists of all the=0A=
out of band information required for both the LCT building block and for=0A=
the FEC building block. The possible means for acquiring this out of=0A=
band information is the same as for the LCT building block and the FEC=0A=
building block, and in particular is outside the scope of the ALC=0A=
protocol.=0A=
=0A=
=0A=
2.1. Delivery service models=0A=
=0A=
ALC can support several different delivery service models. Two examples=0A=
are briefly described here.=0A=
=0A=
=0A=
Push service model.=0A=
=0A=
One way a push service model can be used for reliable content delivery=0A=
is to deliver a series of objects. For example, a receiver could join=0A=
the session and dynamically adapt the number of LCT channels the=0A=
receiver is joined to until enough packets have been received to=0A=
reconstruct an object. After reconstructing the object the receiver may=0A=
stay in the session and wait for the transmission of the next object.=0A=
=0A=
The push model is particularly attractive in satellite networks and=0A=
wireless networks. In these cases, a session may consist of one fixed=0A=
rate LCT channel.=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
Luby/Gemmell/Vicisano/Rizzo/Crowcroft Section 2.1. [Page 7]=0A=
=0C=0A=
INTERNET-DRAFT Expires: April 2002 October 2001=0A=
=0A=
=0A=
On-demand content delivery model.=0A=
=0A=
For an on-demand content delivery service model, senders typically=0A=
transmit for some given time period selected to be long enough to allow=0A=
all the intended receivers to join the session and recover a single=0A=
object. For example a popular software update might be transmitted=0A=
using ALC for several days, even though a receiver may be able to=0A=
complete the download in one hour total of connection time, perhaps=0A=
spread over several intervals of time.=0A=
=0A=
In this case the receivers join the session at any point in time when it=0A=
is active and dynamically adapt the number of LCT channels they=0A=
subscribe to according to the available bandwidth using a multi-rate=0A=
congestion control building block. Receivers leave the session when they=0A=
have received enough packets to recover the object.=0A=
=0A=
=0A=
Other service models.=0A=
=0A=
=0A=
There may be other delivery service models that can be supported by ALC.=0A=
The description of the potential applications, the appropriate delivery=0A=
service model, and the additional mechanisms to support such=0A=
functionalities when combined with ALC is beyond the scope of this=0A=
document.=0A=
=0A=
=0A=
2.2. Congestion Control=0A=
=0A=
A multi-rate congestion control building block that is feedback-free,=0A=
that is suitable for reliable content delivery, and that conforms to=0A=
RFC2357 is to be used by ALC. An example of such a congestion control=0A=
building block is described in [6] and [1]. While the general behavior=0A=
of the congestion control building block is to reduce transmission rate=0A=
in the presence of congestion and gradually increase the rate in the=0A=
absence of congestion, the actual dynamic behavior (e.g. response to=0A=
single losses) can vary.=0A=
=0A=
The congestion control building block must use the Congestion Control=0A=
Information field carried in the LCT header of each packet. Congestion=0A=
control must be applied to all packets within a session independently of=0A=
which information about which object is carried in each packet.=0A=
=0A=
=0A=
3. Packet format used by the ALC protocol=0A=
=0A=
The packet format used by the ALC protocol is the UDP header followed by=0A=
the default LCT header followed by the FEC Payload ID followed by the=0A=
=0A=
=0A=
=0A=
Luby/Gemmell/Vicisano/Rizzo/Crowcroft Section 3. [Page 8]=0A=
=0C=0A=
INTERNET-DRAFT Expires: April 2002 October 2001=0A=
=0A=
=0A=
packet payload. The packet payload is as described in [3], i.e., it=0A=
contains encoding information about the object. If Generic Router=0A=
Assist (GRA) is being used, then additional information may be required=0A=
in the packet headers, and an additional specification may be needed.=0A=
=0A=
The version number of ALC specified in this document is 0. This=0A=
coincides with version 0 of the LCT building block [4] used in this=0A=
specification. The LCT version number field should be interpreted as=0A=
the ALC version number field.=0A=
=0A=
Some instances of sessions may require the generation of feedback from=0A=
the receivers to the sender. However, the mechanism for doing this is=0A=
outside the scope of ALC.=0A=
=0A=
=0A=
3.1. Specific packet format=0A=
=0A=
The packet format used for ALC protocol is depicted in Figure 1.=0A=
=0A=
=0A=
0 1 2 3=0A=
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=0A=
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A=
| Default LCT header |=0A=
| |=0A=
=
+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=
=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=0A=
| FEC Payload ID |=0A=
| |=0A=
=
+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=
=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=0A=
| ALC payload |=0A=
| |=0A=
| |=0A=
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A=
=0A=
=0A=
Figure 1 - Packet format for the ALC protocol=0A=
=0A=
The length of the Default LCT header is explicitly encoded in the=0A=
header itself (see=0A=
[4]) , while the length of the FEC Payload ID is implicitly defined by =
the=0A=
FEC Encoding ID (see=0A=
[3]) , that is communicated out of band and, possibly, through the =
Codepoint=0A=
field in the LCT header. The rest of the datagram is made of ALC=0A=
payload.=0A=
=0A=
In some special cases an ALC source may need to produce ALC packets=0A=
that do not contain any payload. This may be required, for example, to=0A=
signal the end of a session or to convey congestion control=0A=
=0A=
=0A=
=0A=
Luby/Gemmell/Vicisano/Rizzo/Crowcroft Section 3.1. [Page 9]=0A=
=0C=0A=
INTERNET-DRAFT Expires: April 2002 October 2001=0A=
=0A=
=0A=
information. These data-less packets do not contain the FEC Payload ID=0A=
either, but only the LCT header fields. The total datagram length,=0A=
conveyed by outer protocol headers (e.g. the IP or UDP header),=0A=
enables receivers to detect the absence of the ALC payload and FEC=0A=
Payload ID.=0A=
=0A=
=0A=
3.2. Packet header field definitions=0A=
=0A=
The description of the fields and their functions within the default LCT=0A=
header can be found in [4]. The information that needs to be=0A=
communicated out of band for the LCT building block and the possible=0A=
mechanisms for achieving this are described in [4].=0A=
=0A=
The description of the fields and their functions within the FEC Payload=0A=
ID can be found in [3]. The information that needs to be communicated=0A=
out of band for the FEC codecs and the possible mechanisms for achieving=0A=
this are described in [3]. The mechanisms for communicating the out of=0A=
band information needed for the LCT building block, including the=0A=
mapping between the Codepoint field values in the default LCT header and=0A=
the interpretations of the values, may be the same as those used for=0A=
communicating the out of band information needed for the FEC building=0A=
block, with the exception that portions of the information needed for=0A=
FEC building blocks may be communicated through the use of the Codepoint=0A=
field in the default LCT header.=0A=
=0A=
Multiple objects may be transmitted in the same session. The Transport=0A=
Object Identifier (TOI) field in the LCT header must be used to identify=0A=
the different objects, and the FEC Payload ID and the packet payload=0A=
must correspond to the object identified by the TOI in the LCT header.=0A=
=0A=
If the FEC encoding scheme varies among different objects transmitted in=0A=
the same session, the Codepoint field in the LCT header must be used to=0A=
convey, in each packet, the association between the ALC payload and the=0A=
tuple <FEC Encoding ID, FEC Encoding Name>. This allows the receiver to=0A=
parse the FEC Payload ID field and to select the appropriate decoder=0A=
class without having to interpret the TOI field.=0A=
=0A=
=0A=
4. Procedures=0A=
=0A=
=0A=
4.1. Sender Operation=0A=
=0A=
The sender operation when using the ALC protocol includes all the points=0A=
made about the sender operation when using the LCT building block as=0A=
described in [4], and the FEC building block as described in [3]. The=0A=
following description highlights some of the additional considerations=0A=
=0A=
=0A=
=0A=
Luby/Gemmell/Vicisano/Rizzo/Crowcroft Section 4.1. [Page 10]=0A=
=0C=0A=
INTERNET-DRAFT Expires: April 2002 October 2001=0A=
=0A=
=0A=
to be taken into account with respect to the ALC protocol.=0A=
=0A=
A sender using the ALC protocol must make available all applicable=0A=
information regarding the session. This information includes:=0A=
=0A=
o Any information needed by the LCT building block;=0A=
=0A=
o The congestion control building block being used within the LCT=0A=
building block;=0A=
=0A=
o The mapping between values of the Codepoint field in the default LCT=0A=
header and interpretations of these values;=0A=
=0A=
o Any information needed for the FEC building block, including the FEC=0A=
Object Transmission Information;=0A=
=0A=
o If used, the packet authentication scheme being used within the LCT=0A=
building block, and all relevant information which is necessary for=0A=
packet authentication purposes.=0A=
=0A=
=0A=
4.2. Receiver Operation=0A=
=0A=
The receiver operation when using the ALC protocol includes all the=0A=
points made about the receiver operation that pertain to reliable=0A=
content delivery when using the LCT building block as described in [4],=0A=
and that pertain to using the FEC building block as described in [3].=0A=
The following description highlights some of the additional=0A=
considerations to be taken into account with respect to the ALC=0A=
protocol.=0A=
=0A=
When a receiver receives a packet, the receiver must process the default=0A=
LCT header (excluding the Codepoint field) as described in [4] before=0A=
processing any other fields of the packet.=0A=
=0A=
=0A=
5. Security Considerations=0A=
=0A=
The same security consideration that apply to the LCT building block and=0A=
to the FEC building block also apply to the ALC protocol. In addition,=0A=
any security considerations that apply to the congestion control=0A=
building block used by the ALC protocol within the LCT building block=0A=
also apply.=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
Luby/Gemmell/Vicisano/Rizzo/Crowcroft Section 5. [Page 11]=0A=
=0C=0A=
INTERNET-DRAFT Expires: April 2002 October 2001=0A=
=0A=
=0A=
6. IANA Considerations=0A=
=0A=
No information in this specification is directly subject to IANA=0A=
registration. However, building blocks components used by the ALC=0A=
protocol may introduce additional IANA considerations. In particular,=0A=
the FEC building block used by the ALC protocol does require IANA=0A=
registration of the FEC codecs used.=0A=
=0A=
=0A=
7. Intellectual Property Issues=0A=
=0A=
=0A=
No specific reliability building block or congestion control building=0A=
block is specified or referenced as mandatory in this document.=0A=
=0A=
ALC may be used with congestion control building blocks and other=0A=
building blocks which contain proprietary elements, or have pending or=0A=
granted patents.=0A=
=0A=
=0A=
8. Acknowledgments=0A=
=0A=
=0A=
Thanks to Vincent Roca and Justin Chapweske for their detailed comments=0A=
on this draft.=0A=
=0A=
=0A=
9. References=0A=
=0A=
[1] Byers, J.W., Frumin, M., Horn, G., Luby, M., Mitzenmacher, M.,=0A=
Roetter, A., and Shaver, W., "FLID-DL: Congestion Control for Layered=0A=
Multicast", Proceedings of Second International Workshop on Networked=0A=
Group Communications (NGC 2000), Palo Alto, CA, November 2000.=0A=
=0A=
[2] Luby, M., Gemmell, Vicisano, L., J., Rizzo, L., Handley, M.,=0A=
Crowcroft, J., "The use of Forward Error Correction in Reliable=0A=
Multicast", Internet Draft draft-ietf-rmt-info-fec-01.txt, October 2001,=0A=
a work in progress.=0A=
=0A=
[3] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., Handley, M.,=0A=
Crowcroft, J., "RMT BB Forward Error Correction Codes", Internet Draft=0A=
draft-ietf-rmt-bb-fec-04.txt, October 2001.=0A=
=0A=
[4] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., Handley, M.,=0A=
Crowcroft, J., "Layered Coding Transport: A massively scalable content=0A=
delivery transport", Internet Draft draft-ietf-rmt-bb-lct-02.txt,=0A=
October 2001.=0A=
=0A=
=0A=
=0A=
=0A=
Luby/Gemmell/Vicisano/Rizzo/Crowcroft Section 9. [Page 12]=0A=
=0C=0A=
INTERNET-DRAFT Expires: April 2002 October 2001=0A=
=0A=
=0A=
[5] Perrig, A., Canetti, R., Song, D., Tygar, J.D., "Efficient and=0A=
Secure Source Authentication for Multicast", Network and Distributed=0A=
System Security Symposium, NDSS 2001, pp. 35-46, February 2001.=0A=
=0A=
[6] Vicisano, L., Rizzo, L., Crowcroft, J., "TCP-like Congestion Control=0A=
for Layered Multicast Data Transfer", IEEE Infocom '98, San Francisco,=0A=
CA, Mar.28-Apr.1 1998.=0A=
=0A=
=0A=
=0A=
10. Authors' Addresses=0A=
=0A=
Michael Luby=0A=
luby@digitalfountain.com=0A=
Digital Fountain=0A=
39141 Civic Center Drive=0A=
Suite 300=0A=
Fremont, CA, USA, 94538=0A=
=0A=
Jim Gemmell=0A=
jgemmell@microsoft.com=0A=
Microsoft Research=0A=
301 Howard St., #830=0A=
San Francisco, CA, USA, 94105=0A=
=0A=
Lorenzo Vicisano=0A=
lorenzo@cisco.com=0A=
cisco Systems, Inc.=0A=
170 West Tasman Dr.,=0A=
San Jose, CA, USA, 95134=0A=
=0A=
Luigi Rizzo=0A=
luigi@iet.unipi.it=0A=
Dip. Ing. dell'Informazione,=0A=
Univ. di Pisa=0A=
via Diotisalvi 2, 56126 Pisa, Italy=0A=
=0A=
Jon Crowcroft=0A=
J.Crowcroft@cs.ucl.ac.uk=0A=
Department of Computer Science=0A=
University College London=0A=
Gower Street,=0A=
London WC1E 6BT, UK=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
Luby/Gemmell/Vicisano/Rizzo/Crowcroft Section 10. [Page 13]=0A=
=0C=0A=
INTERNET-DRAFT Expires: April 2002 October 2001=0A=
=0A=
=0A=
11. Full Copyright Statement=0A=
=0A=
Copyright (C) The Internet Society (2001). All Rights Reserved.=0A=
=0A=
This document and translations of it may be copied and furnished to=0A=
others, and derivative works that comment on or otherwise explain it or=0A=
assist in its implementation may be prepared, copied, published and=0A=
distributed, in whole or in part, without restriction of any kind,=0A=
provided that the above copyright notice and this paragraph are included=0A=
on all such copies and derivative works. However, this document itself=0A=
may not be modified in any way, such as by removing the copyright notice=0A=
or references to the Internet Society or other Internet organizations,=0A=
except as needed for the purpose of developing Internet standards in=0A=
which case the procedures for copyrights defined in the Internet=0A=
languages other than English.=0A=
=0A=
The limited permissions granted above are perpetual and will not be=0A=
revoked by the Internet Society or its successors or assigns.=0A=
=0A=
This document and the information contained herein is provided on an "AS=0A=
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK=0A=
FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT=0A=
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT=0A=
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR=0A=
FITNESS FOR A PARTICULAR PURPOSE."=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
Luby/Gemmell/Vicisano/Rizzo/Crowcroft Section 11. [Page 14]=0A=
=0C=0A=
INTERNET-DRAFT Expires: April 2002 October 2001=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
Luby/Gemmell/Vicisano/Rizzo/Crowcroft Section 11. [Page 15]=0A=
------=_NextPart_000_000A_01C157E0.F961EDC0
Content-Type: application/postscript;
name="draft-ietf-rmt-pi-alc-03.ps"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
filename="draft-ietf-rmt-pi-alc-03.ps"
%!PS-Adobe-3.0=0A=
%%Creator: groff version 1.15=0A=
%%CreationDate: Thu Oct 18 10:45:53 2001=0A=
%%DocumentNeededResources: font Courier-Bold=0A=
%%+ font Times-Bold=0A=
%%+ font Times-Roman=0A=
%%+ font Courier=0A=
%%DocumentSuppliedResources: procset grops 1.15 1=0A=
%%Pages: 12=0A=
%%PageOrder: Ascend=0A=
%%Orientation: Portrait=0A=
%%EndComments=0A=
%%BeginProlog=0A=
%%BeginResource: procset grops 1.15 1=0A=
/setpacking where{=0A=
pop=0A=
currentpacking=0A=
true setpacking=0A=
}if=0A=
/grops 120 dict dup begin=0A=
/SC 32 def=0A=
/A/show load def=0A=
/B{0 SC 3 -1 roll widthshow}bind def=0A=
/C{0 exch ashow}bind def=0A=
/D{0 exch 0 SC 5 2 roll awidthshow}bind def=0A=
/E{0 rmoveto show}bind def=0A=
/F{0 rmoveto 0 SC 3 -1 roll widthshow}bind def=0A=
/G{0 rmoveto 0 exch ashow}bind def=0A=
/H{0 rmoveto 0 exch 0 SC 5 2 roll awidthshow}bind def=0A=
/I{0 exch rmoveto show}bind def=0A=
/J{0 exch rmoveto 0 SC 3 -1 roll widthshow}bind def=0A=
/K{0 exch rmoveto 0 exch ashow}bind def=0A=
/L{0 exch rmoveto 0 exch 0 SC 5 2 roll awidthshow}bind def=0A=
/M{rmoveto show}bind def=0A=
/N{rmoveto 0 SC 3 -1 roll widthshow}bind def=0A=
/O{rmoveto 0 exch ashow}bind def=0A=
/P{rmoveto 0 exch 0 SC 5 2 roll awidthshow}bind def=0A=
/Q{moveto show}bind def=0A=
/R{moveto 0 SC 3 -1 roll widthshow}bind def=0A=
/S{moveto 0 exch ashow}bind def=0A=
/T{moveto 0 exch 0 SC 5 2 roll awidthshow}bind def=0A=
/SF{=0A=
findfont exch=0A=
[exch dup 0 exch 0 exch neg 0 0]makefont=0A=
dup setfont=0A=
[exch/setfont cvx]cvx bind def=0A=
}bind def=0A=
/MF{=0A=
findfont=0A=
[5 2 roll=0A=
0 3 1 roll=0A=
neg 0 0]makefont=0A=
dup setfont=0A=
[exch/setfont cvx]cvx bind def=0A=
}bind def=0A=
/level0 0 def=0A=
/RES 0 def=0A=
/PL 0 def=0A=
/LS 0 def=0A=
/MANUAL{=0A=
statusdict begin/manualfeed true store end=0A=
}bind def=0A=
/PLG{=0A=
gsave newpath clippath pathbbox grestore=0A=
exch pop add exch pop=0A=
}bind def=0A=
/BP{=0A=
/level0 save def=0A=
1 setlinecap=0A=
1 setlinejoin=0A=
72 RES div dup scale=0A=
LS{=0A=
90 rotate=0A=
}{=0A=
0 PL translate=0A=
}ifelse=0A=
1 -1 scale=0A=
}bind def=0A=
/EP{=0A=
level0 restore=0A=
showpage=0A=
}bind def=0A=
/DA{=0A=
newpath arcn stroke=0A=
}bind def=0A=
/SN{=0A=
transform=0A=
.25 sub exch .25 sub exch=0A=
round .25 add exch round .25 add exch=0A=
itransform=0A=
}bind def=0A=
/DL{=0A=
SN=0A=
moveto=0A=
SN=0A=
lineto stroke=0A=
}bind def=0A=
/DC{=0A=
newpath 0 360 arc closepath=0A=
}bind def=0A=
/TM matrix def=0A=
/DE{=0A=
TM currentmatrix pop=0A=
translate scale newpath 0 0 .5 0 360 arc closepath=0A=
TM setmatrix=0A=
}bind def=0A=
/RC/rcurveto load def=0A=
/RL/rlineto load def=0A=
/ST/stroke load def=0A=
/MT/moveto load def=0A=
/CL/closepath load def=0A=
/FL{=0A=
currentgray exch setgray fill setgray=0A=
}bind def=0A=
/BL/fill load def=0A=
/LW/setlinewidth load def=0A=
/RE{=0A=
findfont=0A=
dup maxlength 1 index/FontName known not{1 add}if dict begin=0A=
{=0A=
1 index/FID ne{def}{pop pop}ifelse=0A=
}forall=0A=
/Encoding exch def=0A=
dup/FontName exch def=0A=
currentdict end definefont pop=0A=
}bind def=0A=
/DEFS 0 def=0A=
/EBEGIN{=0A=
moveto=0A=
DEFS begin=0A=
}bind def=0A=
/EEND/end load def=0A=
/CNT 0 def=0A=
/level1 0 def=0A=
/PBEGIN{=0A=
/level1 save def=0A=
translate=0A=
div 3 1 roll div exch scale=0A=
neg exch neg exch translate=0A=
0 setgray=0A=
0 setlinecap=0A=
1 setlinewidth=0A=
0 setlinejoin=0A=
10 setmiterlimit=0A=
[]0 setdash=0A=
/setstrokeadjust where{=0A=
pop=0A=
false setstrokeadjust=0A=
}if=0A=
/setoverprint where{=0A=
pop=0A=
false setoverprint=0A=
}if=0A=
newpath=0A=
/CNT countdictstack def=0A=
userdict begin=0A=
/showpage{}def=0A=
}bind def=0A=
/PEND{=0A=
clear=0A=
countdictstack CNT sub{end}repeat=0A=
level1 restore=0A=
}bind def=0A=
end def=0A=
/setpacking where{=0A=
pop=0A=
setpacking=0A=
}if=0A=
%%EndResource=0A=
%%IncludeResource: font Courier-Bold=0A=
%%IncludeResource: font Times-Bold=0A=
%%IncludeResource: font Times-Roman=0A=
%%IncludeResource: font Courier=0A=
grops begin/DEFS 1 dict def DEFS begin/u{.001 mul}bind def end/RES 72=0A=
def/PL 792 def/LS false def/ENC0[/asciicircum/asciitilde/Scaron/Zcaron=0A=
/scaron/zcaron/Ydieresis/trademark/quotesingle/.notdef/.notdef/.notdef=0A=
/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef=0A=
/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef=0A=
/.notdef/.notdef/space/exclam/quotedbl/numbersign/dollar/percent=0A=
/ampersand/quoteright/parenleft/parenright/asterisk/plus/comma/hyphen=0A=
/period/slash/zero/one/two/three/four/five/six/seven/eight/nine/colon=0A=
/semicolon/less/equal/greater/question/at/A/B/C/D/E/F/G/H/I/J/K/L/M/N/O=0A=
/P/Q/R/S/T/U/V/W/X/Y/Z/bracketleft/backslash/bracketright/circumflex=0A=
/underscore/quoteleft/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y=0A=
/z/braceleft/bar/braceright/tilde/.notdef/quotesinglbase/guillemotleft=0A=
/guillemotright/bullet/florin/fraction/perthousand/dagger/daggerdbl=0A=
/endash/emdash/ff/fi/fl/ffi/ffl/dotlessi/dotlessj/grave/hungarumlaut=0A=
/dotaccent/breve/caron/ring/ogonek/quotedblleft/quotedblright/oe/lslash=0A=
/quotedblbase/OE/Lslash/.notdef/exclamdown/cent/sterling/currency/yen=0A=
/brokenbar/section/dieresis/copyright/ordfeminine/guilsinglleft=0A=
/logicalnot/minus/registered/macron/degree/plusminus/twosuperior=0A=
/threesuperior/acute/mu/paragraph/periodcentered/cedilla/onesuperior=0A=
/ordmasculine/guilsinglright/onequarter/onehalf/threequarters=0A=
/questiondown/Agrave/Aacute/Acircumflex/Atilde/Adieresis/Aring/AE=0A=
/Ccedilla/Egrave/Eacute/Ecircumflex/Edieresis/Igrave/Iacute/Icircumflex=0A=
/Idieresis/Eth/Ntilde/Ograve/Oacute/Ocircumflex/Otilde/Odieresis=0A=
/multiply/Oslash/Ugrave/Uacute/Ucircumflex/Udieresis/Yacute/Thorn=0A=
/germandbls/agrave/aacute/acircumflex/atilde/adieresis/aring/ae/ccedilla=0A=
/egrave/eacute/ecircumflex/edieresis/igrave/iacute/icircumflex/idieresis=0A=
/eth/ntilde/ograve/oacute/ocircumflex/otilde/odieresis/divide/oslash=0A=
/ugrave/uacute/ucircumflex/udieresis/yacute/thorn/ydieresis]def=0A=
/Courier@0 ENC0/Courier RE/Times-Roman@0 ENC0/Times-Roman RE=0A=
/Times-Bold@0 ENC0/Times-Bold RE/Courier-Bold@0 ENC0/Courier-Bold RE=0A=
%%EndProlog=0A=
%%Page: 1 1=0A=
%%BeginPageSetup=0A=
BP=0A=
%%EndPageSetup=0A=
/F0 10/Courier-Bold@0 SF(Internet Engineering Task Force)72 85 Q(RMT WG)=0A=
209.999 E 203.999(INTERNET-DRAFT M.Luby/Digital)72 98 R(Fountain)6 E=0A=
149.999(draft-ietf-rmt-pi-alc-03.ps J.Gemmell/Microsoft)72 111 R=0A=
(L.Vicisano/Cisco)407.999 124 Q(L.Rizzo/ACIRI and Univ. Pisa)335.999 137=0A=
Q(J. Crowcroft/UCL)407.999 150 Q(18 October 2001)413.999 163 Q=0A=
(Expires: April 2002)389.999 176 Q/F1 14/Times-Bold@0 SF(Asynchr)193.038=0A=
201 Q(onous Lay)-.252 E(er)-.14 E(ed Coding:)-.252 E 3.5(Am)87.289 214 S=0A=
(assi)-3.5 E -.14(ve)-.14 G(ly scalable r).14 E(eliable content deli)=0A=
-.252 E -.14(ve)-.14 G(ry pr).14 E(otocol instantiation)-.252 E/F2 11=0A=
/Times-Bold@0 SF(Status of this Document)72 259 Q/F3 11/Times-Roman@0 SF=0A=
(This document is an Internet-Draft and is in full conformance with all\=0A=
pro)72 275.6 Q(visions of Section 10 of)-.165 E(RFC2026.)72 288.6 Q=0A=
(Internet-Drafts are w)72 314.6 Q=0A=
(orking documents of the Internet Engineering T)-.11 E(ask F)-.88 E=0A=
(orce \(IETF\), its areas,)-.165 E(and its w)72 327.6 Q(orking groups.)=0A=
-.11 E(Note that other groups may also distrib)5.5 E(ute w)-.22 E=0A=
(orking documents as)-.11 E(Internet-Drafts.)72 340.6 Q=0A=
(Internet-Drafts are v)72 366.6 Q=0A=
(alid for a maximum of six months and may be updated, replaced, or)-.275=0A=
E(obsoleted by other documents at an)72 379.6 Q 2.75(yt)-.165 G 2.75=0A=
(ime. It)-2.75 F(is inappropriate to use Internet-Drafts as reference)=0A=
2.75 E(material or to cite them other than as a "w)72 392.6 Q=0A=
(ork in progress".)-.11 E=0A=
(The list of current Internet-Drafts can be accessed at http://www)72=0A=
418.6 Q(.ietf.or)-.715 E(g/ietf/1id-abstracts.txt)-.198 E 1.76 -.88=0A=
(To v)72 444.6 T(ie).88 E 2.75(wt)-.275 G(he list Internet-Draft Shado)=0A=
-2.75 E 2.75(wD)-.275 G(irectories, see http://www)-2.75 E(.ietf.or)=0A=
-.715 E(g/shado)-.198 E -.715(w.)-.275 G(html.).715 E=0A=
(This document is a product of the IETF RMT WG.)72 470.6 Q=0A=
(Comments should be addressed to the)5.5 E(authors, or the WG')72 483.6=0A=
Q 2.75(sm)-.605 G(ailing list at rmt@lbl.go)-2.75 E -.715(v.)-.165 G F2=0A=
(Abstract)267.534 515.6 Q F3(This document describes the Asynchronous L\=0A=
ayered Coding protocol, a massi)97 538.2 Q -.165(ve)-.275 G(ly).165 E=0A=
(scalable reliable content deli)97 551.2 Q -.165(ve)-.275 G=0A=
(ry protocol, hereafter referred to as ALC.).165 E(ALC can be)5.5 E=0A=
(used for multi-rate reliable deli)97 564.2 Q -.165(ve)-.275 G=0A=
(ry of content to lar).165 E(ge sets of recei)-.198 E -.165(ve)-.275 G=0A=
2.75(rs. This).165 F(speci\214cation of ALC uses v)97 577.2 Q=0A=
(ersion 0 of the LCT b)-.165 E(uilding block speci\214ed in [4])-.22 E=0A=
(augmented with a multi-rate congestion control b)97 590.2 Q=0A=
(uilding block that is compliant with)-.22 E=0A=
(RFC2357 such as one of the congestion control b)97 603.2 Q=0A=
(uilding blocks described [6] and [1].)-.22 E(ALC achie)97 616.2 Q -.165=0A=
(ve)-.275 G 2.75(sr).165 G=0A=
(eliability based on FEC codecs as generally described in [2], and in)=0A=
-2.75 E(particular uses the FEC b)97 629.2 Q=0A=
(uilding block described in [3].)-.22 E(Luby/Gemmell/V)72 769 Q=0A=
(icisano/Rizzo/Cro)-.66 E 207.017(wcroft [P)-.275 F(age 1])-.165 E EP=0A=
%%Page: 2 2=0A=
%%BeginPageSetup=0A=
BP=0A=
%%EndPageSetup=0A=
/F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 77.081(-DRAFT Expires:)-1.012 F=0A=
(April 2002)2.75 E(October 2001)112.127 E/F1 13/Times-Bold@0 SF -1.196=0A=
(Ta)239.126 85 S(ble of Contents)1.196 E/F2 10/Times-Roman@0 SF=0A=
(1. Introduction)97 123 Q F0 11(......................)3.56 G F2(3)11.5=0A=
E(1.1. Related Documents)107 135 Q F0 11(..................)11.9 G F2(4)=0A=
11.5 E(1.2. En)107 147 Q(vironmental Requirements and Considerations)-.4=0A=
E F0 11(..........)3.97 G F2(4)11.5 E(2. General Architecture)97 159 Q=0A=
F0 11(...................)10.12 G F2(5)11.5 E(2.1. Deli)107 171 Q -.15=0A=
(ve)-.25 G(ry service models).15 E F0 11(.................)7.45 G F2(5)=0A=
11.5 E(2.2. Congestion Control)107 183 Q F0 11(..................)11.88=0A=
G F2(6)11.5 E(3. P)97 195 Q(ack)-.15 E=0A=
(et format used by the ALC protocol)-.1 E F0 11(..............)1.05 G F2=0A=
(6)11.5 E(3.1. Speci\214c pack)107 207 Q(et format)-.1 E F0 11=0A=
(..................).62 G F2(6)11.5 E(3.2. P)107 219 Q(ack)-.15 E=0A=
(et header \214eld de\214nitions)-.1 E F0 11(...............)11.18 G F2=0A=
(7)11.5 E(4. Procedures)97 231 Q F0 11(......................)8.57 G F2=0A=
(8)11.5 E(4.1. Sender Operation)107 243 Q F0 11(...................)6.49=0A=
G F2(8)11.5 E(4.2. Recei)107 255 Q -.15(ve)-.25 G 2.5(rO).15 G(peration)=0A=
-2.5 E F0 11(..................)12.87 G F2(8)11.5 E=0A=
(5. Security Considerations)97 267 Q F0 11(..................)12.17 G F2=0A=
(8)11.5 E(6. IAN)97 279 Q 2.5(AC)-.35 G(onsiderations)-2.5 E F0 11=0A=
(...................)7.11 G F2(9)11.5 E(7. Intellectual Property Issues)=0A=
97 291 Q F0 11(.................)12.88 G F2(9)11.5 E(8. Ackno)97 303 Q=0A=
(wledgments)-.25 E F0 11(....................)5.76 G F2(9)11.5 E=0A=
(9. References)97 315 Q F0 11(......................)8.58 G F2(9)11.5 E=0A=
(10. Authors' Addresses)97 327 Q F0 11(...................)10.1 G F2(10)=0A=
6.5 E(11. Full Cop)97 339 Q(yright Statement)-.1 E F0 11=0A=
(..................)1.42 G F2(11)6.5 E F0(Luby/Gemmell/V)72 769 Q=0A=
(icisano/Rizzo/Cro)-.66 E 207.017(wcroft [P)-.275 F(age 2])-.165 E EP=0A=
%%Page: 3 3=0A=
%%BeginPageSetup=0A=
BP=0A=
%%EndPageSetup=0A=
/F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 77.081(-DRAFT Expires:)-1.012 F=0A=
(April 2002)2.75 E(October 2001)112.127 E/F1 11/Times-Bold@0 SF(1.)72 85=0A=
Q/F2 14/Times-Bold@0 SF(Intr)5.5 E(oduction)-.252 E F0=0A=
(This document describes a massi)72 101.6 Q -.165(ve)-.275 G=0A=
(ly scalable reliable content deli).165 E -.165(ve)-.275 G=0A=
(ry protocol, Asynchronous).165 E=0A=
(Layered Coding \(ALC\), for multi-rate reliable content deli)72 114.6 Q=0A=
-.165(ve)-.275 G(ry).165 E 5.5(.A)-.715 G=0A=
(LC is a protocol instantiation)-5.5 E=0A=
(as de\214ned in RFC3048. This speci\214cation of ALC uses v)72 127.6 Q=0A=
(ersion 0 of the LCT b)-.165 E(uilding block)-.22 E=0A=
(speci\214ed in [4]. Lik)72 140.6 Q 2.75(et)-.11 G(he LCT b)-2.75 E=0A=
(uilding block, the ALC protocol is primarily designed to be used)-.22 E=0A=
(with the IP multicast netw)72 153.6 Q(ork service, b)-.11 E=0A=
(ut may also be used with other basic underlying netw)-.22 E(ork)-.11 E=0A=
(services such as unicast IP)72 166.6 Q(.)-1.221 E(All ALC pack)72 192.6=0A=
Q(ets in a session use the def)-.11 E(ault LCT header to con)-.11 E=0A=
-.165(vey)-.44 G 2.75(,a)-.55 G(mong others, session and)-2.75 E=0A=
(layering information.)72 205.6 Q(ALC uses FEC codes to pro)5.5 E=0A=
(vide reliability as generally described in [2],)-.165 E=0A=
(and in particular ALC uses the FEC b)72 218.6 Q=0A=
(uilding block described in [3]. Thus, all pack)-.22 E(ets in a session)=0A=
-.11 E=0A=
(contain an FEC payload ID in a format that is compliant with the FEC b)=0A=
72 231.6 Q(uilding block.)-.22 E(Ov)5.5 E(erall, a)-.165 E(pack)72 244.6=0A=
Q(et includes the def)-.11 E(ault LCT header)-.11 E 2.75(,f)-.44 G(ollo)=0A=
-2.75 E(wed by the FEC P)-.275 E(ayload ID, follo)-.165 E=0A=
(wed by the pack)-.275 E(et)-.11 E(payload.)72 257.6 Q(Although ALC is \=0A=
a transport protocol, no IP protocol identi\214er is reserv)72 283.6 Q=0A=
(ed for it and this)-.165 E(speci\214cation de\214nes ALC as UDP payloa\=0A=
d, in accordance with the RMT)72 296.6 Q(-WG guidelines. The)-1.012 E=0A=
(ALC header hence follo)72 309.6 Q(ws an UDP header in an IP pack)-.275=0A=
E(et. Future v)-.11 E(ersions of this speci\214cation,)-.165 E=0A=
(or companion documents may e)72 322.6 Q(xtend ALC to use the IP netw)=0A=
-.165 E(ork layer service directly)-.11 E 2.75(.N)-.715 G(ote that)-2.75=0A=
E(this speci\214cation does not mak)72 335.6 Q 2.75(ea)-.11 G .33 -.165=0A=
(ny a)-2.75 H(ssumption on the presence of UDP).165 E(.)-1.221 E 2.75=0A=
(Ac)72 361.6 S(rucial point is that ALC strongly relies on FEC codecs i\=0A=
n the sense that there is no request for)-2.75 E(retransmission of indi)=0A=
72 374.6 Q(vidual pack)-.275 E(ets from recei)-.11 E -.165(ve)-.275 G=0A=
(rs that miss pack).165 E(ets in order to assure reliable)-.11 E=0A=
(reception of an object, and the pack)72 387.6 Q=0A=
(ets and their rate of transmission out of the sender can be)-.11 E=0A=
(independent of the number and the indi)72 400.6 Q(vidual reception e)=0A=
-.275 E(xperiences of the recei)-.165 E -.165(ve)-.275 G 2.75(rs. In)=0A=
.165 F(some)2.75 E(deli)72 413.6 Q -.165(ve)-.275 G=0A=
(ry service models it is appropriate that recei).165 E -.165(ve)-.275 G=0A=
(rs send out of band messages to the sender to).165 E(pro)72 426.6 Q=0A=
(vide guaranteed deli)-.165 E -.165(ve)-.275 G(ry of content.).165 E=0A=
-.165(Fo)5.5 G 2.75(re).165 G(xample, in a push reliable deli)-2.915 E=0A=
-.165(ve)-.275 G(ry model recei).165 E -.165(ve)-.275 G(rs).165 E=0A=
(may send messages to a sender to continue the session if recei)72 439.6=0A=
Q -.165(ve)-.275 G(rs ha).165 E .33 -.165(ve n)-.22 H(ot yet recei).165=0A=
E -.165(ve)-.275 G 2.75(de).165 G(nough)-2.75 E(pack)72 452.6 Q=0A=
(ets to reco)-.11 E -.165(ve)-.165 G 2.75(rt).165 G=0A=
(he content or to terminate the session when recei)-2.75 E -.165(ve)=0A=
-.275 G(rs ha).165 E .33 -.165(ve r)-.22 H(ecei).165 E -.165(ve)-.275 G=0A=
2.75(de).165 G(nough)-2.75 E(pack)72 465.6 Q(ets to reco)-.11 E -.165=0A=
(ve)-.165 G 2.75(rt).165 G(he content.)-2.75 E 1.76 -.88(To b)5.5 H 2.75=0A=
(ea).88 G(ble to track usage of the system, recei)-2.75 E -.165(ve)-.275=0A=
G(rs may also send).165 E(messages out of band to the sender that conta\=0A=
in statistics on their reception e)72 478.6 Q(xperience. ALC,)-.165 E=0A=
(ho)72 491.6 Q(we)-.275 E -.165(ve)-.275 G .88 -.44(r, d).165 H=0A=
(oes not require nor specify such messages, with the aim of a).44 E -.22=0A=
(vo)-.22 G(iding unnecessary).22 E=0A=
(limitation to the scalability of the basic ALC protocol.)72 504.6 Q=0A=
(The LCT b)72 530.6 Q(uilding block pro)-.22 E=0A=
(vides support for congestion control, and the ALC protocol uses this)=0A=
-.165 E 2.75(support. In)72 543.6 R(particular)2.75 E 2.75(,t)-.44 G=0A=
2.75(ot)-2.75 G(ak)-2.75 E 2.75(ef)-.11 G(ull adv)-2.75 E=0A=
(antage of the scalability features of ALC, the congestion)-.275 E=0A=
(control b)72 556.6 Q(uilding block used by ALC must be a multi-rate co\=0A=
ngestion control scheme that requires)-.22 E(no recei)72 569.6 Q -.165=0A=
(ve)-.275 G 2.75(rf).165 G(eedback to the sender and must use the Conge\=0A=
stion Control Information \214eld within)-2.75 E(the LCT header to con)=0A=
72 582.6 Q .33 -.165(vey p)-.44 H(ack).165 E(et by pack)-.11 E=0A=
(et congestion control information to recei)-.11 E -.165(ve)-.275 G 2.75=0A=
(rs. Possible).165 F(congestion control b)72 595.6 Q(uilding blocks tha\=0A=
t could be used with ALC are described in [6] and [1]. A)-.22 E=0A=
(sender sends pack)72 608.6 Q(ets in the session to se)-.11 E -.165(ve)=0A=
-.275 G(ral LCT channels at potentially dif).165 E(ferent rates. Then,)=0A=
-.275 E(indi)72 621.6 Q(vidual recei)-.275 E -.165(ve)-.275 G(rs can ad\=0A=
just their reception rate within a session by adjusting which set of LC\=0A=
T).165 E(channels the)72 634.6 Q 2.75(ya)-.165 G=0A=
(re joined to at each point in time depending on the a)-2.75 E -.275(va)=0A=
-.22 G(ilable bandwidth between).275 E(the recei)72 647.6 Q -.165(ve)=0A=
-.275 G 2.75(ra).165 G(nd the sender)-2.75 E 2.75(,b)-.44 G=0A=
(ut independent of other recei)-2.97 E -.165(ve)-.275 G(rs.).165 E=0A=
(Recei)72 673.6 Q -.165(ve)-.275 G(rs may join and lea).165 E .33 -.165=0A=
(ve a s)-.22 H(ession asynchronously at their discretion.).165 E=0A=
(Note also that the congestion control b)72 699.6 Q=0A=
(uilding block used by ALC must conform with RFC2357.)-.22 E=0A=
(ALC has the follo)72 725.6 Q=0A=
(wing properties when multicast is used to deli)-.275 E -.165(ve)-.275 G=0A=
2.75(rp).165 G(ack)-2.75 E(ets:)-.11 E(Luby/Gemmell/V)72 769 Q=0A=
(icisano/Rizzo/Cro)-.66 E 157.517(wcroft Section)-.275 F 2.75(1. [P)2.75=0A=
F(age 3])-.165 E EP=0A=
%%Page: 4 4=0A=
%%BeginPageSetup=0A=
BP=0A=
%%EndPageSetup=0A=
/F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 77.081(-DRAFT Expires:)-1.012 F=0A=
(April 2002)2.75 E(October 2001)112.127 E 5.5(oT)72 85 S 2.75(oe)-6.38 G=0A=
(ach recei)-2.75 E -.165(ve)-.275 G .88 -.44(r, i).165 H 2.75(ta).44 G(\=0A=
ppears as if though there is a dedicated session from the sender to the)=0A=
-2.75 E(recei)83 98 Q -.165(ve)-.275 G .88 -.44(r, w).165 H(here the re\=0A=
ception rate adjusts to congestion along the path from sender to recei)=0A=
.44 E -.165(ve)-.275 G -.605(r.).165 G 5.5(oT)72 114.6 S 2.75(ot)-6.38 G=0A=
(he sender)-2.75 E 2.75(,t)-.44 G(here is no dif)-2.75 E=0A=
(ference in load or outgoing rate if one recei)-.275 E -.165(ve)-.275 G=0A=
2.75(ri).165 G 2.75(sj)-2.75 G(oined to the)-2.75 E=0A=
(session or a million \(or an)83 127.6 Q 2.75(yn)-.165 G=0A=
(umber of\) recei)-2.75 E -.165(ve)-.275 G=0A=
(rs are joined to the session, independent of when).165 E(the recei)83=0A=
140.6 Q -.165(ve)-.275 G(rs join and lea).165 E -.165(ve)-.22 G(.).165 E=0A=
5.5(oO)72 157.2 S 2.75(ne)-5.5 G(ach link in the netw)-2.75 E=0A=
(ork, the pack)-.11 E(et traf)-.11 E=0A=
(\214c from the session and its reaction to competing)-.275 E(traf)83=0A=
170.2 Q(\214c is the same whether there is one recei)-.275 E -.165(ve)=0A=
-.275 G 2.75(ro).165 G 2.75(ram)-2.75 G(illion recei)-2.75 E -.165(ve)=0A=
-.275 G(rs be).165 E(yond the link.)-.165 E(Thus, ALC pro)83 196.2 Q=0A=
(vides a massi)-.165 E -.165(ve)-.275 G(ly scalable content deli).165 E=0A=
-.165(ve)-.275 G(ry system that is netw).165 E(ork friendly)-.11 E(.)=0A=
-.715 E(The k)83 222.2 Q .33 -.165(ey w)-.11 H(ords "MUST", "MUST NO)=0A=
.055 E(T", "REQ)-.44 E(UIRED", "SHALL", "SHALL NO)-.11 E(T",)-.44 E=0A=
("SHOULD", "SHOULD NO)83 235.2 Q(T", "RECOMMENDED", "MA)-.44 E=0A=
(Y", and "OPTION)-1.155 E(AL" in this)-.385 E=0A=
(document are to be interpreted as described in RFC2119.)83 248.2 Q/F1=0A=
11/Times-Bold@0 SF(1.1.)72 287.2 Q/F2 13/Times-Bold@0 SF=0A=
(Related Documents)5.5 E F0(This speci\214cation of ALC must use v)72=0A=
303.8 Q(ersion 0 of the LCT b)-.165 E=0A=
(uilding block as speci\214ed in [4].)-.22 E(A)5.5 E(more in-depth desc\=0A=
ription of the use of FEC codecs in reliable content deli)72 316.8 Q=0A=
-.165(ve)-.275 G(ry protocols is gi).165 E -.165(ve)-.275 G(n).165 E=0A=
(in [2]. All pack)72 329.8 Q(ets in a session must contain an FEC P)-.11=0A=
E(ayload ID in a format that is compliant with)-.165 E(the FEC b)72=0A=
342.8 Q(uilding block described in [3].)-.22 E=0A=
(Implementors of ALC must also implement a multi-rate)5.5 E=0A=
(feedback-free congestion control b)72 355.8 Q=0A=
(uilding block that is in accordance to RFC2357, where the)-.22 E=0A=
(congestion control is o)72 368.8 Q -.165(ve)-.165 G 2.75(rt).165 G=0A=
(he entire session.)-2.75 E=0A=
(Some possible schemes are speci\214ed in [6] and [1].)5.5 E=0A=
(Congestion control must be inte)72 381.8 Q=0A=
(grated into ALC through the support pro)-.165 E(vided in the LCT)-.165=0A=
E -.22(bu)72 394.8 S(ilding block.).22 E=0A=
(It is recommended that ALC implementors use some pack)72 420.8 Q=0A=
(et authentication scheme to protect the)-.11 E=0A=
(protocol from attacks. An e)72 433.8 Q=0A=
(xample of a possibly suitable scheme is described in [5]. P)-.165 E=0A=
(ack)-.165 E(et)-.11 E(authentication in ALC, if used, is to be inte)72=0A=
446.8 Q(grated through the support pro)-.165 E(vided in the LCT)-.165 E=0A=
-.22(bu)72 459.8 S(ilding block.).22 E F1(1.2.)72 498.8 Q F2(En)5.5 E=0A=
(vir)-.52 E(onmental Requir)-.234 E(ements and Considerations)-.234 E F0=0A=
(ALC is intended for mult-rate congestion controlled deli)72 515.4 Q=0A=
-.165(ve)-.275 G(ry of objects, i.e., reliable content).165 E(deli)72=0A=
528.4 Q -.165(ve)-.275 G(ry).165 E(.)-.715 E(This speci\214cation de\=0A=
\214nes ALC as payload of the UDP transport protocol \(RFC768\).)72=0A=
554.4 Q(All of the en)72 580.4 Q=0A=
(vironmental requirements and considerations that apply to the LCT b)=0A=
-.44 E(uilding block)-.22 E(and to the FEC b)72 593.4 Q=0A=
(uilding block also apply to ALC.)-.22 E(In particular)72 619.4 Q 2.75=0A=
(,L)-.44 G(CT requires the ability by recei)-2.75 E -.165(ve)-.275 G=0A=
(rs to uniquely identify and demultiple).165 E 2.75(xp)-.165 G(ack)-2.75=0A=
E(ets)-.11 E=0A=
(associated with an LCT session, and ALC inherits this requirement.)72=0A=
632.4 Q 1.76 -.88(To t)5.5 H(his purpose, a T).88 E(ransport)-.385 E(Se\=0A=
ssion Identi\214er \(TSI\) must be associated with each session. The TS\=0A=
I is scoped by the IP address)72 645.4 Q(of the sender)72 658.4 Q 2.75=0A=
(,a)-.44 G(nd the IP address of the sender together with the TSI must u\=0A=
niquely identify the)-2.75 E 2.75(session. It)72 671.4 R=0A=
(is recommended that the TSI \214eld in the LCT header is used to con)=0A=
2.75 E .33 -.165(vey t)-.44 H(he ALC TSI.).165 E=0A=
(If the TSI is not present in the LCT header)72 684.4 Q 2.75(,t)-.44 G=0A=
(hen 16-bit UDP source port is used as TSI.)-2.75 E(If Generic Router A\=0A=
ssist \(GRA\) is being used then additional dependencies may be introdu\=0A=
ced by)72 710.4 Q(GRA on the TSI \214eld.)72 723.4 Q=0A=
(Generic Router Assist is a current topic of discussion within the RMT)=0A=
5.5 E(Luby/Gemmell/V)72 769 Q(icisano/Rizzo/Cro)-.66 E 149.267=0A=
(wcroft Section)-.275 F 2.75(1.2. [P)2.75 F(age 4])-.165 E EP=0A=
%%Page: 5 5=0A=
%%BeginPageSetup=0A=
BP=0A=
%%EndPageSetup=0A=
/F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 77.081(-DRAFT Expires:)-1.012 F=0A=
(April 2002)2.75 E(October 2001)112.127 E -.11(wo)72 85 S(rking group.)=0A=
.11 E(If a TSI v)5.5 E(alue appears more than once in a pack)-.275 E=0A=
(et then all occurrences of the)-.11 E -.275(va)72 98 S=0A=
(lue must be equal.).275 E=0A=
(If, in future speci\214cation, there is no underlying TSI pro)72 124 Q=0A=
(vided by the netw)-.165 E(ork, transport or an)-.11 E(y)-.165 E=0A=
(other layer)72 137 Q 2.75(,t)-.44 G=0A=
(hen the use of the TSI in the LCT header must be mandatory)-2.75 E(.)=0A=
-.715 E/F1 11/Times-Bold@0 SF(2.)72 176 Q/F2 14/Times-Bold@0 SF=0A=
(General Ar)5.5 E(chitectur)-.252 E(e)-.252 E F0(ALC protocol uses the \=0A=
FEC codecs in the form described in [3] combined with the LCT b)72 192.6=0A=
Q(uilding)-.22 E(block as described in [4]. Thus, the terminology used \=0A=
in the description of the LCT b)72 205.6 Q(uilding block)-.22 E=0A=
(and the FEC b)72 218.6 Q(uilding block are inherited by the ALC protoc\=0A=
ol and this terminology is used belo)-.22 E -.715(w.)-.275 G=0A=
(In particular)72 231.6 Q 2.75(,t)-.44 G(he de\214nition of a session f\=0A=
or the ALC protocol is the same as it is for the LCT)-2.75 E -.22(bu)72=0A=
244.6 S(ilding block.).22 E=0A=
(There is a one-to-one mapping between ALC sessions and LCT sessions.)72=0A=
270.6 Q(An ALC pack)72 296.6 Q(et consists of the def)-.11 E=0A=
(ault LCT header)-.11 E 2.75(,f)-.44 G(ollo)-2.75 E(wed by the FEC P)=0A=
-.275 E(ayload ID, follo)-.165 E(wed by)-.275 E(the pack)72 309.6 Q=0A=
(et payload.)-.11 E(The pack)5.5 E=0A=
(et payload is as described in [3]. If Generic Router Assist \(GRA\) is)=0A=
-.11 E(being used, then additional constraints may be introduced on the\=0A=
LCT header)72 322.6 Q(.)-.605 E(The ALC header immediately follo)72=0A=
348.6 Q(ws a UDP header)-.275 E(.)-.605 E(The out of band information u\=0A=
sed by the ALC protocol consists of all the out of band information)72=0A=
374.6 Q(required for both the LCT b)72 387.6 Q=0A=
(uilding block and for the FEC b)-.22 E(uilding block.)-.22 E=0A=
(The possible means for)5.5 E=0A=
(acquiring this out of band information is the same as for the LCT b)72=0A=
400.6 Q(uilding block and the FEC)-.22 E -.22(bu)72 413.6 S(ilding bloc\=0A=
k, and in particular is outside the scope of the ALC protocol.).22 E F1=0A=
(2.1.)72 452.6 Q/F3 13/Times-Bold@0 SF(Deli)5.5 E -.13(ve)-.13 G(ry ser)=0A=
.13 E(vice models)-.13 E F0(ALC can support se)72 469.2 Q -.165(ve)-.275=0A=
G(ral dif).165 E(ferent deli)-.275 E -.165(ve)-.275 G=0A=
(ry service models. T).165 E .22 -.11(wo e)-.88 H=0A=
(xamples are brie\215y described)-.055 E(here.)72 482.2 Q F1(Push ser)72=0A=
521.2 Q(vice model.)-.11 E F0(One w)72 537.8 Q=0A=
(ay a push service model can be used for reliable content deli)-.11 E=0A=
-.165(ve)-.275 G(ry is to deli).165 E -.165(ve)-.275 G 2.75(ras).165 G=0A=
(eries of)-2.75 E 2.75(objects. F)72 550.8 R(or e)-.165 E=0A=
(xample, a recei)-.165 E -.165(ve)-.275 G 2.75(rc).165 G=0A=
(ould join the session and dynamically adapt the number of LCT)-2.75 E=0A=
(channels the recei)72 563.8 Q -.165(ve)-.275 G 2.75(ri).165 G 2.75(sj)=0A=
-2.75 G(oined to until enough pack)-2.75 E(ets ha)-.11 E .33 -.165(ve b)=0A=
-.22 H(een recei).165 E -.165(ve)-.275 G 2.75(dt).165 G 2.75(or)-2.75 G=0A=
(econstruct an)-2.75 E=0A=
(object. After reconstructing the object the recei)72 576.8 Q -.165(ve)=0A=
-.275 G 2.75(rm).165 G(ay stay in the session and w)-2.75 E(ait for the)=0A=
-.11 E(transmission of the ne)72 589.8 Q(xt object.)-.165 E=0A=
(The push model is particularly attracti)72 615.8 Q .33 -.165(ve i)-.275=0A=
H 2.75(ns).165 G(atellite netw)-2.75 E(orks and wireless netw)-.11 E=0A=
2.75(orks. In)-.11 F(these)2.75 E=0A=
(cases, a session may consist of one \214x)72 628.8 Q=0A=
(ed rate LCT channel.)-.165 E F1(On-demand content deli)72 667.8 Q -.11=0A=
(ve)-.11 G(ry model.).11 E F0 -.165(Fo)72 684.4 S 2.75(ra).165 G 2.75=0A=
(no)-2.75 G(n-demand content deli)-2.75 E -.165(ve)-.275 G=0A=
(ry service model, senders typically transmit for some gi).165 E -.165=0A=
(ve)-.275 G 2.75(nt).165 G(ime)-2.75 E=0A=
(period selected to be long enough to allo)72 697.4 Q 2.75(wa)-.275 G=0A=
(ll the intended recei)-2.75 E -.165(ve)-.275 G=0A=
(rs to join the session and).165 E(reco)72 710.4 Q -.165(ve)-.165 G 2.75=0A=
(ras).165 G(ingle object.)-2.75 E -.165(Fo)5.5 G 2.75(re).165 G=0A=
(xample a popular softw)-2.915 E=0A=
(are update might be transmitted using ALC)-.11 E(for se)72 723.4 Q=0A=
-.165(ve)-.275 G(ral days, e).165 E -.165(ve)-.275 G 2.75(nt).165 G=0A=
(hough a recei)-2.75 E -.165(ve)-.275 G 2.75(rm).165 G=0A=
(ay be able to complete the do)-2.75 E(wnload in one hour total)-.275 E=0A=
(Luby/Gemmell/V)72 769 Q(icisano/Rizzo/Cro)-.66 E 149.267=0A=
(wcroft Section)-.275 F 2.75(2.1. [P)2.75 F(age 5])-.165 E EP=0A=
%%Page: 6 6=0A=
%%BeginPageSetup=0A=
BP=0A=
%%EndPageSetup=0A=
/F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 77.081(-DRAFT Expires:)-1.012 F=0A=
(April 2002)2.75 E(October 2001)112.127 E=0A=
(of connection time, perhaps spread o)72 85 Q -.165(ve)-.165 G 2.75(rs)=0A=
.165 G -2.365 -.275(ev e)-2.75 H(ral interv).275 E(als of time.)-.275 E=0A=
(In this case the recei)72 111 Q -.165(ve)-.275 G=0A=
(rs join the session at an).165 E 2.75(yp)-.165 G=0A=
(oint in time when it is acti)-2.75 E .33 -.165(ve a)-.275 H=0A=
(nd dynamically).165 E(adapt the number of LCT channels the)72 124 Q=0A=
2.75(ys)-.165 G(ubscribe to according to the a)-2.75 E -.275(va)-.22 G=0A=
(ilable bandwidth using a).275 E(multi-rate congestion control b)72 137=0A=
Q(uilding block. Recei)-.22 E -.165(ve)-.275 G(rs lea).165 E .33 -.165=0A=
(ve t)-.22 H(he session when the).165 E 2.75(yh)-.165 G -2.475 -.22=0A=
(av e)-2.75 H(recei)2.97 E -.165(ve)-.275 G(d).165 E(enough pack)72 150=0A=
Q(ets to reco)-.11 E -.165(ve)-.165 G 2.75(rt).165 G(he object.)-2.75 E=0A=
/F1 11/Times-Bold@0 SF(Other ser)72 189 Q(vice models.)-.11 E F0=0A=
(There may be other deli)72 218.6 Q -.165(ve)-.275 G=0A=
(ry service models that can be supported by ALC.).165 E=0A=
(The description of)5.5 E=0A=
(the potential applications, the appropriate deli)72 231.6 Q -.165(ve)=0A=
-.275 G(ry service model, and the additional mechanisms).165 E=0A=
(to support such functionalities when combined with ALC is be)72 244.6 Q=0A=
(yond the scope of this document.)-.165 E F1(2.2.)72 283.6 Q/F2 13=0A=
/Times-Bold@0 SF(Congestion Contr)5.5 E(ol)-.234 E F0 2.75(Am)72 300.2 S=0A=
(ulti-rate congestion control b)-2.75 E=0A=
(uilding block that is feedback-free, that is suitable for reliable)-.22=0A=
E(content deli)72 313.2 Q -.165(ve)-.275 G(ry).165 E 2.75(,a)-.715 G=0A=
(nd that conforms to RFC2357 is to be used by ALC.)-2.75 E(An e)5.5 E=0A=
(xample of such a)-.165 E(congestion control b)72 326.2 Q=0A=
(uilding block is described in [6] and [1]. While the general beha)-.22=0A=
E(vior of the)-.22 E(congestion control b)72 339.2 Q(uilding block is t\=0A=
o reduce transmission rate in the presence of congestion and)-.22 E(gra\=0A=
dually increase the rate in the absence of congestion, the actual dynam\=0A=
ic beha)72 352.2 Q(vior \(e.g.)-.22 E(response to single losses\) can v)=0A=
72 365.2 Q(ary)-.275 E(.)-.715 E(The congestion control b)72 391.2 Q(ui\=0A=
lding block must use the Congestion Control Information \214eld carried)=0A=
-.22 E(in the LCT header of each pack)72 404.2 Q 2.75(et. Congestion)=0A=
-.11 F(control must be applied to all pack)2.75 E(ets within a)-.11 E(s\=0A=
ession independently of which information about which object is carried\=0A=
in each pack)72 417.2 Q(et.)-.11 E F1(3.)72 456.2 Q/F3 14/Times-Bold@0=0A=
SF -.14(Pa)5.5 G(ck).14 E(et f)-.14 E(ormat used by the ALC pr)-.35 E=0A=
(otocol)-.252 E F0(The pack)72 472.8 Q=0A=
(et format used by the ALC protocol is the UDP header follo)-.11 E=0A=
(wed by the def)-.275 E(ault LCT)-.11 E(header follo)72 485.8 Q=0A=
(wed by the FEC P)-.275 E(ayload ID follo)-.165 E(wed by the pack)-.275=0A=
E(et payload.)-.11 E(The pack)5.5 E(et payload is)-.11 E(as described i\=0A=
n [3], i.e., it contains encoding information about the object.)72 498.8=0A=
Q(If Generic Router)5.5 E(Assist \(GRA\) is being used, then additional\=0A=
information may be required in the pack)72 511.8 Q(et headers,)-.11 E=0A=
(and an additional speci\214cation may be needed.)72 524.8 Q(The v)72=0A=
550.8 Q(ersion number of ALC speci\214ed in this document is 0.)-.165 E=0A=
(This coincides with v)5.5 E(ersion 0 of the)-.165 E(LCT b)72 563.8 Q=0A=
(uilding block [4] used in this speci\214cation.)-.22 E(The LCT v)5.5 E=0A=
(ersion number \214eld should be)-.165 E(interpreted as the ALC v)72=0A=
576.8 Q(ersion number \214eld.)-.165 E(Some instances of sessions may r\=0A=
equire the generation of feedback from the recei)72 602.8 Q -.165(ve)=0A=
-.275 G(rs to the).165 E(sender)72 615.8 Q 5.5(.H)-.605 G -.275(ow)-5.5=0A=
G -2.365 -.275(ev e).275 H .88 -.44(r, t).275 H=0A=
(he mechanism for doing this is outside the scope of ALC.).44 E F1(3.1.)=0A=
72 654.8 Q F2(Speci\214c pack)5.5 E(et f)-.13 E(ormat)-.325 E F0=0A=
(The pack)72 671.4 Q=0A=
(et format used for ALC protocol is depicted in Figure 1.)-.11 E=0A=
(Luby/Gemmell/V)72 769 Q(icisano/Rizzo/Cro)-.66 E 149.267=0A=
(wcroft Section)-.275 F 2.75(3.1. [P)2.75 F(age 6])-.165 E EP=0A=
%%Page: 7 7=0A=
%%BeginPageSetup=0A=
BP=0A=
%%EndPageSetup=0A=
/F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 77.081(-DRAFT Expires:)-1.012 F=0A=
(April 2002)2.75 E(October 2001)112.127 E/F1 8/Courier@0 SF 91.2(0123)=0A=
81.6 85 S 4.8(01234567890123456789012345678901)81.6 98 S=0A=
(+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+)76.8=0A=
111 Q 100.8(|D)76.8 124 S(efault LCT header)-100.8 E(|)115.2 E 302.4(||)=0A=
76.8 137 S=0A=
(+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D=
+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+)76.8=0A=
150 Q 110.4(|F)76.8 163 S(EC Payload ID)-110.4 E(|)124.8 E 302.4(||)76.8=0A=
176 =
S(+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D=
+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+)=0A=
76.8 189 Q 115.2(|A)76.8 202 S(LC payload)-115.2 E(|)134.4 E 302.4(||)=0A=
76.8 215 S 302.4(||)76.8 228 S=0A=
(+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+)76.8=0A=
241 Q/F2 10/Times-Roman@0 SF(Figure 1 - P)72 280 Q(ack)-.15 E=0A=
(et format for the ALC protocol)-.1 E(The length of the Def)72 306 Q=0A=
(ault LCT header is e)-.1 E(xplicitly encoded in the)-.15 E=0A=
(header itself \(see)72 319 Q([4]\) , while the length of the FEC P)72=0A=
332 Q(ayload ID is implicitly de\214ned by the)-.15 E=0A=
(FEC Encoding ID \(see)72 345 Q=0A=
([3]\) , that is communicated out of band and, possibly)72 358 Q 2.5(,t)=0A=
-.65 G(hrough the Codepoint)-2.5 E(\214eld in the LCT header)72 371 Q 5=0A=
(.T)-.55 G(he rest of the datagram is made of ALC)-5 E(payload.)72 384 Q=0A=
(In some special cases an ALC source may need to produce ALC pack)72 410=0A=
Q(ets)-.1 E(that do not contain an)72 423 Q 2.5(yp)-.15 G=0A=
(ayload. This may be required, for e)-2.5 E(xample, to)-.15 E=0A=
(signal the end of a session or to con)72 436 Q .3 -.15(vey c)-.4 H=0A=
(ongestion control).15 E(information. These data-less pack)72 449 Q=0A=
(ets do not contain the FEC P)-.1 E(ayload ID)-.15 E(either)72 462 Q 2.5=0A=
(,b)-.4 G(ut only the LCT header \214elds. The total datagram length,)=0A=
-2.7 E(con)72 475 Q -.15(vey)-.4 G=0A=
(ed by outer protocol headers \(e.g. the IP or UDP header\),).15 E=0A=
(enables recei)72 488 Q -.15(ve)-.25 G=0A=
(rs to detect the absence of the ALC payload and FEC).15 E -.15(Pa)72=0A=
501 S(yload ID.).15 E/F3 11/Times-Bold@0 SF(3.2.)72 540 Q/F4 13=0A=
/Times-Bold@0 SF -.13(Pa)5.5 G(ck).13 E(et header \214eld de\214nitions)=0A=
-.13 E F0=0A=
(The description of the \214elds and their functions within the def)72=0A=
556.6 Q(ault LCT header can be found in)-.11 E([4]. The information tha\=0A=
t needs to be communicated out of band for the LCT b)72 569.6 Q=0A=
(uilding block and)-.22 E(the possible mechanisms for achie)72 582.6 Q=0A=
(ving this are described in [4].)-.275 E=0A=
(The description of the \214elds and their functions within the FEC P)72=0A=
599.2 Q(ayload ID can be found in [3].)-.165 E(The information that nee\=0A=
ds to be communicated out of band for the FEC codecs and the possible)72=0A=
612.2 Q(mechanisms for achie)72 625.2 Q(ving this are described in [3].\=0A=
The mechanisms for communicating the out)-.275 E=0A=
(of band information needed for the LCT b)72 638.2 Q=0A=
(uilding block, including the mapping between the)-.22 E=0A=
(Codepoint \214eld v)72 651.2 Q(alues in the def)-.275 E=0A=
(ault LCT header and the interpretations of the v)-.11 E=0A=
(alues, may be the)-.275 E(same as those used for communicating the out\=0A=
of band information needed for the FEC b)72 664.2 Q(uilding)-.22 E=0A=
(block, with the e)72 677.2 Q=0A=
(xception that portions of the information needed for FEC b)-.165 E=0A=
(uilding blocks may be)-.22 E=0A=
(communicated through the use of the Codepoint \214eld in the def)72=0A=
690.2 Q(ault LCT header)-.11 E(.)-.605 E=0A=
(Multiple objects may be transmitted in the same session.)72 716.2 Q=0A=
(The T)5.5 E(ransport Object Identi\214er \(T)-.385 E(OI\))-.198 E=0A=
(Luby/Gemmell/V)72 769 Q(icisano/Rizzo/Cro)-.66 E 149.267=0A=
(wcroft Section)-.275 F 2.75(3.2. [P)2.75 F(age 7])-.165 E EP=0A=
%%Page: 8 8=0A=
%%BeginPageSetup=0A=
BP=0A=
%%EndPageSetup=0A=
/F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 77.081(-DRAFT Expires:)-1.012 F=0A=
(April 2002)2.75 E(October 2001)112.127 E=0A=
(\214eld in the LCT header must be used to identify the dif)72 85 Q=0A=
(ferent objects, and the FEC P)-.275 E(ayload ID)-.165 E(and the pack)72=0A=
98 Q(et payload must correspond to the object identi\214ed by the T)-.11=0A=
E(OI in the LCT header)-.198 E(.)-.605 E(If the FEC encoding scheme v)72=0A=
124 Q(aries among dif)-.275 E=0A=
(ferent objects transmitted in the same session, the)-.275 E=0A=
(Codepoint \214eld in the LCT header must be used to con)72 137 Q -.165=0A=
(vey)-.44 G 2.75(,i)-.55 G 2.75(ne)-2.75 G(ach pack)-2.75 E=0A=
(et, the association)-.11 E(between the ALC payload and the tuple <FEC \=0A=
Encoding ID, FEC Encoding Name>. This allo)72 150 Q(ws)-.275 E=0A=
(the recei)72 163 Q -.165(ve)-.275 G 2.75(rt).165 G 2.75(op)-2.75 G=0A=
(arse the FEC P)-2.75 E=0A=
(ayload ID \214eld and to select the appropriate decoder class without)=0A=
-.165 E(ha)72 176 Q(ving to interpret the T)-.22 E(OI \214eld.)-.198 E=0A=
/F1 11/Times-Bold@0 SF(4.)72 215 Q/F2 14/Times-Bold@0 SF(Pr)5.5 E=0A=
(ocedur)-.252 E(es)-.252 E F1(4.1.)72 254 Q/F3 13/Times-Bold@0 SF=0A=
(Sender Operation)5.5 E F0(The sender operation when using the ALC prot\=0A=
ocol includes all the points made about the sender)72 270.6 Q=0A=
(operation when using the LCT b)72 283.6 Q=0A=
(uilding block as described in [4], and the FEC b)-.22 E=0A=
(uilding block as)-.22 E(described in [3]. The follo)72 296.6 Q(wing de\=0A=
scription highlights some of the additional considerations to be)-.275 E=0A=
(tak)72 309.6 Q(en into account with respect to the ALC protocol.)-.11 E=0A=
2.75(As)72 335.6 S(ender using the ALC protocol must mak)-2.75 E 2.75=0A=
(ea)-.11 G -.275(va)-2.97 G(ilable all applicable information re).275 E=0A=
-.055(ga)-.165 G(rding the).055 E 2.75(session. This)72 348.6 R=0A=
(information includes:)2.75 E 11(oA)77.5 365.2 S .33 -.165(ny i)-11 H=0A=
(nformation needed by the LCT b).165 E(uilding block;)-.22 E 11(oT)77.5=0A=
381.8 S(he congestion control b)-11 E=0A=
(uilding block being used within the LCT b)-.22 E(uilding block;)-.22 E=0A=
11(oT)77.5 398.4 S(he mapping between v)-11 E=0A=
(alues of the Codepoint \214eld in the def)-.275 E(ault LCT header and)=0A=
-.11 E(interpretations of these v)94 411.4 Q(alues;)-.275 E 11(oA)77.5=0A=
428 S .33 -.165(ny i)-11 H(nformation needed for the FEC b).165 E=0A=
(uilding block, including the FEC Object T)-.22 E(ransmission)-.385 E=0A=
(Information;)94 441 Q 11(oI)77.5 457.6 S 2.75(fu)-11 G(sed, the pack)=0A=
-2.75 E(et authentication scheme being used within the LCT b)-.11 E=0A=
(uilding block, and all)-.22 E(rele)94 470.6 Q -.275(va)-.275 G=0A=
(nt information which is necessary for pack).275 E=0A=
(et authentication purposes.)-.11 E F1(4.2.)72 509.6 Q F3(Recei)5.5 E=0A=
-.13(ve)-.13 G 3.25(rO).13 G(peration)-3.25 E F0(The recei)72 526.2 Q=0A=
-.165(ve)-.275 G 2.75(ro).165 G(peration when using the ALC protocol in\=0A=
cludes all the points made about the)-2.75 E(recei)72 539.2 Q -.165(ve)=0A=
-.275 G 2.75(ro).165 G(peration that pertain to reliable content deli)=0A=
-2.75 E -.165(ve)-.275 G(ry when using the LCT b).165 E=0A=
(uilding block as)-.22 E=0A=
(described in [4], and that pertain to using the FEC b)72 552.2 Q=0A=
(uilding block as described in [3]. The)-.22 E(follo)72 565.2 Q(wing de\=0A=
scription highlights some of the additional considerations to be tak)=0A=
-.275 E(en into account)-.11 E(with respect to the ALC protocol.)72=0A=
578.2 Q(When a recei)72 604.2 Q -.165(ve)-.275 G 2.75(rr).165 G(ecei)=0A=
-2.75 E -.165(ve)-.275 G 2.75(sap).165 G(ack)-2.75 E(et, the recei)-.11=0A=
E -.165(ve)-.275 G 2.75(rm).165 G(ust process the def)-2.75 E=0A=
(ault LCT header \(e)-.11 E(xcluding)-.165 E=0A=
(the Codepoint \214eld\) as described in [4] before processing an)72=0A=
617.2 Q 2.75(yo)-.165 G(ther \214elds of the pack)-2.75 E(et.)-.11 E F1=0A=
(5.)72 656.2 Q F2(Security Considerations)5.5 E F0=0A=
(The same security consideration that apply to the LCT b)72 672.8 Q=0A=
(uilding block and to the FEC b)-.22 E(uilding)-.22 E=0A=
(block also apply to the ALC protocol.)72 685.8 Q(In addition, an)5.5 E=0A=
2.75(ys)-.165 G(ecurity considerations that apply to the)-2.75 E=0A=
(congestion control b)72 698.8 Q=0A=
(uilding block used by the ALC protocol within the LCT b)-.22 E=0A=
(uilding block also)-.22 E(apply)72 711.8 Q(.)-.715 E(Luby/Gemmell/V)72=0A=
769 Q(icisano/Rizzo/Cro)-.66 E 157.517(wcroft Section)-.275 F 2.75=0A=
(5. [P)2.75 F(age 8])-.165 E EP=0A=
%%Page: 9 9=0A=
%%BeginPageSetup=0A=
BP=0A=
%%EndPageSetup=0A=
/F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 77.081(-DRAFT Expires:)-1.012 F=0A=
(April 2002)2.75 E(October 2001)112.127 E/F1 11/Times-Bold@0 SF(6.)72 85=0A=
Q/F2 14/Times-Bold@0 SF(IAN)5.5 E 3.5(AC)-.28 G(onsiderations)-3.5 E F0=0A=
(No information in this speci\214cation is directly subject to IAN)72=0A=
101.6 Q 2.75(Ar)-.385 G -.165(eg)-2.75 G 2.75(istration. Ho).165 F(we)=0A=
-.275 E -.165(ve)-.275 G .88 -.44(r, b).165 H(uilding).22 E(blocks comp\=0A=
onents used by the ALC protocol may introduce additional IAN)72 114.6 Q=0A=
2.75(Ac)-.385 G 2.75(onsiderations. In)-2.75 F(particular)72 127.6 Q=0A=
2.75(,t)-.44 G(he FEC b)-2.75 E=0A=
(uilding block used by the ALC protocol does require IAN)-.22 E 2.75(Ar)=0A=
-.385 G -.165(eg)-2.75 G(istration of).165 E(the FEC codecs used.)72=0A=
140.6 Q F1(7.)72 179.6 Q F2(Intellectual Pr)5.5 E(operty Issues)-.252 E=0A=
F0(No speci\214c reliability b)72 209.2 Q=0A=
(uilding block or congestion control b)-.22 E=0A=
(uilding block is speci\214ed or)-.22 E=0A=
(referenced as mandatory in this document.)72 222.2 Q=0A=
(ALC may be used with congestion control b)72 248.2 Q=0A=
(uilding blocks and other b)-.22 E(uilding blocks which)-.22 E=0A=
(contain proprietary elements, or ha)72 261.2 Q .33 -.165(ve p)-.22 H=0A=
(ending or granted patents.).165 E F1(8.)72 300.2 Q F2(Ackno)5.5 E=0A=
(wledgments)-.14 E F0(Thanks to V)72 329.8 Q=0A=
(incent Roca and Justin Chapwesk)-.66 E 2.75(ef)-.11 G=0A=
(or their detailed comments on this draft.)-2.75 E F1(9.)72 368.8 Q F2=0A=
(Refer)5.5 E(ences)-.252 E F0([1] Byers, J.W)72 385.4 Q=0A=
(., Frumin, M., Horn, G., Luby)-1.012 E 2.75(,M)-.715 G(., Mitzenmacher)=0A=
-2.75 E 2.75(,M)-.44 G(., Roetter)-2.75 E 2.75(,A)-.44 G(., and Sha)=0A=
-2.75 E -.165(ve)-.22 G .88 -.44(r, W).165 H(.,)-.572 E("FLID-DL: Conge\=0A=
stion Control for Layered Multicast", Proceedings of Second Internation\=0A=
al)72 398.4 Q -.88(Wo)72 411.4 S(rkshop on Netw).88 E(ork)-.11 E=0A=
(ed Group Communications \(NGC 2000\), P)-.11 E(alo Alto, CA, No)-.165 E=0A=
-.165(ve)-.165 G(mber 2000.).165 E([2] Luby)72 437.4 Q 2.75(,M)-.715 G=0A=
(., Gemmell, V)-2.75 E(icisano, L., J., Rizzo, L., Handle)-.66 E 1.43=0A=
-.715(y, M)-.165 H(., Cro).715 E(wcroft, J., "The use of)-.275 E -.165=0A=
(Fo)72 450.4 S(rw).165 E(ard Error Correction in Reliable Multicast", I\=0A=
nternet Draft draft-ietf-rmt-info-fec-01.txt,)-.11 E(October 2001, a w)=0A=
72 463.4 Q(ork in progress.)-.11 E([3] Luby)72 489.4 Q 2.75(,M)-.715 G=0A=
(., Gemmell, J., V)-2.75 E(icisano, L., Rizzo, L., Handle)-.66 E 1.43=0A=
-.715(y, M)-.165 H(., Cro).715 E(wcroft, J., "RMT BB)-.275 E -.165(Fo)72=0A=
502.4 S(rw).165 E(ard Error Correction Codes", Internet Draft draft-iet\=0A=
f-rmt-bb-fec-04.txt, October 2001.)-.11 E([4] Luby)72 528.4 Q 2.75(,M)=0A=
-.715 G(., Gemmell, J., V)-2.75 E(icisano, L., Rizzo, L., Handle)-.66 E=0A=
1.43 -.715(y, M)-.165 H(., Cro).715 E(wcroft, J., "Layered Coding)-.275=0A=
E -.385(Tr)72 541.4 S(ansport: A massi).385 E -.165(ve)-.275 G=0A=
(ly scalable content deli).165 E -.165(ve)-.275 G=0A=
(ry transport", Internet Draft draft-ietf-rmt-bb-).165 E=0A=
(lct-02.txt, October 2001.)72 554.4 Q=0A=
([5] Perrig, A., Canetti, R., Song, D., T)72 580.4 Q(yg)-.88 E(ar)-.055=0A=
E 2.75(,J)-.44 G(.D., "Ef)-2.75 E=0A=
(\214cient and Secure Source Authentication for)-.275 E=0A=
(Multicast", Netw)72 593.4 Q(ork and Distrib)-.11 E=0A=
(uted System Security Symposium, NDSS 2001, pp. 35-46,)-.22 E=0A=
(February 2001.)72 606.4 Q([6] V)72 632.4 Q(icisano, L., Rizzo, L., Cro)=0A=
-.66 E(wcroft, J., "TCP-lik)-.275 E 2.75(eC)-.11 G=0A=
(ongestion Control for Layered Multicast)-2.75 E(Data T)72 645.4 Q=0A=
(ransfer", IEEE Infocom '98, San Francisco, CA, Mar)-.385 E(.28-Apr)=0A=
-.605 E(.1 1998.)-.605 E(Luby/Gemmell/V)72 769 Q(icisano/Rizzo/Cro)-.66=0A=
E 157.517(wcroft Section)-.275 F 2.75(9. [P)2.75 F(age 9])-.165 E EP=0A=
%%Page: 10 10=0A=
%%BeginPageSetup=0A=
BP=0A=
%%EndPageSetup=0A=
/F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 77.081(-DRAFT Expires:)-1.012 F=0A=
(April 2002)2.75 E(October 2001)112.127 E/F1 11/Times-Bold@0 SF(10.)72=0A=
85 Q/F2 14/Times-Bold@0 SF -.7(Au)5.5 G(thors' Addr).7 E(esses)-.252 E=0A=
F0(Michael Luby)80.25 101.6 Q(luby@digitalfountain.com)80.25 114.6 Q=0A=
(Digital F)80.25 127.6 Q(ountain)-.165 E(39141 Ci)80.25 140.6 Q=0A=
(vic Center Dri)-.275 E -.165(ve)-.275 G(Suite 300)80.25 153.6 Q=0A=
(Fremont, CA, USA, 94538)80.25 166.6 Q(Jim Gemmell)80.25 192.6 Q=0A=
(jgemmell@microsoft.com)80.25 205.6 Q(Microsoft Research)80.25 218.6 Q=0A=
(301 Ho)80.25 231.6 Q -.11(wa)-.275 G(rd St., #830).11 E=0A=
(San Francisco, CA, USA, 94105)80.25 244.6 Q(Lorenzo V)80.25 270.6 Q=0A=
(icisano)-.66 E(lorenzo@cisco.com)80.25 283.6 Q(cisco Systems, Inc.)=0A=
80.25 296.6 Q(170 W)80.25 309.6 Q(est T)-.88 E(asman Dr)-.88 E(.,)-.605=0A=
E(San Jose, CA, USA, 95134)80.25 322.6 Q(Luigi Rizzo)80.25 348.6 Q=0A=
(luigi@iet.unipi.it)80.25 361.6 Q(Dip. Ing. dell'Informazione,)80.25=0A=
374.6 Q(Uni)80.25 387.6 Q 1.43 -.715(v. d)-.275 H 2.75(iP).715 G(isa)=0A=
-2.75 E(via Diotisalvi 2, 56126 Pisa, Italy)80.25 400.6 Q(Jon Cro)80.25=0A=
426.6 Q(wcroft)-.275 E(J.Cro)80.25 439.6 Q(wcroft@cs.ucl.ac.uk)-.275 E=0A=
(Department of Computer Science)80.25 452.6 Q(Uni)80.25 465.6 Q -.165=0A=
(ve)-.275 G(rsity Colle).165 E(ge London)-.165 E(Go)80.25 478.6 Q=0A=
(wer Street,)-.275 E(London WC1E 6BT)80.25 491.6 Q 2.75(,U)-.814 G(K)=0A=
-2.75 E(Luby/Gemmell/V)72 769 Q(icisano/Rizzo/Cro)-.66 E 146.517=0A=
(wcroft Section)-.275 F 2.75(10. [P)2.75 F(age 10])-.165 E EP=0A=
%%Page: 11 11=0A=
%%BeginPageSetup=0A=
BP=0A=
%%EndPageSetup=0A=
/F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 77.081(-DRAFT Expires:)-1.012 F=0A=
(April 2002)2.75 E(October 2001)112.127 E/F1 11/Times-Bold@0 SF(11.)72=0A=
85 Q/F2 14/Times-Bold@0 SF(Full Copyright Statement)5.5 E F0(Cop)72=0A=
101.6 Q(yright \(C\) The Internet Society \(2001\).)-.11 E=0A=
(All Rights Reserv)5.5 E(ed.)-.165 E(This document and translations of \=0A=
it may be copied and furnished to others, and deri)72 118.2 Q -.275(va)=0A=
-.275 G(ti).275 E .33 -.165(ve w)-.275 H(orks).055 E=0A=
(that comment on or otherwise e)72 131.2 Q=0A=
(xplain it or assist in its implementation may be prepared, copied,)=0A=
-.165 E(published and distrib)72 144.2 Q=0A=
(uted, in whole or in part, without restriction of an)-.22 E 2.75(yk)=0A=
-.165 G(ind, pro)-2.75 E(vided that the)-.165 E(abo)72 157.2 Q .33 -.165=0A=
(ve c)-.165 H(op).165 E(yright notice and this paragraph are included o\=0A=
n all such copies and deri)-.11 E -.275(va)-.275 G(ti).275 E .33 -.165=0A=
(ve w)-.275 H(orks.).055 E(Ho)72 170.2 Q(we)-.275 E -.165(ve)-.275 G .88=0A=
-.44(r, t).165 H(his document itself may not be modi\214ed in an).44 E=0A=
2.75(yw)-.165 G(ay)-2.86 E 2.75(,s)-.715 G(uch as by remo)-2.75 E=0A=
(ving the)-.165 E(cop)72 183.2 Q(yright notice or references to the Int\=0A=
ernet Society or other Internet or)-.11 E -.055(ga)-.198 G(nizations, e)=0A=
.055 E(xcept as)-.165 E(needed for the purpose of de)72 196.2 Q -.165=0A=
(ve)-.275 G(loping Internet standards in which case the procedures for)=0A=
.165 E(cop)72 209.2 Q=0A=
(yrights de\214ned in the Internet languages other than English.)-.11 E=0A=
(The limited permissions granted abo)72 225.8 Q .33 -.165(ve a)-.165 H=0A=
(re perpetual and will not be re).165 E -.22(vo)-.275 G -.11(ke).22 G=0A=
2.75(db).11 G 2.75(yt)-2.75 G(he Internet)-2.75 E=0A=
(Society or its successors or assigns.)72 238.8 Q=0A=
(This document and the information contained herein is pro)72 255.4 Q=0A=
(vided on an "AS IS" basis and THE)-.165 E=0A=
(INTERNET SOCIETY AND THE INTERNET ENGINEERING T)72 268.4 Q=0A=
(ASK FORCE DISCLAIMS)-1.023 E(ALL W)72 281.4 Q=0A=
(ARRANTIES, EXPRESS OR IMPLIED, INCLUDING B)-1.32 E(UT NO)-.11 E 2.75=0A=
(TL)-.44 G(IMITED T)-2.75 E 2.75(OA)-.198 G(NY)-2.75 E -1.32(WA)72 294.4=0A=
S(RRANTY THA)1.32 E 2.75(TT)-1.221 G(HE USE OF THE INFORMA)-2.75 E=0A=
(TION HEREIN WILL NO)-1.221 E 2.75(TI)-.44 G(NFRINGE)-2.75 E=0A=
(ANY RIGHTS OR ANY IMPLIED W)72 307.4 Q(ARRANTIES OF MERCHANT)-1.32 E=0A=
(ABILITY OR FITNESS)-1.023 E(FOR A P)72 320.4 Q(AR)-1.012 E=0A=
(TICULAR PURPOSE.")-.66 E(Luby/Gemmell/V)72 769 Q(icisano/Rizzo/Cro)-.66=0A=
E 146.517(wcroft Section)-.275 F 2.75(11. [P)2.75 F(age 11])-.165 E EP=0A=
%%Page: 12 12=0A=
%%BeginPageSetup=0A=
BP=0A=
%%EndPageSetup=0A=
/F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 77.081(-DRAFT Expires:)-1.012 F=0A=
(April 2002)2.75 E(October 2001)112.127 E(Luby/Gemmell/V)72 769 Q=0A=
(icisano/Rizzo/Cro)-.66 E 146.517(wcroft Section)-.275 F 2.75(11. [P)=0A=
2.75 F(age 12])-.165 E EP=0A=
%%Trailer=0A=
end=0A=
%%EOF=0A=
------=_NextPart_000_000A_01C157E0.F961EDC0--
>From owner-rmt@listserv.lbl.gov Thu Oct 18 14:27:40 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f9ILORf04351;
Thu, 18 Oct 2001 14:24:27 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f9ILOPp04343
for <rmt@listserv.lbl.gov>; Thu, 18 Oct 2001 14:24:25 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f9ILOOm27258
for <rmt@listserv.lbl.gov>; Thu, 18 Oct 2001 14:24:24 -0700 (PDT)
Received: from mx.webfountain.com (mx.digitalfountain.com [209.219.233.39])
by SpamWall.lbl.gov (8.11.2/8.11.2) with SMTP id f9ILOMb27222
for <rmt@lbl.gov>; Thu, 18 Oct 2001 14:24:23 -0700 (PDT)
Received: (qmail 23849 invoked from network); 18 Oct 2001 21:24:17 -0000
Received: from mail.intranet (10.1.1.37)
by mx.digitalfountain.com with SMTP; 18 Oct 2001 21:24:17 -0000
Received: from bozz (dhcp-10-1-2-180.intranet [10.1.2.180])
by mail.intranet (8.9.3/8.9.3) with SMTP id OAA31638;
Thu, 18 Oct 2001 14:23:51 -0700
X-Authentication-Warning: mail.intranet: Host dhcp-10-1-2-180.intranet [10.1.2.180] claimed to be bozz
From: "Michael Luby" <luby@digitalfountain.com>
To: "Internet-Drafts@Ietf. Org" <internet-drafts@ietf.org>,
"Rmt@Lbl. Gov" <rmt@lbl.gov>
Cc: "Michael Luby" <luby@digitalfountain.com>
Subject: draft-ietf-rmt-bb-fec-04.txt
Date: Thu, 18 Oct 2001 14:29:15 -0700
Message-ID: <NEBBIAPCNKEDCLPNFBNCOEKKCHAA.luby@digitalfountain.com>
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="----=_NextPart_000_000F_01C157E1.43555B10"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <NEBBIAPCNKEDCLPNFBNCKEKKCHAA.luby@digitalfountain.com>
Sender: owner-rmt@lbl.gov
Precedence: bulk
This is a multi-part message in MIME format.
------=_NextPart_000_000F_01C157E1.43555B10
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Please post this draft on the IETF Internet Drafts archive. This is an
update of an existing WG draft (RMT).
This also serves as a last call before moving this towards RFC status.
Please send any comments or concerns to the RMT list by Monday, October 22.
Thanks, Mike Luby
------=_NextPart_000_000F_01C157E1.43555B10
Content-Type: text/plain;
name="draft-ietf-rmt-bb-fec-04.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
filename="draft-ietf-rmt-bb-fec-04.txt"
Internet Engineering Task Force RMT WG=0A=
INTERNET-DRAFT M.Luby/Digital Fountain=0A=
draft-ietf-rmt-bb-fec-04.txt L.Vicisano/Cisco=0A=
J.Gemmell/Microsoft=0A=
L.Rizzo/ACIRI and Univ. Pisa=0A=
M.Handley/ACIRI=0A=
J. Crowcroft/UCL=0A=
18 October 2001=0A=
Expires: April 2002=0A=
=0A=
=0A=
RMT BB Forward Error Correction Codes=0A=
=0A=
This document is an Internet-Draft and is in full conformance with all=0A=
provisions of Section 10 of RFC2026.=0A=
=0A=
Internet-Drafts are working documents of the Internet Engineering Task=0A=
Force (IETF), its areas, and its working groups. Note that other groups=0A=
may also distribute working documents as Internet-Drafts.=0A=
=0A=
Internet-Drafts are valid for a maximum of six months and may be=0A=
updated, replaced, or obsoleted by other documents at any time. It is=0A=
inappropriate to use Internet-Drafts as reference material or to cite=0A=
them other than as a "work in progress".=0A=
=0A=
The list of current Internet-Drafts can be accessed at=0A=
http://www.ietf.org/ietf/1id-abstracts.txt=0A=
=0A=
To view the list Internet-Draft Shadow Directories, see=0A=
http://www.ietf.org/shadow.html.=0A=
=0A=
This document is a product of the IETF RMT WG. Comments should be=0A=
addressed to the authors, or the WG's mailing list at rmt@isi.edu.=0A=
=0A=
=0A=
Abstract=0A=
=0A=
=0A=
This memo describes the abstract packet formats and IANA=0A=
registration procedures for use of Forward Error Correction=0A=
(FEC) codes within the context of reliable IP multicast=0A=
transport. This memo should be read in conjunction with and=0A=
uses the terminology of the companion memo [1], which=0A=
describes the use of Forward Error Correction (FEC) codes=0A=
within the context of reliable IP multicast transport and=0A=
=0A=
=0A=
=0A=
Luby/Vicisano/Gemmell/Rizzo/Handley/Crowcroft [Page 1]=0A=
=0C=0A=
INTERNET-DRAFT Expires: April 2002 October 2001=0A=
=0A=
=0A=
provides an introduction to some commonly used FEC codes.=0A=
=0A=
=0A=
1. FEC Abstract Packet Fields and Out-of-Band Information=0A=
=0A=
This section describes FEC information that is either to be sent out-of-=0A=
band or in packets. The FEC information is associated with transmission=0A=
of data about a particular object. There are three classes of packets=0A=
that may contain FEC information: data packets, session-control packets=0A=
and feedback packets. They generally contain different kinds of FEC=0A=
information. Note that some protocols may not use session-control or=0A=
feedback packets.=0A=
=0A=
Data packets may sometimes serve as session-control packets as well;=0A=
both data and session-control packets generally travel downstream from=0A=
the sender towards receivers and are sent to a multicast channel or to a=0A=
specific receiver using unicast.=0A=
=0A=
As a general rule, feedback packets travel upstream from receivers to=0A=
the sender. Sometimes, however, they might be sent to a multicast=0A=
channel or to another receiver or to some intermediate node or=0A=
neighboring router that provides recovery services.=0A=
=0A=
This document specifies the FEC information that must be carried in data=0A=
packets and the other FEC information that must be communicated either=0A=
out-of-band or in data packets. This document does not specify out-of-=0A=
band methods nor does it specify the way out-of-band FEC information is=0A=
associated with FEC information carried in data packets. These methods=0A=
must be specified in a complete protocol instantiation that uses the FEC=0A=
building block. FEC information is classified as follows:=0A=
=0A=
=0A=
1) FEC Encoding ID=0A=
=0A=
Identifies the FEC encoder being used and allows receivers to=0A=
select the appropriate FEC decoder. The value of the FEC Encoding=0A=
ID MUST be the same for all transmission of data related to a=0A=
particular object, but MAY vary across different transmissions of=0A=
data about different objects, even if transmitted to the same set=0A=
of multicast channels and/or using a single upper-layer session.=0A=
The FEC encoding ID is subject to IANA registration.=0A=
=0A=
2) FEC Encoding Name=0A=
=0A=
Provides a more specific identification of the FEC encoder being=0A=
used for an Under-Specified FEC scheme. This value is not used=0A=
for Fully-Specified FEC schemes. (See Section 1.1 for the=0A=
definition of Under-Specified and Fully-Specified FEC schemes.)=0A=
=0A=
=0A=
=0A=
Luby/Vicisano/Gemmell/Rizzo/Handley/Crowcroft Section 1. [Page 2]=0A=
=0C=0A=
INTERNET-DRAFT Expires: April 2002 October 2001=0A=
=0A=
=0A=
The FEC encoding name is scoped by the FEC encoding ID, and is=0A=
subject to IANA registration.=0A=
=0A=
3) FEC payload ID=0A=
=0A=
Identifies the encoding symbol(s) in the payload of the packet.=0A=
The fields in the FEC Payload ID depend on the encoder being used=0A=
(e.g. in Block and Expandable FEC codes this may be the=0A=
combination of block number and encoding symbol ID).=0A=
=0A=
4) FEC Object Transmission Information=0A=
=0A=
This is information regarding the encoding of a specific object=0A=
needed by the FEC decoder (e.g. for Block and Expandable FEC codes=0A=
this may be the combination of the source block lengths and the=0A=
object length). This might also include specific parameters of=0A=
the FEC encoder.=0A=
=0A=
=0A=
The FEC Encoding ID, FEC Encoding Name (for Under-Specified FEC schemes)=0A=
and the FEC Object Transmission Information can be sent to a receiver=0A=
within the data packet headers, within session control packets, or by=0A=
some other means. In any case, the means for communicating this to a=0A=
receiver is out of the scope of this document. The FEC Payload ID MUST=0A=
be included in the data packet header fields, as it provides a=0A=
description of the data contained in the packet.=0A=
=0A=
Within the context of FEC repair schemes, feedback packets are=0A=
(optionally) used to request FEC retransmission. The FEC-related=0A=
information present in feedback packets usually contains an FEC Block ID=0A=
that defines the block that is being repaired, and the number of Repair=0A=
Symbols requested. Although this is the most common case, variants are=0A=
possible in which the receivers provide more specific information about=0A=
the Repair Symbols requested (e.g. an index range or a list of symbols=0A=
accepted). It is also possible to include multiple of these requests in=0A=
a single feedback packet.=0A=
=0A=
This document does not provide any detail about feedback schemes used in=0A=
combination with FEC nor the format of FEC information in feedback=0A=
packets. If feedback packets are used in a complete protocol=0A=
instantiation, these details must be provided in the protocol=0A=
instantiation specification.=0A=
=0A=
=0A=
1.1. FEC Encoding ID and FEC Encoding Name=0A=
=0A=
=0A=
The FEC Encoding ID is a numeric index that identifies a specific FEC=0A=
=0A=
=0A=
=0A=
Luby/Vicisano/Gemmell/Rizzo/Handley/Crowcroft Section 1.1. [Page 3]=0A=
=0C=0A=
INTERNET-DRAFT Expires: April 2002 October 2001=0A=
=0A=
=0A=
scheme OR a class of encoding schemes that share the same FEC Payload ID=0A=
format.=0A=
=0A=
An FEC scheme is a Fully-Specified FEC scheme if the encoding scheme is=0A=
formally and fully specified, in a way that independent implementors can=0A=
implement both encoder and decoder from a specification that is an IETF=0A=
RFC. The FEC Encoding ID uniquely identifies a Fully-Specified FEC=0A=
scheme. Companion documents of this specification may specify Fully-=0A=
Specified FEC schemes and associate them with FEC Encoding ID values.=0A=
These documents MUST also specify a format for the FEC Payload ID and=0A=
specify the information in the FEC Object Transmission Information.=0A=
=0A=
It is possible that a FEC scheme cannot be a Fully-Specified FEC scheme,=0A=
because a specification is simply not available or that a party exists=0A=
that owns the encoding scheme and is not willing to disclose the=0A=
algorithm or specification. We refer to such an FEC encoding schemes as=0A=
an Under-Specified FEC scheme. The following holds for an Under-=0A=
Specified FEC scheme:=0A=
=0A=
o The format of the FEC Payload ID and the specific information in the=0A=
FEC Object Transmission Information MUST be defined for the Under-=0A=
Specified FEC scheme.=0A=
=0A=
o A value for the FEC Encoding ID MUST be reserved and associated with=0A=
the format of the FEC Payload ID and the specific information in the=0A=
FEC Object Transmission Information. An already reserved FEC=0A=
Encoding ID value MUST be reused if it is associated with the same=0A=
format of FEC Payload ID and the same information in the FEC Object=0A=
Transmission Information as the ones needed for the new Under-=0A=
Specified FEC scheme.=0A=
=0A=
o A value for the FEC Encoding Name MUST be reserved.=0A=
=0A=
=0A=
An Under-specified FEC scheme is fully identified by the tuple (FEC=0A=
Encoding ID, FEC Encoding Name). The tuple MUST identify a single scheme=0A=
that has at least one implementation. The party that owns this tuple=0A=
MUST be able to provide information on how to obtain the Under-Specified=0A=
FEC scheme identified by the tuple, e.g. a pointer to a publicly=0A=
available reference-implementation or the name and contacts of a company=0A=
that sells it, either separately or embedded in another product.=0A=
=0A=
Different Under-Specified FEC schemes that share the same FEC Encoding=0A=
ID -- but have different FEC Encoding Names -- also share the same=0A=
format of FEC Payload ID and specify the same information in the FEC=0A=
Object Transmission Information.=0A=
=0A=
This specification reserves the range 0-127 for the values of FEC=0A=
=0A=
=0A=
=0A=
Luby/Vicisano/Gemmell/Rizzo/Handley/Crowcroft Section 1.1. [Page 4]=0A=
=0C=0A=
INTERNET-DRAFT Expires: April 2002 October 2001=0A=
=0A=
=0A=
Encoding IDs for Fully-Specified FEC schemes and the range 128-255 for=0A=
the values of Under-Specified FEC schemes.=0A=
=0A=
=0A=
1.2. FEC Payload ID and FEC Object Transmission Information=0A=
=0A=
=0A=
A document that specifies an FEC scheme and reserves a value of FEC=0A=
Encoding ID MUST define a packet format for the FEC Payload ID and=0A=
specify the information in the FEC Object Transmission Information=0A=
according to the needs of the encoding scheme. This applies to documents=0A=
that reserve values of FEC Encoding IDs for both Fully-Specified and=0A=
Under-Specified FEC schemes.=0A=
=0A=
The packet format definition for the FEC Payload ID MUST specify the=0A=
meaning and layout of the fields down to the level of specific bits.=0A=
The FEC Payload ID MUST have a length that is a multiple of a 4-byte=0A=
word. This requirement facilitates the alignment of packet fields in=0A=
protocol instantiations.=0A=
=0A=
=0A=
2. Preassigned FEC Encoding IDs=0A=
=0A=
This section specifies the FEC Encoding ID and the associated FEC=0A=
Payload ID format and the specific information in the FEC Object=0A=
Transmission Information for a number of known Under-Specified FEC=0A=
schemes. Under-specified FEC schemes that use the same FEC Payload ID=0A=
format and specific information in the FEC Object Transmission=0A=
Information as for one of the FEC Encoding IDs specified in this section=0A=
MUST use the corresponding FEC Encoding ID. Other FEC Encoding IDs may=0A=
be specified for other Under-Specified FEC schemes in companion=0A=
documents.=0A=
=0A=
=0A=
2.1. Small Block, Large Block and Expandable FEC Codes=0A=
=0A=
This subsection reserves the FEC Encoding ID value 128 for the Under-=0A=
Specified FEC schemes described in [1] that are called Small Block FEC=0A=
codes, Large Block FEC codes and Expandable FEC codes.=0A=
=0A=
The FEC Payload ID is composed of a Source Block Number and an Encoding=0A=
Symbol ID structured as follows:=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
Luby/Vicisano/Gemmell/Rizzo/Handley/Crowcroft Section 2.1. [Page 5]=0A=
=0C=0A=
INTERNET-DRAFT Expires: April 2002 October 2001=0A=
=0A=
=0A=
0 1 2 3=0A=
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=0A=
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A=
| Source Block Number |=0A=
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A=
| Encoding Symbol ID |=0A=
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A=
=0A=
=0A=
The Source Block Number idenfities from which source block of the object=0A=
the encoding symbol(s) in the payload are generated. These blocks are=0A=
numbered consecutively from 0 to N-1, where N is the number of source=0A=
blocks in the object.=0A=
=0A=
The Encoding Symbol ID identifies which specific encoding symbol(s)=0A=
generated from the source block are carried in the packet payload. The=0A=
exact details of the correspondence between Encoding Symbol IDs and the=0A=
encoding symbol(s) in the packet payload are dependent on the particular=0A=
encoding algorithm used as identified by the Fec Encoding ID and by the=0A=
FEC Encoding Name, and these details may be proprietary.=0A=
=0A=
The FEC Object Transmission Information has the following specific=0A=
information:=0A=
=0A=
=0A=
o The total length of the object in bytes.=0A=
=0A=
o The number of source blocks that the object is partitioned into, and=0A=
the length of each source block in bytes.=0A=
=0A=
=0A=
=0A=
2.2. Small Block Systematic FEC Codes=0A=
=0A=
This subsection reserves the FEC Encoding ID value 129 for the Under-=0A=
Specified FEC schemes described in [1] that are called Small Block=0A=
Systematic FEC codes. For Small Block Systematic FEC codes, each source=0A=
block is of length at most 65536 bytes.=0A=
=0A=
Although these codes can generally be accommodated by the FEC Encoding=0A=
ID described in Section 2.1, a specific FEC Encoding ID is defined for=0A=
Small Block Systematic FEC codes to allow more flexibility and to retain=0A=
header compactness. The small source block length and small exapansion=0A=
factor that often characterize systematic codes may require that the=0A=
data source changes frequently the source block length. To allow the=0A=
dynamic variation of the source block length and to communicate it to=0A=
the receivers with low overhead, the block length is included in the FEC=0A=
Payload ID.=0A=
=0A=
=0A=
=0A=
Luby/Vicisano/Gemmell/Rizzo/Handley/Crowcroft Section 2.2. [Page 6]=0A=
=0C=0A=
INTERNET-DRAFT Expires: April 2002 October 2001=0A=
=0A=
=0A=
The FEC Payload ID is composed of the Source Block Number, Source Block=0A=
Length and the Encoding Symbol ID:=0A=
=0A=
=0A=
0 1 2 3=0A=
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=0A=
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A=
| Source Block Number |=0A=
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A=
| Source Block Length | Encoding Symbol ID |=0A=
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A=
=0A=
=0A=
The Source Block Number idenfities from which source block of the object=0A=
the encoding symbol(s) in the payload are generated. These blocks are=0A=
numbered consecutively from 0 to N-1, where N is the number of source=0A=
blocks in the object.=0A=
=0A=
The Source Block Length is the length in units of source symbols of the=0A=
source block identified by the Source Block Number.=0A=
=0A=
The Encoding Symbol ID identifies which specific encoding symbol(s)=0A=
generated from the source block are carried in the packet payload. The=0A=
exact details of the correspondence between Encoding Symbol IDs and the=0A=
encoding symbol(s) in the packet payload are dependent on the particular=0A=
encoding algorithm used as identified by the Fec Encoding ID and by the=0A=
FEC Encoding Name, and these details may be proprietary.=0A=
=0A=
The FEC Object Transmission Information has the following specific=0A=
information:=0A=
=0A=
=0A=
o The total length of the object in bytes.=0A=
=0A=
o The maximum length in bytes of the encoding symbols that can be=0A=
generated for any source block. This field is provided to allow=0A=
receivers to preallocate buffer space that is suitable for decoding=0A=
to recover any source block.=0A=
=0A=
o The length in bytes of a source symbol.=0A=
=0A=
=0A=
=0A=
3. IANA Considerations=0A=
=0A=
Values of FEC Encoding IDs and FEC Encoding Names are subject to IANA=0A=
registration. FEC Encoding IDs and FEC Encoding Names are hierarchical:=0A=
FEC Encoding IDs scope ranges of FEC Encoding Names. Only FEC Encoding=0A=
=0A=
=0A=
=0A=
Luby/Vicisano/Gemmell/Rizzo/Handley/Crowcroft Section 3. [Page 7]=0A=
=0C=0A=
INTERNET-DRAFT Expires: April 2002 October 2001=0A=
=0A=
=0A=
IDs that correspond to Under-Specified FEC schemes scope a corresponding=0A=
set of FEC Encoding Names.=0A=
=0A=
The FEC Encoding ID is a numeric non-negative index. In this document,=0A=
the range of values for FEC Encoding IDs is 0 and 255. Values from 0 to=0A=
127 are reserved for Fully-Specified FEC schemes, as described in more=0A=
detail in Section 1.1. The assignment of a FEC Encoding ID in this range=0A=
can only be granted if the requestor can provide such a specification=0A=
published as an IETF RFC, as described in more detail in Section 1.1.=0A=
Values from 128 to 255 are reserved for Under-Specified FEC schemes, as=0A=
described in more detail in Section 1.1. This specification already=0A=
assigns the values 128 and 129, as described in Section 2.=0A=
=0A=
Values of FEC Encoding IDs can only be assigned if the required format=0A=
for the FEC Payload ID and the specific information in the FEC Object=0A=
Transmission Information are specified in an IETF RFC.=0A=
=0A=
Each FEC Encoding ID assigned to an Under-Specified FEC scheme scopes an=0A=
independent range of FEC Encoding Names (i.e. the same value of FEC=0A=
Encoding Name can be reused for different FEC Encoding IDs). An FEC=0A=
Encoding Name is a numeric non-negative index.=0A=
=0A=
Under the scope of a FEC Encoding ID, FEC Encoding Names are assigned on=0A=
a First Come First Served base to requestors that are able to provide=0A=
point of contact information and a pointer to publicly accessible=0A=
documentation describing the Under-Specified FEC scheme and ways to=0A=
obtain it (e.g. a pointer to a publicly available reference-=0A=
implementation or the name and contacts of a company that sells it,=0A=
either separately or embedded in another product). The requestor is=0A=
responsible for keeping this information up to date.=0A=
=0A=
=0A=
4. Acknowledgments=0A=
=0A=
Brian Adamson contributed to this document by shaping Section 2.2 and=0A=
providing general feedback. We also wish to thank Vincent Roca and=0A=
Justin Chapweske for their comments.=0A=
=0A=
=0A=
5. References=0A=
=0A=
=0A=
[1] Luby, M., Vicisano, Gemmell, J., L., Rizzo, L., Handley, M.,=0A=
Crowcroft, J., "The use of Forward Error Correction in Reliable=0A=
Multicast", Internet draft draft-ietf-rmt-info-fec-01.txt, October 2001.=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
Luby/Vicisano/Gemmell/Rizzo/Handley/Crowcroft Section 5. [Page 8]=0A=
=0C=0A=
INTERNET-DRAFT Expires: April 2002 October 2001=0A=
=0A=
=0A=
6. Authors' Addresses=0A=
=0A=
Michael Luby=0A=
luby@digitalfountain.com=0A=
Digital Fountain, Inc.=0A=
39141 Civic Center Drive=0A=
Suite 300=0A=
Fremont, CA 94538=0A=
=0A=
Lorenzo Vicisano=0A=
lorenzo@cisco.com=0A=
cisco Systems, Inc.=0A=
170 West Tasman Dr.,=0A=
San Jose, CA, USA, 95134=0A=
=0A=
Jim Gemmell=0A=
jgemmell@microsoft.com=0A=
Microsoft Research=0A=
301 Howard St., #830=0A=
San Francisco, CA, USA, 94105=0A=
=0A=
Luigi Rizzo=0A=
luigi@iet.unipi.it=0A=
ACIRI, 1947 Center St., Berkeley CA 94704=0A=
and=0A=
Dip. di Ing. dell'Informazione=0A=
Universita` di Pisa=0A=
via Diotisalvi 2, 56126 Pisa, Italy=0A=
=0A=
Mark Handley=0A=
mjh@aciri.org=0A=
ACIRI=0A=
1947 Center St.=0A=
Berkeley CA, USA, 94704=0A=
=0A=
Jon Crowcroft=0A=
J.Crowcroft@cs.ucl.ac.uk=0A=
Department of Computer Science=0A=
University College London=0A=
Gower Street,=0A=
London WC1E 6BT, UK=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
Luby/Vicisano/Gemmell/Rizzo/Handley/Crowcroft Section 6. [Page 9]=0A=
=0C=0A=
INTERNET-DRAFT Expires: April 2002 October 2001=0A=
=0A=
=0A=
7. Full Copyright Statement=0A=
=0A=
Copyright (C) The Internet Society (2001). All Rights Reserved.=0A=
=0A=
This document and translations of it may be copied and furnished to=0A=
others, and derivative works that comment on or otherwise explain it or=0A=
assist in its implementation may be prepared, copied, published and=0A=
distributed, in whole or in part, without restriction of any kind,=0A=
provided that the above copyright notice and this paragraph are included=0A=
on all such copies and derivative works. However, this document itself=0A=
may not be modified in any way, such as by removing the copyright notice=0A=
or references to the Internet Society or other Internet organizations,=0A=
except as needed for the purpose of developing Internet standards in=0A=
which case the procedures for copyrights defined in the Internet=0A=
languages other than English.=0A=
=0A=
The limited permissions granted above are perpetual and will not be=0A=
revoked by the Internet Society or its successors or assigns.=0A=
=0A=
This document and the information contained herein is provided on an "AS=0A=
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK=0A=
FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT=0A=
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT=0A=
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR=0A=
FITNESS FOR A PARTICULAR PURPOSE."=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
Luby/Vicisano/Gemmell/Rizzo/Handley/Crowcroft Section 7. [Page 10]=0A=
=0C=0A=
INTERNET-DRAFT Expires: April 2002 October 2001=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
Luby/Vicisano/Gemmell/Rizzo/Handley/Crowcroft Section 7. [Page 11]=0A=
------=_NextPart_000_000F_01C157E1.43555B10
Content-Type: application/postscript;
name="draft-ietf-rmt-bb-fec-04.ps"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
filename="draft-ietf-rmt-bb-fec-04.ps"
%!PS-Adobe-3.0=0A=
%%Creator: groff version 1.15=0A=
%%CreationDate: Thu Oct 18 10:38:55 2001=0A=
%%DocumentNeededResources: font Courier-Bold=0A=
%%+ font Times-Bold=0A=
%%+ font Times-Roman=0A=
%%+ font Courier=0A=
%%DocumentSuppliedResources: procset grops 1.15 1=0A=
%%Pages: 9=0A=
%%PageOrder: Ascend=0A=
%%Orientation: Portrait=0A=
%%EndComments=0A=
%%BeginProlog=0A=
%%BeginResource: procset grops 1.15 1=0A=
/setpacking where{=0A=
pop=0A=
currentpacking=0A=
true setpacking=0A=
}if=0A=
/grops 120 dict dup begin=0A=
/SC 32 def=0A=
/A/show load def=0A=
/B{0 SC 3 -1 roll widthshow}bind def=0A=
/C{0 exch ashow}bind def=0A=
/D{0 exch 0 SC 5 2 roll awidthshow}bind def=0A=
/E{0 rmoveto show}bind def=0A=
/F{0 rmoveto 0 SC 3 -1 roll widthshow}bind def=0A=
/G{0 rmoveto 0 exch ashow}bind def=0A=
/H{0 rmoveto 0 exch 0 SC 5 2 roll awidthshow}bind def=0A=
/I{0 exch rmoveto show}bind def=0A=
/J{0 exch rmoveto 0 SC 3 -1 roll widthshow}bind def=0A=
/K{0 exch rmoveto 0 exch ashow}bind def=0A=
/L{0 exch rmoveto 0 exch 0 SC 5 2 roll awidthshow}bind def=0A=
/M{rmoveto show}bind def=0A=
/N{rmoveto 0 SC 3 -1 roll widthshow}bind def=0A=
/O{rmoveto 0 exch ashow}bind def=0A=
/P{rmoveto 0 exch 0 SC 5 2 roll awidthshow}bind def=0A=
/Q{moveto show}bind def=0A=
/R{moveto 0 SC 3 -1 roll widthshow}bind def=0A=
/S{moveto 0 exch ashow}bind def=0A=
/T{moveto 0 exch 0 SC 5 2 roll awidthshow}bind def=0A=
/SF{=0A=
findfont exch=0A=
[exch dup 0 exch 0 exch neg 0 0]makefont=0A=
dup setfont=0A=
[exch/setfont cvx]cvx bind def=0A=
}bind def=0A=
/MF{=0A=
findfont=0A=
[5 2 roll=0A=
0 3 1 roll=0A=
neg 0 0]makefont=0A=
dup setfont=0A=
[exch/setfont cvx]cvx bind def=0A=
}bind def=0A=
/level0 0 def=0A=
/RES 0 def=0A=
/PL 0 def=0A=
/LS 0 def=0A=
/MANUAL{=0A=
statusdict begin/manualfeed true store end=0A=
}bind def=0A=
/PLG{=0A=
gsave newpath clippath pathbbox grestore=0A=
exch pop add exch pop=0A=
}bind def=0A=
/BP{=0A=
/level0 save def=0A=
1 setlinecap=0A=
1 setlinejoin=0A=
72 RES div dup scale=0A=
LS{=0A=
90 rotate=0A=
}{=0A=
0 PL translate=0A=
}ifelse=0A=
1 -1 scale=0A=
}bind def=0A=
/EP{=0A=
level0 restore=0A=
showpage=0A=
}bind def=0A=
/DA{=0A=
newpath arcn stroke=0A=
}bind def=0A=
/SN{=0A=
transform=0A=
.25 sub exch .25 sub exch=0A=
round .25 add exch round .25 add exch=0A=
itransform=0A=
}bind def=0A=
/DL{=0A=
SN=0A=
moveto=0A=
SN=0A=
lineto stroke=0A=
}bind def=0A=
/DC{=0A=
newpath 0 360 arc closepath=0A=
}bind def=0A=
/TM matrix def=0A=
/DE{=0A=
TM currentmatrix pop=0A=
translate scale newpath 0 0 .5 0 360 arc closepath=0A=
TM setmatrix=0A=
}bind def=0A=
/RC/rcurveto load def=0A=
/RL/rlineto load def=0A=
/ST/stroke load def=0A=
/MT/moveto load def=0A=
/CL/closepath load def=0A=
/FL{=0A=
currentgray exch setgray fill setgray=0A=
}bind def=0A=
/BL/fill load def=0A=
/LW/setlinewidth load def=0A=
/RE{=0A=
findfont=0A=
dup maxlength 1 index/FontName known not{1 add}if dict begin=0A=
{=0A=
1 index/FID ne{def}{pop pop}ifelse=0A=
}forall=0A=
/Encoding exch def=0A=
dup/FontName exch def=0A=
currentdict end definefont pop=0A=
}bind def=0A=
/DEFS 0 def=0A=
/EBEGIN{=0A=
moveto=0A=
DEFS begin=0A=
}bind def=0A=
/EEND/end load def=0A=
/CNT 0 def=0A=
/level1 0 def=0A=
/PBEGIN{=0A=
/level1 save def=0A=
translate=0A=
div 3 1 roll div exch scale=0A=
neg exch neg exch translate=0A=
0 setgray=0A=
0 setlinecap=0A=
1 setlinewidth=0A=
0 setlinejoin=0A=
10 setmiterlimit=0A=
[]0 setdash=0A=
/setstrokeadjust where{=0A=
pop=0A=
false setstrokeadjust=0A=
}if=0A=
/setoverprint where{=0A=
pop=0A=
false setoverprint=0A=
}if=0A=
newpath=0A=
/CNT countdictstack def=0A=
userdict begin=0A=
/showpage{}def=0A=
}bind def=0A=
/PEND{=0A=
clear=0A=
countdictstack CNT sub{end}repeat=0A=
level1 restore=0A=
}bind def=0A=
end def=0A=
/setpacking where{=0A=
pop=0A=
setpacking=0A=
}if=0A=
%%EndResource=0A=
%%IncludeResource: font Courier-Bold=0A=
%%IncludeResource: font Times-Bold=0A=
%%IncludeResource: font Times-Roman=0A=
%%IncludeResource: font Courier=0A=
grops begin/DEFS 1 dict def DEFS begin/u{.001 mul}bind def end/RES 72=0A=
def/PL 792 def/LS false def/ENC0[/asciicircum/asciitilde/Scaron/Zcaron=0A=
/scaron/zcaron/Ydieresis/trademark/quotesingle/.notdef/.notdef/.notdef=0A=
/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef=0A=
/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef/.notdef=0A=
/.notdef/.notdef/space/exclam/quotedbl/numbersign/dollar/percent=0A=
/ampersand/quoteright/parenleft/parenright/asterisk/plus/comma/hyphen=0A=
/period/slash/zero/one/two/three/four/five/six/seven/eight/nine/colon=0A=
/semicolon/less/equal/greater/question/at/A/B/C/D/E/F/G/H/I/J/K/L/M/N/O=0A=
/P/Q/R/S/T/U/V/W/X/Y/Z/bracketleft/backslash/bracketright/circumflex=0A=
/underscore/quoteleft/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y=0A=
/z/braceleft/bar/braceright/tilde/.notdef/quotesinglbase/guillemotleft=0A=
/guillemotright/bullet/florin/fraction/perthousand/dagger/daggerdbl=0A=
/endash/emdash/ff/fi/fl/ffi/ffl/dotlessi/dotlessj/grave/hungarumlaut=0A=
/dotaccent/breve/caron/ring/ogonek/quotedblleft/quotedblright/oe/lslash=0A=
/quotedblbase/OE/Lslash/.notdef/exclamdown/cent/sterling/currency/yen=0A=
/brokenbar/section/dieresis/copyright/ordfeminine/guilsinglleft=0A=
/logicalnot/minus/registered/macron/degree/plusminus/twosuperior=0A=
/threesuperior/acute/mu/paragraph/periodcentered/cedilla/onesuperior=0A=
/ordmasculine/guilsinglright/onequarter/onehalf/threequarters=0A=
/questiondown/Agrave/Aacute/Acircumflex/Atilde/Adieresis/Aring/AE=0A=
/Ccedilla/Egrave/Eacute/Ecircumflex/Edieresis/Igrave/Iacute/Icircumflex=0A=
/Idieresis/Eth/Ntilde/Ograve/Oacute/Ocircumflex/Otilde/Odieresis=0A=
/multiply/Oslash/Ugrave/Uacute/Ucircumflex/Udieresis/Yacute/Thorn=0A=
/germandbls/agrave/aacute/acircumflex/atilde/adieresis/aring/ae/ccedilla=0A=
/egrave/eacute/ecircumflex/edieresis/igrave/iacute/icircumflex/idieresis=0A=
/eth/ntilde/ograve/oacute/ocircumflex/otilde/odieresis/divide/oslash=0A=
/ugrave/uacute/ucircumflex/udieresis/yacute/thorn/ydieresis]def=0A=
/Courier@0 ENC0/Courier RE/Times-Roman@0 ENC0/Times-Roman RE=0A=
/Times-Bold@0 ENC0/Times-Bold RE/Courier-Bold@0 ENC0/Courier-Bold RE=0A=
%%EndProlog=0A=
%%Page: 1 1=0A=
%%BeginPageSetup=0A=
BP=0A=
%%EndPageSetup=0A=
/F0 10/Courier-Bold@0 SF(Internet Engineering Task Force)72 85 Q(RMT WG)=0A=
209.999 E 203.999(INTERNET-DRAFT M.Luby/Digital)72 98 R(Fountain)6 E=0A=
167.999(draft-ietf-rmt-bb-fec-04.ps L.Vicisano/Cisco)72 111 R=0A=
(J.Gemmell/Microsoft)389.999 124 Q(L.Rizzo/ACIRI and Univ. Pisa)335.999=0A=
137 Q(M.Handley/ACIRI)413.999 150 Q(J. Crowcroft/UCL)407.999 163 Q=0A=
(18 October 2001)413.999 176 Q(Expires: April 2002)389.999 189 Q/F1 14=0A=
/Times-Bold@0 SF(RMT BB F)159.144 214 Q(orward Err)-.35 E(or Corr)-.252=0A=
E(ection Codes)-.252 E/F2 11/Times-Roman@0 SF(This document is an Inter\=0A=
net-Draft and is in full conformance with all pro)72 233 Q=0A=
(visions of Section 10 of)-.165 E(RFC2026.)72 246 Q=0A=
(Internet-Drafts are w)72 272 Q=0A=
(orking documents of the Internet Engineering T)-.11 E(ask F)-.88 E=0A=
(orce \(IETF\), its areas,)-.165 E(and its w)72 285 Q(orking groups.)=0A=
-.11 E(Note that other groups may also distrib)5.5 E(ute w)-.22 E=0A=
(orking documents as)-.11 E(Internet-Drafts.)72 298 Q=0A=
(Internet-Drafts are v)72 324 Q=0A=
(alid for a maximum of six months and may be updated, replaced, or)-.275=0A=
E(obsoleted by other documents at an)72 337 Q 2.75(yt)-.165 G 2.75=0A=
(ime. It)-2.75 F(is inappropriate to use Internet-Drafts as reference)=0A=
2.75 E(material or to cite them other than as a "w)72 350 Q=0A=
(ork in progress".)-.11 E=0A=
(The list of current Internet-Drafts can be accessed at http://www)72=0A=
376 Q(.ietf.or)-.715 E(g/ietf/1id-abstracts.txt)-.198 E 1.76 -.88(To v)=0A=
72 402 T(ie).88 E 2.75(wt)-.275 G(he list Internet-Draft Shado)-2.75 E=0A=
2.75(wD)-.275 G(irectories, see http://www)-2.75 E(.ietf.or)-.715 E=0A=
(g/shado)-.198 E -.715(w.)-.275 G(html.).715 E=0A=
(This document is a product of the IETF RMT WG.)72 428 Q=0A=
(Comments should be addressed to the)5.5 E(authors, or the WG')72 441 Q=0A=
2.75(sm)-.605 G(ailing list at rmt@isi.edu.)-2.75 E/F3 11/Times-Bold@0=0A=
SF(Abstract)267.534 473 Q F2(This memo describes the abstract pack)97=0A=
495.6 Q(et formats and IAN)-.11 E 2.75(Ar)-.385 G -.165(eg)-2.75 G=0A=
(istration procedures).165 E(for use of F)97 508.6 Q(orw)-.165 E=0A=
(ard Error Correction \(FEC\) codes within the conte)-.11 E=0A=
(xt of reliable IP)-.165 E(multicast transport.)97 521.6 Q=0A=
(This memo should be read in conjunction with and uses the)5.5 E=0A=
(terminology of the companion memo [1], which describes the use of F)97=0A=
534.6 Q(orw)-.165 E(ard Error)-.11 E=0A=
(Correction \(FEC\) codes within the conte)97 547.6 Q=0A=
(xt of reliable IP multicast transport and)-.165 E(pro)97 560.6 Q=0A=
(vides an introduction to some commonly used FEC codes.)-.165 E F3(1.)72=0A=
599.6 Q F1(FEC Abstract P)5.5 E(ack)-.14 E=0A=
(et Fields and Out-of-Band Inf)-.14 E(ormation)-.35 E F2(This section d\=0A=
escribes FEC information that is either to be sent out-of-band or in pa\=0A=
ck)72 616.2 Q 2.75(ets. The)-.11 F(FEC information is associated with t\=0A=
ransmission of data about a particular object.)72 629.2 Q=0A=
(There are three)5.5 E(classes of pack)72 642.2 Q=0A=
(ets that may contain FEC information: data pack)-.11 E=0A=
(ets, session-control pack)-.11 E(ets and)-.11 E(feedback pack)72 655.2=0A=
Q 2.75(ets. The)-.11 F 2.75(yg)-.165 G(enerally contain dif)-2.75 E=0A=
(ferent kinds of FEC information.)-.275 E(Note that some)5.5 E=0A=
(protocols may not use session-control or feedback pack)72 668.2 Q(ets.)=0A=
-.11 E(Data pack)72 694.2 Q(ets may sometimes serv)-.11 E 2.75(ea)-.165=0A=
G 2.75(ss)-2.75 G(ession-control pack)-2.75 E=0A=
(ets as well; both data and session-)-.11 E(control pack)72 707.2 Q=0A=
(ets generally tra)-.11 E -.165(ve)-.22 G 2.75(ld).165 G -.275(ow)-2.75=0A=
G(nstream from the sender to).275 E -.11(wa)-.275 G(rds recei).11 E=0A=
-.165(ve)-.275 G(rs and are sent to a).165 E=0A=
(multicast channel or to a speci\214c recei)72 720.2 Q -.165(ve)-.275 G=0A=
2.75(ru).165 G(sing unicast.)-2.75 E(Luby/V)72 769 Q=0A=
(icisano/Gemmell/Rizzo/Handle)-.66 E(y/Cro)-.165 E 117.356=0A=
(wcroft Section)-.275 F 2.75(1. [P)2.75 F(age 1])-.165 E EP=0A=
%%Page: 2 2=0A=
%%BeginPageSetup=0A=
BP=0A=
%%EndPageSetup=0A=
/F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 77.081(-DRAFT Expires:)-1.012 F=0A=
(April 2002)2.75 E(October 2001)112.127 E=0A=
(As a general rule, feedback pack)72 85 Q(ets tra)-.11 E -.165(ve)-.22 G=0A=
2.75(lu).165 G(pstream from recei)-2.75 E -.165(ve)-.275 G=0A=
(rs to the sender).165 E 2.75(.S)-.605 G(ometimes,)-2.75 E(ho)72 98 Q=0A=
(we)-.275 E -.165(ve)-.275 G .88 -.44(r, t).165 H(he).44 E 2.75(ym)-.165=0A=
G(ight be sent to a multicast channel or to another recei)-2.75 E -.165=0A=
(ve)-.275 G 2.75(ro).165 G 2.75(rt)-2.75 G 2.75(os)-2.75 G=0A=
(ome intermediate)-2.75 E(node or neighboring router that pro)72 111 Q=0A=
(vides reco)-.165 E -.165(ve)-.165 G(ry services.).165 E(This document \=0A=
speci\214es the FEC information that must be carried in data pack)72 137=0A=
Q(ets and the other)-.11 E(FEC information that must be communicated ei\=0A=
ther out-of-band or in data pack)72 150 Q(ets. This)-.11 E(document doe\=0A=
s not specify out-of-band methods nor does it specify the w)72 163 Q=0A=
(ay out-of-band FEC)-.11 E=0A=
(information is associated with FEC information carried in data pack)72=0A=
176 Q 2.75(ets. These)-.11 F(methods must be)2.75 E=0A=
(speci\214ed in a complete protocol instantiation that uses the FEC b)72=0A=
189 Q(uilding block. FEC information)-.22 E(is classi\214ed as follo)72=0A=
202 Q(ws:)-.275 E 7.337(1\) FEC)74.75 231.6 R(Encoding ID)2.75 E=0A=
(Identi\214es the FEC encoder being used and allo)105 248.2 Q(ws recei)=0A=
-.275 E -.165(ve)-.275 G(rs to select the appropriate FEC).165 E=0A=
(decoder)105 261.2 Q 5.5(.T)-.605 G(he v)-5.5 E=0A=
(alue of the FEC Encoding ID MUST be the same for all transmission of)=0A=
-.275 E(data related to a particular object, b)105 274.2 Q(ut MA)-.22 E=0A=
2.75(Yv)-1.155 G(ary across dif)-3.025 E(ferent transmissions of data)=0A=
-.275 E(about dif)105 287.2 Q(ferent objects, e)-.275 E -.165(ve)-.275 G=0A=
2.75(ni).165 G 2.75(ft)-2.75 G=0A=
(ransmitted to the same set of multicast channels and/or)-2.75 E=0A=
(using a single upper)105 300.2 Q(-layer session.)-.22 E=0A=
(The FEC encoding ID is subject to IAN)5.5 E 2.75(Ar)-.385 G -.165(eg)=0A=
-2.75 G(istration.).165 E 7.337(2\) FEC)74.75 316.8 R(Encoding Name)2.75=0A=
E(Pro)105 333.4 Q(vides a more speci\214c identi\214cation of the FEC e\=0A=
ncoder being used for an Under)-.165 E(-)-.22 E(Speci\214ed FEC scheme.)=0A=
105 346.4 Q(This v)5.5 E=0A=
(alue is not used for Fully-Speci\214ed FEC schemes.)-.275 E(\(See)5.5 E=0A=
(Section 1.1 for the de\214nition of Under)105 359.4 Q=0A=
(-Speci\214ed and Fully-Speci\214ed FEC schemes.\))-.22 E(The)5.5 E(FEC\=0A=
encoding name is scoped by the FEC encoding ID, and is subject to IAN)=0A=
105 372.4 Q(A)-.385 E(re)105 385.4 Q(gistration.)-.165 E 7.337(3\) FEC)=0A=
74.75 402 R(payload ID)2.75 E=0A=
(Identi\214es the encoding symbol\(s\) in the payload of the pack)105=0A=
418.6 Q 2.75(et. The)-.11 F(\214elds in the FEC)2.75 E -.165(Pa)105=0A=
431.6 S(yload ID depend on the encoder being used \(e.g. in Block and E\=0A=
xpandable FEC codes).165 E=0A=
(this may be the combination of block number and encoding symbol ID\).)=0A=
105 444.6 Q 7.337(4\) FEC)74.75 461.2 R(Object T)2.75 E=0A=
(ransmission Information)-.385 E(This is information re)105 477.8 Q=0A=
-.055(ga)-.165 G=0A=
(rding the encoding of a speci\214c object needed by the FEC decoder)=0A=
.055 E(\(e.g. for Block and Expandable FEC codes this may be the combin\=0A=
ation of the source)105 490.8 Q(block lengths and the object length\).)=0A=
105 503.8 Q(This might also include speci\214c parameters of the)5.5 E=0A=
(FEC encoder)105 516.8 Q(.)-.605 E=0A=
(The FEC Encoding ID, FEC Encoding Name \(for Under)72 546.4 Q=0A=
(-Speci\214ed FEC schemes\) and the FEC)-.22 E(Object T)72 559.4 Q=0A=
(ransmission Information can be sent to a recei)-.385 E -.165(ve)-.275 G=0A=
2.75(rw).165 G(ithin the data pack)-2.75 E(et headers, within)-.11 E=0A=
(session control pack)72 572.4 Q(ets, or by some other means.)-.11 E=0A=
(In an)5.5 E 2.75(yc)-.165 G(ase, the means for communicating this)-2.75=0A=
E(to a recei)72 585.4 Q -.165(ve)-.275 G 2.75(ri).165 G 2.75(so)-2.75 G=0A=
(ut of the scope of this document.)-2.75 E(The FEC P)5.5 E=0A=
(ayload ID MUST be included in the)-.165 E(data pack)72 598.4 Q=0A=
(et header \214elds, as it pro)-.11 E=0A=
(vides a description of the data contained in the pack)-.165 E(et.)-.11=0A=
E -.44(Wi)72 624.4 S(thin the conte).44 E=0A=
(xt of FEC repair schemes, feedback pack)-.165 E=0A=
(ets are \(optionally\) used to request FEC)-.11 E 2.75=0A=
(retransmission. The)72 637.4 R=0A=
(FEC-related information present in feedback pack)2.75 E=0A=
(ets usually contains an)-.11 E(FEC Block ID that de\214nes the block t\=0A=
hat is being repaired, and the number of Repair Symbols)72 650.4 Q=0A=
(requested. Although this is the most common case, v)72 663.4 Q=0A=
(ariants are possible in which the recei)-.275 E -.165(ve)-.275 G(rs)=0A=
.165 E(pro)72 676.4 Q(vide more speci\214c information about the Repair\=0A=
Symbols requested \(e.g. an inde)-.165 E 2.75(xr)-.165 G(ange or a)=0A=
-2.75 E(list of symbols accepted\). It is also possible to include mult\=0A=
iple of these requests in a single)72 689.4 Q(feedback pack)72 702.4 Q=0A=
(et.)-.11 E(Luby/V)72 769 Q(icisano/Gemmell/Rizzo/Handle)-.66 E(y/Cro)=0A=
-.165 E 117.356(wcroft Section)-.275 F 2.75(1. [P)2.75 F(age 2])-.165 E=0A=
EP=0A=
%%Page: 3 3=0A=
%%BeginPageSetup=0A=
BP=0A=
%%EndPageSetup=0A=
/F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 77.081(-DRAFT Expires:)-1.012 F=0A=
(April 2002)2.75 E(October 2001)112.127 E(This document does not pro)72=0A=
85 Q(vide an)-.165 E 2.75(yd)-.165 G=0A=
(etail about feedback schemes used in combination with)-2.75 E=0A=
(FEC nor the format of FEC information in feedback pack)72 98 Q 2.75=0A=
(ets. If)-.11 F(feedback pack)2.75 E(ets are used in a)-.11 E=0A=
(complete protocol instantiation, these details must be pro)72 111 Q=0A=
(vided in the protocol instantiation)-.165 E(speci\214cation.)72 124 Q=0A=
/F1 11/Times-Bold@0 SF(1.1.)72 163 Q/F2 13/Times-Bold@0 SF=0A=
(FEC Encoding ID and FEC Encoding Name)5.5 E F0=0A=
(The FEC Encoding ID is a numeric inde)72 192.6 Q 2.75(xt)-.165 G=0A=
(hat identi\214es a speci\214c FEC scheme OR a class of)-2.75 E=0A=
(encoding schemes that share the same FEC P)72 205.6 Q=0A=
(ayload ID format.)-.165 E(An FEC scheme is a Fully-Speci\214ed FEC sch\=0A=
eme if the encoding scheme is formally and fully)72 231.6 Q=0A=
(speci\214ed, in a w)72 244.6 Q(ay that independent implementors can im\=0A=
plement both encoder and decoder from)-.11 E 2.75(as)72 257.6 S=0A=
(peci\214cation that is an IETF RFC.)-2.75 E=0A=
(The FEC Encoding ID uniquely identi\214es a Fully-Speci\214ed)5.5 E=0A=
(FEC scheme.)72 270.6 Q(Companion documents of this speci\214cation may\=0A=
specify Fully-Speci\214ed FEC)5.5 E=0A=
(schemes and associate them with FEC Encoding ID v)72 283.6 Q=0A=
(alues. These documents MUST also specify)-.275 E 2.75(af)72 296.6 S=0A=
(ormat for the FEC P)-2.75 E=0A=
(ayload ID and specify the information in the FEC Object T)-.165 E=0A=
(ransmission)-.385 E(Information.)72 309.6 Q(It is possible that a FEC \=0A=
scheme cannot be a Fully-Speci\214ed FEC scheme, because a speci\214cat\=0A=
ion)72 335.6 Q(is simply not a)72 348.6 Q -.275(va)-.22 G=0A=
(ilable or that a party e).275 E(xists that o)-.165 E=0A=
(wns the encoding scheme and is not willing to)-.275 E=0A=
(disclose the algorithm or speci\214cation. W)72 361.6 Q 2.75(er)-.88 G=0A=
(efer to such an FEC encoding schemes as an Under)-2.75 E(-)-.22 E=0A=
(Speci\214ed FEC scheme.)72 374.6 Q(The follo)5.5 E=0A=
(wing holds for an Under)-.275 E(-Speci\214ed FEC scheme:)-.22 E 11(oT)=0A=
77.5 391.2 S(he format of the FEC P)-11 E=0A=
(ayload ID and the speci\214c information in the FEC Object)-.165 E=0A=
-.385(Tr)94 404.2 S=0A=
(ansmission Information MUST be de\214ned for the Under).385 E=0A=
(-Speci\214ed FEC scheme.)-.22 E 11(oA)77.5 420.8 S -.275(va)-8.25 G=0A=
(lue for the FEC Encoding ID MUST be reserv).275 E=0A=
(ed and associated with the format of the)-.165 E(FEC P)94 433.8 Q=0A=
(ayload ID and the speci\214c information in the FEC Object T)-.165 E=0A=
(ransmission Information.)-.385 E(An already reserv)94 446.8 Q=0A=
(ed FEC Encoding ID v)-.165 E=0A=
(alue MUST be reused if it is associated with the)-.275 E=0A=
(same format of FEC P)94 459.8 Q=0A=
(ayload ID and the same information in the FEC Object T)-.165 E=0A=
(ransmission)-.385 E(Information as the ones needed for the ne)94 472.8=0A=
Q 2.75(wU)-.275 G(nder)-2.75 E(-Speci\214ed FEC scheme.)-.22 E 11(oA)=0A=
77.5 489.4 S -.275(va)-8.25 G=0A=
(lue for the FEC Encoding Name MUST be reserv).275 E(ed.)-.165 E=0A=
(An Under)72 519 Q(-speci\214ed FEC scheme is fully identi\214ed by the\=0A=
tuple \(FEC Encoding ID, FEC)-.22 E(Encoding Name\). The tuple MUST id\=0A=
entify a single scheme that has at least one implementation.)72 532 Q=0A=
(The party that o)72 545 Q(wns this tuple MUST be able to pro)-.275 E=0A=
(vide information on ho)-.165 E 2.75(wt)-.275 G 2.75(oo)-2.75 G=0A=
(btain the Under)-2.75 E(-)-.22 E(Speci\214ed FEC scheme identi\214ed b\=0A=
y the tuple, e.g. a pointer to a publicly a)72 558 Q -.275(va)-.22 G=0A=
(ilable reference-).275 E=0A=
(implementation or the name and contacts of a compan)72 571 Q 2.75(yt)=0A=
-.165 G(hat sells it, either separately or embedded)-2.75 E=0A=
(in another product.)72 584 Q(Dif)72 610 Q(ferent Under)-.275 E=0A=
(-Speci\214ed FEC schemes that share the same FEC Encoding ID -- b)-.22=0A=
E(ut ha)-.22 E -.165(ve)-.22 G(dif)72 623 Q=0A=
(ferent FEC Encoding Names -- also share the same format of FEC P)-.275=0A=
E(ayload ID and specify the)-.165 E=0A=
(same information in the FEC Object T)72 636 Q(ransmission Information.)=0A=
-.385 E(This speci\214cation reserv)72 662 Q=0A=
(es the range 0-127 for the v)-.165 E=0A=
(alues of FEC Encoding IDs for Fully-)-.275 E=0A=
(Speci\214ed FEC schemes and the range 128-255 for the v)72 675 Q=0A=
(alues of Under)-.275 E(-Speci\214ed FEC schemes.)-.22 E(Luby/V)72 769 Q=0A=
(icisano/Gemmell/Rizzo/Handle)-.66 E(y/Cro)-.165 E 109.106=0A=
(wcroft Section)-.275 F 2.75(1.1. [P)2.75 F(age 3])-.165 E EP=0A=
%%Page: 4 4=0A=
%%BeginPageSetup=0A=
BP=0A=
%%EndPageSetup=0A=
/F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 77.081(-DRAFT Expires:)-1.012 F=0A=
(April 2002)2.75 E(October 2001)112.127 E/F1 11/Times-Bold@0 SF(1.2.)72=0A=
85 Q/F2 13/Times-Bold@0 SF(FEC P)5.5 E(ayload ID and FEC Object T)-.13 E=0A=
(ransmission Inf)-.962 E(ormation)-.325 E F0 2.75(Ad)97 114.6 S=0A=
(ocument that speci\214es an FEC scheme and reserv)-2.75 E(es a v)-.165=0A=
E(alue of FEC Encoding ID MUST)-.275 E(de\214ne a pack)72 127.6 Q=0A=
(et format for the FEC P)-.11 E=0A=
(ayload ID and specify the information in the FEC Object)-.165 E -.385=0A=
(Tr)72 140.6 S(ansmission Information according to the needs of the enc\=0A=
oding scheme. This applies to).385 E(documents that reserv)72 153.6 Q=0A=
2.75(ev)-.165 G=0A=
(alues of FEC Encoding IDs for both Fully-Speci\214ed and Under)-3.025 E=0A=
(-Speci\214ed)-.22 E(FEC schemes.)72 166.6 Q(The pack)72 192.6 Q=0A=
(et format de\214nition for the FEC P)-.11 E=0A=
(ayload ID MUST specify the meaning and layout of)-.165 E=0A=
(the \214elds do)72 205.6 Q(wn to the le)-.275 E -.165(ve)-.275 G 2.75=0A=
(lo).165 G 2.75(fs)-2.75 G(peci\214c bits.)-2.75 E(The FEC P)5.5 E=0A=
(ayload ID MUST ha)-.165 E .33 -.165(ve a l)-.22 H(ength that is a).165=0A=
E(multiple of a 4-byte w)72 218.6 Q 2.75(ord. This)-.11 F(requirement f)=0A=
2.75 E(acilitates the alignment of pack)-.11 E(et \214elds in protocol)=0A=
-.11 E(instantiations.)72 231.6 Q F1(2.)72 270.6 Q/F3 14/Times-Bold@0 SF=0A=
(Pr)5.5 E(eassigned FEC Encoding IDs)-.252 E F0=0A=
(This section speci\214es the FEC Encoding ID and the associated FEC P)=0A=
72 287.2 Q(ayload ID format and the)-.165 E=0A=
(speci\214c information in the FEC Object T)72 300.2 Q=0A=
(ransmission Information for a number of kno)-.385 E(wn Under)-.275 E(-)=0A=
-.22 E(Speci\214ed FEC schemes.)72 313.2 Q(Under)5.5 E=0A=
(-speci\214ed FEC schemes that use the same FEC P)-.22 E=0A=
(ayload ID format)-.165 E=0A=
(and speci\214c information in the FEC Object T)72 326.2 Q=0A=
(ransmission Information as for one of the FEC)-.385 E(Encoding IDs spe\=0A=
ci\214ed in this section MUST use the corresponding FEC Encoding ID.)72=0A=
339.2 Q(Other)5.5 E(FEC Encoding IDs may be speci\214ed for other Under)=0A=
72 352.2 Q(-Speci\214ed FEC schemes in companion)-.22 E(documents.)72=0A=
365.2 Q F1(2.1.)72 404.2 Q F2(Small Block, Lar)5.5 E=0A=
(ge Block and Expandable FEC Codes)-.13 E F0(This subsection reserv)72=0A=
420.8 Q(es the FEC Encoding ID v)-.165 E(alue 128 for the Under)-.275 E=0A=
(-Speci\214ed FEC schemes)-.22 E=0A=
(described in [1] that are called Small Block FEC codes, Lar)72 433.8 Q=0A=
(ge Block FEC codes and Expandable)-.198 E(FEC codes.)72 446.8 Q=0A=
(The FEC P)72 472.8 Q(ayload ID is composed of a Source Block Number an\=0A=
d an Encoding Symbol ID)-.165 E(structured as follo)72 485.8 Q(ws:)-.275=0A=
E/F4 8/Courier@0 SF 91.2(0123)76.8 524.8 S 4.8=0A=
(01234567890123456789012345678901)76.8 537.8 S=0A=
(+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+)72=0A=
550.8 Q 100.8(|S)72 563.8 S(ource Block Number)-100.8 E(|)110.4 E=0A=
(+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+)72=0A=
576.8 Q 105.6(|E)72 589.8 S(ncoding Symbol ID)-105.6 E(|)110.4 E=0A=
(+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+)72=0A=
602.8 Q F0(The Source Block Number iden\214ties from which source block\=0A=
of the object the encoding)72 632.4 Q=0A=
(symbol\(s\) in the payload are generated.)72 645.4 Q=0A=
(These blocks are numbered consecuti)5.5 E -.165(ve)-.275 G=0A=
(ly from 0 to N-1,).165 E=0A=
(where N is the number of source blocks in the object.)72 658.4 Q(The E\=0A=
ncoding Symbol ID identi\214es which speci\214c encoding symbol\(s\) ge\=0A=
nerated from the source)72 684.4 Q(block are carried in the pack)72=0A=
697.4 Q(et payload.)-.11 E(The e)5.5 E=0A=
(xact details of the correspondence between)-.165 E=0A=
(Encoding Symbol IDs and the encoding symbol\(s\) in the pack)72 710.4 Q=0A=
(et payload are dependent on the)-.11 E(particular encoding algorithm u\=0A=
sed as identi\214ed by the Fec Encoding ID and by the FEC)72 723.4 Q=0A=
(Luby/V)72 769 Q(icisano/Gemmell/Rizzo/Handle)-.66 E(y/Cro)-.165 E=0A=
109.106(wcroft Section)-.275 F 2.75(2.1. [P)2.75 F(age 4])-.165 E EP=0A=
%%Page: 5 5=0A=
%%BeginPageSetup=0A=
BP=0A=
%%EndPageSetup=0A=
/F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 77.081(-DRAFT Expires:)-1.012 F=0A=
(April 2002)2.75 E(October 2001)112.127 E=0A=
(Encoding Name, and these details may be proprietary)72 85 Q(.)-.715 E=0A=
(The FEC Object T)72 111 Q(ransmission Information has the follo)-.385 E=0A=
(wing speci\214c information:)-.275 E 11(oT)77.5 140.6 S=0A=
(he total length of the object in bytes.)-11 E 11(oT)77.5 157.2 S(he nu\=0A=
mber of source blocks that the object is partitioned into, and the leng\=0A=
th of each source)-11 E(block in bytes.)94 170.2 Q/F1 11/Times-Bold@0 SF=0A=
(2.2.)72 212.8 Q/F2 13/Times-Bold@0 SF(Small Block Systematic FEC Codes)=0A=
5.5 E F0(This subsection reserv)72 229.4 Q(es the FEC Encoding ID v)=0A=
-.165 E(alue 129 for the Under)-.275 E(-Speci\214ed FEC schemes)-.22 E=0A=
(described in [1] that are called Small Block Systematic FEC codes.)72=0A=
242.4 Q -.165(Fo)5.5 G 2.75(rS).165 G(mall Block Systematic)-2.75 E=0A=
(FEC codes, each source block is of length at most 65536 bytes.)72 255.4=0A=
Q(Although these codes can generally be accommodated by the FEC Encodin\=0A=
g ID described in)72 281.4 Q(Section 2.1, a speci\214c FEC Encoding ID \=0A=
is de\214ned for Small Block Systematic FEC codes to)72 294.4 Q(allo)72=0A=
307.4 Q 2.75(wm)-.275 G(ore \215e)-2.75 E(xibility and to retain header\=0A=
compactness. The small source block length and small)-.165 E -.165(ex)=0A=
72 320.4 S(apansion f).165 E(actor that often characterize systematic c\=0A=
odes may require that the data source)-.11 E=0A=
(changes frequently the source block length. T)72 333.4 Q 2.75(oa)-.88 G=0A=
(llo)-2.75 E 2.75(wt)-.275 G(he dynamic v)-2.75 E=0A=
(ariation of the source block)-.275 E=0A=
(length and to communicate it to the recei)72 346.4 Q -.165(ve)-.275 G=0A=
(rs with lo).165 E 2.75(wo)-.275 G -.165(ve)-2.915 G=0A=
(rhead, the block length is included in).165 E(the FEC P)72 359.4 Q=0A=
(ayload ID.)-.165 E(The FEC P)72 385.4 Q=0A=
(ayload ID is composed of the Source Block Number)-.165 E 2.75(,S)-.44 G=0A=
(ource Block Length and the)-2.75 E(Encoding Symbol ID:)72 398.4 Q/F3 8=0A=
/Courier@0 SF 91.2(0123)76.8 437.4 S 4.8=0A=
(01234567890123456789012345678901)76.8 450.4 S=0A=
(+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+)72=0A=
463.4 Q 100.8(|S)72 476.4 S(ource Block Number)-100.8 E(|)110.4 E=0A=
(+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+)72=0A=
489.4 Q 28.8(|S)72 502.4 S(ource Block Length)-28.8 E 33.6(|E)28.8 G=0A=
(ncoding Symbol ID)-33.6 E(|)28.8 E=0A=
(+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+)72=0A=
515.4 Q F0(The Source Block Number iden\214ties from which source block\=0A=
of the object the encoding)72 545 Q=0A=
(symbol\(s\) in the payload are generated.)72 558 Q=0A=
(These blocks are numbered consecuti)5.5 E -.165(ve)-.275 G=0A=
(ly from 0 to N-1,).165 E=0A=
(where N is the number of source blocks in the object.)72 571 Q(The Sou\=0A=
rce Block Length is the length in units of source symbols of the source\=0A=
block identi\214ed)72 597 Q(by the Source Block Number)72 610 Q(.)-.605=0A=
E(The Encoding Symbol ID identi\214es which speci\214c encoding symbol\=0A=
\(s\) generated from the source)72 636 Q(block are carried in the pack)=0A=
72 649 Q(et payload.)-.11 E(The e)5.5 E=0A=
(xact details of the correspondence between)-.165 E=0A=
(Encoding Symbol IDs and the encoding symbol\(s\) in the pack)72 662 Q=0A=
(et payload are dependent on the)-.11 E(particular encoding algorithm u\=0A=
sed as identi\214ed by the Fec Encoding ID and by the FEC)72 675 Q=0A=
(Encoding Name, and these details may be proprietary)72 688 Q(.)-.715 E=0A=
(The FEC Object T)72 714 Q(ransmission Information has the follo)-.385 E=0A=
(wing speci\214c information:)-.275 E(Luby/V)72 769 Q=0A=
(icisano/Gemmell/Rizzo/Handle)-.66 E(y/Cro)-.165 E 109.106=0A=
(wcroft Section)-.275 F 2.75(2.2. [P)2.75 F(age 5])-.165 E EP=0A=
%%Page: 6 6=0A=
%%BeginPageSetup=0A=
BP=0A=
%%EndPageSetup=0A=
/F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 77.081(-DRAFT Expires:)-1.012 F=0A=
(April 2002)2.75 E(October 2001)112.127 E 11(oT)77.5 85 S=0A=
(he total length of the object in bytes.)-11 E 11(oT)77.5 101.6 S(he ma\=0A=
ximum length in bytes of the encoding symbols that can be generated for\=0A=
an)-11 E 2.75(ys)-.165 G(ource)-2.75 E 2.75(block. This)94 114.6 R=0A=
(\214eld is pro)2.75 E(vided to allo)-.165 E 2.75(wr)-.275 G(ecei)-2.75=0A=
E -.165(ve)-.275 G(rs to preallocate b).165 E(uf)-.22 E=0A=
(fer space that is suitable for)-.275 E(decoding to reco)94 127.6 Q=0A=
-.165(ve)-.165 G 2.75(ra).165 G .33 -.165(ny s)-2.75 H(ource block.).165=0A=
E 11(oT)77.5 144.2 S(he length in bytes of a source symbol.)-11 E/F1 11=0A=
/Times-Bold@0 SF(3.)72 186.8 Q/F2 14/Times-Bold@0 SF(IAN)5.5 E 3.5(AC)=0A=
-.28 G(onsiderations)-3.5 E F0 -1.221(Va)72 203.4 S=0A=
(lues of FEC Encoding IDs and FEC Encoding Names are subject to IAN)=0A=
1.221 E 2.75(Ar)-.385 G -.165(eg)-2.75 G(istration. FEC).165 E(Encoding\=0A=
IDs and FEC Encoding Names are hierarchical: FEC Encoding IDs scope ra\=0A=
nges of)72 216.4 Q(FEC Encoding Names.)72 229.4 Q=0A=
(Only FEC Encoding IDs that correspond to Under)5.5 E(-Speci\214ed FEC)=0A=
-.22 E(schemes scope a corresponding set of FEC Encoding Names.)72 242.4=0A=
Q(The FEC Encoding ID is a numeric non-ne)72 268.4 Q -.055(ga)-.165 G=0A=
(ti).055 E .33 -.165(ve i)-.275 H(nde).165 E=0A=
(x. In this document, the range of v)-.165 E(alues for)-.275 E=0A=
(FEC Encoding IDs is 0 and 255.)72 281.4 Q -1.221(Va)5.5 G=0A=
(lues from 0 to 127 are reserv)1.221 E(ed for Fully-Speci\214ed FEC)=0A=
-.165 E(schemes, as described in more detail in Section 1.1. The assign\=0A=
ment of a FEC Encoding ID in this)72 294.4 Q=0A=
(range can only be granted if the requestor can pro)72 307.4 Q=0A=
(vide such a speci\214cation published as an IETF)-.165 E=0A=
(RFC, as described in more detail in Section 1.1. V)72 320.4 Q=0A=
(alues from 128 to 255 are reserv)-1.221 E(ed for Under)-.165 E(-)-.22 E=0A=
(Speci\214ed FEC schemes, as described in more detail in Section 1.1. T\=0A=
his speci\214cation already)72 333.4 Q(assigns the v)72 346.4 Q=0A=
(alues 128 and 129, as described in Section 2.)-.275 E -1.221(Va)72 363=0A=
S(lues of FEC Encoding IDs can only be assigned if the required format \=0A=
for the FEC P)1.221 E(ayload ID)-.165 E=0A=
(and the speci\214c information in the FEC Object T)72 376 Q=0A=
(ransmission Information are speci\214ed in an IETF)-.385 E(RFC.)72 389=0A=
Q(Each FEC Encoding ID assigned to an Under)72 415 Q=0A=
(-Speci\214ed FEC scheme scopes an independent range)-.22 E=0A=
(of FEC Encoding Names \(i.e. the same v)72 428 Q=0A=
(alue of FEC Encoding Name can be reused for dif)-.275 E(ferent)-.275 E=0A=
(FEC Encoding IDs\). An FEC Encoding Name is a numeric non-ne)72 441 Q=0A=
-.055(ga)-.165 G(ti).055 E .33 -.165(ve i)-.275 H(nde).165 E(x.)-.165 E=0A=
(Under the scope of a FEC Encoding ID, FEC Encoding Names are assigned \=0A=
on a First Come First)72 467 Q(Serv)72 480 Q=0A=
(ed base to requestors that are able to pro)-.165 E=0A=
(vide point of contact information and a pointer to)-.165 E=0A=
(publicly accessible documentation describing the Under)72 493 Q=0A=
(-Speci\214ed FEC scheme and w)-.22 E(ays to)-.11 E=0A=
(obtain it \(e.g. a pointer to a publicly a)72 506 Q -.275(va)-.22 G=0A=
(ilable reference-implementation or the name and contacts).275 E=0A=
(of a compan)72 519 Q 2.75(yt)-.165 G(hat sells it, either separately o\=0A=
r embedded in another product\). The requestor is)-2.75 E=0A=
(responsible for k)72 532 Q(eeping this information up to date.)-.11 E=0A=
F1(4.)72 571 Q F2(Ackno)5.5 E(wledgments)-.14 E F0=0A=
(Brian Adamson contrib)72 587.6 Q=0A=
(uted to this document by shaping Section 2.2 and pro)-.22 E=0A=
(viding general)-.165 E(feedback. W)72 600.6 Q 2.75(ea)-.88 G=0A=
(lso wish to thank V)-2.75 E(incent Roca and Justin Chapwesk)-.66 E 2.75=0A=
(ef)-.11 G(or their comments.)-2.75 E F1(5.)72 639.6 Q F2(Refer)5.5 E=0A=
(ences)-.252 E F0([1] Luby)72 669.2 Q 2.75(,M)-.715 G(., V)-2.75 E=0A=
(icisano, Gemmell, J., L., Rizzo, L., Handle)-.66 E 1.43 -.715(y, M)=0A=
-.165 H 2.75(., Cro).715 F(wcroft, J., "The use of)-.275 E -.165(Fo)72=0A=
682.2 S(rw).165 E(ard Error Correction in Reliable Multicast", Internet\=0A=
draft draft-ietf-rmt-info-fec-01.txt,)-.11 E(October 2001.)72 695.2 Q=0A=
(Luby/V)72 769 Q(icisano/Gemmell/Rizzo/Handle)-.66 E(y/Cro)-.165 E=0A=
117.356(wcroft Section)-.275 F 2.75(5. [P)2.75 F(age 6])-.165 E EP=0A=
%%Page: 7 7=0A=
%%BeginPageSetup=0A=
BP=0A=
%%EndPageSetup=0A=
/F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 77.081(-DRAFT Expires:)-1.012 F=0A=
(April 2002)2.75 E(October 2001)112.127 E/F1 11/Times-Bold@0 SF(6.)72 85=0A=
Q/F2 14/Times-Bold@0 SF -.7(Au)5.5 G(thors' Addr).7 E(esses)-.252 E F0=0A=
(Michael Luby)80.25 101.6 Q(luby@digitalfountain.com)80.25 114.6 Q=0A=
(Digital F)80.25 127.6 Q(ountain, Inc.)-.165 E(39141 Ci)80.25 140.6 Q=0A=
(vic Center Dri)-.275 E -.165(ve)-.275 G(Suite 300)80.25 153.6 Q=0A=
(Fremont, CA)80.25 166.6 Q(94538)5.5 E(Lorenzo V)80.25 192.6 Q(icisano)=0A=
-.66 E(lorenzo@cisco.com)80.25 205.6 Q(cisco Systems, Inc.)80.25 218.6 Q=0A=
(170 W)80.25 231.6 Q(est T)-.88 E(asman Dr)-.88 E(.,)-.605 E=0A=
(San Jose, CA, USA, 95134)80.25 244.6 Q(Jim Gemmell)80.25 270.6 Q=0A=
(jgemmell@microsoft.com)80.25 283.6 Q(Microsoft Research)80.25 296.6 Q=0A=
(301 Ho)80.25 309.6 Q -.11(wa)-.275 G(rd St., #830).11 E=0A=
(San Francisco, CA, USA, 94105)80.25 322.6 Q(Luigi Rizzo)80.25 348.6 Q=0A=
(luigi@iet.unipi.it)80.25 361.6 Q -.44(AC)80.25 374.6 S=0A=
(IRI, 1947 Center St., Berk).44 E(ele)-.11 E 2.75(yC)-.165 G 2.75(A9)=0A=
-2.75 G(4704)-2.75 E(and)80.25 387.6 Q(Dip. di Ing. dell'Informazione)=0A=
80.25 400.6 Q(Uni)80.25 413.6 Q -.165(ve)-.275 G(rsita` di Pisa).165 E=0A=
(via Diotisalvi 2, 56126 Pisa, Italy)80.25 426.6 Q(Mark Handle)80.25=0A=
452.6 Q(y)-.165 E(mjh@aciri.or)80.25 465.6 Q(g)-.198 E -.44(AC)80.25=0A=
478.6 S(IRI).44 E(1947 Center St.)80.25 491.6 Q(Berk)80.25 504.6 Q(ele)=0A=
-.11 E 2.75(yC)-.165 G(A, USA, 94704)-2.75 E(Jon Cro)80.25 530.6 Q=0A=
(wcroft)-.275 E(J.Cro)80.25 543.6 Q(wcroft@cs.ucl.ac.uk)-.275 E=0A=
(Department of Computer Science)80.25 556.6 Q(Uni)80.25 569.6 Q -.165=0A=
(ve)-.275 G(rsity Colle).165 E(ge London)-.165 E(Go)80.25 582.6 Q=0A=
(wer Street,)-.275 E(London WC1E 6BT)80.25 595.6 Q 2.75(,U)-.814 G(K)=0A=
-2.75 E(Luby/V)72 769 Q(icisano/Gemmell/Rizzo/Handle)-.66 E(y/Cro)-.165=0A=
E 117.356(wcroft Section)-.275 F 2.75(6. [P)2.75 F(age 7])-.165 E EP=0A=
%%Page: 8 8=0A=
%%BeginPageSetup=0A=
BP=0A=
%%EndPageSetup=0A=
/F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 77.081(-DRAFT Expires:)-1.012 F=0A=
(April 2002)2.75 E(October 2001)112.127 E/F1 11/Times-Bold@0 SF(7.)72 85=0A=
Q/F2 14/Times-Bold@0 SF(Full Copyright Statement)5.5 E F0(Cop)72 101.6 Q=0A=
(yright \(C\) The Internet Society \(2001\).)-.11 E(All Rights Reserv)=0A=
5.5 E(ed.)-.165 E(This document and translations of it may be copied an\=0A=
d furnished to others, and deri)72 118.2 Q -.275(va)-.275 G(ti).275 E=0A=
.33 -.165(ve w)-.275 H(orks).055 E(that comment on or otherwise e)72=0A=
131.2 Q=0A=
(xplain it or assist in its implementation may be prepared, copied,)=0A=
-.165 E(published and distrib)72 144.2 Q=0A=
(uted, in whole or in part, without restriction of an)-.22 E 2.75(yk)=0A=
-.165 G(ind, pro)-2.75 E(vided that the)-.165 E(abo)72 157.2 Q .33 -.165=0A=
(ve c)-.165 H(op).165 E(yright notice and this paragraph are included o\=0A=
n all such copies and deri)-.11 E -.275(va)-.275 G(ti).275 E .33 -.165=0A=
(ve w)-.275 H(orks.).055 E(Ho)72 170.2 Q(we)-.275 E -.165(ve)-.275 G .88=0A=
-.44(r, t).165 H(his document itself may not be modi\214ed in an).44 E=0A=
2.75(yw)-.165 G(ay)-2.86 E 2.75(,s)-.715 G(uch as by remo)-2.75 E=0A=
(ving the)-.165 E(cop)72 183.2 Q(yright notice or references to the Int\=0A=
ernet Society or other Internet or)-.11 E -.055(ga)-.198 G(nizations, e)=0A=
.055 E(xcept as)-.165 E(needed for the purpose of de)72 196.2 Q -.165=0A=
(ve)-.275 G(loping Internet standards in which case the procedures for)=0A=
.165 E(cop)72 209.2 Q=0A=
(yrights de\214ned in the Internet languages other than English.)-.11 E=0A=
(The limited permissions granted abo)72 225.8 Q .33 -.165(ve a)-.165 H=0A=
(re perpetual and will not be re).165 E -.22(vo)-.275 G -.11(ke).22 G=0A=
2.75(db).11 G 2.75(yt)-2.75 G(he Internet)-2.75 E=0A=
(Society or its successors or assigns.)72 238.8 Q=0A=
(This document and the information contained herein is pro)72 255.4 Q=0A=
(vided on an "AS IS" basis and THE)-.165 E=0A=
(INTERNET SOCIETY AND THE INTERNET ENGINEERING T)72 268.4 Q=0A=
(ASK FORCE DISCLAIMS)-1.023 E(ALL W)72 281.4 Q=0A=
(ARRANTIES, EXPRESS OR IMPLIED, INCLUDING B)-1.32 E(UT NO)-.11 E 2.75=0A=
(TL)-.44 G(IMITED T)-2.75 E 2.75(OA)-.198 G(NY)-2.75 E -1.32(WA)72 294.4=0A=
S(RRANTY THA)1.32 E 2.75(TT)-1.221 G(HE USE OF THE INFORMA)-2.75 E=0A=
(TION HEREIN WILL NO)-1.221 E 2.75(TI)-.44 G(NFRINGE)-2.75 E=0A=
(ANY RIGHTS OR ANY IMPLIED W)72 307.4 Q(ARRANTIES OF MERCHANT)-1.32 E=0A=
(ABILITY OR FITNESS)-1.023 E(FOR A P)72 320.4 Q(AR)-1.012 E=0A=
(TICULAR PURPOSE.")-.66 E(Luby/V)72 769 Q(icisano/Gemmell/Rizzo/Handle)=0A=
-.66 E(y/Cro)-.165 E 117.356(wcroft Section)-.275 F 2.75(7. [P)2.75 F=0A=
(age 8])-.165 E EP=0A=
%%Page: 9 9=0A=
%%BeginPageSetup=0A=
BP=0A=
%%EndPageSetup=0A=
/F0 11/Times-Roman@0 SF(INTERNET)72 49 Q 77.081(-DRAFT Expires:)-1.012 F=0A=
(April 2002)2.75 E(October 2001)112.127 E(Luby/V)72 769 Q=0A=
(icisano/Gemmell/Rizzo/Handle)-.66 E(y/Cro)-.165 E 117.356=0A=
(wcroft Section)-.275 F 2.75(7. [P)2.75 F(age 9])-.165 E EP=0A=
%%Trailer=0A=
end=0A=
%%EOF=0A=
------=_NextPart_000_000F_01C157E1.43555B10--
>From owner-rmt@listserv.lbl.gov Thu Oct 18 16:13:04 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f9IN8uY10816;
Thu, 18 Oct 2001 16:08:56 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f9IN8sp10812
for <rmt@listserv.lbl.gov>; Thu, 18 Oct 2001 16:08:54 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f9IN8sB25440
for <rmt@listserv.lbl.gov>; Thu, 18 Oct 2001 16:08:54 -0700 (PDT)
Received: from mx.webfountain.com (mx.digitalfountain.com [209.219.233.39])
by SpamWall.lbl.gov (8.11.2/8.11.2) with SMTP id f9IN8rb25434
for <rmt@lbl.gov>; Thu, 18 Oct 2001 16:08:53 -0700 (PDT)
Received: (qmail 24867 invoked from network); 18 Oct 2001 23:08:47 -0000
Received: from mail.intranet (10.1.1.37)
by mx.digitalfountain.com with SMTP; 18 Oct 2001 23:08:47 -0000
Received: from magnemite (dhcp-10-1-2-226.intranet [10.1.2.226])
by mail.intranet (8.9.3/8.9.3) with SMTP id QAA06749;
Thu, 18 Oct 2001 16:08:21 -0700
X-Authentication-Warning: mail.intranet: Host dhcp-10-1-2-226.intranet [10.1.2.226] claimed to be magnemite
From: "Michael Luby" <luby@digitalfountain.com>
To: "Rmt@Lbl. Gov" <rmt@lbl.gov>
Cc: "Michael Luby" <luby@digitalfountain.com>
Subject: IETF drafts FEC INFO 01, LCT BB 02, ALC PI 03, FEC BB 04
Date: Thu, 18 Oct 2001 16:12:35 -0700
Message-ID: <MLEAJLFPEBEIKPLNBLGIGELBCAAA.luby@digitalfountain.com>
MIME-Version: 1.0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-Mimeole: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-rmt@lbl.gov
Precedence: bulk
RMTers,
Being new to the game, I obviously didn't follow the procedure that was
meant to happen (see email below). The last call for these 4 drafts will be
in two weeks, ending Thursday, November 1, after which we intend to submit
the drafts as Experimental RFCs. Sorry about the confusion.
Mike
-----Original Message-----
From: Lorenzo Vicisano [mailto:lorenzo@cisco.com]
Sent: Thursday, October 18, 2001 3:52 PM
To: luby@digitalfountain.com
Cc: lorenzo@cisco.com
Subject: WG last call ?
Hi Mike,
my intention was to post the drafts to the list, leave
'till monday for people to comment, and if there were no
comments, post the drafts to the IETF directory and
call "last call".
doing the first 2 steps at the same time (post to the list
and to the IETF) is fine (in the worst case we will have
to resubmit). But the last call implies allowing two weeks
for people to comment before submitting as an RFC.. now
this collides with the deadline of Monday that you have specified..
could you please clarify this to the rmt list (no need
to send to internet-drafts) saying that the last-call
is 2 weeks (ending Nov 1st) after which we intend to submit
the drafts as Experimental RFC.
thanks,
Lorenzo
>From owner-rmt@listserv.lbl.gov Thu Oct 18 18:46:12 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f9J1eUk16201;
Thu, 18 Oct 2001 18:40:30 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f9J1eTp16197
for <rmt@listserv.lbl.gov>; Thu, 18 Oct 2001 18:40:29 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f9J1eSp09223
for <rmt@listserv.lbl.gov>; Thu, 18 Oct 2001 18:40:28 -0700 (PDT)
Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f9J1eRW09206
for <rmt@lbl.gov>; Thu, 18 Oct 2001 18:40:27 -0700 (PDT)
Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id SAA09418; Thu, 18 Oct 2001 18:40:24 -0700 (MST)]
Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id SAA01734; Thu, 18 Oct 2001 18:40:22 -0700 (MST)]
Received: from arc.corp.mot.com (marcia.arc.corp.mot.com [10.238.80.74])
by homer.arc.corp.mot.com (8.11.2/8.11.2) with ESMTP id f9J1eKX14599;
Fri, 19 Oct 2001 11:40:20 +1000 (EST)
Message-ID: <3BCF847D.4F60F316@arc.corp.mot.com>
Date: Fri, 19 Oct 2001 11:40:13 +1000
From: Roger Kermode <rkermode@arc.corp.mot.com>
Organization: Motorola
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: rmt-list@iet.org, rmt-list <rmt@lbl.gov>
Subject: RMT Changes.. new email list, new web site
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-rmt@lbl.gov
Precedence: bulk
Dear Everyone,
As part of the ongoing efforts to help manage the ietf lists
the rmt list is changing from rmt-list@lbl.gov to rmt-list@ietf.org
All current members of the lbl.gov list have been subscribed to
the new ietf list and the archive will be moving there shortly as
well. Please use the new list for all future emails
To help us move forward I've also put together a web site for
rmt that supplements the ietf one. On it you will find more details
about where we are with drafts beyond that of their existence or
expiration. the new site can be found at
http://rmt.motlabs.com
cheers,
Roger
>From owner-rmt@listserv.lbl.gov Thu Oct 18 18:55:38 2001
Received: (from majordom@localhost)
by listserv.lbl.gov (8.11.2/8.11.2) id f9J1qCo16251;
Thu, 18 Oct 2001 18:52:12 -0700 (PDT)
X-Authentication-Warning: listserv.lbl.gov: majordom set sender to owner-rmt@listserv.lbl.gov using -f
Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f9J1qBp16247
for <rmt@listserv.lbl.gov>; Thu, 18 Oct 2001 18:52:11 -0700 (PDT)
Received: from SpamWall.lbl.gov (localhost [127.0.0.1])
by postal1.lbl.gov (8.11.2/8.11.2) with ESMTP id f9J1qAB15585
for <rmt@listserv.lbl.gov>; Thu, 18 Oct 2001 18:52:10 -0700 (PDT)
Received: from motgate.mot.com (motgate.mot.com [129.188.136.100])
by SpamWall.lbl.gov (8.11.2/8.11.2) with ESMTP id f9J1q9W15576
for <rmt@lbl.gov>; Thu, 18 Oct 2001 18:52:09 -0700 (PDT)
Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate.mot.com (motgate 2.1) with ESMTP id SAA25894 for <rmt@lbl.gov>; Thu, 18 Oct 2001 18:52:08 -0700 (MST)]
Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id SAA18238 for <rmt@lbl.gov>; Thu, 18 Oct 2001 18:52:07 -0700 (MST)]
Received: from arc.corp.mot.com (marcia.arc.corp.mot.com [10.238.80.74])
by homer.arc.corp.mot.com (8.11.2/8.11.2) with ESMTP id f9J1q5X15687;
Fri, 19 Oct 2001 11:52:05 +1000 (EST)
Message-ID: <3BCF873D.81DDD7AB@arc.corp.mot.com>
Date: Fri, 19 Oct 2001 11:51:57 +1000
From: Roger Kermode <rkermode@arc.corp.mot.com>
Organization: Motorola
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: rmt@lbl.gov, rmt@ietf.org
Subject: CORRECTION: Changes...new email list, new web site
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-rmt@lbl.gov
Precedence: bulk
Dear Everyone,
As part of the ongoing efforts to help manage the ietf lists
the rmt list is changing from rmt@lbl.gov to rmt@ietf.org
All current members of the lbl.gov list have been subscribed to
the new ietf.org list and the archive will be moving there shortly as
well. Please use the new list for all future emails
To help us move forward I've also put together a web site for
rmt that supplements the ietf one. On it you will find more details
about where we are with drafts beyond that of their existence or
expiration. the new site can be found at
http://rmt.motlabs.com
cheers,
Roger