Minutes for TCPM at IETF-96
minutes-96-tcpm-1

TCPM meeting at IETF-96
Berlin, Germany
Monday, July 18, 10:00-12:30

Chairs: Michael Scharf
        Pasi Sarolahti

Notes: Gorry Fairhurst
       Brian Trammell

1. Agenda discussed.

2. WG status

For slides, see meeting proceedings.
RFC793bis - Update by Wes later in the meeting
EDO - Joe has new implementation work
DCTCP - Update posted this morning - Please read and note any concerns (WGLC
may come soon) Cubic - There is a pending update - Please read and note any
concerns (WGLC may come soon) Acc ECN - Updated

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

3. Working Group Items

3.1 Wes Eddy (Chairs update for editor) - RFC793bis
Draft: draft-ietf-tcpm-rfc793bis

No questions.

3.2 Mark Allman (Chairs update for editor) - Moving forward
draft-ietf-tcpm-rto-consider Draft: draft-ietf-tcpm-rto-consider - Slides
prepared by the Chairs.

Various topics raised on the list were presented - see slides.

The chairs asked if the change of MUST to SHOULD in relation to RFC6298 needs
to be marked in the IETF series as an UPDATE?

Mirja Kühlewind: If this document applies to TCP, use of RFC6298 is a “MUST”
for TCP.

Pasi: Does this allow wider experimentation?
Mirja (as AD): That depends on what it says in this document.

Christian: The present algorithm in RFC6298 is a compromise between
implementation and protocol. I think the “MUST” use requirement is a weird,
this is based on what hardware was available 30 years ago.

Pasi: The question remains.

Pasi: Should the RTO considerations refer to RFC5405bis as a reference for UDP
designers from this draft?

David Black: I think the answer is “yes”. I think the ID in TCPM is a good
document for design of mechanisms, and this should proceed here. However, the
normative statements for using UDP belong in RFC5405.bis, and recommendations
for UDP belong there or in TSVWG drafts.

Pasi: OK. We should take this forward in that way, and finish this work here.

David: I agree. RFC5405.bis has passed IETF last call. I do not want to be
standing at a microphone queue in the Seoul still discussing the UDP Guidelines.

David B: I had problems with the original text presented and then made
suggestions to improve the text, as reflected in option 2.

Lars Eggert: I support removal of the “Future implementation freedom” text on
the slide.

Gorry: I also think we need to remove this text. The ID should encourage people
to publish drafts that document what they will do or have done. I do not like
the idea of encouraging future changes that do not need to be documented in the
RFC-series.

David B: I do support removing this.

Mirja: There will be another update, and I think choosing to use normative
language to describe informational procedure.

Pasi (as Chair): OK. We now have feedback for the editor.

Lars: This is a TCPM WG item and Mark is a WG editor - so the Chairs will need
to relay things to the editor to reflect the consensus.

David (as TSVWG Chair): TSVWG plans to update the text. There will be a
deadline to commenting on this topic.

Michael (as Chair): The ID will be last-called in both TSVWG and TCPM.

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

4. Other Items

4.1 Yuchung Cheng - Updates of RACK Linux implementation
Draft: draft-cheng-tcpm-rack

Lars: What happens if you have a variation in the base RTT that is greater than
reo_wnd? Some paths do have varying RTTs. It seems this would result in
spurious retransmission?

Yuchung: Yes, there can be cases of many losses.

Jana: You could also measure variation of the RTT and use this to select a
“reo_wnd” that is more like a maximum.

Yuchung: There is a surprise benefit in reducing TSO fragmentation (fewer SACK
merge events).

Lars: Do you have stats on how many extra transmissions are commonly observed?

Yuchung: This is around 0.5%

Randall Stewart: We are also playing with RACK at Netflix using a BSD
implantation, and also see similar benefits - and an additional benefit that
RACK can recover from all loss patterns - previously TCP mechanisms had some
patterns that were hard/impossible to recover.

Praveen Balasubramanian: I think this is good work, we have implemented RACK in
Windows.

Lars: I would like to see more data because this is a core mechanism for TCP.
Come and share results and experience with the IETF - either here in TCPM or in
ICCRG.

Christian: I think the actual intention is to replace the DupACK?

Yuchung: Yes.

Ingmar: I found the RACK spec easy to understand. A change in how we detect
loss will impact design of the network: Current 3G stacks typically try to
preserve ordering, this in sequence delivery requires mechanisms at layer 2.

Yuchung: ??

Gorry: The present method of using DupACK serialises the protocol packets on
the wire is very robust to very unusual paths, since it eliminates the impact
of timing variations. If we do RACK, we need to keep in mind that TCP needs to
be robust to the most unusual paths we encounter, and not design just for
performance of the most common path. Robustness is important.

Lars: Can we give a guidance on the reordering window that would be best?

Jana: This moves from sequence number to space time.

Praveen: Should we ever discard the min_rtt measured, e.g., after a timeout?
What about path changes?

Yuchung: We think the min_rtt is still a number that was measured, and only
discard after over the last 5 minutes.

Praveen: I think the rules for discarding the min_rtt should be in the draft.

Praveen: What about when one TCP session shares multiple paths?

Yuchung: Yes, this sometimes happen (e.g., under extreme load).

Christian: Reordering window is a key parameter. How do you set the parameter?
We need need guidance on choosing this parameter.

Yuchung: Packets are reordered in a RTT. It is hard to judge whether we should
set the window at 1/4 RTT or something.

Christian: This is only vaguely related to the RTT , what if we have multiple
paths used at the same time?

Randall Stewart: We could make RACK reordering-adaptive.

Yuchung: I tried, but I could not see the best algorithm, we need more work on
this.

Michael Scharf (WG Chair): What is the relation to Tail Loss Probe (TLP)?

Yuchung: Both can be done at the same time, and this can simplify the
implementation.

Michael Scarf: Can we then also merge the documents?

Yuchung: We could merge these in future.

Christian: I do not know of issues when implementing both specs at the same
time.

Praveen: I think TLP can also be implemented just on its own.

Andrew McGregor: I think the mechanisms are orthogonal.

-: It can be more important to have simpler documents.

Michael Scharf (as WG Chair): How many have people in the room have read the
RACK ID ? (about 10)

WG Chair: Do you think RACK should become a WG item? (about 20)
WG Chair: How many people think the WG should not do work in this space? (0)

WG Chair: Do you think we should immediately adopt this item? (10+)
WG Chair: Do you think we should defer to see how TLP could integrate? (0)

Pasi (as WG Chair): I think we look to an EXP publication, if we proceed.

Jana: Does the header of an EXP ID need to list drafts it updates in the header?

Gorry: I suggest we note which RFCs are updated in the text, but do not list
list the update in the header, I think we need to wait until the experiment is
over - only a PS should update other PS RFCs.

----------

4.2 Praveen Balasubramanian - Transport advancements in the Windows networking
stack

David S: When you say “all outbound” TCP-Fast Open, do you mean all outbound
connections using FO with TLS?

Praveen: Yes.

Bob Briscoe: What was the correlation between servers that did not accept a
TCP-FO and did not do the correct thing?

Praveen: There was no statistical evidence of problems. There were no more
drops than for other SYN drops (e.g., drops die to under load.)

Jana: I like the experimentation. Is there a link to the current API? I would
love to be able to use a common API? and see I would love to see Fast Open
logging data - that would be really interesting.

Praveen: Currently the only error feedback is a single burst.

Gorry: When you see IW10 has problems, have you considered caching the use of a
lower IW, rather than just changing the cwnd for the session? This would avoid
repeatedly probing with a larger IW for each session?

Praveen: We are looking at options for keeping it between flows, but there also
can be cases this can be very conservative.

Praveen: What is the delayed ACK procedure in Linux?

Neal Cardwell: Linux has been using 40ms for some time, it does try to
determine if the flow is a bulk flow and adapt.

Bob Briscoe: Under what cases does RACK not help?

Praveen: For example, too small a RTT causes implementation challenges with
timers.

Ingemar: Do you need to infer the timestamp clock on the opposite side?

Praveen: That is something we need to deal with.

Ingemar: I also saw issues when IW<4 segments.

Bob: The interesting thing is that Remy only changes the algorithm, if you
change the protocol you can do even more.

Lars: We did standardise on New-Reno, there are now multiple co-existing
methods.

Praveen: There are tradeoffs in the network.

Ingemar: Throughout and delay can be tuned. Most LTE networks use AQM.

Dave Täht: Answering these two questions would need beer to proceed.

Michael: This discussion should be continued in ICCRG.

Lars: Thank you to Praveen and others for providing the WG with experience with
real implementations!

---------

4.3 Naeem Khademi - TCP Alternative Backoff with ECN (ABE)
Draft: draft-khademi-tcpm-alternativebackoff-ecn

Bob: I was thinking last night about this... Cubic is used as a justification
for this, but this does this for a high bandwidth case.

Roland Bless: I think there is value in this. If we have many flows sharing the
bottleneck, you could then have many flows that use a bottleneck, so you can
adjust beta - but that is hard to figure out in practice.

Roland Bless: You can keep the utilisation high if you do this.

David Black: The TSVWG draft seeks to remove the constraint to allow this
experimentation.

Pasi: ...

Colin: There is also work in other IETF areas that also rely upon ECN. We
should also consider other uses of ECN (e.g., UDP-based protocols) and we need
to evaluate all of these together.

Markku Kojo: I support doing work on the current draft in TCPM.

Markku: I think the current form of relaxing this in TSVWG is dangerous, it
would allow any form of update to ECN.

David Black: I would like to see the TSVWG draft say that the IETF retains
control of proposed uses. I think this is a good topic to take forward at the
TSVWG meeting.

WG Chair: How many have read? (10)

WG Chair: Please hum if TCPM should allow work on this in TCPM (moderate hum
for) WG Chair: Please hum if you think TCPM should not do this work now (no hum
against)

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

4.4 Michael Welzl - TCP Control Block Interdependence (2140bis)
Draft: draft-touch-tcpm-2140bis

Jana: This is interesting. Do we have data to support this as a BCP?

Michael W: We have data from BSD and Linux, but many of the params are not
shared (only ssthresh).

Praveen: We should probably include windows, we share PMTU and FO cookie.

Yuchung: I think we should not do this. Linux experience suggests there can be
negative implications with caching.

Michael W: It depends on the use case, the draft does not always recommend
caching.

Yuchung: That is my point. There are a lot of caveats in how you use these
parameters. Google

Michael W: This is starting a discussion about all parameters, and identifying
useful values.

Yuchung: This documents the pros and cons of each.

Pasi: This could be informational.

Jana Yiengar: Is the recommendation to recommend best practices for caching.
Saying something about how, why or why not - sounds useful.

Michael: There is value in documenting the implementations, there may be
opportunities to modernise the wording. You can make significant improvements
as you edit the document.

Pasi: Can you please add a section on key differences between the draft and the
original RFC.

Michael Scharf (WG Chair): We are not doing an adoption call at this time.
Please continue to update.

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

4.5 Carles Gomez - TCP over Constrained-Node Networks
Draft: draft-gomez-core-tcp-constrained-node-networks

Lars: Is the local interface MTU not already setting the MSS?

Carles: This is less than the minimum MTU for IPv6.

Matt Mathis: We are missing a specification about the relationship between MTU
and MSS.

Michael S: We will probably see several topics that will generate questions.

Brian Trammel: These are constrained nodes? Do they care about the additional
energy costs of keep-alives?

Carles: There may in some cases be no other choice.

Lars: I think this is too much in one document. It mixes things that conflict
with the existing TCP RFCs, highly optimised RTO with other simplified
mechanisms. Saying not to use existing mechanisms is a big issue.

Gorry: This is a complicated mix of things, trying to simplify complex
mechanisms may  not be a good way to proceed. For example, you say using a
window of 1 and choosing ECN, that does not seem possible to work properly.
Maybe it would be helpful to start with a really simple subset of TCP, and
think separately about adding what you need.

Carles: ECN is a recent addition.

Gorry: It may be impossible to do correctly with only one packet per window.

Colin: In general, we should avoid thinking about requiring not to do things,
that prevents evolution.

Lars: Have you thought about using TFTP to meet your (simple) goals?

Carles: Will look at this.

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

4.6 Marcelo Bagnulo - Adding ECN to TCP control packets
Draft: draft-bagnulo-tsvwg-generalized-ecn

Brian: We need to still have mechanisms that allow us to differentiate paths
that work, but if we make measurements harder, we may also eliminate options to
probe to determine the path behaves as expected - that may prove an issue for

Dave That: There are protocols that would be benefits for other protocols if
you let excess packets be dropped.

Marcello: You can also drop ECN-marked packets.

Bob: In a normal regime you do not want to drop SYNs.

Chairs: The document should be discussed on the mailing list.

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

5.1 Marcelo Bagnulo - Recommendations for increasing TCP performance in low RTT
networks Draft: draft-bagnulo-tcpm-tcp-low-rtt

No remaining time, please read this draft and send comments to the list.

The WG meeting closed.