ICCRG meeting, IETF 98, Chicago, IL, USA Monday 27th 2017 Hannu Flinck: Throughput Guidance draft-flinck-mobile-throughput-guidance-04 Hannu presented an update on experiments that used the mechanisms. Jana: What is authenticated mode? Hannu: The provider inserts info into the header authenticated with a CERT from the guidance provider (shared out of band). Ingemar: Without any help, the delay could be of the order of 1 seconds? Hannu: Yes, maybe. Ingemar: It would be nice to see a side-by-side comparison. Mirja: How frequently do you send this info? Hannu: We send each TCP ACK. Mirja: How often does the info change? Does the value really change more often than a RTT? Hannu: We update the info every ACK. Sometimes the rate change is faster than a RTT. Mirja: Does the sender follow the guidance directly? Hannu: This is decided by the sender after each ACK. A video server can choose a lower rate when it sees this. Mirja: I just wonder how much benefit there is from this? Jana: The re-buffer time is a measurable metric. Is there a distribution time for this? Jana: Is the model limited to pre-shared secrets? ?: Did you enable packet pacing? Hannu: No, this may improve things. Tommy Pauly: ICCRG + TAPS: On deploying new algorithms Tommy asked for help to review TAPS documents on evolving the Internet API. ? : The higher layer APIs like to expose requirements such as “low latency” Tommy, : We need to understand if these values are booleans, ... or real numbers? ? : Some parameters are well-known, some need to be debated. Fallback can be tried each time a connection is made to each try a different option and build up a picture of what is supported. Randell Jesup: How does this relate to UDP? There are a range of different approaches. Latency can have a range of values. Tommy: Yes, can you send an email to the TAPS list on RMCAT work. Christian Huitema: The classic problem is “everyone wants a pony”, sometimes it is better to know the trade-offs that need to be made when things go wrong. Tommy: Yes. Christian H: Video games have multiple trade-offs, sometimes background loading, sometimes realtime shooting. Jana: Current video games often do not have an API, what may that look like? video conferencing is another app with interesting tradeoffs, large capacity but also low latency. Mirja: Video has frames, is this already covered? Brian: We want to develop these use cases going forward. Jim Roskind: I like the idea of being adaptive. We listed four apps, and defaults should change and combine over time, so we can learn path awareness. Lin Han: Problem Statement: Transport Support for Augmented and Virtual Reality Applications Described network requirements for VR applications. Gorry Fairhurst: Have you thoughts on where AQM or ECN may help? Lin: This does not let you prioritize traffic. Gorry: How about DiffServ to differentiate traffic? Lin: We looked at RSVP, but this was not deployed. - Even for 5g it is hard to realise this type of latency. Lin: This is for wired end to end. This is very challenging. Randell Jesup: Look at FEC, and algorithms for video encoding that avoid I-frame bursts. You have to deal with packet loss, and avoiding keyframe refresh is important to not glitch on errors. Wolfgang Beck: I did some work with processing at the receiver to allow local movement to be compensated in the device. Is there really that much need for low-delay network paths. Lin: This still needs low delay for interactive cases. Christian: The constraint can be divided into two parts, you need the remote server to send a 3D object that can locally be re-rendered for movement. This needs computing at the local device. Lin: There are many ways. Matt Mathis: Maybe there are some things the network can not do faster, there are transport things that can be done, but you need to think about the way you use the Internet. Local rendering is important. Koen De Schepper: L4S TCP-Prague Presented design considerations for developing TCP-Prague. Matt: Do you have anything written down on RTT fairness? Gorry: How likely is that we will have a document by the next Prague IETF that the WG can start to think on. I’d think many people in ICCRG would be interested in this. Koen: We would be happy to share info. Ingemar: This may solve the latency problem from the last talk, so this may fit well in future transport work. Interesting. Matt: How can you cope with loss, which also becomes a problem at high transmission rates - other work is trying to reduce the effects of loss. Neil Cardwell and Yuchung Cheng: An Update on BBR Congestion Control Described BBR deployment in google and open research issues. Jim Roskind: QUIC was defined to monitor one-way times, has there been progress to use pacing rate v receive time in QUIC? Can you comment on this? Neil: This is on the list of things to experiment with when we get a chance. Koen: We tried BBR with a few things. There were things we saw on your list, one was the the fight between AQM and BBR - when the two have different goals, and AQM produces loss that depends on a different model, this can be a problem. Competition with other CC can also cause a lot of loss, with oscillation. Neil: I would like a scheme that models the buffer scheme of a buffer that can work across AQM and FIFO queues. The dynamics interacting with other controllers. One thing is to allow BBR to try to find out whether the capacity it sees is a result of its own decisions, not paying attention when it is not probing for bandwidth at this time. Tim Shepherd: Is there a sad part here when working with cellular links. Neil: We try to make sure that the test probe packets are added and then removed after the tests. Matt: There are link-layers that require backlog to do load calculation this is a design tradeoff that has to be done globally - i.e. we need the queue decisions at layer 2 and layer 4, these are not independent design decisions. Randell: RMCAT has algorithms that resemble this Praveen Balasubramanian: Is there going to be a draft? Neil: At some point we may write a draft. Praveen: What are the possibilities of incremental deployment? Neil: We think this is good - not too nice like TCP-Vegas, instead BBR has the right incentives (usable when cooperating with Cubic). Praveen: Was BBR sharing the bottleneck with other CC? Neil: We took a sample, in most cases the flows would not likely be sharing, we often see a single CC for our traffic. Praveen Balasubramanian: Reflections on Congestion Control This talk will be taken in TSV-Area meeting today.