Subject: [Spud] Additional SPUD use-cases

From: "Pal Martinsen (palmarti)" <[email-masked]>
Date: Mon, 16 Mar 2015 11:07:26 +0000

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

---

From: Ted Hardie <[email-masked]>
Date: Mon, 16 Mar 2015 09:55:58 -0700

Hi Pål-Erik,

Thanks for your message; some comments in-line.

On Mon, Mar 16, 2015 at 4:07 AM, Pal Martinsen (palmarti) <
[email-masked]> 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.
>
> 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.
>
> 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).

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

> _______________________________________________
> Spud mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spud
>
>

---

From: "Black, David" <[email-masked]>
Date: Mon, 16 Mar 2015 21:02:03 +0000

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:[email-masked]] On Behalf Of Ted Hardie
Sent: Monday, March 16, 2015 12:56 PM
To: Pal Martinsen (palmarti)
Cc: [email-masked]
Subject: Re: [Spud] Additional SPUD use-cases

Hi Pål-Erik,

On Mon, Mar 16, 2015 at 4:07 AM, Pal Martinsen (palmarti) <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

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

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

.-.
Pål-Erik

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

---

From: "Pal Martinsen (palmarti)" <[email-masked]>
Date: Tue, 17 Mar 2015 09:47:32 +0000

On 16 Mar 2015, at 22:02, Black, David <[email-masked]<mailto:[email-masked]>> wrote:

Thanks for pointing them out. Interesting read.

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.

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

Cc: [email-masked]<mailto:[email-masked]>

Hi Pål-Erik,

​regards,
Ted​

.-.
Pål-Erik

---

From: "Pal Martinsen (palmarti)" <[email-masked]>
Date: Tue, 17 Mar 2015 10:02:17 +0000

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

Hi Pål-Erik,

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

​

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​

.-.
Pål-Erik

---

From: "Black, David" <[email-masked]>
Date: Tue, 17 Mar 2015 14:18:51 +0000

> This work is TCP based, but with similar goals:
[... snip ...]
> 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.

+1 - that was the reason for sending those draft pointers.

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

The problems aren’t so much network elements, as they are transport protocol side effects.  See the DART draft for more.

>  (Would be interesting to know the rationale on why the networks remarks the DSCP values so we can avoid that with SPUD).

Losing battle; values that can’t be rewritten will be ignored.  If DSCP values are used for QoS, they’re part of the network’s traffic engineering and hence have to be rewritable by the network operator (prior optimism that the values would somehow pass through all networks unchanged w/each network doing something reasonable has proven to be naïve); if they can’t be rewritten, they will (have to) be ignored, IMHO.  This draft provides some info about an approach with end-to-end possibilities that is likely to work if it gets adopted and widely deployed:

http://datatracker.ietf.org/doc/draft-ietf-tsvwg-diffserv-intercon/

Thanks,
--David

From: Spud [mailto:[email-masked]] On Behalf Of Pal Martinsen (palmarti)
Sent: Tuesday, March 17, 2015 5:48 AM
To: Black, David
Cc: [email-masked]
Subject: Re: [Spud] Additional SPUD use-cases

.-.
Pål-Erik

Thanks,
--David

Hi Pål-Erik,

​regards,
Ted​

.-.
Pål-Erik

---

From: Aaron Falk <[email-masked]>
Date: Wed, 18 Mar 2015 12:42:59 -0400

On Mon, Mar 16, 2015 at 5:02 PM, Black, David <[email-masked]> wrote:

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

Hi David-

Are the congestion control concerns being discussed within a working group?

--aaron

---

From: [email-masked]
Date: Wed, 18 Mar 2015 17:13:17 -0000

David & I  approved the talk as a presentation of current research.

My own hopes are that this talk focusses on:

- the existing experiments and running code, showing how this handles
congestion-control.
- Actual gains of a L2-enhanced approach, such as this, compared to a
mechanism such as ECN.
- How to handle speed-increases, previous attempts at explicit signals for
speed increases at the IETF have all failed to progress. I am dubious that
this signal is useful for a shared capacity bearer.
- Explain the security requirements and model (which I do not understand).
- Help understand if this useful outside of a single-bottleneck radio
network.

To avoid any confusion: This is an individual submission expected to start
a discussion, this draft will not be considered as a candidate for
adoption at this meeting.

Gorry

---

From: "Eggert, Lars" <[email-masked]>
Date: Wed, 18 Mar 2015 17:29:39 +0000

> this signal is useful for a shared capacity bearer.

+1

This is exactly why we decided to let https://eggert.org/papers/draft-eggert-tcpm-tcp-retransmit-now-02.txt die.

Lars

---

From: Aaron Falk <[email-masked]>
Date: Wed, 18 Mar 2015 13:37:24 -0400

Ah, so in TSVWG.  +1 to your list of hopes.

--aaron

---

From: "Black, David" <[email-masked]>
Date: Wed, 18 Mar 2015 21:16:04 +0000

> - Explain the security requirements and model (which I do not understand).

I believe that I do understand the security model, and I see serious problems with it.

Overall, as Gorry noted, we (tsvwg chairs) put this topic (primarily draft-sprecher-mobile-tg-exposure-req-arch) on the tsvwg Dallas  agenda because we think there’s an interesting discussion to be had about what could and should be done in this area.
Speaking for myself, understanding the possibilities here is useful, so the experiments are valuable, but I don’t regard the protocol used to run the experiments as useful for much beyond than running experiments.

Thanks,
--David

From: Aaron Falk [mailto:[email-masked]]
Sent: Wednesday, March 18, 2015 1:37 PM
To: Gorry Fairhurst
Cc: Pal Martinsen (palmarti); Black, David; Ted Hardie; [email-masked]
Subject: Re: [Spud] Additional SPUD use-cases

--aaron

On Wed, Mar 18, 2015 at 1:13 PM, <[email-masked]<mailto:[email-masked]>> wrote:
David & I  approved the talk as a presentation of current research.

Gorry

> On Mon, Mar 16, 2015 at 5:02 PM, Black, David <[email-masked]<mailto:[email-masked]>> wrote:
>

---

From: Mirja Kühlewind <[email-masked]>
Date: Thu, 19 Mar 2015 11:38:05 -0400

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) <[email-masked]>:
> 
> 
>> On 16 Mar 2015, at 22:02, Black, David <[email-masked]> wrote:
>> 
>> On Mon, Mar 16, 2015 at 4:07 AM, Pal Martinsen (palmarti) <[email-masked]> wrote:
>> Hi, 
>>

---

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Thu, 19 Mar 2015 17:17:10 +0000

>- 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…?)

I'm CC'ing in some people that I know are interested in working on "COSE", a recoding of JOSE into CBOR, but who may not be subscribed to the SPUD list.

One approach we could take is have the client put a (tube-specific? time-limited?) public key into each OPEN packet in a path-accessible way.  Assertions from the application could be signed with the corresponding private key, assertions from the path could be encrypted with the public key.  

I'm worried about the CPU overhead for middleboxen, but we could both make this optional in the protocol and required-by-default in the library to see what the market shakes out as use cases.

-- 
Joe Hildebrand

---

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Thu, 19 Mar 2015 18:01:15 +0000

> One approach we could take is have the client put a (tube-specific? time-limited?) 
> public key into each OPEN packet in a path-accessible way.  Assertions from the 
> application could be signed with the corresponding private key, assertions from 
> the path could be encrypted with the public key.

On 3/19/15, 11:56 AM, "Richard Barnes" <[email-masked]> wrote:

>Honestly, this seems quixotic.  Can we just specify that SPUD has a stack of messages, and leave it at that?

Nod.  Particularly if SPUD ends up just being requirements for DTLS, there's no reason to go down this path.  I've got COSE on the brain today. :)

-- 
Joe Hildebrand

---

From: Richard Barnes <[email-masked]>
Date: Thu, 19 Mar 2015 13:56:02 -0400

Honestly, this seems quixotic.  Can we just specify that SPUD has a stack
of messages, and leave it at that?

Since there's no authentication of the middleboxes, the endpoint can't tell
the difference between a middlebox changing a value and just deleting it
and replacing it, which it can still do in this scheme.

You might think you could prevent middleboxes from seeing each others'
messages, but since there's no authentication on the *endpoint* keys, a
middlebox could just replace the key and send the messages on, then take
things on the return path, snarf whatever messages it wants, and re-encrypt
them to the real key.

So there is very limited benefit here, if at all.

On Thu, Mar 19, 2015 at 1:17 PM, Joe Hildebrand (jhildebr) <
[email-masked]> wrote:

> >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 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…?)
>
> I'm CC'ing in some people that I know are interested in working on "COSE",
> a recoding of JOSE into CBOR, but who may not be subscribed to the SPUD
> list.
>
> One approach we could take is have the client put a (tube-specific?
> time-limited?) public key into each OPEN packet in a path-accessible way.
> Assertions from the application could be signed with the corresponding
> private key, assertions from the path could be encrypted with the public
> key.
>
> I'm worried about the CPU overhead for middleboxen, but we could both make
> this optional in the protocol and required-by-default in the library to see
> what the market shakes out as use cases.
>
> --
> Joe Hildebrand
>
>
>
>

---

From: Mirja Kühlewind <[email-masked]>
Date: Thu, 19 Mar 2015 14:09:12 -0400

Okay, the question is than rather, how can we avoid that non-spud-aware middleboxes accidentally modify spud information which can hinder spud deployment is the same way other approaches failed…? I think we should at least be somehow able to detect these kind of unintentional modifications.

Mirja

> Am 19.03.2015 um 13:56 schrieb Richard Barnes <[email-masked]>:
> 
> Since there's no authentication of the middleboxes, the endpoint can't tell the difference between a middlebox changing a value and just deleting it and replacing it, which it can still do in this scheme.  
> 
> You might think you could prevent middleboxes from seeing each others' messages, but since there's no authentication on the *endpoint* keys, a middlebox could just replace the key and send the messages on, then take things on the return path, snarf whatever messages it wants, and re-encrypt them to the real key.
> 
> On Thu, Mar 19, 2015 at 1:17 PM, Joe Hildebrand (jhildebr) <[email-masked]> wrote:

---

From: Richard Barnes <[email-masked]>
Date: Thu, 19 Mar 2015 15:03:53 -0400

I see.  That's a different question.  Seems like some sort of basic
consistency check / checksum would be sufficient?

On Thu, Mar 19, 2015 at 2:09 PM, Mirja Kühlewind <
[email-masked]> wrote:

> Okay, the question is than rather, how can we avoid that non-spud-aware
> middleboxes accidentally modify spud information which can hinder spud
> deployment is the same way other approaches failed…? I think we should at
> least be somehow able to detect these kind of unintentional modifications.
>
> Mirja
>
>
> > Since there's no authentication of the middleboxes, the endpoint can't
> tell the difference between a middlebox changing a value and just deleting
> it and replacing it, which it can still do in this scheme.
> >
> > >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
> > >- 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…?)
> >
> > I'm CC'ing in some people that I know are interested in working on
> "COSE", a recoding of JOSE into CBOR, but who may not be subscribed to the
> SPUD list.
> >
> > I'm worried about the CPU overhead for middleboxen, but we could both
> make this optional in the protocol and required-by-default in the library
> to see what the market shakes out as use cases.
> >
> > --
> > Joe Hildebrand
> >
> >
> >
> >
>
>