Re: [Spud] Additional SPUD use-cases

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

On 16 Mar 2015, at 17:55, Ted Hardie <[e-mail]<mailto:[e-mail]>> wrote:

Hi Pål-Erik,

Thanks for your message; some comments in-line.

On Mon, Mar 16, 2015 at 4:07 AM, Pal Martinsen (palmarti) <[e-mail]<mailto:[e-mail]>> wrote:
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.
​

​When you say “the network" here, this seems to me the first hop-AP.

That probably provides most value. But the use case is not limited to just wireless. It can be useful for a coffeeshop to have similar functionality performed by the gateway device.

For cases where the radio resources are at issue, it seems likely that you might want to coordinate this with the other 802.11 facilities, so I'm not sure that this the right layer to do this.  In particular, multi-AP deployments might request the station re-associate to a less-busy AP or make other adjustments to the channel handling of frame marked with the higher priority WMM bits (given the potential issues with cross-talk, shifting APs is certainly not a panacea, but my be better than what amounts to admission control).

Yes. Close coordination with the layers beneath are needed. This can also be viewed as an application friendly tspec signalling. Tspec should handle this, but getting that information from the wireless driver all the way up to the application might prove difficult without any admin privileges.

​

* 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.


​I think ordinal priority among the tubes coming from the same user is a baseline use case.  There seem to be two possibilities to making that dynamic:  mint a new tube or set of tubes on the same 6-tuple ​when the ordinal priority changes or update the ordinal priority on the existing tubes.  I am not sure of the complexity trade-off between those two yet, and I'd be interested in folks thoughts on that.

Instinctively I would say make it easy for the app developer. And I think updating priorities in existing tubes is the easies way. They are already set up, and middle boxes have accepted the tubes. Tearing down and setting up new tubes seems to cause more pain for all involved parties.

But more considerations should be given to how to best solve this problem.

.-.
Pål-Erik

​regards,

Ted​




Comments, flames and what not are of course welcome.

.-.
Pål-Erik

_______________________________________________
Spud mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/spud


_______________________________________________
Spud mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/spud