Hi Philipp,

Thanks for sharing this document! Providing an API for generic network intents 
is something of a Holy Grail—valuable but elusive to nail down. This document 
should be a good place to start a conversation, and I look forward to 
discussing it in Prague.

A few initial comments:

- I’d love to see the terminology be less sockets-specific, especially 
considering the work for Post-Sockets APIs. A set of intents should be able to 
be applied to individual messages being sent or on a higher-level protocol, 
ideally, not just on the level of a transport connection as represented by a 
socket.

- Certain properties, like burstiness, are focused on what the application will 
be sending, and what its sending pattern will look like. This works fine for 
some use cases, but in the case of downloads, the application may not have 
enough/any insight into what patterns the server will have. What do you think 
the best way to account for this is?

- While explicit intents are a great way to avoid ossification, I would also 
argue that we should minimize the surface of the intents in order to reduce the 
complexity for application writers. Do you think that some of these intent 
properties can also be inferred automatically based on the traffic patterns 
observed by the system? I’m thinking here of traffic category, in which we’re 
asking the app to say if they’re using queries or streams or bulk downloads, 
etc.

Thanks,
Tommy

> On Jun 16, 2017, at 1:54 AM, Philipp S. Tiesel <[email protected]> wrote:
> 
> Hi,
> 
> I just uploaded draft-tiesel-taps-socketintents-00 to the data tracker 
> yesterday.
> https://datatracker.ietf.org/doc/draft-tiesel-taps-socketintents/
> 
> This draft should fits into point three of the TAPS charter.
> 
> Socket Intents allow applications to share their knowledge about upcoming
> communication and express their performance preferences in an API independent 
> way.
> Therefore, thy can be used by an OS/API to gain enough knowledge to perform 
> access
> as well as transport protocol selection and tuning.
> 
> A draft explaining an experimental implementation based on BSD sockets will 
> follow.
> 
> I am looking forward to the discussion, here and in Prague.
> 
> AVE!
>  Philipp S. Tiesel / phils…
> 
> _______________________________________________
> Taps mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/taps

_______________________________________________
Taps mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/taps

Reply via email to