Re: [Spud] [Stackevo-discuss] Fwd: Possible WG-forming follow-on to SPUD BoF

[Ian Swett <[e-mail]>]

You were clear, I just wanted to voice my support on that point.

As you imply, there are a variety of ways to define a 'header', and as long
as the peers and the on-path elements can interpret it correctly, it
accomplishes the desired goal.  That could be a PLUS header fully
encapsulating another protocol, or as you mention, it could be defining a
way to integrate PLUS into new and existing UDP protocols.

On Fri, May 20, 2016 at 10:06 AM, Brian Trammell <[e-mail]> wrote:

> hi Ian,
>
> >> There's a couple of problems here which could (IMO should) be handled
> better in a transport protocol independent way:
> >>
> >> (1) Generic indication of flow start/end. Firewalls use TCP semantics,
> for the most part, and new protocols should expose at least these to get
> better treatment. Yes, this would have most of the same problems than SYNs,
> RSTs, and FINs do in TCP right now, but we can do better than the status
> quo. One of the things we looked at with the SPUD header is using a tube ID
> in a sparse identifier space to at least provide better protection against
> RST/FIN with guessed sequence numbers (which outside BGP is still a threat
> to deployed TCP, see [1]).
> >>
> >> (2) Indication of NAT/FW state timeout and timeout expectation, to
> minimize unproductive keepalive traffic. Even with generic flow state
> indication you still need timers, and always will, but exposing information
> makes the average case performance better.
> >>
> >> We could consider adding these as key use cases in the protocol, but I
> still think we want to have the broader use case discussion within any
> eventual PLUS WG.
> >>
> >> If we *don't* care about the general deployability of new transport
> protocols, if we think that QUIC is the Last Transport We'll Ever Need
> (i.e., what SCTP was supposed to be), then we can just make sure QUIC
> exposes enough to make this possible, and go home. While QUIC is a definite
> improvement for the application semantics it's meant to support, and a
> widely deployable SCTP would be a improvement for other media applications,
> I'm not convinced that The Last Transport We'll Ever Need is a thing that
> exists, or that we should want to exist.
> >>
> > I think QUIC is great, but it's certainly not "The Last Transport We'll
> Ever Need.".  I don't think such a thing exists.
>
> To be clear, I agree with every part of this statement. :)
>
> There is an alternate approach that might be worth discussion here:
> Instead of defining an encapsulation layer for handling these two core use
> cases, we can define a set of behaviors along with expected bits and
> offsets in headers under the UDP header that can be used for state and
> (maybe) timer management purposes. If a QUIC header and a PLUS header look
> the same to the path for these purposes, then we can still solve this
> problem once for both.
>
> Of course a set of behaviors and bits at given offsets is a "header", so
> the distinction is probably academic.
>
> Cheers,
>
> Brian
>