TSVAREA agenda IETF-71, Philadelphia, PA, USA Tuesday, 2008-3-11, 1740-1950 Chairs: Magnus Westerlund Lars Eggert Note takers: Martin Stiemerling Matt Zekauskas 1740-1810 Agenda Bashing (30 min) Note Well State of the Area Lars Eggert gave the update on the TSV area. The IESG is looking for scribes to get better load balancing. The area received two liaison statements from ITU-T SG 11, one related to PCN and one on Y.2121 aka Y.flowreq. The interest in PCN seems like business as usual, but the Y.2121 could potentially be problematic, due to the nature of that ITU-T recommendation. Dave Lauries (?), who is a rapporteur in SG 11, mentioned that folks in the ITU-T had tried to stop the Y.2121 work but hadn't been successful. He said it would be extremely useful to send a strongly worded liaison about this to SG 11. Lars continued that the ADs were going to meet with the IETF's ITU-T liaisons to discuss the two liaisons, and that as usual an ad-hoc team would compose a draft response, followed by a comment period and consensus call on the TSVAREA mailing list, as usual. Continuing with the state of the area, the ADs noted that not that many working groups remain (MIDCOM about to close, RSERPOOL/IPPM/ROHC and the end of their chartered work). The ADs encouraged folks to bring ideas for new work to the area, maybe in the form of BOF proposals. 1810-1840 Requirements for P2PSIP transport (30 min) draft-bryan-p2psip-reload-03 Cullen Jennings Cullen Jennings started out noting that this work is at a very early stage. P2PSIP is looking for some help from transport folks to figure this out. The goal is to standardize a Skype-like service, where most of peers are behind NATs and there is a requirement that a solution be deployable as an unprivileged application on most major operating systems. Michael Richardson (on the transport requirements slides): Are you trying this with TCP? Cullen Jennings: Have tried to do this with TCP and UDP, but not other protocols. TCP has simultaneous-open issues. Have tried experiments on 50 NATs I own, 25% work. No one else has reported numbers > 50%. With UDP I get 95% success. Tim Shepard: Have you tried Teredo? Cullen Jennings: Have not done experiments with Teredo, but has been thought about. The believe is that it'd be identical to UDP in terms of success rate. Architecturally, with IPv6 inside, it may be a little bit cleaner. Cullen continued with the "straw man" slide, saying P2PSIP wanted to think, start simple and pick something safe that allowed a migration path to provide better performance. They had two possible strawmen: (1) sending data with retransmissions + sequence numbers on top of UDP. Every packet is ACK'ed and a bitmask of the previous 32 transmissions allows loss detection. (2) TCP implemented in user space over UDP, because P2PSIP has a requirement to avoid kernel changes. Stuart Cheshire: Have you considered talking to the NAT via UPnP? Cullen Jennings: We looked at UPnP. But there are many installations with multi-layer NATs. For residential cases, what Microsoft requires to certify NATs helps, but the issue is with service provider NATs, which are common in Asia right now. You couldn't get the client to control a service provider NAT. Matt Mathis: Did you consider SCTP over UDP? Perhaps a better fit to the application. Cullen Jennings: Discussed it, not sure whether it's a better fit. A intense discussion followed that touched on very many points. One important question was that although P2PSIP is chartered to focus on a solution for P2P communication of SIP messages, a more generally useful P2P communication framework would be interesting to solve other problems. Several people argued that that a more general solution should be developed and that P2PSIP should be come one user of that solution. Others argued that a SIP-specific P2P communication method was what the IETF had the expertise for at this time. There discussion had no clear results. The P2PSIP work in ongoing, with a timeline of having serious proposals by the next IETF meeting and finalized protocols in a year. 1840-1910 SIP Overload Control (30 min) Volker Hilt Volker Hilt presented the current state of the work of the SIP Overload design team, to ask for feedback from the transport community on a SIP problem that is related to transport protocol mechanisms. The presentation included results from several simulators, however, none of them are currently publicly available, although there are plans to make some of them available. Aki Niemi asked whether the results, which are currently based on simulations where SIP runs on top of UDP, would look different if TCP was used. The resulting discussion didn't result in a conclusive statement, some participants argued that the results would remain fundamentally unchanged, others argued that for some of the communication pairings (server-server vs. server-client) or certain buffering schemes, the results would be different. Tom Phelan asked how to contribute to this design process, given that the design team operates in a closed fashion. Jonathan Rosenberg is the person to talk to. Lixia Zhang asked what communication delays the current simulations modeled and whether they considered any message loss. Volker responded that the current simulations did not model delay or loss. Several audience members commented that it is essential to evaluate the proposed load control schemes under various delays and loss distributions, because it is well known in the transport community that they have significant impact. Finally, Matt Mathis suggested that the design team review mechanisms designed to mitigate TCP SYN floods, due to potential similarities. 1910-1940 UDP and TCP as the New Waist of the Internet Hourglass (30 min) draft-rosenberg-internet-waist-hourglass-00 Jonathan Rosenberg Jonathan Rosenberg presented his draft, that argues that the 16-bit port number has in fact become part of the IP address space due to ubiquitous NAT'ing, and that the new "waist" of the IP protocol stack is hence UDP for peer-to-peer applications and TCP for client-server applications. The implications for applications and new transport protocols is hence that they need to encapsulate inside TCP or UDP. He pointed out that the only argument against this approach is operation in Intranets, i.e., networks where there is no NAT. Even then, he suggests that applications will sooner or later be run on the general (NAT'ed) Internet and will then need such encapsulation, so they might was well be designed from the get-go using a UDP encapsulation, because the overhead is negligible. Henning Schulzrinne: That works, but before you had two demultiplexing fields and now only one, unless you introduce another layer on top of UDP to designate the port for the transport protocol. What if we want several new transports protocols over UDP? Jonathan Rosenberg: Standard tricks apply, the full port range is still available with SIP. The port now indicates next protocol and the service port. Philip Matthews: The UDP header does not have next header field. Need a framing layer. Joe Touch: Ports perform two functions: demultiplexing and identifying the next protocol. Had draft two years back (draft-touch-tcp-portnames) that tried to decouple those roles. They are also somewhat decoupled in SCTP and DCCP. Tom Phelan: I wrote a DCCP over UDP draft (draft-phelan-dccp-natencap). With UDP encapsulation, the total header size is four bytes bigger than the standard DCCP. Stuart Cheshire: Next protocol field is helpful for debugging, but ports are not required for applications to connect. Jonathan continued his presentation with a slide on what happens with IPv6. Lixia Zhang and Joe Touch pointed out that with IPv6 NATs, the issue may be reduced or at least different than with IPv4. Jonathan disagreed. Dave Thaler: NATs are not the real problem, security is the problem - there are security devices out there! Stuart Cheshire: I agree with Jonathan, the situation is much worse than the commenters think, based on my experiences at Apple. Apple has the "back to my Mac" service that carries TCP over IPv6 encrypted with IPsec over port 4500 over IPv4. *Still* couldn't connect from somewhere in New Mexico - was at a location where the DSL modem blocks everything other than TCP port 80. Iljitsch van Beijnum: Do you want to apply UDP encapsulation only to new transport protocols, or also to existing ones? (Jonathan nodding.) How do you propose to manage transition for existing protocol to run over UDP? This is all a waste of time - the time will come when we don't need such hacks anymore. Lars Eggert (from the floor): Tunneling is not really new, but typically IP-in-something. The new thing of this proposal is to get rid of IP in the middle and encapsulate for example TCP directly in UDP. Why is that a feature? You could just pull up an IP-in-UDP tunnel before communicating, like Teredo does. (The raw minutes didn't record a clear answer here, and the audio archive was offline when this was written.) Tim Shepard: Got into the queue to point out that it even worse than Stuart Cheshire described. But there are two ways out: port 80 and 22. You can use this to tunnel. But I don't think running everything over UDP is the answer, but it is *one* answer - but no one answer will work anywhere. You need an interface to bag of tricks, that includes stuff like what Skype does Jonathan pointed Tim to the ICE spec as the IETF's bag-of-tricks. Philip Matthews: What is the intention of this draft? Jonathan Rosenberg: Getting feedback, see what I get, think about (IP?) encapsulation vs. running in side UDP and maybe ask about publication as BCP. The discussion concluded with Tom Phelan pointing out that the ADs had expressed an opinion about per-protocol encapsulation proposals, and asking where a more general encapsulation proposal should go to. The ADs responded that there is clearly energy and interest in this space, and suggested that this energy organize itself into maybe a BOF proposal.