At the time of writing this, the spec says that when sending a packet:
If packet’s sendTime is greater than now + 100ms, throw a RangeError.
This magic value of 100ms should be made more explicit, perhaps by exposing it as a property, so an application knows what is expected of it. The spec further raises this question:
What should the acceptable range for the send time be? What if the send time is in the past?
as https://w3c.github.io/webrtc-rtptransport/#issue-20dce09d
I see at least three options here:
- Packets are always appended to the end of the queue. If the send time is in the past, that simple means "send it as soon as possible".
- The queue of pending packets to be sent is ordered by send time (not packet id), so it's possible to add packets before other packet already pending in the queue.
- Reject packets is send time is in the past. This seems like a bad option as it'll easily be racy.
I think (1) is probably the one with the least surprising behavior.
Another related question: Should there be a queue size limit, in terms of number of packets, number of bytes or both? Otherwise we risk an application accidentally or deliberately enqueueing an arbitrarily large amount of data before we have any feedback available. If there is something akin to a congestion window, the application should be able to understand that size of that window.
At the time of writing this, the spec says that when sending a packet:
This magic value of 100ms should be made more explicit, perhaps by exposing it as a property, so an application knows what is expected of it. The spec further raises this question:
as https://w3c.github.io/webrtc-rtptransport/#issue-20dce09d
I see at least three options here:
I think (1) is probably the one with the least surprising behavior.
Another related question: Should there be a queue size limit, in terms of number of packets, number of bytes or both? Otherwise we risk an application accidentally or deliberately enqueueing an arbitrarily large amount of data before we have any feedback available. If there is something akin to a congestion window, the application should be able to understand that size of that window.