ICCRG meeting minutes, IETF 89, London, UK Monday, March 3, 2014, 15:20-17:30, room Balmoral ----- Renaud Sallantin, Safe increase of the TCP's Initial Window Using Initial Spreading, 20 min http://tools.ietf.org/html/draft-sallantin-iccrg-initial-spreading-00 * Andrew McGregor: implementation consideration: use fq queue discipline * Bob Briscoe: how about using information from previous session for initial window? you are increasing mean completion time to decrease variance, any reasoning how much you should do this? Do you have thought framework about where the bounds to these tradeoffs are? * Richard Scheffenegger: jiffies are synchronized between multiple TCP flows. you are sending bursts from different TCP flows when you have multiple flows. break synchronization between flows * Michael Scharf: mostly simulation results? done pacing tests myself. pacing in simulations have better results than in practice. there is more randomness. be careful when looking at simulations * Matt Mathis: you really want to pace TSO bursts into two-three packet bursts, you cannot do it with jiffy timers * Raffaello Secchi: pacing also useful after tcp idle periods. question about correlation between packet losses: do you have evidence about sychronization of losses? * Andrew Mcgregor: you do see correlated losses. clock events are synchonized. fq_codel / Dave Taht has published lots of information about pacing in AQM. ----- Keith Winstein, The Latest in Computer-Generated Congestion Control Protocols, 20 min (see http://mit.edu/remy for background info) * Matt Mathis: immediate reaction: what happens when network gets to a state that is completely outside learning space. Focus should not be about fairness but about safety. Quest for fairness in TCP has been somewhat misguided. Van Jacobson was looking for global stability, not so interested in fairness. It is easy to construct cases where fairness does not work. * Keith: TCP over current internet is not safe anymore. * Sorin Farish: current congestion control solutions become irrelevant with SDN. Therea are different ways to take care of congestion problems. In the new context solutions will be different. * Keith: Agree, by building new kind of networks, we learn new things about TCP and congestion control * Mirja Kuehlewind: Initially sounded like cool idea. You cannot guarantee that everybody is using the same congestion control * Keith: This is an emperical question, we can measure cost and benefit of TCP friendliness. * Mirja: You normally don't know about network, model assumptions are not always clear. * Keith: Reno or Vegas specify behavior, they do not do assumptions about network either. * Lars Eggert: Keith is the winner one of ANRP prizes, there will be another presentation tomorrow ------- Wolfram Lautenschlaeger, Global Synchronization Protection for Packet Queues, 20 min http://tools.ietf.org/html/draft-lauten-aqm-gsp-00 * Michael Welzl: how do you know the RTT? did you validate it with different RTT? * Wolfram: just parameter, should be like typical RTT in your network. Tried different combinations * Costin Raiciu: Did you start connections at the same time? (A: yes). Then they are synchronized. Mark Handley and Damon at UCL found that you don't need bw-delay buffers, if you have many flows. * Wolfram: if you have many flows, forget about syncronizations. different flows run at different bit rates, doesn't matter that they start at the same time. * Gorry Fairhurst: 1) what was the traffic workload? bulk transfers or web? (A: long lasting simultaneously sharing flows) 2) I did not get the RTT part: what happens when flow RTT is much larger than the AQM-configured RTT? (A: then you have two or three drops, it still is better than nothing) ----- Greg White, A PIE-Based AQM for DOCSIS Cable Modems, 20 min http://tools.ietf.org/html/draft-white-aqm-docsis-pie-00 No questions or comments ----- Lingli Deng, Further considerations on data center congestion control, 15 min * Lars Eggert: year or two ago had a lunch meeting in SIGCOMM to start datacenter research group. Comment was that nobody is sharing any data, so it is hard to come into solutions. Can have ideas, but need to know about traffic patterns. This has to change somehow. * Jon Crowcroft: We don't have common language to this. What do you mean with virtualized router? Need high-level language to describe the virtualized solution. Totally agree with lack of information. Many people have data but they are not sharing it. IRTF should reject work if you don't share the data. What is network hypervisor? Very little written down * Zhu Lei: Need to consider end to end congestion control. Consider using ipfix or such interfaces for managing traffic. - A: If you have questions bring these questions for open discussion on Friday