Gorry mentions that the draft-livingood-low-latency-deployment makes
recommendations and therefore is useful to present here.
Chairs are not intending to make an adoption call.
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-careful-resume-qlog/
Presents status of document, implementations and next steps.
The document has normative references to the main qlog specifications,
but can't issue last call prior to those being progressed.
Lucas Pardue as QUIC chair and qlog author states that document is in
good shape. Mentions that there are registries that need to be
registered with IANA and such.
Chairs: Do we need a qlog directorate?
Lucas: The form of this is being discussed. In one way or other there
will be an expert review.
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-l4sops/
Presents scope and status of l4sops..
l4sops is intended to be published as an informational RFC, authors
believe it's ready for working group last call.
Asks the wg if it's appropriate to put instructions on enabling L4S
support in linux fq_codel in an appendix of the draft.
Christian H: we are moving away from something ancient to something
modern, in relation to the ECN bit usage. We keep having issues around
new mechanisms (both congestion control) and queue management not being
"friendly" with the ancient standards. We need to get rid of the old
standards. Urges the group to think about how to abandon the ancient
stuff.
Greg mentions bottlenecks that do flow queuing as way to get rid of this
problem, also noting that these are not universally deployed.
Chris Box doesn't mind having the linux config guidance in the appendix,
but also suggests that a URL could be posted there instead.
Greg mentions that he couldn't find a web page with the relevant
information.
Martin D: there's a WG-wiki where information can be put.
Greg mentions that there was an ANRW presentation that found and fixed a
bug in the fallback mechanism. If you are intending to do experiments,
make sure to use the fixed implementation.
Presents hackathon interop activities.
Martin D (from the floor) asks about details on the congestion control
algorithms and their similarity to Prague.
Someone came up and said it's something different.
https://datatracker.ietf.org/doc/draft-livingood-low-latency-deployment/
Presents deployment status of comcast L4S rollout.
Presents an overview of draft-livingood-low-latency-deployment
L4S can be used with Apple devices (Beta versions of MacOs and IOS).
Describes how to use the responsiveness (draft-ietf-ippm-responsiveness)
test with Apple devices, urges network operators to test their networks.
Also urges people to do real-world tests using Facetime.
Presents measurement results in a Comcast network.
L4S cuts latency by half in the presented tests.
Christian Huitema: Three versions of comcast are compared. Can you
clarify how they differ?
Stuart explains that the first one is the most conservative, does not
support L4S deployments, end-systems understand L4S but networks do not
do marking.
Christian asks if there some other AQM in that setup. Jason clarifies
that the modems here do not support dual queue but they support both
uplink and downlink AQM.
Christian: so in the first example we see the effect of AQM and Flow
Queuing.
Stuart interjects to clarify the difference between AQM and Flow
Queuing. Talks about how FQ protects my flow from other flows, but
what's lacking is the protection from myself and my own capacity seeking
behaviour.
The next example is a consumer residential service, where the network
supports L4S. Two tests, run traffic without marking L4S in endpoints
and run with L4S enabled in endpoints.
Stuart explains more about how the responsiveness test works.
Chris Box: Is the version of responsiveness in current Apple
implementations the same as what's described in the latest draft
revision? Stuart beleives so.
Chris asks about how reproducible the results are.
Stuart mentions that the servers are based on Linux and that they have
worked on getting L4S support into the mainline, so that it can be more
easily reproduced.
Martin D. Asks if it generates synthetic test traffic, Stuart doesn't
like that terminology, but yes. Martin goes on to mention that they've
seen similar improvements in Greg's lab setup. In real filtered
measurements he hasn't observed the same improvements.
Jonathan L. Asks if L4S is only in the test tools, or if it's enabled
for all traffic flows. It's all of them, Stuart answers, but there are
mutliple ways to configure that. For normal usage there are heuristics
as to when to use L4S.
Jonathan: Are you planning to submit a document explaining what
algorithm you use for FaceTime. Sutart can't make such promises, the
algorithm doesn't have a name, it's continuously tweaked etc.
Lorenzo asks how close the kernel implementations are to being mainline.
Greg jumps in to mention that there are three parts, TCP Accurate-ECN is
a few months away. The other parts around dual-pi qdisc and TCP Prague
will go in after accurate-ecn, the hope is that they will be more
smoothly integrated.
https://datatracker.ietf.org/doc/draft-tahiliani-tsvwg-fq-pie/
Greg White: Thanks for the draft. This fills a gap in the RFC series in
the available cc algorithms. I think it is worthwhile to adopt this
draft. I also have a technical question. You made a minor modification
to use timestamps. There is an interesting tradeoff in the
implementation regarding the enqueue vs. the dequeue. You also have a
choice in how to make the drop decision. Codel and PIE were at the
opposite spectrum. I wonder whether your design decision has been
studied.
Mohit: There is a paper, which has been referenced in the draft. The
Linux code change has been made already.
Greg White: Did you study the impact of delaying the latency estimates?
Mohit: No, not directly. We studied the different design decisions.
Chairs: This group is the right forum to work on this document.
Poll: Who read the draft?
7 YES, 23 NO, 2 NO OPINION
Poll: Should we adopt the draft?
19 YES, 0 NO, 8 NO OPINION
https://datatracker.ietf.org/doc/draft-westerlund-tsvwg-sctp-dtls-handshake/
https://datatracker.ietf.org/doc/draft-tuexen-tsvwg-dtls-chunk-key-management/
Magnus starts the presentation of the design team and Michael continues
with a description of the architecture, which includes the DTLS stack,
the SCTP stack, and the upper layer protocol. Proposal allows for
implementations of SCTP in the kernel- and user-space.
Martin: The post handshake authentication refers to the DTLS protocol?
Michael: Yes.
Martin: The DTLS Chunk protector is the only dependency.
Michael: There is also the extended key update.
John: Regarding the post handshake authnteication, Tiru has a 00 draft
that allows an exchange in the TLS handshake.
Michael: The post handshake authentication runs on top of TLS and that
is the solution we have right now. There is this proposal from Tiru and
that might be standardized in the future. If it is, you can utilize is.
We could update the document in the future. We have the facility to
negotiate this feature. It is not that we are waiting for it.
Magnus continues with his presentation and talks about the separation of
functionality between the DTLS Chunk and the key management.
Magnus presents an example of a session, which also indicates when the
keys are established with the DTLS chunk implementation.
For the downgrade protection the list of INIT parameters is included in
the key derivation using the TLS exporter.
The DTLS Chunk is an SCTP Chunk with DTLS 1.3 DTLS Ciphertext inside.
Michael continues with the DTLS key management. The algorithms
negotiated in DTLS are the same used for the DTLS Chunk. Since the
current DTLS 1.3 specification does not update the exported keys after a
key update, we rely on the extended key update draft.
SCTP restart is an issue where one side dies, restarts and the other
peer has not detected this reboot. We want to make sure that an attacker
cannot negatively impact the behavior. The SCTP restart functionality
requires the keys and keys to be stored persistently, which cannot be
fulfilled in all circumstances.
There is also an abstract API defined in the draft. The socket API will
be specified later.
There are two individual drafts.
Martin: This IPR declaration does not impact your ability to implement
this proposal.
Michael: No, it is only defensive.
Martin: What is unencrypted?
Michael: The DTLS Chunk header is unencrypted but the payload is
encrypted.
Martin: For the restart, why does it matter for the firewall?
Michael: Because it looks at the verification tag.
Martin: The middlebox will not look at the init chunk.
Michael: If there is a verification tag of zero then it needs to be an
init chunk.
Proposal from Michael: Adopt DTLS key management. Adopt the DTLS Chunk.
Hannes said "good presentation".
Poll: I have read either or both of the DTLS/SCTP drafts.
8 YES, 18 NO
Gorry: The design team contained most of the interested parties.
Charles: Really happy to see this. Question on the dependency. There has
been good progress. Has anything happened on the extended key update?
Michael: It was presented in the TLS WG. It is an working group
document. It received constructive feedback yesterday.
Poll: TSVWG should adopt both DTLS/SCTP drafts?
16 YES, 0 NO, 7 NO OPINION
Martin: Does anyone need to read the document before they can respond.
Join the queue.
Chairs: Thanks for the hard work.
Question to Charles: Do we need to respond to the 3GPP?
Magnus: We need to say that we are progressing.
Charles: We also need to provide a brief description of what has been
going on.
Martin: Think about appropriate milestones.
Charles: Provide a brief description we can relay to the 3GPP
Charles: Do you expect any specific action from the 3GPP? I believe we
have enough input and understand their requirements.
Chairs: If the 3GPP has more questions then they will come to us. Will
you reach out to the TLS WG chairs? I do not think we should not make
promises on behalf of the TLS WG.
Magnus: We should be honest about the progress in the TLS WG. We have
these dependencies.
John: TLS is progressing great. We do not need a write-up.
Chairs: Just inform the 3GPP - no promises.