Re: [Marnew] RFC 6077

["Sri Gundavelli (sgundave)" <[e-mail]>]

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


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



On Thu, Sep 24, 2015 at 9:11 AM, Sri Gundavelli (sgundave) <[e-mail]<mailto:[e-mail]>> 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.

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 <[e-mail]<mailto:[e-mail]>> on behalf of Vijay Devarapalli <[e-mail]<mailto:[e-mail]>>
Date: Thursday, September 24, 2015 at 6:31 AM
To: Blake Matheny <[e-mail]<mailto:[e-mail]>>, Ca By <[e-mail]<mailto:[e-mail]>>
Cc: "Scharf, Michael (Michael)" <[e-mail]<mailto:[e-mail]>>, "Smith, Kevin, (R&D) Vodafone Group" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>

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

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)", "<mailto:[e-mail]>[e-mail]<mailto:[e-mail]>"
Subject: Re: [Marnew] RFC 6077



On Thursday, September 24, 2015, Blake Matheny <<mailto:[e-mail]>[e-mail]<mailto:[e-mail]>> 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" <[e-mail] on behalf of [e-mail]> 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)" <[e-mail]<mailto:[e-mail]>> 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.
>
>Michael (co-author of RFC 6077)
>
>_______________________________________________
>Marnew mailing list
>[e-mail]
>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
>
>_______________________________________________
>Marnew mailing list
>[e-mail]
>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
_______________________________________________
Marnew mailing list
[e-mail]
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>



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