[Plus] Status of PLUS

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

Hi, Lin, all,

Circling back on these points...

> On 14 Feb 2017, at 22:38, Lin Han <[e-mail]> wrote:
> 
> Hello, all
> 
> Just signed up this list, I knew PLUS has been concluded unfortunately.

In the sense that the BoF failed to come to consensus that a working group could be formed with the presented scope, due to questions about the privacy risk / utility tradeoff of a generalized solution to the problem of replacing implicit interference by path elements with explicit communication, yes... I would not yet say we've come to a "conclusion" yet, though.

> The idea of PLUS is very useful for the transportation improvement for some applications that the traditional transport could not support properly.
> Want to see what is the plan for the group ?

Stepping back, there are three things I think we wanted out of PLUS:

(1) Providing basic measurability and state maintenance for transport protocols with encrypted headers, and doing it once. The basic header in draft-trammell-plus-spec does this. You could get the same effect by adding the same information to some variants of the QUIC public header. In any case, without a common basic header, the measurability and statefulness of new transport protocols will have to be considered by each new transport protocol. draft-kuehlewind-plus-appman is an initial applicability and manageability statement for QUIC, the manageability section of which will discuss these issues specific to QUIC.

(2) Adding (very) small amounts of information to packets to give advisory signals to path elements on how the application would prefer they be handled. Kind of like DSCP, but with end-to-end integrity protection. The Basic Header in draft-trammell-plus-spec does this for two bits: L for signaling transport-layer loss insensitivity, and R for signaling transport-layer reordering insensitivity. One could add more to the extended header at additional cost. Here, the questions (raised at the ACCORD BoF for the loss insensitivity bit) are, as I understand them, about utility for cost: i.e., 1% better aggregate throughput is not worth twenty additional header bytes per packet. FWIW we're doing some experiments with in-network handling of the L bit this year.

(3) Building a generalized, transport-protocol-independent facility for communicating arbitrary information from endpoints to the path, or from the path to endpoints. This is where SPUD started off, and this is what we showed can work with endpoint integrity protection in draft-trammell-plus-abstract-mech. This is also where most of the controversy in the PLUS BoF came from. What I took away from the feedback at the PLUS BoF is that we need to have a much better idea of the restricted vocabulary we'd use with such a thing, how these restrictions can be enforced, and the incremental benefits of that vocabulary. There’s certainly room for more research on these points.

Cheers,

Brian

> Regards
> 
> Lin
> _______________________________________________
> Plus mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/plus