Hi, > On 14. Nov 2019, at 23:16, Tommy Pauly <[email protected]> > wrote: >> On Nov 14, 2019, at 10:18 AM, Mirja Kuehlewind <[email protected]> wrote: >> >> Hi taps folks (also cc’ing the WebTransport list), >> >> I assume that people on the taps list are aware of the WebTransport effort >> that will have a BoF meeting on 13:30-15:00 Wednesday. I had another look at >> the WebTransport documents today in order to better understand the scope of >> WebTransport compared to taps. >> >> Looking at https://tools.ietf.org/html/draft-vvv-webtransport-overview-00 I >> believe that this should be covered by pooled connections in taps + use of >> partial messages. WebTransport proposes to use streams as the base concept >> while we in taps explicitly decided against this but to use messages instead >> which also aligns with other protocols that are discussed in WebTransports >> like Websockets and WebRTC data channels. Unfortunately the draft doesn’t >> give any reasoning for that choice but I would still think that use of >> particle messages in taps should be equivalent at it is explicitly designed >> to address applications that actually need streaming. What do people think? > > I think the notion of stream here is just a multiplexing concept; the > terminology doesn't follow the terminology in TAPS, but it's not at odds. > It's just a different phrasing.
I largely agree. The thing they call a Stream would be represented by a TAPS connection backed by a stream of a QUIC connection. A TAPS system should also be able to provide functionally equivalent alternative transport, e.g, falling back to TCP connections or assigning the stream to a a specific connection from a pool of established QUIC connections. >> >> Further looking at >> https://tools.ietf.org/html/draft-vvv-webtransport-quic-00 >> <https://tools.ietf.org/html/draft-vvv-webtransport-quic-00> this draft >> defines a new ALPN value and a QUIC extension. I guess in taps we have not >> explicitly considered ALPN so far but we really would need to do that in any >> case! I guess one could see this as a protocol specific property but maybe >> it’s even worth to be more explicit here. Did anybody consider ALPN already? > > ALPN is a TLS option, so it fits into the protocol-specific options. We > certainly have support for that in our implementation! > (https://developer.apple.com/documentation/security/2976269-sec_protocol_options_add_tls_app?language=objc > > <https://developer.apple.com/documentation/security/2976269-sec_protocol_options_add_tls_app?language=objc>) in the long run, making the ALPN a TLS option may be a little short sighted. We should consider to making it an optional part of the remote endpoint (remote.with_alp(“http”), as a future QUIC version that may not be based on TLS would certainly also support this concept. I can also imagine Applications only specifying a ALPN and a host name while the transport systems fills in port candidates or use appropriate proxy chains. This can also be used to address services in Kybernetis like cloud infrastructures. >> Regarding the new QUIC transport parameter I have to say that the purpose it >> not fully clear to me from the draft. However it seems that this is supposed >> to support some kind of access control that is performed on the application >> layer but by a more trusted entity than the client application itself. It is >> not fully clear to me what the trust assumptions are, however it does seems >> that is should not be a transport parameter that is protocol specific but >> rather some function on the higher layer. However, to be able to make a >> proposal here, I would probably need to understand the purpose better. Do >> people have any insights? > > From the TAPS side, transport parameters in QUIC do need to be able to be > configured by the app or set as a default for a given use case, so that > shouldn't be an issue. Full ACK – But I would discourage using it as it makes protocol evolution harder. > >> >> Do people have thoughts? What is missing in taps to also cover the full web >> use case? Is that something we want to account for in taps? Or what is the >> difference that would not fit with the taps approach? What am I missing? > > Fundamentally, TAPS is about API shape and approach. It alone doesn't define > any new protocol knobs. If WebTransport needs new on-the-wire protocol > changes, those need to be independent. However, the shape of creating > connections, and sending and receiving messages, is something that can > certainly conform to a TAPS-compliant interface. > > If you read through draft-vvv-webtransport-overview, it largely outlines > something that is a TAPS interface, just without referencing TAPS or calling > that out. > > So, one way to view the relationship is that WebTransport as described is a > specific set of protocol features that a web-focused implementation of a TAPS > system ought to build, plus a few protocol tweaks below. Agreed. AVE! Philipp S. Tiesel -- Philipp S. Tiesel https://philipp.tiesel.net/
_______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
