Minutes interim-2020-tcpm-01: Wed 16:00
minutes-interim-2020-tcpm-01-202004291600-00

-------------------------------------------------

TCPM interim meeting
Wednesday, April 29, 2020, 14:00 - 16:30 UTC

WG Status Updates
Working Group Items

-------------------------------------------------

Notetaker: Richard Scheffenegger, NetApp

* Requirements for Time-Based Loss Detection                             (14:15)
  https://tools.ietf.org/html/draft-ietf-tcpm-rto-consider-10
  Speaker: Mark Allman

Mark Allman: Minor problem when going from retransmission to loss detection
language. Spin one more revision with that fixed. Michael Tüxen: WGLC will then
be concluded for this draft.

* RFC 793bis                                                             (14:25)
  https://tools.ietf.org/html/draft-ietf-tcpm-rfc793bis-16
  Speaker: Michael Scharf (document shephard) [ Wesley Eddy ]

Mirja: We discussed change the reg policy for the header bit last meeting. Not
that urgent any more. Should that be integrated into this doc? Michael Scharf:
It makes sense to clean up the registry, some reserved bits don't even have an
entry. Also move everything to one page. Alloc policy will not be in 793bis.
This will only be about editorial changes to the IANA registry. For change in
the policy, a separate document should be written. Mirja: The groups should
decide, we have a -bis document, and we could change anything. Michael Scharf:
This would be a change in the agreed scope of the document, I would prefer not
to go down this road with this document. Consensus on list is to clean up the
registry, but the allocation policy should be kept out of -bis for the moment.

* RFC 2140bis                                                            (14:30)
  https://tools.ietf.org/html/draft-ietf-tcpm-2140bis-02
  Speaker: Michael Welzl

Michael Tüxen (Chair): You are done with the document?
Michael Welzl: Yes
Chair: Ready for WGLC?
Michael Welzl: Yes
Michael Scharf: One more review should be done and we already have a volunteer.
I will ping the person again who had agreed to review this.

* Accurate ECN TCP Feedback: Changes & Status                            (14:35)
  https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-11
  Speaker: Bob Briscoe

Mangling Detection: Mirja - server doesn't know if there's been mangling if 3rd
ACK of 3WHS is lost ... unless the session uses the AccECN option.

Mirja: ACE Wrap behaviour - counter may stay the same in received ACKs. Need to
be conservative about having had one CE, but not how many. Bob: New text talks
more about the one counter wrap - not the first one. Mirja: Regarding the
Update section: I don't think we update the old 3168, right? Bob: We replace
those sections, 3168 is no longer relevant in those case.

Michael Scharf (as individual): Slide 10 - more than what is on the slide was
suggested as to how to address this problem. For instance, we could also use
different length values for the different encodings. Two option codepoints are
probably the easiest solution. Bob: Mirja originally don't like that option
(different length options). The document already uses the length field to allow
longer/shorter options. It was suggested to also use the length field to
determine the order of the fields.

Martin Duke (as individual): Why do we need to hold for ECT(1) decision?
Michael Tüxen: Want to be on the safe side. We hope things get cleaned up soon
- we need to reconsider if this doesn't happen soon. Martin Duke: Push to quick
resolution in TSVWG. Bob Briscoe: I would like this draft not to be stuck if
this doesn't get resolved. Mirja: I think there is no dependency from accecn ->
l4s but only the other way around. We only need a flexible way to signal the
ordering of counters in the option. Michael Tüxen: We don't want to hold this
for too long. Gorry (TSVWG Chair): As soon as this is stable, check the RFC3168
updates using the TSVWG list... I don't think the dependency is large enough to
hold this document.

* Accurate ECN Linux Implementation: Experiences and Challenges          (14:50)
  https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-11
  Speaker: Ilpo Järvinen

Bob Briscoe: On ACKs: It's still a SHOULD. If you would be doing the SHOULD
properly (option on most ack) this problem (slide 8) would not exist. This
issue only exists if you try to be (overly) sparse with the AccECN Options.

Yoshi: Do we really need 24 bit counters? If we used only 22 bits, we would
have enough space and there would be no need for a new byte. Bob: ACE is only 3
bits, and AccECN is designed to be working with just that. The options are
there to provide fine granularity as an optional - decreasing the fidelity
seems counterintuitive.

Mirja: Q about the option: I don't fully understand the problem - as ACE the
field should also be increasing. I don't think we need a separate field to
distinguish which counter has increased. Ilpo: Cross checking on field is
possible, but it may create loop of checks. Mirja: ECT0 and ECT1 distinction
was not the core requirement - only CE information has to be accurate. If you
can get the ordering information as a side effect, thats nice, but it was not a
requirement

* TCP RACK                                                               (15:15)
  https://tools.ietf.org/html/draft-ietf-tcpm-rack-08
  Speaker: Yuchung Cheng

Michael Tüxen: Looking forward for the updated document, thanks to all the hard
work of the authors and reviewers. It improves the document!

Non Working Group Items
-------------------------------------------------

* YANG Model for Transmission Control Protocol (TCP) Configuration       (15:30)
  https://tools.ietf.org/html/draft-scharf-tcpm-yang-tcp-04
  Speaker: Mahesh Jethanandani

Michael Tüxen: Mixed feedback (positive, and also not to adopt). Any opinions
from people in attendance? Michael Tüxen: Chairs have not decided yet Martin
Duke: Can someone articulate which TCP implementations may be using NETCONF to
configure themselves. Michael Scharf (as author): Two use cases - one in the
NETCONF WG, there is commercial interest in configuring TCP keep-alives (but
that is currently outside of this specific YANG model). The second use case is
BGP. Given these two use cases, sooner or later other uses may surface. More
likely this will be used by devices / routers which already use NETCONF. It is
unlikely that host operating systems will use a YANG model any time soon.
Mirja: Needs works and commitment from people for this make it work. Needs to
be correct. I think the plate is already quite full, we should complete other
work first. Michael Scharf (as author): There were questions on the list
whether this work is doable. The options are either to focus narrowly (as
presented, needed in other WGs) or to extend the model for TCP configuration in
stacks. Contributors in the room asked for the latter in earlier meetings, but
that results in a number of extensions (e.g. ECN, TS, SACK turning on/off). The
narrow focus seems to be the lower hanging fruit, a sophisticated configuration
model could be followed up later. Martin (as individual): I would encourage WG
to focus on known use cases. TCP config space is massive. I don't want to spend
much time on something which has limited value.

* HyStart++: Modified Slow Start for TCP                                 (15:45)
  https://tools.ietf.org/html/draft-balasubramanian-tcpm-hystartplusplus-03
  Speaker: Praveen Balasubramanian

Mirja: The performance improvement was by avoiding RTOs
Praveen: Spent less time recovering losses - avoid all kinds of problems by not
overshooting the queue. Overshooting is a more severe problem. In none of the
test the flow completion time was worse. Martin: State of the document:
Experimental or Informational? Praveen: Open to changing the type of document.
We would like others to use this, too. Richard: Would like to have this adopted
as WG item eventually to address buffer overshoot. Yoshi: Informational can
document the Microsoft implementation, EXP or PS would imply WG consensus on
the content. Duke: If other people are interest in implementing this we would
like to change the status. (+1 in the WebEx chat from Mirja and Rod) Michael
Tüxen: Positive feedback from the floor. The chairs will discuss and will
provide feedback to the mailing list.

Side chat discussion on increasing ABC to PS:
Praveen: Shocked that ABC is not in PS state.
Mirja: We could move ABC to PS
Michael Welzl: +1
Michael Tüxen (as individual): Anyone willing to spend cycles on that work?
Mirja: We should probably read the document before we simply change the status.
If that the right thing to do, it should be possible to change only the status
without doing a -bis document Martin: ABC has no errata so there isn't really
any need for a bis. Michael Welzl: There was a bit of recent list discussion
not too long ago, regarding some part of it not being implemented in Linux.
This was related to burst limitation. Mark (as the author of ABC) was also
involved, and he said that some part of it (the L limiting burstyness) may not
be a good way to do it in modern networks. So this probably does need an
update, incorporating Linux implementation experience.

* Advancing ACK Handling for Wireless Transports                         (15:55)
  https://tools.ietf.org/html/draft-li-tcpm-advancing-ack-for-wireless-00
  Speaker: Rahul Jadhav

Bob: Don't trade off speed for latency. Need to do ACK thinning properly at L4,
so it's not done without knowledge of context in the network. Richard: Missing
AckCC as list of previous work. You seem to be looking only at Web-like traffic
with uni-directional transfers. I would be interested in situations in which
sender and receiver roles change frequently. Praveen: Packet batching, LRO -
there is already ACK stretching in practise because of these functionality. I
would be very surprised if you see an ACK really every other wire packet.
Rahul: It is a possibility to reduce the ACK rate even further. The transport
layer is not in control of this reduction (Wifi batching) - this lack of
control has a detrimental effect on overall performance. Gorry: I like this
work, QUIC seems to be better than TCP. Maybe bringing a lot of different
people together on this one, as there is a lot of use.

* Sender Control of Delayed Acknowledgments in TCP: Problem Statement,   (16:15)
  Requirements and Analysis of Potential Solutions
  https://tools.ietf.org/html/draft-gomez-tcpm-delack-suppr-reqs-01
  Speaker: Carles Gomez

Michael Tüxen: Target status?
Carles: INFO
Gorry: RFC 7053 SCTP version of AckPull?
Carles: Not yet looked at that one in particular.
Gorry: When it was put up I was against it. I don't think these are real
issues. I think this is dangerous to pursue. We should discuss this on the list
before asking for WG adoption. Bob: It was me to suggest to move it into a
requirements doc first. I hope people like the approach of pulling together all
ideas. Agree that discussion is needed before adoption is asked. (+1 from Rod)
Yuchung: A lot could be done from the ACKs. Two drafts, they are opposite of
each other. Richard: We have had the experience that delayed ACKs are a major
latency issue. We need to have a discussion about what to do about this.
Michael Tuexen: Would be great if you can bring that to the list. Richard: Can
do, let's continue the discussion on the WG list on this particular topic.
Martin: I think we should adopt this draft only if we decide this is a problem
we want to solve. In particular, I'd like to understand Gorry's objections,
which I understand to be global.