ICCRG IETF 91 MEETING NOTES Tuesday, November 11, 2014, 15:20-17:20, room Coral 1 Chairs: Michael Welzl (and David Ros (not present)) Note-takers: Stein Gjessing and Naeem Khademi --------------------------------------------------------------------------- TCP evaluation suite - need reviewers Lars Eggert: We have a master student working on it and didn't find any main issues with it, document understandable, ship it ! [Toke: I will read it] [Miria: I will read it] --------------------------------------------------------------------------- Agenda: 1. Should the initial window hang loose? 2. RMCAT 3. Lowering queuing delay --------------------------------------------------------------------------- IW10 discussion Initial spreading foils 1 and 2 Lars Eggert: I read old paper by John Heidemann on rate based pacing. Is this the same? Yoshifumi Nishida: Why does this only operate on the initial window? There are other situations where TCP can be very bursty. Michael Welzl: Not an author; can't say why Karen Nielsen (Ericsson): we are implementing this with SCTP but not only for IW but also after idleness... the answer to Lars is that, they're using random timers and some randomness in the timer. Have questions to the authors but they are not here, so will initiate discussion on the list Michael Welzl (Slide 3&4/10): Configuring TCP initial window (IW). Applications could choose their IW based on a formula depending on the flow size... Slide 5 (issues) Slide 6 (initial implementation) Slide 7&8 (Results) Slide 9 (Next steps) Michael Welzl: Q: What shall we do with the IW ? would it be good to have initial spreading or dynamic IW adjustment from the application or both? Jim Gettys: Problem is head of line blocking, many or most web pages go into bloated buffers and they have small objects, things that are most likely to help are mixing flows and spreading. I am interested in spreading. Haven't thought about the second thing much. David Dolson: Thoughts on API. More general approach may be to indicate whether it's a bulk or interactive transfer. Can have long lived flows with interactive pieces in it or email, API could configure DSCP and window side etc., more elegant Las Eggert: Initial spreading is the new word for pacing 18 years later, but makes sense. Discussed quite a bit, seems to be a goodi idea. The other IW proposal I do not get my head around. For large flows, doesn't really matter. For short flows it seems to be pretty complicated. First slide a bit incorrect: IW defined as a constant, but IW < 10: just use it, nobody will kill you. Michael: This proposal is more about system-wide vs. per-flow Lars: But it's a TCP in the RFC but you could choose to implement different constants for different flows in your OS. As long as <10 noone would care much. I worry about application signalling this and then something happens. Are we planning > 10 ? No, right. Then why not just use 10 for short flows, paced. That seems to be pretty simple to do. Length also doesn't say anything about sending behavior, which is what matters. Long flow but application-limited, is that really still a long flow? What about youtube style traffic? Michael: the way I got that it's all about the bulk length, this is what you specify Lars: But bulk length is one variable that can characterize many different flows, and doesn't characterize the sending behavior but this is what matters. I don't see the complexity worth the effort. Bill Versteeg: Lot of tools in the toolkit. It's not just the IW; consider a flow that's no longer paced by ACKs, when ACKs are queued up, it's rinse and repeat - or MPEG-dash style ... it's about the block size. Pacing got a bad name 8 or 10 years ago, it didn't deserve it, we need to give it a new name and think about it. Karen Nielsen About not only IW: also use it for SCTP whenever we switch paths we are starting again with IW and there are issues where we get congestion if we start up too slow, so it's not only about short flows. Question whether 10 should also apply for restart window. We've implemented IW10 for deployment but then realized it wasn't a good idea because what we had in pacing was probably too simple. We're looking for some guidance and solutions. Michael Welzl: Some form of pacing is also in TCP, there was a presentation by Yuchung Cheng at one of the last ICCRGs about that. Jim Gettys: It is called sch_fq and it's been in Linux for more than a year, and inside certain companies being widely deployed. Mixing scad and pacing can do really nice things all the way to the edge of the network. Michael Welzl: These are useful comments for the authors. Thank you Randell Jesup on Jabber (via Lars Eggert): SVD HDB-2 affects how this works. Websites are trying to make the browser generate a ton of requests to get faster load on good connections. Anything that pounds on connection startup will hurt competing interactive applications, i.e. RMCAT / WebRTC --------------------------------------------------------------------------- RMCAT related presentations --------------------------------------------------------------------------- Coupling Discrete Time Events to Continuous Time in RMCAT and Reasonable Bounds on the Time Rate of Change in Available Capacity Presenter: Michael Ramalho Jim Gettys: Very nice presentation. I will note that you can't solve fairness in TCP, that requires things outside of TCP to solve the difference-in-RTT problems. Not been able to understand how to do these things without fair queuing. About FQ-CoDel, well-paced flows are scheduled in preference to bulk flows that build a queue, which gives you preference for interactive traffic. There's an advantage to keeping two flows for a session because you can keep the audio protected from video. Zahed: Very nice presentation. My conclusion is, when a rate-based adaptation will figure out whether there is congestion, ACK-clocked based adaptation could start reacting. Michael Ramalho: No. ACK-based protocols work pretty well for the case where there is a problem, but you don't know if it's in the forward or the reverse channel. Rate-based proposals also have their place. Rough equivalence, nothign from a theoretical point of view that an ack based protocol does that we couldn't build a similar heuristic in a rate-based protocol. Example, I miss 1 or 2 ACKs - rate-based protocols could guess it's in the reverse channel. Wanted to get away from rate-based debate. Window-based protocol are superior in some dimension. From an analytics point of view you could take either one to accomplish what you want. --------------------------------------------------------------------------- A Delay Recovery Phase For RMCAT Flows Presenter: Geert van der Auwera Jim Gettys: In wireless and the like, also cellular we see lot of BW changes in both directions, bloat the same order of time of several RTTs and this is going to make control loop interaction problems more than entertaining..good luck with that! Varun Singh: Write this up so that some companies can declare IPR on this, such as Nokia. Other comment, RMCAT and FACK CC have undershoot mechanism to undershoot queue buildup so you can have a bounce-back, delay spike becomes narrower. I think this is a worthy mechanism that almost every CC should implement. TMBR is orthogonal to undershooting. Zahed: For this method that you're proposing, does it matter which encoder you're using? Geert: The method we have implemented is encoder-agnostic. Zahed: Good. But also like Jim Gettys I see serious control loop issues. Michael Ramalho: When dominant bottleneck is cellular or LTE link and you're the only flow on it, I guess you can make a nice calculation to back off. However, not only environment. Work over different bottlenecks, flows. Coordinated reaction between all flows going to the bottleneck having a similar kind of reaction should be used. Why is this better than other things that are simply using delay samples to control how much you throttle back? Geert: This is also delay sample based, and does not do this undershoot in every case, so this has to detect large delay build up or rate drop before this is triggered, normal probing phase where there is also a small queue build-up and detects congestion and then backs off. Those two are separate. --------------------------------------------------------------------------- Lowering queuing delay: --------------------------------------------------------------------------- How to reliably measure the performance of modern AQMs – and what comes of doing so? Presenter: Toke Høyland Jørgensen Jana: How many competing flows? Toke: 4 flows in each direction. Web: Huffington post (slide 13) Jim Gettys: Do you clear your local DNS cache between runs? Toke: Yes, we're using a user-space resolver that doesn't use the cache Yuchung Cheng: It seems overall as long as you have FQ it works better. It's FQ that wins, not particular FQ_CoDel or FQ_NoCoDel. Toke: I was actually surprised, a lot of the benefit of FQ_CoDel is actually from the scheduler and not from the AQM part. What you saw on VoIP was what the AQM does, it protects you from hash collisions and protects a flow that induces queuing that also wants low latency. So I think there's a good reason to have AQM in there but fair scheduling is definitely the major part of this. To graph on slide 16: seems SFQ is worse than FQ_noCoDel or FQ_CoDel, why is that? Toke: That's the sparse flow optimization of FQ_CoDel. The competing flows that measure latency are very slow, so each time they get a packet that will get priority through the priority scheduler through that sparse flow optimization. SFQ doesn't so that takes a whole round-robin trip between all the active flows each time it gets a packet through, and that translates into this difference in latency where if you look at the 100Mbit/s results the difference is smaller because it doesn't take as long to do a round-robin thing. Bill Versteeg: Recently completed implementation of fair queuing with PIE and can confirm same benefits. This is cross-traffic induced delay as opposed to self-induced delay. Toke: Yes Jim Gettys: Please dont randomly try this on an airplane (joking) WiFi seemed to crash close to when I was running tests. Will verify this with United. Don't know if that was me. Jana: I was on the same flight and I could not work (joking) Similar to what Yuchung said, it clearly seems that FQ by itself is giving substantial benefit. Under what realistic conditions should we look at what CoDel is giving us? There's one obvious condition when you have enough flows to have collisions you will start seeing the value, but outside of that? Jim Gettys: Besides hash collison, these flows represent some application. X windows system for example, i would like to run over the network, you dont want a really big queue to build for any application. Toke: I try to create framewoek so that pople can test with realistic traffic patterns, is work in progress. Bill Versteeg: Other are where it's useful to have is when several queues meet 3 queues, no matter how much you wish for you're not getting another queue. Toke: FQ_CoDel draft lists some instances where flow queueing may not work for various reasons. Jana: Having a measure for how much latency is introduced is good enough. Jim Gettys: I believe you should have a slide of various people who went out deploying this, it's a very substantial quantity in some places. Toke: Presentation on FQ_CoDel draft in AQM lists that. Mirja Kühlewind: Do you also have throughput plots for the scenarios shown in delay plot? Toke: Yes, plots generated from the same dataset. Mirja Kühlewind: I would imagine if you have low latency that also utilization goes down. Toke: No, not necessarily. Mirja Kühlewind: What kind of congestion control have you been using? Toke: That's not in here. Mirja Kühlewind: Point I wanted to make, you should regard those things together, not only show one part. --------------------------------------------------------------------------- TCP SIAD: Congestion Control supporting Low Latency and High Speed Presenter: Mirja Kühlewind Algorithm design: Further components (slide 10) Bill Versteeg: I encourage you to test this with steady-state cross-traffic, or statmux pool that is fairly flat rate against a statmux pool that has highly variable cross-traffic, cause this will be hard to get right when you're competing with a bursty sender Mirja Kühlewind: Our results with bursty cross traffic shows it's actually pretty good due to the adaptive decrease mechanism. Less sensitive to bursty cross traffic than other schemes I tested. Jana Iyengar: How do you decide the value of numRTT? Mirja: You have this as a default value in results shown, 20 RTTs; medium-speed access link, that's probably the congestion interval you see. Idea was that you have a default set fitting your access link and then the application can adaptively change it, in a higher-level control loop. Jana: numRTT changes how aggressively you yield bandwidth and how aggressively you increase. In that respect I'm trying parallels between how that's being used, and how MulTCP uses an n-connection thing. Mirja: For simulation setup it's an easy dumbbell scenario where you have N senders and N receivers etc. Mirja -- Slide 19: you can see the queue always gets empty and the congestion-time distances are equal Yoshifumi Nishida: No cross traffic and every flow has same RT? Mirja: Yes this is a very basic scenario. But for different RTTs for example you can use this parameter again to balance them out. Have parameter in no. RTTs or milliseconds.