Hi Tommy,
thanks for your appreciation and comments.
> 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.
I totally agree that the Idea of Intents is not limited to sockets and the
transport layer, but the Idea started from there.
Background: The the original idea was very close to the sockets and targeted at
deciding which network interface to use for upcoming connections. We extended
this in the meantime to smaller communication units (HTTP Request/Response
pairs) and it worked very well in simulations and our prototype using the
"Object Size” Intent. I try to give more background on this in an additional
draft.
I take making the terminology be less sockets-specific as a ToDo-Item for the
-01 version.
By introducing an applicability scope and choosing levels that do not directly
map the protocol layering, but an abstract
layering of functionality (Flow, Association, Stream, or Object level), I took
the first step towards a more generic abstraction.
For me, Object level indeed would include individual messages in an application
layer protocol like HTTP Requests.
Question: Is this sufficient or do we need to need more or different levels?
We might also consider postponing this question as we are now in the progress
of writing a draft on explaining
this levels and how multipath-funtionality may be distributed over them.
> - 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?
Currently, In this cases I would either not set the Intent at all or explicitly
to "mixed/don’t know”.
I consider setting Intents best effort - what the application doesn’t know it
can't communicate.
Therefore, some of the Intents are not really overlap-free. Setting “Object
Size” to something really large, the "Traffic Category” is pretty obvious even
when not set. This also plays into you next question.
> - 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.
I don’t see having Intents and inferring their values as exclusive, but as
complementary.
I anticipate inferring traffic pattern will work fine for many applications,
but not for all.
What I definitely want to avoid is application developers having to train
machine learning algorithms in order to have their applications working.
Therefore, I prefer exposing more Intents and making them optional over relying
on being able to infer them.
AVE!
Philipp S. Tiesel / phils…
--
{phils}--->---([email protected])--->---(http://phils.in-panik.de)----,
wenn w eine aube ist dn man au dran dre en |
o Schr an muss hc h (Kurt Schwitters) |
:wq! <----(phone: +49-179-6737439)---<---(jabber: [email protected])----'
_______________________________________________
Taps mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/taps
