Discarding connection state at server on unvalidated client

[janaiyengar]

The recovery draft says:

Until the server has validated the client's address on the path, the amount of	
data it can send is limited, as specified in Section 8.1 of {{QUIC-TRANSPORT}}.	
If not all unacknowledged CRYPTO data can be sent, then all unacknowledged	
CRYPTO data sent in Initial packets should be retransmitted.  If no data can be	
sent, then no alarm should be armed until data has been received from the	
client.

@mikkelfj notes in #2655 that the sender should discard connection state after some time.

This should probably happen after the idle timeout. In which case, the idle timeout timer ought to be armed.

[mikkelfj]

I think idle timeout might be too long depending on have cheaply a rogue client can initiate new connection attempts, possibly from spoofed source addresses, but that needs more analysis.

[ianswett]

I agree there should be a handshake timeout, which I believe is what you're discussing. But if so, that seems like a transport issue?

[marten-seemann]

I agree with @ianswett that this is a transport issue, and doesn't belong in the recovery document. There we are only talking about the timers needed for loss recovery, and I would find it confusing to talk about closing connections there.
I'm not sure if we need to have any text about a handshake timeout. An idle timeout should be sufficient to garbage-collect connections that aren't active any more. Having a (shorter) handshake timeout is an optimization that implementations might or might not want to have, depending on the threat model.

[mikkelfj]

More generally on idle timeout - would it be OK to do a periodic GC scan risking up to 100% later timeout than the advertised idle timeout? Avoiding timers in passive connections is much cheaper.

[martinthomson]

Yes, idle timeout on a periodic sweep is likely better than assuming that a timer is in play. As @marten-seemann says, anything we say here is in optimization territory. It is likely a very useful optimization, but we don't need to say too much in the spec unless there is an interop or security hazard. Offhand, I can't see anything other than a resource exhaustion problem, but that's clearly something that the periodic sweep should address.

[mikkelfj]

Am I correct in assuming that the PTO timer is not generally armed when data is transmitted actively on quality connections, or a while after data has been delivered?

Combined with idle timeout scans this would mean that most long running connections would likely not have an active timer.

This is a highly desirable property since a precise timer is O(log N). As far as I can tell theoretically O(1) timer wheels are no more effective than a good O(log N) implementation, including foregoing ordering below a certain resolution. There is a big difference between 1,000 entries and 100,000 timer entries.

[ianswett]

This seems somewhat related to Issue #2602

[janaiyengar]

Fair point, @ianswett (and others) -- this should be against transport. It's probably worth clarifying that last sentence so it's not confusing to implementers.

[larseggert]

Discussed in Montreal, decision is to flip to editorial

[martinthomson]

After reviewing this, I'm inclined to do nothing. The idle timeout covers this already. Servers are always permitted to drop connections sooner, but we don't need to specify anything. My primitive server doesn't have a problem with this as connections eventually drop based on the idle timeout.

[ianswett]

The originally quoted section has been substantially rewritten and now specifies the PTO alarm, so there's no confusion about which alarm.

So I support @martinthomson suggestion to close this with no further action/OBE.

[martinthomson]

@janaiyengar, if you agree with the previous suggestions, we could have one fewer open issue with very little effort.

[janaiyengar]

My experience with this suggests that things work fine with just the idle timeout, so closing this.