Techniques for Advanced Networking Applications (TANA) BoF IETF-72, Dublin, Ireland WG Chairs: Stanislav Shalunov (Stas) Gorry Fairhurst Jabber: Marshall Eubanks Note-takers at IETF-72: Matt Zekauskas & Alissa Cooper 1. Agenda Bashing - Gorry Fairhurst Goals: 1 Examine design space 2 Identify options 3 Identify interested parties Non-goals: 1. Updating TCP, SCTP, DCCP (expected inputs to other WG, such as DCCP, TCPM) 2. Deployment of ECN (although may use this when available) 3. BoF will not specify a solution The goals are to examine the design space; identify options and volunteers and determine if the IETF is willing to proceed, and if so, prepare the way for a charter. 2. Short Presentations (80 minutes including questions) * TANA Problem Statement - Stanislav Shalunov http://www.ietf.org/internet-drafts/draft-shalunov-tana-problem-statement-00.txt Some of the slides were adapted from a previous P2P workshop sponsored by the IETF RAI area in Boston in May at MIT. Proposed work items: 1 Congestion control algorithm for Scavenger Service 2 UDP framing for byte stream transport to use the new mechanism. 3 Implications of multiple transport connections (Informational). Bob Briscoe: I submitted a draft to TSV WG describing apps that benefited from opening multiple connections. We need to give operators and users some way to know what is good and bad at run time. It is contextual. Stas: We do not need to say much about what is good and bad. We could mention that it is probably counterproductive to open multiple connections to one destination. This does not have a transport solution. Stas: The aim is to confirm what is actually done (e.g. Bittorrent opens many connections although the number looks scary, it does not really use them for data transfers (choosing just 5). This sort of info may be useful to people that are concerned, including saying whether this is good or bad. Spencer Dawkins: I have been out of TSV for a while, but 6-7 yrs ago, there were some TCP implementations that did not implement RFC 2581 cwnd decay, this may need consideration. Stas: Not decaying the cwnd when not sending, is clearly a problem. Cullen: I think application developers have a hard time to identify what best to do with multiple connections, the IETF is qualified to provide this info to applications developers. Other: There are useful things we can do in the multiple connections bucket. Stas: All comments seem to be about multiple connections... but other two proposed work items are more integral to solving the p2p problem. Aaron Falk: Is there an assumption here that congestion control will use a delay based model? I have concerns about that for small buffers. Stas: This is not in the description, but if your design goal is to make delay low, and your only input is delay, you have to be able to achieve your goal. The Internet has a lot of network diversity of queues and applications. The ICC RG has expertise to look at new proposals. Aaron Falk: We need to discuss the effect of new transport protocols on existing traffic and need to understand the range of diversity in net. Gorry: The chairs talked to the ADs to think about the relationship between this and the IRTF CC RG. We are looking for new congestion control methods, looking for results from both experiments and review from researchers. Aaron Falk: i thin that feel pretty strongly that any new cong control proposals should be reviewed in ICC RG. There are experts there. Lars: I agree with you in general. Examples such as hstcp have reviewed in iccrg, but this is different. If this is designed to lose against Reno, we could be safe (get no throughput), or be only as aggressive as Reno. We need to look how best to proceed. Stas: I agree. If you want to yield to Reno, Reno will starve you out. It is a design characteristic. If at worst the new protocol behaves like Reno, that is not a big problem. Mark Handley: The choice of using this over UDP seems a compromise between doing what is quick and doing what is right. UDP is quick, but it is not the right long-term direction. This could cause UDP to become the new IP and we will end-up back where we were. Lars: On the question of short vs long term, we discussed a bit, and hope we can do both. The key outcome is the algorithm (rather like TFRC) that can the be used in a transport protocol. This could be a low-priority tcp flavor, a plug into tcp protocol. This design work needs to be done somewhere else (see BoF proposal). Stas: We could do other things like a CCID for DCCP in future... this is a suggested outcome. It is benefical to have something standard. Briscoe: There is a possible arms race between delay-based protocols. We also really want to recommend routers with small buffers. If congestion control becomes delay-based, it needs a reasonable-sized buffer to measure delay. So there is a tension between those two goals. Dave Oran: You should consult with AVT WG to discuss using RTP framing. Lars: We are talking about stream-oriented transport, not streaming - this is not for real-time. Lars: Structure #1 as an algorithm, not a protocol. Then decide how to use the algorithm in a transport protocol. Could, e.g., do a low-priority transport, but we are not getting specific. The chairs asked who had read BoF description: almost all The chairs asked who has read draft 30-ish * ISP Requirements for TANA - Richard Woundy, Jason Livingood Lars: Must a solution involve DiffServ? Or can it just approximate what DiffServ does? And is less-than-best-effort still useful if you are already using DiffServ? Jason: The mechanism does not matter, as long as it solves the issue. Other: These requirements are not being met by the BoF statement. Gorry: DS and ECN should be a part of an IETF solution in the transport space, even if these are not work items for TANA. - : If this is picked up by another WG, it would be good to know. Other: Does delay-based congestion control solve the problem for all users behind a CMTS? Henning: The concept of a user is not well-defined: are me and my son the same user? Steve: Deploying DSCPs across borders is not easy, we could not get agreement between North America and EU on DiffServ. The US had 7 levels and UK has 2. Briscoe: We would be happy to turn our p2pi contribution into an I-D where we compare transport against DS. Gorry: OK. In this BoF, we are to focus on solving this at the transport, rather than DiffServ. Henning: Is the problem lack of a fixed codepoint? No one uses the same classes? Rich: Yes. - : Can you say anything about 1st bullet - behind your own CPE, you can have own cong control, can you change what we do? Rich: Behind the CPE point, anything is possible depending on the user topology. The Comcast focus is from CM onward. There was a presentation at IETF 71, which concerned using vista, and experiences where home devices had crashed. So we must be careful in what we send. The ISP can not control devices in users homes, and can not upgrade firmware. There is a also a lack of inter-ISP diffserv support. if mark and give to other ISPs, they will just overwrite anyway. Stas: Delay is delay. It does not matter if only one experiences this, or this is shared along with others. Lars: DiffServ-based solutions are not in the BoF proposal. This is for scavenger-approximation or regular best efforts as options to application. There does not need to be agreement end-to-end like with DiffServ. * P2P Application Requirements for TANA - Laird Popkin Bruce Lowekamp: We need to focus discussions. Solving problems of bittorrent apps is useful, but does not solve the problem for all p2p apps. Some do not download multiple streams. We need to consider other problems too. Stas: This class comprises 85-90% of p2p traffic. Bruce: Right, but we should be precise. Dave Mcdyson: I have question on scope. The quota comment made me think this is between end systems. Would it be within scope if a service provider defined quota field to indicate some information? Gorry: This was not in the BoF scope, feel free to take that at end. - : Is source selection in scope? Gorry: This could be in Alto? * Uses of end-to-end Scavenger Service - Marshall Eubanks Oran: Is the expectation that various users of the scavenger class compete fairly with each other? Stas: So far that is a decision of the app, but yes. Oran: You might want to state that in the requirement. Marshall: If we are talking about gradations of service, I do not think this will work. Briscoe: The benefit of doing it at the ends is that you can have a spectrum. In the network you can only have 2 classes. 3. Discussion of Way Forward Gorry: We recently received one more presentation, about fairness among multiple flows, but the speaker is not here. I will send this out to list. Bob and Leslie: There are congestion situations that need to be addressed that are not addressed with this set of solutions (e.g. on core, backbone networks), iy would be good to get wider inputs. Marshall: There is a missing concern of security implications. Stas: The proposed way of doing scavenger service is without ISPs having to do anything at all. Security considerations are the same as for TCP. Francois: What is the incentive for providing a scavenger class? This came up several times. For an app to use it, it must have benefit. What is the incentive, or mechanism to give incentive in the charter? Gorry: If you use DS, it is easier to configure for less than effort service, than premium high priority service. Bob: Ot is "not that simple" - most of the time a user is not just competing with himself. Stas: I have heard you about congestion in the middle. Our data indicates otherwise, we do not see much congestion in the middle. Most of the time congestion in different streams correlates. Once we limit we did not see delays. There is a huge amount of pain in the last hop connection that needs to be solved, we can do it. Bob: There is not only one point where congestion can occur in the Internet. Stas: Yes. Congestion control needs to also work at points other than last mile. Magnus: I got the impression that this would be worse without a specification. Stas: I believe that concerns of arms races are overblown. Magnus: One more thing... if we go forward with work item one, the known set of tests should go against multiple scenarios. Stas: We could use the Internet as a testbed. -: That is what I was afraid of... Stas: In some ways, we already are. - : Are you expecting ISPs to config special class? Stas: This is not required. Colin Perkins: I can see a case for building a less than best effort congestion control algorithm. However, such an algorithm is only useful if there is a transport protocol. Is it the aim of the group to design a new transport protocol, or modify or what? Stas: Item 2 is UDP framing for stream transport. Colin: I would be a little bit concerned if we develop a UDP version of TCP in user space in this group. Stas: I would prefer not to do it. Stas: We need to be able to deploy whatever we create on the Internet. We have two choices for transport today. Lars: But we are not necessary limited by what we can do in user space. We could discuss implementing it as an option in TCP space is an open question. Stas: We need different people if we are going to do this in the kernel. Colin: We do lots of things in IETF that get deployed in the kernel. Stas: But Microsoft does not do these kinds of things today. Lars: This is a different timeframe. If we need to do this quickly we can start in user space. Aaron: The decision to put congestion control in the kernel was conscious Ð It is not conducive to the overall health of the net to make it too easy for peopoe to fuss with it. We need to think hard about how to balance expediency versus safety. Stas: Putting TCP in the kernel was based on performance. The movement today is in the opposite direction, modern TCP stacks allow you to choose which congestion control you like more. Aaron: When will your algorithms and measurements discussed at the p2p workshop be made available? Stas: They will be made available when working group goes forward, depends on AD decisions. Months. Jonathan Rosenberg: Incremental deployability is most important, according to the IAB. I support designing new protocols over UDP Ð if they workout we can move them into the kernel. We have other WGs working on short-term implementations in user-land, with eventual realization in the kernel. Spencer: I thought the problem was that transport mechanisms were not hidden well enough for people to not be able to abuse them. So ths is not solving a problem, it is creating one. Marshall relaying Bryan Fordvia jabber: Why is Item 2, a mechanism that runs a new transport protocol over UDP, specific to TANA? If there is support in the IETF community for running transports over UDP, then DCCP, SCTP, and other new transports need that too. And if there is still strong resistance to running transports atop UDP, why will TANA surmount this resistance when all existing IETF transport projects have not? Gorry: Current methods have been deployed over UDP to try the algorithm and evaluate. In the long term, this is for TSV to sort out. i.e., whether we eventually need new transport protocol, or refer this to other working groups. Marshall: I am not against using DCCP (or some other) in addition. Briscoe: Would a new protocol support ECN? OSes do not let users turn on ECN. User-space program will not let you turn on ECN. Gorry: We are open to ECN or AQM or DiffServ. Bob: Anyone have a view if this proto could not also support ECN? A number of OS only allow ops to change ECN code points. Gorry: I think we should investigate this. Tom: Kernel implementations make Microsoft the gate-keeper of what gets deployed on the Internet. This argues for user-space implementations. - : I don't see why we define something new, if have scavenger class. So, the assumption should be that we do not have scavrngrt class. Stas: Deployment is a fact, as much as as I prefer... the Internet does not have currently have a scavenger class. If this were to be provided end to end, then this work is finshed. Rich: In our net (Comcast), if anyone sees DS bits set, they clear them. That is the way things work today. As part of this, we might give evidence that should not be clearing bits. 4. Summary of Current Position Chair: Please say who would like to see this taken forward as a work item at the IETF? Chair: Who were opposed top taking this forward at this time? Chair: Who wished to record that they abstained? Chair: Who wish to contribut to this work? Chair: Does the AD wish to say anything? Lars: no. End of TANA BoF