Transport Area Open Meeting Agenda -- Meeting Notes IETF 70 - Vancouver Tuesday, December 4, 2007 1300-1500 Afternoon Session I Salon A/B Note takers: Steven Blake Tom Phelan Chairs: Magnus Westerlund Lars Eggert Transport Area had a single area open meeting. The Ads Magnus Westerlund and Lars Eggert started the meeting by discussing the status of the area and some other transport related announcements. Then Michelle Cotton from IANA talked about the proposal to revise the transport protocol registration rules that are under development. This was followed by a presentation and discussion on Structured Streams by Bryan Ford. The area meeting ended with presentation and discussion by Bob Briscoe concerning the possibility to create a framework for fairness accountability. - Mentioned that IESG wants additional scribes for telechats and f2f mtgs. If interested please send email to iesg@ietf.org - Congestion control help for "SIP Overload: Design Team - have presentation of output of design team showing that still all proposed solutions shows how utility drops as offered load increases. - need help from TSV area; talk to ADs if interested; also Jonathan Rosenberg Status of the Area ------------------ - See slides - 11 docs approved by IESG, 20 published as RFCs - Lars' queue is empty - ITU-T SG13 flow state-aware forwarding: proposed liaison response posted to list; consensus call ongoing; please comment - IPS and RDDP WGs have concluded - Thinking about starting a storage maintenance WG - WGs nearing completion: IPPM, MIDCOM, RSERPOOL, ROHC - Leaves BEHAVE, DCCP, FECFRAME, NFSv4, NSIS, PCN, RMT, TCPM, and TSVWG Stuff on the Horizon -------------------- AD thoughts on what potentially the area could work with. Being mentioned is no automatic acceptance: - NAT Firewall Traversal & Control - Incentive problems for deploying new stuff - IPv6 deployment; IPv6 stacks is still malleable Magnus Westerlund: firewall control problems exist in IPv6 even without NATS Marcus Isomaki: IETF have worked on many of these issues in the past. It is not clear where the problem is. Lars Eggert: Anyone in this room can design a NAT and FW control protocol here that will work; nobody has designed one that anyone really wants to deploy. Will ?: Host using multiple networks, IPv6 with p2p IPsec, corporate firewalls, will create an incentive. The pain isn't high enough yet. Lars: So the pain isn't large enough yet? Will ?: Not yet, but will be. Bryan Ford: App space - apps behind good NATs can behave as first-class citizens in the net (e.g., supernode). Some users don't want to be a supernode, thus benefit from having a badly behaving NAT. Could we reverse this incentive? Joe Touch: NAT designers want to be transparent; don't want to be talked to. Fundamental flaw is that ISPs are incented to deploy NATs to correspond with their charging model; don't see a good solution because it's a commercial problem. Hannes Tschofenig: Protocols that provide rendevous services have the problem. UDP keepalive problem. Mobile IP: no TCP, imagine how bad this is going to work, v4-v6 transition will make it even worse. Lars Eggert: It is obvious we don’t have the ideal solution Magnus: An additional issue is that we are not sure how to divide up the problem. Magnus Westerlund presented the Multi-level NAT Implications slide: - what happens with overlapping address spaces - failure to connect - NAT traversal solutions make traffic go where it isn't intended - Some NATs can switch to bridge mode if they are given a private external address Bryan Ford: Does this suggests an incentive for NAT control, if this does become more common? Translation for IPv6-to-IPv4 compatibility - renewed interest to support v6 hosts working with v4 Internet - standardization may happen in TSV with strong INT participation Internet Heterogeneity - getting both faster and slower (multi-Gbps links; low-power networks) - how do we design transport protocols to effectively and efficiently operate in such a network? - connectivity characteristics in Internet are different from they were in the past; creative L2 schemes Marcus Isomaki: How far are you willing to go away from TCP's end2end model? Lars Eggert: as much as needed; need a wide range of research. We are probably looking at SHIM layers on short term and more efficient solution in the longer run. Marcus Isomaki: May need some work in IRTF. Are they taking these on? Lars: Are some developments in ICCRG (high-speed links), TMMRG and IRTF external research. Not a lot of push on standardizing anything yet Sally Floyd: There needs to be evaluation of pro and cons of cross- layer communication. IRTF may be the place to do this. Aaron Falk: add characteristics to this that apply to shim6 Lars: Shim6 has some text about diddle with TCP variables; shim6 people have identified the need to do something at layer 4. Aaron Falk: they were told that TSV area would come in and help them Sally: TMRG is working on best-current practice docs (e.g., CC on wireless links) There are more topics, but we didn’t want to discuss a shopping list. If you have ideas, please talk to the Ads. Michelle Cotton, IANA, on revised port number procedures -------------------------------------------------------- The current procedures are defined in RFC 2780, but not clear. IANA currently have a paid expert to review port requests. Port applications also can have non-disclosure agreement. Both these things are the only registry to have them. It does create costs and issues for IANA. Another issue is that historically, you get both TCP and UDP ports when requesting either. SCTP and DCCP are different and have detailed guidelines. The goal is to get the same for TCP and UDP. The new proposed guidelines are: - Official expert designated by IESG - No NDA’s - Only assign what requestor is asking for (tcp or udp only) - 15-20 ports assigned per month The remaining issues are: - How port assignment interacts with service names - Requests for service names without port number - Renaming/reusing existing ports - Well known vs. registered -- still need for distinction - XML'izing the port registry This presentation is seeking comments on the proposed guidelines and feedback on the remaining issues. Joe Touch: one issue has been whether you are required to have a RFC to request a port. Michelle: system port requires RFC. If we eliminate the difference between well-known and user, then the procedure might change. Joe Touch: I believe that publicly published port allocation needs a public description of the protocol. Lars: Are you saying that we need a private range? Iljitsch van Benijum: Because of NATs, if you want multiple services on the same NATed IP address, then the fixed port numbers are an issue. We should move away from this and use SRV records instead. Lars: This is a near-term effort to resolve the issues we do have. Iljitsch: We should recommend applications from not using registered port numbers. Magnus: IESG/IANA does raise the question if well-known or registered port is the right solution in different protocols. Mark Finn(?): I am the by IANA paid expert. We get a NDA about once a month. If we don't find a solution to NDA, then folks will quit coming to IANA and just stomp on a free port. Lot's of applicants that aren't willing to share info on their protocol. And we do get to see the protocol. Lars: Port numbers is the only registry that allows NDAs. Are port number requestors different? Mark: yes, most are application writers. Application writers working from cookbook from the 1980's. Difference between well-known and registered needs to go away. Currently have a different process for allocating these. Joe Touch: I wrote a port names document, which explains why we don't always want to use SRV records (involves third party). Encourage IANA to act as an authority; Encourage iana to expand last letter of acronym. IANA have the list of ports, you also have list of who's using them, you need to also list ports being "usurped", "stolen", etc. Bill Fenner: For SRV, you currently needs to get a port anyway, need to fix this. What if you sign an NDA but don't allocate the port; aren't they going to camp on it anyway? Is FCFS an acceptable allocation policy? Michele: we don't turn too may requests away. NDA available on IANA website, some companies may sign it automatically. Bill Fenner: allocations for experimental protocols; do you ever point people at that? Lars: The document for the updated rules will point this out. Bill Fenner: if we make any change, then we should just stop well-known allocations, just say that registered are available. Bryan Ford: can we make camping less harmful? Philip Matthews: Port names -- any recommendations about renaming ports? Michele: may go hand-in-hand with the idea of a service name registry. For individual cases IANA is relying on other people with expertise, however we think where it is needed that we can change the short names. 1345-1415 Structured Streams Bryan Ford Bryan Ford discussed some research he has done on what he calls structured streams. The issue is the current transport abstractions, i.e. neither UDP/DCCP datagrams or TCP byte streams matches what most of the application desires. Thus he looked into another type of abstraction which is structured streams. Please see slides or http://pdos.csail.mit.edu/uia/sst/ for more information. Jana Iyengar: like to see comparison with SCTP, lot of things are already there in RFC4960 Bryan: SCTP already has multiple streams. Differences, sctp, no dynamic stream creation/shutdown, no per-stream flow control, best-effort datagram size limited; Structured Streams have no multihoming (yet). Mark Handley: really like this idea. Wish you had come up with this 25 years ago. What role can we carve out for this. Would you like to deploy it. Bryan: that's why I put it into a library; don't have to ship it as part of the app, or put it in the kernel. Mark H: do you pay any penalties from running over UDP? Bryan: common problems with running in userspace. Randall Stewart: SCTP had (per-stream flow control?) historically, cost 12 bytes, at that time not considered worth it. Don't understand limit on datagram size. Bryan: Can have segments dropped. Randall: Yes, but with partial reliability on can set check points. Jana Iyengar: sst vs. sctp, first point legitimate, but if you have 64k streams it's more a question of mapping. Bryan: always a way to map, but question of complexity. Jennai: parallelism you are trying to create is available. Kevin Fall: have you considered alternative APIs Bryan: yes Michael Tuxen: no port numbers in header -- what do you do? Bryan: on-going issue, evolving to use standard port numbers for rendevous purposes Lars: Bryan is here thanks to ISOC student travel program 1415-1445 An Accountability Framework for Use of Congested Internet Resources Bob Briscoe - See slides - New title: "We don't have to decide fairness ourselves" IETF should concentrate on accountability; let users/apps/operators decide on fairness. BitTorrent opens ~100 flows. Ilijitsh: Clients don't always use all the sessions; ones they use may be fairly low BW. Can't just count the flows. Bob: showed example where they were all active Joost opens ~1500 UDP streams. It would be fairer if lighter users get more rate when they need it. Upgrading link by factor of 4 only increases per-flow rate by 30 kbps. Volume accounting not the answer either: doesn't account for whether the heavy user is inducing congestion. What should IETF do? - introduce congestion accountability framework - offer an evolvable alternative to DPI - coexist with null enforcement Trying to design protocols that start-up faster then TCP. Sally Floyd: how does a transport protocol know if fairness is being addressed on all the links and the path? Will you have a protocol for the link between my PC and my fileserver at work? Bob: These questions are about the solution, and valid. Proposed solution deals with the first but not the second. Bryan: Fairness operates at multiple levels. Bob: natural hierarchy, yes Andrew ?: all these schemes have been used by my ISP (New Zeeland), often at once. Lars to Bob: we need a more interactive discussion on fairness, not more presentations like this.