TSVWG, IETF 118, Prague, Autumn/Fall 2023
Session (1 hour)
Monday, 6th Nov 2023, Session IV 1730-1830
Room Name: Congress Hall 2
1: WG Status and draft updates
RFC's completed: None.
With IESG:
draft-ietf-tsvwg-ecn-encap-guidelines (IETF LC) Document Shepherd: Gorry
draft-ietf-tsvwg-rfc6040update-shim (IETF LC) Document Shepherd: Gorry
Drafts beyond WGLC:
draft-ietf-tsvwg-sctp-zero-checksum Document Shepherd: Gorry
Status updates on other WG drafts
Chairs: Milestones
Notices and Related Drafts
Liaisons:
3GPP Liaison Request - (SCTP & DTLS) Gorry
https://datatracker.ietf.org/liaison/1847/
GSMA Liaison Request - (Multi-Path DCCP) Gorry
Chairs: Announcements and Heads-Up
TSVWG Design Team to set Requirements for DTLS/SCTP
See updates on mailing list.
This team is cope initially to produce some requirements for this
meeting, and to help direct the working group activities.
Magnus: Would be good to rescope design team.
Gorry: Original scope was to produce these requirements. Can this
be completed before end of this meeting? Does it make sense to
request that report over the next two meeting intervals?
Magnus: TLDR: yes.
Gorry: It would be useful to to for this dsign team to look into a
suggested path(s) forward for the working group?
Remote participant: Can we consider also the implications of
satellite 3g with high latency, has sctp been considered in such a
situation?
Martin: That is mostly out of scope for this work, though the
security updates should not much affect the performance
characteristics of SCTP.
Magnus: SCTP is robust on the Internet, and should not suffer too
badly in that situation.
Gorry: If there are security considerations, please bring them to
the design team, more general considerations, please bring to the WG
list.
Transport: Multipath and CC
4.1 Raffaello Secchi: Careful Resumption of CC
draft-ietf-tsvwg-careful-resume
Presented some activities at the Hackathon prior to the IETF,
building experimental implementaions of CR in Quiche, Fastly and
checking interiop, also with P{icoQuic.
Michael: How long are path parameters stored?
Raffaello: The draft does not say at present, we are thinking of
the order 5 minutes, based on what is done in other specs.
Christian: I have tried a jump at ull BDP, that is dangerous. So I
alos tried an increase of window to half the recorded BDP, which
then takes one RTT to grow to full BDP, but is safer if conditions
have changed.
Raffaello: I concur: A jump of a half BDP is chosen to be safer.
Matt: Thinking in futrure: This parameter you would ideally learn
from the history of previous restarts.
Kazuho: We do full BDP with pacing, but that can be 2x
overestimated, and so half may well be the correct value.
4.2 Markus Ahmend: MP-DCCP
draft-ietf-tsvwg-multipath-dccp
Gorry: Markus, you have hackathon code, is that code still relevant
to the latest spec?
Markus: It is still, there are plans to modify the handshake in the
spec, the code will be updated to match.
Markus: Next steps are to confirm the draft contents with those who
has reveiwe comments and ask for a WGLC.
Session 2 (2 hours)
Thursday, 9th Nov 2023, Session I 0930-1130
Room name: Congress Hall 2
Agenda Recap and Notices (10 mins)
5.1 Tommy Pauly: Happy Eyeballs v3
Lars Eggert: Great update, we should do this. Why is v6ops the
right working group?
Tommy: v1 and v2 were in v6ops. They had great input on other
things that need to be updated for v6 only networks.
Lars: While it started in v6ops because of IPv4 VS v6, I don't see
any growth there beyond v6, but on other layers such as TLS. Going
to other groups where this work happens makes sense.
Brian Trammell: Agree with Lars. This looks now very WITty (WIT is
the new area), it is the canonical draft for the new area. If TAPS
weren't going to close, this would fit in TAPS very well. Now, this
group is the place to do the work.
Martin Duke: Is there a critical urgency to publish this?
Tommy: No urgency. The bit on SVBC we've been running for years.
But, there's more discussion on how do we correctly incorporate the
preferences around ALPN, there is still room for discussion and
debate.
Martin: The IESG will discuss it, or if not, DISPATCH. There's four
different areas that could claim this.
Tommy: Agree with Brian on WIT-ness. With area reorg, it fits
better in WIT than other areas. But, the IESG should talk about the
evolution of TSVWG within WIT.
Martin: TSVWG is not the generic WIT place, it still focuses on
transport.
Gorry: As individual, this is interesting because it requires input
from many groups and decisions from one group, I would like to hope
we can continue to develop the work with visibility in multiple
places.
ECN & L4S Drafts
6.1 Jason Livingood: L4S Experience (20 mins)
Jonathan Morton: The results overall seem similar to deploying
Cake. How vigorously are you looking at the harm that can result to
innocent bystanders?
Jason: Very vigorously. The users monitor their regular activity
and report any issues.
Jonathan: That's the participants. What about bystanders: people on
different networks that don't support L4S but receive spillover L4S
traffic.
Jason: We haven't seen any effect. We've got network statistics and
analytics at interconnection points and other places in the network.
Jonathan: Slide 4 - you're using a DSCP, bleaching distorted
heavily-quoted statistics on ECN deployment, I am questioning
justification for using ECT(1). We could have run this experiment
years earlier using DSCP.
Jason: Most networks have their own proprietary use of DSCP, we
made sure to fix bleaching.
Chris Box: Thank you for sharing these results. What are the
Cloud-native apps?
Jason: Cloud Gaming, but we have internal theories on Cloud-based
collaboration apps, which may see a bigger benefit.
Chris: Network responsiveness results slide 14 - what do these RPM
changes mean?
Jason: Challenges - users needed to run latest version of macOS,
enable L4S in network quality test, some of these were confounding
issues. We were hoping to see higher RPM numbers. The numbers on the
right are three different customer examples.
Lars: Any there other effors for customers not in the US?
Jason: Greg White has been running interops, and had a variety of
equipment vendors attend and expect to see PON and 5G
demonstrations, I don't know where these networks are.
Greg: There's a lot of interest and network operators planning
deployment, but so far Comcast is the only one that has announced a
trial.
Jason: Part of my 2024 plan is to talk to other operators.
Dan Druta: Sign me up. Any results on connections from other
devices in the home, such as Wifi routers, switches, that homeowners
install and that are out of your control?
Jason: Good suggestion, we'll make sure we do that.
Subir Das: Slide 4 - You tested Facetime and gaming. Why put
everything on AC_VI on Wifi?
Jason: It is in a recommendation document to use a different WMM
class than AC_BE. Each of these queues has different types on
config.
Subir: Are you following RFC 8325? Gaming and interactive video
would be in different classes. There should be separation.
Jason: The main place where this happens is on downstream side. On
the upstream side it'll mark however the client wants to mark.
Tong Meng: Great results, looking forward to more, such as 5G. How
do you set CE marking thresholds?
Jason: Most of that is done on the client side, the application
software can implement it in different ways.
Greg: On CE marking threshold, one of the config file changes will
roll out soon. Currently a very low threshold, so there might be
some excessive CE marking. Intention is around 2ms of buffering
delay.
Tong: May not be the best option to set CE marking to same
threshold for all networks. We have conducted tests with L4S, we see
non-congested behaviors in 5G the latency will not decrease to a
super low value, there are negative effects to throughput and
bandwidth efficiency.
Greg: Yes, in networks where capacity varies rapidly, there can be
a benefit to having a larger CE-threshold.
Madhan Kanagarathinam: Gaming latency, once we put packets into
AC_VI the network will prioritize. Did we ensure we benchmark the
default case, was it also in AC_VI? Plans for testing with Android
or other devices?
Jason: Android - we have users running Android, we haven't run any
specific tests, if you have any we'd love to talk. First question
- testing we've done so far is only upstream, once we get the packet
off the Wifi, we're looking at marks and putting it in the
low-latency queue, if client has marked AC_VI or AC_BE, it gets
handled however the Wifi wants to handle it. We haven't been able to
set that. Once we do downstream testing, we may see the difference.
6.2 Greg White: L4S Interops and L4S Operational Guidance (10 mins)
draft-ietf-tsvwg-l4sops
Lars: Have you had meetings at NANOG or RIPE?
Greg: Have not had, interesting idea. Thank you!
Gorry: This draft bis targeting publication Nov 2024, please be
sure to add any more experience.
6.3 Greg White: NQB (10 mins)
draft-ietf-tsvwg-nqb
Gorry: People who will review? I see one. Looking for people
volunteering to review the final text, please let Greg or me know.
Gorry: Please comment on the mailing list or Github.
SCTP Drafts
7.1 Michael Tuexen: Zero Checksum for SCTP (10 mins)
draft-ietf-tsvwg-sctp-zero-checksum
Gorry: WGLC will end formally today. This is your last chance to
send comments. The doc creates a registry which allows non-IETF
documents to specify transport behavior. We will consult the IESG.
Lars: What's the IANA policy?
Michael: Spec required, expert will review.
Lars: What is an indication of how much CPU the CRC32c is using?
Michael: Users using datachannels disable checksum on receiver
side, gain up to 30% CPU.
Lars: That seems high.
Michael: These were low-powered boxes. ARMv8 has support for
special instructions for doing it, but they were on smaller boxes. I
know of a product that substantially reduced the CPU amount,
couldn't do what they wanted with the checksum enabled. 30% was the
worst case.
Jonathan: Never underestimate software engineers to introduce
bloat.
7.2 Michael Tuexen: SCTP AUTH 4895.bis (10 mins)
draft-tuexen-tsvwg-rfc4895-bis
Gorry: Chairs think this falls in our charter. Who has read this
document? At least four people. Please hum or indicate remotely if
you think this topic of maintaining the spec is one we should
address. I hear a small hum. Please hum if not. I hear nothing.
Please use the tool now. Who supports adoption of this draft as
work item in this WG? 15 Yes, 2 No.
People who said No: please speak up. None wished to.
We will repeat the adoption call on the list and confirm.
7.3 SCTP & DTLS (5 mins)
Michael: The design team will meet after this meeting.
Gorry: This will be an informal meeting. We will have additional
design team meetings scheduled with remote participation. Should end
at the end of December.
UDP Transport
8.1 Gorry on behalf of chairs: UDP Options (15 mins)
draft-ietf-tsvwg-udp-options
draft-ietf-tsvwg-udp-options-dplpmtud
Issue #16: Decision whether to send ICMP messages?
Wolfgang Beck: I think it would be a bad idea to have ICMP
feedback. If you have oversized UDP packets, you have other feedback
like RTCP. Other protocols like DNS or SIP, they have their own
timeout mechanism. I would prefer solutions that simply drop the UDP
fragments.
Gorry: I understand, just let the application deal with it. Two
notifications of fragmentation is a bad side effect.
Mike C. Heard: I concur.
Christian Huitema: The main thing you should do is set the Don't
fragment bit.
Gorry: These are not IP fragments, but individual UDP packets that
can't set DF. They are fragmenting a larger UDP datagrams at the
sender into two smaller UDP packets, each with an IP header.
Christian: You should do what QUIC does, it has its own
packetization on top of that.
Gorry: Yes, this is orthogonal, it's about fragmenting the payload
on top of that.
Christian: I think I concur with everything that was said before.
Martin Duke (no hats): Fragmentation is confusing. If I think of it
that way, ICMP is a layering fragmentation, because it's about IP
layer.
Gorry: It's possible to have a UDP layer ICMP. But we'd need a
strong reason to do it, I'll ask an INT area AD for comment.
-
Mike: The current -24 didn't get some of the issues that are
currently closed fully addressed.
#21 is our biggest bug bear, modulo the issue of AUTH not being ready,
which I agree on. Those two are specified correctly in the architecture
in this version, but they defy expectations, the WG needs to decide if
we want these things there at all. The easy thing is to drop them. On
the rest, we seem to have agreement in principle.
Gorry: Keep some of that text to capture the dicsussion, but not
specify a code point?
Mike: Hard to argue with that.
Gorry: Let's do a WGLC ASAP. Please contribute and review.
Individual Draft
9.1 WG Chairs: Heads-up notices on proposed future work (10 mins)
9.2 John Kaippallimalil: Metadata for a Media Packets (15 mins)
draft-kaippallimalil-tsvwg-media-hdr-wireless
Gorry: When you say the values of these fields change per packets.
Are they mutable or immutable in network?
John: They're immutable.
Gorry: We are not considering an adoption call at this meeting, but
we will ask questions to the group.
Dan: I'm interested in the subject. What is the overhead of
per-packet information that needs to be updated quite frequently, on
the media server and the wireless node? Are the media server
providers willing to play along? How do you plan to encode those
three elements on a per-packet? I've seen patterns where the
expectation is one piece of information, you are expecting to send
three.
John: The overhead is 18 bytes, if we add an auth option that's in
addition. In terms of updating things, we defined it to be flexible.
Relative priority is pretty easy to provide, the other options are
burst size and delay, which may not be so easy. The data is flexible
of providing one or more. The idea of having something in the IETF
is to allow many application providers and wireless service
providers to have a common framework as a basis to do this. But yes,
there are tradeoffs, we'll need to look at them.
Magnus Westerlund: One of my concerns is related - to process this
in the wireless network you need to keep state and the information
is longer than your buffer depth. I look forward to this, some of
these questions have a lot of impact.
Martin, no hats: Media providers - SADCDN folks are largely content
providers who are trying to solve similar problems, please align
with them. I do appreciate how this has migrated to UDP
encapsulation as an explicit channel between endpoint and network,
easily lets plug in DTLS, privacy, authentication. This could be
better than using UDP options.
Hang Shi: Use case is valid, can be separated in two parts: What
metadata and where do you put it. If we agree on encapsulation,
where we need to defer to which protocol.
Tianji Jiang: I know the background from 3GPP. It's one of many
possible options, it's a good one.
Marcus Ihlar: Agree with Magnus - listen to 3GPP, there is a lot of
work on the applicability. You have to think a lot about the trust
model, as you can allocate resources on the radio.
Ruediger: I'd appreciate discussing DiffServ more in the draft. You
could signal up to 64 signaling behavior.
Gorry: Please hum if the topic of per-packet signaling is a topic
where you'd like to see work done. Please hum if not.
I heard some hums both ways, maybe slightly more for the first one.
Who would contribute to this work? Please use the tool. Not support
it - Would you work on it or review it? 12 Yes, we saw 28 people
interested at the last IETF.
We'll use the WG list to develop more thoughts on this.
Any Other Business (1 slide each & discussion, if time permits)
draft-yao-tsvwg-cco-problem-statement-and-usecases-00
draft-yao-tsvwg-cco-requirement-and-analysis-00
draft-jiang-tsvwg-slice-media-service-01
(Out of time for the above.)