Minutes IETF98: iccrg
minutes-98-iccrg-00

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.