Skip to main content

Minutes IETF98: tsvwg
minutes-98-tsvwg-03

Meeting Minutes Transport and Services Working Group (tsvwg) WG
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-03
TSVWG met in two sessions at IETF-98 (Chicago)
Chairs: G Fairhurst, D Black, W Eddy
Note takers: V Rocca (Session 1), M Welzl (Session 2)

Session 1

1. Agenda (WG Chairs)

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

2. Status/updates (WG Chairs)

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

Gorry presented 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 both. Donald Eastlake and Ingemar Johansson 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 did not manage to update this, and plans to do that by May 2017.

TSVWG Meeting at IETF 98, Chicago, USA
WG Chairs: Gorry Fairhurst, David Black and Wes Eddy
Note Taker 1: Wes Eddy
Note Taker 2: M Welzl
Jabber Scribe 1: Magnus Westerlund

Session 2

Presentation by Gorry:
   TCPM WG: Retransmission Timeout Requirements
   draft-ietf-tcpm-rto-consider

Gorry: Note that this will be WGLC'ed here, it applies to other transport
protocols, not just TCP

Presentations by Felix Weinrank:
    Stream Schedulers and User Message Interleaving for SCTP
    draft-ietf-tsvwg-sctp-ndata

Felix: A clarification on weight, double weight = double capacity.
Gorry: This is past WGLC. We believe all issues raised have been addressed.
Will check with Michael if this is updated, will issue a new version and
proceed to shepherd writeup. Last chance to comment.

    SCTP Network Address Translation Support
    draft-ietf-tsvwg-natsupp

Felix: This is ID is not related to WebRTC
Gorry: The feedback matches things on todo list, we expect authors to address
and submit a final version.

    RFC 4960 Errata and Issues
    draft-ietf-tsvwg-rfc4960-errata

Felix: There were no changes since last IETF.
Gorry: This is the first round of expected changes which will update the base
spec. It is an important document. The procedure is to try to capture
everything before opening an update to the main Spec. Please read and comment
if you see any issues.

    Additional Considerations for UDP Encapsulation of SCTP (5 minutes)
    draft-tuexen-tsvwg-sctp-udp-encaps-cons

Felix: There were no changes since last IETF.
Gorry: We previously requested feedback on this; we went through issues,
preferred update to the doc instead of list of changes. That is what we asked
for and that is what we expect.

6. Individual drafts

Presentations by Joe Touch (remote):
    Transport Options for UDP - Gorry Fairhurst for Joe Touch (10 minutes)
    draft-touch-tsvwg-udp-options

Chairs: How many people had read the draft?: 8
Tom Herbert: The bottom line will be, is this practical for Internet?
Joe: Legacy UDP will just throw away the option data. UDP stack would interpret
that data. Tom: UDP length not included, right? Joe: UDP length is shorter than
the IP length, we did not need anything extra from IP, IP thinks it is an IP
payload Tom: There will be problems, e.g. UDP encapsulation... TSO... devices
are not going to handle that. Joe: Everything we have tested allows the
information to go through when it is a relay, and an endpoint simply ignores it
if it is a legacy endpoint, this is exactly what should happen. It is possible
that an endpoint could just truncate the information, but if it does we will
figure this out with the checksum, user will not have a problem. Christian
Huitema: I am concerned that putting data in this gap will allow putting
supercookies in packets and stuff like that. If we start having a logic in
which we expect this place to be used, we allow attackers to use it. This is
outside the TLS security envelope, I would like to drop the packet. Gorry: This
is the same for all transport protocol options. Joe: If you drop packets that
would be a violation of spec. If you want to send supercookies there are a
thousand other ways. Christian: Not with something like QUIC, for example Lars
Eggert: As chair of QUIC, is there any benefit for QUIC of having this option?
If this would make something like QUIC work better that would be a powerful
deployment reason. Else maybe not so useful? Joe: We are not doing anything
that an app layer can’t do. The problem is, getting every app layer to do this
cleanly is hard. If it is transport all apps get it. E.g. frag/reassembly, if
we could rely on UDP to do that there's one less thing apps have to do. Bob
Briscoe (remote): (answering Christian): Maybe this is an opportunity to secure
this space. Just because a spec says this is now legal does not mean attackers
are not already using it. Christian: Yes, correct. My preferred solution is we
drop any packet that has anything in this grey area. Gorry: That would be
against IETF guidance. Christian: App options are inside security envelope,
this grey area is not. The fact that it is not protected by the  encryption
envelope that gives me jitters. Bob: We could specify it within the encryption
envelope. There is an opportunity here to do this. Joe: I like this suggestion.
I disagree that this is not part of the security envelope, security envelope
for IPSec would cover it. This is in the same place as any kind of option
space; at some point when you do next layer up you have to take this into
account. If you want to protect this you have to have header protection
security or IPSec. TCP options are not covered by TLS.

Show of hands: interested in progressing something in this space: 5 + 1 from
jabber people who think we shouldn't: 1

Wes (chair): Assuming we address the security problem, would that make it
better? Christian: If the options are included in the TLS security envelope I
would have no problem. IPSec isn not used (much) in practice. Joe: Why are you
not concerned that TLS does not cover TCP options? Christian: I am, that is why
we are doing QUIC.

Gorry (chair): The WG will ask for clarity on how security problem should be
treated; then do an adoption call; we will later cover question of intended
status and which options will be included. Joe: AOK.

Presentations by Vincent Rocca:
    Vincent Rocca - FEC Framework Extension to Convolutional Codes
    draft-roca-tsvwg-fecframev2 (10 minutes)

    Vincent Rocca - Random Linear Codes (RLC) FEC Scheme for FECFRAME
    draft-roca-tsvwg-rlc-fec-scheme (10 minutes)

David Black: Any 3GPP interest in this extension?
David Moses: For high speed links such codes are a must in the physical layer.
So why do we need this? Vincent: having it at an upper layer makes sense anyway
even if there is protection at the lower layer. This is one of the conclusions
of the WG. David Black: A concatenation of links on a path can create problems.
Georg Mayer, (3GPP liaison): I can't find this draft on the dependency list
which we have to find which drafts should be pushed. About video, this is
something that is on the 3GPP agenda with a high priority. I am not sure how
this draft will fulfil the requirements that we set but dependency by
referencing the draft in 3GPP specs. This does not have to be a WG draft but of
course if its is it will make it easier to convince people. Vincent: Both
drafts exist, and can easily be mentioned in the 3GPP proposal, no problem.
Gorry: This is a change of framework to include methods known for decades. If
we open it for that my concern is this could open it for a succession of other
FEC schemes, etc - do you see this as the start of a family of drafts or is one
proposal enough to make a real contribution? Vincent: This proposal is clearly
the main solution. It will not fit all use cases, since this is limited by
coding complexity. It may not be a good solution for doing the same with large
encoding blocks. I do not expect to come back again to TSVWG soon. For the
moment, for the current use cases, this is a solution. Matt Mathis: If I miss
too many frames to repair a hole, I could potentially need to retransmit a
single frame, this could later help repair earlier frames, is the in the spec?
Vincent: No. I could be done if you are in time but there are probably other
ways to do that. Lars: This needs expertise in this space. The more you put on
the plate, the more concerned I am if we have the energy and expertise for it.
Vincent: We could also say this is a good opportunity to bring expertise in
this domain. Let IETF make efficient tools in this space, which is not the case
today. David: Again, error protection should be at the link layer. Vincent:
Packet FEC is included in 3GPP specs for end to end, we have these schemes in
the standard, you need it e2e too. Gorry: We do not need to discuss the FEC
frame architecture. This is already something we have in the IETF.

Chairs: Who has read the ID? 5 hands.

Brandon Williams: We would appreciate having a standard thing as opposed to the
stuff we are doing now. Interested in seeing this go forward. Chairs: Who think
this is interesting to work on? 12 hands.

David Black: What is time frame for clarifying the 3GPP situation? I understand
it is been proposed to 3GPP but not yet picked-up. Georg: When something is on
the dependency list it is highlighted, for example FEC scheme is on that list.
When a company comes and wants it and there is consensus to adopt it, it can be
listed. Dependency could be ready within the next 2-3 months so we could
highlight it officially. David B: Is this decision likely to be at a next major
meeting? Georg: This depends on companies to bring it in. I can not say at the
moment, we do not think in those terms. David B: Let is assume that Vincent and
his colleagues will bring it there and time frame is a couple of months.

Adoption call will happen on the list in future.
Chairs: people who think we should adopt this, just as a question: approx 10
Chairs: Who thinks we should not adopt these drafts and do this work? 0

David B: We need at least one person who is not part of this work and can check
if this is the right code. David B: Do you have reviewers for the maths part?
Vincent: Yes I can find these.

Presentations by Koen De Schepper - L4S:
        Low Latency, Low Loss, Scalable Throughput (L4S) Internet Service:
        Architecture draft-briscoe-tsvwg-l4s-arch

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

        Identifying Modified ECN Semantics for Ultra-Low Queuing Delay
        draft-briscoe-tsvwg-ecn-l4s-id

Slide L4S Deployment Sequences:
Gorry (as individual): The DCTCP ID  was specified only for not-Internet usage.
Koen: Yes, walled garden. Use in a controlled environment.
David Black (as individual): If we have one bottleneck that uses Dual Queue,
everything may be wonderful. When there are two bottlenecks in a row using Dual
Q, interesting things happen because CE marks from the low latency queue go
through the wrong queue in second bottleneck. WE need to find if this is a real
problem. Bob Briscoe: You do get multiple bottlenecks sometimes, but it is
rare. This was mentioned in TCPM. The marked packet also gets into the
low-latency queue in the second bottleneck, so the packet will be delivered
earlier. David B: One of the reasons for running the wide area experiment is to
look at how often these things appear in practice and how to deal with them.
Koen: If marked, the packet gets in the low latency queue, so it gets faster
response to congestion. It gets priority, so it gets in the L4S queue, this is
also a potential benefit for classic TCP, plus there is congestion, so there is
no issue with repordering. Wes (Chair): At the last meeting there was energy,
on the list too. We think we should adopt, so we need to think about
milestones. David B (individual author): We would like to get the ECN
Experimentation draft off to ADs next month. Have not seen major objections. I
have reason to believe that this will be revised and through WGLC by end of
April / early May. Mirja Kuehlewind: Nods in agreement with timeframe.

Bob: to David: need to define what classic ECN should do with ECT(1), we are
going to write this out on the list. David Dolson: Whether this works depends
on whether devices can be configured David Black: The challenge is to open
space to run the experiment. The draft is reasonably clear on ECT(1). If it
does not encompass what to do if you are not part of the experiment it is
close. We will look at the text. Gorry (individual): we do not seem to have a
specified transport that would allow for Internet experimentation using L4S. We
have the TCP-Prague proposal, but currently nothing on the experimental track
that defines how to use the experiment. Koen: We have to have at least one
working implementation, we do not know if we need a draft. Congestion control,
I guess this has to be ready before we can experiment on the Internet, right?
Gorry: Yes, I think we need a spec, or a list of requirements. Mirja: What does
the arch. draft say that you should use as congestion control? Koen: Anything
that behaves more or less like DCTCP. It does not say if negotiation is
required. Mirja: Accurate ECN will have negotiation. Does this block us here
from moving on? David Black (as chair): I wonder if a fudge is possible where
we have spec for DCTCP and just state somewhere that this could be used for
this experiment? Gorry: I would strongly protest. DCTCP said explicitly there
are issues that need to be addressed to deploy outside the data centre. Let's
be careful as we go forward. Mirja: We should check the draft. It should say
"only use it in an environment where everyone is using this kind of stuff". Not
necessarily controlled environment. L4S is a new service, we can expect
everyone in this experiment is doing the same kind of thing. Gorry: Any non-L4S
routers on the path are the issue. Koen: But what if the transport is backward
compatible with drop? Bob: The spec says that DCTCP can be used in controlled
experiment, I would agree with Mirja that this is a controlled area across the
Internet. Respond to drop but also fall back to Reno-like behavior. DCTCP does
that. Getting to the point where we have code and spec. Maybe we need to check
some more what controlled environment means. Gorry: I will look at drafts again
to check my understanding of this. Mirja: A personal comment, I think this is
good work and we should enable experimentation here. Congestion control is part
of the experiment and we're going to look at it. Spencer Dawkins: I am excited
about the possibilities after the ECN experimentation draft. Phil Eardley: This
is good stuff. Can we do it without a working implementation of TCP Prague?
Gorry (Chair): . I think we have raised this, and people will look.We are now
in danger of ratholing: we all know accurate ECN is cool. Christian Huitema: I
am not worried about routers that don not do ECN. There you will get loss
signals that tell you something. I am worried about routers that do ECN the old
way, there are a few of those. This will be interesting if you found a way to
detect specifically that - how often did I try something and I believe I found
a legacy ECN router on the path. Koen: Other experiments are also going on,
Apple have enabled ECN, they can say how much traffic is marked. Christian:
Yes, but this is specifically about the ECT(1) codepoint.

Adoption call:
Chairs: Please show hands for those who have read the drafts: 12
Chairs: Does anyone think one of the 3 drafts is immature, or would like to
consider these individually? - No one. Hum if you think IETF should adopt work:
clear hum. Hum if you have concerns or think we should delay work: silence.

Chairs: There is a clear consensus to progress these drafts. We will take this
decision to the mailing list to confirm this adoption call.

Mirja: It would be good to add an experimentation section with guidance on how
to run the experiment - things like: don't enable it for all traffic, what
metrics to measure, etc.


Presentation by Ingemar Johansson
        High ACK rates for transports operating at high speed

Tom Herbert: One of the side effects of generic receiver offload is stretch
ACKs, it does happen in real life Praveen Balasubramanian: Stretch ACKs are
pretty common, Windows stack has been doing that for a long time, a sender
should be able to know when that's happening Mirja: True, work is ongoing for
TCP, that is good - but for QUIC there is nothing defined, I think we cannot
discuss this at the moment for QUIC. Gorry: There is a related BCP already
(BCP69), RFC339 - let’s just talk more and take Mirja's comments into
consideration. Qiaobing Xie: This is good work, we must make sure that SACK is
covered in the study, SACK is generated by a different set of rules.

The meeting closed.