Maybe I just lack imagination but this is the part of the "put it in
transport and everyone gets it for free" line that I've not understood.

For example, Cloudflare's quiche implementation of QUIC is I/O agnostic,
you put application data in, it gives you QUIC packets back and you do with
them what you like. This flexibility means it's portable to lots of
platforms and applications. It's been able to slide into curl and nginx
implementations without a need to re-architect. More people using the
library means more diverse use cases and better coverage of protocol
features.

I don't know what a TAPS-quiche integration would look like or provide.
>From looking at
https://tools.ietf.org/html/draft-ietf-taps-interface-09#section-7.1.7 a
lot of the decisions are "implementation specific". I'd hazard a guess that
each implementation would make its own decisions and want to expose
different things to the application. And even if *it* didn't expose network
information, it would need access. So either it sits in the application and
uses a platform API that could've been used all along, or it gets compiled
into the platform and now we lose agility.

Cheers
Lucas

Reply via email to