TSV Area meeting in Dublin IETF 72 minutes Scribes Randall Stewart Michael Tuxen Meeting Chairs: Lars Eggert Magnus Westerlund Status of the Transport Area ============================ Lars and Magnus started the meeting by presenting the status of the Transport Area. Please see slides for status information. Their where no questions on the status of the Area. Flow-State-Aware Forwarding and Standards Development ===================================================== draft-adams-tsvwg-flow-signalling-codepoint Presenter: John Adams Lars Eggert summarized the history so far: ITU-T has been working on requirements for flow state aware signalling. They have published a requirements doc, and now beginning an effort to do the standards developments. The Transport Area have pointed out that many of there changes are under control of the IETF, and liaisoned that to them. One of the purpose is to understand flow state aware signalling to a sufficient level to understand the impact on our specifications. We need to work towards to keep the conflicts at a minimum. John Adams presented an overview of what Flow-State Aware signalling is about. People interested in the presentation should listen into the audio feed. Fred Baker asked 2 questions: 1) Is the possibility of routing in sense that telephone system routes the calls, does not want to talk about that. 2) is the allocation of b/w in this environment is the same as the voice admit codepoint currently under discussion. It might be worthwhile to have them use the same codepoint. John answered that the limited scope does not apply to routing. Not trying to route. What we are saying is its a complex migration. It may be a disruptive technology. So that is quite complex story on multiple commercial fronts. How existing tech can see a path forward etc. And what's there today in the network and which bits can be swapped out. Dave McDysan stated that IETF has some flow-state aware signaling, aka RSVP, can you contrast that to your approach. What improvements or benefits you can provide. John answered that RSVP differs in respect to a flow. Not aware of RSVP offering an available rate service. Maximum rate service is not in RSVP. (they evaluate every 100 or so packets). You append an initial packet (first flow state aware preference) and specify how the flow goes, but you don't wait for a response. Admittance control becomes a swap between two states instead of a go/nogo decision. This leads to new notions of service. Lars commented that there are existing protocols for example parallezing this with other protocols with existing protocols and switch the state. ICMP in parallel can give you roughly the same thing. Bruce Davie stated that there are points of difference but none are architectural. RSVP does not define services, all min/max etc RSVP allows an arbitrary number. Many of the goals you are trying to achieve fits with RSVP. Could be done with new service definitions in RSVP. John was not opposed to doing it that way. Bob Briscoe asked about Cases where content and endpoint are NOT flow state aware but network is. If network decides to block a flow, how would the app know. John answered that Packet discard state is changed moment to moment, so app would see some lost packets. In the extreme the app would see no packets. But there are all spectrums in between. Lars wrapped the session as we had run out of allotted time. There good feedback and John was recommend to also solicit feedback from the routing area. BitTorrent Transport: Mechanisms and Impact =========================================== Presenter: Stanislav Shalunov Bob Briscoe asked what was meant that other applications don't experience congestion? Stanislav explained that few applications are experiencing a state where the is persistent congestion over most of the session unless there is a p2p file download in progress at the same time. Web surfing sees at most one or a few losses per action. Fred Baker commented that it would be interesting to see a statistical study that supports this statement. Tim Shepherd commented that people may be interpreting to much into this statement. Tim's personal experience is that while p2p file sharing is going on the websurfing experience is lousy. And when not it mostly works quickly. Stanislaw confirmed that this what he meant. Fred Baker commented that this is not limited to yourself, there are reports on that when you are using file sharing your next door neighbour is affected. The bottleneck is in the DSLAM or somewhere else in the access network. Looking at core statistics doesn't help you. Some discussion about difference experience including that of the hotel's room network during the meeting. Shared resources are the key reason people experience these problems, like in cable networks. Joel Jaeggli commented that there are also other applications that cause this type of problems. Chris Liljenstolpe commented that he had done work on DSL and Dslams. There is potential contention with bit torrants. In case where lots of small bursts. No problems but there are several 100 folks being drained by a small link from the dslam. So when a large torrant goes on, it effects the rest. Bob Briscoe commented about the usage of multiple connections. Want to to make it clear that apps not necesarrily evil from doing this. Some apps can benefit and we should allow protocols to do this. The case he wants to check, if you have large number pairs that have finished, anyone trying to get that pair can download. Stanislav responded that if you have a lot of seeds you are limited by the number of peers you connect to. So you might download with 1/2 of your open connections. Normally the opposite problem is in place, person exits after he downloads. So you never get your download capacity saturated. If you manage to get a rate higher than you upload capacity you are doing well. If you have symmetric capacity then it works better. Remi Denis-Courmont commented that multiple connections are as a likely problem for NAT and Firewalls that overload. Ilitsch Van Belnium, commented that in the work for IPv4 and IPv6 co-existence there are likely to be issues with a limitation of the number of bindings that can be provided per customer on the public IPv4 side. It would also be good if ICE like traversal NAT traversal could be supported as that would likely work better over translation gateways. Stanislav answered that if there will be a change in what is predominant, it is very likely that support will be provided. Multipath TCP and the Resource Pooling Principle ================================================ Presenter: Mark Handley Lixia Zhang commented, I see the word pooling but its spread over all bullets. I question this word with multi-homing. Its more after redundancy not a pool. Mark answered that you pool the reliability of the links. Word semantic discussion. Randy Stewart commented doing multipath at the transport layer is more efficient than at application layer. Randy also asked about shared bottle necks. Concurrent Multipath Transport for SCTP exist but needs to know if there are any shared bottlenecks. Mark responded that you don't need that if you share the right state between the different transports. Scott Brim, what about existing security solutions like deep packet inspection? Depends on how one sees at this, if it is a privacy intrusion or a feature. Scott also asked what about multicast. To which Mark don't know. asked what would be the gain today of doing this to the whole system? Mark responded that its work in progress. What fraction of the benefit do you get from end host vs doing work in the network. This is all research to be done.