* 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: Martin Duke, Magnus Westerlund | 1999-Oct-22 —  

IETF-109 tsvwg minutes

Session 2020-11-16 1600-1800: Room 8 - tsvwg chatroom
Session 2020-11-18 1430-1530: Room 8 - tsvwg chatroom


minutes-109-tsvwg-01 minutes

          TSVWG Meeting (Monday - Session I)
          IETF 109 (Online)
          November 16, 2020
          Jabber Scribe: Pete Resnick
          Note taker: Andrew McGregor
          1. Chairs Update
             RFCs completed/in Queue:
                  §RFC 8899 DPLPMTUD (PS) : Document Shepherd: Wes
                  draft-ietf-tsvwg-rtcweb-qos (RFC-Ed: AUTH48) Document Shepherd:
             Drafts beyond WGLC:
                  draft-ietf-tsvwg-transport-encrypt (AD Review) Document Shepherd:
                  draft-ietf-tsvwg-natsupp (with shepherd) Document Shepherd: Gorry
                  draft-ietf-tsvwg-ecn-encap-guidelines (Revised I-D Needed -WGLC
                          Document Shepherd: David
                  draft-ietf-tsvwg-rfc6040update-shim (Revised I-D Needed -WGLC
                          Document Shepherd: David
          2. Milestone updates
                  L4S drafts: Milestone date to be reviewed by chairs and draft
          3. Announcements and Heads-Up
             NOTE: Authors of the new drafts below can send ONE slide to be
             presented by chairs
                  Generic Transport Functions -
                  Proposing a general notion of fragmentation, may be applicable
                  to work in other WGs,
                  please read and comment on list.
                  Separation of Data Path - draft-asai-tsvwg-transport-review
                  SCE Update - various drafts
                  HPCC Update - draft-pan-tsvwg-hpccplus
                  PFC - draft-dai-tsvwg-pfc-free-congestion-control
          4. SCTP Drafts
          4.1 Michael Tuexen: bis update to SCTP Spec.
          Editorial changes coming, this will remove Appendix A.
          WGLC is expected December or January, reviews will go to the list after
          an updated draft is posted.
          5. Transport Working Group Drafts: Protocols
          5.1 Joe Touch (proxy/remote): UDP Options
          Work is still in progress, a new revision expected after meeting to
          reflect comments around IETF-108.
          Once this is posted, please review the ID on the list.
          5.2 Gorry Fairhurst: DPLPMTUD for UDP Options (10 mins) - Adoption
          request by authors
          WG Adoption requested. This needs more people to read draft, the Chairs
          will take discussion of adoption up on mailing list.
          -: How does this relate to QUIC?
          QUIC would not use UDP options to implement DPLPMTUD - it has its own
          specification in the QUIC Transport ID.
          5.3 Greg White: Identifying and Handling Non-Queue Building Flows
          - Turning NQB+Default into a PHB Group should be a last resort.
          - WiFi mapping needs to go to the list.
          - Items 3&4 on remaining work slide (slide #3) imply that at the edge
          - : Does one DSCP make sense for access networks and a different DSCP
          in the core (e.g., backbone networks)?
          6. Individual Drafts
          6.1 Markus Amend: DCCP Extensions for Multipath Operation
          WG adoption was requested. The WG chairs will consult with AD about
          appropriate next steps for these drafts, including overall approach to
          work in this area.
          Wednesday, November 18, 14:30-15:30 Session II
          7. Transport Working Group Drafts: ECN
          7.1 Agenda Recap & tooling discovery
          7.2 Greg White: L4S Operational Guidance
          Sebastian: I have a comment on slide 3: "reasonable fairness across
          range of conditions" is what's under discussion.  We have currently
          demonstrated a range of conditions where reasonable fairness is present,
          but this may not be sufficiently broad.
          David Black: Where are these tests?  In the hosts or a separate test?
          Greg: It depends.  Pre-launch tests for some of it, in-band testing also
          should be used and is mentioned in some of the L4S drafts.  A non-realtime
          response would be more operational management code.  A mix.
          Andrew McGregor: What kind of granularity would be used for the tests? Per
          host? Per destination prefix?
          Greg: One scenario, Residential ISP, you might have a queue on their
          network so test results could depend on IP address.
          - Gorry: any operators or vendors here have a quick comment on the single
          queue 3168 treatment?
          Andrew: Routers exist that can treat ECT1 as NonECT, but not particular
           - with Jonathan in chat mentioning it's technically in violation of 3168.
          Bob: It is not formally contrary to 3168; this is not changing the
          codepoint, it is just being a non-ECN router for that codepoint.
          Gorry: RFCs have specified different treatments based on ECN, e.g. PCN
          also specified a different use of ECT(1) (RFC 6660).
          Jake: I though RFC 8311, did that and placed some requirements on the
          behavior. Isn't that why it was standards track?
          Greg: It opened the door to experimental treatment documented in an
          experimental RFC.
          David: RFC 3168 permits drop instead of marking, so configuring that
          is compatible.
          Jonathan: This draft is requiring networks to be specially prepared for
          L4S traffic, right?
          Greg: This is overstating it. These RFC 3168 single queue implementations
          are known to exist. Deployment prevalence not known. The impact of them
          existing is not catastrophic. The point is to make networks in general
          prepared for L4s.
          Jonathan: Long-running flows sharing a queue can suffer ... also what
          about tunnels encountering an AQM?
          Greg: Yes, as mentioned on the slides there is an asterisk there as
          known point to make with this draft.
          Jonathan: Risk analysis needs to consider both prevalence and severity.
          Greg: I agree.
          Stuart: Apple enabled ECN several years back.  I wish we had the problem
          today of deployed legacy routers doing smart queueing instead of tail
          drop, but iphone data shows 0 deployment of RFC 3168 marked packets,
          to many decimal points.
          Jana: +1 to adopting this.
          Jake: See our presentation at interim MAPRG meeting. We saw several
          ASNs that had non-zero CE marking. This had different vantage points
          than iPhone data, but zero percent is not what we saw.
          Stuart: If you have newer data (ours if from a year or two
          ago). When we first collected we saw some plausible CE marking
          (Argentina? France?) which turned out to be bogus -- wasn't actual
          working smart queueing. If there's measurement of actual working ECN
          then that would be important to know the prevalence.
          Jake: We noted that. There were other networks. By country, it is hard
          to see patterns (?)... on a network basis we do see plausible marking.
          Bob: Was that single queue, or FQ? fq-codel sees some deployment in
          recent years. We need better tests to distinguish this.
          Wes: The chairs plan to start an adoption call for the next revision,
          please discuss this on the mailing list.
          The chairs asked how many had read this draft:
          15 read it, 19 has not of 88 participants (at the time of the poll)
          7.3 Bob Briscoe: L4S ECN drafts (30 mins)
          Jana: What is the intent here, are you asking for last call?  The biggest
          issue seems to be #16 (classic competition), correct?
          Bob: Yes, that and whether a CC is up to speed with the aspirations in
          this draft?
          Jana: At a high level, this seems ready for an experiment. We need
          to outline what we measure and what we expect to see as part of the
          Jana: If the concern about competition with classic ECN is an issue,
          it is only an issue of L4S is successful. I would like it to become an
          issue and for L4S to be successful, but needs to be deployed to make that.
          Colin, Richard, Mirja, Ingemar, Philip, Mark, Koen: +1 (in chat)
          David: The path to address the safety concerns runs thru the operational
          considerations draft.
          Gorry: When this is adopted, is the WG ready to start a WGLC? Do we need
          something specific?
          David: I am not sure.  We now need to judge as a WG whether there is a
          reasonable approach to dealing with RFC 3168 "old" equipment.
          Sebastian in chat: I do not think L4S is ready.
          Jonathan in chat: I also do not think L4S is ready.
          Jake: I do not see why an RFC is needed to perform an experiment and
          report observations, many lab things have been done already, and they
          demonstrate problems.
          Colin: I do not think we need to wait for the ops draft.
          Lars: I am struggling to understand what the experiment is.  The draft
          seems to describe a spec, but not an experiment that tells whether it
          succeeded or not?
          Mirja: The problems that were detected in a lab make assumptions about
          deployment.  By deploying it at scale we can find out whether these are
          really problems at scale or not.
          Lars: So, the experiment is to throw it on the network and see what
          Koen: The intent is to get this nailed down, so that CC development
          engagement can proceed.  We should not wait, we should start this,
          so that more people will work on it.
          Jana: I think Lars's question is about what is the experiment? History has
          shown just getting this ECN marking deployed is a pretty big experiment.
          But, yes, encouraging endpoints to experiment with congestion controllers.
          Jana: Do we think that by keeping it as a draft in the WG we gain
          Sebastian: The operational safety seems unproven.  Deploying it is
          un-cautious.  I think we should not be talking about last call.  We do
          not have data for a wide range of topologies: we are discussing in the
          abstract when many people have not examined the data.
          Greg: The specification of classic ECN is 20 years old, with near 0
          deployment. I think we need to move it forward.
          Lars: Asking for a fabric upgrade is a tall ask.  If it can't be used by
          apps it won't ever be used.  The IETF has done some changes, both in the
          network and in the endpoints. ECN requires both.  We need heavier thinking
          about the incentives and how this will manifest itself in applications.
          Koen: In the past we saw specs, but no network interest.  Now we have the
          opposite, network interest with good engagement and plans to deploy it.
          This means we can do the experiments now, let's move this forward.
          Bob: The network will not deploy it without an RFC out there.
          Gorry: How many would review and comment on a last call if we start one
          before next IETF meeting?
          18 hands raised, 2 not raised, 52 participants at time of poll.
          Jonathan Morton (chat): I think WGLC at least has to wait for l4s-ops
          to be completed.
          Mirja Kühlewind (chat): I disagree, let's get things moving.
          Sebastian Moeller (chat): DualQ does not equitably share between the two
          classes in a number of relevant cases and requires the protocol to work
          as expected.
          Koen Schepper (chat): +1 to starting a WGLC: Only the real experiment
          can bring more engagement and experience.
          Greg White (chat): +1 to starting WGLC and to starting the experiment.
          Ingemar Johansson: The opts draft is not required before a WGLC of the
          L4S, on the contrary, I would see that the ops draft will in part be a
          result of the experiments.
          Carsten Bormann (chat): The purpose of an experimental RFC is to agree
          what exactly the experiment is.
          Sebastian Moeller (chat): Making the endpoints responsible for safety
          and equitable sharing is an odd choice, since the same endpoints will
          profit from unequal sharing.
          Andrew McGregor (chat): The ops draft is required... but it shouldn't be
          last called until after the experiment is done, because it will become
          the ops document for the eventual standard.
          Jonathan Morton (chat): There is also a risk that deploying the experiment
          will "eat" the ECT(1) codepoint and prevent it from being used in a
          different way later.
          Gorry Fairhurst (chat):  I think Jonathan is correct, the intention
          is that TSVWG will assign ECT(1) for this, until the experiment is
          Mirja Kühlewind (chat): We discussed the question if RFC 3168 marking is
          being deployed. If the question is no, L4S deployment is much simpler. If
          those who have deployed RFC3168 are the first once to update to L4S that
          fine as well, if the answer is no
          Colin Perkins (chat): I don't see how that data can be found without
          trial deployments.
          (+1 from Jana Iyengar, Ingemar Johansson, David Schinazi, Mirja
          Kühlewindd, Ram Ranganathann)
          (for more details see Jabber log).
          The chairs asked who would review these Specs if the WG were to start
          a WGLC?
          18 would review (+1 via chat), 2 would not (out of 52)
          All Other Business
          8.1 Davide Brunello’s thesis work relevant to L4S (No time this meeting)

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