Re: [Spud] Bare-minimum PLUS (was Re: Thoughts on the privacy concerns expressed at the BoF)

[Brian Trammell <[e-mail]>]

hi Kyle,

> On 29 Jul 2016, at 14:39, Kyle Rose <[e-mail]> wrote:
> 
>> On Fri, Jul 29, 2016 at 8:18 AM, Eliot Lear <[e-mail]> wrote:
>> Hi Tom,
>> 
>> Something that did not get brought up at the BOF is nagging at me...
>> 
>> 
>> On 7/28/16 8:17 PM, Tom Herbert wrote:
>> > The abstraction is only useful up to the point that networks preserve
>> > the model. If the network breaks the model in ad hoc ways that forces
>> > the application to try to compensate with more ad hoc mechanisms or
>> > just stop innovating altogether as we see happened with protocol
>> > ossification.
>> 
>> You write that as if it's a bad thing ;-)
>> 
>> Some amount of protocol ossification is a GOOD thing.  In particular,
>> the calling interface for transports needs to be stable or source code
>> will have no shelf life.  The fact that TCP's calling interface has been
>> SO stable for SO long has meant that a large code base did not require
>> substantial maintenance just to keep doing the same thing it was
>> doing.   I see this as an exercise to determine what needs ossification
>> and what does not, and there are extreme positions at both ends.
> 
> I think this conflates two issues. I think of "ossification" as unintended structure that precludes development within the protocol stack, something I think is broadly accepted as a problem by people who are trying to improve the experience of users. What you are talking about here seems to be stability of the API for a specific protocol. Frankly, if we apply "ossification" to that then the term becomes overly broad and therefore meaningless. I don't think anyone is suggesting that all APIs should be randomly perturbed over time just to see what happens.

Some of it is stability of the API, some of it is the stability of the what i'll call the "wire image": what the headers and behaviors look like to an on-path device.

I agree with Eliot that what we're trying to do here is re-ossify the wire image *on purpose*, given the things we've learned since the 1980s from the less intentional ossification that's happened since then. There is a careful line to draw when doing this. It should be generic enough that all the transport innovation we think we might want to do between now and 2040 fits inside it. It should be restrictive enough that it presents an improvement on the present state of the world with respect to the types of shenanigans described in https://tools.ietf.org/html/draft-trammell-privsec-defeating-tcpip-meta-00. But if it's too restrictive, people will just find other ways to implement the kinds of in-network functions they want to: cf. using the QUIC version number as a QUIC magic number, for instance.

> No one is going to break the sockets API anytime soon

*ahem* https://www.ietf.org/proceedings/96/slides/slides-96-taps-2.pdf *cough* -- I'm not saying we're going to be successful in breaking it, but it *is* the other half of the problem we have today.

Cheers,

Brian

> but having to develop a new API for modern protocols would be a nice problem to have. First, though, we need to figure out how to route those protocols through the boxes that right now assume the entire internet runs over a snapshot of TCP from 20 years ago.
> 
> Kyle
> _______________________________________________
> Spud mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spud