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

Tsvwg Status Pages

Transport Area Working Group (Active WG)
Tsv Area: Mirja K├╝hlewind, Magnus Westerlund | 1999-Oct-22 —  

IETF-105 tsvwg minutes

Session 2019-07-25 1000-1200: Laurier - Audio stream - tsvwg chatroom
Session 2019-07-26 1220-1350: Place du Canada - tsvwg chatroom


minutes-105-tsvwg-04 minutes

          THURSDAY, July 25, 2019, 1000-1200  Morning Session I, Laurier
          Chairs: Gorry Fairhurst; David Balck; Wes Eddy (remote).
          (Notetaker: Theresa Enghardt)
          1. Agenda
          2. Chairs Update:
                  RFC's completed/in Queue:
                  draft-ietf-tsvwg-le-phb  (RFC) Document Shepherd: David
                  draft-ietf-tsvwg-fecframe-ext (RFC-Ed) Document Shepherd: Wes
                  draft-ietf-tsvwg-rlc-fec-scheme (RFC-Ed) Document Shepherd: Wes
                  draft-ietf-tsvwg-tinymt32 (RFC-Ed) Document Shepherd: Wes
                  Drafts beyond WGLC:
                  draft-ietf-tsvwg-ecn-encap-guidelines (WGLC) Document Shepherd:
                   draft-ietf-tsvwg-rfc6040update-shim (WGLC) Document Shepherd:
          (new text on fragmentation, review needed)
          Gorry: The text on tunnel remarking has changed in the latest version.
          Bob Briscoe: This text was written after WGLC responding to a WGLC
          Gorry: It is unusual to have so much new text, we need to make sure we
          have review of this text by the WG.
          Markku Kojo: This is not the RFC3168 mechanism, I've sent comments to
          the list (about how to deal with fragment marking).
          Bob Briscoe: I plan to revise the text after the meeting.
          Chairs: Please make a new ID and we'll evaluate whether this is ready
          or needs another WGLC.
          (Slide 10: Related Drafts (2))
          The overload protection ID is probably headed for independent submission
          to the ISE: Low latency DOCSIS
          Bob: We haven't spoken about this, but probably yes. This documents what
          is done in DOCSIS, rather than defining a new iETF mechanism.
          Gorry: Future work on this topic would likely fall within the WG
          remit. WG, please review this ID for technical clarity.
                  Chairs: Milestone updates
                  Chairs: Announcements and Heads-Up
          2.1 Heads-Up Socks Proxy 6
          Chairs: Has anyone read a recent version? (1 for previous version)
          Gorry: Please read and comment on list. Please consider this as a
          potential TSVWG work item.
          3. Transport Protocols and Mechanisms
          Transport Encryption
          3.1        Colin Perkins: Impact of Transport Header Encryption (WGLC)
          Tom Herbert: Is the latest version of draft is more positive to extension
          headers? I still think it's a little negative. We need to get better
          measurements of HBH options in the Internet, and find more recent data.
          Gorry: Please check current version.
          Tom: Deploying IPv6 HBH options is a known issue we're trying to
          resolve. There's lots of efforts to resolve it. At least suggest this
          approach could be used. Wording will be interesting. I'm not sure I've
          ever heard of intentional ossification.
          Colin: Protocol may make an explicit statement to declare features
          stable for all time, so you can assume they won't change. An example is
          QUIC invariants.
          Joel (Jaeggly?): When we bake something into an RFC we're kind of doing
          that. We are literally aiming for things to not change.
          Colin: There is a difference between this and a commitment to never
          change these bits.
          Joel: If you want to change the three-way handshake in TCP, good
          luck. Standardized doesn't mean it's not gonna change.
          Colin: Here, harm comes from a path preventing a change the specification
          in ways we want it to change.
          Tom: We now have two major transport protocols. One of the bits of QUIC
          was public, a middlebox vendor ossified it. Classical ossification we
          want to avoid. QUIC and TCP need equal consideration now.
          Colin: RTP is very widely deployed too, and did fix visible headers.
          Matt Matthis: In the past, there were drafts saying to enforce "must be
          0" in headers and middleboxes checked this. That's ugly. Occasionally
          this creates attack vectors.
          Alissa Cooper: What about  review from security area?
          Gorry: We discussed the SEC review last meeting. The security review was
          a long one, and really good. We went through comments and responded to
          each one, then updated the document. We added in text to address nearly
          all comments, and responded on mailing list why we didn't think some
          additional text would be helpful. I don't know if reviewer posted an
          update on whether they think it's fully addressed.
          Colin: I ad long discussion with Chris Wood - who was the reviewer. There
          was also an earlier review by Stephen Farrell.
          Alissa: Good to know. The document is not entirely unrelated to a previous
          doc, there is a chance that some language hits a series of people.
          Colin: We have presented it in OPSEC several times.
          Alissa: Some concerns could be dealt with while the document is still
          in the WG. That would make things easier. Get the feedback earlier.
          David: We plan to ask other areas during WGLC.
          Gorry: We welcome feedback. However, it is important that this ID
          documents, raises questions, but does not propose new solutions.
          Chairs: The next revision will go to WGLC, expected in August - if so,
          we will make this longer than the usual 2 weeks - because it will be in
          August. We will cross-announce to the OPS and SEC area.
          3.2         Igor Lubashev : Loss Signaling for Encrypted Protocols
          Aaron Falk: There is great interest to Quantum Internet Research Group
          that you use Q-Bits.
          Tom: What else is there, what other information? I'm worried if you give
          a mouse a cheese... Protocol-agnostic is better than protocol-specific
          mechanisms. How do we unify?
          Gorry: The current presentation is just one presentation in this
          space. There are other topics that are related, and they will all request
          bits to convey info.
          Martin Duke: If it's in QUIC header, of course it's authenticated. Not
          anyone can mess with those bits.
          Igor: We do mess with IP header bits, it's not going to be any
          different from what people can do right now. In the QUIC header it
          will be authenticated, there's advantages and disadvantages to any
          proposal. That's why we don't dive into details right now. We would like
          people to agree that this is a problem and we need to solve it.
          Martin: The threat model a serious problem when using measurement data
          that is authenticated?
          Igor: If a sender is playing fair and keeping a separate counter,
          I don't think it's an important threat model.
          Mauro Cociglio: I suggest to add a reference to RFC 8321 about ways to
          measure packet loss, use for case two different measurement points to
          understand packet loss
          Igor: We will definitely do more. This just uses one probe, one direction
          of traffic. Once you identify which direction a loss is, you could have
          another probe.
          ?: Can you compare with congestion exposure? There's some similarity.
          Chairs: Please continue to discuss this ID on the list.
          SCTP Drafts
          3.3        Michael Tuexen: bis update two SCTP Spec.
          Gorry: Have you looked at the ID with suggestions for a next generation
          SCTP (Individual draft)? Do you see anything taht needs to be in the
          bis document?
          Michael: We integrated almost all the errata in the base spec. Except
          for one document describing the I-Bit. The other suggested additional
          work is on changing concepts. I don't think anything applies here except
          the I-Bit.
          Gorry: If the WG thinks there are any other additions to this document,
          please come to the mic. This document is meant to be a stable
          specification for this protocol, and we don't want any last-minute
          proposals. When is next revision?
          Michael: Maybe tomorrow.
                  Michael Tuexen: NAT for SCTP
          3.4        Maksim Proshin: Retransmit bit for SCTP DATA, I-DATA and SACK
          David: What is your intention for this draft?
          Maksim: I asked for adoption and I will update.
          David: See you in Singapore!
          Michael T: Do we need negotiation? What if a receiver does not understand?
          Maksim: You can mistakenly think that your first original send... yes,
          needs negotiation.
          Gorry: This looks like good plan, but what is the complexity?
          Chairs: Please continue to discuss this ID on the list.
          Transport Working Group Drafts
          3.5        Gorry Fairhurst: Datagram PLPMTUD
          Gorry: The draft contains all the framework, and is stable. There are
          some topcis requiring research, and measurements - but these are not the
          purpose of the current draft. We think this ID is nearly ready to publish.
          Chairs: We expect a WGLC before next IETF. Removal of UDP the options
          text was an executive decision by the chairs in the hope to get this
          published before the UDP Options work is complete.
          Tom Herbert: Is there implementation?
          Gorry: There have been 4 implementations we know about. There is FreeBSD
          work in the git, this won't be upstreamed until spec is finished. There
          was another project in git. Another in the QUIC at hackathon into mozquic.
          Tom: Good to add a reference to it.
          Gorry: We will have this in shepherd writeup. Not sure if it is useful
          to add to the draft?
          Michael: We have implemetations on demo applications. We did an early
          implementation , but this has changed as the WG document finished. We
          hope to update the latest algorithm in our SCTP implementation.
          3.6        Joe Touch (Presented by Gorry): UDP Options
          David: A crucial text change is if the UDP checksum is not zero, you have
          to use the OCS. There may be a corner cases with tunnels, this needs to
          be worked out on the list.
          David: There has been proposal for a must-support flag in the option
          header, which indicates that no further options will be processed if
          this option cannot be parsed. Any objection?
          Tom: I expected discussion here?
          David: The chairs are looking for a sense of the room on the proposal.
          Matt: Does this allow rewriting packets? To drop headers without dropping
          David: No, this is receiver behavior for an option that is not
          supported. The most you can do is to toss the option and later options.
          Mike Herd: Yes.
          Magnus Westerlund: I think that is the right way.
          Tom: I think it is more than ceasing option processing. Based on IPv6
          HBH options. This bit in an IPv6 option type tells the receiver to skip
          an option not recognized or to drop the packet. Drop the packet if not
          recognized, because the rest of packet may be incorrect. This means you
          can't have options that modify the data. Two use cases for UDP options:
          A Trailer with a UDP payload, I agree. In node 2 (?) there's no legacy
          receiver. Payload in surplus we can do what we want with it.
          Gorry: Are you saying if anything is critical, a receiver should drop
          Tom: Drop the packet. That is the IPv6 way.
          David: We are retrofitting here to UDP, not disturbing the existing
          UDP payload.
          Tom: We already cannot deliver data that has not been properly
          processed. We cannot deliver fragments to applications. We need to
          be careful.
          David: When we use fragmentation, all of the fragment data is sitting
          in the UDP options area.
          Tom: There may be other cases where we cannot deliver that
          data. Encryption, compression?
          Gorry: Agree these could be done as options, but I do not yet see a
          new point.
          David: If there is UDP payload and a problem in options processing,
          then you can drop options, but can't drop the UDP payload.
          Tom: We may need this for extensibility. You want to make sure we can
          have version 2 and we can have this option in case.
          Mike Heard: The problem is that some options affect data handling,
          so data must share fate. What Tom said and we see it in the encryption
          case as well.
          Gorry: Let us make sure this level of agreement is actually on the list
          and that Joe is on the same page.
          David: Going forward we maybe could divide the option space for critical
          options. We'll figure this out on the list.
          Gorry: Do we need the LITE option independent of the FRAG option? If we
          remove that, it'll be simpler. Magnus suggested on list that UDP-Lite
          equivalence is not needed and I agree this raises more issues than it
          solves and is unlikely to be ever used.
          David: If you're doing DNS fragmentation because DNSSEC, you got
          individual checksum, do you also need reassembly checksum. Shove it in
          the application? If application is doing its own, does not remove need
          for OCS, make sure packet goes through the path.
          Tom: Agree
          David: Focus on: Does this do something useful for DNS?
          Mike Heard: No LITE option trailer, it does bad things to legacy
          David: One more voice for not keeping lite.
          Tom: Log all stateful or stateless options. I prefer the IPv6 method. If I
          have both of these, I can use the same implementation as for HBH options.
          Mike: We already ACS option for reassembly checksum.
          Gorry: We should not be using a CRC-16 for this length of data, SCTP
          and other specs use a CRC32c.
          David: iSCSI also uses a CRC32c, it's easy to implement with modern CPUs.
          Mike: CRC-16 was agreed on the list some time ago, but I agree that this
          decision should be revisited.
          Chairs: We expect Joe to collect the inputs and produces a new revison
          of the ID. It will then become clearer what issues remain.
          4. New Work
          4.1        Aseem Choudhary: RTG area (Diffserv and Yang)
          David: Nit: You cannot use ranges with DSCPs, only a list of codepoints.
          Gorry: Any other comments? Can anyone help? Please ask on list as
          well. Are you looking for adoption in routing area?
          Aseem: Yes.
          4.2        Jerome Henry: QCI and Diffserv API (no slides)
          Jerome: We are looking forward to feedback from the 3GPP liaison. This is
          meant to be informative text, the first step is to express the intentions
          of this text. We do not wish to impose anything. e.g., we provide the
          intention of mappings if people build a multipath system. Translate
          these one to the other.
          Martin Dolly (AT&T, 3GPP): The table referenced on QCI is an
          informative table. Each carrier uses DSCPs differently, QCI can be as
          well between different carriers. Moving forward to 5G, the table is
          ever changing. Moving target and informative. Any kind of MUST language
          referring to an informative table is probably ill-advised. In addition,
          this is most useful for private network deployments, but not for carriers
          who already know how to provision their networks.
          David: Let's get the new text. This is potentially useful for private
          networks as starting point.
          Chairs: We expect a new revision of the ID for people to discuss.
          4.3        Greg White: Identifying and Handling Non-Queue Building Flows
          David: Please don't put a specific non-IANA-assigned DSCP into running
          Gorry: ... yet.
          Martin Dolly: Thank you for your help with this.
          Subir Das: Thanks for this draft. Softening that language helps. For
          the WiFi sections you have SHOULD, but for LTE you have MUST. Why?
          Greg: The reason is just editorial, depending on which of the co-authors
          wrote that. I don't think there will be a concern.
          Gorry: Obviously the WG would have to decide on the recommendations.
          Chris Lemmons: You have SHOULD for protection against mis-marked
          flows. Application that does not implement that are in a sorry state. If
          application can classify, why do we need DSCP?
          Greg: The reason this is a SHOULD, is that some queue disciplines do
          not need to implement this, like per-flow queue systems.
          Gorry: I suggest this needs more text.
          Subir: Security considerations is a good thing. Maybe this needs more
          elaboration on who is responsible for marking this.
          Chairs: Who has read? (12-15)
          Chairs: Can we have a hum if this topic is worth pursuing in the WG?
          YES: Strong hum
          NO: Silence
          Who supports adoption?
          YES:Strong Hum
          In doubt: Silence
          Magnus: There seems a very clear consensus that we can adopt this.
          Chairs: We agree. The Chairs will confirm this on the list.
          FRIDAY, July 26, 2019,  1220-1350  Afternoon Session I - Place du Canada
          (Notetaker: Michael Scharf)
          5. Transport and Network - Chairs
                  Wes/Gorry: Review of WG discussions preparing for WGLC of
                  L4S drafts
          Chairs: The first item on the agenda will be a summary of the
          IPR discussion that has taken place on the list from the chairs'
          perspective. Disclaimer: Full version: The chairs are not lawyers.
          This is not legal advice.  If you want legal advice, you need to talk
          to a lawyer.
          (No comments allowing the summarised IPR)
          5.1         Bob Briscoe: L4S ECN drafts
          Slide "Implementation status"
          Andrew McGregor: Are you aware of anybody who is working on putting L4S
          support into the Linux WiFi stack?
          Bob: I am not aware of anybody doing that. Do you volunteer?
          Andrew: Unfortunately I may have no time for that.
          Slide "Open issue #1: RFC3168 ECN in a FIFO"
          Jake Holland: Akamai has observed ECE codepoints in the wild in the
          Internet. Some production traffic has ECN enabled. Some servers indeed
          see some ECE marks.
          Rod: Help from operators to get data would be very valuable.
          Gorry (chair): Would this need a change to the 3 specs?
          Bob: Not to the spec, but I can update the text.
          Gorry: Sounds reasonable.
          Chairs present slide deck with potential discussion topics seen on
          the list.
          Jake Holland: I would like to add one item to the list: Admission control
          for untrusted markings in a classifier.
          Gorry: This is classified as useful research in RFC7567. What do you
          suggest? Work in the WG?
          Jake: That is an interesting question. I don't have an opinion right now.
          Christian Huitema: Evaluation of the L4S experiment. All slides compare
          L4S to CUBIC, which is not designed for low latency. I would like to
          see a comparison to a delay based CC, in particular BBRv2.
          Bob: We are waiting for BBRv2.
          Jonathan Morton: I have 4 topics:
          f) The Congestion Response/Marking Differences experiments enabled
          for in RFC8311, (with the effective redefinition of the CE codepoint
          proposed required an RFC with consensus.  RFC8311 did not in itself give
          this approval.
          g) Incremental deployment requires compatibility, which has not been
          demonstrated so far.
          a) Effective congestion control is required. Codel is the most
          deployed AQM. With the current Codel, the time to reach the correct
          marked rate would be 4 seconds (?). 4 seconds for a link with 10ms is
          not effective.  The inadequate response of DCTCP (and thus presumably
          Prague) to Codel is of only slightly less concern in FQ form, due to
          the consecutive-bottleneck problem alluded to in
          point B (where the upstream bottleneck may be a dumb FIFO).
          b) Fair queueing is fairly robust. My concern is when there are two
          consecutive bottlenecks. In our experiments we have found issues.
          Chairs: The latter sounds like an issue in FQ-Codel.
          Peter Heist: I highlight 2 topics:
          e). A strong concern against using ECT(1) as classifier. DSCP relies on
          domain security at domain borders. With ECT(1) there would be no borders.
          h) Implementation status. There are issues in the repo. TCP Prague is
          over-reacting in experiments. There will be further interopaibility
          David Black (from floor): Regarding open issue #2. The whole point of
          the L4S experiment is an experiment for the Internet as a whole: this
          was much discussed before we adopted this work item. The interaction
          between queue can occur anywhere in the Internet.  But, resequencing is
          different. For instance, for wireless links there can be asymmetry. But,
          this does not happen inside data centers. The underlying cause for
          resequencing delays does not exist there. The problem mostly occurs in
          specific access networks. It has to be solved there.
          It is not appropriate to mandate that all Internet end nodes be modified
          in order to take advantage of L4S.
          Gorry: We need clarity on what the intention is. Is this specifying
          recovery in terms of time - which could then lead to relaxation of
          sequencing requirements *or* is this specifying a relaxation now? The
          latter would need cross-area review before moving forward.
          Bob: It is the former. We are saying that a link has the capability of
          not doing resequencing packets with the identifier.
          David: This is proposed as Internet-wide experiment. I still believe
          that this has a major scope problem.
          Bob: The relaxation is only for ECT(1). There is an opportunity to use
          a time-based loss detection. It seems like a good opportunity.
          David: I see the opportunity for a separate experiment.
          Gorry: As chair, I concur with David that describing other features apart
          from the core requirements for the ECN experiment really needs to be put
          in a separate experiment. If we do that, we will have to go to Int Area
          and RAI.
          Bob: The document only says what the endpoint must do. It does not day
          anything about the node.
          Gorry: Does the annex needs to be there?
          Bob: No, the annex is not needed.
          Gorry: With QUIC and RACK being deployed, tolerance to reordering may
          improve anyway.
          David (from floor): You are running two experiments. Is the annex is
          normative? What if we pulled the annex into a separate, informative
          document without any normative reference from the L4S spec.
          Bob: The normative specification in the main part could be a SHOULD.
          Chgair: As chair, I would recommend removing the paragraphs from this
          document that lead-on from the experiment and those that pass comment
          on DSCP deployability, we think the current text requires additional
          cross-area review.
          Jake: This list is a list of technical considerations and I agree. In
          addition, I have raised on the list editorial considerations. There are
          significant editorial issues that I think must be addressed before moving
          the document forward.
          Gorry: What do you mean? Is this about the section order?
          Jake: This is about word choice, and ensuring it only makes technical
          Gorry: This is excellent feedback. Please do send notes to the list.
          Jake: I sent a review of one section to the list. I am waiting for
          feedback. If I continue, it will be quite a bit of feedback.  wanted to
          raise the issue about the wording. Please reduce the hype.
          Bob: I understand this comment. I have started, but not finished the
          reply - I think I know what to do and will revise.
          Chairs: Time for some hums...
          How many have read -architecture ID?
          (15-20) (+1 on jabber)
          How many have read -id ID?
          (15) (+1 on jabber)
          How many have read -dual-queue ID?
          (15-20) (+1 on jabber)
          Wes: Does anyone want to bring up IPR?
          Rod: There are people who want to speak to IPR are not present.
          Jonathan: Toke Hoiland-Jorgensen wants to speak to this later, he could
          not join.
          Chairs: Please read the IPR summary and decide on your own position.
          Chairs: Are these documents ready for evaluation in a WGLC? Please hum.
          ("yes": Weak hum, "no": Weak hum) (Jabber: +1 "no" from Dave)
          Magnus (AD): Some people think the current text is not ready. The
          text needs revised. People should have some few weeks to send technical
          comments to the list on what needs to be addressed. If you have technical
          concerns why it is not ready, please tell us.
          Chairs: This is a good idea, we plan to revisit this next month when a
          revised ID is available.
          5.2         Bob Briscoe: Transport for L4S Data
          6.New Work (if time permits)
          6.1         Jonathan Morton: Some Congestion Experienced
                  Related drafts:
          Slide #7
          Mirja Kuehlewind: For the CUBIC-only flow, what AQM is used at the
          Jonathan: Cake, i.e. FQ_Codel, with standard parameters
          Gorry (as individual): What is the pink plot? Is this with fair queueing?
          Jonathan: The two flows get separate queues.
          Slide #8
          Gorry (as individual): Is this one FQ?
          Jonathan: This is single queue and there is convergence.
          Gorry (from floor): Were the changes you mentioned upstreamed?
          Gorry (from floor): Please do post links to the patches.
          6.2         Markus Ahmed: DCCP Extensions for Multipath Operation
          The authors provided a short presentation after the meeting (see
          slides). There was no time to discuss this ID at the meeting, but they
          suggested the topic could be prioritised for the next meeting. Please
          read the drafts and do discuss this topic on the list.
          6.3        Other items - please contact the Chairs

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