Align the protocol with draft-jennings-quicr-proto

[huitema]

And vice versa, probably.

That may mean developing a way to acquire the manifest, new formats for subscribe messages, etc.

[huitema]

@suhasHere that means, in particular, unifying the Quicrp and Quicr layers. Right now, it is duplicate functionality. Maybe migrate the Quicr code inside the Quicrp prototype. That would be good for performance, and also for control.

[suhasHere]

@huitema may be I am missing something here, what do you mean by "migrate the Quicr code inside the Quicrp prototype."

My understanding of this work was

1. Support various messages - Publish/Publish_Intent/Subscribe/Relay_Redirect and so on. Also implement their semantics in client, origin and relay
2. map the naming to match group of objects or a variant of that, but decide on it
3. support relay behavior similar to one in the draft and possibly extend it
4. Define media capabilities (aka manifest) that defines just the template as in the draft
5. may be something more that I am missing

What are your thoughts here ?

[huitema]

When we were discussing performance, you told me that your code would read the media segment, format it as a quicr message in a separate thread, and then write it out as a datagram frame. I think it would be much cleaner if that wrapping up in a quicr message was done inside quicrq.

[suhasHere]

The current send pipeline is encoded media -> fragment -> encode in to app message structutre that has app specific identities -> enqueue the binary blob into the transport queue

=== then on picoquic requesting for new data --> deque the opaque binary blob from the transport queue --> set it as data parameter into the quicrq callback

We can discuss further on how and where to optimize the flow here over a call or something

[huitema]

I think we should discuss this further, as we progress towards a more refined prototype. The more I think of it, the more I believe we need to split the application into an end-to-end layer visible by clients and origins, and a media-transfer layer implemented by relays, clients and origins. We cannot expect the relays to have detailed knowledge of the application, which is why I think we need something like a "media stream" abstraction. This would get a split of functions:

• identities of clients, steams, etc., mostly handled inside the application.
• interface between application and the media stream layer using an API that exposes just enough data to relays to handle media routing, find the origin, etc.
• interface between media sources and media stream layer to expose key elements of the media stream such as restart points, frames, maybe priority levels and time stamps.

That probably mean revising the QUICR protocol and split it between what belongs in "media stream" and wht in "application control".

[huitema]

I think this points to the biggest "impedance mismatch" between the QUICR spec and the implementation. The QUICR spec assumes that every message is either "subscribe" or "publish". If I read the spec, each piece of data sent on the media stream is a "publish" message, carrying the whole set of protocol data:

PUBLISH {
     ORIGIN            (String)
     NAME              (Number128)
     FLAGS             (Byte)
     FRAGMENT_ID       (Number16)
     BESTBEFORE        (Number64)
     TIMESTAMP         (Number64)
     PAYLOAD           (ByteArray)
   }

In the implementation, I assumed that the full Subscribe or Publish messages are only sent at the beginning of a "media stream", identified by a media stream ID -- typically the ID of the QUIC Stream used for control in the datagram case, or for both control and transmission in the stream case.

So we have a split:

• Publish means "providing a media stream", and only defines Origin, Name and maybe flags
• The media stream itself is a series of fragments, including frame number, fragment ID and payload. This could be extended to include best before, time stamp, and maybe flags.

[suhasHere]

@huitema Agree with you that we need to rethink it a bit. The basic expectation on relays here is

• when it gets a published data, it knows where in cache to store the data
• An easy way to do that mapping
• allow redirects to a new relay to have similar behavior
• have per payload markings and aggregate markings for relay to act upon

I am with you on the fact that we need to split the things into

• needs to be shared once
• needs to be shared per payload

• Let me setup sometime to discuss the same . thanks

[huitema]

The differences between code and spec started with the need to support both QUIC streams and QUIC datagrams, and also with the need to separate signaling and transport. I think that we can draw a path forward as follow:

• enhance the spec to describe signalling transactions such as "subscribe" and "upload" (or post)
• enhance the spec by explaining how streams get closed: unsubscribe, marking the end of an upload, etc. The code manages that by mapping each transaction to a QUIC stream used for control. Closing that stream is equivalent to closing the subscription. Maybe describe that in the spec.
• enhance the spec and replace the 16 bytes identifier by a negotiated stream-id, negotiated as part of the subscribe or upload.
• minor point, but it would be nice if the spec mapped integers to the "varint" format defined in RFC 9000, instead of inventing its own coding.
• enhance the spec by tying the "publish" transaction to a previous "subscribe" or "upload". This also means distinguish "publish stream" (called upload above) and "publish object".
• enhance the code to align the datagram fragment header with the stream/group/object/fragment+parameters structure. Currently, it has only stream/object/fragment.

[suhasHere]

@huitema +1 it aligns with our chat and also our thinking towards having a workable demo that shows how relays and clients interact with this protocol.

also I feel, we need to keep streams only mode as well in the spec and have a spec to show how datagrams can be used. Here is the rough list of specs we might end in the initial versions

• Architecture spec
• Protocol Spec with defaulted to QUIC Streams
• Datagram extension spec that builds on the protocol
• Some study report - either as a spec or as an email. I strongly feel having this submitted will help understand the differences. Can we get some data reports you had to start compiling as we develop the poc.

[huitema]

We could document QUIC streams as well. But we will have to answer some questions, in particular:

1) Is the QUIC stream on which data is published the same as the QUIC stream on which the "subscribe" is received? Currently it is, but that implies a single stream for all group of objects, thus head of line blocking.

2) Do we want a single QUIC Stream for all objects, or one stream per group of objects? One stream per GOO will result in better performance and control, e.g., possibility to drop old group of objects to "skip ahead" if the queue is full. But it is more complex.

3) What is the content of the stream? Are these full objects, or fragments? If full objects, that requires reassembly if a relay receives datagrams and sends streams.

4) Do we send a full header for each object in the stream? Something like

? Probably yes, this is simpler.

5) Is the content in order? Can relay drop low priority data?