Re: [tsvwg] Comments on draft-ietf-tsvwg-transport-encrypt-06

[Thomas Fossati <[e-mail]>]

Hi Tom,

> ML requires massive amounts of data to be most effect effective, but
> strong security mandates that we only expose the minimal amount of
> data we need to. So this is the tussle. If someone were to say we need
> uniform metrics exposed in transport protocols in the Internet, then
> the first question to be asked is "what information about transport
> protocols is _required_ to be exposed to the network?" Architecturally
> and from a position of security, the answer to this question in the
> Internet is none. A better question to ask might be what information
> would be useful and optional to expose and how can we limit the
> exposure to only trusted parties (for instance, I might trust my local
> network more than I trust the Internet, so I may be willing to expose
> data to the local network if there are sufficient mechanisms to scope
> it). That implies the need for a mechanism whereby hosts can signal
> the network with ancilary scoped information attached to packets. IMO
> the mechanism for this should be Hop-by-Hop options.

Sorry for the confusion. The thing I am suggesting is to standardise the
interface to the inference engine, not to force higher layers to leak
information.

The (naive?) model I have in mind is one where the ML trainer not only
has the ability to measure passively but also to inject ad hoc
application flows itself - ideally from multiple vantage points.  These
can be then correlated with their blind counterparts both in the
training and check/reinforcement phases.

In principle, the application endpoints don't need to reveal anything,
apart from their network headers and whatever the transport already
exposes (e.g., spin-bit, connection id).  The onus of generating the
otherwise hidden data is on the ML engine owner and whoever chooses to
partner with it.  For example, a mobile network operator could partner
with customers that opt to participate in a crowdsourced measurement
campaign.

To this end, the two log formats that are emerging around QUIC: qlog [1]
and QUIC trace [2] would act as the source of high fidelity
transport-specific information.

On top of those, there could be a bunch of standardised application
specific formats - e.g., time series of MOS scores for real-time A/V
apps, perceived video quality for HAS, $your_QoE_estimator of choice.

And maybe another level of tagging is a set of KPIs at the global scope,
provided by the network, (e.g., congestion levels, percent of rejected
flows) if the available samples are too sparse to reconstruct the big
picture.

This is effectively a hierarchy of standardised log data formats that
can be composed easily, for which pre-processing tools can be shared,
that would help with reproducibility plus all the other advantages that
come with a common, well defined format.

Of course, there's the inherent correlation/anonymity dichotomy that
needs addressing, but I think the IETF has the right expertise in house
to tackle this kind of stuff - the time we spent on making sure RFC7937
was shippable is a testament to that :-)

Cheers, t

[1] https://datatracker.ietf.org/meeting/104/materials/slides-104-tsvarea-logging-tooling-and-debugging-for-modern-network-protocols-robin-marx-00
[2] https://datatracker.ietf.org/meeting/104/materials/slides-104-tsvarea-quic-tracing-victor-vasiliev-00

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.