TSVWG Meeting Minutes Incorporated into Final Agenda TSVWG Agenda for IETF 67 (San Diego) Tuesday November 7th, 2006 1520-1720 1740-1840 Chair's 1520-1530 Agenda Bashing (10 min) NOTE WELL Document Status and Accomplishments New Charter New Milestones No agenda bashing Francois - RSVP Extensions for Emergency Services 1530-1540 draft-ietf-tsvwg-emergency-rsvp-00 (10min) - Listed what was done since last meeting in response to comments on the list: * changed the admission priority from 3 to 8 bits, * inverted the encoding order * added a DRSN example to clarify the ALRP priority field, and * clarified engineered capacity limits - plan to fix the very few remaining editorial nits- Francois thinks this is ready to WGLC - ~10 hands showed they had read the doc Kwok - Aggregation of Diffserv Service Classes 1540-1550 draft-ietf-tsvwg-diffserv-class-aggr-01 (10min) - made editorial clarifications - thanks to Dave McDyson for his review - ~10 hands said they had read this doc - Kwok thinks this is ready to WGLC Fred and Martin's - An EF DSCP for Capacity-Admitted Traffic 1550-1600 draft-baker-tsvwg-admitted-voice-dscp-01 (10min) - Problem: capacity admission for real-time services, but have no concept of bandwidth (a point from RFC4542) - in the past, people have asked for a DSCP for (seemingly everything) - doc recommends what most are really asking for is about capacity admission - problem: two traffic classes (one that has no admission, and one that has admission) - Proposal is this: allow an amount un-admitted traffic and an amount of traffic that has been admitted - asking for a DSCP number - PHB is just as RFC 3246/7 o Dave McDyson: interesting doc (supporting the idea), wants a more general admission control o Bruce Davie, clarified that 3246 allows for more than one DSCP value for EF, so this is within the Diffserv rules o Georgios: likes the doc, thinks it can be used for priority and preemption scenarios o Bob Briscoe: likes the idea, but is wary that this might implicitly say that without this DSCP, there is no admitted traffic - Will make a request for WG item in a month (probably) Bruce - A Proposal to Incorporate ECN and PCN in MPLS 1600-1610 draft-davie-ecn-mpls-01 (10min) - review: we need 3 states in 2 bits, MPLS only has 3 bits - not all Diffserv classes require ECN - this talks about one thing that you could do, not the only thing you could do - remove dependency on PCN - copying ECN info to exposed header on egress is not mandatory - crossing the ECN-enabled to ECN-disabled domain is addressed - promotes a solution for ECN support in MPLS - ID is consistent with 3168 (ECN) and 3270 (MPLS-Diffserv) RFCs - authors realize ECN expertise is here in TSVWG - MPLS chair verified this is the WG for this effort o Matt Mathis: how much interest is there for MPLS vendors for marking MPLS traffic? o Bruce: support exists within his co. o Sally: thinks this would be a good WG item o Lars - who read the ID? ~15 hands up HUM for WG item 100% HUM against WG item 0% Jonathan's Reqs for Mgmt of Overload in SIP 1610-1620 draft-rosenberg-sipping-overload-reqs-02 (10min) - Pointed at the Reqs ID about overloaded SIP servers - this is a heads-up from the SIP community who is asking for help - diagram of home proxies (real routers), edge proxies (1st line servers) and UAs - diagram of a Proxy Model - looking for volunteers for simulation work along this line Bob - Policing and Accountability for Causing Congestion on Borders draft-briscoe-tsvwg-re-ecn-tcp-03 1620-1630 (10min) - Aim: trying to hold ECN Nonce at Experimental while testing this idea, as this idea is a big change to ECN. There is a religious war here - operators want to balance the ability of operators to deliver predictable service with those who want 100% edge control. Basically, without some form of admission, real time traffic is dangerous to the network, and users have differing contracts. Operators need a balance between "freedom" and "fairness". - intent: standards track - immediate intent: hold ECN nonce (RFC 3540) at experimental. Proposal is not to disrupt ECN Nonce, but to find an encoding that addresses both the ECN and re-ECN issues. - has tried to build community interest - current Internet is basically unfair, with traffic stomping on other flows everywhere - solution: allows SPs enforce policies along the balance of freedom and fairness - building a spectrum of conservative (throttle traffic) to liberal (no restrictions) - market conditions will decide this - "doing nothing" is not an answer, because things are happening - nonces is too small a step to put in an IP header - doesn't think there is running code for ECN nonce o Sally: objects to the characterization of authors adding the ECN nonce to documents to pad out the security considerations section, saying that the ECN nonce was added to RFC 3168 by the IESG, not by the document editors. o Gerrit Renker: Why an option in IPv6 and not in IPv4? o Bob: because IPv6 does everything in options while IPv4 doesn't. - graph shows in a chart the space the ECN nonce is for, and the 20x larger space the re-ECN addresses - re-ECN negotiates one common codepoint, ECN nonce doesn't - again proposes ECN nonce is held back - put in guidelines to put this into TCP and SCTP o Lars: this proposal is counter to the experimental use of the same bits in ECN nonce. The question to the community is which way do we go (to declare ECN nonce bits as done and over) or that the first way is better o Sally: one problem with holding the ECN nonce is that the codepoint is standardized in RFC 3168, and used in three other Proposed Standard RFCs (RFCs 4340, 4341, 4342), so keeping RFC 3540 at Experimental does not hold up the use of the ECN nonce in Proposed Standard protocols. o Gory: issue for v6, the ECN is an option, but not for v4? Why is this the case. o Magnus: where are we standing from a security point of view? o Bob: those networks that choose to protect themselves, get the protection, those that don't, don't get it. Self-defense is always better that relying on someone else to do it for you o Matt: is there an intersection between the two proposals? o Bob: (missed the answer) o Matt: question to the audience - how many in this room believe flow rate fairness is good (before this week's events), and who didn't? o Francois - observes that SPs have the problem that 5% of their users cause SPs to have to increase all their BW and functionality. o Lars: looking for what direction WG wants to proceed in, called for the following Hums: * Existing ECN nonce is useful HUM 0% of room * If re-ECN proposal has merit and perhaps should progress HUM 100% of room * Those that are not sure what to do HUM 0% of room Georgios - Resource Unavailability PDB 1630-1640 draft-karagiannis-ru-pdb-03 (10min) - Problem: The PDB is an approach to measurement of available capacity in a Diffserv domain from outside the domain. Can support such measurements in any Diffserv network. - Claim: this allows an external system to determine available capacity in a network. - doc provides a PDB for throughput measurements and DSCP marking or remarking them as appropriate within a loosely agreed upon SLS - what happens? Sender can block until threshold is met - for rate adaptive applications - goal is better use experience o Francois: what is the marking? o Georgios: RMD could be used, or any mechanism (none specified in the doc) o Fred: what's the intended use of this? o Georgios: this assumes that all hosts in the domain are trusted and the network does not manage its policies. o Philip: how is this info used? o Georgios: used for admission control or preemption - but assumed this is supplied by an application o Lars: the application appears to be unclear o Georgios: examples in the draft, this is a means to detect unavailability, no signaling o Anna Charny: Should the PCN WG be created, this I-D may be better homed there o Georgios agreed. - ~5 read the draft Francois - RSVP Proxy Approaches 1640-1650 draft-lefaucheur-tsvwg-rsvp-proxy-00.txt (10min) - this is a new draft - RSVP deployments are for CAC (voice/video) on WAN in Enterprise, CAC on aggregation in triple-play, also being considered for Mobile CAC on radio - RSVP doesn't necessarily have to be e2e (for the cases of a sender only RSVP capable, or receiver only RSVP capable) - showed diagram on CAC aggregation in Triple play - showed diagram on WAN with limited BW links - showed a diagram with VOD server getting a new small extension notifying it of a RESV CAC error message - talking about the problem of not having the application endpoint the same as the RSVP end or start point o Yong Xue (US DoD): this is very much needed and we would like the IETF to do it. RSVP is needed due to its support of multicast and the ability to run it over a hybrid infrastructure. - Francois wasn't sure about which direction this doc should go in, as there is a small RSVP extension called out in the doc, which means, as it is, doc needs to go for Standards Track. Another option could be to move the RSVP extension into separate doc which goes for Standards Track, while all the rest of the material on background, approaches, use cases would go for Informational Track. o James: creating the Proxy doesn't make any doc a PS, but creating the proxy while extending a PS (2205) does, so the fine line doesn't have to be walked - this as it is, is standards track based on the extension to RSVP contained o Lars: TSVWG is allowed to minor extensions to RSVP, but doing more requires 'strong' community consensus to move forward o Fred: keeps mentioning that he has talked to customer after customer after customer about this and they want these features/functions o Lars: but those customers need to come to the IETF and say this o Pratik (Lockheed Martin): has a number of customers all over the world that want this functionality and are starting to deploy RSVP, and it requires these types of extensions o Janet (NCS/CSC): she believes this is going to be used by most SPs her org will contract with o Dave McDyson (Verizon): thinks all this is good, and needs to move forward within the IETF - strong room opinion seems to favor this functionality moving forward Pasi and Sally - Cross-layer Indications for Transport Protocols draft-sarolahti-tsvwg-crosslayer-00 1650-1700 (10min) - Related to TERNLI bar-BOF in Montreal, and building on TCP Quick-Start. The idea is to collect history of work on cross-layer information management, to inform future projects and BOFs. - not specifying new protocols or extensions - Doc to classify known problems in cross-layer mechanisms - focusing on mechanisms that require network interaction - in-band and out-of-band mechanisms - v-00 is missing sections, next version will fill in text - wanted feedback on this effort o Bob: wanted on-path vs. off-path as well as in-band and out-of-band - who's read the doc - ~20 hands - Initial document well-received, editorial work is none-the-less required. Further community feedback would be useful. o Pasi asked: Should TSVWG take this up? o Lars: wait until complete doc, and see where to go Sally and Mark's - Specifying New Congestion Control Algorithms draft-floyd-cc-alt-00.txt 1700-1710 (10min) - Problem: there are many congestion control mechanisms at the IETF - Some TCP implementations haven't been through the IETF (e.g. Linux and BIC TCP) - goals: encourage new congestion control mechanisms to go through the IETF, and to give guidelines for considering CC mechanisms - provided a list of guidelines (fairness, using space capacity, difficult environments, full backoff (one packet per round trip time), performance of misbehaving nodes and outside attackers) - goal is to provide what future docs should address (each of the guidelines) explicitly - changes to make: need to state incremental deployment, provide an alternate to full backoff, etc - probably going to suggest any algorithm start in an Informational RFC o Aaron: doc didn't include transients that affect things o Sally: I agree - who's read it: ~5 hands up - The authors want this to be an BCP Gorry - MIB for the UDP-Lite protocol 1710-1720 draft-renker-tsvwg-udplite-mib-00 (10min) - Overview of UDP-Lite - UDP-Lite (RFC 3828) is UDP with a partial checksum for use in multimedia applications. It has had a working stack for a year. Discussion of MIB structure, reporting error characteristics, using 32 bit counters. - UDP-Lite has been implemented for a year (Linux 2.6.20) - what bucket used which checksum, and which bucket didn't - Doc specifies 32 bit counters, does it need to go to 64? - problem: to be able to see if a valid packet is received, but not delivered to the application - solution: you need a counter - very few nits, and waiting for feedback - question: what about gigabit speeds? o Joe Touch: pointed out potential inconsistencies o Gorry: no per connection stats o Fred: got into the SNMP reporting of 32 bit vs. 64 bit fields and counters, and ultimately suggested going to 64 to be safe o Matt: wrap-time for gigabit speeds area ridiculously small, so they should be avoided o Bert: suggested 64 bit counters should be used George's RSVP Error codes if there's draft-swallow-rsvp-user-error-spec-00.txt time - George provided an overview for this simple user error mechanism - The idea is to be able to add diagnostic error messages for testing and other reasons on an organization and usage basis. Presently, the authors ask the working group to read it and discuss. - included that nothing like exists in RSVP - provides a means to solve this area - isn't asking for any WG action, since this ID wasn't available to the WG for review prior to this meeting - will continue to progress effort for Prague