TCPM meeting, IETF-120, Vancouver

Tuesday 23rd July 2024, 13:00 (UTC-07) to 15:00 (UTC-07) (120 mins)

Chairs: Ian Swett, Michael Tüxen, Yoshifumi Nishida

WG Status update

Gorry Fairhurst (University of Aberdeen, UK)
We should have accurate milestone dates.

Mirja Kühlewind (Ericsson)
It makes no difference here. That is now how this group works.

Ian Swett (Google)
Agree with Mirja Kühlewind.

Michael Tüxen (Münster University of Applied Sciences)
People not familiar with the peculiarities of this group may expect the
published milestones to mean something.

Matt Mathis (Google)
Would be more useful to show the date the document was last edited.

Alan Jowett (Microsoft)
Rather than specific dates, we could publish the order in which we
expect to complete the documents.

Gorry Fairhurst (University of Aberdeen, UK)
People would like to know when to expect things to be finished.

Mirja Kühlewind (Ericsson)
Why put them in order? Let them be finished when they're done.

Working Group Drafts

RFC 6937bis updates

https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-prr-rfc6937bis-08

Speaker: Neal Cardwell (remote)
Time: 30 mins 45/120

Ian Swett (Google)
Agrees with clarification on “Finishing PRR” slide.
Is this documented elsewhere.

Gorry Fairhurst (University of Aberdeen, UK)
The Initial Window document covers something similar.

Alessandro Ghedini (Cloudflare)
Cloudflare has implemented a version of this.

Yoshifumi Nishida is the shepherd for this document
Yoshifumi Nishida says this is now ready to submit.

Lars Eggert (Mozilla)
QUIC is doing something similar.
Do we need a separate document for QUIC?

Ian Swett (Google)
I will defer to an AD’s judgement.

Martin Duke (Google)
This document is in TCPM for historical reasons, but arguably it really
belongs in CCWG.

Lars Eggert (Mozilla)
We should do a joint last-call in both working groups.

Matt Mathis (Google)
As an author, we’re tired of this. It is time we published it.

Gorry Fairhurst (University of Aberdeen, UK)
QUIC already covers most of what is described here.

Ian Swett (Google)
It should be no more than a page of text to cover how this applies to
QUIC.

Martin Duke (Google)
Who is going to write that page of text?

Michael Tüxen (Münster University of Applied Sciences)
We should get a timely decision on whether we need extra text and who
will write it.

Matt Mathis (Google)
This document has already completed WGLC in TCPM.

Michael Tüxen (Münster University of Applied Sciences)
If we add QUIC text we will need to do another TCPM WGLC.

Yoshifumi Nishida (Tiktok)
Does PRR apply to BBR?

Alessandro Ghedini (Cloudflare)
PRR is useful for Reno and CUBIC.
PRR does not apply to BBR.

Neal Cardwell (Google)
This document should not mention BBR at all. Will clarify it in a new
version.

Accurate ECN Update

https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-accurate-ecn-30
Speaker: TBD
Time: 15 mins 60/120

Michael Tüxen (Münster University of Applied Sciences) presented summary
of changes in draft-30

Stuart Cheshire (Apple)
This document is much needed and should move forward to publication.
For further comments see email earlier today to tcpm@ietf.org.

Status of ACK Rate Request

https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-ack-rate-request-05

Speaker: Carles Gomez (local)
Time: 15 mins 75/120

Neal Cardwell (Google)
Is the proposal that after timeout the sender then requests the receiver
to ack every other packet?
If cwnd drops to 1, asking for an ack for every 2 packets is going to
guarantee a slow ack for the first packet.
If cwnd drops to 1, then it would be better to set an R value of 1 to
request an immediate ack.

Yoshifumi Nishida (Tiktok)
I think text should say the R value should be the minimum of 2 and we
should update Loss Window to 2 in outside of the draft.

Gorry Fairhurst (University of Aberdeen, UK)
Using R value of 1 after a timeout will then give you a good fresh RTT
measurement.

Individual Drafts

• Handling of Ghost ACKs
  https://datatracker.ietf.org/doc/html/draft-pan-tcpm-tcp-ghost-acks-00

  Speaker: Yepeng (Eric) Pan (remote)
  Time: 20 mins 95/120

At the beginning of a TCP connection, the sender should not accept
packets where the ACK number is less than the initial sequence number
plus 1. After 2^31 bytes have been sent, this check is removed to allow
the sequence number to wrap around safely.

Michael Tüxen (Münster University of Applied Sciences)
Should we document this?

Lars Eggert (Mozilla)
This idea looks good.
We should not leave this to implementers to sort out for themselves.
This cannot be handled as an erratum to the existing RFCs.
This is not a typographical mistake in the existing RFCs; it is a new
idea not included in those RFCs.

Michael Tüxen (Münster University of Applied Sciences)
There is no reason any implementation would guard against Ghost ACKs but
not use the protections from RFC 5961.

Lars Eggert (Mozilla)
The datatracker does not record any IPR claims on RFC 5961.

Michael Tüxen (Münster University of Applied Sciences)
There is https://datatracker.ietf.org/ipr/421/
I would be willing to help write a short RFC documenting this.

Ian Swett (Google)
We will do a call for adoption on the mailing list.

Yoshifumi Nishida (Tiktok)
The option 2 proposal may have wrapping issue