Proposal for requirement on reliability

[mirjak]

No description provided.

[achernya]

Hi Mirja,

Can you please explain the motivation for this change? I do not understand why you want to promote this from the extensions section to core protocol requirements. As it currently stands, I think your text is achieved with the extension mechanism the core requirements already describe.

[dallasmcc]

Alex,

I think Mirja's point (please correct me if I'm wrong) is that we already need to support reliable transmission to satisfy the fallback requirements for endpoints that don't support datagrams -- so why not include an option that allows you to force the use of that even if everyone supports datagrams?

[achernya]

I think that would be a fine feature, but doesn't the current text allow that? I suppose we could add an explicit callout that the participants have the option to choose among the Data Transports available?

[mirjak]

Yes, the point is providing a interface for that should be easy (as the function is needed anyway) that why I would like to see that as part of the base protocol and not an extension. Local repairs is a use case we are really interested in.

[DavidSchinazi]

@mirjak can you elaborate on why you think this should be in the base protocol? As a design principle, I see performance improvements as well suited to extensions

[achernya]

@mirjak "providing an interface" is an implementation detail, not a protocol requirement.

I believe the current requirements text already captures this capability sufficiently, and agree with @DavidSchinazi that explicit use of it is well-suited to an extension. (Although my current read is that an extension would only be needed if we allowed endpoints to advertise which subset of Data Transports they supported---I was imagining all implementations would have to support all available Data Transports for their appropriate protocol)

[mirjak]

The "mechanism to allow forwarding some packets reliably" as it is described currently in the extension section has to be there no matter what, as datagrams are optional and therefore there is always a stream-base data transport.

To give the client a choice which one to use (if datagram is available as well) it not a performance optimisation but an essential function to support a use case where local recovery on high delay networks is desired. Therefore I would like to see a requirement for it.

[achernya]

Mirja, please provide a specific use-case to help justify this. The existence of high delay networks running an unreliable protocol, or a protocol with convergence properties worse than QUIC's own congestion control, does not benefit from this today and to my knowledge works without it.

Otherwise, I cannot justify promoting this from an extension to a core requirement.

Also, I'd like to re-iterate what I said in the interim: this requirements document is outlining the core protocol requirements, and ensuring we have enough extensibility to build the systems that we want. We do not need to (or want to!) mandate every capability for every use case. I fully anticipate we will have to publish not just an implementation RFC of the core protocol, but also a list of mandatory-to-implement extensions for specific use cases. There is wide precedent for this in the IETF; for example, ALPN is mandatory-to-implement in QUIC but is an extension to TLS (note: an earlier version of this comment erroneously said "TLS1.3" instead of QUIC, I got my wires crossed).

[mirjak]

The use case is local recovery for high loss links. This has nothing to do with high-delay networks. The assumption is the opposite that you would have a QUIC tunnel for a local link with only little latency compared to the end-to-end connection within the tunnel. Beside problems with physical links that for some reasons made have high loss, using an reliable QUIC tunnel could also be interesting in future for mobile networks in order to reduce latency from lower layer recovery mechanism but instead give the client a chance to request reliability if desired.

This could be implemented using one of the extensibility mechanism we define, however, I still argue that this is a very basic (and easy to realise) function that I would like to see it as part of the base spec. Actually thinking further about this, it's probably already going too much into implementation details to say if something is realised as an extension or not, instead of specifying if a requirement is mandatory or maybe desired, or optional, or whatever.

[achernya]

I don't understand your use case, then. "QUIC tunnel for a local link with only little latency compared to the end-to-end connection within the tunnel" means there's still an end-to-end connection with high loss. QUIC cannot do anything better for you unless there's a substantial difference in the congestion control implementation that QUIC uses compared to the protocol you are trying to proxy, as I mentioned before. While I agree that is a possible scenario, it feels extremely unlikely to be common.

Whether something is "basic" or "easy to realize" is not a good metric for deciding if something goes into the core protocol specification. There are plenty of features that are basic and easy to realize that we have moved into extensions so as to avoid cluttering the main mechanism.

I'd like to mention something further: this requirements document is not absolute. Just because we say something is an extension now, or is in the base protocol, does not mean that when we go to do an implementation design we cannot change things around. As a result, I believe if there's a disagreement as to if something should be in the core protocol or extension, then the default should be extension.

[ekr]

I also agree that this seems like an extension.

[mirjak]

Just to clarify the local repair use case: All losses at the high loss local link would be repaired by the reliable QUIC tunnel connection and would not be visible to the end-to-end connection. The local repairs would be seen as delay increases by the end-to-end connection but if the delay of the local link with the QUIC tunnel is low compared to the end-to-end delay that not a problem.