Minutes IETF99: tsvwg

Meeting Minutes Transport Area Working Group (tsvwg) WG
Title Minutes IETF99: tsvwg
State Active
Other versions plain text
Last updated 2017-07-26

Meeting Minutes

   AGENDA for TSVWG Meeting at IETF 99, Prague, Cz
 WG Chairs: Gorry Fairhurst, David Black and Wes Eddy
 Note Taker 1: David Dolson
 Jabber Scribe.

Session 1: 13:30-15:30  Tuesday Afternoon Session I

- David Black discusses status slides
- There is an open issue and significant changes are going to be required.
Spencer Dawkins (AD): I like the Chunk draft. What does the ECN experimentation
draft need to say? David B: ECN makes the NS historic. The new text will remove
the IANA registration for TCP NS field. Gorry: When will this revision be
ready? David: Next week. Spencer: The ECN draft is a 3GPP dependency.

David: The SCTP n-Data draft is the last of the webrtc drafts.
Bob Briscoe: There will be another dependency for an AD action wrt to a
document status change. David: Spencer has an action to do a status changes
document fro ECN-Nonce. Spencer: OK, thank you. Public humiation works. David:
The PHB LE mappings are stable; I hope to resolve and send to last call. David
announces WG the adoption of the FEC framework drafts. These do not justify a
new wg. Gorry: Please talk to Gorry if interested in transport-header-encrypt
or PMTUD drafts. David: TSVWG'ers please also go to intarea mtgs for Tunnel
MTU, MPT or SOCKS documents. Gorry: Or speak-up to Chairs or mailing list if
you think there are Transport issues for these drafts.

1. Review Agenda (WG Chairs)
- No agenda changes

2. Status/updates (WG Chairs)

  2.1 Tunnel Congestion feedback
  draft-ietf-tsvwg-tunnel-congestion-feedback --- WGLC more work needed.
David: This needs significant work to frame an example use.

  2.2 ECN Experimentation
  draft-ietf-tsvwg-ecn-experimentation --- WGLC concluded.
David: This will be updated to addresses the IANA issue.

  2.3 SCTP I-Data
  draft-ietf-tsvwg-sctp-ndata --- WGLC concluded.

  2.4 DS IEEE 802.11 — WGLC Summary
Tim Szigeti talks to slides
- The 802.11 mapping is already in wide use in Cisco & Meraki APs and Apple
devices. ~800M devices using recommendation. - We will avoid the overloaded
word "trust". - The LE PHB PS will obsolete RFC 3662, and thus have a cascading
effect on RFC 4594 and also this PS - Please review. David: Depending on
consensus on the DSCP decided for LE, the WG may reference the LE mapping,
rather than update this document.

  2.5 UDP Options - Adoption
Tom Jones: I have a working implementation in FreeBSD; I would like to interop
with other operating systems. David Dolson: Was the old FreeBSD code OK for
receiving datagrams with UDP options? Tom Jones: Yes the recieve code was safe.

  2.6 Related work that may be of interest:

3. WG Drafts

WG Drafts - Diffserv

  3.1 Roland Bless - LE PHB
Roland does not think 2 DSCPs are required for LE.

  3.2 Chairs - Discussion on appropriate DSCP for LE
- Short reports on observed remarking behaviour for proposed LE DSCP (please
contact chairs) Raffaello Secchi presented a study about DSCP  LE codepoints
using PATHscope & Edgetrace. DSCP 2 might not be good because of bleaching
of upper bits in deployed networks. Many other DS classes would be mapped to
LE. This effect is worse than mapping to best-effort. 16% ToS bleaching or 4.7%
ToS bleaching in different scenarios. Fred Baker: There are 8 values with top 3
bits set to zero. The odd values are for local use. Gorry: Half of these are
local use, the registry says the other could be allocated by IANA if the IETF
has need. Fred: The value we would like to have in the upper 3 bits is 0, so
this might allow a DSCP of 2/4/6. I do not see the real difference. I would
rather tell people not to bleach the DSCP. Gorry: This advice to people
configuring routers is still correct.

Tom Jones: SSH is using code point 2 and 4, one for bulk transfer, one for the
rest. This is squatting on the code point. David: It would be good for someone
to fix that, but it is not what is steering this decision. Michael: Is the
bleaching only to zero, or to other values as well? Raffaello: There is
beaching to zero, but that is not the issue. In this case the dominant
pathology that impacts this decision is ToS bleaching, and a small number of
other DSCP changes unrelated to original values (i.e., operators assigning all
traffic to a specific DSCP). Michael ?: This is probably not intentional
remarking. Brian Trammel: It looks like DSCPs are used inside the network, but
they could leaks out. Brian: How many ASes were traversed by measurements? RS:
30 in these tests. Brian: So, we're talking about 10^-4.  Can we just make
phone calls to the ASes with broken routers? David Black: IANA registry: code
points in pool 3 ending in 01 may be utilized for future standards allocation.
Gorry: I have a question: Is this going to be better than CS1? Rolan Bless: The
term "IP precedence bleach" is more accurate. We should stop working around
broken configurations/implementations. Why is SSH broken? David: On Michael's
comment, operators might not be clear on what config their equipment is doing.

David (Chair): Can I see a show of hands straw poll: how many think they
understand the issue? (About a dozen). David (Chair): How many think we have
enough info today? could we stick with DSCP 2 or pick an odd-numbered one? How
many people who understand the issue think we have enough info to make decison
now? No hands raised.

Bob Briscoe: It could be a mix of "No" and "Not sure".
David: The lack of raised hands is important.
Roland: The odd code points would be worse than 2, given ToS precedence
bleaching. David: The reason to not choose 2 also applies to not choosing the
other DSCPs. Tim Chown: We do not know if people will fix their configurations.
 Why did we pick 2? David: The even numbered code points are for standards
action; others for local use. Tim Chown: I am inclined to go with codepoint 2.
Brian Trammel: I did not raise my hand. Did you do Pathscope measurements for 1
and 5? Tom: I have Edgetrace results for DSCP 1 that show this is as expected.
Gorry: PATHspider shows 1 gets thru network. Not bad from traversal point of
view. Brian: For the SSH problem, can we just do a pull request in SSH code?
Tom: Yes. However, the pull request is ~12 years old. They will probably never
take it. Tom: The ToS precedence bleaching behavior is the same as for 2 but
without the peril of 2. David Black (Chair): We cannot make a decision now. We
will follow-up on the list

WG Milestones Review
Tim: The 802.11 milestone should be noted as "Proposed Standard", not
Informational. David Black: This is a typo - we will fix. Gorry: I would like
more info on the LE DSCP from peoplw. Raffaello, can you do more measurements?
Raffaelo: Yes. Gorry: Let's get to the bottom of it. Speak to Raffaello if you
also wish to make measurements of DSCPs. David: Can get NAT support publihsed
by the End of Year? (yes) David: For L4S? Bob: Maybe fix a milestone before
Sept. 2018. Essentially the drafts are finished, except TCP-Prague; the drafts
are in holding pattern. Gorry: We can do an early WG last call to get
consensus, even if we freeze and do not immediately publish. David : UDP
Options -- We are waiting to hear about implementation work. David: Is June a
possible milestone date for the FEC drafts? (yes)

  WG Drafts - ECN

  3.3 Bob Briscoe - Guidelines for Adding Congestion Notification
  Propagating ECN Across IP Tunnel Headers
We want New Radio to support ECN? And therefore L4S.
David: This also came up at 3GPP liason meeting. (see Liasion slot in TSVWG on
Thursday.) David: We hope to have published very soon.

This exists so the IETF community can update other proposed standards.
Bob: In Problem#1 slide the figures are wrong.
Bob: "NSH" is vague, not applicable.
Bob: We did not (yet) find any evidence of automatic configuration of GRE.
Gorry: Does anyone in room know cases where GRE is automatically configured?
e.g. in VPN usage? Brian Trammel: If BANANA is chartered, a new automated GRE
tunnel setup might show up, at least we have this list to start from. Jake
Holland: AMT RFC7450 is missing from list. Bob: I will look. We only need to
know about shim-types. Christian H: Is it conceptually hard to handle ECN in
Teredo? (No.) If we specified it, would it be updated? Dave Dolson: Do I
understand this is about finding inner header after the Ethernet E.g., in
CAPWAP? Bob: We need to propagate both ECN and CE across layers. Christian: In
Teredo, an operator is not exactly the end-user.

  WG Drafts - L4S

Gorry: We need people to activity participate in these L4S drafts - please
comment on list, especially on the architecture ID.

  3.5 Bob Briscoe -  L4S Internet Service: Architecture

  3.6 Bob Briscoe -  Identifying Modified ECN Semantics
ECN is used as a default classifier, but there may be other classifiers. E.g.,
ECN combined with other fields of traffic (e.g., IP address). Adding hooks in
Linux to let people add other classifiers. But advantage of the default is it
being end-to-end eventually. David Black (from floor): DSCP classifiers help an
enormous amount for incremental deployment. Bob: The more identifiers you add
to the classifier, the less incremental the deployment can be. Bob: There are
business motivations... David: Some wording changes should be added to the
draft to indicate it is optional. Andrew: We cannot see how to test without
other classifiers. So if we do not add it, someone else will.

Some people are still using the entire ToS byte for load-balancing. This is not
best practice. Gorry: This is something people have to fix. David Dolson: In
suggest putting ECN-bleaching (or otherwise bad behavior) in tools like
traceroute, so we can measure this easily. Andrew: There can be reordering when
entire ToS field is still used for load-balancing entropy (e.g. ECMP). Multiple
router vendors have support for both currently specified methods and the legacy
byte-based methods. Many devices still have wrong defaults. These need to be

  3.7 Koen De Schepper - DualQ Coupled AQM for L4S
Gorry: BBR isn't in any working group. But we should of course  pay attention
to what is happening in the real Internet. Koen: Please test and try.

Session 2: 18:10-19:10  Thursday Afternoon Session III

 4. Agenda recap (WG Chairs)
Note Takers: Roland Bless & Dave Dolson

Liaison Notices (WG Chairs)

Georg Mayer
No clear view on requests for 3GPP, still building up the requirements for 5G.
Question in Q&A about whether someone wanted to not consider ECN in 5G,
then please tell me, I haven't seen things. ECN will be in 5G. We will come and
speak when any questions arise in 3GPP that are relevant for this group.
Spencer (AD): Thank you for coming to talk to us.

 5. WG drafts - Transport Protocols

   5.1 Michael Tuexen - SCTP NAT Support
Gorry: Let's try to put IPv6 into this document and see what happens. This
should be ready to WGLC soon.

   5.2 Michael Tuexen- RFC 4960 Errata and Issues
Gorry: Can you remind us about the standard status of related RFCs (6096, 6335,
7053)? Michael: There are no new features, just clarifications. David B: Are we
referencing the RFCs or copy/pasting? Michael: New text from the SCTP
dependencies, but citing normatively the BCP on IANA procedures.

Michael: There is an opportunity to go for Standards track and progress to
Internet Standard. Gorry: This document will provide a check list of changes
for Spencer that needs to be reviewed. Spencer: The process for progressing to
full standard is OK with me. Gorry (as Chair): Does anyone think we're missing
anything in SCTP? (no one answered)

 6. WG Drafts - FECFRAME

  6.1 Vincent Roca - FECFRAME

  6.2 Vincent Roca - RLC FEC Scheme for FECFRAME
Vincent: I am unclear whether we should add one or two more extensions, e.g.,
also could consider sparse versions. David Black: It is good to see that
Marie-Jose did reviews. Others, please do comment on the list. Vincent: We hope
to get more reviews from the network coding RG. I already asked them. Jake
Holland: Are there implementations available? Vincent: Yes.

  6.3 Michael Tuexen - UDP Encapsulation of SCTP
Gorry: I confirm this process. This document will die, and the working will
consider adoption of the document that replaces this. Jake Holland: Was the
decision to change the heartbeat based on measurements? Michael: I just looked
at what other protocols do (15s). Also applications can control this. Gorry:
Should refer to the UDP Usage Guidelines BCP. Michael: OK.

Gorry: please comment on the list:
    - Please make measurements and have thoughts about the effect of LE
    codepoint selection. - ECN encaps and shim have been talked about a lot at
    this IETF, they may be ready soon to progress. - L4S arch needs eyes from
    anyone who has interest in ECN and L4S in particular. - Please read SCTP
    rfc4960-errata if you have intrest in SCTP.