Subject: [Marnew] RFC 6077

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Thu, 24 Sep 2015 09:36:12 +0000

On the MarNew page, I see some ideas related to network-support/network-assisted congestion control. The IRTF has written some time ago RFC 6077, and it could be useful to review the challenges in Section 3.1 therein. Of course, parts of that RFC may be outdated.

Michael (co-author of RFC 6077)

---

From: "Smith, Kevin, (R&D) Vodafone Group" <[email-masked]>
Date: Thu, 24 Sep 2015 11:34:45 +0000

Hi Michael,
Thanks for reminding me - Bob Briscoe also recommended 6077, especially when considering the impact of providing congestion hints (namely in the Mobile Throughput Guidance draft). Certainly we need to make sure that such efforts do not merely shift the bottleneck to cause problems elsewhere. So as you say we can review those challenges - if not in detail at the workshop then on the mailing list.
All best
Kevin

"Scharf, Michael (Michael)" <[email-masked]> wrote:

_______________________________________________
Marnew mailing list
[email-masked]
https://www.iab.org/mailman/listinfo/marnew

---

From: Blake Matheny <[email-masked]>
Date: Thu, 24 Sep 2015 12:39:50 +0000

I’ve asked a couple of vendors for congestion hints in a variety of ways. So far, no luck :) I would really like to see this as well.

On 9/24/15, 7:34 AM, "Marnew on behalf of Smith, Kevin, (R&D) Vodafone Group" <[email-masked] on behalf of [email-masked]> wrote:

>https://urldefense.proofpoint.com/v1/url?u=https://www.iab.org/mailman/listinfo/marnew&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=dPSUqzzpoMUu%2B7UN6oQ1DQ%3D%3D%0A&m=sfDv5HORjurZqK2gt%2FlxX1SHIUOTFXmXhNMlEycm9DI%3D%0A&s=287c4a2ca16575e5bb0b89f8a38b2058107aa632016e43ad3d5820b036687265
>
>https://urldefense.proofpoint.com/v1/url?u=https://www.iab.org/mailman/listinfo/marnew&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=dPSUqzzpoMUu%2B7UN6oQ1DQ%3D%3D%0A&m=sfDv5HORjurZqK2gt%2FlxX1SHIUOTFXmXhNMlEycm9DI%3D%0A&s=287c4a2ca16575e5bb0b89f8a38b2058107aa632016e43ad3d5820b036687265

---

From: Ca By <[email-masked]>
Date: Thu, 24 Sep 2015 05:49:30 -0700

On Thursday, September 24, 2015, Blake Matheny <[email-masked]> wrote:

> I’ve asked a couple of vendors for congestion hints in a variety of ways.
> So far, no luck :) I would really like to see this as well.
>
>
>
The problem is these hints are too ephemeral and dynamic to be useful.
Someone turns on a microwave oven and congestion becomes high ....

This just seems to be more signalling without actionable information. I
belive tcp already provides these hints

>
>
> On 9/24/15, 7:34 AM, "Marnew on behalf of Smith, Kevin, (R&D) Vodafone
> Group" <[email-masked] <javascript:;> on behalf of
> [email-masked] <javascript:;>> wrote:
>
> >Hi Michael,
> >Thanks for reminding me - Bob Briscoe also recommended 6077, especially
> when considering the impact of providing congestion hints (namely in the
> Mobile Throughput Guidance draft). Certainly we need to make sure that such
> efforts do not merely shift the bottleneck to cause problems elsewhere. So
> as you say we can review those challenges - if not in detail at the
> workshop then on the mailing list.
> >All best
> >Kevin
> >
> >"Scharf, Michael (Michael)" <[email-masked]
> <javascript:;>> wrote:
> >
> >
> >On the MarNew page, I see some ideas related to
> network-support/network-assisted congestion control. The IRTF has written
> some time ago RFC 6077, and it could be useful to review the challenges in
> Section 3.1 therein. Of course, parts of that RFC may be outdated.
> >
> >[email-masked] <javascript:;>
> >
> >[email-masked] <javascript:;>
> >
> [email-masked] <javascript:;>

---

From: Blake Matheny <[email-masked]>
Date: Thu, 24 Sep 2015 13:11:43 +0000

I don’t think that has to be the case. I’d like to get channel bandwidth, allocated channels vs available channels, and a couple of other things from the tower. Beyond collecting this data to better understand global trends, we use similar (less accurate) signals for making dynamic decisions (for instance, disable a particular feature because conditions look like X).

Just because the signals are ephemeral/dynamic don’t mean they aren’t useful. TCP does not provide these hints. Also struct tcp_info is a Linuxism and is not widely available across platforms.

-Blake

From: Ca By
Date: Thursday, September 24, 2015 at 8:49 AM
To: Blake Matheny
Cc: "Smith, Kevin, (R&D) Vodafone Group", "Scharf, Michael (Michael)", "[email-masked]<mailto:[email-masked]>"
Subject: Re: [Marnew] RFC 6077

On Thursday, September 24, 2015, Blake Matheny <[email-masked]<mailto:[email-masked]>> wrote:
I’ve asked a couple of vendors for congestion hints in a variety of ways. So far, no luck :) I would really like to see this as well.

The problem is these hints are too ephemeral and dynamic to be useful.  Someone turns on a microwave oven and congestion becomes high ....

This just seems to be more signalling without actionable information. I belive tcp already provides these hints

On 9/24/15, 7:34 AM, "Marnew on behalf of Smith, Kevin, (R&D) Vodafone Group" <[email-masked]<javascript:;> on behalf of [email-masked]<javascript:;>> wrote:

>"Scharf, Michael (Michael)" <[email-masked]<javascript:;>> wrote:
>
>
>[email-masked]<javascript:;>
>[email-masked]<javascript:;>
_______________________________________________
Marnew mailing list
[email-masked]<javascript:;>
https://www.iab.org/mailman/listinfo/marnew<https://urldefense.proofpoint.com/v1/url?u=https://www.iab.org/mailman/listinfo/marnew&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=dPSUqzzpoMUu%2B7UN6oQ1DQ%3D%3D%0A&m=Jss0283WJ77x215YTlEiFoCnppBsdgDltN16tKkCNn0%3D%0A&s=89899417f5b429204a349b6420a315e537ba5bac6608bfaf44f3af11cc8a1b17>

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 24 Sep 2015 13:21:11 +0000

> Just because the signals are ephemeral/dynamic don’t mean they aren’t useful. TCP does not provide these hints.

And UDP is mportant.  And a use case of someone using their phone at home, then in the car, and then in the office, is important.  (For example, watching a keynote while in a carpool (certainly not driving;), before coming into a work meeting.  Or watching a football  game at the office and then on the train home.)

--  
Senior Architect, Akamai Technologies
IM: [email-masked] Twitter: RichSalz

---

From: Ca By <[email-masked]>
Date: Thu, 24 Sep 2015 06:28:46 -0700

On Thursday, September 24, 2015, Blake Matheny <[email-masked]> wrote:

> I don’t think that has to be the case. I’d like to get channel bandwidth,
> allocated channels vs available channels, and a couple of other things from
> the tower. Beyond collecting this
>
>
Why not get it from the ue?

You realize this data will all change before you even receive it? So it
would be no more than a historical record.

Also, there may be privacy concerns here.

Maybe i dont want you to know my location. Everytime the 49ers play at
home, my congestion goes up, you may now infer my location.

> data to better understand global trends, we use similar (less accurate)
> signals for making dynamic decisions (for instance, disable a particular
> feature because conditions look like X).
>
> Just because the signals are ephemeral/dynamic don’t mean they aren’t
> useful. TCP does not provide these hints. Also struct tcp_info is a
> Linuxism and is not widely available across platforms.
>
> -Blake
>
> From: Ca By
> Cc: "Smith, Kevin, (R&D) Vodafone Group", "Scharf, Michael (Michael)", "
> [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>"
> On Thursday, September 24, 2015, Blake Matheny <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>
>> Group" <[email-masked] on behalf of [email-masked]>
>> wrote:
>>
>> >Hi Michael,
>> <https://urldefense.proofpoint.com/v1/url?u=https://www.iab.org/mailman/listinfo/marnew&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=dPSUqzzpoMUu%2B7UN6oQ1DQ%3D%3D%0A&m=Jss0283WJ77x215YTlEiFoCnppBsdgDltN16tKkCNn0%3D%0A&s=89899417f5b429204a349b6420a315e537ba5bac6608bfaf44f3af11cc8a1b17>
>>
>

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 24 Sep 2015 09:31:15 -0400

No Operator would share that kind of information from their base 
station. That is a non-starter. The base stations are busy with what 
they usually do best - delivering as many bits as possible to the UEs 
attached to it.

Vijay

On 9/24/15 9:11 AM, Blake Matheny wrote:
> I don’t think that has to be the case. I’d like to get channel 
> bandwidth, allocated channels vs available channels, and a couple of 
> other things from the tower. Beyond collecting this data to better 
> understand global trends, we use similar (less accurate) signals for 
> making dynamic decisions (for instance, disable a particular feature 
> because conditions look like X).
>
> Cc: "Smith, Kevin, (R&D) Vodafone Group", "Scharf, Michael (Michael)", 
> "[email-masked] <mailto:[email-masked]>"
>     <mailto:[email-masked]>> wrote:
>
>         I’ve asked a couple of vendors for congestion hints in a
>         variety of ways. So far, no luck :) I would really like to see
>         this as well.
>
>
>
>     The problem is these hints are too ephemeral and dynamic to be
>     useful.  Someone turns on a microwave oven and congestion becomes
>     high ....
>
>     This just seems to be more signalling without actionable
>     information. I belive tcp already provides these hints
>
>
>
>         On 9/24/15, 7:34 AM, "Marnew on behalf of Smith, Kevin, (R&D)
>         Vodafone Group" <[email-masked] <javascript:;> on
>         behalf of [email-masked] <javascript:;>> wrote:
>
>         >Hi Michael,
>         >Thanks for reminding me - Bob Briscoe also recommended 6077,
>         especially when considering the impact of providing congestion
>         hints (namely in the Mobile Throughput Guidance draft).
>         Certainly we need to make sure that such efforts do not merely
>         shift the bottleneck to cause problems elsewhere. So as you
>         say we can review those challenges - if not in detail at the
>         >"Scharf, Michael (Michael)"
>         <[email-masked] <javascript:;>> wrote:
>         >
>         >
>         network-support/network-assisted congestion control. The IRTF
>         has written some time ago RFC 6077, and it could be useful to
>         review the challenges in Section 3.1 therein. Of course, parts
>         of that RFC may be outdated.
>         >

---

From: Ca By <[email-masked]>
Date: Thu, 24 Sep 2015 06:33:44 -0700

On Thursday, September 24, 2015, Salz, Rich <[email-masked]> wrote:

> useful. TCP does not provide these hints.
>
> And UDP is mportant.  And a use case of someone using their phone at home,
> then in the car, and then in the office, is important.  (For example,
> watching a keynote while in a carpool (certainly not driving;), before
> coming into a work meeting.  Or watching a football  game at the office and
> then on the train home.)
>
>

Your point to me is not clear.

But rtcp has a performance reporting function that works with udp / rtp

That said, i am not optimistic on udp's resurgence

https://tools.ietf.org/html/draft-byrne-opsec-udp-advisory-00

> IM: [email-masked] <javascript:;> Twitter: RichSalz
>
>
>

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 24 Sep 2015 13:36:28 +0000

I was agreeing with you, and trying to add two additional reasons.

UDP is important; SPUD and QUIC are two datapoints.  And a use-case of a mobile going home/mobile/work is important.

---

From: Blake Matheny <[email-masked]>
Date: Thu, 24 Sep 2015 13:37:55 +0000

On Thursday, September 24, 2015, Blake Matheny <[email-masked]<mailto:[email-masked]>> wrote:
I don’t think that has to be the case. I’d like to get channel bandwidth, allocated channels vs available channels, and a couple of other things from the tower. Beyond collecting this

You realize this data will all change before you even receive it? So it would be no more than a historical record.

Maybe i dont want you to know my location. Everytime the 49ers play at home, my congestion goes up, you may now infer my location.

The UE doesn’t make this available because the operator doesn’t. The chipsets don’t have support (AFAIK), and there are certainly no UE API’s for use.

The historical record is useful. It not being real-time isn’t a problem.

Many applications require GPS (location) privileges. It’s unclear to me why providing explicit congestion information is somehow worse. Again, this can be an explicit privilege based model.

---

From: Blake Matheny <[email-masked]>
Date: Thu, 24 Sep 2015 13:38:51 +0000

No Operator would share that kind of information from their base station. That is a non-starter. The base stations are busy with what they usually do best - delivering as many bits as possible to the UEs attached to it.

Vijay

I’ve had discussions with carriers that would contradict that statement.

---

From: Andreas Terzis <[email-masked]>
Date: Thu, 24 Sep 2015 10:48:54 -0300

Blake,

Please look at requestBandwidthUpdate() coming up in Android M as an API of
exposing available capacity on the radio downlink.

http://developer.android.com/reference/android/net/ConnectivityManager.html#requestBandwidthUpdate(android.net.Network)

Andreas

On Thu, Sep 24, 2015 at 10:38 AM, Blake Matheny <[email-masked]> wrote:

> No Operator would share that kind of information from their base station.
> That is a non-starter. The base stations are busy with what they usually do
> best - delivering as many bits as possible to the UEs attached to it.
>
> Vijay
>
>

---

From: Blake Matheny <[email-masked]>
Date: Thu, 24 Sep 2015 13:54:58 +0000

People have been calculating bandwidth on their own successfully for a long time, I’ll look at the code and see what my be different here.

At the risk of taking this far off track, maybe this would be a good lunch time discussion. Bandwidth is necessary, but not sufficient, for fully understanding underlying network characteristics.

-Blake

From: Andreas Terzis
Date: Thursday, September 24, 2015 at 9:48 AM
To: Blake Matheny
Cc: Vijay Devarapalli, Ca By, "Scharf, Michael (Michael)", "Smith, Kevin, (R&D) Vodafone Group", "[email-masked]<mailto:[email-masked]>"
Subject: Re: [Marnew] RFC 6077

Blake,

Please look at requestBandwidthUpdate() coming up in Android M as an API of exposing available capacity on the radio downlink.

http://developer.android.com/reference/android/net/ConnectivityManager.html#requestBandwidthUpdate(android.net.Network)<https://urldefense.proofpoint.com/v1/url?u=http://developer.android.com/reference/android/net/ConnectivityManager.html%23requestBandwidthUpdate%28android.net.Network%29&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=dPSUqzzpoMUu%2B7UN6oQ1DQ%3D%3D%0A&m=N5wveO%2BsGGBYBYSvInKvypoNwi%2BY2hKoEtcFsEA%2Fks8%3D%0A&s=21eef043e08976b201cd0e05881e7499bf3c38a77ed5f120869e9941740c3a6a>

Andreas

On Thu, Sep 24, 2015 at 10:38 AM, Blake Matheny <[email-masked]<mailto:[email-masked]>> wrote:
No Operator would share that kind of information from their base station. That is a non-starter. The base stations are busy with what they usually do best - delivering as many bits as possible to the UEs attached to it.

Vijay

_______________________________________________
Marnew mailing list
[email-masked]<mailto:[email-masked]>
https://www.iab.org/mailman/listinfo/marnew<https://urldefense.proofpoint.com/v1/url?u=https://www.iab.org/mailman/listinfo/marnew&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=dPSUqzzpoMUu%2B7UN6oQ1DQ%3D%3D%0A&m=N5wveO%2BsGGBYBYSvInKvypoNwi%2BY2hKoEtcFsEA%2Fks8%3D%0A&s=3fd4cb16c45aa04137335dfdb0f66a36c70cfdb5cb04db07d7cf7b3e78acb149>

---

From: "Smith, Kevin, (R&D) Vodafone Group" <[email-masked]>
Date: Thu, 24 Sep 2015 14:26:12 +0000

Certainly I think that info pertaining to the cell (or cell cluster) as a whole is best managed at the RRC, the dedicated radio resource controller within 3GPP networks. As Cameron says that aspect is too dynamic and ephemeral to effectively share. But there may be cases where the Android API can provide a coarse hint that is useful,  would be worth testing that.

Cheers
Kevin

Blake Matheny <[email-masked]> wrote:

-Blake

From: Andreas Terzis

Blake,

Andreas

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 24 Sep 2015 10:27:18 -0400

There is usually a lag between changing conditions in a cell and the UE 
detecting reduced/increased bandwidth

Vijay

On 9/24/15 9:54 AM, Blake Matheny wrote:
> People have been calculating bandwidth on their own successfully for a 
> long time, I’ll look at the code and see what my be different here.
>
> At the risk of taking this far off track, maybe this would be a good 
> lunch time discussion. Bandwidth is necessary, but not sufficient, for 
> fully understanding underlying network characteristics.
>
> -Blake
>
> From: Andreas Terzis
> Cc: Vijay Devarapalli, Ca By, "Scharf, Michael (Michael)", "Smith, 
> Kevin, (R&D) Vodafone Group", "[email-masked] <mailto:[email-masked]>"
>     Please look at requestBandwidthUpdate() coming up in Android M as
>     an API of exposing available capacity on the radio downlink.
>
>     <https://urldefense.proofpoint.com/v1/url?u=http://developer.android.com/reference/android/net/ConnectivityManager.html%23requestBandwidthUpdate%28android.net.Network%29&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=dPSUqzzpoMUu%2B7UN6oQ1DQ%3D%3D%0A&m=N5wveO%2BsGGBYBYSvInKvypoNwi%2BY2hKoEtcFsEA%2Fks8%3D%0A&s=21eef043e08976b201cd0e05881e7499bf3c38a77ed5f120869e9941740c3a6a>
>
>     Andreas
>
>             No Operator would share that kind of information from
>             their base station. That is a non-starter. The base
>             stations are busy with what they usually do best -
>             delivering as many bits as possible to the UEs attached to it.
>
>             Vijay
>
>
>         [email-masked] <mailto:[email-masked]>
>         <https://urldefense.proofpoint.com/v1/url?u=https://www.iab.org/mailman/listinfo/marnew&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=dPSUqzzpoMUu%2B7UN6oQ1DQ%3D%3D%0A&m=N5wveO%2BsGGBYBYSvInKvypoNwi%2BY2hKoEtcFsEA%2Fks8%3D%0A&s=3fd4cb16c45aa04137335dfdb0f66a36c70cfdb5cb04db07d7cf7b3e78acb149>
>
>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 24 Sep 2015 09:31:37 -0500

+1 on lunchtime discussion. Or something.

Anything like QUIC or SPUD is going to need to work on lots of network
types (at least as well as TCP does), right? So understanding the
characteristics at a coarse level will be helpful, but tying proposals to
specific versions of LTE (say) isn't going to worth the way we want to
work, across network times and over time.

Spencer

On Thu, Sep 24, 2015 at 9:26 AM, Smith, Kevin, (R&D) Vodafone Group <
[email-masked]> wrote:

> At the risk of taking this far off track, maybe this would be a good lunch
> time discussion. Bandwidth is necessary, but not sufficient, for fully
> understanding underlying network characteristics.
>
> -Blake
>
> From: Andreas Terzis
> Cc: Vijay Devarapalli, Ca By, "Scharf, Michael (Michael)", "Smith, Kevin,
> (R&D) Vodafone Group", "[email-masked]"
> Please look at requestBandwidthUpdate() coming up in Android M as an API
> of exposing available capacity on the radio downlink.
>
>

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Thu, 24 Sep 2015 16:11:27 +0000

> No Operator would share that kind of information from their base station. That is a non-starter. The base stations are busy with what they usually do best - delivering as many bits as possible to t…

I agree with this. This is probably considered as sensitive information. Can the operator expose such information and monetize that is an interesting question, Last time I asked such question,  the response was to the affect, “over my dead body” :)

From: Marnew <[email-masked]<mailto:[email-masked]>> on behalf of Vijay Devarapalli <[email-masked]<mailto:[email-masked]>>
Date: Thursday, September 24, 2015 at 6:31 AM
To: Blake Matheny <[email-masked]<mailto:[email-masked]>>, Ca By <[email-masked]<mailto:[email-masked]>>
Cc: "Scharf, Michael (Michael)" <[email-masked]<mailto:[email-masked]>>, "Smith, Kevin, (R&D) Vodafone Group" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Marnew] RFC 6077

Vijay

-Blake

From: Ca By
Date: Thursday, September 24, 2015 at 8:49 AM
To: Blake Matheny
Cc: "Smith, Kevin, (R&D) Vodafone Group", "Scharf, Michael (Michael)", "<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>"
Subject: Re: [Marnew] RFC 6077

On Thursday, September 24, 2015, Blake Matheny <<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>> wrote:
I’ve asked a couple of vendors for congestion hints in a variety of ways. So far, no luck :) I would really like to see this as well.

On 9/24/15, 7:34 AM, "Marnew on behalf of Smith, Kevin, (R&D) Vodafone Group" <[email-masked]<javascript:;> on behalf of [email-masked]<javascript:;>> wrote:

>"Scharf, Michael (Michael)" <<javascript:;>[email-masked]<mailto:[email-masked]>> wrote:
>
>

_______________________________________________
Marnew mailing list
[email-masked]<mailto:[email-masked]>https://www.iab.org/mailman/listinfo/marnew

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 24 Sep 2015 11:34:09 -0500

If I might  make a suggestion ...

It seems to me that if we liimit our statements to "I would never do this
(and, in the context of this workshop, I can tell you that the operator I
work for would never do this)", rather than "no operator would do this", we
may have a more productive conversation.

People may say "no one would ever do this" and be correct about that, but
we don't actually need to decide whether everyone on earth agrees, in order
to have most of the discussions we need to have.

Spencer, speaking as a humble member of the program committee, but only one
member ...

---

From: Ca By <[email-masked]>
Date: Thu, 24 Sep 2015 09:41:45 -0700

On Thu, Sep 24, 2015 at 9:11 AM, Sri Gundavelli (sgundave) <
[email-masked]> wrote:

> station. That is a non-starter. The base stations are busy with what they
> usually do best - delivering as many bits as possible to the UEs attached
> to it.
>
> I agree with this. This is probably considered as sensitive information.
> Can the operator expose such information and monetize that is an
> interesting question, Last time I asked such question,  the response was to
> the affect, “over my dead body” :)
>
>
I would certainly say there are challenges, not limited to:

Is this info free or paid for (NN issue)?

If i sell it to FB, do i need to sell it to GOOG too (anti-trust issue?)

Can my competitor or customers get this information and use it against me?
 (here is map of where your network is poor during rush hour)

Can my suppliers get this information and use it against me ? (we see you
need an upgrade, we just raised our rates!)

It is a slippery slope for sure.

CB

>
>
> From: Marnew <[email-masked]> on behalf of Vijay Devarapalli <
> [email-masked]>
> To: Blake Matheny <[email-masked]>, Ca By <[email-masked]>
> Cc: "Scharf, Michael (Michael)" <[email-masked]>,
> "Smith, Kevin, (R&D) Vodafone Group" <[email-masked]>, "
> [email-masked]" <[email-masked]>
>
> the tower. Beyond collecting this data to better understand global trends,
> we use similar (less accurate) signals for making dynamic decisions (for
> instance, disable a particular feature because conditions look like X).
>
> <[email-masked]>[email-masked]"
> On Thursday, September 24, 2015, Blake Matheny < <[email-masked]>
> [email-masked]> wrote:
>
> Marnew mailing [email-masked]://www.iab.org/mailman/listinfo/marnew
>
>
>

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Thu, 24 Sep 2015 16:45:50 +0000

Agree. Competitive / regulatory / opportunity, can be the drivers for sides of the argument.

From: Ca By <[email-masked]<mailto:[email-masked]>>
Date: Thursday, September 24, 2015 at 9:41 AM
To: Sri Gundavelli <[email-masked]<mailto:[email-masked]>>
Cc: Vijay Devarapalli <[email-masked]<mailto:[email-masked]>>, Blake Matheny <[email-masked]<mailto:[email-masked]>>, "Scharf, Michael (Michael)" <[email-masked]<mailto:[email-masked]>>, "Smith, Kevin, (R&D) Vodafone Group" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Marnew] RFC 6077

Can my competitor or customers get this information and use it against me?  (here is map of where your network is poor during rush hour)

Can my suppliers get this information and use it against me ? (we see you need an upgrade, we just raised our rates!)

CB

Vijay

-Blake

From: Ca By

On 9/24/15, 7:34 AM, "Marnew on behalf of Smith, Kevin, (R&D) Vodafone Group" <[email-masked] on behalf of [email-masked]> wrote:

>"Scharf, Michael (Michael)" <[email-masked]<mailto:[email-masked]>> wrote:
>
>

---

From: Blake Matheny <[email-masked]>
Date: Thu, 24 Sep 2015 16:54:30 +0000

I strongly agree here, assuming we’re still talking about what hints can we expect from operators.

The thing is, any sophisticated terminal application already has most of this information. It’s inferred, and not explicit.

Something (I think) less sensitive, but still helps. Knowing your RRC state. If I know I’m in IDLE, DCH, FACH, etc I can make better decisions. This isn’t widely exposed. If you’re on a network where the IDLE->FACH transition takes 2000ms, incorporating that into your view of congestion is inappropriate.

I guess my point in all of this is that we have a ton of information available to us, but it’s quite incomplete.

Many basic approaches in CC related to RTT or loss are skewed by radio network characteristics and start to break down. Unless we can get better signals from the network.

-Blake

From: "Sri Gundavelli (sgundave)"
Date: Thursday, September 24, 2015 at 12:45 PM
To: Ca By
Cc: Vijay Devarapalli, Blake Matheny, "Scharf, Michael (Michael)", "Smith, Kevin, (R&D) Vodafone Group", "[email-masked]<mailto:[email-masked]>"
Subject: Re: [Marnew] RFC 6077

CB

Vijay

-Blake

From: Ca By

_______________________________________________
Marnew mailing list
[email-masked]<mailto:[email-masked]>https://www.iab.org/mailman/listinfo/marnew<https://urldefense.proofpoint.com/v1/url?u=https://www.iab.org/mailman/listinfo/marnew&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=dPSUqzzpoMUu%2B7UN6oQ1DQ%3D%3D%0A&m=Od4bVA%2BjHektGrGhs8VEj69NWWpJICvynVVWyReV55Y%3D%0A&s=19d8793210b5002ae2bf116dbe4027b0d0cb44532dbf3678b2d376185aa7655f>

---

From: "Thomas Anderson (thomande)" <[email-masked]>
Date: Thu, 24 Sep 2015 18:00:43 +0000

Of course, all transport data in a mobile network is ephemeral ... aggregate channel BW, per user BW, latency, ...  on time scales of 10-100's of ms and variations on the order of 50:1 or more (or less).  It would be good to get some information particularly if you also knew the range of accuracy.  But RAN vendors have been loath to expose this since its hard to predict accuracy and easy to make bad decisions based on ever changing data.   However, on a larger time scale (say many seconds / minutes), you can conclude some level of overall aggregate channel conditions.  Each specific user still may see a wide variation of performance since they may be in very good signal-to-noise areas (getting a higher share of BW) or very bad signal-to-noise areas (getting a very low BW).  But in aggregate, you can conclude that there are problems and some mitigation of traffic for certain classes of users could result in an aggregate improvement in QoE.   An operator will argue that they can conclude this based on data and heuristics they can get.  An ability to expose this  to clients/apps would seem to be highly advantageous (think SPUD maybe). And of course, some new structures/protocols to be able to expose/act on this information would be needed. Fundamentally, it would be nice to divorce traffic management methods, ... from the dependence on traffic type detection mechanisms.

              Tom

From: Marnew [mailto:[email-masked]] On Behalf Of Blake Matheny
Sent: Thursday, September 24, 2015 8:55 AM
To: Andreas Terzis
Cc: Vijay Devarapalli; Ca By; Smith, Kevin, (R&D) Vodafone Group; Scharf, Michael (Michael); [email-masked]
Subject: Re: [Marnew] RFC 6077

-Blake

From: Andreas Terzis

Blake,

Andreas

Vijay

---

From: <[email-masked]>
Date: Thu, 24 Sep 2015 19:44:16 +0000

I wonder if even the best possible signal coming from the RAN can effectively  be used by a TCP sender.

If anyone has public data to share I am interested to read that.

In LTE it's probably latency variability that impacts the most TCP.  Even with zero packet loss rate thanks to link adaptation, poor ACK clocking caused by the latency would augment TCP burstiness.  This can bring buffer losses that could be avoided by simply pacing  TCP on the sender side.
Seems counter-intuitive but link adaptation avoid channel losses,  augment latency variability causes buffer losses.  In the end the packet is lost.

I'm not saying that pacing is easy to implement but simpler than closed loop protocols based on complex feedback.

Also TCP pacing  over LTE would not suffer from the known fairness issues as buffers for different UEs aren't shared in the tower.

I wonder if anyone has tried this approach.

Luca

-------- Message d'origine --------
De : Blake Matheny
Date :2015/09/24 7:13 PM (GMT+01:00)
À : "Sri Gundavelli (sgundave)" , Ca By
Cc : Vijay Devarapalli , "Smith, Kevin, (R&D) Vodafone Group" , "Scharf, Michael (Michael)" , [email-masked]
Objet : Re: [Marnew] RFC 6077

-Blake

CB

Vijay

-Blake

From: Ca By

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Thu, 24 Sep 2015 20:32:47 +0000

I do not believe it is being used at a TCP layer, but RSSI and other signal parameters such as RSSI/RSRP are being used for interface/network selection or in connection manager type applications. From an application point of view, parameters such as Jitter, Latency and Delay parameters (based on some explicit measurements) on an access link are used to some extent., may not be RSSI; if it is then this may be a proprietary art and there may be good amount of heuristics involved in such calculations.

Some popular end-points do make use of signal strength parameters, not at the application level but for network selection; such as performing an handover between two  access points, when the RSSI differential between those adjacent AP’s is below a certain threshold, or a mobile router's selection of an egress link (LTE or Wi-Fi) based on these parameters.

Regards
Sri

From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Thursday, September 24, 2015 at 12:44 PM
To: Blake Matheny <[email-masked]<mailto:[email-masked]>>, Sri Gundavelli <[email-masked]<mailto:[email-masked]>>, Ca By <[email-masked]<mailto:[email-masked]>>
Cc: Vijay Devarapalli <[email-masked]<mailto:[email-masked]>>, "Smith, Kevin, (R&D) Vodafone Group" <[email-masked]<mailto:[email-masked]>>, "Scharf, Michael (Michael)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE : [Marnew] RFC 6077

Luca

-------- Message d'origine --------
De : Blake Matheny
Date :2015/09/24 7:13 PM (GMT+01:00)
À : "Sri Gundavelli (sgundave)" , Ca By
Cc : Vijay Devarapalli , "Smith, Kevin, (R&D) Vodafone Group" , "Scharf, Michael (Michael)" , [email-masked]<mailto:[email-masked]>
Objet : Re: [Marnew] RFC 6077

-Blake

CB

Vijay

-Blake

From: Ca By

---

From: "M. Zubair Shafiq" <[email-masked]>
Date: Thu, 24 Sep 2015 15:40:13 -0500

A recent paper from Andreas (Google) and UCSD folks proposed a channel
quality indicator (CQI) based cross-layer congestion control for cellular
networks.

http://static.googleusercontent.com/media/research.google.com/en//pubs/archive/43311.pdf

-- 
Best Wishes,
M. Zubair Shafiq

-----------------------------------------------
Assistant Professor
Department of Computer Science
The University of Iowa
Iowa City, IA 52242-1419
Office: 201J MacLean Hall
Tel: 319-335-0742
Fax: 319-335-3624
Email: [email-masked]
Web: http://www.cs.uiowa.edu/~mshafiq
-----------------------------------------------

On Thu, Sep 24, 2015 at 3:32 PM, Sri Gundavelli (sgundave) <
[email-masked]> wrote:

> I do not believe it is being used at a TCP layer, but RSSI and other
> signal parameters such as RSSI/RSRP are being used for interface/network
> selection or in connection manager type applications. From an application
> point of view, parameters such as Jitter, Latency and Delay parameters
> (based on some explicit measurements) on an access link are used to some
> extent., may not be RSSI; if it is then this may be a proprietary art and
> there may be good amount of heuristics involved in such calculations.
>
> Some popular end-points do make use of signal strength parameters, not at
> the application level but for network selection; such as performing an
> handover between two  access points, when the RSSI differential between
> those adjacent AP’s is below a certain threshold, or a mobile router's
> selection of an egress link (LTE or Wi-Fi) based on these parameters.
>
>
> Regards
> Sri
>
>
> From: "[email-masked]" <[email-masked]>
> To: Blake Matheny <[email-masked]>, Sri Gundavelli <[email-masked]>,
> Ca By <[email-masked]>
> Cc: Vijay Devarapalli <[email-masked]>, "Smith, Kevin, (R&D)
> Vodafone Group" <[email-masked]>, "Scharf, Michael (Michael)" <
> [email-masked]>, "[email-masked]" <[email-masked]>
> In LTE it's probably latency variability that impacts the most TCP.  Even
> with zero packet loss rate thanks to link adaptation, poor ACK clocking
> caused by the latency would augment TCP burstiness.  This can bring buffer
> losses that could be avoided by simply pacing  TCP on the sender side.
> Seems counter-intuitive but link adaptation avoid channel losses,  augment
> latency variability causes buffer losses.  In the end the packet is lost.
>
> I'm not saying that pacing is easy to implement but simpler than closed
> loop protocols based on complex feedback.
>
> Also TCP pacing  over LTE would not suffer from the known fairness issues
> as buffers for different UEs aren't shared in the tower.
>
>
> The thing is, any sophisticated terminal application already has most of
> this information. It’s inferred, and not explicit.
>
> Something (I think) less sensitive, but still helps. Knowing your RRC
> state. If I know I’m in IDLE, DCH, FACH, etc I can make better decisions.
> This isn’t widely exposed. If you’re on a network where the IDLE->FACH
> transition takes 2000ms, incorporating that into your view of congestion is
> inappropriate.
>
> I guess my point in all of this is that we have a ton of information
> available to us, but it’s quite incomplete.
>
> Many basic approaches in CC related to RTT or loss are skewed by radio
> network characteristics and start to break down. Unless we can get better
> signals from the network.
>
> -Blake
>
> Cc: Vijay Devarapalli, Blake Matheny, "Scharf, Michael (Michael)",
> "Smith, Kevin, (R&D) Vodafone Group", "[email-masked]"
> From: Ca By <[email-masked]>
> To: Sri Gundavelli <[email-masked]>
> Cc: Vijay Devarapalli <[email-masked]>, Blake Matheny <
> [email-masked]>, "Scharf, Michael (Michael)" <
> [email-masked]>, "Smith, Kevin, (R&D) Vodafone Group" <
> [email-masked]>, "[email-masked]" <[email-masked]>
>>> I’ve asked a couple of vendors for congestion hints in a variety of
>>> ways. So far, no luck :) I would really like to see this as well.
>>>
>>>
>>>
>> Marnew mailing [email-masked]://www.iab.org/mailman/listinfo/marnew <https://urldefense.proofpoint.com/v1/url?u=https://www.iab.org/mailman/listinfo/marnew&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=dPSUqzzpoMUu%2B7UN6oQ1DQ%3D%3D%0A&m=Od4bVA%2BjHektGrGhs8VEj69NWWpJICvynVVWyReV55Y%3D%0A&s=19d8793210b5002ae2bf116dbe4027b0d0cb44532dbf3678b2d376185aa7655f>
>>
>>
>>

---

From: <[email-masked]>
Date: Thu, 24 Sep 2015 21:59:12 +0000

what is proposed in this work is actually TCP pacing  with rate inferred from the feedback. Pacing  is implemented using  token bucket rate limitation.

I feel like the pacing component is more important ie performance would be good by just pacing  at the Ack clock rate. This is not explored in this paper but if so the implementation would not require any feedback from the RAN.

Luca

-------- Message d'origine --------
De : "M. Zubair Shafiq"
Date :2015/09/24 10:40 PM (GMT+01:00)
À : "Sri Gundavelli (sgundave)"
Cc : MUSCARIELLO Luca IMT/OLN , Blake Matheny , Ca By , Vijay Devarapalli , "Smith, Kevin, (R&D) Vodafone Group" , "Scharf, Michael (Michael)" , [email-masked]
Objet : Re: [Marnew] RFC 6077

A recent paper from Andreas (Google) and UCSD folks proposed a channel quality indicator (CQI) based cross-layer congestion control for cellular networks.

--
Best Wishes,
M. Zubair Shafiq

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

On Thu, Sep 24, 2015 at 3:32 PM, Sri Gundavelli (sgundave) <[email-masked]<mailto:[email-masked]>> wrote:
I do not believe it is being used at a TCP layer, but RSSI and other signal parameters such as RSSI/RSRP are being used for interface/network selection or in connection manager type applications. From an application point of view, parameters such as Jitter, Latency and Delay parameters (based on some explicit measurements) on an access link are used to some extent., may not be RSSI; if it is then this may be a proprietary art and there may be good amount of heuristics involved in such calculations.

Regards
Sri

Luca

-------- Message d'origine --------
De : Blake Matheny

-Blake

CB

Vijay

-Blake

From: Ca By

---

From: Istvan Lajtos <[email-masked]>
Date: Sun, 27 Sep 2015 14:03:56 +0000

Sorry folks chipping in late...we were probably too busy focusing on the workshop content :)

I would like to add my comment, that we started fleshing out a few ideas in GSMA ECNRY subgroup about the possibility of exchanging radio network information for some metadata, specifically focusing for CDNs and CPs (video contents more precisely)  in a standardised way. (via a bilateral agreement between operators and CDN/CP)

So far had proposed a couple of ideas including information from radio network such as:

*        Congestion notification

*        IP QoS (specific to traffic type)

*        Optimisation services (content adaptation, transcoding video content etc.)

*        Network push (network status info)

*        Traffic optimisation (optimise encrypted traffic)

>From the CDN / CP side it would be some metadata (only) exposed about content type of encrypted traffic.

Istvan
From: Marnew [mailto:[email-masked]] On Behalf Of Sri Gundavelli (sgundave)
Sent: 24 September 2015 17:11
To: Vijay Devarapalli <[email-masked]>; Blake Matheny <[email-masked]>; Ca By <[email-masked]>
Cc: [email-masked]; KSmith <[email-masked]>; Scharf, Michael (Michael) <[email-masked]>
Subject: Re: [Marnew] RFC 6077

> No Operator would share that kind of information from their base station. That is a non-starter. The base stations are busy with what they usually do best - delivering as many bits as possible to t…

I agree with this. This is probably considered as sensitive information. Can the operator expose such information and monetize that is an interesting question, Last time I asked such question,  the response was to the affect, "over my dead body" :)

Vijay
On 9/24/15 9:11 AM, Blake Matheny wrote:
I don't think that has to be the case. I'd like to get channel bandwidth, allocated channels vs available channels, and a couple of other things from the tower. Beyond collecting this data to better understand global trends, we use similar (less accurate) signals for making dynamic decisions (for instance, disable a particular feature because conditions look like X).

Just because the signals are ephemeral/dynamic don't mean they aren't useful. TCP does not provide these hints. Also struct tcp_info is a Linuxism and is not widely available across platforms.

-Blake

From: Ca By

On Thursday, September 24, 2015, Blake Matheny <[email-masked]<mailto:[email-masked]>> wrote:
I've asked a couple of vendors for congestion hints in a variety of ways. So far, no luck :) I would really like to see this as well.

Marnew mailing list

This email and its attachments are intended for the above named only and may be confidential. If they have come to you in error you must take no action based on them, nor must you copy or show them to anyone; please reply to this email or call +44 207 356 0600 and highlight the error.