TCPM meeting at IETF 92
Dallas, TX, USA
Tuesday, March 24, 2015, 0900-1130

Chairs:
  Pasi Sarolathi (remotely)
  Michael Scharf
  Yoshifumi Nishida  (excused)

Minutes:
  Gorry Fairhurst
  Michael Welzl


1. WG Chairs Presentation

* TCPM status

Agenda was agreed.

Michael Scharf (Chair) reviewed rechartering to clarify scope of new work items.

Aaron Falk: Is CC running over UDP out of scope?

Michael: Yes, it was intentional to keep this out of scope for TCPM.

Martin S (AD): This is with IESG, currently there are not many comments.

Michael reviewed status of all drafts.


2. Working Group Items

* draft-ietf-tcpm-newcwv (Gorry Fairhurst)

Wolfgang Beck: This should include implementation advice. I had to struggle with 2 TCP implementations of major vendors, one was a freebsd implementation. Both had problems with in-flight capacity estimaitionon when TCP flows are bi-directional and when ACKs contain data.

Gorry Fairhurst: OK, we’re interested in implementation in general, please send the comments via email.

Michael: There is expertise on the list - please bring this up.

Michael: How many people have read the most recent version of the document?
(6 or 7 people in the room)

Please read and send any comments during WGLC.


* draft-ietf-tcpm-rtorestart (Anna Brunstrom)

Michael Tuexen: The title says this applies to TCP and SCTP - do you imagine that this can be applied per socket, which is normal in SCTP?

Anna: I think for experimentation you can just turn it on system-wide. This is the way it works at the moment.

Michael T: Normally I would let applications choose to use this. We can control this per socket, i.e., the method in Nagle.

Anna: I am not sure this is the same.

Michael T: If this is something that an application may control? We could add a socket API section.

Michael Welzl: I do not think we need a socket option to do this - there is no application-specific tuning.

Anna: It could depend on the application send pattern.

Michael T: This is different to Nagle.

Mirja Kuehlewind: It may be good to configure this.

Karen Nielsen: This is something we may want to configure. We probably would not want to configure it on a per-association basis but maybe some nodes want to turn it on and others not. We would implement this configurable.

Anna: On a system basis or as a socket option?

Karen: I think socket option makes sense.

Gorry: In TSVWG, we would normally do this for SCTP. We would add an informational section that describes the actual socket API that is really implemented. Talk to implementer and agree a name.

Michael T: For SCTP, we would do a concrete socket option. If you specify it for SCTP we can guess what it is for TCP.

Karen: We do see problems with APIs for TCP, and it would be good to see documentation in the RFC series.

Michael S: Difficult with TCP, e.g. in the MPTCP working group there was pushback on a socket option. Proposal of APIs does lie within the charter.

Michael S (Chair): Sense of the room whether we should add the section on SCTP API description?
(equal hums for and against adding an SCTP API section)

Anna: what about TCP?

Michael S(Chair): We should decide on whether to add an TCP API description after we have decided on the SCTP status. We need to decide SCTP first.

Gorry (TSVWG Chair): We should briefly state this in TSVWG - where other drafts relating to SCTP are maintained - perhaps a short heads-up at the meeting this week.

Michael S (Chair): Yes, please email both lists on this one topic.


* draft-ietf-tcpm-undeployed (Richard Scheffenegger)

Martin S (AD): Moving things to Historic can be done so by IESG action. Things that are not well-defined cannot be easily changed to Informational - this may resubmission of an RFC. Probably the right thing is to leave them in the state they are.

Richard S: There are anomalies in the updated status for one RFC. The special case is the item below on slide 6, superceded by RFC1122 but it doesn’t obsolete them.

Martin S (AD): For this case, we should see if we can change the meta data. I will find out what can be done.

Bob Briscoe: The judgement on whether to make them historical is not easy. E.g. why would 896 be historical?

Richard: Superceded by 1122.

Bob: Maybe mention it’s updated by someone else without re-issuing the RFC?

Richard: That’s the question that Martin will figure out.

Michael S (Chair): We will await inputs from our AD on how to proceed.


* draft-ietf-tcpm-tcp-edo (Wesley Eddy, on behalf of Joe Touch)

Matt: How does it cause retransmits? Are there checksum errors?

Wes: I think so, we are looking into details.

Bob: Useful to establish how much resegmentation is done on the Internet. You are unable to control GRO on platforms beyond your own interface.

Andrew McGregor: Move to testing with 10gig

Wes: There is no general guidance on when to coalesce

Jana: GSO is a specific case of middle boxes that do coalesce.

Wes: I see this as an implementation pitfall. One question is how to detect corruption, such as a checksum or some other method (e.g., John Leslie’s proposal)

Bob: We are implementing Inner Space at the moment on FreeBSD.

Christian Huitema: We should add this as one of the things to be measured across Internet paths.

Jana: I do not think this is implementation, this is deployability. If we can’t detect failures we’ve lost data integrity.

Wes: It is not a difficult to detect the problem.

Tom Herbert: Is this in Linux? GRO is important and can be fixed.

Matt: Depending on checksum errors is not good enough. It’s easy to have test cases that can not be detected.

Wes: This only needs one detected problem to allow this to be turned off.

Andrew McG: There are two forms of GRO in Linux - hardware or software. It can be hard to make hardware do the right thing.

Aaron: There is evidence that shows that checksums will corrupt and then get passed up to the app, so you should default to off. Design question not runtime question, as that can happen at any time. Checksum is not going to be sufficient.

Wes: There are two code bases, we would like to see others help and test.

Michael S: We can offer time to discuss data that would help us move forward.

Tom H: Have you tried TSO and GSO?

Wes: I think TSO copies the data into all segments.

Tom: H: Did you need to disable TSO? TSO works best if we blindly just copy. Don’t want to force it into having to understand options. (Doing a checksum sometimes is complex, just copying is simple.)

Richard S: There may be a workaround for some extended options. Can give the TSO engine a set of data descriptors each of which have the same header. If you need to have EDO enabled you can instruct the hardware to put it on, one packet at a time. One the receive side, the hw will slow-path on "unknown" tcp header bits (which currently includes ECN-related bits). Thus having just one bit in the header for segments which have the EDO option may be one possibility. Not efficient but possible.

Bob: Is this new hardware that understands some data are options? EDO overrides the data offset.

Andrew McG: The hardware concatenates the header. There is no understanding of TCP options

Richard S: True, and does not know the data offset.

Michael (Chair): One high level question is whether we need to change the option format to include some checksum coverage, or take some other approach. Deploying this as we see today may not be possible, we need further experience with this, and find solutions so that other working groups may leverage this. We are not able to discuss the status question yet.


3. Individual Drafts

* draft-eddy-rfc793bis (Wesley Eddy)

Matt M: one of the issues is that there were details discussed on the mailing lists that did not make it into the RFC.

Wes: Can you point this out? It can be hard to find things. Most of these things will turn out as out of scope, there should be no new consensus.

Tim Shepard: Is the intent to preserve all of RRFC 793?

Wes: I tried to redo the introduction, but the normative spec is preserved.

Tim: Would we obsolete 793?

Wes: Yes I think so

Martin: The document updates the spec and refers to the (now) historic document.

Michael S: This is in the document.

Richard: We actually did this in the same way in 1323bis, obsoleted the old one and insert text in the new one

Dave Borman: It could be copied to the appendix.

Wes: RFC 793 was originally good to learn about TCP, but now there are textbooks, other ways to learn about TCP

Tim: Yes but also different. Books can be wrong. Figure 1 is great, is that going away?

Wes: Yes

Tim: That’s very sad.

Wes: Not up to date. Doesn’t show IPv6, doesn’t show things that have changed.

Tim: Doesn’t need to

Mirja: I would like this document as short as possible, the old text does not go away.

Matt: Do you mention DSACK - this is good to detect bugs. 

Wes: We say should do RFC793 with DSACK, but does not describe DSACk algorithms.

Bob: How do we deal with specs that do more than one thing in the same document? 3168 is a good example of where it covers TCP and other stuff. If you update it people get confused about what you’re updating.

Wes: I tried to change text as little as possible, but will think about this. 1122 has that problem even worse

Bob: Multiple parts rather than one monolithic thing? May be a better way

Wes: Probably would be more prone to doing what I was trying to avoid: not writing new text, not introducing errors in the process.

Jana: For implementations that do 793 but don’t do some others, what happens to them?

Wes: 1122 has a checklist of things you need to do, must conform with that already. Nagle is another example.

Tim S: Can we obsolete parts of a previous RFCs?

Wes: Probably not. Obsolete 793, update 1122.

Martin S (AD): We can not obsolete parts.

Wes: We can say which bits are obsolete, but can’t mark the document

Gorry: We can mark this as updates specific sections?

Wes: We can do that.

Yuchung C: Is Nagel defined in this, or in RFC 1122?

Wes: It will be here, and we will update RFC 1122 (and include the TCP things here). The goal is to reduce the number of documents.

Mirja: Make sure to get the right piece of text by involving people who wrote the documents.

Brian Trammell: I will review this, I think it is important to do. There needs to be text that’s very clear about what it doesn’t change. Text like "Don’t worry, if you implemented this other thing, don’t freak out."

Aaron: I’m in favor of this document, it is a good idea. Relationship to roadmap rfc?

Wes: Useful to refer to. I don’t know if we catch every single thing but we can get very close. RFC editor database captures a large subset of what needs to be captured but we cannot solely rely on that.

Aaron: I suggest to have Bob Braden to look at it. And look at Stevens book.

Kevin Fall: Stevens book updated in 2011 after 7 years of work. I even rewrote the pictures so that it fits the latest version.

Tim S: I support this.

Jana: I support.

Michael S (Chair): This falls within the Charter. The real challenge is to ensure this is reviewed comprehesively. We will need reviewers from multiple angles.

How many people would offer to review?
(10 people raised hands).

We would like to know if TCP should adopt his document?
(strong hum)

Any concerns about adoption of this?
(none).

The room consensus is clear support. We will start an adoption call on the mailing list.


* draft-borman-tcpm-tcp4way (David Borman)

Yuchung Cheng: In established state, can the client receive data at that point?

Dave B: Yes.

Yuchung C: Why is this not established?

Dave B: This is to do with reliably delivering options. Once you get past the establishment point it’s not reliable. In the handshake there’s an inherent reliable negotiation, so this is where option negotiation fits.

Tom Herbert: If you need to go to established state you require an extra round trip, the cost is high.

Dave B: You may need to order the options to negotiate some things first. We are trying to avoid an extra RTT to give robustness.

Tom: I think sending data while negotiating could be problematic. If you use authentication, you can not complete until this is negotaited.

Dave B: I wanted to minimise incurring an extra delay, when the additional space is not used.

Bob B: You start data while the handshake, there are issues - with TFO,IW=3, you have many segments. If you use IW=10, most of current connections will have finished, before the connection starts. There may be options you are trying to negotiate. Last time Lars stated the requirements was that you can have options on a SYN without increasing latency.

Dave B: It depends on the options. Not every option impacts the data. This approach is deterministic. This keeps everything in the context of one TCP connection.

Michael Welzl: Is it possible to implement this by doing simultaneous open?

Dave B: Yes, mainly did not do this because middleboxes do not like the SYN response. With midleboxes allow a bare SYN outgoing, but not incoming. The SYN-ACK is more likely to traverse.

Wes: You could cache, and start using enhanced SYNs straight away.

Dave B: If you have prior knowledge, then you can safely send this in the Initial SYN. A legacy option can become part of a TCP stream.

Yuchung C: What happens if the middlebox drops in the pre-established state?

Dave B: If the SYN-ACK is constantly dropped, this is a problem - which could revert to a 3-way handshake. We would lose the ability of these additional options. But that’s not in the draft.

Yuchung C: Some cases will need all options, it depends on the usage.

Dave B: It could be designed to allow this, but not currently in the draft.

Yuchung C: Yuchung: I think TCP state machine is really complex, updating this is a complicated task. I like the idea to continue negotiating options, but not adding states.

Bob: If you know the server has accepted this in the past and you use extended SYN options, you still have to have a fall-back. Can still do that, can send single SYN with extra option space and then fall back to 3-way handshake. This is solved.

Dave B: I like to have a solution that can do this within a single TCP flow, and how can we evolve. Introducing window scale changed the header.

Matt M: If you send options and retransmit, then this is tied to the sequence number.

Dave B: If you do not send data in the other direction the sequence number does not change.

Matt M: Is there any grounds for the idempotent approach of TCP, using Happy Eyeballs could be a solution to the problem.

Tim: This is the nicest, cleanest, easiest to understand solution. But we really want to negotiate options in the first round-trip time. Thank you for writing this down but the desire to squeeze out round-trips makes this proposal problematic.

Jana: +1 to Tim, extremely clean but the RTT problem is an issue. Would also be good to know how problematic the SYN/ACK returning might be with middleboxes.

Yeuchung C: I think the lack of SACK options is not a critical problem in practice. Not sure how to justify it’s useful to extend the option space for SACK.

Michael S (Chair): Need vendors to step up, need implementation experience. Some of these proposals are also beyond minor modifications, might not be the WG for it.

Gorry Fairhurst: We can discuss it even though we can’t adopt it here.

Michael S: Yes, this is the WG that can discuss these proposals to see how to progress.


* draft-nayak-tcp-sha2 (Brian Weis)

Matt M: What about DSACK? This does not take additional space. It redefines corner cases in SACK (previously unspecified). SACK can work with a single SACK block.

Brian: This could be a worse case.

Matt M: Well, SACK can fill all the space.

Tero Kivinen: You could truncate the number of bits (e.g., 96 bits) in the HMAC in this case. Can we make the hash variable dependent on the length field.

Brian W: There is no negotiation involved, it depends on local policy.

Tero: Based on TCP option length, if it’s something plus 12 then you know it’s a 12 byte long hash, if it’s 16 then it’s 16. So you could use a shorter one in the SYN packet.

Brian W: Interesting ideas. The length is security policy that people want to use.

Dave B: The MSS option is only in the first exchange.

Matt M: RFC5925 has a bug in the language about DSACK, I will file an Errata.

Andrew: BGP peering point is a generic host. Should look at generic stack. You could any number of things here, there are going to be wrong implementations in kernels.

Michael S: Would this be a natural fit for EDO?

Wes: I think you are unlikely to use GSO, TSO, in these platforms, you may be able to use EDO

Michael S: Do you have running code with TCP-AO? Would doing this increase deployment? PS specifications in TCPM typically have a high bar (e.g., unning code).

How many have read this draft?
(1)

Who is able to review this type of document?
(no current volunteers)

Michael S (Chair): This falls within the scope of the TCPM Charter. We are not asking for adoption now. I am interested in whether we can find reviewers who can review the spec and describe experience. You may be able to find reviewers from other communities who can discuss with TCPM to see this work progress.

Meeting ended at 11:35