• rohc-tcp: TCP header compression

Looking for input and document reviewers
rohc wants committed reviewers, so be sure to contact them if you want credit as one.

• F-RTO:

should be published shortly

• NCR:

approaching WG last call; new draft more understandable; technical input sought.

• ICMP soft errors:

being revised

• ICMP attacks:

will be discussed in Vancouver; revision in progress

• TCP antispoof

revision in progress; perhaps WGLC before Vancouver

Bob Braden: UTO is exactly? There's no idle timeout in RFC 793
Lars: Unacknowledged data time out.

Abolade Gbadegesin: How does this relate to SO_MAXRT?
Lars: That's an API for setting this locally. (later: maxrt is apparently defined in posix as a socket option) [After the meeting, Ted: I haven't been able to find it, but under FreeBSD and Linux, I believe the the sockopts to set UTO are SO_SNDTIMEO and SO_SNDTIMEO. Linux has sysctls to set the defaults tcp_retries{1,2}. XXX: Have I run these down correctly, or is there a POSIX sockopt I've missed?]

Bob: count retransmissions instead of waiting for X time to pass as per 1122 [in UTO negotiations].

Joe Touch: Conflict between description in document and consequences of actual defined semantics. Description says 'negotiate' etc, but setting is unilateral.

Bob: It might be in the spirit of TCP to coordinate in the apps, i.e. provide an API, and allow apps to do their own policy.
Ted: Hooks to do this [coordinate in the applications] are already there [in published RFCs], we intend to allow the stack to do it itself.

Abolade Gbadegesin: Makes sense to allow app to specify in real time units, have TCP figure it out in RTTs. Also, app doesn't know when this timer started, so it's hard to make use of this.

Tim Shepard: Sympathetic to the problem, but don't see that carrying an option to the other end is the answer. Why not allow maximum system-wide, allow apps to turn it down, and have policy on purging.

AG: How does knowing the other end's timeout help me cope with events? All that matters is my own timer.

Knowing the other end's timeout is of no use if I don't know that the other end has begun trying to send something to me. Typically, the only way to know the other end has begun trying to send something is if there's an upper layer protocol which gives me that information. But if I'm relying on an upper layer protocol to tell me when I should be expecting something from the other end, I may as well rely on that upper layer protocol to tell me the timeout as well. And in that case, I don't need UTO in the TCP layer.

Ted: Let's take these offline.

Jabber summary: jishac:

So I think a way of summarizing Tim's comment and resulting discussion on UTO is that there are a couple of ways of looking at this:

1. Current is that you have (in example on all of these numbers) a server that uses 5 sec but may be able to support a day dur. for some connections. UTO gives an app a way of requesting some of those resources



2. Server grants a higher dur. (and thus resources) to all connections but has a smart way of purging connections. and one may argue that the purging will be required with 1 anyways

Presenting test results showing reduction in spurious retransmissions due to use of Eifel and F-RTO.

Bob B: is this intended to be published?
KY: yes, that is the intention. [See slides for papers, Ted encouraged them to post to lists]

Greg Daley: asking about number of runs when measuring spurious TOs.
KY: don't have that number, "a lot"

Markku, Helsinki U: (co-author of F-RTO draft) interesting findings, similar to our results in an emulated network, we could make delay spikes quite frequent, which makes this much easier to see. It can be the case than when window is open, the RTT is longer and that is why we see more retransmissions due to a delay spike.

Summarizes draft looking at mechanisms for forcing probes for connections with outages longer than an RTT. [See slides]

Draft does not define specific connectivity indicators (as in, triggers for this behavior). Idea is that they be local, not deep in the network.

Basic idea, send away if you have a connectivity indicator.

Implicitly, signal with triple-duplicate ACKs
Explicitly, with a new option.

LMDR and Retransmit-Now play in the same space.

LMDR is a proposal to prevent over-aggressive behavior when switching to a slower link (f.e.) [ XXX: Lars/Andrew - what's f.e. short for here? ]

Bob B: How does this relate to DTN? D=delay or disruption
Lars: if delay is too long, this doesn't apply, but it might in cars or trains.
Bob: is it of general application, or specialized?

Tim: Phil Karn's NOS had mechanism for this sort of thing, 'tcp kick', which WAS useful. But should this be 'below' TCP in some sense... HIP or shim6 might activate this.
Lars: We actually tested with HIP. But the security issues do remain.

Greg Daley: It's about path change indication, locators have changed. Maybe want to talk to internet area about carrying this information up and down the stack, and maybe even end-to-end... but only once per endpoint, not per TCP therefore mitigating the security issues.

AG: draft says that this doesn't change congestion control, it at least seems to violate packet conservation... it introduces extra packets unless endpoints know that the earlier packets have certainly gone. Do CIs announce time of disruption? Must be careful not to introduce unnecessary packets.
Ted: should be thought about

Gorry: where do link indications come from? Are we looking at remote links?
Lars: no, that is not my idea.

Markku: this could be very useful, but might like to see broader indication than simply reconnect; maybe 'link characteristics have now changed'
Lars: didn't want it to be too complex

Wes Eddy [via Jabber]: that's the point of LMDR, and integrating rexmit-now with LMDR.
[ Wes says: The LMDR signalling specifically indicates that the physical path has changed to some extent (at least at the "final hop"), i.e. it is a "link characteristics have now changed" notification, as the speaker at the mic was suggesting would be useful.]

Bill S[XXX:??]: million connections likely to be lots of places, so one packet per endpoint pair may not be that much of a win

Aaron Falk: (at mic) The IAB has been working on documenting some of the many efforts on bringing link change indications into the stack in draft-iab-link-indications. When these mechanisms get deployed, people will start making stack "optimizations" to do this kind of stuff. The IETF should document how to do it right, if that is possible, or why not to do it, if not.

Ted: Hum if you think that looking at TCP link indication is WG material.
[A hum was taken indicating approval for the question, but not overwhelming support. After Joe's clarification below no additional hums were taken. Ted's position is that there is interest in the area, but by no means is the topic or the draft a WG priority at this time. The issue is not closed by any means however and more list discussion is actively solicited.]

Joe Touch: Question had too many negatives. Maybe WG should indicate where it breaks.

Ted: Lets pursue this on list, there is interest in the field if not the specific document (on its own)

Jon P: IPR situation is uncertain. There are initial indications on ancestors of the current document, but not on it itself. However, have been anecdotal reports of IPR action taking place.

Scott Bradner (via jabber): the point is that the IPR holder has asked for a NDA discussion to get a license to implement 4015 so its not so theoretical as Jon suggests

Christian Huitema: encumbered to the point where many in the room cannot implement

Ted: Scott says cannot directly address IPR in a document, but can say RFC is moved in status based on discussion of IPR

Christian: try to implement, then can change status

Scott B: cannot bless IPR claim by specifically referring to it.

(many 'aah's)

Ted: hear 'move to experimental with a note'

Gorry: The roadmap authors and WG moved another standards-track document (jumbograms, RFC2675) to the "extensions" section, on the basis that it was not yet widely implemented. Could a similar case be made for Eifel?

Ted: that would be another reason

Markku: there is another complication, proposed standard status was accidental.

Scott B: Christian is correct about 2026 in theory but we actually have no running code on that part of 2026
Scott B: I think it has been implemented which is how the question of the license came up

Ted: Hums showed strong support for moving RFC 4015 to the experimental section of the roadmap - mostly due to IPR concerns, but please post other arguments. Hums on other two options, "move to separate section" and "no change," received basically no support.

Joe T: note the other reason for moving 4015 to experimental section, i.e., dependence on experimental RFCs, and asked to include that in the comment in the roadmap

Jon: this leaves the roadmap without any standards-track recommendations for this issue, do we really want that?

Joe T: Is there another solution we want in the roadmap?
Ted: F-RTO is a possibility
Mark Allman: Not F-RTO. F-RTO is a detection algorithm and RFC 4015 is a response algorithm.
Bob B: don't hold up the roadmap for that
Ted: should we hold for that?

Hum was to not delay the roadmap for a new spurious RTO response algorithm and the response was strong to proceed with that issue unaddressed in the roadmap - i.e., no response algorithm in the "Recommended" section.