Minutes IETF100: tsvwg
minutes-100-tsvwg-01

IETF-100 TSVWG Meeting

Monday Afternoon session

1. Chairs:
The chairs presented the WG slides, noted completed RFCs, milestones, etc.

RFC's completed:
draft-ietf-tsvwg-sctp-dtls-encaps
draft-ietf-tsvwg-sctp-dtls-ndata (I-data)

Other WG drafts:
draft-ietf-tsvwg-ecn-experimentation (post IESG, will be at RFC Editor soon)
draft-ietf-tsvwg-ieee-802-11 (IESG)
draft-ietf-tsvwg-tunnel-congestion-feedback (work needed)
draft-ietf-tsvwg-udp-options

2.Individual drafts:

2.1 Note detnet WG discussion of draft-thubert-tsvwg-detnet-transport (in
detnet WG)

3. ECN encapsulation (Bob Briscoe)
draft-ietf-tsvwg-rfc6040update-shim

draft-ietf-tsvwg-ecn-encap-guidelines
Bob reviewed rev -05 of Propagating ECN across IP tunnel Headers Separated by a
Shim

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:
Joel
Stuart Cheshire

4. LE PHB, round 1 (Roland Bless)
draft-ietf-tsvwg-le-phb

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)
draft-fairhurst-tsvwg-transport-encrypt

The draft had been presented in OPSEC and there was interest from there in a
document on this topic.

Lars: 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: QUIC is on an accelerated plan that is not
taking as much input as it could. This is a consideration for the IETF. David:
If QUIC is the first example, then attention should be proposed Colin: The
draft is about what needs to be done and not what needs to be changed. Lars: I
am concerned the IETF-QUIC will be blocked if nothing happens. There is a
concern that 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 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: 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: 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 Evan: I support this document, we need to
balance security and manageable. Joel: 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: 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: 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

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)
draft-tuexen-tsvwg-sctp-udp-encaps-cons
No change since last IETF.

draft-ietf-tsvwg-natsupp
No change since last IETF.

draft-ietf-tsvwg-rfc4960-errata
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)
draft-ietf-tsvwg-ecn-l4s-id
draft-ietf-tsvwg-l4s-arch
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
release 16.

draft-ietf-tsvwg-aqm-dualq-coupled
The document will be updated to include experiment considerations.

David Black (from the floor): I am interested in how a dual-queue structure and
how this 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)
draft-ietf-tsvwg-le-phb
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 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: 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: I think we should try this approach for the entire of Pool 3.

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.

10. FECFRAME (Vincent Rocca)
draft-ietf-tsvwg-fecframe-ext
draft-ietf-tsvwg-rlc-fec-scheme

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
the list.

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.
M 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: I support this work, there are issues in
this area. What do you do with data packets sent with the wrong pmts? Gorry:
This depends on the transport, so that’s not our responsibility, but we do say
how to handle the probes. Maksim: It’s hard to re-fragment for SCTP. Gorry:
Indeed, speak to the SCTP people - also see the end of the draft for other
issues. ?: I 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: I heard it may help - I do not know DNS, so anyone interested in this
please talk to me about how to do this. M Abrahamson: Is this for the UDP apps
developer, OS? Gorry: 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 (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: When do you expect the ETSI NGP project to
complete? Lin: This work time may be ready by the end of the year. Gorry: Is
there more than one work item? Lin: Yes, this is one of many items. Roland: I
see issues at various levels. It seems you do not pass the resource messages
with the data. Lin: 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 (relay):
Please see RFC 6077 that describes many of the issues that need to be
considered in such designs. M Abrahamson: There is a business model concern
here. Do you want to work across multiple domains? Lin: We currently only look
at one single domain. David Black: 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: This is simpler than ATM. The source
knows if it works. Bob Briscoe: I have read the draft, and do not think there
is discussion of layer 2 elements or tunnels. Lin: 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: 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.

Meeting closed.