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

[Spencer Dawkins at IETF <[e-mail]>]

Hi, Brian,

On Fri, Apr 6, 2018 at 7:54 AM, Brian Trammell (IETF) <[e-mail]>
wrote:

> 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. ;)


Honestly, we should be checking a sundial.

If I'm understanding that the problem is what happens when signals are
unreliable and devices have to include workarounds that accommodate missed
signals, I THINK that's a conversation I overheard sometime around 2000, in
L2Triggers. I wasn't a participant in that conversation, but IIRC, the
reason that TRIGTRAN's scope was limited to first-hop routers in 2002 was
because of the problems L2Triggers had identified with signals coming from
routers that weren't locally attached, and we couldn't turn TRIGTRAN into
something useful even with that limitation.

The signals being discussed aren't the same signals, but the problems sound
very, very familiar.

Keeping in mind that I started Section 4 of
https://tools.ietf.org/html/draft-dawkins-panrg-what-not-to-do-00 with
TRIGTRAN, that's probably not an good sign ...

Do the right thing, of course.

Spencer