Tuesday, November 5th, 2024, from 13:00 (UTC+0) to 14:30 (UTC+0) (90
mins)
Chair: Michael Tüxen
Note Taker: Stuart Cheshire
Michael Tüxen presented update on Working Group document status
draft-ietf-tcpm-prr-rfc6937bis
Neal Cardwell (Google) (remote) presented updates on document status.
No questions or comments from the meeting room.
Neal Cardwell will post updated revision in the next day or two.
Gorry Fairhurst (University of Aberdeen): Please post that revision and
we can review it.
Yoshifumi Nishida (TikTok): This document has already completed Working
Group Last Call. These updates are minor and do not require another Last
Call.
Michael Welzl (University of Oslo): I support the two changes that have
been made in the draft.
draft-ietf-tcpm-tcp-ghost-acks
Michael Tüxen presented slides on behalf of authors Prof. Dr. Christian
Rossow and Yepeng (Eric) Pan.
No questions or comments from the meeting room.
Yoshifumi Nishida (TikTok) presented slides on behalf of authors Joe
Touch and Wes Eddy.
Matt Mathis (Freelance): Did the authors consider revising the semantics
of other TCP options to allow them on the first EDO segment after the
SYN?
Yoshifumi Nishida: I cannot speak for the authors, but personally I
think this is a little tricky.
Michael Tüxen (Münster University of Applied Sciences): If GSO and GRO
have to be disabled to use Extended Data Offset, how much does this
degrade performance today?
Gorry Fairhurst (University of Aberdeen): This work is ten years old.
How much does the Working Group remember about it?
Lars Eggert (Mozilla): The Working Group does not have energy to work on
this. The fact that the main proponent of this is unable to participate
to present the proposal at the Working Group meeting is symptomatic of
this.
Lars Eggert (Mozilla): Having to disable GSO and GRO makes this
impractical for real-world deployment.
Yoshifumi Nishida: This is a chicken-and-egg problem. If the RFC is
published then commercial GSO/GRO hardware may be enhanced to support
EDO.
Gorry Fairhurst (University of Aberdeen): What is our goal here? To
publish an Informational RFC that allows people to experiment with this?
Lars Eggert (Mozilla): We don’t see a compelling workload that needs
this, or hardware vendors lining up stating their enthusiasm to
implement EDO in their hardware.
David Schinazi (Google): People who want to experiment with this do not
need and RFC to give them permission to do that.
Yoshifumi Nishida: I support publishing this document.
Lars Eggert (Mozilla): Let’s have an informal show of hands to gauge how
much interest there is in this.
Do you think the WG should progress the Document?
Out of 44 people in the meeting:
6 Yes
14 No
4 No opinion
draft-ietf-tcpm-ack-rate-request
Carles Gomez presented overview of TARR.
Document adopted by Working Group February 2023.
Draft-06 addresses comments from IETF 120.
Matt Mathis (Freelance): TARR is relevant to L4S community. Sparse ACKs
without packet pacing inflicts burstiness on all other flows. Inflicting
burstiness on other flows it a top-level concern. It is harmful and
increases the chance of queue overflow. The document should say
something about scenarios where TARR should only be used in conjunction
with packet pacing, to avoid excessive burstiness.
Stuart Cheshire (Apple): I support this document. For very constrained
devices it is very useful to allow an ack for every packet. I also agree
with Matt’s comment about being careful to avoid increasing burstiness.
A sender should only request sparse ACKs if it is also doing packet
pacing.
Matt Mathis (Freelance): I agree, but if the burst size is 1 ms or less,
then it’s okay to send a burst without pacing.
Gorry Fairhurst (University of Aberdeen): We should recommend pacing. It
should not be conditional based on burst size.
Neal Cardwell (Google): Recommending aiming for one ack per millisecond
is good practical advice.
Eric Kinnear (Apple): One ACK per millisecond seems like a reasonable
recommendation.
Matt Mathis (Freelance): Burstiness saves CPU load for the sender by
inflicting jitter on other traffic. It ought to be a policy parameter
for the Internet. We should recommend minimizing burstiness. It might
not belong in this document, but discussing how much jitter is
appropriate should be on the agenda for the IETF (maybe CCWG).
Jonathan Morton: Use pacing to reduce burstiness.
Stuart Cheshire (Apple) gave overview of the source-buffering delay
problem.
Jonathan Morton: You could also solve this by not trying to fill the
bandwidth-delay-product of the network pipe, and instead being content
to have only one frame in flight at a time.