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
  1. 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

  2. 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.

  3. 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

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  1. 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.

  2. 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.)