ICCRG minutes, IETF 85, Atlanta, Monday, 5 November, 13:00-15:00, Salon A Scribe Andrew McGregor Lars Eggert: The IPR disclosure notice has been updated. New chair: David Ros Rong Pan: "A new algorithm for dealing with buffer bloat", 20+10 min Jana Iyengar: What is the UDP traffic? RP: CBR Kath: How wide are the spikes in the PIE latency graph? RP: 200ms or so Matt Mathis: Is this using fixed A&B parameters? RP: No, it's autotuned, but same algorithm for all experiments. Andrew McGregor: What's the effect of this on DNS requests?  fq_codel doesn't drop DNS requests, ever... x: Have you tested with multiple very high speed flows? RP: Not extensively, we have around 20 nodes Jana: Going back to a&b parameters... RP: We have a&b, have run analysis and know what values are stable, but we can't necessarily set single values.  Autotuning is better.  The values are related to drop probability.  I will release the analysis details, it naturally scales to very high speeds. Jana: You're using a proportional controller to seed the drop probability.  So, where does PIE break?  Where are the edges? RP: When you have autotuning, it tends to break less. Jim Gettys: 30ms is too much for lots of real time things... it's a total budget.  How does this behave when you try to control the latency to a much tighter behaviour. RP: At 5ms, we have to use a virtual queue on low speed links due to single packet jitter. Jim: How sensitive is it? RP: 20ms and 15ms seem OK, 5 gets a bit unstable. Lars: It would be good to get some CPU analysis.  The link rate drop is not particularly saying anything about radio, because RF links are very different. Fred Baker: Something about 802.11 that I didn't understand (doesn't correspond with my understanding of 802.11 so I was confused) Nestor Michael C. Tiglao: "Transport layer caching mechanisms and optimization", 20+10 min Matt: Are your end-systems a restricted class of devices? NT: No, they're not Matt: Is there any optimisation to be done by knowing the particular algorithms in use in the end systems. NT: No congestion control yet Gorry Fairhurst: "Updating TCP to support Rate-Limited Traffic"draft-fairhurst-tcpm-newcwv-05 Matt: Cool stuff.  One of the things that has been bothering me is that we don't understand what the normal worst case for TCP is.  If we are in equilibrium with other traffic, stop, then restart, what's the impact there.  Compared with, what happens if I send into a large pipe with less headroom than my own link.  We don't have a good model for another case either (missed it).  These are the things to compare with. GF: Not that I have these models, but this is intended to deal with those cases, and be very conservative when there is a problem. Matt: The most common case is someone else fills the capacity when you back off. GF: Traffic is more bursty than you think... Matt: Yep. Randall: The flows are not long in real networks, I'm lucky to see 10 in 100k flows that last more than 2 minutes.  How does this affect these shorter flows? GF: This is actually better Yuchung Chen: Majority of data is sent on persistent connections... have you considered for the 5 minute threshold, that apps will send at 4.9 minutes?  What if we don't reduce the window at all? GF: The reason for this timer is... if lots of apps have large cwnd, and they all restart at once, this is bad.  You can't really guard against it, but may as well reduce it.  This isn't so much of a problem, it just implies eventually you have to do a slow start. Yuchung: I agree this should be safe GF: This is all about making sure you do better.  There are times when you Yuchung: Why not pace? GF: Not sure we know how to do that right. Mirja Kühlewind: Still concerned that this can cause large losses...  GF: Lots of people are using TCP without decreasing cwnd in this case.  I don't particularly fear this because of that. Matt: The experimental RFC is not widely deployed in those places where it should be. Piers O'Hanlan: Could the same kind of behaviour be applied to rmcat? GF: It's a bit like tfrc.  We believed Mark Allman's message that you should consider how much data you lost when you were in a problem state.  Question is, is that big change applicable in rmcat, becuase it implies a large dynamic range. Jana: I think this is very useful and important, and I agree there's a lot more burstiness than we are led to believe.  That said, the 5 minute gap... it seems like pushing away a problem.  But you might as well keep it open.  Have you thought about reuse of other long-term info? GF: This expiry wants to take place after long enough that you consider congestion state is invalid. Jana: So that amounts to a CC restart after long idle? GF: yes Matt: I actually think the 5 minutes is more conservative than it needs to be.  Backfilling and topology change both have a few seconds timescale.  I wouldn't argue against an hour. Piers O'Hanlon: Can't you derive the good number from an RTT distribution? Open discussion about the applicability of more precise ECN signalling Mirja: What can we do with more precise ECN?  Right now ECN should be treated as loss, but what else might you do? Bob Briscoe: At the moment with SACK you get more accurate loss information, we are bringing ECN up to the same level as losses. Mirja: Do you want to use loss amounts in CC? GF: I want to count losses when we move into non-validated phase, which would be different to ECN marks. Mirja: The research question is also, what do the marks mean? Michael: Is there other published work on using more precise ECN except DCTCP? Matt: Not aware of work in that space.  There was a straightforward game theory argument that if ECN were not equal to loss, there would be deployment problems.  The whole branch of research space was not explored.  Of course, the problem still exists.