Skip to main content

Minutes IETF106: tcpm
minutes-106-tcpm-00

Meeting Minutes TCP Maintenance and Minor Extensions (tcpm) WG
Date and time 2019-11-22 02:00
Title Minutes IETF106: tcpm
State Active
Other versions plain text
Last updated 2019-12-03

minutes-106-tcpm-00
TCPM meeting at IETF-106

Meeting  : IETF106, Friday Nov 22, 2019, 10:00 - 12:00 (Morning Session II)
Location : VIP A
Chairs   : Michael Scharf
           Michael Tüxen
           Yoshifumi Nishida
AD       : Mirja Kühlewind
URL      : http://tools.ietf.org/wg/tcpm/
Note Taker: Martin Duke

--------------------------------------------------------------------------

1:  WG Updates - Chairs

   No RFCs since Montreal, but many drafts are close
      converters : to iesg
      RFC793bis: early 2020 wglc
      2140bis (control block interdependence): more or less ready for WGLC.
      please read. rack: close to WGLC. PS or EXP?

         ->15 votes in favor of RACK as Proposed Standard. Zero votes for
         Experimental

      Gorry: why was this even a question?
      Yoshi: not many implementations.
      Praveen: Draft is complete, but it is not that readable. Needs an
      editorial pass. Chris (Jabber): Is this best done as a hum instead of a
      show of hands Mahesh: ++

      RTO-consider:Close to WGLC, needs a few more reviews.
      accurate-ecn and generalized-ecn: close to WGLC, a few more points.

--------------------------------------------------------------------------

2: RTO-consider feedback - Gorry Fairhurst:

   Gorry:
      now less TCP centric. it's readable, seems correct, sometimes vague.
      Does this update existing RFCs? - see slides for some other nits

   Welzl:
      leave "recent" [measurement] undefined

   Gorry:
      then get rid of the SHOULD

   Michael W.:
      but SHOULD nudges people to do it

   Jana:
      yes, let's define it better. A BCP should say SHOULD.
      There's also cc-guidelines, but Gorry says it's an unrelated document.

   Mirja:
      we did a great WGLC review, let's just get it out the door. These are
      WGLC-level comments

   Yoshi:
      you're basically OK with proceeding WGLC?

   Gorry:
      yes. these are non-blocking, except for the intent to update other RFCs
      (or not). does not conflict with anything else.

   Jana:
      I'm writing up review now, but I've carefully read it. Only one major
      question: is this a TCP document or is it protocol agnostic? the document
      precludes QUIC, which does not require retransmission. For TCP or for
      other protocols?

   Praveen:
      Jana, you still have retransmission in QUIC, no?

   Jana:
      True, but RTO is about loss detection, not retransmission. the scope of
      the document is just detection. that's what rto is for.
   Gorry:
      RFC 8085 says it applies to UDP-based transport and has the same
      guidance, so no problem.

   Jana:
      just get rid of the dependence on retransmissions; this draft is about
      loss detection.

   Mirja:
      seems poorly thought out, get rid of it.

   Markku:
      loss detection usually means retransmission, which involves congestion
      control. when there are only a few packets, evertyhing is timer-based.
      can be the region of congestion collapse.

--------------------------------------------------------------------------

3: ECN++ updates - Marcelo Bagnulo

   Marcelo:
      [ECN in control packets]
      Thorough review from Michael Scharf, many changes. mostly editorial
      Can only mark SYN ECT if also doing AccECN. In draft-05, now we can also
      send it if we send init_cwnd to 1.

   Markku:
      assume that AccECN is the only way to provide feedbacK?

   Marcelo:
      you can mark it if you have some way to get the feedback back (AccECN or
      something else in the future)

   Mirja:
      to generalize: if your window is 1 forever, you can mark all your packets

   Gorry:
      once per RTT or once per 3 sec (if you don't know the RTT)

   Jonathan Morton:
      If ECE is the sticky bit, can we leave it at 1 MSS? After the initial
      handshake, could record what happened during the handshake. Then increase
      above 1 once it's clear that nothing happened in the handshake. ECE is
      always set during handshake. thus after handshake you can see if CE was
      set, and if not restore the cwnd to something bigger.

   Bob Briscoe:
      how can you tell it didn't occur?

   Jonathan:
      because it's cleared.

   Mirja:
      not implemented that way. Will just disable ECN if you see it in the SYN.

   Bob:
      maybe it shouldn't but implmenters will correctly argue that this is 3168
      behavior.

   Rodney:
      it's on us if we don't fix it.

   Marcelo:
      Jonathan's suggestion seems reasonable, but many implementations will
      behave in an undesired way. So we can acknowledge these implementations.

   Jonathan:
      does behavior only happen on ECE?

   Mijra:
      if you negotiate with ECN with server,.... we should see if ECE is
      implemented as sticky. some implementations fall back on other bits.

   Marcelo:
      conclusion: need to verify a few things about implementations, but we are
      moving forward with Jonathan's suggestion.

   Mirja:
      if draft going to say "even without negotiating AccECN, you can set ECE"?

   Marcelo: yes

--------------------------------------------------------------------------

4: Registration Policy for TCP Header Flags - Mirja Kuehlewind

   Mirja:
      change registration policy to IETF review. must note experiments in
      registry. use it for experiments, but there should be sunset criteria. 4
      other options on slide

   Brian Trammell:
      i don't like any of the other options
      this document reflects reality, so good.
      we measured deployment of this compared to experimental options. using
      bits was easier than new options. fully support the draft.

   Gorry:
      implied "slow start" for internet-drafts. I don't like the drafts or use
      of keywords. don't like the details. "SHOULD discuss" -> "MUST discuss".

   David Black:
      full support of draft. As RFC 8311 author, this is great.

   Rodney:
      I agree with Gorry. only problem is "recent use" -- don't like words like
      'recent' in drafts. how to handle "MUST negotiate". find a way.

   Brian: some wordsmithing.

   Martin Duke: how would negotiation work if options are blocked?

   Mirja: there are other ways.

   Jonathan: ?

   Bob Briscoe: nonce sum was set on the SYN. receiver didn't have to do
   anything about it.

   Mirja:
       I think jonathan is right but i don't know the implications of it for
       the draft. you must need "some way" of negotiation. doesn't say how.

   Jonathan: discuss semantics offline.

   Mirja: nonce did not do a good job, not sure how nonce messed it up so bad.

   Rod: we've discussed this enough. we should look at some possibilities but
   it's a good start.

   Bob:
      makes sure "EXP" in the draft makes it more reversible. add that the WG
      must be clear that exp status is just to get a codepoint. must prove that
      it's reversible.

   Gorry: +1.

   Mirja: negotiation would make it reversible.

   Rodney: MUST be deployment/de-deployment plan

   Mirja: negotiate meaning of bit, not use of bit.

   Jana: why is this confusing? we should adopt. plan for deployment is not
   deployment. when checking for reversing, look it it's been deployed.

   Mirja: the draft says it

   Bob: nonce was only deployed on one testbed, but took 19 years to establish
   that.

   Jana: depends who you ask

   Mirja: only because no one was interested for 15 years

   David: +1

--------------------------------------------------------------------------

5: AccECN clarification - Bob Briscoe

   Bob:
      like SACK updated acks
      3168 ECN is just existence of congestion, not extent. one per rtt
      3 bits encode CE packet ct. CE bytes in a supplementary option.
      this is crucial for low latency
      added another option type to allow different ordering of fields, so we
      can omit ones that haven't changed

   Rod: either solution would work

   Mirja: use the initial value to identify the field.

   Jonathan: 6 permutation of 3 fields

   Jana: how big are fields

   Bob: 24 bits

   Jana; don't design this at mic

   Mirja: bit can wrap around

   Jana; just use 3 bits of state

   Duke: would it be routine to only have 2 fields

   Bob: yes

   Martin Duke: then i support it. option space is scarce. probably a good
   encoding but I'll send it to the list.

   Rod: +1

   Bob: have to fix language about optional options -- what to do in each case.

--------------------------------------------------------------------------

6: Procedual discussions for AccECN and ECN++ - Chairs

   Yoshi: how should we proceed on AccECN, ECN++. do we have remaining tech
   discussion points?

   Mirja: decouple to proposals. ECN++ needs AccECN, but not the reverse.
   AccECN should go first.

   Praveen: (to Bob) what was outcome of dctcp feedback discussion?

   Bob:
      we consdiered a separate draft that provided another negotiation. many
      companies are using dctcp feedback, accECN would be a transition problem.
      can we use AccECN negotiation but still DCTCP-style feedback? we said
      yes. use different initial ACE counter values. we could set up an IANA
      registry for the 3 ACE bits.

   Yoshi: too much tech discussion.

   Bob: the DCTCP thing would have been a separate draft, so not a WGLC stopper

   Praveen: that draft is important. offer to co-author

   Mirja: yes, it should be in a separate draft.

   yoshi: questions about bit 7, dependency between multiple ecn proposals. I'd
   like to clarify before WGLC.

   Morton: SCE uses bit 7 but only when AccECN is not negotiated. ECE and CWR
   would retain RFC 3168 meaning.

   yoshi: (see slide "remaining points from chairs")

   Morton: SCE position is to use the registry

   Rodney: applying policy to bit 7 is fine, then escalate later, for an
   experiment.

   Michael S.: another option -- make accECN negotiation a PS, then what comes
   after can be PS or EXP.

   Mirja: how would that work? you need a default behavior.

   Michael S.: iana registry is part of the negotiation. just put it in
   different specs.

   Mirja: if negotiation fails, fall back to default. what is the default?

   Bob:
      splitting negotiation from the spec uses the term "after". but there's
      reordering, etc. these are intimately tied together. not possible to
      really split. clean separation not happening with so few bits.

   Michael S.: i don't understand mirja's objection

   Mirja: you need negotiation to extend scheme, but there is a default scheme

   Michael S.: accECN is the default

   Yoshi: this is a preference argument. can we converge?

   Mirja: people want registration no matter what. but we can take a hum on PS.

   10 votes for PS. 13 for exp

   Yoshi: draft is written as experimental, would require revision.

   Chris Lemmons: shouldn't this be a hum

   Marcelo: this is not a split group. just publish it.

   Jana: do people care about document type? can you live with either

   Mirja: have to publish registration

   Yoshi: do people support mirja's draft (12 vs. 0)

   Martin Duke: which is easier? PS or EXP

   Jana: equally easy

   Briscoe: somewhat may object to Mirja's draft

   Rod: do both tracks

   Gorry: AccECN only changing one thing. Good for PS. shouldn't gate on
   mirja's draft. people are implementing and it'll be sticky.

   Michael S.: PS means no dependency on IETF consensus

   Jana: +1 PS is faster

   Yoshi: does this terminate other ECN experiments?

   Jonathan: other uses of bit 7 do not conflict with AccECN

   Jana: that's irrelevant to PS/EXP.

   Mirja: let's hum for exp/ps and the registration draft.

   Gorry: let's have a don't care hum.

   Yoshi: PS: 8, EXP: 2, don't care: 8

   Jana: this is not controversial. "don't care" = shortest path. Strong
   consensus for PS.

   Yoshi: chairs will discuss

   Mirja: didn't we choose path? room consensus is strong.

   Yoshi: what's the point of your draft if we put bit 7 in a PS?

   Mirja: still good for future draft

   Michael S.: need to confirm on mailing list, but I sense consensus in the
   room. registration draft is too late to adopt.

   Mirja: i accept the decision, but the dependency changes things. submitted
   late because I was discussing with chairs

   Bob: only change for PS is "other experiments" -> "experiments"

   Yoshi: is there any conflict with other proposals?

   Rod: still discussing this. would like more time before discussing in WG

   Gorry: is reporting ECT(1) possible in AccECN?

   Mirja: we can confirm there is no conflict.

   Rod: if we change accecn to PS, and negotiation fails, and the bit becomes
   available, then there is no conflict.

   Mirja: also true ECE and CWR.

   Yoshi: have to clarify that in draft

   Mirja: no, it shouldn't define what happens if it fails.

   Yoshi: we stil need to discuss more.

--------------------------------------------------------------------------

7: HyStart++: Modified Slow Start for TCP - Praveen Balasubramanian

   Praveen:
     deployed by default in windows 10.
     (see slides) 14-39% improvement in goodput., other positive things. in a/b
     testing in production. only one person has read it.adopt as informational.

   Mirja: do you want to add more experiments to draft?

   Praveen: no, that will go in iccrg or something

   Jana: applies to qUIC as well?

   Praveen: yes.

   Jana: should this be in iccrg? will you expand scope to QUIC?

   Praveen: might be a separate draft or added to qUIC rfc. I would just like
   to document this in TCP for now.

   Bob: will commit to reviewing.

--------------------------------------------------------------------------

8: TCP ACK Pull - Carles Gomez

   Carles:
      use a bit from the tcp hdr to force more acks.

   Jonathan: how does this differ from PSH flag?
   Carles: doesn't always work.