* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Tcpm Status Pages

TCP Maintenance and Minor Extensions (Active WG)
Tsv Area: Mirja Kühlewind, Spencer Dawkins | 2004-Feb-05 —  

IETF-102 tcpm minutes

Session 2018-07-17 0930-1200: Centre Ville - Audio stream - tcpm chatroom


minutes-102-tcpm-01 minutes

          TCPM meeting, IETF-102, Montreal
          Tuesday, July 17, 9:30 - 12:00
          WG Chairs:  Michael Tüxen, Yoshifumi Nishida, Michael Scharf (not
          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.
               I spoke to Mark and he seemed willing to make a new revision.
               I am happy to help push this draft forward.
               Would you be an editor?
               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
               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).
               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).
               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?
               Yes, we wanted to keep this loose to allow implementation
            Ian Swett:
               I got some new data suggesting MinRTT/8 may be a good starting point
               (see talk in MAPRG at IETF-102).
               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.
               Is this ready for WGLC?
               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.
               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.
               I can't do real experiments, so we need to use a testbed, that
               constrains the testing.
               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?
               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?
               For fast networks, GRO is critical for fast networks. For 10 Mbps
               paths, probably not.
            Manesi ... :
               Are there tunnel concerns?
               Not specifically, TSVWG has work to address this.
               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?
               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.
               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.
               Yes, you have to read the draft to read the header.
               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
               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
               You said there were cases of an attack with 50% chance, is it worth
               for protecting after the event?
               Hmm.. guess no.
               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.
               Do you need this on all packets? I guess you only need to set TS
               when you retransmit packets
               It might work. Combining the TS and Sequence number provides more
               It doesn't have to be TS, but this already is really useful to the
            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
            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.
               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.
               Sounds like an implementation problem to me.
               In IETF, implementation problem is a problem
               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
               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.
               I would like to understand workloads and the value of TSO.
               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.
               How much applies to Internet workloads.
               It limits 100 connections on a single.
               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
               Document has been presented in LWIG and TCPM. The next version is
               expected to be submitted in Sept 2018 and ask for WGLC.
               Please provide feedback.
          The meeting closed at 12:00 noon.

Generated from PyHt script /wg/tcpm/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -