Hi,

as I already asked to discuss this on Friday, here a short summary for the list:

During the first discussions about how to map QUIC connections and streams
to TAPS objects, it became apparent that there are two ways how this mapping
could be done:
 - Map QUIC Streams to TAPS connections
 - Map QUIC Streams to TAPS messages
While the former is a very natural mapping for a multi-streaming protocol,
the latter is more useful for protocols that treat QUIC streams as messages,
like HTTP/3.

-> As a way out of this tussle, I propose to add connection pooling to TAPS.

The basic idea for connection pooling is to add an alternate interaction
scheme that wraps multiple connection and distributes messages automatically.

How can this be used?
 - For regular TAPS connections, we map QUIC Streams to TAPS connections.
 - For pooled  TAPS connections, we map QUIC Streams to TAPS messages.
 - For regular TAPS connections, we map one UDP 5-tuple to a TAPS connections.
 - For pooled  TAPS connections, we map all UDP packets with the same
   local address/port to messages of one TAPS connection.
 - If we add pseudo-protocol support for HTTP, we can have HTTP 
requests/responses
   as messages and let the transport system framers take care about whether to
   use HTTP/1.1, HTTP/2 oder HTTP/3.
 - We can even upgrade HTTP versions or use two versions at the same time 
without
   bothering the application.
 - We can bundle multiple underlaying transport connections over different paths
   and distribute the messages over these transparently or according to 
information
   provided with the send call.

There were already some discussions in GitHub Issue #266
https://github.com/ietf-tapswg/api-drafts/issues/266

I also prepared two Pull-Requests with proposals how Connection Pooling can be
added to TAPS on GitHub:
 - As separate Object            -> 
https://github.com/ietf-tapswg/api-drafts/pull/295
 - As property of the connection -> 
https://github.com/ietf-tapswg/api-drafts/pull/298

Seeing forward to the discussion (writing this from the train to Prague)

   Philipp S. Tiesel

--
Philipp S. Tiesel
https://philipp.tiesel.net/

Attachment: signature.asc
Description: Message signed with OpenPGP

_______________________________________________
Taps mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/taps

Reply via email to