I'm late to this discussion, but if the need is a protocol that delivers streams without encryption, SCTP (or SCTP over UDP) is a reasonably well-vetted choice that would appear to meet the requirements. It certainly sounds superior to asking people to invent a new protocol.
(Which is not to say that the suggestions to making QUIC work in this use case are unworkable) On Mon, Oct 3, 2022 at 11:38 AM Lucas Pardue <[email protected]> wrote: > Hi Phillip, > > On Mon, 3 Oct 2022, 19:13 Phillip Hallam-Baker, <[email protected]> > wrote: > >> I think we have to actually build a prototype of a transactional-first >> transport, then build some applications over it and only then look to see >> whether/how we might re-use QUIC. >> >> That is how I originally worked on HTTP, I build applications using HTTP >> as a transport, one of which was the first Webmail service, those allowed >> me to discover the need for content length and start working on connection >> keepalive and framing. >> >> And we need to build any such system around the capabilities of modern >> programming languages which support threads and asynchronous methods. >> Otherwise we just end up trapped in subordination type interactions and >> don't progress beyond RPC. >> >> What I am saying is, let me build something, then take a look at it and >> tell me if/how to build it using QUIC. >> > > In case I was unclear, I think building something and revisitng later > sounds like a good approach. Look forward to seeing your progress > > In the meantime, and tangentially, I think its important to we provide a > consistent reminder that QUIC is very unopinionted about the applications > on top. This has been the case for years. I suspect many application > protocols that already exist would straightforwardly map to QUIC. We have > RFCs that do this, many I-Ds either individual or adopted by WGs, and I'm > aware of many protocol mappings that are defined outside the IETF - either > openly documented or private. > > Should future evolution of QUIC provide opportunity for alternative > (re)mappings that people think would be useful, that is entirely possible > and supported. Extension like that should probably also add a section that > extends the applicability document to aid designers and implementers. > > Cheers > Lucas > > > >> >> On Mon, Oct 3, 2022 at 1:19 PM Lucas Pardue <[email protected]> >> wrote: >> >>> Hi Behcet, >>> >>> >>> On Mon, Oct 3, 2022 at 5:56 PM Behcet Sarikaya <[email protected]> >>> wrote: >>> >>>> Hi Christian, >>>> >>>> I quickly glanced through RFC 9250 which defines DoQ and references >>>> ALPN in RFC 7301. >>>> Agree with Philip that DoQ does not define something that is >>>> independent of HTTP. >>>> >>>> Will it come one day, we don't know? >>>> Behcet >>>> >>> >>> DoQ is an application mapping over QUIC. ALPN is an extension to TLS. >>> DoQ might use a transactional model that maps to bidirectional streams but >>> that is the full extent of similarities to HTTP; there is no normative >>> dependency. >>> >>> RFC 9000 was written carefully to describe the interface that >>> application-data-bearing streams can provide to applications. This is not >>> related to HTTP, QUIC is independent of HTTP. Indeed, QUIC on its own means >>> pretty much nothing. It needs an application mapping protocol. The >>> recently-published applicability draft, RFC 9308 [1], is specifically >>> written to aid designers or implementers of such mappings. Randy might find >>> RFC 9308 informative if wishing to pursue QUIC as a transport substrate for >>> the OT application layer traffic. >>> >>> Cheers >>> Lucas >>> >>> [1] - https://www.rfc-editor.org/rfc/rfc9308.html >>> >>> >>> >>
