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.