What happens if an application wants to send a too large datagram? about datagram HOT 7 CLOSED

I think a lot of this comes down to an implementation decision. In one sense there is similarity with stream data whn an application tries to write more bytes than the flow control would allow. How that is handles is a choice - you could send some of the bytes (up to the flow control limit) or reject them all and tell the application this. A library might have an API that can returncurrent capacity and expect the application to chunk writes. The list is long and it depends on lots of things we won't agree on.

Specifically for datagram, the OP question can be rephrased as what should the transport do about something that it by definition cannot do. But really its an implementation choice. In mine I expose the maximum size allowed. If an application tries to give me something bigger I reject the operation. I don't drop the datagram, I never accepted it. The application is trying something that will never logically work and there's probably a host of application-layer reasons or ways to deal with it. Mike's comments speak to that but there is not things to say here in this specification IMO

from datagram.

I think this will just be dropped, like the text describes for flow control on congestion control reasons.

The signaling to the application will be API specific for this case. I think we can't say anything normative about this, but we could suggest that implementations consider how this case would be signaled to applications.

from datagram.

I don't like the "just drop it" answer; while datagrams are inherently unreliable, that doesn't mean an application expects a message it sends to not even attempt to be delivered. "Need to handle" basically means applications need to do their own PMTUD implementation atop DATAGRAMs, since even querying an API only tells you one hop.

The DATAGRAM capsule type means that an arbitrarily large datagram can be transported, but loses the benefit of unreliable, out-of-order delivery. I had previously suggested that we could optionally define a Datagram unidirectional stream type, which would allow for reliable out-of-order delivery of larger-than-MTU payloads.

If a datagram being transported is too large for a DATAGRAM frame, perhaps some other method SHOULD be used?

from datagram.

@MikeBishop for H3 datagrams, then, it could fall back to sending a capsule over the stream itself, assuming the application layer knew that the datagram was dropped or too large. I do think for the QUIC datagram layer itself, it can only drop and notify if the application tries to send something too large, and it's up to the application protocol to handle it.

from datagram.

Ah, sorry -- wrong repo! You're correct -- at the QUIC layer, that's all you can do.

from datagram.

Actually I think for datagrams, sending only some of the data should not be an option. I think for datagrams the implicit contract is that the application always gets the whole datagram or nothing. So that's probably something to spell out.

from datagram.

I seriously considered adding a line to the draft that prohibits truncation, but looking into it I realized that this document doesn't define an API contract for sending and receiving datagrams, so truncation is out of scope. Also, I could imagine there exists an application out there that does want truncation, so there's no reason to ban this in all implementations and applications. All existing implementations already the right thing for their applications today, so adding text doesn't help there either. I'm closing this editorial issue with no action so we can move things forward.

from datagram.