Re: Grips in the Wire Image for In-Network State (was Re: Privacy holes (was Re: Getting to consensus on packet number encryption))

["Brian Trammell (IETF)" <[e-mail]>]

hi Martin,

> On 6 Apr 2018, at 12:55, Martin Thomson <[e-mail]> wrote:
> 
> I don't know how to game this one out.
> 
> If we're looking for mutual benefit, the best I can come up with is
> that the middlebox knows about flow up/down, so it can extend timeouts
> for most flows and endpoints thereby enjoy better chance of flow
> liveness after longer periods of quiescence.  That would be something
> like with TCP where you can expect timeouts to be in the order of
> minutes or tens of minutes (30 minutes if you pick the right port
> number) and not merely tens of seconds.

Flow down in this case is way more useful than flow up.

> The problem here is that you need enough of the middlebox population
> to extend timeouts in the common case.  Tuning to specific networks is
> difficult and time-consuming.  So endpoints would deploy this "grip"
> without any expectation of reciprocation for potentially a very long
> time.  That's in the order of the end-of-life cycle for home routers,
> or an entire Internet era.

We, as a community, are currently managing transitions that have taken that long. Insert your favorite IPv6 joke here, of course, but ECN comes to mind as well.

> In the meantime, endpoints have to assume flow liveness based on the
> Internet of today.  30s is the benchmark now, despite the wishful
> "requirement" for 2 minutes in RFC 4787.

"Flow liveness" is a path property, not a global one, a function of the minimum timeout of all connection-breaking state along the path. I suspect that endpoint pairs in a world ruled by UDP state timeout will end up widely deploy simple probing algorithms to discover it whether or not there's a simple way to signal that state can be disposed of early.

This is really a separate issue, though -- the question about state disposal is disjoiny from how to keep flow start signaling from ossifying into an unintentional magic packet sequence you have to show the network. It makes sense to think about the "grippiness" of the protocol in terms of the eventual endpoint as well as management reqt's though.

> Thus we end up with the tension between the documented wire image that
> says that there is a "done" signal, and the actual wire image, which
> has activity every 30 seconds.  Add genuine cases of migration,
> crashes, stateless resets, and the other reasons that the "done"
> signal doesn't appear and the timer has to come down.
> 
> There might be benefits if everything comes together, but it's a long
> game to play.

I've been having some variant of this particular conversation for (checks watch) about four years now. ;)

Cheers,

Brian