search

quicwg / datagram

In-progress version of draft-ietf-quic-datagram
https://quicwg.org/
31 stars 8 forks source link

Is it obvious that Datagram frame can be aggregated in the same QUIC packet #41

Closed gloinul closed 3 years ago

gloinul commented 3 years ago

I find no discussion about aggregating DATAGRAM frames in the same QUIC packets, with other DATAGRAM frames or other types. Is that so obvious that it is possible that it doesn't need mentioning?

I would be slightly worried that an QUIC stack that aggregate may cause fate sharing between different datagram frames, which the application wasn't expecting. In a classical UDP application clearly doing two calls for UDP packets will create two different packets. Two calls to transmit Datagram frames may not cause multiple QUIC packets to be sent, which is usually for the good. However, it goes back to maybe be clear that this may occurr, and a question if API needs consideration to indicate if aggregation is fine or not?

DavidSchinazi commented 3 years ago

We originally had text for this, but folks pointed out that we can't make recommendations that apply to all use cases: some might want fate sharing while some might not. It's probably best to leave this up to the application.

gloinul commented 3 years ago

So I don't think recommendations are necessary. I think bringing up the issue and the potential need for an API to indicate on per datagram if it is okay for this to be aggregated with other datagrams would be sufficient.

tfpauly commented 3 years ago

Hm, I don't know if there needs to an API for this, that seems like an implementation-specific decision. I'd prefer to not add text for this, to let the applications that use datagrams be free in their usage.

That's not saying that HTTP/3, CONNECT-UDP, can't make recommendations, just that it doesn't need to belong here.

LPardue commented 3 years ago

Section 5 and 5.1 mention the frame can be coalesced with other frames in a packet, and some of the multiplexing concerns. That seems like enough to me.

The suggestion for a specific API to mark non-coalescing reminds me of an issue I opened (and closed) a year ago - https://github.com/quicwg/datagram/issues/5.

I think the text in 5.1 is already open enough to allow people to support this capability as part of a "prioritization API" if they wanted, saying anything more specific seems subjective and implementation territory - as David and Tommy have said.

@gloinul I'd like to wrap this issue up and I'm not seeing much for the editors to do. Can we close it or do you have some specific proposal?

tfpauly commented 3 years ago

@gloinul are you okay to close this issue?

gloinul commented 3 years ago

Yes you may close this issue. I think what is in the editors copy are sufficient.