ICCRG Session 1 Monday, July 29, 2013, 16:20-17:20, room Tiergarten 1/2 Emmanuel Lochin, FavorQueue: a Stateless Active Queue Management to Improve TCP Traffic Performance Tim Shepard: Difference between FQ_CoDel and FavorQueue? the former seems to achieve exactly the same as the latter. A: Have to look into FQ_Codel, don't know it. Bob Briscoe: Can a user game the system by splitting a large flow into small flows? A: Not sure, have to look into it. Mirja Kuehlewind: Definition of latency in results? A: Flow completion time. Alexander Zimmermann: slide 1 says the mechanism is stateless, what is the computational complexity? A: Stateless was maybe a bad choice of words, it's parameterless. Puneet Agarwal: Q about complexity / statelessness of the algorithm. A: Wouldn't be a big deal on a home router. Pat Thaler: Q about fairness issues. There should be no impact. Midori Kato, DCTCP implementation in FreeBSD Mirja: About question on if/how to reduce cwnd on first ECN mark: need to look at link utilisation and latency simultaneously to decide. Mitch Gusat: on setting of ecn_thresh and queue length (?) Michael Welzl: About the first ECN mark: other than the data center case, we don't have instantaneous queue marking, so if used in the wild, DCTCP must react in some more conservative way on the first ECN mark. Bob: You use yet another way of signaling ECN feedback. Microsoft's DCTCP implementation has another method, we need to standardize a common way of doing this. Mirja: We have also implemented DCTCP, ? (implementation details). Lars Eggert: Note: possible IPR from Microsoft. Bob: We have gone through the patents and it'd seem they wouldn't hold. Randy Stewart: on BSD implementation and IPR. Yuchung Cheng, packetdrill: Scriptable Network Stack Testing, from Sockets to Packets ICCRG Session 2 Wednesday, July 31, 2013, 13:00-15:00, room Tiergarten 1/2 Lars Eggert -- clarified IRTF IPR policy: if you or your employer have IPR on contribution, you MUST disclose it. Pat Thaler and Rong Pan, The 802.1Qcu congestion notification algorithm [Slide: simulation parameters] Ken Carlberg: Timer period is 15 ms, is there a basis for that? Rong: we assume max 500 us RTT, you allow a few RTTs for feedback. Pat: Also related to sampling rate, you want to spread that out. If you send a fair quantity of data, the byte counter timer will expire first. [End of Slides] Victor Firiou: I think I have seen this before, why's that? Pat: We were asked to present, we finished this three years go, simulations took a while, little bit more researchy than usual. We started working from 2005. Victor Firiou: How about other kind of traffic that is not uniform, how it interacts with control loops, two ethernets, on top of it TCP? Pat: We looked at a network with multiple stages, each having congestion notification, priority-based flow control operating, pushback in link flow control, making sure it still is well behaved, looked at other topologies (parking lot, ...). This is only a small fraction of sims. Different traffic distributions. That's how we developed several stage recovery. Mitch Gusat: We do have available results, different TCP variants. Most results show that scheme works. Pat: i'm confident that this is stable and well behaved. We looked at a number of schemes, several competing proposals tested in initial phase. This is reasonably quick. Victor Firiou: Was there another scheme compared? Pat: All simulations are on the 802 web site on public area. There were four schemes initially, one that Mitch brought initially. Douglas Leith, Congestion control in CTCP Emmanuel Lochin: You don't talk about the coding process, is it block code? systematic/non-systematic? And is this fair against standard TCP? A: Systematic code. have estimate of packet loss rate. transmit certain number of random linearly coded packets, block size is 32. If you recover enough packets, otherwise ARQ response. Decoupled from congestion control. Delay-based mechanism for congestion control. Same as standard tcp for congestion control, there is a feedback loop. Tim Shepard: you changed coding and congestion response. can you tease apart these two? A: it is not in the paper, but I do have more recent results. For long lived flows TCP is controlling the rate. You can run it with ARQ, but the delay goes to the roof. For the short lived flows it is decoupled. Tim: looks like you used increased delays. didn't understand. If you were seeing no additional delay, no backoff. What if AQM is signaling congestion, such as codel. what if you detect loss. A: if there is ECN of course you react. if there is loss, haven't analysed. if there is no sending queue Tim: if the current RTT matches the shortest you have seen, I don't think you respond to congestion A: True, might need to fix that Naeem Khademi: TCP's beta factor modification is a good thing, you need to measure min RTT. how would min RTT fluctuate, e.g. on WiFi links? A: there is a lot of data, i will send you some links Richard Scheffenegger: Tim made a valid point. The implicit assumption is that you have a queue that grows delay. AQM tries to reduce the standing queue, if RTT changes, your flow will impact itself. A: questions are how common is that? compound tcp will suffer from that. Ramin Khalili, Congestion Control of Multipath TCP: Problems and Solutions Question by speaker: shouldn't OLIA be default CC for MPTCP? Michael Welzl: Irrespective of whether this would eventually be published via MPTCP or ICCRG, reviewers for this document are sought, please volunteer. Lars: Claim is better load balancing, but results were throughput, any results on load balancing? A: experimental results on slide 17, more in the paper Michael Scharf: How does scheme work when there is application limited traffic, haven't seen this discussion in MPTCP. A: Similar to LIA or whatever CC algorithm. Important question to analyse, how does TCP react, not perfect either? Also some problems on receiver side about how fast app can read. Simone Ferlin-Oliveira: some experiments on LTE. Did you observe interesting effects for MPTCP, e.g. regarding the RTT? A: results showed LTE vs. WiFi also for MPTCP. Simone: how about switching between 3G and different link technologies? Nicolas Kuhn, Mitigating Receiver's Buffer Blocking by Delay Aware Packet Scheduling in Multipath Data Transfer Karen Nielsen: do you have packet losses? A: at the moment no. we can't do worse than what CMT is doing Yuchung Cheng: interesting that you look at receiver HOL problem. TCP has exactly the same problem. any plans of looking at TCP? There is no real-world SCTP traffic. (side comment from Mirja: There is no multipath TCP on real-world either) A: we plan to do it Yuchung: are you aware of the Minion work? With it, out of order packets can be read on the receiver side. David Hayes, An update about the TCP Evaluation Suite Mirja Kuehlewind: how are you planning to move forward? are you waiting results? RMCAT also looking for evaluation material A: any input welcome Michael Welzl: we want that to get this draft finished Mirja: interesting to have artificial very short flows that do not get out of slow start. interesting corner case A: majority of flows in the traces are that Lars: RMCAT does cc for media, want to significantly refactor this, tease apart topology, metrics and traffic patterns. topologies could be taken to RMCAT, some of the metrics too. If someone would like to do it would be useful Michael: practical problem: payroll of our project, if we don't do it, we need to find a volunteer. Lars: funding could be found Yuchung: question about flow completion time metric. Not very representive for HTTP or other persistent connection. A: flow completion time is a difficult metric, maybe burst completion time would be better Michael Scharf: metrics are the key problem. getting useful metrics is a key challenge. traces have a lot of detailed issues. evaluation is the hardest problem Mitch: look at 802, we have quite a number of metrics, topologies, we have learned tough lessons of Flow Completion Time on layer 2. Difficult to have deterministic controlled scenarios. Mirja Kuehlewind, SimLib-QEMU: TCP Simulations integrating Virtual Machines Lars: can you run on a cluster? A: not yet but there are plans. you can have several connections in one kernel Damien Saucez: why wasn't it easier to fix NSC? Why did you do a separate system? A: they only use part of the kernel, here you can use a full virtual system, any applications Damien: Can you send this to the ?? mailing list (mailing list related to NSC) Michael Welzl: use ICCRG mailing list