Subject: 51st IETF London RMT Minutes

From: Roger Kermode <[email-masked]>
Date: Fri, 07 Sep 2001 15:44:04 +1000

Reliable Mulitcast Transport (rmt) WG
51st IETF, London
Minute Taker: Jon Crowcroft, [email-masked]
Chairs: Roger Kermode, [email-masked]
        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...