datagrams: Add initial datagram draft#680
Conversation
marten-seemann
left a comment
marten-seemann
left a comment
There was a problem hiding this comment.
Have you considered tying a datagram flow to a stream, similar to what HTTP DATAGRAMS (RFC 9297) does?
This would have the following benefits:
- Shorter datagram header (especially important given MTU restrictions).
- Both peers get the opportunity to cancel a datagram flow (by closing / resetting the associated stream).
- A reliable control channel, e.g. for application protocols that need to send an occasional control message next to a datagram flow.
|
Thanks @marten-seemann! That's a nice idea. We can include the versioning information in the stream as well so we don't pay that overhead on every datagram. The datagram itself then only has a single varint of overhead. |
MarcoPolo
force-pushed
the
marco/datagrams
branch
from
8dac785 to
1b5c110
Compare
|
@jxs - I've reached out to zig, nim, py and dotnet for feedback to get this moving. |
| libp2p datagrams on WebTransport behave the same as libp2p datagrams on QUIC. | ||
| However, the application data may be further limited by the overhead of HTTP | ||
| Datagram's Quarter Stream ID field. | ||
|
|
||
| In the future, a separate spec may be able to remove this overhead. |
There was a problem hiding this comment.
the quic encoding uses a stream id as the control stream identifier, but browser webtransport doesn't expose quic stream ids. If browser implementations are expected to support this, how is the control stream identified? would some specific webtransport flow identifier be needed?
| start sending datagrams at once. There is currently no other use for the control | ||
| stream besides negotiating the application protocol ID. Receipt of a QUIC | ||
| DATAGRAM frame whose payload is too short to allow parsing the Control Stream ID | ||
| field MUST be treated as a connection error of type PROTOCOL_VIOLATION (0x1003). |
There was a problem hiding this comment.
Perhaps something like this so the name does not clash with QUIC's own PROTOCOL_VIOLATION (0x0a) error? (also on line 71:72)
| field MUST be treated as a connection error of type PROTOCOL_VIOLATION (0x1003). | |
| field MUST be treated as a connection error of type DG_PROTOCOL_VIOLATION (0x1003). |
| If a libp2p datagram is received and its Control Stream ID field maps to a | ||
| stream that cannot be created due to client-initiated bidirectional stream | ||
| limits, it MUST be treated as a connection error of type PROTOCOL_VIOLATION | ||
| (0x1003). |
There was a problem hiding this comment.
i'm a bit confused by the reference to "client-initiated bidirectional stream limits". Can control streams be opened by either peer?
| protocol. A control stream is a QUIC bidirectional stream that has negotiated | ||
| the libp2p datagram control stream protocol ID `/dg/1`. The initiator MUST send | ||
| the related application protocol ID with a [uvarint] length prefix after | ||
| negotiating the control stream. The control stream MUST stay open for the |
There was a problem hiding this comment.
i think it would help to clarify the receiver behavior if the application protocol id is unsupported or malformed. (i.e. close stream / reset?). Is this going to use multistream-select?
| the related application protocol ID with a [uvarint] length prefix after | ||
| negotiating the control stream. The control stream MUST stay open for the | ||
| duration of the datagram flow. Implementation MAY create the control stream and | ||
| start sending datagrams at once. There is currently no other use for the control |
There was a problem hiding this comment.
What should happen to datagrams that arrive before control stream has finished /dg1 processing and application protocol negotiation? should they be dropped or buffered?
4 participants
Initial text for specifying how datagrams will work on libp2p.
cc @raulk @sukunrt @jxs