Re: Small size of core QUIC library to replace TCP for embedded system

[Paul Vixie <[e-mail]>]

On Tuesday, 21 July 2020 10:56:22 UTC Jupiter wrote:
> Hi Lars,
> 
> On 7/21/20, Lars Eggert <[e-mail]> wrote:
> > ...
> > https://github.com/quicwg/base-drafts/wiki/Implementations)
> > ...
> 
> Sorry for not being clear, I should say Linux embedded system at the
> beginning. Although I would say the time for embedded systems with 8M
> Flash and 64KRAM has been long gone :-), I still have to manage the
> resources for meaning full network stacks and applications.

i realize that this has been declared off-topic, but you've raised a question 
that your /quicwg/ URI above does not answer.

for privilege separation reasons, sockets have been kernel objects. this has 
facilitated logging and filtering for regulatory, policy, ad-blocking, malware 
filtering, and so on. user mode code has not historically been able to form a 
connection without a "connect" system call, where policy could be enforced by 
the kernel. as an example, "raw" sockets necessary to implement user-mode TCP 
have historically been restricted to processes running with elevated 
privilege.

in some environments this will be an invariant, and UDP sockets will be made 
to require elevated privileges, precisely so as to give the kernel a chance to 
log and filter connection attempts according to local policy. in that 
environment, a kernel-resident QUIC implementation will be needed, so that 
something like a "connect" system call can still exist. i do not expect this 
to save memory, because shared libraries are equal in size to kernel modules. 
but as a place to put an ad-blocker or other edge-device connection policy, a 
kernel-resident QUIC implementation is going to be required in some places.

my question is, has any QUIC implementor been thinking along these lines? i 
believe that the parameters to a QUIC "connect" syscall would be larger and 
more numerous than for a TCP or SCTP or UDP "connect" syscall, for example.

-- 
Paul