Re: [Spud] Additional SPUD use-cases

[Ted Hardie <[e-mail]>]

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]> 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]
> https://www.ietf.org/mailman/listinfo/spud
>
>