Minutes for TCPM at IETF-94
minutes-94-tcpm-3

TCPM meeting, IETF-94, Yokohama, Japan
Thursday, November 5, 9:00 - 11:30
====================================

Chairs:        Yoshifumi Nishida
               Pasi Sarolahti
               Michael Scharf (not on-site)

Note takers:   Christoph Paasch
               David Hayes

(minutes revised 2015-11-26 based on corrections and comments)

Chair Slides
-----

Transmission Control Protocol Specification
draft-ietf-tcpm-rfc793bis
Speaker: Chairs for authors
-----

- Background
- Changes since last meeting
- New Questions for Working Group
  Karen Nielson: Keep the API in the new draft?
  Pasi Sarolahti: Defer to mailing-list. API got discussed earlier but no clear
  conclusion. Karen: Would be good to clarify why the API is or is not relevant.
- Forward Plans

TCP Extended Data Offset Option
draft-ietf-tcpm-tcp-edo
Speaker: Chairs for authors
-----

- Status
- Current issues
- Issues...

Yuchung Cheng: Saying, TSO driver must not do something is not realistic. It's
not easy to change NIC's firmware. EDO is not going to be deployed

Praveen Balasubramanian: TSO implementations, code could...

Tom Herbert: There are variations in how TSO is implemented in different NICs,
which is going to have an impact on EDO.

Jana Iyengar: Addressing it as a MUST NOT is inadequate.

Datacenter TCP (DCTCP): TCP Congestion Control for Datacenters
draft-ietf-tcpm-dctcp
Speaker: Praveen Balasubramanian
-----

- Next Steps

Bob Briscoe: There is a machinery in DCTCP that still uses CWR. Sender sends,
but receiver ignores. Thus, CWR is not necessary?

Praveen: CWR is unchanged in the code, thus the reason why it is being sent.

Bob: If it's unused, don't use that codepoint.

Lars Eggert: Changing it in the draft is not gonna change the code.

Bob: Asking if you can change it in the code.

Pasi: We need one more review before LC.

Lars: Changes are not substantial. Only a change in the calculation of alpha.
LC should be done now.

Yoshifumi Nishida: Are there any concerns in the room?

Mirja Kuehlewind: Supports this, Bob has a review (yet to write and submit), we
have enough, go ahead.

Chair: Go to last call

TCP Alternative Backoff with ECN (ABE)
draft-khademi-alternativebackoff-ecn
Speaker: Naeem Khademi
------------------
- I-D's scope
- Status of the I-D
Mirja Kuehlewind: Doesn't support to have normative language in the draft
(thinks it is a mistake in the ECN draft). Hard to say what is right and wrong
for congestion signal.

Naeem: Why?

Mirja: Because it is difficult to say what's right, what is wrong. Because, the
state may change and thus the right answer might change

David Black: As one of the authors of RFC 3168: I agree that encouraging
Experimental for congestion control is a really good idea. 3168 was written for
the broad internet, hence contains some very strict language that basically
said don't do anything that would break things. We had people react to
congestion if you CE-mark as if you're dropping a packet, we said: the only
thing we know for certain is safe right now - this was a long time ago - was:
react to it as you would react to a packet drop. I'm not opposed to interesting
innovative things being done under the guise of experimentation, I wanna
provide some history for why 3168 says what it does.

Markku Kojo: Is there a reason why you are using cwnd and not flight-size,
because if you are app-limited, flight-size is smaller than cwnd. Thus,
flight-size has to be used in this case. 5681 says to use flight-size in the
congestion-response.

Naeem: I can't give any specific reason

Markku: The modification that is needed is not quite as simple as you have
proposed. Take it off line.

Naeem: Consult with coauthors.

Yoshifumi: An Experimental Draft cannot update a proposed standard.

Naeem: Requests feedback on tcpm and iccrg lists regarding value for beta

More Accurate ECN Feedback in TCP
draft-kuehlewind-tcpm-accurate-ecn
Speaker: Mirja Kuehlewind
-----
- Background & Problem
- History
- Overview AccECN
- AccECN Capa Negotiation
- The ACE field

Mirja: Add milestone and then ask for WG adoption

Praveen Balasubramanian: DCTCP performs well without option

Mirja: Provides number of marked packets, and option provides counter of marked
bytes.

Praveen: Introducing new options is always painful.

Mirja: We do not require the option in the SYN, but in the SYN/ACK to test the
path. And, option in the third ACK.

Brian Trammel: Why not send CE first? (slide 8)

Bob Briscoe: Your repeating the count of what will change most often

Brian: Accepts rationale

Karen: Why do we not go for proposed standard?

Mirja: Because, it's a new option and we know there are problems with it. But,
proposed standard could be fine as well.

Yuchung: What about ACK-suppression?

Mirja: If an ACK gets lost, it is OK

Yuchung: You are saying more robust to ack loss

Mirja: yes

Bob: You must send an ACK every 6 times for CE markings.

Mikael Abrahamsson: Is the code usable for experimenting?

Mirja: It's not yet well tested. The big "issue" is that now it sends the
option on each ack. future will change this.

Karen: In SCTP there is something similar. Should we work on both in parallel?

Chairs: How many people are interested in putting effort into this?
(only two hands)

Mirja: There is not much work left.

Chairs: Why don't we wait another couple of IETFs

Karen: Willing in reviewing it. Many people are not here, so let's not judge on
the audience

Gorry Fairhurst(jabber): I'll review this since I read the requirements
document.

Mirja: Not changing TCP behaviour, only the feedback mechanism. Like a hum on
adding a milestone

Lars: One of the pieces under TCP Prague. When this is laid out more it will be
clear how this will be useful.

Mirja: DCTCP is a usecase

Lars: DCTCP doesn't need this, it is a new way to provide the same information.
Not saying don't do it, just explaining why WG isn't as keen.

Brian: I'll review it. Value to doing experimentation with this (HOPS hat).
Supports bringing this in now.

Tommy Pauly: Also review it. Interesting work.

Chair: Hum for adoption. Adoption convincingly supported. Taking it to the
mailing list.

"Sharp Close": Elimination of TIME-WAIT state of TCP connections
draft-kitamura-tcp-sharp-close
Speaker: Hiroshi Kitamura
-----
- For Next Steps

Karen Nielsen: We have the same problem in Er. We have made TIME-WAIT
configurable, and about 2s for the same reasons that you have outlined.

Lars: There is a '99 SIGCOMM paper about faster closure. There are other things
that can be done, let's assess this.

Yoshi: If you use the linger-option, you send a RST and you eliminate TW on
both sides.

Karen: We did some analysis. I'll come back with more info on the list.

TCB sharing: RFC 2140 vs. reality
draft-welzl-tcpm-tcb-sharing
Speaker: Safiqul Islam
-----
Lars: "Cached" means cached and shared.

Safiqul: Would like to have windows esp. windows and mac or corrections to
linux and freebsd

Lars: 2140 was informational, it was a research idea. And kind of similar to
SPDY.

Chairs: Status

Safiqul: possible rfcbis document

Lars: 2140 informational. CCR paper on this as well. Sharing of cwnd is
interesting. Chair: Informational or other

Safiqul: Discus with authors on how to proceed.

Yuchung: Google has had caching/sharing turned off for a few years

A-PAWS: Alternative Approach for PAWS
draft-nishida-tcpm-apaws
Speaker: Yoshifumi Nishida
-----
Lars: Any option that gives back option-space is useful.

Yuchung: Today Linux & Mac use TS by default. Using 10-12 bytes is annoying,
but not a big deal. Will this incentivize Windows to use TS?

Praveene: This would make it easier to support TS, but right now there is no
incentive.

Tim Shepherd: If we don't care that data gets corrupted, we don't need
timestamps. We don't need to worry about seq-number if the connection does not
wrap. I do not think we should ignore segments that are older than 2MSL.
Because, there is no guarantee on the internet about 2MSL.

Praveen: For things like ledbat, it is good to compute one-way-delay, and TS is
useful there. Have you thought about adding an option to facilitate this?

Lars: There was a paper that measured RTT's on the Internet at IMC --- found up
to 180s.

Increasing Maximum Window Size of TCP
draft-nishida-tcpm-maxwin
Speaker: Yoshifumi Nishida
-----
Yuchung Cheng: Sure. But is there a need to do that? The current scale still
works for the highest speed network I know.

Yoshifumi: Google DC in Japan to Google DC in US

Yuchung: OK

Bob: Whatever you need today is irrelevant as speeds are increasing more and
more. Doubled every 1.5 years.

Christian Huitema: What we are doing here is to just double it. Following Bob's
argument, at one point we need a 64-bit number.

The RACK fast recovery
draft-cheng-tcpm-rack
Speaker: Yuchung Cheng
-----
Christian: When getting an ACK, you do not know whether the ACK got received
because of the retransmission or because of reordering?

Yuchung: Good point. This is discussed in the draft. Timestamps allow to diff
between retr. and duplicate/reordering. If no TS, we can infer this by using an
RTT-heuristic

Yuchung: Like to get community feedback on observed reordering

Mirja: When you detect a loss, you also trigger congestion-event?

Yuchung: Yes

Yoshifiumi: What about pipe-size during recovery phase

Yuchung: Our algorithm does not change the congestion-control. It just changes
the trigger for loss-recovery.

Yoshi: Isn't it more aggressive?

Yuchung: [missed the answer]

Anna Brunstrom: Do you have measurement results regarding the effect?

Yuchung: Yes. I'll include more data in the draft We were able to improve
loss-retransmits by 2 to 3 times compared to RTO.

Jana: This is what is done in Quic. And it helps a lot.

Karen: It's the natural evolution of the protocols. Similar mechanism in SCTP.

PRR (RFC6937) and traffic policers
No draft
Speaker: Yuchung Cheng
-----
Ethan Katz-Bassett: We looked at ?NDTD? data. Steady declines in policing.

Yuchung: Still quite common

Ethan: Yes

Mirja: More explanation on "without detecting further losses"

Yuchung: Only if the ACK does not indicate that a retransmission has been lost.

Mirja: Does the loss of retransmission trigger a reduction of the
congestion-window?

Yuchung: Not in Linux

Mirja: Maybe it should

Yuchung: From an implementation point-of-view, it is really hard to do this.

Mirja: Reduce ssthresh when you don't want to reduce cwnd?

Yuchung: Good idea.

Jana: ? loss coding problem ??

CUBIC fix in QUIC and Linux-TCP
No draft
Speaker: Jana Iyengar
-----
Lars: We are looking for new authors for the cubic-draft - you can take the pen!

Jana: Happy to look at the ID.

Yuchung: Linux-bug was hidden, because Linux's cubic limits the increase to
slow-start.

Praveen: ??

Jana: Seen in youtube type sending

Praveen: Slow start after idle?

Yuchung/Jana (?): At Google, slow-start-after-idle is disabled (use pacing) -
as most CDNs do.

Chair: Does cubic draft have this?

Jana: No

Lars: We need someone that monitors netdev and updates the Cubic-draft.

Mirja: What is the state of the document - how are we going to keep it in-sync
with the Linux imlementation.

Lars: It exists, updated once. How to maintain as linux moves forward. But
better than now where there is no standard that describes linux

Jana: Informational

Karen: I thought cubic draft was going to describe cubic as an algorithm and
not cubic the Linux implementation.

Lars: Document could provide description of the best possible implementation.

Tim Shepherd: Cubic by default also does hystart. Does this also describe
Hystart?

Lars: yes

Tim: Suggest name change to cubic and hystart because they are two different
algorithms.

Deploying TCP Fast Open in the wild
No draft
Speaker: Christoph Paasch
-----

Bob Briscoe: How often are you finding these problems?

Christoph: Rarely, but fixed it with the vendor

Mikael  Abrahamsson: How do you define what is a network?

Christoph: Client knows

Tom Herbet: Changes client side or servers

Christoph: Blacklisting is done on the client side. Each client has to do the
probing.

Brian: Can we see the black list?

Christoph: We don't have the black list - on the client

Brian: Can some results come to HOPS?

Yuchung: linux netfilter doesn't check data in syn (old fixed linux bug), but
some boxes running it.

Bob: Conntrack bug. Surprised it is only 0.1%

Andrew McGregor: Depends on how conntrack is configured. Although in netfilter
everywhere, cases it is configured are probably relatively rare.

Praveen: Is the blacklist permanent?

Christoph: Yes at the moment, but it will be tuned as we gather data.

Jana: 0.1% is not really low for TFO, but high!