Skip to main content

Minutes IETF106: tsvwg
minutes-106-tsvwg-02

The information below is for an old version of the document.
Meeting Minutes Transport and Services Working Group (tsvwg) WG Snapshot
Date and time 2019-11-21 02:00
Title Minutes IETF106: tsvwg
State Active
Other versions plain text
Last updated 2019-12-01

minutes-106-tsvwg-02
Agenda for TSVWG at IETF 106 Singapore
WG Chairs: Gorry Fairhurst, David Black, Wes Eddy (remote)
Note-takers: Stuart Cheshire and Theresa Enghardt

MONDAY, 18th November, 2019, 13:30-15:30  Afternoon Session I, Sophia

1. Agenda

2. Chairs Update:

    RFCs completed:
       RFC8622  Document Shepherd: David
       RFC8682  Document Shepherd: Wes
       RFC8681  Document Shepherd: Wes
       RFC8680  Document Shepherd: Wes
    In RFC-Ed Author-48 state, prior to publication:
       draft-ietf-tsvwg-fecframe-ext  Document Shepherd: Wes
       draft-ietf-tsvwg-rlc-fec-scheme Document Shepherd: Wes
       draft-ietf-tsvwg-tinymt32       Document Shepherd: Wes
   In RFC-Ed
       draft-ietf-tsvwg-rtcweb-qos Document Shepherd: David
   Drafts beyond WGLC:
       draft-ietf-tsvwg-ecn-encap-guidelines (WGLC) Document Shepherd: David
       draft-ietf-tsvwg-rfc6040update-shim (WGLC)   Document Shepherd: David
       draft-ietf-tsvwg-tunnel-congestion-feedback  Document Shepherd: David
       draft-ietf-tsvwg-transport-encrypt (WGLC)    Document Shepherd: David

    Chairs: Milestone updates

    WGLC discussion:
       Transport Header Encryption
       draft-ietf-tsvwg-transport-encrypt (WGLC) Document Shepherd: David

David Black: We expect a 2nd WGLC on this draft for the next IETF meeting.
Gorry Fairhust (as editor): We believe we have material to make a new revision
shortly after, this will go ahead.
Colin Perkins (as author): We were always aiming for a neutral point of view,
but we clearly missed.
David Black: Yes, I agree that was the intent.
The next version will be considerably better in this regard.
Tommy Pauly: What do you mean by neutral here? We don't want to set it up as
an opposition, about should be encrypt header or not. This about where we draw
the boundaries about what we encrypt. There is definitely a pro to encryption,
we just need to understand the conquences.
David: This describes the consequences, mostly from an in-network point of view.
It is not supposed to be advocating one way or the other,
it is providing design considerations.
Tommy: We should not shy away from saying that there are positive reasons to
encrypt, as we also point out the considerations. Gorry: Was that an offer to
have a look at the text? Tommy: If we have early versions, I am happy to review
it. Colin: There are sometimes reasons to do other things, and this also needs
to be said. Tommy: I think we agree. Please make sure we have the right tone so
people outside of this community do not misunderstand this. Brian Trammell:
This document needs more wordsmithing than other documents out of TSVWG because
there are lots of people picking things apart. I also offer to go through the
language to find opportunities for misinterpretation. I can make that happen
next week.

    Chairs: Announcements and Heads-Up.
    These documents that will not be discussed this meeting here:
       draft-ferrieuxhamchaoui-tsvwg-lossbits
       draft-zhuang-tsvwg-open-cc-architecture
       draft-zhuang-tsvwg-ai-ecn-for-dcn
       draft-olteanu-intarea-socks-6
       draft-bonica-intarea-lossless-pmtud

       3GPP SA2 contribution on L4S
       https://www.3gpp.org/ftp/tsg_sa/WG2_Arch/TSGS2_136_Reno/Docs/S2-1911250.zip
       3GPP RAN2 contribution
       https://www.3gpp.org/ftp/TSG_RAN/WG2_RL2/TSGR2_107bis/Docs/R2-1913888.zip

3. Feedback on Code Development and Hackathon against working group IDs

    3.1 Bob Briscoe: TCP Prague Status of Implementation and Evaluation (8 mins)

Bob presented coding updates since July. Work had been focussed on the missing
code. Accurate ECN is planned to be upstreamed to Linux stack.
There is now research code on fractional windows.
The was still work on-going to complete the list of topics.
An open slide meeting is organised before the next session.

  3.1.1 SCE Hackathon Update (Jonathan Morton) - no slides

There had been work on interoperability SCE with AccECN. We were able to achieve
something useful there.
Investigation on bursty link variation on a short timescale - can effect high
fidelity congestion control, dur to low threshold.
There had been success with a new marking scheme for SCE feedback based on
CoDel - with a new version of CoDel with two instances of marking, one for CE
or one SCE - This has considerably better throughput in a bursty environment.
More work is to be done on tuning the parameters.

    3.2 Julius Flohr (Remote): DPLPMTUD for SCTP: implementation and evaluation
    (This happened after 4.3)

Julius has implemented DPLPMTUD (rev-09) in SCTP and there are plans to
upstream to FreeBSD when complete. The focus of work was on IPv4/IPv6 support.

4. SCTP Drafts

    4.1 Michael Tuexen (Proxy: G Fairhurst): Bis update to SCTP Spec.
          draft-ietf-tsvwg-rfc4960-bis

The plan is to review RFC-2119 language and new text to be added.

    4.2 Michael Tuexen (Proxy: G Fairhurst): NAT for SCTP (Preparing for WGLC)
          draft-ietf-tsvwg-natsupp

The text is thought ready for WGLC, but there is one topic to discuss in the
next presentation.

    4.3 M. Boucadair: NAT for SCTP - Proposed Yang Model
        draft-ietf-tsvwg-natsupp

David Black: I understand some of this. The magic word is "augment".
Jake Holland: I have done a little bit with YANG, but I am less familiar with
SCTP. What are the SCTP VTags used for? Gorry: It is tied with the NAT state.
It will be useful to talk to Michael who proposed this. We can close this
without doing this or we could do this... Jake: I have no objection if there is
some understanding what those things mean. Brian: I think the question is: Is
the description internal verification tag and external verification enough for
someone messing with SCTP on a NAT box? And I think so. I think this is fine.
Yes, put it in. Bernard Aboba: Is there an assumption that these drafts will
make SCTP work with NAT? Gorry: There are working SCTP NATs out there. Maybe
not in people's home. Brian: And we would like to configure them with YANG.
David: Sounds like this is moving forward. SCTP people to check the SCTP part
works, then a trip to the YANG doctor.

Gorry (Chair): Is the SCTP-NAT draft ready (ignoring whether we include the
Yang model)...  Does anyone think there is additional work?
David: No hands were raised in the room.
David: The Chairs are going to move this forward and ask the authors to add the
Yang model before WGLC and then get review to move forward to a WGLC.

    4.4 Nagesh Shammer (Remote)
          draft-nagesh-sctp-auth-4895bis-00
          (This happened after 6.1)

Gorry (as Chair): Some of these additions could be filed as errata.
The normal procedure is to file an errata for smaller issues and see
if there's consensus. Please file errata and then see what else is on the list.
David: File what can be filed, then work with the other folks in the
SCTP community, then figure out in the Vancouver timeframe whether more work is
needed.

5. Transport Working Group Drafts: Protocols

    5.1  Gorry Fairhurst: Datagram PLPMTUD (Preparing for WGLC)
         draft-ietf-tsvwg-datagram-plpmtud
          (This happened after 4.3)

David Black: What is the timeline for QUIC?
Martin Duke: [About the QUIC schedule] We hope to do WGLC soon-ish,
so maybe Vancouver? Maybe even earlie? There will be a lot of comments
and require some rework. There is going to be more than one WGLC,
but the first one will happen in the next quarter.
David Black: UDP options have been separated so we can publish it without
having to wait, this gets referenced from SCTP draft.
Gorry: I expect the stuff for QUIC is the right text for QUIC.
The details are in QUIC itself, so I hope there are no real dependencies.
But we will align these two.
Martin: I have trouble believing that anything changing in QUIC at this point
will have any impact on PLPMTUD. David: I expect WGLC in the near future. Is
anyone else willing to review? Martin and Ian Swett. Gorry: Please read this.
We accept comments on any aspects, including readability.

6. New Work

    6.1 Greg White: Identifying and Handling Non-Queue Building Flows
        draft-ietf-tsvwg-nqb

The idea is to mark with a verifiable behavior.

(slide 5: queue-building traffic)
David Black (as individual): There is an open SHOULD vs MUST.
It is possible that the word  "node" in that last requirement
might be able to be removed. It is possible that you could
do what DOCSIS has done to evict queue-building traffic to
a separate quue.
You might also be able to bring some kind of admission control.
If you do not have a protection on the PHB. This looks like EF.
Greg: Agree this could be more flexible. Supporting the PHB has visibilty
into what traffic is causing queueing.
Bob Briscoe: About "node", to be verifiable, this needs to be on
the node that has the queue. It is different to a DiffServ domain
where you can have edge protection or policing, there you get a contract,
you don't get a contract here.
David: I still think there's some flexibility possible here, and we
can talk more.

(slide 7; WiFi)
Jonathan Morton: I think there is some WiFi equipment that already meets
the NQB requirement, but without an actual code point. Because they
implement FQ Codel on a per-station basis.
Andrew McGregor: The WiFi MACs varies in many other parameters
associated with the queue. I think that NQB and WiFi queueing are
kind of orthogonal. You likely want to have more one DSCP because
you also may need to distinguish between queue-building and not
in the VI queue. I am just saying there's more  parameters here.
Aggregate building characteristics are different.
Greg: Is that configuration?
Andrew McGregor:  You can't just do that, because it's not reflected in
all hardware.

(slide 8; DSCP)
Is it possible to influence the QoS map in home networks?

Bob: We ought to agree on the requirements for the code points first.
Chairs: Agree, Please discuss on the list.

    6.2 Markus Amend: DCCP Extensions for Multipath Operation
          draft-amend-tsvwg-dccp-udp-header-conversion
          draft-amend-tsvwg-multipath-dccp
          draft-amend-tsvwg-multipath-framework-mpdccp
(Moved to Thursday)

    6.3 Gorry Fairhurst: Guidelines for Internet Congestion Control at Endpoints
          draft-fairhurst-tsvwg-cc

David: I volunteer, once I survive the transport header encryption draft.
Jana Iyengar: I did read the draft. I have some specific comments, which
I will talk through off-line. I think the work should be done.
Looking into the text that has been written,  I find it difficult to
find a real recommendation that we can apply.
I am looking for something more concrete than RFC 2914.
Something between RFC 2914 and specifying exact behavior.
It's very relevant, important, useful to have that.
Your box is talking about specific transports, but any new protocol should use
this. The current text in the draft is focussed on our past experience with
TCP. Gorry: The existing RFCs were written with TCP in mind, because that is
the only starting point we can have. We can try to get there. Markku Kojo: Have
read this, it looks useful, I care. Very careful considerations need to be made
to encompass this, and in
 particular we need to think what else to include?. And we need
to separate thinking that is still experimental.
Gorry: Interesting.
Praveen: I care and I think it is really important. Should apply to all
transports. Bob: Yes, it is important. Having done the first round, it might be
worth taking out stuff that isn't really saying anything new. To more focus in
things that have changed. For instance, the burst stuff, that is newer than
RFC2914. New ideas are coming out with fairness, as mentioned in ICCRG. Try not
to repeat stuff from the past, but things that may be more controversial.
Gorry: OK. I think we could try adding a short section that clearly calls out
what is mew and see if that address that point? Yoshifumi Nishida: In TCPM we
have RTO considerations. There are several overlaps. If TSVWG will be the venue
of this draft, this WG should decide how to treat this. Gorry: RTO
considerations seems now complete, we are restating some of that here. The
overlap is not intended to be in contention. We should reconcile this between
the Working Groups, and we have to ensure that if two documents are published
they compliment each other.

Gorry: Can we do this in this WG?
David: I think we can do this work here, but an adoption call is a little
premature. There are people interested in working on this draft, and
we can likely have an adoption call in Vancouver.
Gorry: I am looking for people to talk to about this, I want to work with others
to make a better document available for the next IETF meeting.
Jana: I will comment on the next revision.
Bob: To be clear about what I said before: Previous advice is still important,
we just do not need to say it again. I was thinking about Sally Floyd, and
the fact she kept on saying this. This is probably the reason so many people
now understand it.
Jana: I think Bob just volunteered?
Jana: I am trying to find some time this week.
Gorry: I am doing this as an individual, but I only will continue if other
people talk to me to define the box together.

The first session closed.

THURSDAY, 21ST November, 2019,  10:00-12:00  Morning Session I - Canning

7. Transport Working Group Drafts

    7.1 Joe Touch (Proxy: G Fairhurst): UDP Options
       draft-ietf-tsvwg-udp-options
    Presented by Gorry Fairhurst on behalf of Joe Touch
    <https://tools.ietf.org/html/draft-ietf-tsvwg-udp-options-08>
    <https://datatracker.ietf.org/meeting/106/materials/slides-106-tsvwg-sessa-71-udp-options>

The document has been changed to PS. The final category will be decided after
WGLC inputs, for now please review with PS publication in mind. Joe reported no
further discussion of the suggested PADN and "MUST SUPPORT" flag. UDP-Lite had
been removed, and plans to update the draft to complete this. Please speak-up
if you think these would be needed.

Since Joe Touch is remote, the Chairs requested feedback on this document on
the email list.

    7.1.a) Markus Amend: DCCP Extensions for Multipath Operation (Moved from
    Monday)
          draft-amend-tsvwg-dccp-udp-header-conversion
          draft-amend-tsvwg-multipath-dccp
          draft-amend-tsvwg-multipath-framework-mpdccp
          <https://datatracker.ietf.org/meeting/106/materials/slides-106-tsvwg-sessa-71a-dccp-extensions-for-multipath-operation>

Analysis were presented in ICCRG and this focused on multipath draft (now 03)
updates since IETF-105. There is work to look at BBR in comparison with DCCP
CCID-2. There is a github repository to coordinate with anyone interested?

Roland Bless: Did you implement BBRv1?
Markus Amend: Yes.
Roland Bless: You would then need to conisder multiple sharing flows and need
to consider the impact of small buffers or you should use BBRv2, because
the results would be nice with a single flow and problems occur with multiple
flows. Markus Amend: We will consider this. Andrew McGregor: I would not
characterise BBR in quite that way, but things can go wrong in BBRv1 and the
results could be weird, and BBRv2 may be better. I think this is valuable work,
there are plenty of places where this may be useful.

Chairs: Please continue this discussion on the list.

    7.2 Bob Briscoe: L4S ECN drafts
          draft-ietf-tsvwg-ecn-l4s-id
          draft-ietf-tsvwg-l4s-arch
          draft-ietf-tsvwg-aqm-dualq-coupled
          <https://datatracker.ietf.org/meeting/106/materials/slides-106-tsvwg-sessa-72-l4s-drafts>

Bob reported implementation of dualq-coupled in DOCSIS equipment (whwre it
has a normative reference to the ID). This was implemented in firmware. A
Nokia WiFi product for Q1 2020, using dual PI2 (in the appendix) and was
demonstrated at BBWF. There drafts had been upsated.

Gorry Fairhurst: Did feedback from DOCSIS implementers influence the draft?
Bob Briscoe: Yes. Some feedback was posted on the list.
Other feedback was sent directly to me and I relayed it to the list.

Ingemar Johansson (via Jabber): The L4S contribution was discussed this week
at the 3GPP SA2 meeting #136 in Reno, Nevada. The reception was overall
positive, with some new additonal proponents supporting L4S, and some push-back
from others. It is currently unclear in what time frame L4S support will be in
these standards. We will have to wait for the debriefing next week for more
details.

    7.3 Wes Eddy (Remote Chair): Review of Open L4S ECN Issues.
          Issue #16: Detection of RFC3168 ECN AQM and fall-back.
          Issue #17: Interaction with FQ AQMs
          Issue #18,#19: Loss detection in time units and reordering requirement
          Other issues
          <https://datatracker.ietf.org/meeting/106/materials/slides-106-tsvwg-sessa-73-l4s-open-issues-summary-wes-eddy>

Wes is the document shepherd for the 3 drafts. The charter says we
should finish this in June. We are a few months behind (as we knew).
Wes discussed the requirements for EXP, and to know how to "put the
brakes" on any experiment that go badley.
He reveiwed the remaining issues.

Jake Holland: Do we have consensus on what it would mean to
“break the Intenet”?
Are we talking about congestion collapse, or something else?
What if L4S makes latency worse for the gaming modems currently on the market?
Wesley Eddy: So I think think this is about, did you have the ability
to observe the L4S experiment and can you identify the breakage and show
this was caused by the L4S experiment and then easilly can turn off L4S,
allowing people to turn off. I do not know of an RFC that helps.
Mirja Kühlewind: My understanding was that we specify only requirements
for congestion control in this ID. Requirements alone will not break the
Internet. Wes: I agree.

Wes identified the main issues to be cleared before WGLC.
The "trac" would be used to capture the main issues and important facts
 - discussion would be on the mailing list, and then as issues were
resolved, we would update the tracker. If other specs emerge that use
the ECT(1) codepoint then wehave discussed with the ADs and we are
not planning to hold L4S publication for this, while the other
spec is worked upon. If we come to it, we'll have to discuss
co-existance and how to handle this.

Jake Holland: I thought part of the point was to avoid issues
being discussed and then lost on the issues list. I wanted to
be sure that the main key points should be captured in the issues list.
Wes: That is the intent. I wanted to be sure that people do not
need to add their comments to an existing issue.
Gorry Fairhust: I agree, I think the goal is to make sure issues
do not get lost, and proposed consenus position is clear. I would
see Wes as being in charge that we do not miss things, if in doubt
ask Wes.

Wes presented what he saw of the view ... (green means ready for
text, down to read meaning this needs work). Let us talk...

(Issue #16)
Bob Briscoe presented a slide to compare CUBIC with ECN, in a single queue.

Andrew McGregor: 16:1 unfairness is not great, but it’s not catastrophic either:
Long-lived "classic" flows would become lesser best effort ... oh well...
Jake Holland: Isn't that starvation on the left of the graph?
Bob Briscoe: The tick in the line is the mean, abd the top and bottom are the
99th percentile. Jake: The bottom end of the 99th percentile goes down to 1%?
Bob: That means that 1% of sampled seconds see this. The means represnts the
mean of all the seconds (samples). Jake: Ah that needs more thought. I thought
the guidelines in RFC 2914 say that “fairness” means when capacity shares are
within an order of magnitude. Some of the data points cross that line. Markku
Kojo: Do you have results with the same number of CUBIC flows are alone without
DCTCP. That should be the basis for comparison. Bob Briscoe: How many CUBIC
flows? Markku Kojo:  You could have 8 CUBIC flows, and you replace 4 of them as
DCTCP? Now you can compare to see if there is any harm? Bob: They're only
comparing the same Round Trip Times. This is just 1 against 1, two cubics will
be "1" on the line. Markku Kojo: Do you have results comparing CUBIC vs. CUBIC,
against what you present here? That would be useful to know if there is harm.
Bob Briscoe: The man would be 1. I havenot plotted the variance. Gorry
Fairhust: Could you do that experiment easily and show that the ratio of CUBIC
vs. CUBIC is 1:1? ...and post to the list? Bob Briscoe: OK. Jake Holland: Same
question for Reno. Isn't that less aggressive? Bob: We have done experiments
with Reno, and can post these results.

Jana Iyengar: I think we know this. These results are not surprising to anyone.
We already know DCTCP is more aggressive than CUBIC or Reno. What are we
learning here? Bob: Starvation usually means the flows arte ratchets down over
time, until they get nothing. That is not the case here, they reach a steady
state. Gorry: Is there other information that group really needs? Is this the
only issue that needs to be resolved. Bob: This is the main reason SCE has been
proposed. How do we know the target? Andrew McGregor: If we do this for CUBIC
vs. CUBIC or Reno vs Reno, we get numbers less than 1. Here we're filling the
link, so we get 0.5-0.7, that is really the "comparison", we never want fill
completely. Peter Heist: From the SCE team, I'd like to say why we're doing
this experiment: There are many RFC 3168 AQMs deployed. We'd like to see what
really happens, this is a serious issue. Bob: These problems only happen with a
router that uses a single shared queue. With FQ, you don't get this problem at
all. Jake Holland: I'm far more interested in how well the classification
works, and this goes away when functional. If the classic queue detections work
we may not need this after all. Jana Iyengar: What are the real numbers about
existing deployment of RFC 3168 ECN marking? It's interesting to know as a WG
about existing deployments. Wes Eddy: The key here is for WG to agree is in the
L4S requirements, and that TCP Prague is scoped to meet the correct
requirements. Jake Holland: That's in fact the only question for me. Can we
meet the L4S requirements with TCP Prague? Can anything meet the L4S
requirements?

(Issue #17)
There had been a previous bug introduced in TCP Prague (copied from DCTCP), a
and that had created discussion, that had now been understood, and fixed.

Jonathan Morton: Initializing Alpha to one means we have a multiplicative
decrease after slow start. What happens if path capacity has decreaed after
it has stabilized?
Bob Briscoe: We've got paced chirping, which is also congestion avoidance.
We are also working on another PI controller. I presented this at ICCRG and
Netdev. Jake Holland: There was another latency spike, later in the flow. Has
that been investigated? Greg White: If TCP prague is a steady state, and new
flow emerges, I think FQ Codel does not give enough congestion signal to reduce
the capacity. Gorry Fairhurst: Is there something that does not use paced
chirping, e.g., when hardware offload that makes paced chirping hard to
implement? Bob Briscoe: Next step is to see whether paced chirping is
practical, or whether there is a less-ambitious first step, etc. Gorry
Fairhurst: I think there are not any RFCs on paced chirping, you should be
careful, to find something that can be published quickly. Bob Briscoe: Are we
going to have to solve all congestion control problems before we can finish
L4S? Gorry Fairhurst: Just to know it can be solved... Wesley Eddy: The short
answer is, if this would not change anything in the 3 drafts, then we would be
able publish the drafts.

(Open issues #2, slide 27)
I think we can go for SHOULD to resolve this issue.

David Black (as inidvidual): I strongly endorse the SHOULD here.
Richard Scheffenegger: Many stacks are able to adjust the amount of reordering
interval they tolerate. Would this be an alternative method to do this? Or
must it be time units?
Bob Briscoe: If you started with 3 DupACKs that would be OK, providing you
adapt as the flow builds up.
David Black: Pacing helps a lot.
Richard Schefenegger: But for stacks that do not have pacing, chirping, etc,
can they be compliant with the spec if they do reordering detection?
Bob: If we put it as a SHOULD, yes.
Juanna Dang: I think this is a necessary solution.
Jana Iyengar: I think this makes the transport resillient to network changes.
Devices in the network typically don't know the Round Trip Time.
Is there a better term than “Loss detection in time units”?
Bob: I think the network knows the rough round trip of the network in which
it is installed.
Jana Iyengar: I think this is a SHOULD. I do wonder if the text ought to be
about resillient to reordering beyond the 3 DupACK threshold. I wonder
if there is a much better way to say this than "time units'?
Praveen Balasubramanian: I prefer "SHOULD", I think thus about an endpoint
needs to provide reordering adaption in either packets or time and we need to
say that. The current transport specs do not specify this (TCP and QUIC).
Gorry Fairhust: As a chair ,I find it difficult to relax the reordering
constraints in the Internet Layer - unless we write a draft that explicitly
states this and we can agree consensus. Relaxing transport requirements
is within scope, as long as write text that does not motivate a network
change. I think the current text is close.

Bob: We also tried to address issue 21.

8. Individual Drafts

    8.1 Jonathan Morton: Some Congestion Experienced (20 mins)
          draft-morton-tsvwg-sce
          draft-grimes-tcpm-tcpsce (discuss in TCPM)
          <https://datatracker.ietf.org/meeting/106/materials/slides-106-tsvwg-sessa-81-some-congestion-experienced>
          <https://tools.ietf.org/html/draft-morton-tsvwg-sce-01>
          <https://tools.ietf.org/html/draft-morton-tsvwg-cheap-nasty-queueing-01>

SCE reflects earlier proposals to use ECT(1) as a signal of mild congestion,
asking for a small reduction in the transport. This eliminates ambiguity
about how much to reduce the rate by.

Stuart Cheshire: Is sojourn time the instaneous time for a particular packet
for minimum for last window? Other parts of CoDel operates over a window.
Jonathan Morton: Per packet marking with different parameters.
Richard Schefenegger: In the case where there is CE amrking, will
there also be 100% SCE marking?
Jonathan Morton: Yes.
Gorry Fairhust: Where does drop occur?
Jonathan Morton: Drop on queue overflow, or use Blue with unresponsive floods.
Gorry Fairhust: How does this let you guarantee low latency? How do you mix
delay properties if there is no limit on the queue? Jonathan Morton: SCE does
not influence the drops. Stuart Cheshire: In the area above the marking, you
can't have 100% SCE, you can only have either SCE or CE. There can only be one.
Jonathan Morton: Every packet is marked SCE if it is not otherwise marked CE,
that might include incoming CE marks. Mirja Kühlewind: What do you mean by
backwards compatibility if SCE and non-SCE competing in the same queue?
Jonathan Morton: This about SCE fairness with non-SCE fows within a single
queue, and vice versa. The easiest solution is to leave single quque nodes
without SCE marking capability. Since SCE can work with such queues, using CE
marks. This is also an opportunity to deploy CNQ of FQ, or diffserv.

Bob Briscoe: You said this is a golden opportunity for operators to deploy FQ.
But if they do not, this will not work. This is not a solution for those who
do not wish to do FQ.
Jonathan Morton: You get an advantage if the bottleneck is somewhere else.
Bob Briscoe: CNQ is still a single queue.

Jana Iyengar: I think the work item places low latency as the first requirement,
and backwards compatibility as a secondary requirement. What does SCE offer?
Jonathan Morton: Yes, you need to get the information from the network to
the endpoint to get SCE's advantages. It is a siganlling mechanism.
Jana Iyengar: As a signalling mechanism, this doesn't give me low latency,
it gives me a signal.
Jonathan Morton: If you only have a single queue it may be
backwards-compatible, but doesn’t  provide low latency.
Jonathan Morton: If it's just a single queue, you have to leave it as RFC 3168.
Jana Iyengar: to get low latency you'd need top deploy FQ?
Jonathan Morton: Deploying AQM at any queue gives you low latency. It's
about whether yoy get high throughput.
Brian Trammell: If this gets adopted, we would have two proposals with
similar goals, but with wildly different deployment stories, with
partial deployment. A way forward is to suggest to the WG to make the
deployment story part of any WG deliverable.
Gorry Fairhust: We are not doing a call for adoption now.
Brian Trammell: I'll say that if that comes up.
Gorry Fairhust: If we run two experiments at the same time, we would have to
consider this seriously. Brian Trammell: You also want to consider incremental
deployment and transition after the experiment. Gorry Fairhust: I'd also like
information on the non-deployment outcome.

Gorry Fairhust: Who has read the draft? (~20-25 people in the room)
Gorry Fairhust: Who is planning to use the specs, implement them, experiment,
beyond the team?
Charles Tuffli (via Jabber): Aruba/HPE has read the draft and is planning to
continue our experiments with SCE.
Gorry Fairhust: (~5 in the room +1 remote)
Gorry Fairhust: Thanks, we will follow up with the authors on what is required
to do a call for adoption.

    8.2 Jerome Henry: QCI and Diffserv API
          draft-henry-tsvwg-diffserv-to-qci

No presentation.

Subir Das: There were reservations at the last meeting and this is now marked
as informational, which is good. What is the process?
Gorry Fairhust: This is not yet a working group item. We will get feedback
first, and we would also like to check with others including 3GPP to decide
what to do. Please discus and improve the draft using the list.

    8.3 Fabio Bulgarella: Spin and Delay bits
          draft-cfb-tsvwg-spinbit-new-measurements (10 mins)
          <https://datatracker.ietf.org/meeting/106/materials/slides-106-tsvwg-sessa-new-spinbit-enabled-measurements>

Gorry Fairhust: We, as chairs, believe mechanisms how to do this could be
discussed in this WG. But,  protocol work would probably be adopted in a
different WG, unless it is a generic transport mechanism. Eric Kinnear: Thank
you for doing this, these are interesting measurements. I would be much more
interested in a generic way to do this rather than trying to push it into every
protocol. Brian Trammell (co-chair of IPPM): We have work on a generic
mechanism to do this. We'd also be happy to see this work there. Gorry
Fairhust: IPPM is the right place to decide what the metrics are. Then, we can
discuss mechanisms and protocols. Emile Stephan: I do not care where the work
is done, but do it now. Bob Briscoe: Can I remind people of CONEX done in the
IETF?

    8.4 Lin Han and Yingzhen Qu: Diffserv and Inband Signaling
          draft-han-tsvwg-enhanced-diffserv

There was no time to present this talk, the slides are included in the
proceedings.

Chairs: Thanks for coming to this meeting and please do use the mailing list to
provide technical comments.