IETF-74, San Francisco, CA, US TSVWG *FINAL*MINUTES* Thursday, March 26th, 2009 1300-1500 WG Chairs: James Polk Magnus Westerlund Lars Eggert Chairs Agenda Bashing 1300-1315 (15 min) - changed the order of the presos NOTE WELL Document Status and Accomplishments Update on draft-ietf-tsvwg-emergency-rsvp-10.txt James: RSVP extensions for emergency services returned to WG from IESG 5-6 discusses, rest abstains, no objections. in IESG queue 6 mos. defended doc for 75 minutes (in a 5 min slot); revision reached impasse. IESG highly recommends reconsidering scope/motivation (applicability) -- mechanism was OK. Goal to make it RSVP mechanism. Janet Gunn: appendix A is useful; will it remain? (examples) Francois Le Faucheur: examples will stay. Janet: dependency in DIME to define an APP? based on same token. their doc removed reference. it would be useful to put that back. Ken Carlberg: work in diameter? (yes) I'm tracking that. May have subsequent document coming out. To recap -- plan is to rip out context put in sec 1/2 of the draft; i.e., this is just an extension to RSVP. James: 4 IDs past WG last call - L3VPNs -- needs proto write-up - EF DSCP for capacity admitted traffic - needs revision - RSVP proxy approaches, - RSVP proxy protocols - need external review Francois: RSVP proxy docs complete, stable, frozen. all hanging on router panic issue. waiting for AD go-ahead. James: Magnus has to review last changes for both; approaches doc is the main one waiting review. Francois: does panic hold these docs up? tied to discussion in RTG area. Magnus (via jabber): RTG area requested review, and we're waiting for that. James: port randomization ready for WGLC. review of current milestones. Lars: ACTION: update milestone dates; bump by 1 year James: looking for single chair volunteer to replace the ADs as TSV chair - ADs want to be freed from chairing any WGs, to concentrate on AD responsibilities - prefer for volunteers to commit to not authoring within this WG. Milestones Review * Francois- Applicability of Keying Methods for RSVP Security draft-ietf-tsvwg-rsvp-security-groupkeying 1315-1325 (10 min) Francois - IPsec Tunnel mode (5374) - address preservation + group keying - can be used per hop, and not-RSVP hops - challenge for tunnel mode - Section 9 summary table Bob - issue with outer header - action point - makes sure issue out header is discussed Bob Briscoe: haven't read draft, but... - seeing tunnel mode with adr preservation, - seems like it protects differently - can be redirected without endpoint knowing - wants WGLC Francois: can send packet elsewhere, but same effect at the destination Lars: clarifies. can modify destination router, - path, or other header properties. Francois: believes all outstanding issues complete. propose WGLC. - maybe add something to address Bob's concerns - i.e., tampering with outer header in case of - tunnel mode with address preservation Lars called folks to review doc for WGLC - no one read latest version Lars: Francois needs to lobby folks to review doc before there can be a WGLC - who volunteers to review it? (no hands) Francois accepted this * Randy/Michael - General update on SCTP IDs 1325-1345 (20 min) draft-ietf-tsvwg-sctpsocket - delayed because of DTLS support - issue #1 extending API - kept finding new parameters that needed to be added - all having to do with CMSGs Lars - questioning whether they really need to make this so extensible - answer: each CMSG is how to plug in the API Each extension needs to have a way to use API - Michael agreed - Resolving generalization of SENDER_DRY notification (wrt notifications storms) - folks seem to want this for RDMA draft-ietf-tsvwg-dtls-for-sctp - they have implemented and tested it - what is missing is sec cons section (Eric to do) draft-tuexen-tsvwg-sctp-sack-immediately - about data chunk header - RFC4960 only deals with receiver, not sender - partially implemented in FREEBSD 8.0 - mitigates consequences of misconfigurations - delayed SACK timer and RTO timer - saves up to a second for the DTLS handshake - need a bit in the header, but there's no way to get it there Joe - issue with how marginal the improvement is (i.e., 7-8%), and it takes all this change to the protocol to get this little result. Gorry - joined in the issue about how little this benefits the protocol. Brian - asked about round-trip times (4 RTT vs. RTTs + 1 second). He says this is a big issue (i.e., believes this should be done). Joe - need to show a graph with the LAN vs. WAN impact - Michael will bring this to the next meeting or to the list draft-stewart-tsvwg-sctpstrrst - tested for interop in Aug 2007 - concept of adding streams came up - requested by IPFIX Matt - is there any downside other than our energy? Michael - not that he's aware of Brian (IPFIX WG) - do this or reset the association, which is a problem Lars - that would motivate us to take this on Matt - this feels like an oversight in the original spec Randy - he agrees, and because he was talked out of having it the first Time Lars: strong case to take it on - anyone opposed? (no hands) - will confirm on the list; seems reasonable to take on Lars: we will confirm to the list draft-stewart-tsvwg-sctp-nonce - needs to be more than info - modifies bit in the SACK header Lars - can be experimental - TCP nonce is experimental; right target for this too. Bob - what are you trying to get out of this? - prevent folks from lying Bob - you can't do that at the transport layer - ecn nonce is turn off by default - due to large vendor's bad Implementation (circa 2004) Lars - clearly in scope. Should we pursue this work? Gorry - thinks we should encourage the use of ECN, but not clear if this doc helps that Lars: will this doc encourage ECN? seems like an operator issue not an endsystem issue Randall: doc is brief - expand like TCP ECN doc to motivate Lars: not against these SCTP extensions are they above bar, are they useful for IETF to spend cycles on them the question is do we want to do this here, not is this a good idea can decide later. - has anyone read ANY doc for this sec? Gorry -- good. we can stop having these meetings if silence continues - * James's - Integrated Services Extension to Allow Multiple TSPECs draft-polk-tsvwg-intserv-multiple-tspec 1345-1400 (15 min) - talked through preso Lars - questioning what I mean by "bandwidths" in TSPEC. - clarified this is describing individual TSPECs Lars: how many TSPECs can you have upper limit? James: none per se Lars: walks through protocol diagram, can end up with N packets going to called node -- i.e., can result in an amplification attack. can't see how to fix. higher level question -- what are the tradeoffs of introducing this option? Bob: just pace the messages Lars: pacing is not a mech for amplification attacks. not reducing the load. still amplifies. James: can cap the number of TSPECs to, e.g., 4 will limit the effect of amplification? Lars: this guidance would work, for whatever number we choose. Joe: keep options not tried and rationale in appendix (so the WG doesn't question "why this one?" in the future). (all agree) Lou Berger: same as asymmetric BW in RSVP are you doing anything in RSVP with alternatives? - really an Intserv thing - should be a single solution at the Intserv level, not introduce this as an RSVP option. One alternative makes more sense -- don't do option #1. James: option 1 is most confusing; - option 3 is most backward compatible; - exist reserved fields and could support other ways but now routers on the path need to understand this Francois: prefers option #3 James: option 3 seems obviously preferred because of compatibility Lou Berger: says this is similar to asymmetric RSVP in multicast - and strongly prefers "not Option#1" Francois: strongly prefers Option 3 Janet: was good with option 3 Francois said - there needs to be an RSPEC per TSPEC for Guaranteed Service * Non-Renegable Selective Acknowledgements (NR-SACKs) for SCTP draft-natarajan-tsvwg-sctp-nrsack 1400-1410 (10 min) 5 Ertugrul Yilmaz: presents slides. Gorry: do you think an handheld device will generate this rate of traffic (1.2 Mbps) Lars: this may not apply, they have few flows Randall: adding an overlooked point multipath (CMT) has been around for a while disparate paths (1mb, 100mb) send buffer blocking impacts; with NR-SACKs, problem goes away Lars: you've presented this multiple times, and hitting same issues, e.g., from IETF 71; same people queuing up; not whole lot of changes to the draft need to take the comments seriously, not show us same slides every time Ertugrul: shows implementation matches simulation Lars: previous questions about buggy scoreboard, issues raised previously, the need to show the impact of the benefits for standardization - question is whether it's worth it, and that's the question you need to answer. sounding critical due to lack of coffee ;-) sounds like interesting research, but not progressing as a standard Ertugrul: wanted to discuss it on the mailing list, but not reply Lars: these guys need a kick sometimes what do others think Gorry: very pretty. liked it. liked presentation. seems important when you have a small send buffer, which is intuitive. But if you have a big buffer, do you care? when loss rate increases, what's the impact? is the 8K buffer a realistic scenario? Ertugrul: shows results for various buffers Gorry: if 32K case is OK, then not an issue if servers can handle 32K buffers look at whether small buffer case is important and how much you really save Prethi ?: benefits for SCTP is with saving memory not throughput improvement vs. CMP, load balancing, different path chars can cause impacts Gorry: but if 2% is a reasonable case, then it's 10% loss, 10% loss is quite high Ertugrul: with CMT, see very high impact on throughput Matt: was involved in TCP SACK that sets precedent wish SACK was never in SCTP - quite different this should go through, if nothing else, as a correction the reason isn't memory issues - it's buggy implementations force senders to test renig'ing code to find bugs scoreboard problems aren't as much an issue here Lars: are you volunteering to shepherd this? research meets standards disconnect Matt: yes. don't know SCTP as much, but can help other thing this solves from TCP is at the end of recovery to free retransmit queue when already busy and CPU hit is hard; that goes away if you free resources along the way Ertugrul: doesn't happen in SCTP Randall: it does happen Matt: just traversing the list causes a hit (jabber)?: what is situation with ordered messages, which is most of SCTP messages? Prethi: even with ordered messages, out of order data is non- renigable anyway Michael: seems like you're saving memory it's not about 8k, 32k it's about limiting throughput on parallel path with different BW need to free data that you know you don't need anymore Lars: look at minutes from this time, and previous two meetings send email to list with answer to questions and here's why the WG should take this on Prethi: question to group haven't presented CMT results here would the WG like to see those results? Lars: it would be additional data, which is always good for the IETF, it's a nonstandardized extensions that isn't specified anywhere (mostly research papers) while I beleive you, standardizing them in the wrong order. standardize CMT first, then add this if that's the primary benefit if there are benefits for general SCTP, then we can do this (jabber): long note from the jabber room - see jabber notes for details * Bob's - Layered Encapsulation of Congestion Notification 1410-1420 (10 min) 4 draft-ietf-tsvwg-ecn-tunnel - missed the deadline, this is an announcement of the changes to the draft, which were large. - ingress and egress Fred - there's an RFC that talks about tunnels (inner part and outer part), is this covering the same thing? Bob - no, this is addressing what RFC4301 left out (on purpose?) Gorry - some changes he likes - some about ECT1 vs. ECT0 he's not so sure about - there's a list of folks that have volunteered to review - no backwards compatibility issues Bob: have people on the hook to review will take to IPsec next meeting no backward compatibility issues.