* 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, Spencer Dawkins | 1999-Oct-22 —  

IETF-103 tsvwg minutes

Session 2018-11-05 1350-1550: Chitlada 3 - Audio stream - tsvwg chatroom
Session 2018-11-07 1120-1220: Chitlada 2 - Audio stream - tsvwg chatroom


minutes-103-tsvwg-03 minutes

          TSVWG at IETF 103 Bangkok
          WG Chairs: Gorry Fairhurst (GF), David Black (DB), Wes Eddy (remote)
          Monday 1350-1550 Afternoon Session I
          Note Taker part
           1: Al Morton, John Kaippallimalil
          Note Taker part 2: Richard Scheffeneger
          Jabber: M Abrahamson (MA)
          1. Agenda
                  The presentation on new overlay work will taken in session I.
          2. Chairs Update:
                  DSCP IANA process changes published RFC8436 (Note title change)
                  Status (see slides).
          2.1 IANA Registries
                  IANA ECN errata on RFC 8311
                  Note on the ECN registry that ECT(1) is for experimental use.
          2.2 Chairs: Milestone updates
                  Milestones were discussed (see "yellow" status slides).
          2.3 Chairs: Announcements and Heads-Up
                  Note about QUIC transport meeting this IETF (See TCPM Agenda).
          2.4 Implementation
                  Hackathon inputs were reported in individual presentations.
          2.5 Chairs: Other Drafts Related to TSVWG
                  (See slides)
          3.  Transport and Network
          3.1 Colin Perkins (CSP): Impact of Transport Header Encryption
                  There are ppen issues in Conclusions, and section on
                  the metrics derived from Network Layer headers.
                  There authors seeking WGLC for the next meeting.
          DB:     Has anyone reviewed this from a Privacy perspective?
                  (He has someone in mind.)
          CSP:    Some, more are welcome.
          GF:     We chose not to include recommendations when we wrote this.
                  Does the WG want recommendations added?
          CSP:    I suggest no. This is better suited to a separate draft.
          Spencer D (AD) : I confirm it is better to do that as 2 pieces,
                  because the current material may be useful in IETF and outside.
          Spencer: We can move this draft out quickly, when ready.
          Michael A (MA): Should we have review from other relevant WGs?
          DB:     This is the right time to ask for wider input
          GF:     Yes, we agree.
          MA:     The text on TCP MSS clamping isn’t clear - this prevents too
          large a
                  PMTUD in real networks. Operators know the link limits and
                  can then
                  clamp,  e.g, PPPoE/clamp MSS to 1452 – even if the end sys
                  has 16K
          GF:     Sure, but this is also sometime set to a smaller value, because
                  this is expected to help with some paths, rather than because the
                  PMTU is known. We will look at the text.
          Spencer: Please do not wait for Last Call to ask for reviews ...
          Martin Duke: What do you intend to accomplish with this draft?
                  Experience with the QUIC Spin-bit says that anything related to
                  monitoring will be difficult.
          Alissa Cooper (via Jabber): This should have an early Security Area
          CSP:    OK, the next revision may be ready for this.
          Spencer: I would like to say why this is useful. I was an editor of
          the MARNEW
                  workshop RFC, that discussion was not well informed. This draft
                  would have helped. It would also have helped with the MM draft.
                  We also talked about PEPs in PILC and since then we have maybe not
                  had meaningful discussion own what PEPs were meaning to do.
          3.2 Vincent Roca (VR): RLC FE
          -:      Is it safe across several platforms, CPU, etc:?
          VR:     The proposal is to do beta tests on small and larger devices.
          VR:     We are still working on many good comments from IESG review.
                  Is a BSD-like License compatible with IETF RFC License?
          Mirja Kuehlewind (MK): I hold the DISCUSS for this. This in itself is
                  fine. The problem is with the Copyright statement.
                  There is a conflict with the copyright.
                  Can this be regarded as a literal citation?
                  It is often not a good practice to describe the spec in Code.
                  I see two options: remove code/external ref; remove code/have
                  pseudo-code. A better practice is to describe simply/pseudo code.
          DB:     The problem is that the code is from a 3rd party,
                  and the license is part of code.
          MK:     One issue is that the code authors are not the same as the
          ID authors.
          CSP:    The IETF does have a history of including code in RFCs
          MK:     In this ID, the code is the only spec!
                  (There are not normative statements of the requirements,
                  just code).
          Spencer: Some IESG people are involved in the specification of the
                  OPUS codec, and think that code may not be a good basis for specs.
          GF:     This is a little more tricky than normal. The PNRG is needed to
                  be specified to describe the packets on the wire. It’s not
                  like a video codec, where the code may perhaps explain how to
                  build a receiver, it actually defines what is in the headers.
          Spencer: There is a case where everybody modifies the code, then
                  any changes proposed need to be checked against everybody's code.
          DB:     Other code instances can be registered.
                  That is what we do with modifications.
          The next steps are to resolve the issues!
          Chairs: Please work with Wes as the document shepherd and with your
                  ADs who can obviously advise on what options look most
                  promising to pursue.
          3.3 Bob Briscoe (BB): L4S ECN drafts
          The motivation is extremely low queuing delay (micro second delay vs
          5-15 ms delay). The second queue is for legacy control.
          ECT(1) is the code point that signifies this.
          MA:     If we had FQCodel, how does this work when we use this in the
                  C queue (see figure). Are there any recommendations on the
          BB:     There are challenges in finding the average congestion
                  level across the queues.
          MA:     It appears FQ-Codel is shipping as a default in some
          BB:     I do not have implementation experience of FQ-CoDel, we used
          Pi and
                  have this now available in a tidy form.
          MK:     I think FQ-Codel could be an alternative for L4S to achieve the
          same goals.
          DB:     There are many ways to roll this out.
          - :     The requirement for L4S Senders: Could L4S get stuck on needing
          BB:     One could deploy queue protection, i.e., policers.
                  This is something we can gain some experience about.
          BB:     The proposal is about detecting loss in units of time (point 5).
          DB:     There are different engineering trade-offs across levels in
          the stack.
          BB:     I propose there is no requirement on network to re-sequence.
                  This makes endpoints be more liberal if there is reordering.
          GF:     What the service provides depends also on the scale of reordering.
                  The WG could suggest that they relax link re-ordering requirements
                  or interface reordering. However, one person’s link is a tunnel
                  to another and unless we are careful, this could result in
                  between bonded links, e.g., between data centres and that is
                  a very
                  different thing. I am urging caution here before we start
                  this wider, to be very clear about what is intended and the
                  on existing Internet traffic (i.e. apps and transports).
          DB:     Endpoint modification is not easy in practice.
          BB:     The way RACK works is not complicated.
          DB:     There are systems working that are a decade old and they are not
                  disappearing. We should not ignore these.
          GF:     This is not just about RACK in TCP.
          BB:     I would like input to the discussion from RMCAT WG, and TCPM.
          GF:     This is not the best way to approach this. The WG should first
          be clear about
                  what the proposed change is, then identify the opportunities
                  and pitfalls.
                  At that point we can seek wider inputs to know if this will
                  be acceptable
                  or not. The chairs suggest we write a short a document to be
                  sure this
                  is seen.
          BB:     I can help.
          DB:     Yes. Please do, send material to the chairs, and the chairs will
          consult and
                  circulate something to the WG first.
          Who has read rev 03 of the architecture?
                  (few people).
          aqm-dualq-coupled-08 draft:
          Dual queue, ECN marking, square relationship between the 2 queues,
          for typical or target queuing delay must be expressed in units of time:
          GF:     Has anyone read the dual-queue draft?
                  (no-one, the draft was recently updated).
          GF:     Who plans to read this?
                  (at least 8 people)
          Chair:  Please read, and please also offer to do a detailed review.
          3.4 Magnus Westerlund (MW): Update on ECN in QUIC
          ECN format in ACK. ACK_ECN replaced by ECN section in ACK frame
          GF:     Is  ECN targeting QUICv1?
          MW:     Yes.
          MK:     Are the counters specified in packets or bytes?
MW:   Currently
          these counters are in packets.
          MK:     I have concerns accuracy when reporting in packets and would
          prefer bytes.
          MW:     I have to think of reporting trade-offs. This is simple for
          BB:     I agree, byte counters in accurate ECN /consider protect from
          MK:     Some of these pathologies are not possible in QUIC.
          GF:     We could still think about doing asking QUIC to do something
          different in
                  later QUIC revisions.
          MK:     ACKs and marking are based on change.
          MW:     I am worried about accurate ECN feedback with flipping CE-marks.
          GF:     Please discuss and think about how QUIC should do this.
          4.  Greg White: Identifying and Handling Non-Queue Building Flows
          Queue-building (QB) flows:
          -       Capacity seeking flows, traditional congestion control
          Non-Queue (NQB) building flows:
          -       Rel low data rate, not capacity seeking
          -       Maybe latency sensitive,
          -       -…etc
          DB:     Incentive systems cannot be relied on – devices can and
                  are still misconfigured, (RFC 5706).
          Martin Duke: This is an interesting idea.
          Please send mailing list comments, and discuss there.
          6.  New Work on overlay networks (short talk)
          Motivation – leverage cloud router nodes and model
          Local recovery, CC, Traffic splitting and recombining
          Meeting session 1 closed.
          Wednesday 11:20-12:20 Morning Session II
          5.  Transport Protocols and Mechanisms
          5.1  Joe Touch: UDP Options
          draft-ietf-tsvwg-udp-options (David Black proxy for Joe Touch)
          Tom Jones (TJ): How do we add mandatory protocols in future?
          TJ:     I do not understand how they become mandatory in future.
          DB:     I think we need Joe in the future to update this.
          TJ:     We should have a clear direction, to understand what to do with
                  parts that are either under-specified or have not been
          Lars Eggert (LE):  I am not following this very much.
                  Is anyone using this for anything?
          GF      There is an implementation that nears completion of the core
          DB:     This is useful for a common way for DPLPMTUD with UDP.
          LE:     This appears heavy weight, and I do not see the benefit.
                  Only one informational draft refers to this and we are wasting
                  our time.
          GF:     This is for new protocols, or to deploy common UDP transport
          LE:     It is hard to argue this is useful for UDP/QUIC.
          LE:     If we standardise we shouldhave a protocol that uses this.
                  I think this is a waste of time.
          CSP:    I somewhat agree with Lars, this is not needed in the case of RTP.
                  Does DNS need this?
          GF:     We should have that discussion, of course, in WGLC, but for now
                  the WG has decided to adopt this specification and work on this,
                  but we should really avoid adding complexity at this stage.
          Tom Jones: draft-fairhurst-udp-options-cco
          We have an implementation for FreeBSD.
          DB:     I think running code wins this one. I think this one makes a point
                  to scrap the current option checksum and use this, because
                  it works
          GF:     Do we need to mandate this? Certainly we need to send on every
                  packet. I think path forward is to put a SHOULD on this,
                  and explain
                  what breaks if you don't do it.
          TJ:     I did not implement UDP-Lite, we can make this work with the CCO
                  need on the path we care about. I also did not implement
          GF:     Is the WG keen to implement these remaining items.
          LE:     Is the UDP upstreamed?
          LE:     Good. Which committer has committed to this?
          TJ:     That would be me, when the work is ready (and Joe asked until
          it is finished).
          LE:     Are there any other implementations?
          TJ:     No.
          CSP:    I am not sure from the RTP point, we didn’t see much interest
          in using
                  more of UDP-Lite semantics.
          GF:     Noted.
          CSP:    Going back to fragmentation and coming from writing media stuff,
                  everyone builds apps to fit in a frame, so fragmentation below
                  in UDP
                  is not useful. Unless it ties into STUN et al, it will nor be
                  of use
                  to us.
          DB:     Discussions around fragmentation should be centred around
          GF:     I believe the intent was to use with tunnels.
          MA:     Networks should support frag, but applications should not
          use this.
                  I do not know how to make it work better.
          TJ:     I spent time working to protect from attacks using fragments
          in IP,
                  I do not want to keep doing this.
          DB:     Fragmentation has two sets of considerations.
                  There is the fragility of receiver fragment reassembly.
                  On the other hand, there are tunnel use cases where you can not
                  prevent fragmentation to get proper behavior. When sending
                  UDP through
                  such a tunnel you need to fragment in the tunnel protocol or here.
          MA:     Fragmentation works less well than other options.
          DB:     If you hit tunnel cases where you need fragmentation, your only
                  alternative is to drop packets. We should avoid packet
          MA:     Networks must support fragmentation, but applications should
          try to
                  avoid this. I do not know how to make it work well.
          TJ:     There is no data to support that this helps. I do not want to
          keep this
                  as a UDP Option.
          GF:     It could be that Frag. is only a part of the tunnel protocol,
                  than a UDP Option. What do we do?
          DB:     We will issue a consensus call on the CCO checksum.
          LE:     I suggest you think if standards track is the right way?
          GF:     What is the experiment you see as needed?
          LE:     I do not see anybody really needing this, and do not see
          anyone else
                  implementing this.
          LE:     I think it makes  =UDP more fragile, and does not work in 100%
          of cases.
          GF:     That is not as bad as you say - with the CCO the chance of
                  is much higher.
          GF:     … and anyway you can negotiate to see if packets with this
          are delivered.
          MK:     I’m tending towards experiment, would be nice to have real
          MK:     Just because you use the UDP options, you don't use this on
          every packet.
          CSP:    I am not convinced there is yet much use for this, it may or
          may not be
                  finally deployed, but this is  true for many protocols.
          5.2 Michael Tuexen: SCTP Drafts  (Gorry Fairhurst proxy for Michael
          Plans for progressing this were presented, a new rev is to be submitted
          for WGLC.
          The SCTP errata document has been sent to RFC-Ed.
          The authors plan is now to produce a -00 .bis ID to replace RFC4960.
          This will then be updated in rev -01 with the errata changes.
          Spencer: I like the multi-step process being used here.
          Thanks for doing the right thing.
          5.3 Tom Jones: Datagram PLPMTUD
          Draft has been updated and the core of the draft is now consistent
          and should be complete - we are working on mechanisms to implement.
          GF:     Can you say what was done in QUIC and when a contribution
          is needed?
          TJ:     We probably do not need a lot in QUIC drafts, we will propose
          LE:     The likely deadline for that request is a week if you want to see
                  it in QUICv1.
          MA:     Has there been a talk in v6ops? There are not many people moving
                  packets here...
          GF:     There has been talks in 6man previously.
          MA:     Showing to the operational community would also be a good thing.
                  I will point the NANOG list to this.
          Jen:    Fixing PMTUD is like believing in Santa Claus.
          Jen:    There is a v6 operational community, in Europe there is RIPE,
                  come and talk.
          5.4 Ole Troan (OT): Discussion of PMTUD from the IETF 6MAN WG
          MA:     This list is not exhaustive. There may be a misconfiguration, etc.
          TJ:     No matter what is done in the network, transports have to do
                  PLPMTUD. It is important to be able to send larger probe packets
                  than the current PMTU.
          OT:     Would you be happy if routers silently drop packets?
          OT:     Sure, this is not going to solve the problem, this may help you.
          TJ:     Maybe transport can take this responsibility completely?
          OT:     Do you want the network do nothing and drop packets.
          TJ:     This is what happens now - ICMP is not helping much.
          Spencer: Thanks for being here. I would encourage you to think about this.
                  MTUs are not going to become smaller.
          -:      Should we seek top deprecate PMTUD?
          GF:     We are not discussing deprecation here, only how to signal this.
          Bob Hinden: The mechanisms we are proposing in the new things in 6man
                  is still sending packet too big messages - now from the
          Spencer: You may get this information in various ways. The best way to
                  convince people that something matters is to come up with a way
                  that works.
          Igor:   It is clear that transport has to do PMTUD. If the network can
                  provide a service that lets this be faster, that would be a
                  big benefit.
          MA:     MSS clamping seems to be working. It is used. Some
                  people don't like it. Operators rely on it for TCP.
          GF:     And we should also consider things that are not TCP.
          draft-henry-tsvwg-diffserv-to-qci (heads up of new draft)
          MW:     What is the relation to 3GPP and why are they are not doing
                  they this themselves?
          Jerome: They are working in their own domain.
          MW:     We should have a handshake with the relevant 3GPP parties, and ask
                  whether they are ok with it to ensure we do not step on their
                  The old mapping only addresses the original 4 queues. It will
                  be more the
                  DiffServ to define the mapping
          Zahed Sarker: We should not do this if it conflicts with their
          DB:     We need to bring this work in front of more eyes at the IETF.
                  Please discuss what would be done here on the list.
          Jie Dong: There are additional references that could fit it.
          Zahed:  The GSMA also did a mapping 15 years ago. There is a BBR forum
          Session 2 concluded.

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