Transport Area IETF-75, Stockholm, Sweden 1520-1720 Monday 27 July 2009 Chairs: Magnus Westerlund Lars Eggert Minute taker: Stuart Cheshire 1520 State of the Area 1525 Pasi Sarolahti, Quo Vadis, DCCP? Mark Handley: We need more than just better APIs to communicate congestion/rate information. Problem is that both DCCP and codec want to be in control of the rate. Janardhan Iyengar: How many applications are using DCCP? Pasi Sarolahti: Not many. Colin Perkins: DCCP is basically done and stable. Time to deploy it and get operational experience. No need for a highly-active working group any more. Mark Handley: Maybe we should take the opportunity to examine what lessons we learned from DCCP. It's not exactly been a resounding success. Bryan Ford: DCCP needs something to do. Aaron Falk: Should not close WG. Keep it open but inactive for now. 1540 Colin Perkins, Explicit Congestion Notification (ECN) for RTP over UDP with Magnus Westerlund Background reading: draft-westerlund-avt-ecn-for-rtp Problem today is there's no portable standard API to get access (read on reception, set on transmission) to the ECN bits of UDP packets. David Black: There's no way to tell if all the routers on the path understand the ECN bits. Bob Briscoe: Just because router forwards packets with ECN bits, doesn't mean it understands them and does anything useful with them. Colin Perkins: Point is not to determine whether all the routers on the path understand the ECN bits, but whether all the routers on the path will at least forward packets with ECN bits set, otherwise ECN bits can't be used on that path. Lars Eggert: Slow response to ECN may result in flow being less network-friendly than TCP. Bob Briscoe: Yes, but flow is still at least as network-friendly than RTP flow without ECN. Lars Eggert: Point is that if flow does not react to ECN fast enough to prevent it from experiencing loss, what's the point of using ECN? Christian Vogt: Fast response to avoid loss is important. With TCP, a loss just causes slowness. With RTP, a loss may cause audio dropout. Colin Perkins: Discussion of multicast Bob Briscoe: Nature of multicast is that sender doesn't know all the receivers. David Black: Can modern codecs adapt their rates over a wide enough range? Colin Perkins: Yes Gorry Fairhurst: [?] James Polk: We should do this work in this area, in conjunction with AVT. The necessary expertise is in TSV as well as in AVT. 1610 Bryan Ford, Rethinking Transport Services with Janardhan Iyengar Background reading: draft-iyengar-ford-tng The transport layer is no longer end-to-end Iljitsch van Beijnum: Why is DCCP below DTLS instead of above? Bryan Ford: Because it's more common for the security layer to have to be somewhat specialized to meet the security needs of the application. Miika Komu: How does this compare to HIP? Bryan Ford: HIP is one of the things that could be used to do some of this. Miika Komu: You should read NAT Traversal draft draft-ietf-hip-nat-traversal Christian Vogt: How do you deploy this incrementally? Bryan Ford: Can use UDP as endpoint layer; can use TCP as legacy flow layer. Christian Vogt: Hiding this in the OS instead of making it visible to the application risks causing failures, which results in unhappy users, which results in unhappy OS vendors. 1640 Mark Handley, HTTP Extensions for Simultaneous Download from Multiple Mirrors with Alan Ford Background reading: draft-ford-http-multi-server For large downloads, fetch different parts from different mirrors which hold the same data. A bit like the way Bittorrent downloads different blocks of a file from different sources. Server advertises list of mirrors in its response, and client can chose to make use of that information. Tim Shepard: A single checksum for very large files is insufficient. Mark Handley: Goal is different. Goal is not to compensate for TCP's weak checksum for very large files. Goal is to verify we're getting chunks of the right file. Lloyd Wood: Why not use date instead of checksum? Mark Handley: Don't trust server clocks (or file mod dates) to be reliable. Henrik Nordstrom: Why not use HTTP etag? Mark Handley: Okay, we should use that instead of defining a new checksum. Bryan Ford: Why not generalize which tags can be used, and allow server to offer one or more suitable tags, and client to pick the one it wants. Mark Handley: A checksum has the benefit that it allows client to validate the data at the end. Tim Shepard: What's the point? What the client supposed to do if at the end the checksum doesn't match? Leslie Daigle: Why was this not presented in Applications Area meeting? Mark Handley: Not prepared in time. 1655 Andrew Yourtchenko, Happy Eyeballs: Successful Introduction of New Technology to HTTP with Dan Wing Background reading: draft-wing-http-new-tech Algorithm for doing parallel overlapping connections, with intelligently staggered start times. Bryan Ford: Agree there's a problem, but how does this scale when there's six or eight different ways to connect? Don't we need a way to negotiate the right way to connect up-front? Dan Wing: There is no reliably way to know which method will succeed, so we need something like this that tries multiple method concurrently. Simon Perreault: This is client-side only, so why does it need to be a standard? Just implement it and ship it. There's benefit in standardizing this so that all clients do it the same way. Lars Eggert: Which area does this work? Dan Wing: Transport area, plus Apps area. Bryan Ford: Apps area tense do do per-app solutions. We want a single solution that's shared by all apps. Colin Perkins: Things like SRV records don't solve the problem. Just because the server advertises that it supports SCTP, or IPv6, doesn't tell you whether the intervening path supports SCTP, or IPv6. Bryan Ford: Also, current SRV records have the problem that you have to do multiple DNS queries (presumably in parallel too). We really want a way to do a single DNS query and get back all the data the clients needs to make an intelligent choice. Leslie Daigle: This is broad question. Application software needs guidance about how best to interface with the network. 1710 Lloyd Wood, Turning HTTP into a standalone layer in the network stack Joe Touch: This has similarities to BEEP.