Minutes IETF100: tsvwg
Transport Area Working Group
||Minutes IETF100: tsvwg
IETF-100 TSVWG Meeting
Monday Afternoon session
Notetaker: Brian Carpenter (thanks!)
The chairs presented the WG slides, noted completed RFCs, milestones, etc.
Other WG drafts:
draft-ietf-tsvwg-ecn-experimentation (post IESG, will be at RFC Editor soon)
draft-ietf-tsvwg-tunnel-congestion-feedback (work needed)
2.1 Note detnet WG discussion of draft-thubert-tsvwg-detnet-transport (in
3. ECN encapsulation (Bob Briscoe)
Bob reviewed rev -05 of Propagating ECN across IP tunnel Headers Separated by a
David: We expect to progress the tunnel and shim encapsulation drafts together.
Bob Briscoe: January would be a suitable milestone for both drafts.
People willing to review these drafts:
4. LE PHB, round 1 (Roland Bless)
One serious open issue remains: DSCP selection, since issues had been raised on
the proposed code point of DSCP 2 voiced in Prague. Gorry reviewed the
discussion in Prague and asked the WG to consider the options and be ready to
make a recommendation by the second meeting. Brian Carpenter: One of the
characteristics of Pool 3 is that it currently is permitted for local or
experimental use. Gorry: Yes, and if such an operator understands how to use
Pool 3, then they could be expected to know how to remap that at the network
boundary. It may of course remap this to zero. Bob Briscoe: Is marking up to
zero OK really OK? Gorry: Roland's draft says you should also use a LBE
transport to protect the Default traffic. Andrew McGregor: We have networks
that provide a LE code point and cases where LE and BE traffic has to share a
queue, and the use of a LBE transport works fine in that case.
5. Individual ID (Colin Perkins)
The draft had been presented in OPSEC and there was interest from there in a
document on this topic.
Lars Eggert: QUIC is working on a protocol that has encryption. There is a
design team to consider whether there is a need for information to help
operations. What happens if this work concludes something different to what
QUIC decides to do? QUIC is on a short schedule. Colin Perkins: QUIC is on an
accelerated plan that is not taking as much input as it could. This is a
consideration for the IETF. David Black: If QUIC is the first example, then
attention should be focused there. Colin Perkins: The draft is about what needs
to be done and not what needs to be changed. Lars Eggert: I am concerned the
IETF-QUIC will be blocked if nothing happens. That is a concern if the IETF
QUIC is not progressed, while we wait for an outcome here. Spencer (AD): This
document is targeting informational. It seem crazy to hold other WG work on the
basis of an informational draft. What is the intended audience for this draft
if not QUIC? I think it is brilliant and we should have been working on this
all along. I want to be sure the document is useful. Brian Trammell: I edit the
QUIC manageability of the document that specifically addresses the concerns wrt
to QUIC. I really think it is useful to have a document that targets the
transport issues. This approach on looking at the impact of the people in this
room may be a way to make progress. I think the insights here need to get into
the other drafts. I assume you have looked at the things that are relevant in
other documents at the IETF? Colin Perkins: We think we have looked at these
(we may have missed some - if we have let us know.) Flemming Andreas: I agree
with the message here. Roni Even: I support this document, we need to balance
security and manageability. Joel Jaeggli: I am largely sympathetic to end
system protection from meddling, but also have to protect endpoints in scalable
ways from devices that just send packets. Lars Eggert: The integrity protection
part is a part, but also the ability to prevent middleboxes ossifying on the
stack. It would be good to know what operators think are needed. Colin Perkins:
The trade-off is whether some ossification is good or bad. Not changing some
parts indicates success - we need to decide carefully what we expose and what
can change. Some forms of ossification are actually good. Mark Townsley: The
cat-and-mouse game to figure out what is needed is a race to the bottom. We
should step back and work out what needs to be exposed. We need to figure out
the right data to expose for the correct reasons.
WG Chairs (David): Please continue to read the draft and discuss on the list.
Friday Morning session
Notetaker: Stuart Cheshire (thanks!)
6. Agenda Part 2
6.1 Chairs slides
The SCTP ndata ID has now been approved by RFC-Ed.
Revision -08 of ECN Experimentation was announced 2017-11-13.
The chairs do not expect new issues, but ask the WG to please confirm the final
text is correct- there have been changes since WGLC. (gorry will remind people
on the list). Please review changes by 23rd Nov 2017
6.2 AQM: draft-finzi-priority-switching-scheduler (Fred Baker)
This is a proposal is to make elastic traffic more predictable.
The chairs confirmed this is the appropriate WG to discuss AQM.
Please discuss this ID on the draft to find out if there is interest,
operational use, and what people think is appropriate to do with this draft if
it is taken forward.
7. SCTP (Maksim Proshin)
No change since last IETF.
No change since last IETF.
Revision -03 incorporates the remaining known issues.
Chairs: Is there anyone who can look at the Linux implementation to see if
there is any feedback.
The chairs will ask for reviewers on the list, please tell the chairs. Once we
a list of reviewers the WG plans to start a WGLC. (Started after the meeting.)
8. L4S (Bob Briscoe)
These drafts have not been significantly changed. There had been progress with
3GPP in clarifying the operation of ECN, but a proposal to add ECN support to
RLC was not taken forward in release 15. There is intention to retry for
The document will be updated to include experiment considerations.
David Black (from the floor): I am interested in how a dual-queue structure
relates to DiffServ, and whether there would be multiple instances of the
queues matching diffserv aggregates.
Michael Welzl: Is there a simple way to specify the AQMs that can fit within
the framework? Bob: Yes this is the intention of the architecture ID.
An update is planned before IETF-101.
9. LE PHB, round 2 (Roland Bless)
Measurements from Aberdeen University showed that the group needed to consider
other traffic aggregates that may be mapped to DSCP 2. Roland provided an
update on the draft, and will propose a new DCSP choice.
The WG will consider a process draft to allow DSCP allocations for standard
PHBs in Pool 3. The LE PHB draft will have to wait for that in order to
allocate a Pool 3 DSCP (both DSCP 1 and DSCP 5 are in Pool 3).
Brian Carpenter: I have sympathy with this request. I think routers that do
what the architecture requires will be OK. I think a standards document (PS)
update is needed to over-ride the current allocation method. I assume this is
standards-action? Gorry Fairhurst: Yes, It would be standards-action. Do you
think we should reserve DSCPs 1 and 5 for IETF assignment, or should we grab
the whole pool? Brian Carpenter: I think this should change assignments for the
entire pool. David Black: I think we should try this approach for the entire of
WG please tell us whether a DSCP of 1 or 5 is most suited. Will add text that
relates to the draft-ietf-tsvwg-ieee-802-11 (based on running code) and
possibly updates that RFC-to-be, to be decided.
[Clarification: the text to be added to ietf-tsvwg-ieee-802-11 now is to state
that a new DSCP is being assigned - that draft will not wait for the assignment
to be performed.]
10. FECFRAME (Vincent Rocca)
David Black (individual): The density parameter is currently specified
linearly, maybe an exponential encoding may provide more dynamic range?
Vincent: OK, I understand,
Both documents could be ready for IETF-101 or shortly after. Please discuss on
New drafts to be considered by the WG:
11 draft-fairhurst-tsvwg-datagram-plpmtud (Gorry Fairhurst)
The draft had briefly been presented in INTAREA at IETF-100 and there seemed
interest there in TSVWG doing work on this topic.
Authors requested working group adoption.
Mikael Abrahamson: This is a real problem. Do we know how many TCP hosts use
PLPMTUD? Can someone find this out - it is interesting to know if hosts have
PLPMTUD enabled by default. Maksim Proshim: I support this work, there are
issues in this area. What do you do with data packets sent with the wrong pmts?
Gorry Fairhurst: This depends on the transport, so that's not our
responsibility, but we do say how to handle the probes. Maksim Proshin: It's
hard to re-fragment for SCTP. Gorry Fairhurst: Indeed, speak to the SCTP people
- also see the end of the draft for other issues. Vincent Roca: I support this
draft, and have done some work surveying PMTU. Bob Hinden: I support this work,
we should have done this before. Have you thought about DNS/DNSsec? Gorry
Fairhurst: I heard it may help - I do not know DNS, so anyone interested in
this please talk to me about how to do this. Mikael Abrahamson: Is this for the
UDP apps developer, OS? Gorry Fairhurst: Could be done in UDP options in the
stack (keeping the same 5-tuple); could be added to an IETF transport; could be
done in the app. M Abrahamson: Applications may wish to be involved. Spencer
Dawkins (AD): Applications have deployed really conservative packet sizes to
ensure the paths work. It may be good to talk to the apps folks about what
happens when this is deployed. Chairs (David Black): Please raise hand if you
have read the draft (few). Please hum if you think TSVWG should adopt this
draft (hum for). Please hum if you think the TSVWG should not adopt (none).
Chairs (David Black): We will start an adoption call on the list.
12.draft-han-6man-in-band-signaling-for-transport-qos (Lin Han)
A proposal for a sub-transport layer for IPv6 that can provide QoS, path-aware
routing that can take advantage of advanced hardware router functions. Targets
apps needing high capacity or low latency. The work has been discussed in ETSI
Next Generation Protocol. Gorry Fairhurst: When do you expect the ETSI NGP
project to complete? Lin Han: This work time may be ready by the end of the
year. Gorry Fairhurst: Is there more than one work item? Lin Han: Yes, this is
one of many items. Roland Bless: I see issues at various levels. It seems you
do not pass the resource messages with the data. Lin Han: We try to reduce the
complexity compared to RSVP. The network can release resources if they are not
used (e.g., up to 8 seconds). We have security mappings and can authorise the
users. Michael Scharf (relayed from Jabber): Please see RFC 6077 that describes
many of the issues that need to be considered in such designs. Mikael
Abrahamson: There is a business model concern here. Do you want to work across
multiple domains? Lin Han: We currently only look at one single domain. David
Black (as individual): This seems scoped to a single operator domain. Is there
an incremental deployment method? How will this behave if part of the network
does not support this? Lin Han: This is simpler than ATM. The source knows if
it works. David Black (as individual): This looks like a single operator
"walled garden" design. Bob Briscoe: I have read the draft, and do not think
there is discussion of layer 2 elements or tunnels. Lin Han: There are other
issues with more complexity. This is just a pure IP domain.
Chairs (gorry): What are your intentions with respect to this draft?
Lin Han: We are interested in liaison with the IETF and to learn.
Chairs (gorry): Are the present ETSI documents available to this working group?
Please share progress with the list and see if there is interest in the various
components that have been presented.