Minutes IETF97: tsvwg
minutes-97-tsvwg-00

Meeting Minutes Transport Area Working Group (tsvwg) WG
Title Minutes IETF97: tsvwg
State Active
Other versions plain text
Last updated 2016-11-23

Meeting Minutes
minutes-97-tsvwg

       ---------------------------------------------
    tsvwg Session 1 (2:00:00)
    Tuesday Afternoon session I 13:30-15:30
    Room Name: Park Ballroom I
    ---------------------------------------------
    tsvwg Session 2 (1:00:00)
    Wednesday Morning session II 11:10-12:10
    Room Name: Grand Ballroom I
    ---------------------------------------------

TSVWG Meeting at IETF 97, Seoul, South Korea --> Minutes [DRAFT]
WG Chairs: Gorry Fairhurst and David Black
Note Taker 1: Randy Stewart
Note Taker 2: Vincent Roca
Jabber Scribe: Tim Chown

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

1. Agenda

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

   UDP Usage Guidelines
    draft-ietf-tsvwg-rfc5405bis
        --> Now in RFC Editor Queue

   DiffServ interconnection classes and practice
    draft-ietf-tsvwg-diffserv-intercon
        --> IESG telechat after Seoul, Dec 1

   Tunnel Congestion Feedback
    draft-ietf-tsvwg-tunnel-congestion-feedback
        --> WG LC Complete, need two more reviews, Bob Briscoe and Jake
        Holland volunteered

   Guidelines for DiffServ to IEEE 802.11 Mapping
    draft-ietf-tsvwg-ieee-802-11-00
     --> WG Last Call coming in December

   Charter & Milestones

        --> See slides for milestone updates
                New draft: ECN for Tunnels that use shim headers - new
                milestone: June (submit for RFC publication) New draft: SCTP
                (RFC 4960 Errata and Issues) - new milestone: September (submit
                for RFC publication)

        --> During the sessions in Seoul, the sense of the room was to adopt
        4 more drafts - milestones
                will be added for each draft if/when adopted.

3. WG draft-to-be

   A Lower Effort Per-Hop Behavior (LE PHB) - David Black for Roland Bless (10
   minutes)
    draft-ietf-tsvwg-le-phb-00
     --> Draft now has correct name, is an adopted WG draft
     --> David Black (WG chair) suggests that this be standards track, and
     update
                RFC 4594 (Diffserv Service Classes), as work on the 802.11
                Diffserv draft found some confusing text there that needs
                clarification, and also suggests that obsoleting RFC 3662
                (Lower Effort PDB) is the right thing to do.  Will be taken up
                on list.

4. L4S - Bob Briscoe (30 minutes)

     --> L4S work is expected to take place in TSVWG.  Sense of room in
     Seoul is that the
                WG should adopt these drafts (no hums heard against adoption). 
                The actual WG adoption call for these drafts on the mailing
                list is expected to follow the list adoption call for the ECN
                Experimentation draft (see item 5 below).

   Low Latency, Low Loss, Scalable Throughput (L4S) Internet Service:
   Architecture
    draft-briscoe-tsvwg-l4s-arch-00

   DualQ Coupled AQM for Low Latency, Low Loss and Scalable Throughput
    draft-briscoe-tsvwg-aqm-dualq-coupled-00

     --> Overload options: a) Continue to mark, use tail-drop OR b) Switch
     to classic AQM drop
                Mirja (AD) suggests b), which preserves low latency when low
                latency queue is overloaded
                        in contrast to a) which fills the queue.
                Results shown use drop in non-L4S queue.  Have experimented
                with ECN there, no significant
                        difference in results for drop/mark rate less than 25%.

   Identifying Modified Explicit Congestion Notification (ECN) Semantics for
   Ultra-Low Queuing Delay
    draft-briscoe-tsvwg-ecn-l4s-id-02

     --> If there are two or more bottlenecks, and any bottleneck other than
     the first is located at
                a dual queue node, this marking technique causes packet
                reordering for non-L4S traffic at any dual queue node that is a
                bottleneck, but not the first bottleneck because all because
                all CE-marked packets, including those for non-L4S-traffic, go
                through the low-latency L4S queue.

5. ECN-related drafts

   Explicit Congestion Notification (ECN) Experimentation - David Black (20
   minutes)
    draft-black-tsvwg-ecn-experimentation

     --> Major open issue is whether ECT(1) codepoint usage outside of
     experiments should be
                strongly discouraged (SHOULD NOT use) or outright prohibited
                (MUST NOT use).  The rough consensus in the room is for
                prohibition (MUST NOT use).  This is reflected in the -04
                version of the draft uploaded after the meeting, and discussion
                of this topic will continue on the list.

        --> Sense of the room is for WG adoption of this draft (no hums
        heard against adoption).
                Adoption will be handled via a formal adoption call on the list.

   Guidelines for Adding Congestion Notification to Protocols that Encapsulate
   IP
    draft-ietf-tsvwg-ecn-encap-guidelines
   Propagating Explicit Congestion Notification Across IP Tunnel Headers
   Separated by a Shim
    draft-briscoe-tsvwg-rfc6040bis (NOW draft-ietf-tsvwg-rfc6040update-shim)

        --> Quick status update on both drafts.  rfc6040bis draft has now
        been correctly
                renamed and is a WG draft.

6. Congestion control drafts (brief introductions only, additional discussion of
        one or both drafts may take place in the immediately-following ICCRG
        meeting)

   Circuit Breaker Assisted Congestion Control (CBACC) - Jake Holland (5
   minutes)
    draft-jholland-cb-assisted-cc

        --> Problem: Malicious node joining multicast sessions can overload
        a bottleneck
                link, degrading service to other nodes.  Problem must be solved
                in order to successfully deploy inter-AS (across multiple
                operators) multicast video service.

        --> Only a brief introduction in TSVWG, more discussion occurred in
        ICCRG

   Layer 3 Quantized Congestion Notification (L3QCN) - Yolanda Yu (5 minutes)
    draft-yu-tsvwg-l3qcn

        --> This draft received a longer discussion in TSVWG, and hence was
        not taken up
                in ICCRG.  The draft proposes to extend Ethernet backwards
                congestion notification (QCN) over IP via encapsulation for
                delivery across IP connectivity between Ethernet domains. 
                Important comments from discussion:

                - Draft is currently written for data center leaf/spine
                networks only.  That's
                        too narrow a scope for the IETF to consider, but the
                        draft is applicable to other somewhat controlled
                        networks, e.g., L3VPN. (David Black, WG chair, speaking
                        as an individual)
                - OTOH, backwards congestion notification outside of a
                transport protocol session
                        is not safe for the Internet in general because it's
                        too easy for an attacker to spoof the congestion
                        notification. (Bob Briscoe)
                - Ethernet backwards congestion notification (QCN) is not
                deployed/used much
                        today, hence extending it over IP may not be useful
                        (Pat Thaler, IEEE 802 First Vice Chair, speaking as an
                        individual)

-- Session 2 (45 minutes scheduled out of 60 total)

Note Taker 1: Maxim Proshin
Note Taker 2: Vincent Roca
Jabber Scribe: Tim Chown

Agenda recap (5 minutes)

7. SCTP-related drafts

   Stream Schedulers and User Message Interleaving for the Stream Control
   Transmission Protocol
    draft-ietf-tsvwg-sctp-ndata
     --> Draft is complete, and will go to Working Group Last Call shortly
     after meeting

   Stream Control Transmission Protocol (SCTP) Network Address Translation
   Support
    draft-ietf-tsvwg-natsupp
     --> Now that the -ndata draft is complete, expect progress on this
     draft before next
                IETF meeting in Chicago.  WG chairs would       like to be able
                to hold WG Last Call on this draft before Chicago meeting week.

   Additional Considerations for UDP Encapsulation of SCTP
    draft-tuexen-tsvwg-sctp-udp-encaps-cons-01
        --> This is next in line after SCTP NAT draft above.  Hope to have
        an RFC 6951bis draft for
                the summer IETF meeting in Prague.

   RFC 4960 Errata and Issues - Maxim Proshin (10 minutes)
    draft-ietf-tsvwg-rfc4960-errata
        --> Lots of small items, mostly editorial, a few technical.  All the
        details matter,
                so reviewers are wanted, and the authors are actively
                recruiting people to review.

8. Individual drafts

   Transport Options for UDP - David Black for Joe Touch (10 minutes)
    draft-touch-tsvwg-udp-options-03
        --> Only two peole in Seoul have read this draft, so no adoption hum
        taken. --> Use of this mechanism to realize UDP-Lite with UDP
        protocol number could
                be interesting if that works in practice.
        --> Request to take measurements to figure out how well this works
        in the
                Internet in general (Lars Eggert).  These would be at scale
                measurements to see how widely this works (or doesn't), see
                IRTF MAPRG.

   Forward Error Correction (FEC) Framework version 2 - Vincent Roca (10
   minutes)
    draft-roca-tsvwg-fecframev2
        --> Nobody has read this draft.
        --> Conclusion from discusion is to seriously rework the draft: just
        write an
                additional I-D that explains how to **extend** RFC 6363 to add
                convolution codes and explain what changes to RFC 6363 are
                necessary to enable that. The result should be a much shorter
                draft that will be easier to get people to read.  There's no
                need to reproduce all of the text of RFC 6363 and obsolete RFC.
                 This would become an additional RFC that will extend RFC 6363,
                and will have to be read in conjuction with RFC 6363.
        --> Authors have an implementation. An indpendently developed
        implementation by
                someone else (or more than one someone else) other than the
                authors is highly desirable.