Minutes for TSVWG at IETF-94
minutes-94-tsvwg-2

TSVWG Meeting at IETF 94, Yokohama, JP
WG Chairs: Gorry Fairhurst and David Black
Note Taker 1: Pasi Sarolahti

---- Session 1 (110 min scheduled out of 120 min total)

1. Agenda

2. Status/updates (WG Chairs) (15 minutes)

   Recommendations for Transport Port Number Uses (RFC 7605)
   draft-ietf-tsvwg-port-use

   DTLS Encapsulation of SCTP Packets (RFC-Ed)
   draft-ietf-tsvwg-sctp-dtls-encaps

   Quick Failover Algorithm in SCTP (in AD review)
   draft-ietf-tsvwg-sctp-failover

   NAT Behavioral Requirements Updates
   draft-ietf-tsvwg-behave-requirements-update (WGLC requested)
   [The chairs need to identify reviewers who will look at this during WGLC]

* David looking for reviewers -- no one in the room volunteered

   RSVP Multiple Traffic and Flow Specifications
   draft-ietf-tsvwg-intserv-multiple-tspec
   [This work is likely to be cancelled, unless new interest is shown in this
   draft soon.]

   RSVP Application-ID Profiles for Voice and Video Streams
   draft-ietf-tsvwg-rsvp-app-id-vv-profiles
   [This work has been cancelled due to lack of energy at this time, the WG
   milestone was removed.]

   Charter & Milestones

* Agenda bashing: Karen's SCTP tail-loss presentation has been moved to
Thursday, because she is waiting some more results for the presentation, UDP
magic numbers moved to Monday to compensate.

* Ari Keranen (as ICE WG co-chair): Announcement: ICE has a session on Thursday
morning, with transport related implications to be discussed, hopefully many
transport people will be able to make it.

3. WG Coordination (Activities related to TSV in other areas) (5 minutes)

   Chairs - Encapsulation Considerations
   draft-ietf-rtgwg-dt-encap
   [On-going in routing area (also work in Int Area on tunnels).]

   Chairs - The Benefits to Applications of using ECN (at IESG)
   draft-ietf-aqm-ecn-benefits
   [Follow-up after IESG.]

----------------------------------------

4. WG Drafts (WG Last Call completed)

4.1 David Black for Gorry Fairhurst - Network Transport Circuit Breakers (15
minutes)
    draft-ietf-tsvwg-circuit-breaker

On "Is RTP-CB still to be included?":
* Bob Briscoe: A network cricuit breaker is a third party, but the RTP-CB is
not, that's a fundamental difference. This needs to make very clear how it
differs.

* Colin Perkins: I disagree with Bob's characterization of the RTP circuit
breaker about being only a network circuit breaker, that is just one use case.

* Bob: Just because they have same name, doesn't mean that one is an example of
another. I think this draft must define much more clearly what the scope is.
The draft is unclearly written, the concept of a flow is not clearly defined.

* David's conclusion: The RTP-CB stays in, but clarifying text is needed - see
latest version.

On "What protection is needed for control communication?":
* Colin: The RTP-CB requires protection of the control information (there is
text about an authentication mechanism), I agree with review comment.

* Bob: I sent mail to the list this morning about the definition of a flow, and
about covering tunneled congestion feedback, but this is in conflict with the
other ECN tunneling draft. I think we should split the tunneling part as a
seperate work and make it more consistent with the other work.

-------------------------------------------

4.2 G Fairhurst / L Eggert - UDP Usage Guidelines (15 minutes)
    draft-ietf-tsvwg-rfc5405bis

* David suggesting dropping clarifying pointers to specific sections/documents
that are expected to be relevant for particular use cases (e.g., in routing)

* Lars was concerned about adding new stuff or restructuring. He just wants to
get this particular revision done to update the current position.

* Erik Nordmark: There are other encapsulation drafts that are in the same
space. We should synchronize between documents, and make sure these cite this.

* David: Can you do a quick cross-check to point out the issues? (Erik agreed)

* Lars: I propose we get the commenting done soon, at least before the winter
break.

----------------------------------------

5. SCTP Drafts

5.1 David Black for Michael Tuexen - Stream Schedulers and
    User Message Interleaving for SCTP (idata) (5 minutes)
    draft-ietf-tsvwg-sctp-ndata

[no comments, progress expected before next IETF]

5.2 David Black for Michael Tuexen - SCTP Network Address
    Translation Support (5 minutes)
    draft-ietf-tsvwg-natsupp

* Karen Nielsen has some editorial comments, but thinks the solution is ok.

5.3 Maksim Proshin - RFC 4960 Errata and Issues (10 minutes)
    draft-tuexen-tsvwg-rfc4960-errata
        This is currently an errata tracking draft.  WG adoption
        likely to be requested sometime in 2016.

* Mirja Kuehlewind: Why does this list erratas in a seprate document, why not
have real .bis document?

* Maksim: We plan to do that as a separate next step.

* Karen: Such a document is helpful clarification, to motivate certain changes.

* David: Would it be possible to treat this draft amd 4960bis as a pair of
drafts to be published? This one explains why, other one specifies the protocol.

* Karen: We could use this draft as an informative reference. Agree that
approach, working these in parallel. The given list (Improvements slide) also
proposes changes to the protocol, we should take in only very important and
safe changes to update the standard. Some of the listed items might be
rejected. We want to have discussion about them.

* Lars: This could become an Informational appendix, instead of separate draft.

* Karen: An appendix is more limited in space. Need to spend time polishing the
information

* David: Feeling of the room seems to be to go with two separate drafts
[This is consistent with the procedure discussed at previous TSVWG meetings and
seems to have worked well for SCTP in the past.]

5.4 Karen Nielsen - SCTP Tail Loss Recovery (15 minutes)
        draft-nielsen-tsvwg-sctp-tlr

(presentation moved to Thursday)

------------------------------

6. UDP Drafts

8.2 Tom Herbert - UDP Magic Numbers
        draft-herbert-udp-magic-numbers (10 minutes)

* Martin Stiemerling (for Cameron Byrne from Jabber): It is very strange to me
to do this for a middlebox. Is anyone fron a middlebox is saying they want this
form of number?

* Gorry Fairhurst (from Jabber): When is this more visible than the DST port?
(e.g. what happens inside a tunnel?)

* Ans: RTP payload - Web RTC example results multiple layers of encapsulation
within UDP.

* Colin: Similar, but different magic numbers were chosen in STUN/ICE,
conceptually this is very similar. These numbers were carefully chosen. we
should look at RFC5764.

* Brian Trammell: Why is the magic value chosen like it is? How does it work
with currently deployed application protocols? In a similar case (SPUD) we
looked at protocol specifications to see if anything matches the chosen number.
We should choose the number carefully based on available information.

* Colin: RFC 5764 specifies guidelines on picking these numbers.
[Aside from David: Well, actually see draft-ietf-avtcore-rfc5764-mux-fixes for
how this really works, as RFC 5764 has turned out to be incomplete in this
area.]

* Joe Hildebrand: You need to do something that is doable on the fast path (I
am just trying to answer why middlebox would care).

* Mirja: We also need a magic number in SPUD because we needed to talk to
middleboxes. I'm not supporting to reveal the application name information to
middleboxes. A middlebox needs to know what kind of traffic, it does not need
to know what the application is.

* Joe: +1 to Mirja:  In SPUD we are trying to hide as much as we can, we only
expose what the network needs to see. There is a middleground we can try to
approach.

* Lars: Why is something in the UDP payload something that we need to
standardize? Applications (new protocols) can, and do, what they wish with the
payload.

* Ans: Middleboxes need to support this, a uniform way is helpful.

* Bob Briscoe: I don't agree with Lars. Middleboxes can check the application
payload even without a magic number. Middleboxes still need to work with
traffic that does not co-operate with them. Take a look at GUT we did with
Jukka Manner, it also has a magic number.

* Colin: In practice this is using it as a multiplexing shim layer. We are
defining a new protocol that runs on top of UDP. If we accept this, we accept
this as an architectural design approach. If you do this right, it can be used
by new protocols.

* Joe: The goal of this is to get on the fast path of middleboxes, many
applications would not necessarily use this. It would be interesting to have a
standard way of generating a good magic number.

* Tom: I don't see this as a tool for multiplexing, I want this to be simple.

--------------------------

6.1 Chairs - Transport Options for UDP (5 minutes)
        draft-touch-tsvwg-udp-options

* Gorry (from Jabber): IIRC, UDP-Lite started its life the same way (specified
using the same IP protocol number as UDP).

* Joe Hildebrand: (notes missed the first part of the comment). There is Cisco
IPR on this approach.

* Tom: There may be problems with offloading, etc.
[See slides, this is being explored.]

* John ??:  (missed comment)

* Bob: There might be a case that firewalls check whether the length fields are
consistent.

* Mirja: I like this idea, very curious to see. Makes easier to implement
something on top of UDP?

* Joe: This opens door to including metadata with UDP

------------------------------

6.2 Mirja Kuehlewind/Brian Trammell - Requirements for the design of
        a Substrate Protocol for User Datagrams (SPUD) (20 minutes)
        draft-trammell-spud-req

* Lars: Please keep those two things separate (SPUD and stackevo). Don't merge
the two together.

* Tom Herbert: Should we use something else than UDP as a protocol number?

* Joe Hildebrand: If you want to ensure that doesn't get deployed, feel free to
pick another number.

* ??: When SCTP was developed, one idea was to use it over UDP. It picked a
different protocol [and checksum], all sorts of problems appeared with
middleboxes. We need a way to identify protocols on top of UDP.

* James ??: Was 6lowpan header compression considered? You could potentially
compress more.

* Brian: We haven't thought about it, nobody brought it up. Please come talk to
us on the SPUD list.

* Mirja: We haven't seen any blocking or differential treatment in our
measurements.

* Brian: The SPUD office hours on Wed morning

---------------------------------

   ---- Session 2 (120 min scheduled out of 120 min total)

---------------------------------

Note Taker 2: AARON FALK (aaron.falk@gmail.com)

6. UDP Drafts (continued)

 6.3 Lucy Yong - Generic UDP Encapsulation for IP Tunneling (20 minutes)
              draft-ietf-tsvwg-gre-in-udp-encap

Lars will send a pointer to the randomization RFC for TCP to list (RFC 6056).

AD: For a well-managed IPv4 network MAY set UDP checksum to zero, it doesn't
say why. I think this is wrong to base this on current implementation issues,
and instead the document really ought to say "MAY" and then say for example to
address current implementation performance.

Need to confirm draft text is consistent with tunnels drafts.

---------------------------------

7.1 Bob Briscoe - Guidelines for adding Congestion
    Notification to Protocols that Encapsulate IP (10 minutes)
    draft-ietf-tsvwg-ecn-encap-guidelines

Brian: Unity Media (German ISP) had a behaviour that set CE. This information
did not originate with Apple, it was available via open sources. Ken: The
rationale for recating to ECN marks may be different - some 3gpp specs
recommend codec swapping in respond to CE. Joach Meyer: from Huawei & 3gpp
router vendor, not an expert on ECN.  Bob's report is being read by the 3GPP
groups and we should expect a reply by Dec 2015. This presentation goes
further. Will you bring this to 3GPP as a company contribution? John
(co-author): We will discuss offline on how to best take it to 3GPP Dave: We
probably won't last call this draft before 2016; thanks to 3GPP for the level
of interest they are taking in this matter.

---------------------------------

7.2 David Black (on behalf of authors) - DSCP and other packet markings for
              RTCWeb QoS (5 minutes, no slides)
              draft-ietf-tsvwg-rtcweb-qos

There are 3 drafts addressing this issue and they are not yet completely
aligned. The team will align the drafts. This draft will ask for WGKC once that
is done. Cullen: No disagreements were identified, the work is to figure out
where text should go.

---------------------------------

7.3 David Black - Diffserv interconnection classes and practice (10 minutes)
              draft-ietf-tsvwg-diffserv-intercon

Pat Thaler, Broadcom: I am not comfortable with the lack of room to support
something like DETNET (deterministic networking), although DETNET initially
would only be on a single administrative network. David: That's a different
usecase.  This is about standard interconnect, we need something to allow more
cosnistent deployment now.  Also, I plan to push back hard on feature creep
given the limited number of codepoints available for Diffserv in MPLS - which
this draft intentionally maps to.

---------------------------------

7.4 Xinpeng Wei - draft-ietf-tsvwg-tunnel-congestion-feedback (10 min)
              Tunnel Congestion Feedback

David: This proposed new IPFIX methods to be specified in another group - is
that group OK with this? Brian: I have no problems with the IPFIX aspects. The
work is continuing

---------------------------------

7.5[new] Chairs - Relationship of Circuit Breakers to Tunnel Congestion
Feedback (10 min)
                  draft-ietf-tsvwg-circuit-breaker
                  draft-ietf-tsvwg-tunnel-congestion-feedback

No disagreements with chairs' proposal.
Gorry (as editor): I don't quite agree on the detail ... I think the
measurements that you would need for tunnel congestion control can be something
more than for a CB, but I agree these measurements can then be used for a CB.
An update to the draft is planned to address comments and gorry will work (as
Editor) with David (as Shepherd) on sorting this.

---------------------------------

 5. SCTP draft (moved from Monday)

5.4 Karen Nielsen - SCTP Tail Loss Recovery (15 minutes)
                  draft-nielsen-tsvwg-sctp-tlr

Karen: There is still work to do on the draft, and we are tracking work in TCPM
and QUIC. David: The timeframe for when you'll ask for wg adoption? Karen:
Optimistically, we expect to do this at the next IETF.

---------------------------------

8. Individual Drafts

8.1 Tim Szigeti - Mapping to 802.11 (25 minutes)
              draft-szigeti-tsvwg-ieee-802-11 (presented by Fred Baker)

Tim: Renaming the draft prevents the datatracker from showing the diff.
Fred: You can use rfcdiff to do this for any URL.
David: I can make a "replaced by" change that will add this linkage between the
two drafts.

Pat Thaler, Broadcom & 802: The mappings in 802.1 are only a suggested default
behavior.  There is no fixed mapping in 802.1 w.r.t. priorities.  Ordering of
priorities is totally configurable.  Over the past 8 years, we've added a
number of other ways to handle priority other than strict ordering.  There's
more than 1 default  mapping for 802.1, e.g., one for TSN (enabling home
audio-video bridging, AVB). John Kaippallimalil: There's an additional mapping
between IETF & GSMA/3GPP. [Aside from David: See RFC 7561, Section 4.2]

Fred: I would prefer 802.1 issues be handled in a new draft.  More defaults
will be added.  Putting everything (802.1 and 802.11 mappings) in one doc would
add to the confusion.  It would be nice if 802.1 mappings were consistent with
802.11 mappings. Pat: The link speed does make a difference in whether a switch
would care about particular traffic differentiation.  Any carrier will use
priority differently on their own network and have their own mappings.  We
don't need mappings to be the same, carrier to carrier, we need the DSCP
interpretation to be the same.

David (to Pat): Do you care about priority settings in home networking gear?
Pat: Yes. For TSN there is a suggested default, which is what we expect to work
generally within homes.

David: In this discussion, do you think there's anything the IETF could
usefully do? Pat: Other than clearly defining what the DSCP meanings are, no.

Request for working group adoption
David: How many have read draft?  none.
[People had commented to the list, so some people at least must have read this.]
David: We need to see a few people read the draft before a wg adoption call. We
can ask again on the list.

Fred: There has been some discussion of revising RFC4594.  Cullen may be
interested.  We don't intend to make changes to code points or add a lot more
of them. The 1st step is to define a triage list of what is needed. Dave: We
may also want to write some scoping language; since RFC4594 is very wireline
network oriented, it may need some clarifying language. Fred: A question to the
wg: how badly do you want this? Dave: It is hard to say without seeing the
triage list.

---------------------------------

8.3[new] Nik Teague - DDoS Mitigation (dots) Transport (10 minutes)
                  draft-ietf-dots-requirements
                  draft-ietf-dots-use-cases
                  draft-reddy-dots-transport

[Item included to coordinate with the IETF DOTS WG - follow-up activity can be
taken to this WG] Aaron: The mitigation provider may be several networks
away... Lars: Please read draft-ietf-tsvwg-rfc5405bis when discussing use of
UDP.  TCP connections age out (you can't just open a TCP connection and leave
it, and then expect it to work). Nik: We plan to have a heartbeat. Lars: That
generates state. DTLS doesn't work on unidirectional UDP. You need to consider
rfc5405.  UDP design will be challenging. Bob: How many hosts are sending
heartbeats?  Millions?  The method may form an attack on the mitigation
provider.  Note that NAT timeouts typically are 30sec. Nik: tbd. Bob: Lots of
repeat packets seems a better way than creating many idle encrypted sessions.
David: You should do both TCP & UDP. ??? - use case author: an undocumented use
case includes on-premise system always filtering traffic. David: Please help
the DOTS WG to get this right.

Meeting closed.