Minutes IETF111: tcpm
minutes-111-tcpm-01

TCPM meeting, IETF-111, online
==============================
Tuesday, July 27, 2021, 23:00 - 01:00
WG Chairs: Yoshifumi Nishida; Michael Scharf; Michael Tüxen
WG Note Taker: Gorry Fairhurst

WG Status updates
=================
* RFC2140.bis is in RFC Ed Queue.
* RFC793.bis in IETF LC.

Working Group Items
===================

Adding jitter resiliency to HyStart++
-------------------------------------
https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-hystartplusplus-02
Speaker: Praveen Balasubramanian

Should the document be EXP or Standards Track?
Yoshifumi: There are parameters in the algorithm, will you fix the values?
Praveen: We will examine tradeoffs and make recommendations.
Yoshifumi: Do you have a way to dynamically find good parameters?
Praveen: No, not really. This is more a research question.
Bob Briscoe: I wanted to clarify that the RTT threshold rationale needs to be
explained in the draft. Richard: I hear discussion of constants. I would
suggest EXP status, unless there are recommended values that are clear. Martin
Duke: EXP can be problematic. If we can find confidence we should make it PS.
Christian: We should go for PS. +2 from jabber. Michael Scharf: Aim for PS now.
The WG can make the final decision durin WGLC. Michael T.: Do you do any form
of pacing? Praveen: Not at the moment, it could be added to an implementation.

TCP YANG model - update
-----------------------
https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-yang-tcp-02
Speaker: Michael Scharf

Mahesh: We seem to have resolved the issues and have an implementation, what is
needed to complete WGLC? Michael S.: There are no open issues in the ID. There
is an open issue about implementation and the availability of open source code
for TCP-AO. Mahesh: Is the lack of an open source implementation an issue?
Michael T./Yoshifumi: This document does not need to be blocked on this.
Mahesh: This also depends on the netconf module, which is pending publication
in netconf. We could coordinate with the netconf documents (we don't expect
these to change) Michael T.: The chairs will discuss the WGLC timing. Martin
Duke (on chat): If we don't think additional facts will emerge, I say we just
ship it. It is not hard to understand this document without the NETCONF one.

More Accurate ECN Feedback in TCP
---------------------------------
https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-accurate-ecn-15
Speaker: Bob Briscoe

Praveen: I am not convinced that pure ACKs should be ECN capable.
Bob: This draft does not require you to send pure ACKs, but explains what you
need to do if you wish to monitor congestion on the ACK stream. Praveen: What
happens if a receiver doesn't send an ACK? Bob: Nothing special, ACKs can be
lost. Yuchung: What happens if you have super segments e.g. from GRO. Bob: If
you have 16 packets represented, then offload would normally send a burst of
ACKs corresponding to all the segments. (There are also counters, especially if
you send the option you can ignore wraps.) Yuchung: Linux does not send extra
ACKs, to make more CE ACKs. Yuchung: Are you going to publish the scenarios for
testing the minimal option (fewest number of ACKs)? Bob: We will publish a tech
report. Yuchung: Can we use the version without ACK options. We do use GRO with
large segments (>>16). Bob: I think the option is needed at high rates. The use
without the option is intended as a stop gap. Michael S.: There was originally
pushback from implementors against the option in order to keep things simple.
Question to the group: Has the view on using the option changed? Bob: The
recommendation is now stronger - because of more observed ACK Filtering.
Richard S.: For constrained environments it is possible to get sufficiently
accurate feedback without the option. Yuchung: As NICs get faster, GRO is
important. We need to check this. Praveen: I worry about middlebox behaviours
when using the options on Internet paths. Bob: The draft has a lot on how to
handle middleboxes. We'd like to test more at larger scale.

RFC 8312 bis: CUBIC for Fast and Long-Distance Networks
----------------------------------------------------------
https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-rfc8312bis-02
Speaker: Vidhi Goel

Praveen: Do you expect to see performance differences with respect to the
previous RFC? Vidhi: For linux no. It already implements this. There would be
benefits relative to the current RFC. Praveen: Could you mention the places
where there is improvement - in an email? Yuchung: Linux does not do ABC. An
ACK for 100 packets, then cwnd will grow by the size that is ACK'ed.
Stretch-ACKs are common. Should we change ABC? Vidhi: If you enable ABC, you
adjust by bytes acknowledged. This was originally based on 2 segments/ACK - the
main thing is counting the bytes, even if L does not equal 2. The ABC spec is
maybe not aligned to practice. Richard S.: ABC was mainly used to guard against
ACK-Splitting attacks. Martin: If the WG thinks the L=2 guidance is obsolete,
then we could mention this here. Yuchung: Maybe we should update the RFC with
respect to the stretch ACKs. Martin: Should we update the ABC spec? Vidhi:
There are also cases where we need to add pacing cases. This could be a good
place to describe this. Praveen: I think updating ABC would be a better way to
make this change, because many things refer to ABC. Martin: Maybe someone
should make a first move for an ABC.bis? Yoshifumi: This draft does not have to
wait for an ABC.bis to be published. Martin: The reference to ABC is
informative in this draft. You could refer normatively to RFC5681 if you need a
normative reference to byte counting. Lars: ABC is referenced informatively by
many specs; I don't see a need for a normative reference here.

End of meeting.