Time and Date
Monday July 21, 17:00 - 19:00 CEST (See this time in your local
timezone)
Location: Hidalgo
Mo Zanaty: What differences in latency did you see with universal
AQM vs others?
Jason: Working latencies cut in half when we turned DOCSIS-PIE on in
the core, that was a huge win. Dual queue on top was half again, see
Stuart Cheshire's presentation, idle latency improved as well.
Mo: Roughly same order in each phase?
Jason: 50% reductions in each step, dual queue got you pretty close
to idle latency.
Alessandro Ghedini:
Jason: clarifies that change in behavior on slide 6 is when
downstream AQM was activated
Alessandro: Did things get better because the capacity changed?
Jason: No, the capacity is the same, it's just the introduction of
the dual queue AQM. A realtime flow prior to this change would lose
to queue building traffic, now it's much better for interactive
traffic.
Alessandro: Any specific CCA you were testing with?
Jason: Running DOCSIS PIE, not BBR
(later in chat): the test originates on a CPE that has DOCSIS-PIE
on its US interface and downstream hits the CMTS interface with same
AQM. It is not limited by the CCA on the linux speed test server.
Mohit Tahiliani: Slide 4, what do the different lines mean?
Jason: Upstream and dowstream; dashed line is the "goal" what the
tests were aiming for
Neal Cardwell: number of parallel connections in the tests?
Jason: thinks it could be 4, but is still subject to tweaking
Neal: changing the number of connections might no longer reflect
actual user performance
Jason: external speed tests, such as Cloudflare, did not show any
change. they might be using multiple connections, too
Neal: These are different classes of test, first classic ECN, second
mixed like you get with Apple + Linux, third is L4S
David Black: Good to see the algorithms doing what they're supposed
to do in practice, and at scale. Would strongly support measuring
additional things, so that we can optimize it. Focus on what matters
to the users.
Jason: Agreed.
Show of Hands: I have read draft-welzl-iccrg-pacing (any revision)
Show of Hands: I think ICCRG should adopt draft-welzl-iccrg-pacing?
Reese: we will run formal adoption call on the list
Neal Cardwell: choosing token bucket size such that it avoids packet
loss?
Zili: yes
Neal: It seems like we care about queueing delay in the middle of
the network too, not just loss. How about combining with TSO and use
a pacing rate that works well.
Zili: Good point. Queueing delay in the middle network is equivalent
to the queueing delay in the pacing buffer.
Neal: Not equivalent. The influence to other competing flows will be
different if burst out.
Zili: worthwhile to consider in the future.
Tongyu Dai: How is the quality not affected if the key frames are
reduced?
Zili: ACE does not reduce the key frames' sizes -- it adjusts the
frame size of p-frames at the cost of additional encoding time
instead of quality.
Tongyu: Will the codes be open-sourced?
Zili: will open source code before the SIGCOMM conference
Jana: have you done experiments with multiple senders using your
scheme?
Zili: only initial experiments, there will be interactions between
these senders. we have thus far mainly checked with other senders
Mo Zanaty: do you integrate your bucket with the buckets of the
encoders?
Zili: our buffer is after the encoders
Jana: What are the sender-side signals you are using?
Ali: It could be any defined signal
Jana: Is this theoretical or are you doing it?
Ali: Implemented.
Mo Zanaty: there is no established way for senders to have
receiver-side view and vice versa. We currently have
application-specific solutions to this problem. might be interesting
to aim for a generic signaling solution
Ali: this is a transport layer-independent challenge as it also
depends on info provided by application layer
Jana: follow-up to Mo. Streaming is a particular kind of application
that can enable this
Tongyu Dai: Is ABR implemented on client-side? How combined with CC
on server-side?
TY: Did this on client-side.
Tongyu Dai: Traffic will coexist with other services or
applications. How do you ensure everyone will be "nice"?
TY: Services or applications have to keep each other in check.
Alessandro Ghedini: How exactly does the interaction work? Do you
always pace at the maximum? What is the time frame?
TY: We do this on segment level. Tell congestion control what
maximum speed we need.
Jinghao Yuan: What's the interaction between client and server?
TY: We have a side channel.
Will Law: Netflix/Youtube have lucky position that they control
sender and receiver. There are also standards for CDNs (who don't
control clients) and clients (who don't control servers) to
exchange/retrieve information. Akamai would like to provide this
capability if there's interest. Would be great to look at interop
possibilities.
Mo Zanaty: There needs to be a more fine-grained API between CCA and
application to resolve issues that are for example highlighted by
seemingly conflicting proposals (refers to ACE presentation)
TY: We aim for combined logic, not two different ones that
communicate via API
Jana: Not sure there's anything to standardize here. But the talk
shows that CC and applications can work together
Jason: CC landscape was ossified for long time. Streamers had to
find new ways to address this. Good to see progress and that new
flexibility on transport can help. Interesting where the equilibrium
will be.
Simone: Part of the intention of this panel was to illustrate the
problem. We have the opportunity to create documents in this group.
Could be benchmarking or otherwise. Let's continue the discussion.