TSVWG Meeting IETF 122
Note takers: Magnus Westerlund, Greg White
Monday 13:00 TSVWG Session (2 hours) Room Name: Sala Thai Ballroom
RFC's published: None.
RFC's in Queue: None.
With IESG:
Drafts beyond WGLC:
Zahed as AD will send his comments today or tomorrow. Concerns about if
WG has properly communicated with the other SDOs that are expected to do
things.
Greg White: Maybe simplest to change the wording from normative, to
informative recommendations. Might still be good to send Liaison
statements to inform them so they can take these into account..
draft-ietf-tsvwg-careful-resume Shepherd: Marten (next: WG Chair
Follow-Up)
draft-ietf-tsvwg-usr-exp Shepherd: David (next: Shepherd Writeup)
WGLC expected:
Status updates on WG drafts:
Careful Resumption of CC: draft-ietf-tsvwg-careful-resume
Related drafts:
Chairs: Milestone updates - see tracker.
Liaison notices, if any.
3GPP Liaison - (SCTP & DTLS) Gorry
GSMA Liaison - (MultiPath DCCP) Gorry
Chairs: Announcements and Heads-Up
New LS received from Broadband Forum: Application of L4S to Broadband
Networks. https://datatracker.ietf.org/liaison/1984/
Zahed will reply to Broadband forum that the LS has been received.
Christian Huitema: There is one aspect to the tables related to
capabilities depending on OS version. Should this be handled/documented.
Martin responded that it is intended as a snapshot in time. May need to
make clear which version that is represented in the table.
Jonathan Lennox noted that before Win 10 life is not particulary good
for ECN.
Martin indicated he's willing to accept PRs to provide documentation of
older OS capabilities.
Gorry (as Individual). Thanks for noting that ToS is only the name of
the data strucutre not a real field. Have it been tested if one can send
CE mark from sender side. Martin will investigate if he can get the
data.
Lorenzo Colitti, notes that one might have explicit have set a socket to
a IPv6 only socket, and that dual stack sockets are different. Will note
an issue.
Richard Scheffenegger In BSD one can set the CE mark. Requested to send
some text.
Michael Tüxen: Commented on Free BSD and the IPv6 only socket.
Stuart Cheshire: Will ensure that someone takes a look.
Martin talked about the experiments done to verify the Chrome capability
to send ECN feedback over QUIC. ECT(0) or ECT(1) connections which Saw
Not-ECT, this is likely handshake packets.
Richard Scheffenegger Windows seeing more CE that may be related to that
it supports Datacenter TCP, thus used in more networks that have routers
that mark CE for ECT(1).
Marten Seemann, with the QUIC spec recommending sending not-ECT
initially for handshake, then switching to ECT. The data indicates that
this is the case. Mirja Kühlewind asked if they could distinguish
expected behavior or if this is mangled packets.
draft-custura-tsvwg-careful-resume-qlog
Due to QLOG format changing, the editors have pulled out the QLOG part
of the careful resume into its own draft. Want to ask the WG to adopt
this as seperate WG item. Thus decoupling it from the careful resume
specification itself.
Mirja Kühlewind, good to have a seperate spec. Process question is it
okay to have this WG do a QLOG document.
Lucas Purdue: QLOG is making progress there will be a bit work before
done. Thus, due to expected work there are clearly interaction. But
think there are a good to have TSVWG own this with tight coordination
with the QLOG people in QUIC WG. To compare with MoQ WG QLOG work, that
would clearly not be suitable to take in QUIC.
Jonathan Lennox: This work has already been adopted, you just split it
into two drafts, not necessary to adopt it again. Maybe we need a QLOG
directorate?
Martin Duke (as Chair) has you already got feedback, is this already
been reviewed? Do people need to review it?
Zahed: Thinks QUIC WG is doing the QLOG format and how to extended it
and it is appropriate to handle this particular format in TSVWG.
Chairs poll: 6 out of 33 had read the draft.
Chairs poll: Should the WG adopt the draft:
Yes: 23
No: 0
No Opinion: 23
Chairs will confirm it on the list.
Comcast has deployed L4s , NQB and downstream AQM to 2 millions homes.
Forecast is to have 5M in 3 Weeks. Upstream AQM was deployed during
Covid to improve work from home.
Martin Duke: Ask for clarification on how different queues are deployed.
CMST downstream queue are deployed and then the modems enabled with dual
queue (L4S) and NQB. Depending on hardware.
Ruediger Geib: Latency under load stuff, is this following the ITU test?
No, this is an internal test.
Lorenzo Colitti: Is the latency in slide, idel latency so the RTT is at
least 30 ms. This is 99% perenctile values and usually not both
directions are in the higher range.
They have had some application measurements which indicates the
improvment better with lower latencies and less delay spikes.
How does one as an app developer figure out how much benefit one would
gain from attempting to use L4S?
Stuart Cheshire: You don't get low latency just by enabling setting
ECT1, it enables the application to give itself low latencies by its
response to congestion signals. Also higher capacity does not
neceissarily mean a "faster" application experience.
If anyone is aware of any security issues with what is in the draft,
please send a comment or a PR. Greg will otherwise reference some
relevant considerations from discussed specifications.
There is one more TODO in the doc. WG is invited to submit text if they
have suggestions. Otherwise we will delete the TODO.
If there are any additional missing text please send comment.
draft-ietf-tsvwg-dtls-over-sctp-bis
Magnus gave an update on DTLS protection for SCTP, including a review of
the existing 3 options and a newly proposed option 4.
Michael Tuexen: slide 8 needs some clarifications. The concerns with
option 3 were described well on the mailing list. Shared state between
Chunk Handler and Record Processor is the source of concern.
Martin Duke: Do both options (3 & 4) have IPR concerns? Option 4 has
less IPR encumberances than option 3.
M. Tuexen: are options 1 & 2 still on the table? At last IETF thought
we'd moved away from those.
J. Lennox: which options require formal verification? Magnus: It
depends.
Zahed: what does deployment look like for each of the options? M.
Tuexen: options 1,3,4 kernel parts can't be implemented in kernel due to
IPR.
M. Tuexen: A modified option 4 might be possible, which could avoid the
IPR concern and could be implemented in an open-source kernel.
Magnus: Option 2 is the only one for which there is no IPR declaration.
Option 4 has not been defined sufficiently yet, IPR declarations for
option 3 might also encumber option 4.
Altanai: can key mgmt be offloaded to a hardware security module? M.
Tuexen: yes as long as you ensure that you process the packets in
sequence.
Zahed: How do we make progress? Can we review design goals and present
the options against those goals for a WG decision.
Gorry: One option is to form a design team that could try to do this by
Weds. Magnus, Weds is not feasible, since Michael Tuexen is not here in
person.
Martin Duke: How long does formal verification take? John Pruess
Mattsson: Maybe a year? MD: What would 3GPPs response be if there was no
formal verification. JPM: Don't know, but better would be to try to
urgently do the F.V. MD: Does 3GPP require an open source solution? Not
necessarily. ??: With IPR concerns will likely not pass 3GPP voting. MW:
Option 3 can be implemented quickly.
JPM: The 6G train is already rolling, bringing an addition to 5G in a
few years will not likely be adopted.
Chair's poll: we should do either option 3 or 4
yes 9
no 1
no opinion 11
Charles Eckel: why is 2 off the table?
Zahed: running polls at this point isn't useful.
M. Duke: To the WG, please get educated on this. We will come back to
this on Wednesday to get a sense from the WG.
Martin Duke is joining as chair, Marten Seeman is taking on a new chair
role. Gorry is leaving to become AD. New chair is going to come in.
Charis discuss the SCTP situation. A design team is formed with a strict
deadline for the Madrid meeting. If no consensus is reached by then, the
charis will take over by presenting the available options in order to
assess if there's rough consensus on any of the solutions. If no
consensus is achieved, we give up and notify the 3GPP.
Chairs asks stakeholders to join the design team.
Zahed as AD intends to approve text on UDP Option??
Uses PIE from 8033, with modification, only use timestamps for queue
delay calculation. Uses FQ as described in 8290.
10 yes.
19 yes,
0 no,
7 no opinion.
...
Marin Duke as an individual: queueing might fall into responsibility of
CCWG.
Zahed agrees and points out that CCWG has congestion control and
queueing mechanisms in scope of the charter.
Presents simulation results with fluctuating bandwidth, comparing
FQ-CoDel and FQ-PIE. PIE might be better at utilizing available
throughput.
Richard Schaffenegger: Expresses support for the work.
Christian Huitema: Asks if they've considered L4S marking as opposed to
classic ECN. Mohit replies that it's not expressed in the draft, but
it's implemented in a working model of FQ-PIE.
draft-seemann-tsvwg-udp-fragmentation
Survey of how fragmentation control is performed in different platforms.
Marten laments the lack of consistency across platforms and types of
sockets.
Explains a possible path where an attacker can inject ICMP messages that
indicate a path MTU smaller than 1200 bytes which blocks QUIC from that
path.
Lorenzo asks why not use dual stack sockets everywhere. Suggests to
delete IPv4 sockets and only use dual stack.
Marten: There could be use cases for single stack sockets Marten.
Summarized comment from Lorenzo: Maybe the document should say "dont use
single stack sockets".
Martin Duke, he's describing all ways to do ECN, don't try to second
guess what others might want to do.
Michael T. Some people want clarity in what kind of address they will
get and therefore use single stack socket.
Yes 5,
No 14
Gorry asks about the plans for this document, Marten wants it
adopted.
draft-cheshire-sbm -> see also presentation in the TCPM WG.
It has taken us 30 years to not solve the latency problem.
Bufferbloat is fixed, source buffering must be solved as well.
Asks for input from implementations that may have solved this.
Lorenzo states that cellular modems only gets grants when there is data
to send, and they tend to want to have a lot of data send at the grant.
The draft talks about Wi-Fi, should mention cellular.
Sturart discusses that bandwidth scarcity is not the problem anymore and
that needs to be reflected in our designs.
Yaroslav expresses support and mentions that this does not apply to OS:s
only, but also to things like Masque and VPNs. A common language and
common set of APIs would be useful.
Christian Huitema talks about GSO, QUIC performance depends a lot on the
capability to do GSO to send N packet at a time, the feedback needs to
take this in to consideration.
Stuart agrees and talks about that the important work is to find the
sweet spot of packet-batching where throughput is high while latency
remains low.
Christian refers back to the QUIC session where Stuart talked about the
interface between applications and QUIC implementations. The QUIC stack,
if it can't write to its buffer will have to drop data..
Discussion on this topic continues.. Chairs suggest that they discuss
more offline.
draft-liu-ipsecme-ikev2-mtu-dect (remote presentation)
Presents work on maximum packet size handling in IKEv2, with the purpose
of getting feedback from transport experts.
Asks if there's anything wrong or any negative impacts of their solution
to prevent fragmentation.
Gorry asks what the intention of the draft is.
It was discussed in IPSECME, no decision about MTU before getting
confirmation that it's ok to do it this way.
Gorry suggests to use the mailing list for this topic, and then send it
back to ipsecme. Martin concurs and reminds people that this is the
place for MTU enthusiasts.
draft-cbs-teas-5qi-to-dscp-mapping
Emphasizes that the draft is informational and that it discusses how the
many 5Qis can be mapped to DSCPs.
Ruediger would appreciate if they would mention L4S. L4S is a great step
in the cooperation between IETF and 3GPP in relation to QoS..
Existing protocol supports outbound DSCP measurement but cannot instruct
what to do on return path. This draft enhances that to be able to ask
for DSCP and ECN to be set of reflected packets.
Previous attempts for TWAMP got the feedback that this should not be
done.
Gorry asks if STAMP can be rate limited, Greg Mirsky answers that STAMP
does not have rate control mechanisms. Also points out that there are
several potential issues and should have strict security considerations.
Gorry needs to think about a number of aspects around this.
Ruediger mentions that if you just want to test the marking this
solution should be fine and if you want to test at high rates, use UDP
speed test.