Minutes IETF114: tsvarea: Mon 13:30
minutes-114-tsvarea-202207251330-01

Agenda
Administrivia - TSV ADs (10 minutes)

• Session Recorded, Note Well, Blue Sheets, Jabber Scribes, Agenda
  Bashing
• TSV Overview and State of the Area

Special Topic: The Future of Congestion Control at IETF (45 minutes)

The Transport ADs are going to consider chartering a new IETF working group to update the administrative framework for congestion control standardization, and potentially adopt any proposals that are sufficiently mature for the standards track. We've formulated a proposed charter. Please consider it a starting point for discussion. https://github.com/martinduke/congestion-control-charter/

Please review this document before attending. It answers many of the questions you may already have.

In Philadelphia, we hope to answer as many of the following questions as possible, in order:
- Is there rough consensus on the problem to solve?
- Are the deliverables right?
- Are there people willing to take responsibility for those deliverables? (The meeting is over if the answer is "no")
- Does the proposed charter need changes?
- Is anyone especially excited to chair this WG?

Open mic (5 minutes)
Slides

Discussion on congestion control:

• Martin: Is this a problem? (as stated on the slides)

  • Jana: We get lots of iccrg presentations, but not much docs.
    Issue is that getting consensus is not necessary for deployment.
    Company can deploy the CC algorithm unilatterally. 3rd point is
    that the problems of multiple transports we've solved in tsvwg

    • Martin: Part of the goal is to have a more robust process,
      including feeder docs from iccrg. Current process RFC 5033
      was written in a different time.

  • Jonathan: disagree with Jana, congestion controls do have to
    interoperate somewhat, not entirely unilateral. For new
    congestion controls, you need some coordination and highlighting
    of issues. new group would be at least interesting.

  • Gorry: Agree there's a problem, I haven't yet seen anything that
    might work. When it comes to congestion control, it's hard to
    demonstrate that you don't have an impact on competing traffic.
    Tricky to measure.
  • Toerless: A WG would help, since we don't any more have only one
    protocol, now there's also QUIC. Do not want the QUIC become
    like OSPF group which contains everything. Needs to be outside
    of protocol-specific wgs, and a wg would be helpful for that.
  • Matt Joras: Current discussion lacks nuance distinguishing
    congestion control from loss recovery. These are related but not
    the same. Loss recovery is protocol-specific, but there's
    implications for congestion control.
  • David Black: This is a complex space. Agree there is at least
    one problem--there are at least 3 domains: access
    (wifi/mobile,need to deal with radio interference), backbones
    (where congestion is usually evidence of operator error), and
    datacenters, where we've seen lots of discussion about the
    datacenter CC that goes nowhere in IETF because it's not
    Internet. Need to figure out what we want/don'twant to do about
    datacenter congestion control
  • Jana: Lots of PhD dissertations on congestion control, we can
    and do talk about those in ICCRG, but the interesting thing for
    IETF is about deployed congestion control. We've got BBR, FAST,
    and a huge number of CC algorithms that aren't documented in the
    IETF. The people who have deployed CCs don't see value from
    publishing an RFC, and plus it evolves. By the time it goes thru
    2 years of debate in IETF, the deployed CC has changed,
    particularly on tuning values. Also: +1 loss recovery is
    dfferent from CC. What's the overlap and what's the gap between
    tsvwg and the new cc wg. If we want to charter a new wg to
    document deployed congestion controls, we need to see people in
    the room who want to do that documentation.
  • David Black as tsvwg chair: tsvwg would love to not have the cc
    arguments there, we have other useful work to do.
  • Spencer: 1. is it useful to break CC into components like rate
    control vs. loss response--if one of these is more controversial
    than others, maybe we should know? and 2. wgs also produce BCPs,
    not just specs. Might be useful to write up what's expected to
    feed into ietf
  • Vidhi: We're interested in pubblishing CC docs, yes. Also, it's
    not that useful to compare always against reno just because
    that's standard in today's actual deployed status. But yes,
    we're working on a number of things including L4S admission
    control, not clear where we'd take that without this wg.
  • Bernard: 5033 does clearly need to be revised, you don't have to
    know everything right away to charter this group.
  • Toerless: would be good to have a path to gradually adopt and
    evaluate all this new experimental cc work from phds, right now
    process does not lend itself
  • Zahed: yes, this wg would be about stuff that gets deployed
  • Martin: yes, experimental rfcs can come either irtf or ietf, and
    this doesn't change.
  • Jonathan: It was questioned why newreno is a standard, and the
    the reason is because it's the minimum required to avoid
    congestion collapse on the internet. As simple as that.

Martin Chartered Items slide

• Toerless: re: new algorithms mature enough for standardization,
  maybe not just standardization, but also include experimental
• Ian: charter with loss recovery removed I support more strongly.
  CUBIC and BBR both written under TCP, not really designed to apply
  to QUIC today, this charter looks like it's going the right
  direction
• Toerless: How does this overlap with work in existing groups? Should
  ask chairs of those groups.

• Jana: I don't understand the questions on the charter because I
  don't understand the premise of the wg? Not sure I've got this,
  there's a lot to unpack. (See comments in chat). I think there's
  misalignment between where the IETF is and where the people working
  on these are. You'll definitely get some work, but you'll be missing
  a lot of the point. If you make a wg with enough scope to address
  the issues it needs to, it'll be hard to close it ever or soon. This
  is not a concrete enough ask, at present. Lots of attempts in iccrg,
  this seems like it'll have the same issues.

  • Martin: This is administrative work. There's a few things out
    there now, e.g. TCP Prague. If they were ready to standardize
    today, we wouldn't be in a good place to do it.

  • Toerless: @Jana can you reformulate the comment as suggested
    changes to the charter?

    • Jana: I'm questioning the premise of the charter, I would
      delete it. But to clarify: is BBR one of the docs for this?
      Is loss recovery sharing between QUIC and TCP one?
    • Toerless: This seems similar to the reliable multicast,
      working on building blocks as separate pieces. With these we
      can develop how we can develop things like BBR as standards
      vs. experimental
    • Martin: in terms of things to standardize now we've got
      well-known examples that presently have wrong status, eg.
      dctcp and cubic. Some other things not yet ready, but the
      intent is to have this wg make us ready by the time those
      are ready
    • Gorry: The problems permitted by the charter have too wide a
      scope. To me they look like research prolbems, not things we
      standardize now.
    • Bob: To Jana's question on what drafts are covered: would
      AQMs be in this? AQM needs the same expertise and has strong
      interactions. These need a place for standards track work
      too.

  • Martin: please file issues/PRs in github on the charter text.

Martin: I hear concerns from Jana about whether this is a good idea, and
otherwise relatively strong support. Checking polls:

Would you be inclued to co-author any of these drafts:

• raise hand: 17
• do not raise hand: 27
• participants: 44

Martin: this is enough people to produce the desired documents,
detecting sufficiently strong support. If others have unexpressed
concerns please raise them.

Zahed:

Jana: CC is an active and dynamic space, we ought to engage in that
space and make a forum for it, but we need a different format, the
existing templates for wg activity are not sufficient for this. Need to
create a community NOT at the IETF, operators &c, discussions where we
take what we can get, and discuss what we can do with it.