Draft: draft-ietf-taps-arch

Commentary: Alternate proposal to address ( old PR was " Add CacheContext to architecture and API " , ) Define explicit Connection Groups as a way to define caching boundaries Update TLS 1.3 references to RFC 8446 
 This is a light - weight approach , but seems a little heavy - handed . I thought connection groups were a tool to model multi - streaming . With this PR , they become a fuzzy thing between cache context and multi - streaming abstraction . This may be the better choice , but ist definitely an Architecture decision . I liked the cache original context more . 
 The result of the interim discussion was that we did n't like a separate cache context object as much . Based on the discussion , we need some abstraction to say " these connections do n't share state with the rest of the connections in my process , and can share between one another " . The Group is a convenient way to do this . Note that you can just have one connection in its own group even . In some ways , it solves a lot of problems — it is n't sensical to say that connections in a Group can not share cache state . It I multiplex , I 'm by default sharing TLS state . So if we have a separate cache context , we 'll need some prohibition that you ca n't have multiple connections in a group have different cache contexts . Using the group as the way to define the boundary solves this . 
 I agree that it solves a lot of Problems and is an easy - to - use solution . The more I think about it , the more I like it . If we agree that we want to go down this road , definitely a +1 from my side modulo comments . Still , if we land this one , we need to add some means of manually managing connection groups to the API in the next round . 
 please re - review ! 
 I updated the text to avoid the implication about cloning . I did n't intend to change the behavior for Clone ( ) being required to get multiplexing . I was more thinking that the use of the cache could be managed implicitly , while still requiring calling Clone ( ) to actually multiplex . But , for now , I removed the text about implicit groups . Please check that this resolves your concerns ! 
 Thanks for the reviews and input ! 
 share concerns , approving so we can submit a draft to discuss in prague ... Looks good to me!LGTM ! Thanks for the fixThanks – Looks good to me !
Paragraph (version A):
Many application programming interfaces (APIs) to perform transport
networking have been deployed, perhaps the most widely known and
imitated being the BSD socket() POSIX interface.  The naming of
objects and functions across these APIs is not consistent, and varies
depending on the protocol being used.  For example, sending and
receiving streams of data is conceptually the same for both an
unencrypted Transmission Control Protocol (TCP) stream and operating
on an encrypted Transport Layer Security (TLS) I-D.ietf-tls-tls13
stream over TCP, but applications cannot use the same socket send()
and recv() calls on top of both kinds of connections.  Similarly,
terminology for the implementation of transport protocols varies
based on the context of the protocols themselves: terms such as
"flow", "stream", "message", and "connection" can take on many
different meanings.  This variety can lead to confusion when trying
to understand the similarities and differences between protocols, and
how applications can use them effectively.
Paragraph (version B):
Many application programming interfaces (APIs) to perform transport
networking have been deployed, perhaps the most widely known and
imitated being the BSD socket() POSIX interface.  The naming of
objects and functions across these APIs is not consistent, and varies
depending on the protocol being used.  For example, sending and
receiving streams of data is conceptually the same for both an
unencrypted Transmission Control Protocol (TCP) stream and operating
on an encrypted Transport Layer Security (TLS) RFC8446 stream over
TCP, but applications cannot use the same socket send() and recv()
calls on top of both kinds of connections.  Similarly, terminology
for the implementation of transport protocols varies based on the
context of the protocols themselves: terms such as "flow", "stream",
"message", and "connection" can take on many different meanings.
This variety can lead to confusion when trying to understand the
similarities and differences between protocols, and how applications
can use them effectively.
Paragraph (version A):
Connection Group: A set of Connections that share properties.  For
multiplexing transport protocols, the Connection Group defines the
set of Connections that can be multiplexed together.
Paragraph (version B):
Connection Group: A set of Connections that share properties and
caches.  For multiplexing transport protocols, only Connections
within the same Connection Group are allowed be multiplexed
together.  Applications can use their explicitly defined
Connection Groups to control caching boundaries, as discussed in
groups.
Paragraph (version A):
whereas TLS 1.2 and TLS 1.3 I-D.ietf-tls-tls13 are not considered
equivalent.
Paragraph (version B):
whereas TLS 1.2 and TLS 1.3 RFC8446 are not considered equivalent.
Paragraph (version B):
By default, all stored properties of the Implementation are shared
within a process, such as cached protocol state, cached path state,
and heuristics.  This provides efficiency and convenience for the
application, since the Transport System Implementation can
automatically optimize behavior.
Paragraph (version B):
Privacy concerns about re-using cached protocol state that can
lead to linkability.  Sensitive state may include TLS session
state RFC8446 and HTTP cookies RFC6265.
Paragraph (version B):
Privacy concerns about allowing Connections to multiplex together,
which can tell a Remote Endpoint that all of the Connections are
coming from the same application (for example, when Connections
are multiplexed HTTP/2 or QUIC streams).
Paragraph (version B):
Performance concerns about Connections introducing head-of-line
blocking due to multiplexing or needing to share state on a single
thread.
Paragraph (version B):
The Transport Services API SHOULD allow applications to explicitly
define Connection Groups that force separation of Cached State and
Protocol Stacks.  For example, a web browser application might use
Connection Groups with separate caches for different tabs in the
browser to decrease linkability.
Paragraph (version B):
The interface to specify these Groups MAY expose fine-grained tuning
for which properties and cached state is allowed to be shared with
other Connections.  For example, an application might want to allow
sharing TCP Fast Open cookies across groups, but not TLS session
state.