Configure streams

[SpencerDawkins]

closes #142

[mengelbart]

This is a useful addition, but I suggest moving it into the MAX_STREAMS/flow control subsection to keep all the things related to that issue in one place.

[SpencerDawkins]

Agreed (thanks for the helpful suggestion). I committed a change for this.

[SpencerDawkins]

@mengelbart - I'm looking at this text, also in {#quic-streams},

A RoQ receiver MUST be prepared to receive RTP packets on any number of QUIC streams (subject to its limit on parallel open streams) and SHOULD not make assumptions about which RTP sequence numbers are carried in which streams.

Note: A sender may or may not decide to discontinue using a lower stream number after starting packet transmission on a higher stream number.

I think this would be better as

Because a sender can continue sending on a lower stream number after starting packet transmission on a higher stream number, a RoQ receiver MUST be prepared to receive RoQ packets on any number of QUIC streams (subject to its limit on parallel open streams) and SHOULD not make assumptions about which RTP sequence numbers are carried in which streams.

I'm not wild about

SHOULD not make assumptions about which RTP sequence numbers are carried in which streams

for a couple of reasons.

Is this more like

SHOULD be prepared to accept any RTP sequence number on any open stream?

We can wait to talk about the SHOULD until we work on #111, but in any event,

• we should have a legitimate reason for why a RoQ receiver would choose not to accept any RTP sequence number on any open stream, given that a RoQ sender can send any RTP sequence number on any open stream, and
• if a RoQ receiver makes that choice, we need to think about what happens next.

If you send me an RTP packet with sequence number 12 on stream 32, and I'm not prepared to accept it. Do I drop it? Do I need to tell you that I'm dropping it because of the stream it arrived on, so you don't look at the ACKs/RRs and decide that you need to reduce the sending rate (because you're sending RTP packets that aren't being acknowledged)? Etc.

[mengelbart]

@mengelbart - I'm looking at this text, also in {#quic-streams},

A RoQ receiver MUST be prepared to receive RTP packets on any number of QUIC streams (subject to its limit on parallel open streams) and SHOULD not make assumptions about which RTP sequence numbers are carried in which streams.
Note: A sender may or may not decide to discontinue using a lower stream number after starting packet transmission on a higher stream number.

I think this would be better as

Because a sender can continue sending on a lower stream number after starting packet transmission on a higher stream number, a RoQ receiver MUST be prepared to receive RoQ packets on any number of QUIC streams (subject to its limit on parallel open streams) and SHOULD not make assumptions about which RTP sequence numbers are carried in which streams.

Sounds good to me.

I'm not wild about

SHOULD not make assumptions about which RTP sequence numbers are carried in which streams

for a couple of reasons.

Is this more like

SHOULD be prepared to accept any RTP sequence number on any open stream?

We can wait to talk about the SHOULD until we work on #111, but in any event,

* we should have a legitimate reason for why a RoQ receiver would choose not to accept any RTP sequence number on any open stream, given that a RoQ sender can send any RTP sequence number on any open stream, and

* if a RoQ receiver makes that choice, we need to think about what happens next.

If you send me an RTP packet with sequence number 12 on stream 32, and I'm not prepared to accept it. Do I drop it? Do I need to tell you that I'm dropping it because of the stream it arrived on, so you don't look at the ACKs/RRs and decide that you need to reduce the sending rate (because you're sending RTP packets that aren't being acknowledged)? Etc.

These are good points. I think we want to use MUST instead. There should be no special treatment of RTP packets just because they arrive on a stream with a lower ID or on datagrams.