Skip to main content

Minutes IETF98: tsvwg
minutes-98-tsvwg-01

The information below is for an old version of the document.
Meeting Minutes Transport and Services Working Group (tsvwg) WG Snapshot
Date and time 2017-03-27 22:10
Title Minutes IETF98: tsvwg
State Active
Other versions plain text
Last updated 2017-04-03

minutes-98-tsvwg-01
Session 1
1710-1810 Afternoon Session III

1. Agenda (WG Chairs) (5 minutes)

Wesley Eddy has joined as a 3rd co-chair.

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

2.1. Documents with Chairs

- 4 RFCs published since IETF 97.
- 2 IDs in RFC Editor queue, waiting for a missed-reference.
- 3 drafts completed WGLC and need author action:
        - Tunnel Congestion Feedback
                - David to work with authors
        - Stream Schedulers and User Message Interleaving for SCTP (discussed
        later)
                - Gorry to work with authors
        - DiffServ to IEEE 802.11 Mapping (WiFi)
                - David and Fred Baker have work to do on issues raised against
                the draft - this is likely to need a second WGLC
- 1 ID to go to WGLC soon: ECN experimentation
- 5 other active WG drafts

2.2 Charter & Milestones

- See slide for WG Milestones details:
  https://www.ietf.org/proceedings/98/slides/slides-98-tsvwg-sessa-1-agenda-and-wg-chairs-slides-00.pdf

- 3 IDs calling for WG Adoption:
        - L4S (Low latency, low loss, scalable throughput Internet service.
        - discussions hold so far suggest probably adopted.
        - See presentation on Thursday.

3. WG Drafts

3.1. Explicit Congestion Notification (ECN) Experimentation
        draft-ietf-tsvwg-ecn-experimentation

David presented on behalf of authors.
The current version includes comments received during adoption
and David believes is basically ready.
Gorry asked who read it: 6 people.
The proposal is to have the current version go to WGLC.
Mirja believes the document should say "we do this because it's the right thing
to do, and that it also opens up experiment space", rather than "we do this
because we want to do this experiment". This comment is not about the content,
but about the wording. So next revision, incorporating Mirja's comments, will
go to WGLC.

3.2. A Lower Effort Per-Hop Behavior (LE PHB)
        draft-ietf-tsvwg-le-phb
        https://www.ietf.org/proceedings/98/slides/slides-98-tsvwg-sessa-32-le-phb-01.pdf

Gorry on behalf of Roland Bless.
Many updates have been made from revision -00 to -01 based on WG feedback (see
the slides for details). There are two different semantics to LE, however
current suggestion is to only use 1 DSCP. There are also DSCP marking issues
with domains applying old marking. A quick review of David Black comments is
made, including concerns about the use of "MUST" on deployed running code. A
review of comments from Rudiger Geib, in particular the suggestion to add text
on the way ECN and LE should interact. WG opinion would be useful. Concerning
the choice of which DSCP to use for LE, there are 2 proposals: DSCP 4 and DSCP
2. The use of DSCP 2 presents advantages, both should not be bleached if upper
bits are cleared. But there are problems too, as other DSCPs, when bleached,
could get remarked to DSCP 2, MAPRG data shows this is happening. Also MAPRG
data shows that a bit more than 10% of the time, DSCP 2 might be bleached to
all zeros which is sufficiently frequent to pay attention to. Is there another
possibility? Matt Mathis proposes to assume that DSCP 2 is the right answer and
then inventory the amount of harm that will happen. A question is asked: is
there a specification about passive open looping back the marking (i.e., can
the server echo the code back so that one knows that it survived)? This seems
to be out-of-scope for everyone, but would be of benefit, and we need to start
somewhere. Matt is not just talking about TCP. Mirja reminds that ICMP gives
what you want for looping back the DSCP, even if ICMP does not work all the
time. David Black agrees with Matt about moving forward with DSCP 2. Gorry (as
not a chair) suggests looking at codepoint 5, and his MAPRG presentation this
week will explain why it is working well. Gorry explains he may have more
measurement data for the Prague meeting. David suggests to delay decision till
September, in the hope to have more data till then.

3.3. Guidelines for Adding Congestion Notification to Protocols that
Encapsulate IP
        draft-ietf-tsvwg-ecn-encap-guidelines

Presentation by John Kaippallimalil.
This document has been around for a while, and a new version has just been
posted this morning. This draft got positive responses from IEEE and 3GPP. John
then reviews how comments received have been addressed. A suggestion is made
about issuing a WGLC for this ID as well as draft-ietf-trill-ecn-support that
depends on it. David agrees as they are for the same class of mechanisms in
different contexts. Gorry highlights that this ID hasn't really been changing
and if anybody volunteers to do an early review, we could do that before going
to WGLC on boths. Donald Eastlake volunteered to do an early review. Bob
clarifies that the TRILL draft depending on this is approaching WGLC too. TSVWG
chairs will talk to TRILL chairs and try to get both into WGLC.

3.4. Propagating ECN Across IP Tunnel Headers Separated by a Shim
        draft-ietf-tsvwg-rfc6040update-shim

No presentation requested.
Bob Brisco explains he does not have much to say.
He didn't manage to update it, and plans to do that by May.