Minutes IETF113: tsvwg: Fri 10:00
minutes-113-tsvwg-202203251000-00

TSVWG Agenda
Chairs: G Fairhurst, W Eddy (Remote) D Black (Remote)
AD: Martin Duke

Session 1: 13:00-14:00 Monday 21st March (1 hour)
.1. Agenda
Note taker: Stuart Cheshire (Notes were updated by meeting recording)

.2. Chairs Update
RFCs completed or in Queue: None.

Drafts with IESG: None.

Drafts beyond WGLC:
   [draft-ietf-tsvwg-ecn-encap-guidelines](https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ecn-encap-guidelines) (Writeup Needed) Document Shepherd: David
   [draft-ietf-tsvwg-rfc6040update-shim](https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-rfc6040update-shim) (Writeup Needed) Document Shepherd: David
   [draft-ietf-tsvwg-ecn-l4s-id](https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ecn-l4s-id) (Writeup Needed) Document Shepherd: Wes
   [draft-ietf-tsvwg-l4s-arch](https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-l4s-arch) (Writeup Needed) Document Shepherd: Wes
   [draft-ietf-tsvwg-aqm-dualq-coupled](https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-aqm-dualq-coupled) (Writeup Needed) Document Shepherd: Wes
ECN encaps ID is awaiting text before final write-up and new ID will be sent to the WG.
ECN Shim Headers ID will be submitted with this ID.
A few small points to be taken care of for L4S writeup and plan to wrap these commentrs up this week and submit to the AD a week after.

Chairs: Milestone updates & Liaison
   WBA Liaison Request - (DSCP/5QI mapping) David
       A liaison response was sent about a year ago, and nothing currently heard from WBA
       on this topic.
   3GPP Liaison Request - (SCTP & DTLS) Gorry
   GSMA Liaison Request - (Multipath DCCP) Gorry

Chairs: Announcements and Heads-Up 
   Work related to other WGs: None.
   New proposed work:
      [draft-romo-iccrg-ccid5](https://datatracker.ietf.org/doc/html/draft-romo-iccrg-ccid5) (Please discuss on ICCRG list; progressd of this is related to the BBR IDs)

.3. Transport : SCTP & L4S

3.1 Michael Tüxen: SCTP NAT Support
- This discussed the way forward for the different proposals.
- draft-ietf-tsvwg-natsupp (this ID was returned to WG)
- Anissue is that on multi-homed SCTP hosts, a session can have
multiple IP addresses, but only one port, which is incompatible with
having different NATs on different paths do different port translations.

• Gorry Fairhurst asked for comments from the meeting participants.
• Martin Duke: What is Michael’s preferred solution?
• Michael Tüxen: I like solution 2 (Always use a fallback mechanism)
• Claudio Porfiri: (indistinct audio)
• Magnus Westerlund: These are the issuesI see: Can we support
  multi-homing? Home many sessions? What is the complexity?
• Cullen Jennings: I don’t see how solution 2 works. It is too
  vulnerable to a denial-of-service attack.
• Michael Tüxen: Protection is because the state can only be created by
  internal hosts.
• Chairs: We need to make a decision after this meeting, please
  follow-up on the list and we need to call-out a way forward for this
  item to the group.

3.2 Magnus Westerlund: DTLS over SCTP - RFC6083.bis
- There was discussion based on decision whether or not to make a bis
version that obsoletes the RFC6083 spec.
- draft-ietf-tsvwg-dtls-over-sctp-bis
- Gorry Fairhurst: Is obsoleting RFC 6083 a separate question we can
discuss later?
- Michael Tüxen: I agree RFC6083 needs to be updated. I am concerned
about Ericsson’s IPR declaration on this draft, and that the suggested
work item would prevent open source, which has corrently been possible
for SCTP spec.
- Magnus Westerlund: We do need to make progress for a use by 3GPP.
There could be two IDs, anothger one a simple update to RFC6093,
allowing this to progress in parallel.
- Michael Tuexen: We might need to start a new draft that avoids the
Ericsson’s IPR claim as a replacement for RFC 6083.
- Magnus Westerlund: Would you be willing to work on an alternative to
RFC6093?
- Michael Tuexen: I would work on an update that obsoletes RFC6093, if
there are people wish to join me.
- Gorry Fairhurst: This Working Group needs to decide on this after the
meeting: We could decide not to update RFC 6083, and whether a parallel
spec would be acceptable by the WG.
- Chairs: We expect the current work item can continue in tsvw, but we
do need to take the question of whether this item will finally obsolete
RFC6083. This is a question for the list to decide, and implies that it
is possible that a different work item could then update RFC693 in
future. It is also possible that at the time the current work item
becomes RFC the IPR and open source experience has changed during that
time.
- Martin Duke (AD): Open source has been important in the past. I see
3GPP needs the new spec. At the moment it seems unclear how RFC 6083 and
this will coexist, but that doesn't need to stop progress. There doesn’t
currently seem to be much enthusiasm for writing a separate update to
RFC 6083. We do need to make progress.
- Magnus Westerlund: I don't think it is impossible to have two
parallel version, and the policy and startup will define which version
is used. (Extra slides decribed some future issues for the ID, but were
not presented, which will be discussed on the list.)
- Chairs: In the future, the IETF will need to do security maintenance
of any security-related IETF protocol, so if we finally decie to leave
RFC 6093 still as an active RFC, we can expect a minor update to be
needed. We will ask the WG as a whole after this meeting to seek an
acceptable plan to take this forward.

3.3 Greg White: L4S Operational Guidance
draft-ietf-tsvwg-l4sops
- There was discussion on whether this ID is ready to publish, and then
whether the WG should publish sooner than the current milestone. The
original plan was to keep this as an ID during the L4S experiments, teh
current text seems ready, is this still the plan?
- David Black (individual): I think we should publish this as an RFC
with the L4S or immediately after their review by the IESG, and then
immediately begin work on a subsequent “bis” document to collect lessons
learned from the experiment as we learn them. I think this is stable,
and getting this seen by people is good.
- Martin Duke (individual): How long does this L4S experiment continue?
When is the experiment over? The L4S experiment will continue until the
IETF publishes a PS. Are we expecting operators to be able to deploy
this in months or years?
- Greg White: I would anticipate a small number of years before we have
significant experience, not weeks or small numbers of months.
- Mirja Kühlewind: Agree, that we should publish now.
- Chairs: We would like to see this document completed and will ask the
WG after the meeting if there is agreement to publish this as an RFC
sooner, and then open a new .bis document if this is needed to collect
the lessons learend.

Session 2: 10:00-12:00 Friday 25th March (2 hours)

.4. Agenda Review
Note well
Note taker: Reese Enghardt (Notes were updated by meeting recording)

.5. Transport : DCCP
5.1 Markus Amend: MP-DCCP
draft-ietf-tsvwg-multipath-dccp
- Lars Eggert: Have you started discussing with Linux Netdev community
about upstreaming?
- MA: At the moment, it is out of tree, which makes it easier to get
some first experience.
- LE: For MPTCP we could not really use it because we needed to build
custom kernels, and if you want to run it with containers, it needs to
be in the Linux kernel by default
- MA: We are aware, but we need resources. Karlstad University is also
working on a user space implementation. I am not sure how mature this
is, but may be next IETF I can present something?
- LE: This should not stop the IETF from working on MP-DCCP.
- Michael Tüxen: IPR needs to be considered: What is the relation
between this IPR and the open source code?
- MA: That was declared before WG adoption. It targets being a part of
Linux network stack, so it is GPL based.
- MT: So, no IPR. Thanks.

Tianji Jiang: This is one study topic in 3GPP, including multicast and
how many paths can be supported.
MA: We support as many paths as are available, no limitations.
TJ: For MP-DCCP, will you support a proxy?
MA: This maybe somthing that needs to be clarified in 3GPP, at the
moment. From the draft, there is no support for this. It is also not the
idea of the MP-DCCP protocol.
TJ: OK, thank you.

Chairs: There is an open side-meeting after the current TSVWG to provide
additional information about the possible directions for IETF work to
support the ATSSS work.
David Black: Question in chat: Is there support for remote
participation?
GF: There is no remote participation support for this meeting. The
organisers will make notes and distribute slides. This is an information
distribution meeting, no decisions will be made.
Martin (AD): No remote support for sidemeeting is policy by IETF. Other
means can be used as the organisers see fit.
Toerless Eckert: Is this TSVWG endorsed?
GF: It isnot endorsed, it is only related. We just booked a side-room
with space.
Lars Eggert: Someone could fire up a webex or zoom. Gorry is right
though that the IETF does not provide this.

.6. Differentiated Services

6.1 Ana Custura: DSCP Considerations
draft-tsvwg-dscp-considerations

Martin Duke: Thank you for doing this draft. The grid of DSCPs that you
showed makes it clear we're burning the last useful codepoints, which is
pause for reflection. I encourage you to take this presentation to
OPSAREA. You may not reach the people who are still bleaching the DSCP
(or ToS priority) because they are usually less connected with the IETF,
but still this is a good entrance point into that community.
AC: We will revise this draft to the next version.
MD (AD): Are you proposing an additional draft? What is the new draft?
GF (as individual): The current work item is Informational, and that
seems appropriate until we start clarifying that this RFCs are updated
based on current practice. Maybe Brian Carpenter's recent post on the
mailing list was a useful to start about how we should think about
codepoints after 20 years. Maybe this could be a document pair, with the
recommendations as BCP or PS, that could be a change for DiffServ
architecture. It would be good to get discussion on the data that Ana
had. I don't think this blocks the NQB work item, but then we will not
have many codepoints left.
MD (AD): Please engage the operator community to address the bleaching
situation. We made need an idea to increase the number of usable DSCPs.

GF (as individual): Note the non-IANA assigned DSCPs are local use and
experimental. There are various network usages: Some networks just pass
the DSCP without making changes; Some make changes that are
historically-based, but potentially harmful. Some have configured
policies.
Rüdiger (RG): I am configuring bleaching at my employer. I appreaciate
work on an update to the existing drafts, and contributed a lot of my
expierience. I would like to see some defaults for the access (optimize
for performance, latency, bandwidth). May people come and ask exactly
for that?
GF (as individual): We can include Rüdiger's comments in the draft.
RG: If your document updates the DiffServ spec, we appreciate that.
Jonathan (JM): I want to express support for some BCP or diffserv-RFC
update, discouraging the use of bleaching in the network in some
effective way.
GF (as chair): Ana, please revise this draft, consider presentation to
OPSAREA, also let's probe all about what we mean to see if we can get
consensus on DSCP recommendations. We expect these can be different
timeframes.
Bob Briscoe: You should also look at the IEPG meeting on Sunday. Talk to
Warren Kumari or Lars Eggert. They meet every Sunday arroud IETF
meetings.
Ana: Please introduce me.

Subir Das: Do we need an operator survey? Will the recommendation come
to TSVWG or somewhere else?
GF (individual): We can launch an operaters survery. They have worked
quite well in the OPSAREA. Any diffserv recommendation will come from
this working group. Other groups will have to be involved when we change
the reommendation.
SD: That recommendation will imply a new look at DiffServ architecture,
right?
GF: It looks like it might. DiffServ was implemented 20 years ago to
make something work when nothing worked. Now we have something working,
we might want to make (small) changes to make it work well.
Jake Holland: I echo Martin, this presentation was really good. I would
encourage you to take the data also to MAPRG as a measurement
presentation. Not just the operator community, also the rest of IETF
community and research community will benefit from this.

6.2 Greg White: NQB
draft-ietf-tsvwg-nqb

Gorry Fairhurst (Individual from the floor): Thanks Greg. I think the
whole DSCP thing can be dealt with. I like the change of the two
registry names, that's probably right. I wonder if we should add some
text about why we are doing this, and also to clarify what the use of
the aggregate or low numbered DSCP (5) means when we later have
allocations in the same column in Ana's table. They don't affect NQB,
but may affect the SHOULD/MUST language around remarking.
GW: Right. I agree we should get conesus on the SHOULD/SHOULDN'T
wording. Also what is the end-to-end philosophy going forwards? Is
Diffserv AS specific, or for end-to-end use?
DB (individual): For the history - Diffserv tried to be both, allow
individual networks to configure locally, the end-to-end did not work
out all that well though.
GW: David, do you think we're near WGLC? Looks like framework is close
and we have to pin down text around code points. Anything else we need?

DB: That's about it. Will want to take a close look at what we want to
call these two new codepoints.
Sebastian Moeller (SM): What is the timeframe for the DSCP 45
assignment? If NQB becomes popular and supported ubiquitously, keeping
DSCP 45 seems not needed - this is only to fudge NQB into
existing/future-legacy WiFI deployment?
GW: What is the timeframe?: Applications mark the traffic with NQB while
it is not formally assigned, one developer needs to use an alternate
codepoint. I think there is demand for the codepoint sooner, rather than
later.
GF: Maybe part of the question is how long do we need the allocation
for? e.g.: Do you think DSCP 45 will work end-to-end across the Internet
in 5 years time? Will all the WiFi will be updated within 5 years?
DB: Which version of "NO" do you like to hear (on all WiFi gear being
updated)?
GF: We don't know what's being adopted by who, the WG just makes
suggestions.
David: As the draft is written, DSCP 45 is long term, because that is
recommended.
Chairs: Greg, please work with the Chairs formulating the questions so
that we can clear this issues up, and be ready for WGLC.

.7. Transport : UDP

7.1 Tom Herbert (TH): Checksum Offload

Toerless Eckert (TE): Is there any good data on what the biggest reasons
are for checksum errors and their probabilities? The use case always
escaped me from the analysis.
TH: Yes, there has been a lot of work, beyond scope of this
presentation. The checksum will detect all 1-bit errors, stronger than
parity, but weaker than a CRC.
TE: I was just wondering what is the most simple answer to what actually
happens and how to protect against it. What's the source of the errors
that it does protect against? In UDP we had discussions on when the
checksum can be omitted. Coming from network side, I never looked into
end-to-end, which is the expensive part.
TH: I suspect it is in the network. Modern computers have ECC memory.
Memory corrupution is more likely, not super likely.
For security purposes. Ethernet CRC has much higher protection. In UDP
options the checksum can differentiate between standtard and
non-standard use case. This can still be useful, but maybe not expected.

Richard Scheffenegger: We have checksum errors on the order of once a
year, with fairly old network gear. When you have undetected multi-bit
errors, which then show up in higher layers of the protocol, you do have
CRCs that will flag a bad transport.

Jonathan Morton: Observation: The checksum delta technique is very
useful for updating fields in the IP header for example that commonly
get changed en-route. The ECN field. There can be bugs in the
implementations. Certain packets have incorrect checksums while the rest
are correct. If you use this technique, make sure to get it right.
Problems can be hard to notice. An incorrect checksum has the same
effect as a dropped packet.
TH: Yes.
GF: Does the set of changes which we put into the UDP checksum make it
easier to offload, since the last revision?
TH: When the stack basically creates a packet it will know where the
checksum is. It is not super critical for it to be in a fixed location.
But a device may also have constraints. It is likely that the offset may
have to be within the header of the packet. Devices may only have 1 byte
offset fields. Real estate in the transmit descriptor is very expensive,
we assume that checksum is 2 byte alignment, of 256 values - we can
double that, the checksum can be up to 10 bytes into the packet. Having
a fixed location is not as relevant as making sure this is aligned to
offset of 2 bytes and keeping it in the header of the packet. Obviously
for software stacks this is not so relevant. There may be instances on
older systems that do not like unaligned operations. All currently
defined protcols have the checksum start should be 2-byte aligned to
avoid any issues.
Gorry: Yes, I think that alignment is in the current draft?
TH: Yes. There might also be a misnomer in the context of UDP
encapsulation and options. When someone makes the checksum optional,
that is not necessarily saving cycles or performance, it can make this
worse. UDP encapsulation where RFC 6935 or 6936 allows checksum errors
even for IPv6 and states that a checksum is required, from a host point
of view. If someone sets checksum to 0, we still have to compute the
checksum when there is an embedded TCP packet: we still have to offload
the checksum. In some legacy checksum algos we still have to go through
the whole calculation on the host, which is where performance drops. The
checksum we absorbed on the host, there is little performance gain to
disabling the checksum from host perspective. The benfit is if devices
like routers are communicating and terminate IP, and then they may not
have any offload.
Gorry: Presuming also when they are doing re-encapsulation.
TH: We have absorbed the cost of a TCP UDP checksum, that's not a
current problem we have. But as new protocols are introduced, how do we
continue to leverage those? This is where implementation becomes most
important.

7.2 Joe Touch (proxy Chairs): UDP Options
draft-ietf-tsvwg-udp-options
Tom Herbert: What is the state on the implementation of this?
GF: This is a question to Joe and the WG in general. I have not heard of
implementation for the latest version on the mailing list, please bring
it there. The general concept was implemented in an earlier version. Tom
Jones will speak on DPLPMTUD, who implemented this outside of mainstream
to demonstrate it's feasible. This WG would love to see hackathon
activity and implementations.
TH: That's what I was expecting.
Chairs: When we have a complete revision that is coming, we expect
document to be stable and at this point we invite people to review this.
Tommy Pauly and Colin Perkins have agreed to do an early protocol review
from the transport perspective. This is a new transport protocol, we
have done this type of review before for DCCP and SCTP. We then expect a
further revision and then WGLC. Please provide comments.

7.3 Tom Jones/Gorry Fairhurst: DPLPMTUD for UDP Options
draft-ietf-tsvwg-udp-options-dplpmtud

Chris Heard: I have read this document, I did not post comments to the
ML because I did not have any, it's really good. Did you envisage that
the DPLPMTUD could be implemented as a shim layer on top of UDP options,
rather than be integrated into it? That would influence what we specify
in an upper layer interface? This has not yet gotten sufficient
attention and scrutiny.
TJ: I am not really sure what is the question: If you are using the UDP
options, then there is not really a shim. The service to the upper layer
is a value that is offered to the application. I do not know how you see
the shim. Maybe you can clarify further?
CH: I will write the question in an email...
Chair: This work seems nearly finished. Please review and give comments
on this document.

The meeting closed. Please continue discussions on the tsvwg list.