TSVWG Agenda at IETF-121 (Dublin)
https://datatracker.ietf.org/wg/tsvwg/documents/
Room Name: The Auditorium
Note taking: Jonathan Morton, Joerg Deutschmann
Gorry Fairhurst and Marten Seemann at the table
RFC's published:
RFC's in Queue:
With IESG:
Drafts beyond WGLC:
With WGLC expected:
Status updates on other WG drafts.
Remaining Working Group IDs:
Chairs: Milestone updates - see tracker.
Announcements and Heads-Up:
Please read the individual drafts to familiarise before Friday's
session.
Liaison notices, if any. (There were not.)
Chairs: Announcements and Heads-Up
Changes in draft from -v10 to -v11:
Testing of CR in QUIC, performance analysis using picoquic and
(cloudflare) quiche.
quiche: 10 MB transfer over 4G Vodafone, 5G Vodafone,
geostationary satellite Hylas1, Fibre Zen Internet.
picoquic: geostationary satellite:
picoquic: 5G, Starlink, Congstar LTE
Ingemar Johansson: Question about slide 5: Was there degraded
performance with CR?
Rüdiger Geib: Question about endpoint information consisting about
IP and DSCP, what when NAT is in the connection? The IP address
might not stay the same on end-to-end path.
Kazuho Oku, Ana Custura, Joerg Deutschmann
Kazuho Oku: Careful Resume Experiment at Fastly
Careful Resume test results from Hackathon
Chairs: Show of hands:
* Who has read the CR draft? (Yes: 14, No: 25)
* Do you think the I-D is ready for last call?
* (Yes: 13 yes, No: 0, no opinion: 28).
* The working group will start a last call on the mailing list before
the next meeting.
Technology is ready to scale.
Question from Mo Zanaty: What applications were enabled for this?
Question from Martin Duke: For the low latency queue on the CMTS,
are those stats in milliseconds?
Comment from Stuart Cheshire: I appreciate the effort by Jason and
Comcast in leading the ISP industry on real-world deployment.
Room Name: The Auditorium
… continuing …
Netflix Simple Rate Controller for cloud gaming.
L4S CC in Google Chrome QUIC.
Next IETF L4S Interop: IETF 122 Bangkok, March 2025.
Question from Lorenzo Colitti: Is there documentation? Is there an
OpenWRT config to put on a router?
Question from Jonathan Morton: Mandatory containing of L4S traffic
to a participating network during experimental phase?
Jonathan Morton: Is there active monitoring in the experiments at
Comcast? Checking traffic that goes through network encounters such
bottlenecks elsewhere?
Jonathan Morton: Confidence in passive detection by application?
Jonathon Morton sighs. This kind of thing has been raised repeatedly
during L4S lifecycle and summarily dismissed without real
justification.
ALL CHUNKS parameter.
Improved Replay Protection.
Next Steps slides were written before this discussion. Improved
Replay Protection will be added to keep things simple; not specyfing
the size of the Replay Protection window.
This I-D should be stable soon.
Gorry: In the same way as IPSec, this does not specify the depth of
the replay protection?
Is the working group okay with this?
The I-D is expected to be to progess by end of 2024.
Fourth approach:
There were two parts:
The plan is to include an abstract and socket API to allow the
two parts to interact.
Martin Duke: What is the relationship to the key management to
be specified in the TLS WG? Will key management be specified by
IETF standard?
Which of the discussed documents corresponds to RFC 9001?
Martin Duke: Will there be an adaption of new draft for the
crypto part?
Martin: Will there be a separate document for the key
management? Is there a dependency on the TLS WG?
Martin: Are there three drafts required?
Gorry: This approach seems like it would address the issues
brought to the WG about Open Source implementation. Multiple
documents would seem sensible, and this will need coordination
by WG chairs.
Show of hands: Can the WG un-adopt
draft-ietf-tsvwg-dtls-over-sctp-bis? (Yes: 14, No: 0, No opinion: 2)
* WG decision: the chairs will unadopt the draft.
Martin Duke: The problem with original solution was dependency on
TLS?
John Preuß Mattsson: There are no changes to the TLS dependency
as agreed on a previous discussion. One year sounds optimistic.
Formal l verification is simpler than key update.
Magnus: Let us publish each component as quickly as possible!
Chairs: Hum to check of where to go:
Chairs: This is clear support to continue this direction.
Gorry: What is the approximate time for revision zero of new draft?
Zahed (as AD) asks chairs to summarize.
Chairs summary:
(1) The WG Milestone will be kept: Submit "DTLS over SCTP" as a Proposed
Standard RFC.
(2) The Chairs will remove the current adopted I-D and update the
milestone: removing: draft-ietf-tsvwg-dtls-over-sctp-bis.
(3) The people from today's meeting will create new I-Ds and request for
adoption.
(4) The chairs will continue to liaise with 3GPP.
draft-ietf-tsvwg-dtls-over-sctp-bis
draft-westerlund-tsvwg-sctp-dtls-chunk
draft-westerlund-tsvwg-sctp-dtls-handshake
Room Name: The Auditorium
Mohit provided a heads up for a new AQM I-D:
draft-tahiliani-tsvwg-fq-pie-00. Chairs asks group to provide feedback
on the mailing list to gauge whether there is interest in completing and
taking on this work.
Martin Duke explains that it is a pretty poor experience trying to
implement ECN for UDP across multiple platforms. He wrote this I-D to
have a document available and searchable.
Jonathan Morton notes that BSD is a missing platform. On the other
hand, Martin notes Apple's network stack is BSD-based and that BSD
is mentioned in the editor's copy of the I-D.
Stuart suggests that the I-D adds a column for the Apple Network
Framework and will check with Apple colleagues as to whether they
support ECN exposure already. There was a suggestion to add a column
for the Apple Network Framework because e.g., on the Apple watch BSD
sockets are not available.
Lars states that there are practical differences between Apple and
BSD. He suggested that in parallel to the I-D some one can run
Github CI to check that the I-D is up to date. Any signal that does
this is fine.
Question: Can we do the same thing for the packet TTL? Lars explains
that there are more cases where ancilliary data is useful and
similar guidance would be useful. However, this is thought to be
expanding the scope of the I-D.
Marten S: Can the I-D provide more information on the contents on
the control messages, different platforms and versions of platforms
expect different (sized) SOCKOPT values etc. Reply: This would be
useful.
The DF bit is important for QUIC, can this document be extended with
that or a new doc? (Also an increase of scope.)
Martin notes that his plan is not to write a SOCKOPTs manual.
Gorry notes that for making this I-D useful it should have a limited
scope to ECN.
Spencer expressed a lot of support for this work, and that adopting
the draft and working on it will be more helpful at getting ECN used
than either ignoring the situation or publishing the I-D as an ISE
stream RFC in its present stage would.
Spencer also noted that it seems like every new performance proposal
either generates someone asking "how does this work with ECN?" or
"why aren't you just using ECN", so improving the draft has a chance
of making the Internet work better. This work should be done by the
WG.
Jonathan asks about if someone has contacts regarding ECN for Java
Virtual Machine.
Michael Tuexen agreed with Marten about describing the types of the
messages. Also, it could be good to note behaviors that are
potential bugs, rather than writing these down the WG ought to check
if maintainers can fix these.
Chairs note that fixing differences would be more useful than
documenting variants. It would be really good to reach out to developers
around the behaviours that seem odd, e.g., prior to a potential WGLC.
Chairs: Have you read draft-duke-tsvwg-udp-ecn-01 or
draft-duke-tsvwg-udp-ecn-02? (Yes: 21, No: 14)
Chairs: Is this a useful topic for the working group work to work on?
(Yes: 38, No: 0)
Chairs conclude that there is a clear apetite for people to take on
this work.
Chairs: Could the WG adopt this document as a basis?
(Yes: 27, No: 0)
This document will need a group of people actively working on it, and
we will ask the WG mailing list if they support adoption.
This revision is a result of further work by the authors to respond to
WG requests for a shorter document detailing the requirements. Describes
tradeoffs between per-session, per-flow, and per-packet feedback
signals. Requirements for client-to-network, API/system, and
server-to-network.
Marcus: Is the signalling intended per flow? Have you considered the
abilities of endpoints in prioritizing media themselves?
Ruediger: Is this packet-based scheduling or flow-based? I would
prefer per-packet for stateless schedulers.
John: There is work on this in a wireless context. We've looked at
this and do get per-packet improvements, but we haven't put that in
a draft yet.
Ruediger: You don't explain how this interacts with end-to-end
congestion control. I'd like to understand that.
Gorry the chair: The WG was actually asking where the pitfalls are, when
deploying these protocols, not considering adoption of a particular
proposal at this time.
Brian (SCONE chair). A lot of the things that we've talked about on
the previous SADCDN mailing list apply here. Brian notes that SCONE
work is probably complementary to what is being done here.
Ingemar comments on delay requirements. The simplest 5G schedulers
use Round Robin, but there are more advanced ones that can be used
to prioritize delay sensitive applications. Comments on some of the
research papers and notes that some of them use advanced coding that
is more expensive and expresses skepticism about the benefits over
having low throughput and congestion control. Things perhaps work
fine.
This was analysed in Octopus and showed benefit. Discussion on the
intricacies of the 'Octopus Paper' (please refer to YouTube
recording if you're interested).
Med mentions that detailed solution discussions are for the future.
Brian (individual) Asks if the solution space is restricted to the
case where endpoints send semantic information to the network.
There's a weird overlap with the Path Aware Networking group. There
are two or three different spaces where we work on this and the
solution spaces are exclusive. Worried that this is a bad way of
making progress.
Key point from Brian. We have to understand how deployable something
like this is. Worries that constraints might make the interest for
people to implement this quite low.
Gorry clarified relation to TSVWG.
Lars: The security considerations need significant work. For
instance marking i-frames can expose a lot about a video. Let's not
reexpose information that we've finally put into a crypto envelope.
This requires very deep security analysis. Lars is skeptical about
the usefulness and complexity of the work. As an endpoint provider
he prefers predictability in network behaviour.
Med states that there is no mandatory requirement of exposing
metadata beyond stating that certain packets are more important than
others.
Mirja reminds us that this is not something new. She prefers work on
concrete uses rather than abstract requirements. Also points out
that there are and have been many venues for this discussion.
Working on requirements will not be useful time spent for TSVWG.
Make a more concrete proposal.
Med: We had a bunch of solutions and got feedback that we don't know
what you will solve. So we agreed on working on a set of
requirements. This helps people undersand what we want to achieve.
Spencer observes that SCONE was chartered so recently that people
were surprised about the charter. Please read RFC 9049 (Brian
emended this comment to point to Section 4.9 of that RFC in the
chat)
Zahed (Area Director): I'm happy that this work is being done and that
people are finding the minimal set of requirements. This does not
necessarily need to be published. What I want is some form of consensus
on whether we want to work on per-packet treatment. It could be a good
time to go back to defining a solution based on these requirements. The
WG should now decide whether we should work on this and get to
solutions.
Gorry: Not sure if I understand how to judge specific I-D proposals.
Many things that came up at the mic need answers. The WG needs to
understand what these concerns are for this concrete problem space.
Zahed notes that security discussions can be facilitated in many
places.
Gorry wonders if we can make a judgement call around per-packet
marking whether known issues that can be handled in the group. Can
we ask a sensible question here?
Martin Duke was worried from the start that there will be hidden
pools of resistance to work like this. People outside this working
group will likely have problems with this approach. Key point:
consider early feedback through options such as SECDIR review or
re-chartering.
Mirja re-iterates that this is an interesting space but this is the
wrong approach. Please show benefits first. She would like this done
on a case-by-case basis.
Gorry is not asking about the merit about approaches but rather whether
it is feasible to expose this kind of information (per-packet diffserv,
preferential discard etc).
An option B: Progress documents separately, different designs for
different parties (WiFi, 3GPP, etc)?
Mirja refers to 3GPP discussions, not seen any performance results
so far.
Brian notes that in SCONE we look at a concrete design and iterate
quickly on that. We are getting into the option B space. Let's do
concrete work and aim to be less surprising to the rest of the IETF.
Spencer notes that we have relied on RTP and DASH to address
transport problems at the application level for decades. SCONE might
work, and might be deployed, but it makes sense to me that we can
look at multiple potential solutions in parallel.
Tianji relates this to the work done in 3GPP and mentions that there
are a few options but non is elegant. Suggests to expand section 7.1
on privacy, this is very important for 3GPP.
QUESTIONS FOR THE GROUP:
Poll in parralel with discussion:
Who has read rev 03 or 04 of this draft?
(Yes: 15)
Does the WG think it helpful to spend time exploring the proposals for
concrete designs? (Concrete protocols first to understand benefits.)
(Yes: 12, No: 17, No opinion: 9)
Does the WG think it helpful to explore guidance on per-packet
meta-information? (Guidance first on what ways meta data can/cannot be
used.)
(Yes: 20, No: 11, No opinion: 6)
Gorry notes that he needs to discuss this with his AD. Med concludes
with that he agrees with the point that we need to make the rest of the
IETF aware of this work.
QUESTION:
Does the WG wish to adopt a work item to work on a requirements
document? (Yes - consider adopting something and you will review) (No -
do not consider adopting) (No opinion) (Yes: 10, No: 18, No opinion: 8)
Stuart mentions that all applications want the same thing: Low
latency, high throughput and low loss. It'll be better to focus on
improving the network characteristics (e.g., reduce loss). Please
use ECN instead of throwing packets and we don't need things like
selective discards.
Med mentions that this is complementary to L4S and that there
are cases where packets will be lost in any case and selective
dropping might help.
Stuart questions the tradeoff here, doing a lot of work around
fixing problems that are rare is questionable. Motivates for
reducing packet loss (c.f. Comcast L4S experiments) and compares
design of fixed data rate telephone network with today's
Internet.
Gorry notes that we should continue the debate on the mailing list.
Lars: Low latency means shorter control loops which allows
applications to be more responsive.
Ruediger Geib: What are the benefits considering a simple design? Do
not engineer for 100% of the cases, engineer for 99%, that's good
enough.
Gorry has no concrete advice on what to do next except for urging
continued discussion on the mailing list.