* 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: Zaheduzzaman Sarker, Martin Duke | 2004-Feb-05 —  

IETF-111 tcpm minutes


minutes-111-tcpm-01 minutes

          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++
          Speaker: Praveen Balasubramanian
          Should the document be EXP or Standards Track?
          Yoshifumi: There are parameters in the algorithm, will you fix the
          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
          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
          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
          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
          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
          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
          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
          Martin: The reference to ABC is informative in this draft. You could
          refer normatively to RFC5681 if you need a normative reference to byte
          Lars: ABC is referenced informatively by many specs; I don't see a need
          for a normative reference here.
          End of meeting.

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