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

[Colin Perkins <[e-mail]>]

Hi Thomas,

Thanks for your feedback. 

I agree with your comments on the introductory sections; there’s certainly scope to tighten up that text.

As for the rest, I don’t disagree that machine learning will be important, but I’m not the right person to write about it. I’m also not clear where such material would fit in the document. It might be better to have a separate document, that this can maybe refer to, that starts to discuss solutions to the issues identified.

Cheers,
Colin


> On 17 Jun 2019, at 16:53, Thomas Fossati <[e-mail]> wrote:
> 
> Hi Gorry, Colin,
> 
> I have read your fine draft and gathered a few comments for your
> consideration.
> 
> I think the intro material (Sections 1 and 2) could be slimmed down
> substantially:
> - There's a bit of repetition (sometimes literally, e.g.: 2nd and 3rd
>  para of the intro section carry the same exact information);
> - Content-wise, with regards to setting the context, there seems to be
>  good overlap with a few already published RFCs - for example both
>  Path signals [RFC8558] and Wire image [RFC8546] could be used to
>  factor out a bunch of text here?  Just a suggestion.
> 
> The rest is really good material with the right balance of breadth and
> depth (IMHO).
> 
> However, one of the raison d'etre of the document, as I interpret it, is
> to describe which tools & techniques are available to network operators
> that can survive transports that mux and prioritise inside an encrypted
> envelope.
> 
> And while the document does a very good job identifying what *doesn't*
> work anymore, the "every time a transport field is encrypted, a passive
> measurement tool gets his wings" story, while factually accurate, only
> tells one half of the tale.
> 
> In that respect, I think the draft should also consider any emerging
> techniques & tools.  In particular, ML solutions (especially RNN and
> reinforcement learning architectures) look like one very plausible way
> this is going to evolve.
> 
> Which is not to say these methods are in all cases mature enough for
> production.  On the contrary, I think currently very few of them would
> be ready for prime time.  But this is one line of work that has shown,
> in published research at least, encouraging levels of precision &
> accuracy (even with encrypted traffic), while dealing with all the
> typical scenarios a network operator faces.  (I've seen ML applied to
> fault detection and localisation, QoE/QoS measurements in both real-time
> comms and adaptive video, anomalies / misuse / intrusion detection, the
> whole lot.)
> 
> The thing is that if ML or like approaches are not good enough or not
> mature enough, the risk that MiTM and forced fall-back to TCP become a
> practical and effective tool in the hands of network operators increases
> substantially, which would be pretty unfortunate.  (And yes, we could
> have handled the transition more graciously, cf. SPUD/PLUS, but we
> decided not to, so here we are.)  In this respect, I think it's critical
> to create a shared understanding of what the challenges are and what
> concrete actions can be taken to accelerate / incentivise the
> development and adoption of ML in this venerable field.  To this end,
> it'd be great if the document provided (even succinctly) a critical look
> on ML that highlights the potential and actual successes, its
> limitations (both in general, and specifically WRT encrypted transports)
> as well as the current gaps.
> 
> For example, one thing that becomes quickly apparent once you start
> surveying the existing literature is that comparing different
> ML-for-network-traffic experiments is quite problematic.  The lack of
> uniform evaluation metrics as well as standardised labelled datasets
> (which is only aggravated by ML's sensitivity on training and validation
> data) looks like a gap that urgently needs filling and one where the
> IETF is ideally placed to help reducing the observed fragmentation.
> 
> OK, I'll stop here - I wanted this to be short and snappy but I got
> carried away somehow.  Hopefully my points are still visible above the
> noise line.
> 
> Thanks again for the great job gathering 20+ years of collective
> knowledge and experience.
> 
> Cheers, t
> 
> 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.



-- 
Colin Perkins
https://csperkins.org/