Re: [Spud] Additional SPUD use-cases

[Mirja Kühlewind <[e-mail]>]

Hi all,

just a quick though on our comment regarding basically ‚why does DSCP not work inter-domain‘. One answer to this question is that is it mostly used intra-domain and that’s okay. That’s why we look at SPUD because we actually what something inter-domain (at least to signal information without negotiation). Therefore the questions for SPUD are for me:

- How can we ensure that information provided by the end-point does not get modified?

and more complicated

- How can we ensure that information a middlebox puts in is not (wrongly) modified by another middlebox (as there are cases, we we want one middlebox to override data of another middlebox…?)

Mirja


> Am 17.03.2015 um 05:47 schrieb Pal Martinsen (palmarti) <[e-mail]>:
> 
> 
>> On 16 Mar 2015, at 22:02, Black, David <[e-mail]> wrote:
>> 
>> Here are four potentially related drafts:
>>  
> 
> Thanks for pointing them out. Interesting read.
> 
>> -- 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).
> 
> For now my conclusion is; there is interest in solving similar problems for TCP, so adding it to the SPUD use-case discussion make sense.
> 
>>  
>> -- 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)
> 
> We have implemented a prototype setting different DSCP values on different video packets a few years back. The platform we did it on was a bit underpowered regarding main CPU vs video enc/dev processors. The extra setsockopt call to change the pr packet DSCP value caused problems. Was also unsure if any buffering in the OS cause the right markings to be set on the right packet. The sendMsg() function will probably ensure that, but at the time we did not rewrite our stack to support that. 
> 
> Do we have any information that network elements can handle different DSCP values within a 5-tuple? Word on the street a few years back was that it could be difficult for some platforms.
> 
> In my head SPUD will improve the above drafts by:
> 
> - Provide end to end signalling. 
>   (Would be interesting to know the rationale on why the networks remarks the DSCP values so we can avoid that with SPUD).
> 
> - Easier for applications. Just memcpy() a spud buffer in front of your RTP packet (Make sure to start writing your RTP packet a bit into the buffer…), and fire off the packet as usual. This is an important aspect as it eases the integration work of SPUD. If the application already supports ICE it probably does do similar tricks because of TURN. 
> 
> - It is possible to build a SPUD->DSCP gateway. This is nice as customers can place that gateway at the edge and still have the old carefully DSCP crafted network provide value. 
> 
> 
> .-.
> Pål-Erik
> 
>>  
>>  
>> 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]> 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
>> 
>>  
> 
> _______________________________________________
> Spud mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spud