App: Ref: TAPS API work: on TCP fallback / API?

[gorryfair]

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?

[mirjak]

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?

[gorryfair]

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.

[LPardue]

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 isn'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 isn't a straight shootout between TCP and QUIC. If TAPS frames things like that then I don't know that it helps Applicability.

[mirjak]

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...?

[mirjak]

@LPardue 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?

[LPardue]

I'm still not sure that helps. And I'm trying not to derail Gorry'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 isn'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.

[gorryfair]

I was thinking of something like:

/The IETF TAPS specifications [ID.ietf-taps-arch] 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.

[mirjak]

@LPardue you are right that QUIC provides features that TCP doesn't provide and if you use those features you cannot 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?

[LPardue]

Thanks. I'll have a think on some text. The important thing is that H2 wasn't designed as a fallback for H3, it is its own thing. There are few features that an application desires that it couldn't also achieve by just using HTTP/1.1 and multiple connections for multiplexing.

[mwelzl]

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.

[mirjak]

mainly multiplexing I would say but that probably covered by SCTP

[LPardue]

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.

[mwelzl]

Thanks!
About muxing: is a certain prioritization behavior guaranteed (not just a wish) when muxing with QUIC? SCTP could do that but we don't currently give such guarantees in the TAPS interface.
About security: right... that's what I expected. TAPS isn't going to fall back to a less secure version of what you wish for... so I guess "mostly encrypted header" isn'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 wouldn'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...

[LPardue]

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 http://example.com and receives Alt-Svc: h3=":433". 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.

[mwelzl]

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.

[LPardue]

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.

[gorryfair]

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.

[LPardue]

The suggestion for a short informational reference seems good to me.

[mirjak]

There is already PR #259

[mirjak]

We merged PR #259. Is there anything we want to add or can this issue be closed?

[LPardue]

The merged PR addresses all of my concerns. I'll let @gorryfair be the judge whether his original issue has been addressed.

[gorryfair]

That looked good to me.

[mirjak]

Thanks all!