Subject: RMT Meeting Feb 10, minutes draft

From: Roger Kermode <[email-masked]>
Date: Sun, 05 Mar 2000 22:54:11 +1100

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 <[email-masked]> 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>>