[Spud] Additional SPUD use-cases

["Pal Martinsen (palmarti)" <[e-mail]>]

Hi,

I have a few additional SPUD use-cases I want to bring to the list before the BoF. Some of them have already been solved by using STUN as a signalling protocol (http://tools.ietf.org/id/draft-martinsen-tram-discuss-02.txt). I think SPUD is a more efficient carrier of the bits needed to solve some of the use-cases. But for now they are just use-cases, and discussions on how to solve them should probably be deferred to a later stage.

* Rate Adaption With Confidence
Todays delay sensing rate adaption mechanisms seems to be working very well and can potentially react within half a RTT (Is TT, Trip Time, more accurate or in use as a term?). Having explicit network feedback signalled back to endpoint enabled endpoints to pick a more reasonable starting value when sending media. Explicit signalling during the call enables the network as to signal information back to the endpoint before the problems occur (ECN). Up/down speeding could potentially be done in larger chunks with confidence.

* First Come, First Serve
In WiFi we have some lab tests that show when you hit a limit you hit it hard and everybody on that link suffers. If 9 people enjoy their video conversations going through the same WiFi AP, it is annoying if a 10th call is added causing everybody to get bad video. A possible solution is to let the network signal back to the 10th participants trying to send video that bandwidth is not available; “I will put you in worse than best effort queue if you try to send at that rate”. If bandwidth become available the network will notify the user. Note that this is not RSVP and resource allocation, just hints from the network that if you try, you will suffer.

* Dynamic Per Type Packet Prioritisation (DPTPP *sigh*)
The SPUD use case draft opens up for tube prioritisation. It is possible to prioritise among for example audio, video and data tubes when multiplexing (Bundle) is in use. It is important that the prioritisation is made dynamic. When running a video conference you might want to prioritise video packets, but suddenly there is a need to upload a large presentation to all the participants. In that case it might not make sense for participants having pristine 1080p60 video watching each other waiting for the slow uploading of the presentation to finish.

And the packet type prioritisation does not necessarily stop at audio or video level. Video packets can have for example spatial layers where packets belonging to a temporal layer can be discarded by the network without to much impact on the video quality. Discarding an I-Frame would have much more impact on the quality.



Comments, flames and what not are of course welcome.

.-.
Pål-Erik