Agenda for TSVWG at IETF-96
agenda-96-tsvwg-16

DRAFT Meeting Minutes for TSVWG Meeting at IETF 96, Berlin
WG Chairs: Gorry Fairhurst and David Black

TSVWG Session I
15:50-17:20 Wednesday Afternoon session II (Charlottenburg II/III)

Note Taker: Stuart Cheshire
Jabber Scribe: Mikael Abrahamsson

--
** Chairs gave status updates
See <https://www.ietf.org/proceedings/96/slides/slides-96-tsvwg-5.pdf>

   draft-ietf-tsvwg-circuit-breaker (RFC-Ed, waiting for document)
   draft-ietf-tsvwg-rtcweb-qos (Approved)
   draft-ietf-tsvwg-gre-in-udp-encap (with AD)

   The GRE-in-UDP draft is now in IETF Last Call.
   The GUE UDP encapsulation draft is moving out of NVO3 and will be taken up
   by a new WG.

--
** David Black - DiffServ interconnection classes and practice

Gorry: This document has completed WGLC. Please tell us if there are any new
comments (none).

--
** Gorry Fairhurst / Lars Eggert - UDP Usage Guidelines
    draft-ietf-tsvwg-rfc5405bis (new rev after IETF-LC)
    Lars Eggert presented, and would like to see this published.
    See <https://www.ietf.org/proceedings/96/slides/slides-96-tsvwg-3.pdf>

David: The document has been through IETF-LC. We made progress in TCPM this
week. Pasi: The references to RTO-consider draft is only informative, this
should not cause the process to stall. I don’t see technical issues blocking
publishing the UDP-Guidelines.

David Black (shepherd):  I recommend to publish as-is (with updated text in
RFC5405bis, and a pointer to draft-ietf-tcpm-rto-consider for more guidance). A
decision will be made in August.

--
** Colin Perkins - Discussion of what ECN Circuit Breakers mean for RTP
    draft-ietf-avtcore-rtp-circuit-breakers
    See <https://www.ietf.org/proceedings/96/slides/slides-96-tsvwg-11.pdf>

The specification of an ECN circuit breaker has been removed from RTP Circuit
Breaker draft, because requiring a single ECN CE mark to be treated essentially
the same as a *single* dropped packet would be inappropriate on networks where
ECN CE marks are generated much more frequently than the equivalent packet
drops would occur. RTP feedback and adaptation is typically aggregated with
timing determined by the media (e.g., adapting after one or more video frames -
that can be several RTTs for a low a RTT).

Matt Mathis: Some of the marking schemes that have been proposed mark at high
rates, this means that signalling is being delivered to the protocol that
created ECN. It may be that at some future time that a circuit-breaker can be
defined that triggers. I would add a place holder to future mechanisms. Colin:
That is true. Matt: The work needs to be done before the circuit breaker for
RTP is defined.

Bob Briscoe: I feel this conversation is not based on any code or experience
Gorry: The Fast-Trip circuit breaker is designed as a time-out for congestion
control. Bob: The point of a circuit breaker is not to protect your flow, it is
to protect the rest of the network from your flow. Colin: My point is that
driving the queue to overload can be problematic to other users. David: If you
see significant marking, you may have made congestion mistakes. Bob: Yes, you
our someone else with whom you share. RFC3168 says if you see too much marking,
you should turn-off ECN and deal with the resulting loss.

Christian Huitema: The point of ECN is to trigger rate adaptation and keep
queues small. ECN is a signal of queues, loss is a signal of problems. Matt
Mathis: As originally seen ECN-CE was equivalent to loss. This is not true any
more, 50% marking can be observed int some cases: ECN-CE marks may be frequent
an d do not signify a problem, and hence should not trip a circuit breaker. You
can not know what a CE-mark means. Matt: New AQM ECN algorithms are marking
differently, and generally the way to set CE-marks does not matter.

Dave Täht: I agree. I have seen networks with a high rate of ECN-CE marks,
which is now normal operation and not a problem. I think a combination of drop
and mark is clear sign of a problem. Koen De Schepper: The sender decides what
kind of feedback it wants, in the future if you set ECT(0) means marking is
equivalent to drop and, a new meaning for ECT(1) may be defined. Colin Perkins:
We have been told that ECT(0) marks are not to be treated as equivalent to drop
for a circuit Breaker. John Leslie: Delay may be a better indication of a
problem. Chairs: Please discuss this on the list. It would be good to present
guidance to RMCAT who also building ECN methods for RTP.

—
** Michael Welzl - TCP Alternative Backoff with ECN (ABE)
   draft-khademi-tsvwg-ecn-response (Adoption requested)
   This partially replaces draft-khademi-alternativebackoff-ecn)
   See <https://www.ietf.org/proceedings/96/slides/slides-96-tsvwg-8.pdf>

The aim is to allow experimentation with an update reaction to CE. The document
was updated to try to make it address feedback we have received this week.

Magnus Westerlund: How strong is the recommendation for apps to use ECT(0) in
RFC 3819? David Black (as individual): There is a mild recommendation towards
using ECT(0) We need a procedural draft that removes the limitations preventing
experiments. Magnus Westerlund: We should strengthen the requirement in the new
document to use ECT(0).

Bob Briscoe: To preform an IETF-sanctioned experiment, we will write an
Internet Draft. Michael: The -01 version of the draft seeks to describe this.
Gorry Fairhurst: The draft that we wrote is not intending to create a
free-for-all. The point is to enable future IETF experiments by publications of
RFCs. Colin: RFC6679 says that ECT(0) is to be used by default, ECT(1) can be
negotiated, as can random marking. Michael: We should say this update applies
to RFC6679

Koen De Schepper: Can we assume the network performs marking an ECT(0) packet
as exactly equivalent to dropping a non-ECT packet? David Black : The network
behaviour is the same for ECT(0), but one of the proposed changes is in the
reaction to seeing a CE-mark. David Black: Three experiments are taking place.
One is decoupling ECT(0) from ECT(1). The other is treating the response to a
CE marking as different to the response to drop. Colin Perkins: It seems like
CoDEL and PIE already mark CE differently to a droptail router. Michael: There
is no exact equivalence, when ECN is used packets are queued differently. Matt:
Agree, but that’s not a problem.

David Black: It may also be time to declare the ECN-Nonce experiment has
failed, and hence RFC3540 may be classified as Historic. Bob Briscoe: This
draft is just about enabling the experiments, not what we do after those
experiments are over.

Stuart Cheshire: Current seeds of iOS and macOS use ECN for 50% of TCP
connections. Currently no connectivity problems have been reported.

David Dolson: You still have to treat CE-marking the same as drop. ???

Michael Welzl: We have a document in TCPM that shows the benefits of changing
the sender reaction and shows that treating CE more mildly than drop can be a
little unfair, but not nearly as unfair as you might imagine.

Bob: I was going to submit a draft like this, and think we need to do proceed
with something like this.

Dave: If there is a shaper/policer it can either marl or drop. These need to be
equivalent, to prevent unfairness. Michael: The reaction is different to loss
(see TCPM this week). There can be unfairness, but not significantly more to
worry about. Dave: So this impacts devices that police etc in the network?
Michael: The assumption is that the network does the same, mark or drop would
be the same for a router - it is the sender reaction  that changes. David: We
will on Friday do a sense of the room on whether to adopt the -01 version of
this draft.

--
** Bob Briscoe - Identifying Modified ECN Semantics for Ultra-Low Queuing Delay
    draft-briscoe-tsvwg-ecn-l4s-id (Individual draft)
    See <https://www.ietf.org/proceedings/96/slides/slides-96-tsvwg-12.pdf>

Matt Mathis: The current square root property in TCP is a bug, and shouldn't be
perpetuated. There is no need to be backwards compatible with it.

Bob Briscoe: It is important to do no harm to the existing Internet.

Christian Huitema: I agree the square root element is a bug.
You should find some other way to balance the marking between the two queues.
Not everything today uses the square root formula. CUBIC does not follow the
square root formula at higher rates. Compound TCP (in Windows) also does not
follow the square root formula. Bob: It does at low rates? Christian: This
isn’t so. Bob: We need to choose something. Mirja: Given there was a lot of
positive feedback on L4S when is this document to be discussed? Gorry: We will
return to the adoption call of the PS update on Friday.

--
** Vincent Roca - Forward Error Correction (FEC) Framework version 2
    draft-roca-tsvwg-fecframev2 (Individual draft)
    See <https://www.ietf.org/proceedings/96/slides/slides-96-tsvwg-1.pdf>

Gorry Fairhurst: Is there any interest in work on this topic? (About five
people raised their hands.)

WG Chairs: Please continue this work and use the TSVWG list to discuss the
draft.

***********************************************************************************

TSVWG Session II
Note Taker: Randal Stewart

Status and agenda were reviewed. Tom Herbert could not be at the meeting, so no
slides were presented.

** David Black: Short discussion on: TCP Alternative Backoff with ECN
   draft-khademi-tsvwg-ecn-response

The draft has porposed 3 changes to enable 3 Experimental RFCs to proceed.
Aaron Falk:  All three drafts need to make it clear that sending packets can
conflict with other drafts. Christian: Experimental stars is fine. How will we
know that this experiment is complete? Chairs: The experiments are to determine
if the protocols are deployable and safe for Internet use. We expect a request
to publish as PS once experience is gained.

David: draft-khademi is proposed as one ID to create a singe Standards Track
that modifies RFC 3168. Spencer Dawkins (AD): I am good with everything, but
what is meant by "experimental or better RFC" in the slides? Gorry: The draft
says the updates need to be EXP or PS.

Chair: No objections to proceed.

David Black: I expect to write a draft with some editors that addresses this
update!

---
** Fred Baker -- DSCP mapping to 802.11
   draft-tsvwg-ieee-802-11

A draft may have a normative reference to an informational document. This forms
a down-ref. If you believe that there is significant dependencies, then you can
normatively refer to an Informational document.

Dave Taht: I have two issues:
- There are other diffserv code points
— but others said no
- In one part the document describes CS1 as Background and Scavanger -- which
is meant?

Andrew Macgregor: The term “background” at L2 is the same as “scavanger” at L3.
Fred Baker: Someone wants a whole new Scavanger class, this guy wants that if
the queue is not 0, or higher than a thresh, we would drop the packet. I am not
recommending that.

Fred: What is being done to make sure 802.11 is aware of the document?
Pat Thaler: I think 802.11 should be informed about this.
The chairs will send am email to IEEE noting this document is being prepared
for publication. Pat: I will also inform the 802.11 -- Donald Eastlake
volunteers to note this next week at the 802.11 meeting.

Chairs: Should the present draft be a PS?
Fred: Do we want the document to be published on the Standards track instead of
an Informational RFC? Chairs: We will send an email to the list. Mirja: Why
would this be a PS? What are the reasons this should be PS? Fred: This document
sets codepoints that implementors should follow. Mirja: That sounds good.
Michael: If a PS encourages people to comply with this, that would be a good
thing. I think this should be PS.

Reedier: Should we fix the Scavenger Class (i.e., which DSCP is recommended)?
David Black: There is no PS document that says CS1 is to be used for Scavenger.
Fred: CS1 was chosen because Internet2 was already doing this, rather than
because of a PS.

Chairs: David will be the document shepherd. We will send email proposing that
this document will be requested for publication as a Proposed Standard, if no
objections the document status will be changed. (Note: A PS request requires a
higher level of review.)

---
** Bob Briscoe - Guidelines for adding Congestion Notification
   draft-ietf-tswg-ecn-encap-guidelines-07

Bob Presents slides and speaks to recent outcomes (two).

Chairs: David Black will send a liasion statement back to 3GPP (it is in his
outbox).

---
** draft-briscoe-tsvwg-rfc6040bis

Bob would like that tunneling drafts reference this new bis document (6040)

Bob describes his changes since the last meeting.
Chair: Gorry to have a look at Bob's guidelines update.

The chairs requested reviewers from the WG.
These included:
    Randal Stewart
    Randal Jessup

Chairs to issue a WGLC against the updated document.

Bob had produced a second document by extracting tunnel recommendations from
the Working Group document. This was being requested to progress as a PS.

Mirja: The documents you plan to update often do not speak of ECN - so there is
no text that needs to be updated. Bob: No - the issue is that next time the
tunnel spec is used, they need to read the text. Michael: Is the text generic
enough that the exact text is OK to implement. David: No you describes issues
with incompatible ingress and egress? Bob: Yes.

Chairs: How many people have read the draft? (few).
Chairs: Not enough people have yet read to currently adopt 6040bis in room. We
will ask the question on list.

Aaron: Are there implementations?
Bob: There are IPsec implementations, but I do not know of reported
measurements over tunnels. Mirja: I am still not sure if Update is the correct
label, but then it identifies missing text. This is on the borderline.

Gorry: I think you should supply text that actually says what to do for each
protocol that you say this updates. David: Bob please add "updates" boilerplate
and create sections for each update and insert small section that specifies the
addition/update to be applied to each RFC.

Spencer (as AD): I do not know that you have to state each RFC update in a
separate section, but I know that smart authors do.

---
** Michael Tuexen - SCTP Stream Schedulers
draft-ietf-tsvwg-sctp-ndata

Michael presents his slides

Chairs: The Chairs are looking forward to starting a WG last call, authors
declare -07 is now ready. Chairs: Would people volunteer to read the code, read
the document? Randal Stewart: I will read the code and the document at the same
time and check. Dave Taht: Is there a Linux implementation? Michael: I believe
there is work on this (Marcello). Jabber: Randell Jesep will read.

Chairs: We will read and start last call as soon as possible.

---
** Michael Tuexen - RFC 4960 Errata and Issues
draft-tuexen-tsvwg-rfc4960-errata

Status -- Noted interest in adoption last meeting, but no adoption call was run
on the list. Is there still interest in the WG? (Hum for, none against).

Chairs:  Gorry will arrange an adoption call on the list, after reviewing a 
diff' document for SCTP.

---
** Michael Tuexen — SCTP NAT

Chairs: When will this be ready for WG Last Call?

The author says the NAT draft will be ready for the Seoul IETF, and include
IPv6 examples.

No questions.

---
** Michael Tuexen -  Additional Considerations for UDP Encaps of SCTP
draft-tuexen-tsvwg-sctp-udp-encaps-cons

Spencer Dawkins: The proposed .bis draft would be a complete replacement?
Michael: yes.

---
** Gorry Presents for Joe Touch -- Transport Options for UDP
draft-touch-tsvwg-udp-options

Joe asks if the WG would be willing to adopt this as a PS or EXP.

Christian: What is the proposal of hiding the application layer data?
Answer: The after the UDP length is data options data not application data.
Christian: Hide a bit of a mis-nomer.
Mirja: You can send to a receiver that has not been updated - this is a
deployment story.

Spencer Dawkins: The PLUS BoF was yesterday, and we may have the same
discussion here. Gorry: An important point is that this data is intended to be
used for the transport. Stuart Cheshire: Its not hide from application, it is
with the current API the apps do not get to see it. Lorenzo: It is data that
could be passed as a CMESG. As an App you can send this data at the end of the
packet. Gorry: The stack can use the network as a part of it processing.
Lorenzo: Does the draft say that the network should not touch this data. Mirja:
It makes me sad if we have to say this. It is transport. Christian: Is it OK
for an App to drop packets that have this type of payload. I will drop any
packets that behave this way. Mirja: It is not implemented this way. Christian:
I think this is a side channel that is unsecure and uncontrolled. I think these
packets should be dropped. Stuart Cheshire: I see the PLUS BOF that is about
how you use the data, I see this as about where it is. David That: Is there
anyone working on a newer API? Gorry: TAPS is a forum to develop new standards
and this is a great place to submit drafts about APIs. Lorenzo: Is there a case
to allow the network to insert data into a packet? … No that is not what we are
talking about. Lorenzo: What would you use this for? Gorry: (Speaking as self) 
Examples could perhaps be Timestamps/PMTU-Discovery padding for this. DCCP has
this sort of feature, but UDP does not have these features. Lorenzo: If the
stack changes things (or in the network) then why can you not just add new
headers. Rewriting the packet header is a problem. Michael: An unprivileged
process can not write these options. David: The existing socket api would not
see this data in the read call. Tim Shepard: The use-case needs to be clearer.
The draft could use a bit more for motivation

Chairs: Discussion should continue on the list.

Chairs: The path forward is that this is not yet ready to run adoption call
based on this discussion. It would be good to understand more about what this
is good for and look at that version of the document. Author may want to take
input from the PLUS BoF. Lorenzo: I would worry about any options that can be
used by an operator to signal cookies out of band. I argue that a covert
channel is scarery.

Please send comments to the list!!

—-
** Roland Bless - A Lower Effort Per-Hop Behavior (LE PHB)
draft-bless-tsvwg-le-phb

RFC2470 doesn’t really say whether the CS1 is to be treated correctly, and
motivates choosing a per hob behaviour that has a dedicated DSCP that means LE.
This would update RFC 4994.

Fred: Why do you say the DS draft placed CS1 above CS0.
David: The class selector defines an order.
Fred: Is this local use? - what type?
Roland: This would be a PS (standards action).
Ruediger: I prefer the first three bits to be consistently used - I prefer a
new code point rather than CS1. This is an issue that needs to be settled.
David That: I think an unambiguous DSCP is good. David Blake: The CS class was
a transition mechanism. Brian Carpenter: (form DS chair). I think the draft is
the right thing to do. I think it is time to do it properly in the 000 class.
This seems spot-on.

Chairs: How many folks have read this ID? (at least 6 people)
Chairs: How many people would like to see adoption? (Humm for, few against).
The sense of the room is to adopt this draft.

Chairs: Ask for a draft 01 to be prepared and we will then ask on the list
whether the WG is ready to adopt as working group draft.

Fred: Does this change hold other documents?
David: The 802 draft needs thought about how to handle this - we plan for the
document to be published, and then this new work on Scavenger class will later
update this. Andrew: Would it be good to reassign CS1 to UP2?

******************End TSVWG******************************************

The following notes were taken on the AQM discussion within the TSVWG Session
II at the Berlin IETF.

**  AQM chairs need followup on  status of PIE conflict between Informational
and Experimental, which is it ??

** Recharter??

New work:
-- Slides from Wes.
Bob Briscoe -- is there something we can do to socialize AQM?? -- A new
document advertising it??

Fred: We have a draft that was targeting experimental status, and we have push
back from the IESGs that we need to describe the experiment. Mirja: We talked,
you just need to add text. Fred: We’ll publish as Informational (Codel is
Informational in the Draft header) Gorry: Mirja (as AD) will follow-up with the
WG Chairs.

Bob: Is there a chance for a short document that says something about what AQM
solves? Gorry: A little like the ECN benefits draft? Roland Bless: Operators
were reluctutant due to parameter problems, and sometimes feared to loose
utilisation. The three AQM's have different properties as to loss (from
experiments) -- maybe this is a good subject of a draft/paper? Christian: We
just had a discussion about what is the experiment? -- a experiment report
would be very useful on what happened after AQM was deployed?

Michael Abrams: Operator talking to other people: People don't know about
buffer bloat and there is a lot of folks that need convincing -- We still have
a lot of stuff to do in the operational aspect (5 years more work to do). Fault
finding and monitoring is important also. Michael Weltzl: Some algorithms have
thresholds (PIE for example) -- The sections talk about future work should
include that this threshold should be evaluated as we proceed to proposed
standard. Koen: Sometimes having large buffers is *good* with existing networks
-- and if you cut down on size of buffers you impact existing applications.
Operators are very concerned about existing customer experience. Having config
small AQM may have a big impact. There is a blocking case that brings
compromise. We need more evaluation, and to understand customer experience.
Bob: This is about writing up experiments on the existing AQM’s. Gorry: Is it
research lab experience or deployment? Koen: We have lab experience that
informs customers of what the impact is. Aaron Falk: +1 to having a
experimental experience report -- IAB may be able to help bring operators and
others together (based on report). Dave Taht: I strongly agree with the need
for more research -- could this be in ICCRG? -- As to operators its an outreach
to nanog or the BBforum -- ongoing work in AQM -- bring this work back into
TSVWG is to get wider coverage would like to see the AQM WG closed. Fred Baker:
Cable Labs specified use of PIE for DOCSIS. Andrew: There is other work about
doing AQM in the lower layers, that is baking that might be relevant to here
when ready in a year or so.

** Does anyone want to do algorithm twiddling?
Dave Taht: No, get current algorithms deployed.
Michael Wetzl: Presentation on research on new methods always welcome in ICCRG.
Bob Briscoe: It is important to also consider attacks against any AQM.
** ?? -- FQ-Codel solves a lot of these problems in the network.
Fred Baker: FQ-PIE -- has had two proposals, but it does not matter how you
drop. Christian: Should there be the same relation between next AQM and ICCRG
as the same as the security world, where we do research in a security research
group and then if they get ready to come in then they bring them into the
security world. So maybe ICCRG should be place for new algorithms. Andrew
MacGregor: Plus 1 on that -- AQM goes idle until ICCRG explores new algorithms.
Michael Weltzl: ICCRG used to be very busy.. but there is space on the agenda
for AQM.

** New congestion control algorithms in general should go first for discussion
at ICCRG.