Minutes IETF102: tcpm
minutes-102-tcpm-01

TCPM meeting, IETF-102, Montreal
Tuesday, July 17, 9:30 - 12:00
WG Chairs:  Michael Tüxen, Yoshifumi Nishida, Michael Scharf (not attending)
Notes: Gorry Fairhurst

============================================================================================================

1. WG Status updates

  draft-ietf-tcpm-alternativebackoff passed to IESG.
  Other drafts progressing in the WG.

  Jana I:
     What is the status of RTO reconsider work item?

  Chairs (Yoshifumi Nishida):
     This draft expired as we explained in the previous meeting. We were
     looking for an editor who is intersted in this.

  Jana:
     I spoke to Mark and he seemed willing to make a new revision.
     I am happy to help push this draft forward.

  Yoshi:
     Would you be an editor?

  Jana:
     If necessary, but just check with Mark at first.

  Michael T:
     The final contents of the document needs to reflect WG consensus.

  Mirja K:
     There was some agreement off list between the authors and others, which
     can be a starting point.

============================================================================================================

2. Working Group Items

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

2.1 RFC793.bis  -  (presented by chairs on behalf of the authors)

  - Please review this draft on the list.

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

2.2 RACK Updates - Yuchung Cheng

  Yuchung:
     Reordering detection section added.

  Bob Briscoe:
     I wonder if the initial reordering window could be a Max of 3 DupACKs and
     a RTT, to allow this to be used in the future?

  Yuchung C:
     What happens when timer constraints are no longer an issue? (e.g., as
     hardware improves).

  Bob:
     Could this use e.g. RTT/16 as a threshold?

  Christopher P:
     You could have a bigger reordering window than the RTT itself in some
     cases (links).

  Yuchung:
     If you used a smoothed average, then this should still work to a certain
     extent.

  Christoph P:
     Is that because the SRTT also then increases?

  Yuchung:
     Yes, we wanted to keep this loose to allow implementation flexibility.

  Ian Swett:
     I got some new data suggesting MinRTT/8 may be a good starting point (see
     talk in MAPRG at IETF-102).

  Yuchung:
     We did not previously see a difference when we looked at /4 or /8, but
     happy to learn more from others.

  Michael Tuexen (from floor):
     I suggest you could replace "4" by a named variable, so it could be
     changed if needed.

  Jana:
     Is this ready for WGLC?

  Chairs:
     This draft has a good shape. However, we would like to wait a little more
     for implementor comments, and provide feedback if they have any.

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

2.3 Accurate ECN updates - Bob Briscoe

  - Describes an appendix (B) to document the rationale for the use of the TCP
  header field bits.

  Jana:
     Given we have code in the Internet that is years old, what chance do we
     have that those bits will ever be returned?

  Mirja K:
     If you wish to use those bits you need a different safety measure to start
     using these. This is not what is planned here.

  - DCTCP experiences runs of CE-marks for a time, and then runs of ECT(). The
  marking pattern is different.

  Yuchung C:
     From my point of view implementation complexity needs to have a benefit. I
     do not know how critical it is to handle ACK loss. DCTP is widely
     implemented and GRO is usable within a DC and needed for high rates. If
     ACE can be experimented with, I would like to do understand this.

  Bob:
     I can't do real experiments, so we need to use a testbed, that constrains
     the testing.

  Yoshi:
     Are you suggesting two drafts?

  Yuchung C:
     I prefer two parallel drafts as a starting point, simple is good.
     Middlebox traversal is really hard.

  Gorry F:
     I am concerned about us introducing two approaches (both of which will
     inevitably be used in the wider Internet) - and then we are planning to
     use this to build protocol machines on top. I think the WG as a whole
     needs to understand the proposals and we should try to find one method.

  Neil C:
     Should we wait for a CC that actually uses this?

  Mirja K:
     I think the best use-case is ECN++, which is a motivation for allowing fro
     supporting ACcECN first. Without this we can  make little progress with a
     CC.

  Manesi ... :
     In the deployment issue: Do you see AccEcn as more robust or not?

  Bob:
     If there is loss, then AccECN will be more robust. You don't know of ACK
     loss, and this is hidden with DCTP approach. It does have a GRO issue.

  Manesi ... :
     Does GRO have performance impacts?

  Yuchung:
     For fast networks, GRO is critical for fast networks. For 10 Mbps paths,
     probably not.

  Manesi ... :
     Are there tunnel concerns?

  Bob:
     Not specifically, TSVWG has work to address this.

  Neil:
     There is software GRO that can presumably be aware of accurate ECN.

  Gorry F:
     The idea of understanding the GRO implications seems really useful, Neil
     do you have any feeling about hard it is to look at how hard this may be
     to do?

  Neil:
     My intuition is that software GRO could perhaps be done efficiently, but I
     am not an expert, we should get feedback from those who understand this
     from the Linux stack.

  Mirja:
     I would say you should provide a recommendation about passive measurement
     of ECN with a note that you have to see the SYN. This could change in
     future.

  Bob:
     Yes, you have to read the draft to read the header.

  Gorry:
     The issue with passive measuring isn't that this is bad - I think
     operators in the network may learn useful things by seeing the protocol
     machinery of ECN is actually working. An important issue is when a CE-mark
     is reported, this does not indicate a network problem, we need to be
     careful to say that passive measurement of reported ECN marking does not
     indicate any sort of performance issue - CE-marking is absolutely normal
     network behaviour.

  Michael Scharf (remote):
     I am not suggesting to change the wire protocol.

  Mirja K: << >>.

  Bob B:
     We will work to resolve the issues in a new rev.

============================================================================================================

3. Other Items

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

3.1 Disabling PAWS When Other Protections Are Available - Yoshifumi Nishida

  Bob:
     In the three cases (MTPTCP, TLS, etc) don't you know by negotiating these
     that you do not need to use a TS.

  Randall Stewart:
     You negotiate these simultaneously. So you do not know which you use.

  Bob:
     You said there were cases of an attack with 50% chance, is it worth for
     protecting after the event?

  Yoshi:
     Hmm.. guess no.

  Randall:
     There are other methods to protect from off-path attacks. I don't like
     this. I would rather see other things happening. I can look at the
     timestamps in ACKs to understand better how the feedback reflects capacity
     and that helps with my work on BBR. You need this on data and ACKs.

  Yoshi:
     Do you need this on all packets? I guess you only need to set TS when you
     retransmit packets

  Randall:
     It might work. Combining the TS and Sequence number provides more info.
     It doesn't have to be TS, but this already is really useful to the stack.

  Richard Scheffenegger:
     Yes, agree with Randall - I think something along those lines is in my
     expired draft... We discussed about this at the time.

  Michael T (from floor):
     The protection offered by TLS actually detects problems, but also causes a
     decryption failure. TLS is not being robust, and would as designed tear
     down the connection.

  Stuart Cheshire:
     To make TLS work with this, you would need to change TLS to report-back
     the problem to let TCP deal with this rather than TLS breaking the
     connection.

  Yuchung:
     Cross-layer optimization is always tricky. Also, if you just put TS in
     retransmitted packets, there are also implications that may need a
     repacketization when you have/have not TS. This can impact implementation.

  Yoshi:
     Sounds like an implementation problem to me.

  Yuchung:
     In IETF, implementation problem is a problem

  Neil:
     Timestamps are useful. There also TCP receivers that use TS for a RTT
     estimate to perform receive buffer auto-tuning. I do see potential value
     in negotiating disabling PAWS, or to negotiate a TS format (e.g., microsec
     timestamps) - an example is using PAWS when there are microsec TS requires
     the PAWS mechanisms to be changed. I support a proposal for alternate
     proposals for TS. Although, I also think the current TS overhead in the
     header is justified.

  Brain:
     I think TS could be terrible! They radiate a lot of information about the
     stack. But, what I wanted to say was that I have an old draft that tried
     to address a different problem, but this was not progressed. I think the
     TS negotiation idea by endpoints is useful.

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

3.2 Making TCP faster and cheaper for applications - Soheil Hassas (remote) /
Yuchung Cheng (local)

  - TCP Transmit ZeroCopy in Linux, and other features of the stack.

  Jana:
     I would like to understand workloads and the value of TSO.

  Soheil:
     Most things I spoke about are 100 Gbps NICs on emerging platforms.
     ZeroCopy saves cycles, for 100 Gbps NICs you need TSO to saturate the NIC.

  Jana:
     How much applies to Internet workloads.

  Soheil:
     It limits 100 connections on a single.

  Neil:
     Most of these seem likely to benefit Internet-facing applications. TSO
     helps (but to a lesser extent - because the flows are 10s-100s Mbps), but
     the TSO bursts are constructed as 1 ms worth of data, (e.g. 4 packets at
     100 Mbps) so this definitely adds value.

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

3.3 TCP Usage Guidance in the Internet of Things (IoT) - Carles Gomez

  Carles:
     Document has been presented in LWIG and TCPM. The next version is expected
     to be submitted in Sept 2018 and ask for WGLC.

  Chairs:
     Please provide feedback.

The meeting closed at 12:00 noon.