IETF-69, Chicago, USA TSVWG *FINAL*MEETING*MINUTES* Thursday July 26th, 2007 0900-1130 Grand Ballroom WG Chairs: James Polk Magnus Westerlund Lars Eggert Chairs Agenda Bashing 0900-0915 (15 min) NOTE WELL Document Status and Accomplishments Milestones Review - Fred agreed to update draft-ietf-tsvwg-admitted-voice-dscp due to discussions this week Documents to have only Chair Comments on (WGLC to be asked for) - draft-ietf-ecn-mpls-01.txt - Lars presented an update - Hands to take this to WGLC, 4 for, 0 against - draft-ietf-tsvwg-udplite-mib-00.txt - Lars presented - Asked for volunteers to read it - draft-ietf-rsvp-user-error-spec-01.txt - Lars talked about this having - Magnus: During review for considering this for WG last call. Some issues was found by me. Will post these to the mailing list within a few days. - draft-ietf-tsvwg-diffserv-class-aggr-03.txt - Kwok presented one slide - Changes made to Dave McDyson's comments - Hands to take this to WGLC, ~10 for, 0 against - draft-ietf-tsvwg-emergency-rsvp - version 02 went through WG Last Call - version 03 was issued before Chicago and addressed all comments from WGLC - version 04 will be issued to: - fix a object alignment typo (pointed out by Lou) - update IANA Considerations to request extension to existing Resource-Priority Priority Values registry * Lars - UDP Guidelines 0915-0920 (5 min) draft-ietf-tsvwg-udp-guidelines-02.txt - goal is BCP - guidelines to the designers of applications and application-layer protocols that use unicast UDP - congestion control is difficult to get right, and easy to get wrong, and this is bad - apps SHOULD use TCP, SCTP or DCCP whenever they can - if you can’t use those transports, use UDP according to the rest of these guidelines - Congestion Control Guidelines: - apps that send a small number of messages - SHOULD maintain an RTT estimate, and - limit themselves to 1 outstanding message per RTT - apps that can’t maintain an RTT estimate - SHOULD use a conservative fixed timer, and - exponentially back it off under loss e.g., 500ms, such as SIP & GIST - Message Size Guidelines: - apps SHOULD NOT send messages larger than the path MTU - either implement path MTU discovery - or use IP-layer path MTU information - or don’t send anything larger than the minimum path MTU - IPv6 -> 1280 bytes - IPv4 -> min (1st-hop-MTU, 576 bytes) - Reliability Guidelines: - apps should be aware that UDP does not provide - reliability - duplication protection - reordering protection - apps SHOULD be robust in the presence of such events * Lars - Port Randomization 0920-0930 (10 min) draft-larsen-tsvwg-port-randomization-01.txt - Blind attacks against transport protocols - Port randomization - Mitigates "blind" attacks against transport protocols by obfuscating the four-tuple that identifies the target transport-protocol instance. - It's a general & proactive mitigation technique: it increases the difficulty of performing any blind attack against a transport-protocol instance, even if the vulnerability is not yet known. - It can be implemented for all of our transport protocols (TCP, UDP, DCCP, SCTP, etc.) - Already implemented (for TCP & UDP) in a variety of operating systems (at least Linux, OpenBSD, and FreeBSD). - Gives Requirements for a good port randomization algorithm - Advice is needed on port randomization - Pending changes discussed - asked for more reviews * Francois - RSVP Proxy Approaches 0930-0940 (10 min) draft-ietf-tsvwg-rsvp-proxy-approaches-01.txt - Changes from previous version discussed - Reflected outcome of list discussion with Lou Berger - Reflected outcome of list discussion with Ken Carlberg - Incorporated list input from Chris Christou on IPsec scenario - New section 4.6 on "Policy_Server-Controlled Proxy" - Based on input from Tullio Loffredo and Massimo Sassi - Rewritten Security Considerations - Renamed "Other Proxy Approaches" section into "Endsystem-Controlled Proxy" - Various clean-ups in text & pictures *Hannes - asked how this discusses how Call Control entities interact with RSVP Proxies Answer - it touches the topic and mentions candidate protocols, but doesn't prescribe which protocol is to be used - will ask for WGLC once new version is submitted * Francois - RSVP Proxy Protocol 0940-0955 (15 min) draft-ietf-tsvwg-rsvp-proxy-proto-01.txt - Reflected outcome of list discussion with John Drake: - added new section "3.1.4 Use of PathErr by Regular Receivers" - Reflected outcome of list discussion with Lou Berger: - added new section "3.1.3 Use of Path_State_Removed Flag" - Reflected list discussion on a new optional method for sender notification based on "NOTIFY" - added new section "3.2 Sender Notification via Notify Message" - Rewritten full-blown Security Considerations - Completed IANA Considerations - added specification for Error Value (for "Unrecoverable Receiver Proxy Error" Error Code) - added text on handling of "InPlace" flag - Create an optional more efficient approach by use of the RFC 3473 NOTIFY message, to have the NOTIFY message sent by the RSVP node experiencing problem that would cause ResvErr message to be sent to receiver proxy (which would otherwise send a PathErr message to the PATH originator) *Lou Berger - supports this approach, and wants this extension by leveraging what's useful *Magnus is questioning if because NOTIFY was defined for GMPLS, should this be used by RSVP? *Lou agreed this is a valid question, but argues this is already optional, why not take advantage of this *Dimitry: is the Notify Request Object also sent by Proxy? *Francois: Yes *Lars wants comments on list on the optional approach using NOTIFY for RSVP * James - Signaled Domain_Subdomain ID 0955-1005 (10 min) draft-polk-tsvwg-signaled-domain-id-00.txt - admitted this ID is not complete (i.e., not all problems/interactions are worked out) - Create ability to subdivide an administrative domain into parts to apply different flow treatments based on which subdomain a flow is identified in/from - Necessitates primary administrative domains also be defined/identified - One Specific Use-case - US DOD wants to divide their network(s) into subdomains, called Precedence Domains *Bob wanted clarification of problem space, is a call a flow? And what happens when one subdomain contacts a node in another domain. - Are you interested in policy based on the location of the flow's sender, receiver or either/both? - Flows are between endpoints and they _cross_ network domains. It is always tricky to know if an endpoint is "in" (directly attached to) a remote domain. *James - in this case, a SIP call creates a RSVP flow (i.e., they are the same); and agreed the inter-subdomain behavior has to be addressed - Proposal - Create a new element for use by protocols such as RSVP and COPS identifying domains and subdomains, to apply different rules to these different flows *Hannes - is this WG going to take a stand on which control protocol is used? *Lars - TSV is not the right place *Hannes - but this is needed, as RSVP is the protocol favorite of this WG *Lars - this won't happen in the Transport Area * Hannes - some sense of the overall architecture is good to understand *Lou - he agrees, and makes the point that there's COPS, RADIUS and DIAMETER (what Hannes chairs), and most operators state COPS is *not* the preferred choice *James - but there is also rumors of operators not liking RSVP because it doesn't scale (or something... ;-) * Lou reluctantly agreed to this - Dependent on PREEMPTION_PRI element - Errors (currently) in PREEMPTION_PRI * Melinda like the general idea, but is hung up on the naming, and wants to know how ridged DOD is about all this *James - DOD seems to be ridged on the requirements, but not necessarily on the solution shape (what it looks like) *Ken wants authors to address all his questions *James - will do * Melinda thinks there may be some issues with authorization *James - this seems to be a large issue with this whole idea *Janet is concerned by the potential confusion with this ID verses rsvp-emergency ID in WGLC. *James - will iron this out - seems to be interest, authors need to gain traction of this idea on list * Michael - A framework for RSVP Security using dynamic group-keying 1005-1020 (15 min) draft-behringer-tsvwg-rsvp-security-groupkeying-00.txt - Writing Security Considerations section for each new "RSVP extension for Foo" I-D (painfully) showed that: - Applicability of existing RSVP security mechanism is not sufficiently documented - Existing key approaches have limitations - New key approaches could help alleviate/remove some limitations - Use a group key server (GKS) to distribute group keys (GK) and policy to RSVP nodes; used for RSVP Authentication - GDOI distributed group keys are dynamically provisioned - easier to use than static peer/if keys - Usage: RSVP Authentication and Encryption - Goal of document: - describe applicability, security of these keying approaches for RSVP - Per Neighbor / Interface Keys - Works intra-domain - Works inter-domain - Does not work easily across non-RSVP nodes - Note: regular RSVP (without authentication) does! - Group Keys - Work intra-domain - Do not work inter-domain (not applicable). - Assume: domain = zone of trust - Cannot apply same key across zones of trust - Works across non-RSVP nodes - Impact of Subverted Nodes - Subverted: Not trusted - Under control of hacker, misconfigured, buggy, etc - Single subverted node can - reserve all bandwidth through it *Hannes - thinks this is a useful effort * Francois – note that there is a companion document (draft-weis-gdoi-for-rsvp-00.txt) submitted under MSEC, defining the GDOI extension for RSVP Authentication * Bruce - Support for RSVP in Layer 3 VPNs 1020-1035 (15 min) draft-davie-tsvwg-rsvp-l3vpn-00.txt - Problem Overview - Admission control may be desired on CE<=>PE links of layer 3 VPNs (RFC4364) - Running RSVP across these links presents several issues: - Need to associate RSVP messages (which contain C addresses) with appropriate VRF context when they arrive at PE across backbone - customer address spaces may overlap - Need to intercept Path messages at egress PE but Router Alert IP option may not be visible/accessible - May also wish to perform admission control for e2e flows in backbone - RFC4364 basics: - PEs have multiple routing/forwarding tables (VRFs) - Customer address spaces may overlap - Packets from CEs are normally associated with a VRF based on incoming interface - Packets are tunneled from PE to PE (e.g. over MPLS LSP) - Overview of Proposed Solution - New objects in Path, Resv etc. to identify appropriate VRF context during RSVP processing - Control-plane approach to direct Path messages to egress PE for processing, avoiding need for Router Alert handling in data plane - RSVP over TE tunnels as per RFC 4804 if admission control over provider backbone required - Path message at ingress PE - Path message at egress PE - Resv message at egress PE - Resv message at ingress PE - created new RSVP object - VPN_LABEL object: Class = TBA, C-Type = 1 - Admission control on PE-CE links would be useful - Small set of new mechanisms makes RSVP work in VRF context and solves router alert issue - Put VRF ID and VPN label in forward messages; echo VRF ID in reverse messages - Address Path messages directly to egress PE - Admission control over backbone is optional, leverages existing techniques (RFC 4804) *Maria - said this is useful, asked about scalability *Bruce - need to give guidance about RSVP not being able to bring a box to its knees *Bob - thinks this is an important problem to solve *Yuji Kamite - What about admission control from PE? *Bruce - assumption some providers will have sufficiently provisioned core (from PE to PE), while others will not - this draft covers both cases ( admission on CE-PE only, or on both CE-PE AND PE-PE) * Michael - Avoiding Interactions of Quick-Start TCP and Flow Control 1035-1045 (10 min) draft-scharf-tsvwg-quick-start-flow-control-01.txt - this is a doc that will move to TCPM next meeting - Quick-Start TCP Extension (RFC 4782) - Interactions with TCP Flow Control - Requires optimized receive buffer allocation - RFC 1323 window scaling - Only recommends the "additional ACK" method - Brief discussion whether to send one or multiple additional ACKs - * Bob's - Byte and Packet Congestion Notification 1045-1055 (10 min) draft-briscoe-tsvwg-byte-pkt-mark-00.txt - intended status: informational - immediate intent: move to WG item - exec summary - adjust for bytes when transport reads NOT when network writes - i.e. byte-size of packets notifying congestion (whether dropped or ECN marked) - byte-mode packet drop (small packet -> lower drop probability)? - AQM / RED RFC2309 (sort-of) recommends it - propose 'SHOULD NOT' to avoid perverse incentive to create small packets - survey of >80 vendors (~20% responded): none implemented anyway - NOTE: only 'byte mode packet drop' deprecated - 'byte mode queue measurement' (often called just 'byte mode') is OK - example: comparing each RED mode (byte mode vs. packet mode) - packet mode SHOULD be used - byte mode SHOULD NOT be used - layer to adjust rate for size of a dropped packet - network layer or transport layer? - chart showed SHOULD NOT do at network layer - NOTE: don’t turn off RED completely: favours small packets - at least as much as RED byte mode packet drop - NOTE again: only byte mode packet drop deprecated - byte mode queue measurement (often called just 'byte mode') is OK *Sally - stated clearly this is not an update to RFC2309. *Bob: The ID doesn't say it updates 2309. That's just something I said in the presentation, which I'm happy to retract. * Bob's - Layered Encapsulation of Congestion Notification 1055-1105 (10 min) draft-briscoe-tsvwg-ecn-tunnel-00.txt - intended status: standards track - immediate intent: move to WG item and discuss widening scope - exec summary - propose to update RFC3168 ECN tunnel behaviour for all IP in IP – only wire protocol processing, not marking or response algorithms - to bring into line with new RFC4301 IPsec ECN behaviour - defines default tunnel processing of ECN field for all Diffserv PHBs – but also gives guidance on alternatives for specific PHBs (e.g. PCN) and for specific link encapsulations (e.g. MPLS) - why update ECN RFC3168 now? - non-IPsec tunnels left not copying CE at ingress - copying of whole ECN field at tunnel ingress is more straightforward - PCN & ECN in MPLS currently being defined; simply copying ECN – update RFC3168 now, so all consistent: IPsec, non-IPsec, PCN, MPLS - widen scope of draft? - PCN will probably do 2-level congestion marking *David Black - supports this update *Gory - Does this just copy the 2 bits of the IPsec field? *David - Almost, copy the 2 bit ECN field to the outer header on IPsec tunnel ingress, propagate CE markings back to the inner header on egress * Sally's - Comments on the Usefulness of Simple Best-Effort Traffic 1105-1115 (10 min) draft-floyd-tsvwg-besteffort-00.txt - intended to be a private informational - The Usefulness of Simple Best-Effort Traffic - Minimal technical demands on the network infrastructure. - Minimal demands in terms of economic infrastructure. - Getting a share of the available bandwidth. - The Limitations of Simple Best-Effort Traffic - QoS - The enforcement of fairness. - The Limitations of Flow-based Fairness for Simple Best-Effort Traffic - The difficulties of enforcement. - How is flow-based fairness defined? – Granularity? – RTT-fairness? – Multiple congested routers? – Bursty vs. smooth traffic? – Packets vs. bytes? – Unicast vs. multicast? - Fairness over time? *Tim Shepard: What about where we go from here? What do you propose to do about heavy users? *Sally: Network operator is entitled to determine the balance of applications using its network * Bob's - Flow Rate Fairness: Dismantling a Religion 1115-1125 (10 min) draft-briscoe-tsvarea-fair-02.pdf - very little time to give this preso - not intending to replace existing regime, only adding - we've got nothing to stop much more selfish apps evolving - today fairness enforcement all outside IETF - want to reveal an app-neutral metric (congestion) to operators for balancing network usage - the substance hasn't changed *Lars offered that we might think about next meeting having an hour in Vancouver in TSV-AREA *David Black - agreed to this - Bob - not intending this ID to be adopted by the IETF, and might let ID die *Ted - if we want to keep talking about part of it, he should keep ID alive *Bob: Lou Burness volunteered to edit (+co-authors from list) a forward looking informational I-D