Peeps First Attempt

[martinduke]

I have foregone any premature optimization of the encodings here.

Asking @janaiyengar to take a first look.

[vasilvv]

How does one close a peep? Currently, in our implementation, we rely in combination of delivery preference and object status for that.

[martinduke]

How does one close a peep? Currently, in our implementation, we rely in combination of delivery preference and object status for that.

I think a Stream FIN would be sufficient.

[vasilvv]

How does one close a peep? Currently, in our implementation, we rely in combination of delivery preference and object status for that.

I think a Stream FIN would be sufficient.

How am I supposed to know when to send a FIN?

[martinduke]

How does one close a peep? Currently, in our implementation, we rely in combination of delivery preference and object status for that.

I think a Stream FIN would be sufficient.

How am I supposed to know when to send a FIN?

The publisher sends a FIN when the Peep is done. The relay knows a Peep is complete when it receives the FIN from upstream.

[afrind]

The publisher sends a FIN when the Peep is done. The relay knows a Peep is complete when it receives the FIN from upstream.

Is there ever a case where a publisher needs to close a stream and ensure all data on it is delivered, but does not know that the peep is done, or knows it is not done. For example - in response to an unsubscribe or graceful closure.

[vasilvv]

The publisher sends a FIN when the Peep is done. The relay knows a Peep is complete when it receives the FIN from upstream.

How is this represented in the cache? Are FINs guaranteed to be always at the same position?

One scenario where the sender might FIN a peep earlier is if the next object in the peep is past subscription end, though I'm not sure how we'd hit this in practice.

[martinduke]

The publisher sends a FIN when the Peep is done. The relay knows a Peep is complete when it receives the FIN from upstream.

How is this represented in the cache? Are FINs guaranteed to be always at the same position?

One scenario where the sender might FIN a peep earlier is if the next object in the peep is past subscription end, though I'm not sure how we'd hit this in practice.

Good point, I've added an end of Peep object.

[martinduke]

OK, I believe I've fully addressed all comments except for those I've left unresolved. @suhasHere @ianswett If you are satisfied with my response, please resolve the comment.

[martinduke]

No normative language, summarize what streams are.

[martinduke]

@afrind wants to make a proposal, wait for that

[wilaw]

For bikesheading on the name, I make these two proposals:

1. "Stream" - this correlates directly with the mapping to QUIC. Simple to comprehend and explain.
2. "Block" - this denotes contiguity and avoids overloaded use of the term "stream".

[martinduke]

I have made all changes I know to do. I am awaiting @afrind making a concrete proposal on the question of whether or not two Peeps can have the same priority, and the wire image implications downstream from that.

[martinduke]

Why have Peep ID be a tiebreaker if we also have priority? Just let the streams have the same priority!

[ianswett]

For bikesheading on the name, I make these two proposals:

1. "Stream" - this correlates directly with the mapping to QUIC. Simple to comprehend and explain.
2. "Block" - this denotes contiguity and avoids overloaded use of the term "stream".

Block and Stream work for me.

I was going to say that I prefer "QUIC Stream", but given this might be over WebTransport, technically it'd be a WebTransport stream, so defining the term "Stream" at the top of the document should make that clear.

[suhasHere]

One more name suggestion : SubGroup

[ianswett]

Merging with the understanding that we'll continue to discuss how prioritization should work.