Minutes IETF101: tsvwg
minutes-101-tsvwg-00

DRAFT - to be checked against audio archive.

IETF 101, TSVWG Meeting Minutes
Chairs: Gorry Fairhurst, David Black, and Wes Eddy.

Thanks to Richard Scheffenegger and Paul Congdon for assistance in taking notes.

1550-1750  Afternoon Session II

1. Chairs Update:

  Status of published RFCs since Singapore include; 8260, 8261, 8311 and 8325.
  Two drafts are expected to be submitted to IESG.  These include SCTP errata
  and DSCP IANA process changes.  We expect 5 drafts to go to WGLC.  There are
  7 other WG drafts that are in progress; SCTP NAT, a set of L4S, UDP options,
  Tunnel congestion feedback and Datagram PLPMTUD.  There will be 2 related
  drafts discussed that are on the TSVWG agenda.  There are 3 drafts not on the
  TSVWG agenda.  In the INTAREA WG there are 3 drafts that are related; tunnel
  MTU, fragmentation and SOCS v6.

  Milestone updates and review of WG Progress: Feedback on
  draft-ietf-tsvwg-tunnel-congestion-feedback Update on ecn-encap-guidelines

  SCTP NAT draft should be ready for WGLC at/after the Montreal meeting, so
  October is a good new milestone date for it.  Confirmed by Michael Tuexen.

  Tunnel Congestion Feedback - Bob Briscoe reported that Donnald Eastlake and
  Andy Malis have become interested in using this for Service Function Chaining
  (SFC). They were pointed to this for load balancing across service functions,
  and want to help.

2. Announcements and Heads-Up

2.1 Liaisons

2.2 Other Drafts Related to TSVWG
    draft-olteanu-intarea-socks-6 (For info - Please discuss on INTAREA list)
    draft-saldana-tsvwg-simplemux (For info - Please discuss on TSVWG list)
    draft-herbert-fast (For info - Please discuss on TSVWG list)
    draft-han-tsvwg-cc (For info - Please discuss on TSVWG list)

3. Transport and Network

3.1 Gorry Fairhurst: IANA Action for DSCP Pools
    draft-ietf-tsvwg-iana-dscp-registry (In WGLC)

Spencer Dawkins (as AD):
  (regarding discussion about shortening the name of the draft)
  The current name is meaningful, it is ok.

Roland Bless:
  Replace last part with "requires IANA actionÓ.

Bob Briscoe:
  When you say there will not be any negative impact, is there no private
  use of this pool of DCSPs?
Gorry Fairhurst (as author):
  The purpose of publishing this is to ensure people know the change.
  I donÕt think existing use is harmful, but there is a change, people
  using local use DSCPs should already be aware that they may be
  used by others.

Spencer Dawkins:
  If those networks using the local DSCP, don't they shoot themselves
  in the foot when DSCPs are moved to standard?
Gorry Fairhurst (as author):
  They should not if they adhere to diffserv specs.
David Black:
  Diffserv behaves best with perfect configuration at the diffserv perimeter.
Spencer Dawkins:
  I look forward to shepherd writeup, that should call attention to
  any possible impacts.
Roland Bless:
  Should not be a big issue, as there was a indication these DSCPs (xxxx01)
  were ready marked as possible use for future standards action.
  Local remapping is always possible.

3.2 Roland Bless: Lower Effort PHB
    draft-ietf-tsvwg-le-phb

David Black:
  (Asks for any final feedback on the decision to allocate the DSCP).
   I see no objection to use of codepoint 000001 as the recommendation
   here for the LE PHB (to be confirmed on list).
Bob Briscoe:
  Text current says:
  With respect to the use of LE traffic by different styles of congestion
  control. The text says you don't want to harm people, you shouldn't
  harm others traffic.
  I think this text should  describe what happens if there would be harm.
Gorry Fairhurst (from the floor):
  I prefer an approach that says SHOULD use a less than best effort
  congestion control (e.g., LEDBAT) and explain why this is really desirable.
  That is, if you donÕt, there may  be unwanted or unexpected interaction
  with other traffic. That would be better guidance. I (personally)
  would be reluctant to use MUST, but really IÕd like to see people do this.
David Black:
  From an operator perspective SHOULD vs MUST irrelevant, an operator
  has to defend the service regardless of RFC.
Bob Briscoe:
  The text just doesn't make sense in the current wording, whether LE traffic
   is going to do harm should be written clearly.
David Black:
  The operator concern is not for a singular flow, but for the aggregate.
Gorry Fairhurst:
  Bob, please send example text to list, to help find better wording
  Bob will send text about whether use of a less than best effort transport
  (e.g. LEDBAT) ought to be a MUST or SHOULD requirement for use of the LE PHB,
  and David will comment on this.

Tunneling:
David Black:
  Recommend not updating the document about 802.11 mapping, it is pretty
  clear this new DSCP maps on WiFi.
Roland Bless:
  The ID with guidance on WebRTC (in RFC-Ed queue) needs to be updated. This
  ID discussed CS1 and that advice will become obsolete.

Spencer Dawkins (as AD):
  Updating a draft in the RFC Editor queue, is possible to change to the
  new recommended DSCP.
  I will drop note to RFC Editor, and ask how best to do this.
Gorry Fairhurst:
  The Chairs should let WEBRTC people know of the consensus here.
  We will let the IETF and W3C RTCWEB/WEBRTC groups know
  and recommended the DSCP change.

3.3 Anais Finzi: Priority Switching Scheduler
    draft-finzi-priority-switching-scheduler

(After discussion with the authors this is headed to the Independent Submission
Editor, with inputs from TSVWG.)

The scheduled talk did not occur in Singapore.  The hoal is to make the AF Class
more predictable.  This scheme changes the priority of the traffic based on
credit thresholds.

Roland Bless:
  Is EF not impacted? Not quite sure about that conclusion.
  EF has definition of an error term.
Anais Finzi:
  In our simulations we didn't see any impact.
  The maximum impact is at the maximum frame size.
Roland Bless:
  I will check the paper, thanks.
David Black:
  Roland volunteered as a reviewer of draft.
Ruediger Geib:
  This proposal would remove the req'd policer on the EF class.
  Would this conflict with RFC3246?
(unknown):
  Ao far, the IETF did not specify any schedulers.
  My question is: Is this standard track?
David Black:
  No. This is heading for an Independent Submission.
Ruediger Geib:
  I am not sure if I want to have that scheduler on a 100G link.
  I can review the draft/paper, but I'm not an expert on scheduling.
Roland Bless:
  Early to configure? To set these 3 parameters...
  Paper shows how to translate the current config into the corresponding
  set of settings in PSS. This can be simplified by removing some, but not
  optimal.

Roland Bless and Ruediger Geib agreed to review the draft, and David will
send an announcement to the list requesting other reviews.

3.4 Datagram Path Layer Path MTU Discovery
  Tom Jones  : Datagram PLPMTUD

David Black:
  Have you looked at the draft in INTAREA on PTB signals?
Tom:
  Yes, we have read and sent a few comments, this does not conflict.

Michael Tuexen:
   SCTP can do verification, not just on the 5-tuple.

Matt Mathis:
  I will read this draft. The impact of authenticating messages
  from the network is much broader than just PMTUD. It is good
  to check if there are new solutions. In the absence of authentication
  I agree that messages are just advisory. You have to be able to be
  able to tolerate bad cases.
Gorry Fairhurst:
  What about bad information in a PTB message?
  Are you saying there can be an advertised link MTU much smaller than
  the actual path MTIU?
Matt Mathis:
  There were DOS attacks trying to reduce the PMTU.
  We also did see cases where the two MTU bytes were swapped.
  ??? Jumbo discovery, buffer nic

Magnus Westerlund:
  It is very important to make this robust.
  I will review this draft.
Michael Tuexen:
  When working with SCTP we found a middlebox that just gave
  some random number, instead of the VTAG.
Eric (Akamai):
  We have been running into a wide range of MTU issues.
  This is a nice optimization. How does it interact with load balancers?
  This is important work.
Tom:
  The method only takes PTB as advisory, we plan in the next revision
  to add a probe method to verify if the actual PMTU is larger than the
  advertised link MTU.
Gorry Fairhurst (as author):
  Please tell us about these issues.
  Load balancing (i.e., use of more than one PMTU) was one motivation
  for making it robust - we want to get this part right. For this, we
  need some tales of what actually happens in the wild - please talk to us?

???
David Black:
  How does this work relate to the transport work in QUIC?
Spencer Dawkins (as AD):
  I hope we can make progress on using this in QUIC, although the starting
  point may be for QUIC to pick a PMTU number at first and just fallback
  if this fails to be supported by the path.
  We know PMTU using ICMP is broken. Anything that is doing this better
   seems like a good thing.
Lars Eggert (as QUIC Chair):
  Most current QUIC implementations do something very simple,
  a basic test/fallback. Having a functional PMTUD is not strictly required.
  If this scheme is not too complex, some implementers might try this.
  After we do a v1 of the QUIC spec, we will do v1.1 shortly after.
  This might go into v1.1 or v2.
David (shows the state machine).
Gorry Fairhurst (as author): Actually the full algorithm has many states
  but once we have this, we can profile a simpler algorithm for
  applications that do not need this.
Tom Jones:
  There are two parts needed: First we need some small paragraphs in this
  TSVWG ID to describe requirements and features of each protocol.
  This should be straightforward for the use of QUIC, there is some text
  there already. Review by a QUIC subject matter expert would be great.
  This would make sure nothing is inconsistent is in this draft.
  - We can also help with the actual text for how to implement this
  in a QUIC transport - and that could be in a QUIC WG draft.
David Black:
  I would like QUIC to be upwards compatible with this.

Michael A:
  Talking of Jumbo frames, my conclusion, is we all need this.
  Network operators should support PMTUD, but they often do not.
  TCP still works if network gear is in properly configured.
  Should this become a BCP? Saying we ought to do this?
David Black:
  Plausible with much more experience. Qualitative useful, so
  that the BCP is correct.
Michael A:
  I also want some telemetry, something that tells me this has gone
  active, to help me for troubleshooting.
Tom: An entry in the syslog?
Michael A: Yes that sort of thing.
Spencer Dawkins:
  A BCP - implies more running code, more experience is right.
Eric Akamai:
  There is currently a risk that we don't get to a state that is good and so
  the endpoint remains in a very bad state - just like clamping MSS low
  enough that it is bound to work, but way smaller than optimal.
  If we do not add this as a default, then jumbo frames are never going to
  happen.

Michael A:
  I am most interested in making this work, and logging the event.
  I don't want to give a bad experience to customers when probes failing
  and impact their traffic. I do want Blackhole detection.
Michael Tuexen:
  There are differences when using PLPMTUD with TCP. TCP uses probe packets
  that carry user data, this changes retransmission and the CC state. The TCP
  PLPMTUD is much more complex. In contrast, this datagram version here has
  the assumption this is done without using user data, so probe loss is not
  something that impacts CC or retransmission/repair logic.

??? Timescale ???

3.5 Bob Briscoe: ECN transport
    draft-ietf-tsvwg-rfc6040update-shim

(This draft is now ready for WGLC, and will be WGLCÕed with the second encaps
draft)

Tom Herbert:
  Are there any IETF shims that got it right?
  All have their own issues. If you do it when you first design it,
  it is easy.
Bob (points to table slide).
Philip Eardley:
  Let's make this a management problem. My view ECN is an inter-operator thing.

3.6 Bob Briscoe: ECN & L4S
    draft-ietf-tsvwg-ecn-l4s-id
    draft-ietf-tsvwg-l4s-arch
    draft-ietf-tsvwg-aqm-dualq

(Bob presented slides on L4S. No comments or questions from the WG).
(Bob presented a new individual draft on diffuser and L4S.)
  There were no comments or questions from the WG. This draft would be
  discussed in Montreal, to see if there was interest in this work.

4. Other presentations / New Work

4.1 Paul Congdon: Congestion Isolation in IEEE 802.1

Paul outlined proposed work in IEEE 802 on providing layer 2 congestion support
to switches and the possible interactions with other methods.
The IEEE will be making a possible decision in July.

??? Missing feedback ???

Michael A:
  How does this relate to routers?
  How often is the xon/xoff transition?
Paul : This is casically propagation time, and a threshold.
Michael A:
  Can the hardware actually scale to high speed links and support back to back
  frames of the order of 1 microsec?
  Is is feasible to xon/xoff of 10-12 packets?
Paul:
  We think hardware can provide solutions.
Pat Thaler:
  When the xoff is received, there might not be a packet to be sent.
  Most implmenetations set xoff to maximum and count on xon.
  Send xoff on high thresh, and watermark at low threshold send xon.
Pat:
  That is not the way it's generally deployed.
Bob Briscoe:
  What is the trust model?
Paul:
  This targets a single admin domain, probably a data centre. One administrator.
  Have you considered virtual queues, instead of thresholds for triggering?
  A virtual queue slows you down before you have to buffer. I know
  Broadcom/CISCO chipsets can utilise this.

Sowmini Varadhan:
  We don't like PFC, ECN mostly works. If E2E ECN works, this is not that
  important.
Mirja Kuehlewind:
  Congestion comes up if multiple flows share the same queue.
  How does the switch get to the bad flow?
Paul:
  Same way as an ECN mark for the offending flows.
  Probabilistically the signal should reach the correct source.
Richard:
  Is there granularity of flow detection, can other flows also get stuck into
  the same congested queue?
Paul:
  Yes, we are aware of this.

1750-1810  Beverage Break

1810-1910  Afternoon Session III

5. Transport Protocols and Mechanisms

5.1 Vincent Roca: FEC drafts
    draft-ietf-tsvwg-fecframe-ext
    draft-ietf-tsvwg-rlc-fec-scheme

  (These drafts are now ready for WGLC, reviewers are needed.)
  There were no comments on the final drafts.

  The chairs will look for volunteer reviewers, and will cross-post
  review requests to the IRTF NWCRG.

??? Missing outcome ???

5.2 Joe Touch: UDP Options (pricy by Gorry Fairhurst)
    draft-ietf-tsvwg-udp-options

??? Missing feedback ???

Tom Jones:
  Is there going to be more text to explain the options?
No, this is the January draft; int-area might be the better audience. Joe needs
revise draft to include the presentation.

5.3 Tom Jones: UDP Options Implementation

??? Missing feedback ???

Gorry Fairhurst:
  Joe Touch is willing to look at different sizes of checksums, should the
  TSVWG think that is useful.
Tom Jones:
  A 16 bit checksum is one less line of code, less code  and standard algorithms
  are good.
Gorry Fairhurst: Please follow-up with Joe on the list.

5.4 Michael Tuexen: RFC4960 Errata
    draft-ietf-tsvwg-rfc4960-errata

  (This talk presents updated following WGLC.)

Gorry Fairhurst:
   You note a change to the CRC32c definition. This if often referred to by
   other groups. What changed?
Michael Tuexen:
   This change is to fix code typos by changing definition to make it compile
   on all platforms, it is not an algorithmic change to the CRC32c itself.

  There were no further comments from the room. People are encouraged
  to check the corrections and report any issues to the list.

  The current version can now continue or AD review and IESG LC.

5.5 Michael Tuexen: SCTP NAT
    draft-ietf-tsvwg-natsupp

 There were no comments in the room. The authors have noted the new milestone
 and expect to work on this ID for the Montreal IETF meeting.

5.6 Gorry Fairhurst/Colin Perkins: Impact of Transport Header Encryption
    draft-fairhurst-tsvwg-transport-encrypt

Matt Mathis:
  Are you interested in speculation about what might happen?
  Could we propose one generic transport-agnostic header, that indicates
  embedded OAM across multiple transports?
  This would be useful for debugging and a partial solution to some issues.

  There are also issues relating to equipment that the stakeholders
  do not wish to tell people about - this makes it tricky.
  It may seem that some tools are duplicated, or other ways can be used to
  measure the network path, but people do want to have multiple tools to
  check the answer to the same question. This is needed so they can
  be sure what is actually happening.
  In-band OAM might be interesting as one of these approaches.
Gorry Fairhurst:
  This seems like something that is already possible in some networks,
  (GTP) but I agree this is interesting to find out more about, please
  tell us about this as ID editors.
Matt Mathis:
  OK, I think we should look more at a generic instrumentation shim.
Hannes Tschofennig:
  How much feedback have you had from operators and equipment manufacturers?
  I worked with operations and insight was often very hard to come by.
  On a different topic, tools based on machine learning are possible
  but can be problematic, as even more data was required.
Gorry:
  We received good feedback from many operators off-list. A key problem is
  knowing who needs what operational information. Very often transport
  information is used by people to debug equipment/configuration issues - to
  understand anomalies/health etc, and organisations as a whole do not
  care about content, only specific people need this.
  We are looking still for more people to provide feedback
Hannes Tschofennig:
  DDOS mitigation techniques are important, some rely on machine learning.
  Some approaches suffer more from encryption than others.
Gorry Fairhurst:
  True.
Colin Perkins (author):
  Think this is a interesting discussion. It would be wonderful to have
  a measurement shim. We would be interesting to look at different approaches.

Brian Trammel:
  The IPPM WG did publish an instrumentation shim, for replacing timestamp
  and IP ID in IPv4 networks. This use is not applicable in public Internet.
  This can be better than passive TCP monitoring.
  Some discussions in QUIC will drive us on different designs in this space.
  As a framing document, this ID should be adopted.
Al Morton:
  This provides a good view of what encryption has changed from the transport
  side. This is a useful scope. When encryption has costs, adding shims
  definitely adds very real costs too. It would be useful to quantify the
  complexities that are added here. I am happy to read the next revision of the
  draft.

Question on adoption:
??? Chair ???

Brian Trammel:
  I have a suggestion, we should aim at consensus on this one.
  By scoping to the transport layer, we may get around this.
  Adoption now, or in Montreal: I'm happy with both.
Colin Perkins (author):
  Things are not going to get better. QUIC is going to be deployed,
  and is using these kind of headers.
  At this time the bits that are exposed in QUIC are still changing, it is not
  fully stabilized yet, we need to understand these tradeoffs.

??? Missing Chairs comments ???

End of meeting.