Draft: draft-ietf-quic-applicability

Commentary: This is a proposal by  to address issue 
 This works for me . 
 Should TAPS be cited as an informational ref to an API that is being discussed by the IETF , and which could apply to QUIC - at least to define the primitives needed in an API , and has quite some insight into protocol racing / fallback as described in applicability ? 
 I 'd be happy to do so ;-) however we avoided in the end to talk to much about specific of the interfaces or needed nobs . So not sure it fits or where to fit it .... where would you want to say something ? 
 I think the WG should consider writing a short section on this . It 's important enough that we have a WG developing relevant specs for how to build APIs and the need for this type of fallback / racing . 
 I 'm not sure the QUIC WG has enough experience to say anything on the matter . The fallback discussion is about how ( Application Mapping + QUIC ) could fallback to ( alternative application mapping + TCP ) . For HTTP/3 this is n't a straight fallback - if QUIC fails then a different HTTP version over TCP is required . This has consequences for applications that use HTTP/3 as a substrate ( MASQUE , WebTransport ) which rely on features only it provides like unreliable DATAGRAM . I think the Applicability spec might need to say more here . What I 'm trying to highlight is that there is n't a straight shootout between TCP and QUIC . If  frames things like that then I do n't know that it helps Applicability . 
 taps allows you to use the same interface for multiple transports and also provides you a way to state requirements ( hard or soft ) to restricts the selection of possible transports . In that sense for some application TCP and QUIC might be not make a real difference as long as all features requested are support , e.g reliability and in - order delivery . Still not sure what / if we want to say something in applicability statement ... ? 
 we were trying to not focus on http in this document . But I do agree that the fact that there is a different version needed for http to fallback could still be interesting . How about adding as sentence like the add the end of the first paragraph in section 2 : OLD In the case of HTTP , this fallback is TLS 1.3 over TCP . NEW In the case of HTTP , this fallback is TLS 1.3 over TCP . Note that for HTTP a fallback to TCP also requires the use of a different version of HTTP , as HTTP/3 has been optimised for use with QUIC , e.g. , by removing multiplexing from the HTTP layer and used the provided mechanism within QUIC . We could even add something more like : " Other applications that are optimised for QUIC might need similar adaption in order to be able to function on TCP . " However , not sure that adds much ... What do you think ? 
 I 'm still not sure that helps . And I 'm trying not to derail  's OP . The main grounding I have in my understanding is HTTP . But I appreciate the Applicability document is general purpose , so apologies . Many HTTP applications operate at the semantic level . HTTP semantics are version - independent and get profiled into versions that have a wire - syntax , which depends on different properties of a transport . This could be an optimised use of QUIC features , or it could be an outright requirement for those features . There is n't an interoperable notion of " I want to do HTTP/1.1 over a reliable in - order transport , TAPS selected QUIC for me , great I 'll use that " nor " I want to do HTTP/3 over a reliable , multiplexed , in - order transport , TAPS selected SCTP for me " . The transport fallback behaviour for HTTP semantics is quite straightforward . Pick a different HTTP version . This could lend itself to a race like scenario . However , there are applications that use HTTP as a substrate and things like MASQUE and WebTransport place requirements on the use of features only available in HTTP/3 - I doubt anyone will try to backport features of QUIC to TCP in order to satisfy the requirements of layers above . 
 I was thinking of something like : /The IETF TAPS specifications [ ] describe a system in which multiple protocols can be provided below a common API . and describe some of the implications of fall back , which specifically precludes fallback to insecure protocols or to weaker versions of secure protocols . / Perhaps inserted after this : /These applications must operate , perhaps with impaired functionality , in the absence of features provided by QUIC not present in the fallback protocol./ ... and before mentioning fallback to TLS over TCP . 
 you are right that QUIC provides features that TCP does n't provide and if you use those features you can not just straight - away replace one with the other . However , a simple one - to - one replacement not implicated when talking about falling back . Rather than trying to back - port features to TCP , what you need to do is implement that feature in your application instead ( as H2 does for multiplexing ) . But this is also true if you try to use TCP and fall back to UDP but need reliability ; then you have to implement it in the application layer . I was trying to be brief in my proposed text and maybe the word " optimise " is not the right one . We can of course say more . Do you want to give it a try and propose some text if you think it would be helpful to say more ? 
 Thanks . I 'll have a think on some text . The important thing is that H2 was n't designed as a fallback for H3 , it is its own thing . There are few features that an application desires that it could n't also achieve by just using HTTP/1.1 and multiple connections for multiplexing . 
 May I ask what these features are ? E.g. , the ability to send unreliable datagrams should not matter in the best effort Internet ( reliable transfer , when not needed , is just slower ) . In RFC 8923 , we made an effort to identify exactly what MUST be exposed to an application because there 's no such fall back . This covers TCP , MPTCP , UDP , UDP - Lite , SCTP and LEDBAT ; alas , it excludes QUIC , since this work pre - dates its finalization ( by far , despite the date : it spent a long time in the RFC Editor queue ) . So now I 'm curious what QUIC adds to this list . 
 mainly multiplexing I would say but that probably covered by SCTP 
 The main feature that QUIC provides to the HTTP substrate is that it is a secure transport that can work on the Internet and is easily integrated with WebPKI . These are meta - features in a way . Having parity of the deployment and security models allows more straightforward rationalisation when designing applications and e.g. Web APIs on top of this substrate . 
 Thanks ! About muxing : is a certain prioritization behavior guaranteed ( not just a wish ) when muxing with QUIC ? SCTP could do that but we do n't currently give such guarantees in the TAPS interface . About security : right ... that 's what I expected . TAPS is n't going to fall back to a less secure version of what you wish for ... so I guess " mostly encrypted header " is n't a part of any API but as you say it 's a meta - feature - it 's implicit in the choice of QUIC , and when that 's desired , falling back would n't happen , a TAPS system should always only give you QUIC . I think what 's missing is a QUIC API that makes these wishes explicit ... 
 Personally I 'd say , for an HTTP application , that QUIC packet header protection is less of a concern . More that QUIC provides transport security on - par with TCP+TLS . Often an application can use the same TLS and crypto libraries for both . Fallback from QUIC to TCP can be a downgrade . But an application that does this can ( and should ) be aware of the security properties of the transport it is using . With HTTP , imagine a client that connects to and receives . This advertises the availability of QUIC and HTTP/3 . If that transport connection fails for some reason , then there is not a viable fallback to TCP+TLS . This is an unlikely scenario but the specs allow for it to happen . 
 I would also have thought that encrypting data is more important - but surely having fall - back " under the hood " and just being aware of what you got ( this can be queried in TAPS ) is nicer than having to take care of it in the application . Fall - backs can get complex : e.g. , when multi - homing , considering IPv6 ... a TAPS system can have a rich set to choose from and implement it all efficiently while shielding applications from this trouble - the application is still in control of things and can express limitations , as well as query what it got in case it did give the system some freedom . This HTTP case of preventing a fall - back ... well , it is what it is :) No fall - back in this case , clearly . 
 I remain to be convinced that TAPS API will address the way that applications ( I am familiar with ) intend to use and interact with QUIC . 
 I think we 're drifting towards a discussion of should a mapping document be written for TAPS to QUIC ... which is a different topic . My observation was only that TAPS architecture is something the IETF is working upon , and it has documents that describe how to make an API that with functions and racing / fallback in a very different way to sockets . The guidance about what is an acceptable " alternative " connection appear common , at least enough to say there is a similarity and cite it . 
 The suggestion for a short informational reference seems good to me . 
 There is already PR 
 We merged PR . Is there anything we want to add or can this issue be closed ? 
 The merged PR addresses all of my concerns . I 'll let be the judge whether his original issue has been addressed . 
 That looked good to me . 
 Thanks all ! 
 \o/ lgtm
Paragraph (version B):
The IETF TAPS specifications I-D.ietf-taps-arch describe a system
with a common API for multiple protocols and some of the implications
of fallback between these different protocols, specifically
precluding fallback to insecure protocols or to weaker versions of
secure protocols.