[Tsvwg] DRAFT TSVWG meeting notes - corrections requested

["James M. Polk" <[e-mail]>]

TSVWG

Here are the DRAFT notes for our meeting in Dallas. These are not short 
notes, as there was a lot going on during the meeting, and we included the 
Bar BoF notes for those that did not or could not attend.

I've added a new section, called a Hum report, to review what the room 
agreed to.  Objections to any hum ought to be made asap, for the good of 
the group's progress.

Please offer corrections, modifications, deletions, additions..... (in a 
timely manner)

I'd like to upload these sometime later next week

+++++++++++++++++++++
TSVWG Session
Wednesday, March 22nd, 2006
0900-1130                                   Attendance 36+19=55 people

Chair's                                                 9:00-9:15
       Agenda Bashing                                    (15 min)
       NOTE WELL
       Document Status and Accomplishments
       New Charter?
       New Milestones?

No Agenda Bashing
- Matt said his TCP MIB Ext doc is ready for WGLC (see below)

- During Doc Status - to consider
   draft-ietf-tsvwg-vpn-signaled-preemption WGLC worthy (hum 100% for,
   0% against)

Bar BoF formal WG Announcement

- Gerald Ash was concerned of the scope of the bar BOF. Not prepared to
   present work there.
- Georgios balked at not having time to prepare slides
- Allison said to deal with it

Aaron's                                         9:15-9:25 (until 9:26)
Congestion Control Research Group               (10 min)

- Discussed congestion control RG
- Problem: High throughput requires unrealistic low packet loss rate,
       ==> low throughput in lossy environments
- Plan  4 Phases  Challenge, Solution Proposals, Discussion, Consensus;
- Rec to IETF.

Michael and Randy's                             9:25-9:35  (until 9:39)
draft-tuexen-tsvwg-sctp-padding-00              (10 min)
(might want to add SCTP auth and addip to here)

- Padding chuck is needed by path MTU discovery
- Need motivation in doc
- Lars suggested that the doc be split in two (padding and the other
   stuff)
- Matt said a lack of motivation is good to stay as is
- Michael said <something?>
- Hum to adopt as WG item (knowing sec sect needs a bit more)
- Hum 100% for adopting, 0% against

- ADDIP
       - Not intended for mobility, unlike DCCP
       - Need to slightly modify before progressing to WGLC

- SCTP-AUTH has known dependencies that are needed
       - AUTH Only want to secure ADDIP
       - Needs clarification of Null key, Key Identifier
       - Need to slightly modify before progressing to WGLC
       - Must go together with ADDIP through process

Kwok's                                          9:35-9:45  (until 9:51)
draft-chan-tsvwg-diffserv-class-aggr-03         (10 min)

- Fred presented
- Motivation to provide less granular treatments
- Editorial changes
- Changed name of default class
- Dave McDyson believe this should go to WG status and his network will
   use this
- Dave Blacks thinks this is a good idea and should be a WG item
- Hum for WG status (100% pass, 0% against)
- Dave Black will be a reviewer
- Magnus thinks this ought to have mail-list confirmation for WG status

Phil's                                          9:45-9:57  (until 9:57)
draft-briscoe-tsvwg-cl-phb-01.txt               (12 min)
draft-briscoe-tsvwg-cl-architecture-02.txt

- Split document into two (a deployment ID and a marking ID)
- CL-Arch has changes (on a slide)
- CL-PHB has changes (on a slide)
- Problem: they have 5 things to encode, and 4 possibilities, so
   creativity is necessary
- Asked that folks come to the Bar BoF and give comments and feedback

Bob's                                          9:57-10:15 (until 10:21)
draft-briscoe-tsvwg-re-ecn-tcp-01.txt           (18 min)
draft-briscoe-tsvwg-re-ecn-border-cheat-00.txt

- RE-ECN-TCP
       - About adding accountability to IP congestion
       - How to allow some networks to do policing.
       - Allow different networks to deploy different policies some
         conservative, some liberal.
       - Backwards compatible with the Evil Bit
       - Goal is also to motivate the use of ECN to allow congestion
         marks to be able to be taken advantage of by SPs
       - Question from someone - Problem finding the extra bit in a IPv6
         header, but there is the problem of by adding a bit - you need
         to add a whole 128 bit extension
       - Dave Black wants to open up discussion on using the last bit as
         a real discussion point
         - He's also concerned about the differences between this
           solution in v4 vs. v6 (which isn't public yet)
       - Allison offered that perhaps a creative use of the flow label
         in v6 could be the answer

- RE-ECN-Border
       - Chairs only allowed 1 slide of preso due to time
       - Gave short summary only

Matt's                                        10:15-10:25 (until 10:24)
draft-ietf-tsvwg-tcp-mib-extension-08.txt       (10 min)

- MIB Dr didn't give many comments
- MIB Dr said it's basically done
- There was a template problem that wasn't caught, but this can be
   corrected during the WGLC process
- Ready for WGLC

Francois's                                    10:25-10:40 (until 10:53)
draft-lefaucheur-emergency-rsvp-00              (20 min)
draft-ietf-tsvwg-rsvp-ipsec

- RSVP-IPSec
       - Removed SPI from what identifies the Reservations
       - This made everything here simpler
       - Added notion of extended virtual destination port, also used in
         MPLS
       - Hum to WGLC (100% pass)
       - Agenda had a mistake that this was a individual status (the
         chairs take the hit on that one)

- RSVP-Emergency
       - Discussed capacity handling in a number of ways based on a
         local configuration
       - Speaker asked to take this
       - Gerald Ash - how is this mech mapped to the RPH
       - James answered - that SIP is disconnected from Router
         behaviors, and that local policy determines the mapping from
         the RPH to RSVP Priority values and treatments
       - Janet commented - <missed it>
       - Georgios asked about if there are too many higher priority
         calls, at what point, at what capacity does this doc suggest to
         terminate calls
       - Francois answer that preemption is not discussed
       - Allison commented on reorganizing the doc but separating the BW
         model from the mechanism, as this ID is clearly a PS track, but
         the model is not - so it can be in an appendix
       - Francois to think about that

Sally's                                     10:40-10:50   (until 11:09)
draft-ietf-tsvwg-quickstart                     (10 min)

- Mitchell Airblix (sp?) comments off-line will cause a few more
   paragraphs to be added to the ID
- Tim Sheppard - Multi-Access link Ethernet scenario is clearly
   problematic (and Sally agreed)
- This won’t work if TCP header is encrypted (military nets) but there
   are some nets where this will work.
- Assumption is that this mechanism will never ever be a default
   enabled feature
- Fred - asked who the audience to be then?
- Sally - expects to be used in very high BW little used intra-
   networks, ID clearly lists numerous cases in which this mechanism
   will not work - including anytime a packet in tunneled
- Bob Briscoe - believes this could work in a server farm
- Randy Stewart - asked about IPv6
- Sally - this is fine in IPv6
- Lou Berger - believes this is limited in scope

Jukka's and Markku's                          10:50-11:00 (until 11:19)
draft-manner-tsvwg-lrsvp-00                      (10 min)

- This is not a new ID
- Motivation: clearly e2e QoS is not here, and in times that the remote
   node is not RSVP enable, this mechanism allows RSVP as far as it can,
   and not mandate e2e or even a mechanism at the remote node.
- Reviewed the 2 extensions necessary to enable this mechanism
- Wants 2 bits from Session Object, 2 new message types.
- Francois - thinks there is value is documenting proxy behavior, not
   clear that the endsystem needs to be the starter of this mechanism
   (i.e. a L-RSVP proxy in a early router, more like edge-to-edge)
       - Will send comments to the list now
- Bob - interested how a pair of hosts will ever know if there are in
   this situation or not, perhaps adding a new protocol ID could help
   identify it
       - Will also send comments to the list now that he understand this
         (from the preso, as he didn't from the ID itself)
- No vote for WG status vs. the slide suggestion of moving to an EXP
   status
- Chairs asked for list comments before going forward in either
   direction

Jonathan's                                      11:00-11:10
draft-rosenberg-sipping-overload-reqs-00        (10 min)

- This preso was skipped

Transport Area Chairs Update                 11:10-11:25 (until 11:32)
DCCP Chair (Lars Eggert)                        (15 min)

- Gave overview of DCCP to TSVWG
       - specs pending.
       - WG being rechartered.
       - New chair Gorry

RMT rep (Allison stepping in)

- Reliable Multicast WG is moving their documents from experimental to
   proposed this spring. Flute/ACL with a NACK protocol. One called NORM
   with building blocks.. giant group of protocols going to PS.. must
   look at very closely...

IPPM rep (Matthew J Zekauskas)

- Gave overview of IPPM to TSVWG
- Chartered to do metrics for paths
- list of them on slides.
- Cooperate with ITU
- Did all the low hanging fruit first (slide 7)
- No bulk transfer capacity metric yet.
- Slide 8/9 more completed work.
- Still working .. stuff in page 10.
    reordering moving forward WGLC.

====================================
Hum Report

A review of Hums taken during the meeting:

- draft-ietf-tsvwg-vpn-signaled-preemption-00 considered WGLC worthy
   (hum 100% for, 0% against)
- draft-ietf-tsvwg-rsvp-ipsec-00 considered WGLC worthy (hum 100% for,
   0% against)
- draft-tuexen-tsvwg-sctp-padding-00 to be WG item (hum 100% for, 0%
   against)
- draft-chan-tsvwg-diffserv-class-aggr-03 to be WG item (hum 100% for,
   0% against)

no other hums were asked for.

====================================
CL+RMD Bar BoF                           attendance:  13+15+5=33

Chairing James Polk

Francois on the overall approaches.

Edge2Edge/Controlled Deployment Model

David Black: Assumption that all in PCN domain are in on the PCN. That
domain is then interacting with ECN routers.

PCN is associated with some changes in the ECN field treatment. What
are opportunities if there are mixed ECN and PCN end to end. The model
discussed is an Edge to Edge/controlled. Important to consider these
models when doing the discussion.

See first model slide for this model.

The end system does not need to be trusted.
There is the use of normal RSVP to the end system.

End to end/open deployment model is the other version. Consider mixed
usage model with PCN and ECN.

Questions:

A) Focus on edge to edge/controlled

B) Decide that we want to address both edge to edge and end-to-end.

c) Work out viability of end-to-end/open first?

Are there other models to cover?


Pratik Bose: Will ECN have the same meaning in end to end and
edge-to-edge?

?: Experimental solution for end to end. Use different marking system
and how would they be used? Need input how fast we should go forward.

David Black: Focus on A. Mechanism are used seem to be fine granularity
adjustments that would not be available in end-to-end. Figure out
co-existence with normal ECN (RFC 3168).

Bob Briscoe: Started thinking about the end-to-end case and could not
easily resolve it. That why we started with edge to edge. Requires
reasonable behavior from systems, more likely in network than end
hosts.

Encoding
--------
Presentation of 4 alternatives.

Bob Briscoe: Do people believe this should be done in ECN or in the
DSCP field?

François: Why would you use DSCP in a controlled environment?
What is the motivation for this?

John Anders: Is okay to use another DSCP codepoint, like alt 1?

David Black: It is no obvious that you need to use another code point
as you could filter them into another traffic class and not handle that
with PCN end to end.

François: Filter voice into its own DSCP. Have the PCN behavior depend
on the DSCP.

James: Is this a local decision on what to use?

David Black: No, especially for alt 1. One thing that is happening. Not
have the ECN field to depend on the DSCP.

Bob: Use AM control to traffic that handle ECN. Non ECN is static
assignments.

François: No problem in the controlled environment to use one DSCP.
Down path it might be a bigger problem. Like MPLS. EXP is scarce and
using EXP for this may not be available

Kwok: Pretty open on this issue.

Divide it on DSCP and have that control the ECN behavior:

David Black: As DSCP are operator dependent this can be a problem.
Complexity problem. Would be good to standardize one way to do this.

François: Good to do this in one way for Hard ware support.

Kwok: Not have ECT encoding within a the field. Question on what is
better to use.

David Black: This is not obvious. Needs to go to the list.

François: Goal was to get people thinking.

Initial simulation Study
Anna Charny: Limited applicability. It works in the simulation we have
done. Not done a complete verification. This is a proof of concept. And
a demonstration that there is ongoing simulation work.


PCN/RMD
François: Pre congestion marking: STD or EXP?

John Loughney: Good bring to that into NSIS is supported.
There is a individual draft for integrated service control load:
Will post the draft ref to the TSVWG list.

Bob: Do people think it is enough that PHB and ECN marking is
specified. Do we need to a top level document declaring that
combination that is required to get the service? This would be a one
page.

Restatement

David Black: From process point of view separating ECN from PHB is a
better question. Would provide better clarity.

Anna: A PDB document would need to define a lot of behavior and group
things together.

David Black: It will probably be needed to define how the border
handling is done between domains.

Jozef: Do we need a PDB that defines both the DSCP and ECN.

David black: Sloppy use of PDB. Document needs to define the domain
behavior, not necessarily a Diffserv behavior.


Bob: Are people here for interest, or to actually contribute.

How many people would contribute to this work and review:
14


James
Lars
Magnus
	IETF TSVWG co-chairs