TSVWG meeting / Monday Mar 10th 2008, 1300 - 1500 ============================================ Chairs: James Polk Lars Eggert Magnus Westerlund Note takers: Pasi Sarolahti & Simon Schuetz TSVWG status The WG has since last meeting had 3 RFCs published. Currently there are no drafts in the RFC-editor's queue, 3 I-Ds in WGLC. The RSVP extensions for emergency services (draft-ietf-tsvwg-rsvp- emergency) may be affected by discussion in NSIS WG on the Qspec. So far there has been no comments on the drafts in WGLC. We need to have comments on these drafts. That include an indication that at least someone has at least read it, even if everything looks fine. Drafts are on hold until someone indicates having read them. 4 drafts appear to be done, close to WGLC * UDP guidelines * SCTP sockets * RSVP Proxy Approaches * RSVP Extensions for path-triggered RSVP Receiver Proxy Milestones review * WG is late on user-defined errors for RSVP * 3 milestones completing ahead of time There where no open issues in TSVWG that aren't covered by todays agenda items. Lars Eggert - UDP Guidelines (10 min) ====================== draft-ietf-tsvwg-udp-guidelines-05.txt Lars talked about the current status which is basically done. The only open issue is if the security consideration section should discuss SRTP in context as an RTP security mechanism. The other review comments (see slides) has been addressed. Philip Matthews asked if his question at IETF 70 regarding fragmentation and how applications handle this have been resolved? Lars answered that no text changes has been done. An UDP using application/protocol either has to do path MTU discovery or keep to the minimum MTU. Philip Matthews asked if we should define a generic fragmentation method rather than doing it differently in each protocol/app? Lars answered that we don't need to say anything special, similar to any other tunneling mechanisms. Tunneling methods should provide the fragmentation inside tunnel, thus acts similar to a router. There is nothing UDP specific. If application sends larger than MTU, then application needs to handle the consequence. Every application will need to deal with this individual as they best know how to fragment. Philip wondered if the draft couldn't say that applications can rely on IP frag. But that would be against a SHOULD that exist already in the draft. Matt Mathis commented that the application needs to handle the fragmentation to result in robust results. Lars also reminded about that this is intended for BCP not inventing something new. The poll amongst the present indicated that 10-15 had read this document. As soon as the next revision is made available a WG last call will be started. WGLC will be a cross area one. Michael - Applicability of Keying Methods for RSVP Security =========================================================== draft-ietf-tsvwg-rsvp-security-groupkeying-00.txt (15 min) Francois Le Faucheur presenting This draft is now a WG item, after the discussion on the mailing list. The intended status is a informational RFC and it has a proposed milestone of Dec 2008. The document changes since last version are: * issued as WG item * mainly editorial changes The next steps are: * Waiting Hannes' review comments * Still need to add discussion on couple of points shown on slides * Has been pointed out this document has some applicability on RSVP- TE/GMPLS. Need to work on the draft first before circulating in these communities. There where no comments or questions from the room. Lars asked: Who has read this? one Bruce - RSVP-over-L3VPNs (15 min) ======================== draft-davie-tsvwg-rsvp-l3vpn-01.txt Third time presenting in this WG Bruce quickly gave an overview of the problem and model of operation. The focus is on admission control, any TE will be done in a separate document. The changes from -01 to -02 are: * main change: introduce VPN-IPv4 & VPN-IPv6 as proper RSVP address families, natural extension to RSVP, in response to feedback * simplified operation in multiprovider case * can support Option B without CAC on ASBRs * Aggregate RSVP (RFC3175) sessions across MPLF VPNS added * explicit support for IPv6 VPNs added Overview of proposed solution * use VPN addresses in RSVP objects * Solution to get around using router alert Why VPN-IPv4 & VPN-IPv6 in RSVP session * Responding to feedback in WG * Can uniquely identify session anywhere, property that wasn't there in earlier version Summary: * seeing number of environments where this could be useful * no changes to MPLS/BGP VPN protocols or operations * solution close to complete, where to go next? Consensus in the last IETF was that draft needs to deal with the changes. This has now been done, author thinks draft is close to complete. * Question: Should this be done here or in L3VPN group? Lars answered that if this is done, it should be done in TSVWG, even though application is probably in L3VPN. Only a few in the room had read the document. Need to have a review round in TSVWG on RSVP related issues. Then have L3VPN WG to review the VPN aspects. Then go forward. Bruce will anyway also do a presentation to L3VPN. Lars we need to check what l3vpn group thinks of where to work on this. But lets do a hum for conditionally adopting this document, if ok with l3vpn group. The result of the hum was; some hums for adopting, no one against. Michelle - IANA Allocation Guidelines for TCP and UDP Port Numbers ================================================================== draft-cotton-tsvwg-iana-ports-00 (15 min) James Polk is acting chair because Lars and Magnus are coauthors. Background: in Vancouver IETF it was discussed that port number procedures are not clear. Action item was to put together a document to clarify the procedures. Michelle presented the current status which is that the initial 00 draft version exists. IANA has also asked IESG to designate an expert pool to review port requests. Important sections * now one gets both TCP and UDP ports per request, in future only for those protocols requested * requesting IESG review for well-known ports * not going to allow non-disclosure forms * document procedure for deregistering, revoking, re-using ports Reviewing version-00 * are proposed procedures satisfactory? * plan is to have TSVWG to take over this document. Want people to take look and give feedback * There will probably be separate document for service name registry * How many people have read? some Marshall Eubanks asked if there a danger of exhausting well-known ports? Michelle answered that there is only about 100-150 left. There are a couple new requests a year. So maybe 20 years to go. Marshall also wondered if one can get a block of ports. Which one can but that requires good justification and the approval by the expert. We do hope that people ask only for one. Lars commented that people often ask for more than they need as they should be using payload demultiplexing mechanism within a particular application/protocol. There was a hum if this should become a TSVWG WG item. The result was some hums for, no one against. Clear consensus for taking this as a TSVWG document. To be verified on the mailing list. Preethi - Non-Renegable Sacks for SCTP (10 min) ====================================== draft-natarajan-tsvwg-sctp-nrsack-00.txt First presented in Vancouver. Preethi presented the problem and motivation for adding NR-SACKs to SCTP. See the slides and the audio recording for this. Preethi asked what should now happen with this draft? Lars asked the room who has read it, the result was that no-one that wasn't a co-author have read it. Lars explained that TSVWG has the task to do minor additions/maintenance to SCTP. But the question is if this is an important maintenance item for the SCTP protocol? We would want to send a message that SCTP is stable, this kind of extensions might demonstrate that it is not. We Need to have people read this so we can discuss if it is motivated or not. Gorry Fairhurst commented that it seems painless to implement, but the benefit does not seem very big. Preethi responded that the benefits are cumulating when there are more connections. Fred Baker commented that there is a fundamental benefit in that Sacks can be renewed. That's different to TCP and SCTP wouldn't need to retransmit data unnecessary. Matt Mathis, it is a fundamental change to TCP design. TCP implementations gets this wrong, several examples of it, speaking as an author of SACK. Author underestimates the benefit. This is yet another case where SCTP can do it better than TCP. Jana Iyengar said that it would be easy to extend this mechanism for receiver reneging. Lars Eggert stated that he couldn't get a good feeling for the benefit with the provided information. Thus it is hard to make a decision if this should be adopted or not. Matt Mathis commented that not being able to deal with sack reneging in TCP forces one to use double the buffer space. If it saves you half of the announced window, then it's worth the effort. Gorry Fairhurst stated that he believed Matt, but the presentation is not providing that information. Instead the benefit doesn't seem particular large. Jana responded that she will talk to the ones that commented to figure out what to investigate further to clarify the benefits. Lars Eggert proposed that the discussion continues on the email list. Murari Sridharan asked if there was a reason for the small receive windows as large would better show the benefit. Matt Mathis stated that TCP does not have this, because it may make TCP more fragile against bugs in scoreboard maintenance. Has it been studied if SCTP have these buggy implementations, such as TCP has? Jana was not aware any buggy SCTP SACK implementations Lars asked if this would be an update to RFC 4960, an experimental extension, or a proposed standard extension? Matt thought it should be a experimental extension until further experience has been gathered. Jana, likes to see this as a WG item. Lars further inquired if there are running code for this. The answer was not yet, but it is planned. Lars would be more supportive if this was going experimental. People need to read the document and discuss the technical details on the mailing list. Hopefully we have made some decision on the list by the next meeting. Michio Honda - SCTP Readdressing Retransmission Trigger (10 min) ======================================================= draft-micchie-tsvwg-fastmsctp-01.txt Michio presented how SCTP could be used for migration between different access networks and how to handle connectivity disruptions during that migration. One major problem is the transmission delay caused by retransmission timeouts. Packet loss in the connection causes disruption, as it takes one RTO before they can be retransmitted. This work proposes a new retransmission trigger based on readdressing events. Experimental results was presented. Lars Eggert commented that it is similar to mechanism we have proposed for TCP (draft-schuetz-tcpm-tcp-rlci). It works fine unless there are many parallel connections, and the trigger causes synchronized slow start that overshoots with large number of connections. Assume that SCTP has the same issue. Therefore need more data to prove worthiness. This problem should be investigated for SCTP as well. Fred Baker agreed that more experience with the proposal is needed. Lets continue discuss this on the mailing list and consider if work on multiple protocols needs to be aligned. Bob's - Byte and Packet Congestion Notification (10 min) =============================================== draft-briscoe-tsvwg-byte-pkt-mark-02.txt Bob Briscoe presented this individual draft that has been updated since previous discussion. The intended status is Informational. When using active queue management should we allow for the packet-size when network writes or transport reads a loss or mark. The proposal is that AQM SHOULD NOT give smaller packets preference. Instead adjust for byte-size when transport reads NOT when network writes. The reasons to decide now is that there is the DCCP CCID (small packet variant), PCN, and the ICCRG question on router requirements. The draft have had widespread updates and restructuring as result of long discussions with Sally Floyd at the last IETF meeting. The details are summarized in the draft. Lars Eggert asked how many has read this? A couple indicated that they have read it. Lars Eggert encouraged Bob to restructure his presentation a bit to first of all discuss why one of the RED modes are a bad idea. Bob did this. If packets is much smaller than MTU, large packets are dropped at much higher probability. Creates incentive to send small packets instead of large. Lars asked if the WG believe this problem is real? Matt Mathis commented that we should ask two questions: 1) whether people agree with conclusions 2) whether people this is a important problem? Fred Baker responded that the reason for byte mode is because it is easy. Byte mode is better, my humble opinion. Stuart Cheshire commented that we need to weigh cost of forwarding packets vs. bandwidth fairness. Don't think byte mode is a good idea. Bob asked do you want to get consensus before becoming WG item or do you want to make it WG item to get to consensus? Lars responded that people need to read this, we need to have discussion on the mailing list. So Lars asked: "Who thinks the problem is valid?" Answer: "three". "Who disagrees?" answer "zero" Lars commented that the point that the draft makes did not come up in the presentation. Bob responded "let's make a deal -- if it is taken as WG item, we can make this much shorter". Aaron Falk commented to the chairs that they should ask Bob to find reviewers and write the review on the list. Magnus Westerlund declared that this should be discussed on the mailing list. Aaron commented that this should be brought up also in the ICCRG. Wes Eddy responded that they are going to talk about this in ICCRG. How much of this work is research that should be done in ICCRG, how much work that can be done here? Think this should be adopted by the TSVWG. Certainly going to work on it in ICCRG if not adopted by TSVWG. Lars responded that we should discuss this on the list and get more details. End of meeting.