TSVWG IETF 115 session
Monday November 7th, 2022 - 2 hours
Room Name: Kensington 1
Notetaker: Esko Dijk
TSVWG Accomplishments and Status
(Chairs present - see slides)
1. Agenda
(Chairs present - see slides)
```1: WG Status and draft updates - chairs (15 minutes)
Rotating Chairs - Welcome Marten
RFC's completed/in Queue:
draft-ietf-tsvwg-ecn-l4s-id Document Shepherd: Wes
draft-ietf-tsvwg-l4s-arch Document Shepherd: Wes
draft-ietf-tsvwg-aqm-dualq-coupled Document Shepherd: Wes
With IESG: None.
Drafts beyond WGLC:
draft-ietf-tsvwg-ecn-encap-guidelines (Writeup Needed) Document
Shepherd: David
draft-ietf-tsvwg-rfc6040update-shim (Writeup Needed) Document Shepherd:
David
draft-tsvwg-dscp-considerations (post WGLC) Document Shepherd: David
Chairs: Milestone updates - see tracker.
Chairs: Status updates on other WG drafts:
draft-ietf-tsvwg-nqb (WGLC)
draft-ietf-tsvwg-usr-exp User Ports for Experiments (Ready for WGLC)
Chairs Topics
Obsoleting the PHBID registry at IANA
TSVWG Leadership Update
Marten is welcomed.
Martin Duke: thanks David Black for his contributions and expertise, for
everything.
2. Individual drafts session
2.1 draft-livingood-low-latency-deployment
(see slide)
2.2 draft-miao-tsv-hpcc
Talk descibed HPCC++ deployment, large market acceptance.
2.3 draft-kaippallimalil-tsvwg-media-hdr-wireless
This ID proposes a set of metadata for wireless networks carrying
low-latency media, and how to transport this metadata.
3. WG Differentiated Services & AQM Drafts
3.1 Gorry Fairhurst/Ana Custura: DSCP Considerations (10 mins)
draft-ietf-tsvwg-dscp-considerations-05
Post WGLC
(see slides)
One WGLC suggestion not yet included (slide 4/6): text is pending on
"Bleaching" and will be in next revision.
3.2 Greg White: L4S Operational Guidance (10 mins)
draft-ietf-tsvwg-l4sops
4. WG Transport Drafts (DCCP, UDP & Other Transports)
4.1 MP-DCCP (20 minutes)
4.1.1 Minjun Xi*: Interoperability of MP-DCCP
Ported MP-DCCP to Android (kernel). Tests run with iperf. Test
environments: LAN, WAN. Next steps to test with real traffic (e.g.,
Skype).
Conclusion: Interoperability was reported, -06 draft mature and
complete.
(see slides for details)
David: It is good to see running code for this, a solid piece of work.
Thank you.
4.1.2 Markus Ahmed: MP-DCCP
draft-ietf-tsvwg-multipath-dccp
Discussion of intended document status
Request for reviewers for WGLC
Status: We think there are only minor open issues, this is
feature-complete now.
(many issues from reviews were solved since the past IETF meeting - see
slides for detail)
Note: Slide 4/5 is missing some checkmark graphics - not complete.
Gorry: A show of hands requested for who has read this draft or a
previous version of it.
Poll result: 14 have read (20 have not read).
Requesting any input on PS status, why wouldn't it be PS? Anyone thinks
it should be EXP?
Martin Duke: We are requesting input to help inform this decision about
the publication track. It would make sense to align with the intended
status for the MP-QUIC work. Initially, multipath scheduling seemed like
mostly a research issue not so much for practice.
Markus: (...)
Martin: This protocol work seems ready to progress, solid. A PS status
would communicate to others that it is "safe to use".
Lars Eggert: The scheduling problem is still hard. We have solutions
that work for specific path combinations, but it remains hard in
general. From a safety point of view it should be fine to go ahead. But
we do need a more general scheduler for multipath scenarios (for future
research).
Sri Gundavelli: What is the key technical differences with other
solutions? - compare it with mobile / cellular / 5G systems where
multipath is supported e.g. 2 different access technologies, or
mobility.
Markus: We don't follow this (yet).
Martin: There can be some concerns on fairness issues. People will adopt
MP for its performance. This could mean we might decide not to stamp it
as "standards track" yet.
Lars: This refers to congestion control work by Damon. A mathematically
proven method. Could pick this up as baseline. Need to figure out if we
can feel comfortable with this. What do you use currently for congestion
control?
Martin: MP-DCCP is currently using BBR CC.
... Coupled congestion control.
Lars: This draft needs to define in words how to do safe congestion
control.
Mirja Kuehlewind: There is still a lot of stuff additional to multipath
TCP, so this is not a small change. So there's a slightly higher barrier
(for PS.) So someone should be able to produce an independent
implementation from the draft text (not using the existing code).
Gorry: The Chairs and ADs are asking, what is the maturity of this spec?
What are the risks? Give your input - go to the AD or chairs - quickly!
Question: How many people would review this doc in WGLC?
Poll: 8 would review, 10 would not (or think it's not yet ready for
that).
4.2 SCTP AUTH
4.2.1 John Mattsson: SCTP Authentication analysis (10 mins)
(see slides)
Five SCTP-AUTH security issues found (2 reflection, 2 replay, 1
theoretical only).
Michael Tuxen: Issue 1 reflection, we missed putting in specific things
for this. But for DTLS over SCTP it seems no issue of "inserting data"
by attacker. On issue 2: SCTP doesn't provide better replay protection
than the underlying protocol, that's clearly stated / understood. We
just didn't specify additional things there. On issue 3: we didn't
specify something here but didn't know this. On issue 4/5: at the point
of time of SCTP-AUTH, there was no difference assumed between attackers
who could read packets and who could write packets.
David: "replay" is used a bit inaccurately here. These here are much
more specific replay attacks where the replay happens exactly at the
right time. Can't happen at arbitrary later times which is usually meant
with "replay attack".
Martin Duke: Thank you for breaking our stuff :-) Good contributions,
thanks.
4.2.2 Michael Tuexen: SCTP-Auth 4895.bis (5 mins)
draft-tuexen-tsvwg-rfc4895-bis
(see slides)
Michael: Should we adopt this as a WG document first and then do the
substantial changes (updates of RFC 4895 text)?
Magnus Westerlund: We need to fix the issues that were brought up,
agree.
Poll: To get a feel of how much people have looked: Who has read this
draft? (1 has, 17 not).
Gorry: Few people had the read this draft. The chairs encourage people
to read this draft - today there has been a number of talks on security
and we will look for adoption by the group at a future time.
4.3 Magnus Westerlund: DTLS over SCTP (10 mins)
draft-ietf-tsvwg-dtls-over-sctp-bis
(see slides)
(Slide 6/11) Requesting WG/people to perform own security analysis - are
suggested mitigations sufficient?
Michael Tuexen: Is it relevant what Open Source implementations provide,
given the IPR issues? Can I use an open source DTLS information to test,
or is part patent protected? (asking since WolfSSL was mentioned)
Magnus: ...
David: I suggest to take this discussion on the list. Not a good topic
here.
Martin Duke: If you're confident that DTLS 1.3 is good w.r.t. roadmap
and implementations, then it's fine to go for 1.3 only.
Magnus: It may be good to delay this (1.3) question a bit, see later.
Magnus: Slides 10/11 are asking for input.
Conclusion: The timeline for completion is delayed. We may need to
notify 3GPP of delay with an Liason Statement.
4.4 UDP Options (5 mins)
4.4.1 Joe Touch* (proxy Chairs, TBC): UDP Options
draft-ietf-tsvwg-udp-options
Gorry: A revised ID expected shortly after this IETF, and will be
subject to WGLC
(no presentation).
4.4.2 Tom Jones/Gorry Fairhurst: DPLPMTUD for UDP Options
draft-ietf-tsvwg-udp-options-dplpmtud
This will be WQGLC'ed at the same time as above (no presentation).
5. Individual Drafts
5.1 Michael Tuexen: SCTP/UDP 6951.bis (10 mins)
draft-tuexen-tsvwg-rfc6951-bis
(see slides)
Document created after consulting with AD.
Michael: Can we request WG adoption?
Gorry: I encourage this WG to give feedback on this; it should be of
interest. We are looking forward to see a future presentation.
5.2 Michael Tuexen: Zero Checksum for SCTP (5 mins)
draft-tuexen-tsvwg-sctp-zero-checksum
(see slides)
Michael: The co-authors are willing to implement it into Chrome /
Firefox. So there is some support from implementers. Also Wireshark
support was added at the Hackathon.
Michael: This is a simple document, could progress very fast, and people
want to deploy it. Requesting WG adoption?
Existing comments from Gorry, Mike, and the responses to the IANA
questions will be integrated.
Poll: Who has read this document? (result goes here - notetaker didn't
catch it)
Lars Eggert: You don't need an RFC to make this IANA request, it can be
a "stable specification" for IANA.
Gorry: Lars is correct.
Poll: Who thinks this is useful work? 18 agree, 1 not raising hand.
Martin Duke: I have not read these drafts, do we have WG capacity to do
all this?
Lars: The best home for this work is this WG, still.
Gorry: The Chairs will monitor this work and will do an adoption call in
the future when there are resources to complete this.
Magnus: This makes sense, be clear of the purpose of the document.
5.3 Nicolas Kuhn*: Careful resumption of CC (10 mins)
draft-kuhn-quic-careful-resume
(See slides.)
Slide 2/7: In a satellite network context, QUIC took a while to converge
on the new capacity.
Nicolas: QUIC WG concluded that the problem space isn't QUIC-specific,
but rather generic for congestion control. So that's why we present now
here.
Summary: The ID authors are asking TSVWG if it is willing to work on
this?
Piers O'Hanlon: The signaling has been looked at already in a proposal
for TCP.
Nicolas: We wanted to have metrics in which the client could
participate.
Piers: TCP metrics measures timeouts; this works reasonably well.
Gorry: People, please send an email to the list with details, that would
be helpful.
Martin Duke: We had discussed a CC WG possibility. There is a side
meeting on THursday for that.
Gorry: The Chairs encourage people to keep working on it, we'll find an
IETF home for this.
5.4 Gorry Fairhurst: Guidelines for Internet CC (5 mins)
draft-fairhurst-tsvwg-cc
(see slides)
Gorry (as individual draft author): I am requesting people to come and
talk about whether IETF has made correct guidelines on CC so far. This I
think needs to start with a 'design team' activity ideally. We want to
make new (updated) recommendations or it could even conclude that the
current ones are already right.
Document structure was updated. It is now easier to read - and
specifically tries to differentiate two types of congestion events.
5.5 Martin Duke: ECN Tunnels (5 mins)
draft-duke-tsvwg-ecn-aggregating-tunnels
(see slides)
Martin (as individual draft author): I am looking for input.
David (as an individual): I recommend to proceed, these seem like new
topics.
6. Any Other Business (If time permits)
(There was no time left in this session.)