Minutes IETF103: tsvwg
minutes-103-tsvwg-00

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 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
draft-ietf-tsvwg-transport-encrypt

        Adopted as WG item, submitted -00 with no content changes
        The -01 working group draft was submitted for this meeting,
        added examples, MP-TCP, TCP FAST Open, TCP SACK, TCP MSS issues
        Many other improvements/revisions.

        Open issues in Conclusions, and section on Metrics derived
        from Network Layer headers.
        Authors seeking WGLC for the next meeting.

DB:     Has anyone reviewed this from a Privacy perspective?
        (He has someone in mind.)
CSP: Some.
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 (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 don’t 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 Review.
CSP: OK, next revision may be ready.
Spencer: I’d 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
draft-ietf-tsvwg-rlc-fec-scheme

-:      Is it safe across several platforms, CPU, etc:?
VR:     The proposal is
to do beta tests on small and larger devices. Want to include

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 also 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: The code authors are not the same as the ID authors.
CSP: The IETF has history of including code in RFCs
MK:     In this case, 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
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's what we do with modifications.

The next steps are to resolve the issues!
Chairs: 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
draft-ietf-tsvwg-ecn-l4s-id
draft-ietf-tsvwg-l4s-arch
draft-ietf-tsvwg-aqm

        The motivation is extremely low queuing delay (micro second delay vs
        5-15 ms delay). Second queue is for legacy control. ECT(1) is the code
        point that signifies this.

        The Tsvwg-ecn draft draft has been restructured and then,
        a series of technical updates have been done.

DB:     Slide 7 is a great slide - to show the structure of a solution.
MA:     If we had FQCodel how does this work when we use this in the C queue
(see figure) BB:     We did not look at FQ Copdel. MA:     Are there any
recommendations on the defaults? BB:     This needs to wait for implementation
MA: Do I keep FQ code in the C-Queue on slide 7? Bob: Yes, but there are
challenges in finding the average congestion level across the queues. MA: It
appears FQ-Codel is shipping as a default in some distributions. Bob: I don’t
have implementation experience of FQ-CoDel, we used Pi and have this now
available in a tidy form. Mirja: 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 DCTCP
BB:     One could deploy queue protection, policers. This is something we can
gain experience about. BB:     The proposal is about fetecting loss in units of
time (point 5) DB:     there are different engineering trade-offs across levels
in the stack.
        Links to scale without re-sequencing
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. This
group could assume
        that they are relaxing link order or interface reordering, bit one
        person’s link is a tunnel to another and unless we are careful we end
        up with reordering  between bonded links e.g. between data centres and
        that is a very different thing. I’m urging caution here before we start
        discussing this wider, to be very clear about what is intended and the
        implications 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. GF:     This is not just about RACK in TCP. BB:     I would like
input to the discussion from rmcat, tcpm GF:     This is not the best way to do
this, we 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 make sure this is seen.
BB:     I can help.
DB:     Please do, send material to the chairs, and we 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, parameter
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 in
packets MK:     I have concerns accuracy when reporting in packets vs bytes MW:
    I have to think of reporting trade-offs. This is simple for V1. BB:    
Byte counters in accurate ECN /consider protect from attacks MK:     These are
not possible in QUIC GF:     We could think about doing something different in
later QUIC revisions.

QUIC delayed ack 25 ms, ECN-CE immediate Ack
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 in a
Bottleneck Link

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 be misconfigured,
(RFC 5706) Martin Duke: This is an interesting idea. Please send mailing list
comments.

6.  New Work on overlay networks (short talk)
draft-li-tsvwg-overlayed-path-segment-fwding

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 implemented.

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 functions. DB:     This is useful for a common way for DPLPMTUD with UDP.
LE:     This seems heavyweight. GF:     This is for new protocols, or to deploy
common UDP transport mechanisms, 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 for RTP.
        Does DNS need it?
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 fragmentation…
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.
GF:     I believe the intent was to use with tunnels.

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:     There was quite a lot of discussion on fragmentation, and it works
        less well than other options.
DB:     The only other option is to drop packet in some tunnelling cases.
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 this helps. I don't want to keep this
        as a UDP Option.
GF:     It could be that Frag. is only a part of the tunnel protocol, rather
        than a UDP Option.
DB:     We will issue a consensus call on the CCO checksum.

Lars:   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 delivery
        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
deployment
        experience.
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 Tuexen)
draft-ietf-tsvwg-natsupp

Plans for progressing this were presented, a new rev is to be submitted asking
for WGLC.

SCTP.bis

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-ietf-tsvwg-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 something.
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, please
        come and talk.

5.4 Ole Troan (OT): Discussion of PMTUD from the IETF 6MAN WG
draft-troan-6man-pmtu-solution-space

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
        destination.
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 working. It works, it is used.
        People don't like it. Operators rely on this 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?
        The old mapping only addresses the original 4 queues. It will be more
        the DiffServ to define the mapping
MW:     We should talk with 3GPP group, to see if they are ok with this.

Jie Dong: There are additional references that could fit it.
Zahed:  They are not doing it, but have not seen if they agree with what is
        here. GSMA also did a mapping years ago. There is a BBR forum TR203.

Session 2 concluded.