Re: [Spud] Additional SPUD use-cases

["Black, David" <[e-mail]>]

Here are four potentially related drafts:

-- Rate Adaptation based on network feedback, and (to some extent) FCFS (weak) admission control:

This work is TCP based, but with similar goals:

https://datatracker.ietf.org/doc/draft-sprecher-mobile-tg-exposure-req-arch/
https://datatracker.ietf.org/doc/draft-flinck-mobile-throughput-guidance/

The latter draft is (IMHO) better viewed as a proof-of-concept demonstration that this can work, as opposed to a specific protocol design for how to do it.  Design concerns have been raised about what was done there (e.g., aggressive use of TCP options).

-- Dynamic Per Type Packet Prioritization (DPTPP *sigh*)

Web RTC wants to do this from the application:

      https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rtcweb-qos/

And it can be done, if one is careful:

      https://datatracker.ietf.org/doc/draft-ietf-dart-dscp-rtp/ (in RFC Editor Queue)


Thanks,
--David

From: Spud [mailto:[e-mail]] On Behalf Of Ted Hardie
Sent: Monday, March 16, 2015 12:56 PM
To: Pal Martinsen (palmarti)
Cc: [e-mail]
Subject: Re: [Spud] Additional SPUD use-cases

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.  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).
​

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

​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