Minutes for TCPM at IETF-94
TCP Maintenance and Minor Extensions
||Minutes for TCPM at IETF-94
TCPM meeting, IETF-94, Yokohama, Japan
Thursday, November 5, 9:00 - 11:30
Chairs: Yoshifumi Nishida
Michael Scharf (not on-site)
Note takers: Christoph Paasch
(minutes revised 2015-11-26 based on corrections and comments)
Transmission Control Protocol Specification
Speaker: Chairs for authors
- 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
Speaker: Chairs for authors
- Current 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
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)
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.
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
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
Speaker: Mirja Kuehlewind
- Background & Problem
- 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
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
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
Gorry Fairhurst(jabber): I'll review this since I read the requirements
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
"Sharp Close": Elimination of TIME-WAIT state of TCP connections
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
Karen: We did some analysis. I'll come back with more info on the list.
TCB sharing: RFC 2140 vs. reality
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
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
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
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
Increasing Maximum Window Size of TCP
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
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
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
Yuchung: Like to get community feedback on observed reordering
Mirja: When you detect a loss, you also trigger congestion-event?
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
Speaker: Yuchung Cheng
Ethan Katz-Bassett: We looked at ?NDTD? data. Steady declines in policing.
Yuchung: Still quite common
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
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
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
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?
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
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
Tim: Suggest name change to cubic and hystart because they are two different
Deploying TCP Fast Open in the wild
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
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!