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.

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: zubair-shafiq@uiowa.edu
Web: http://www.cs.uiowa.edu/~mshafiq
-----------------------------------------------

On Thu, Sep 24, 2015 at 3:32 PM, Sri Gundavelli (sgundave) <
sgundave@cisco.com> 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: "luca.muscariello@orange.com" <luca.muscariello@orange.com>
> Date: Thursday, September 24, 2015 at 12:44 PM
> To: Blake Matheny <bmatheny@fb.com>om>, Sri Gundavelli <sgundave@cisco.com>om>,
> Ca By <cb.list6@gmail.com>
> Cc: Vijay Devarapalli <vijay@vasonanetworks.com>om>, "Smith, Kevin, (R&D)
> Vodafone Group" <Kevin.Smith@vodafone.com>om>, "Scharf, Michael (Michael)" <
> michael.scharf@alcatel-lucent.com>gt;, "marnew@iab.org" <marnew@iab.org>
> Subject: RE : [Marnew] RFC 6077
>
> 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)" , marnew@iab.org
> Objet : Re: [Marnew] RFC 6077
>
> 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", "marnew@iab.org"
> Subject: Re: [Marnew] RFC 6077
>
> Agree. Competitive / regulatory / opportunity, can be the drivers for
> sides of the argument.
>
>
> From: Ca By <cb.list6@gmail.com>
> Date: Thursday, September 24, 2015 at 9:41 AM
> To: Sri Gundavelli <sgundave@cisco.com>
> Cc: Vijay Devarapalli <vijay@vasonanetworks.com>om>, Blake Matheny <
> bmatheny@fb.com>gt;, "Scharf, Michael (Michael)" <
> michael.scharf@alcatel-lucent.com>gt;, "Smith, Kevin, (R&D) Vodafone Group" <
> Kevin.Smith@vodafone.com>gt;, "marnew@iab.org" <marnew@iab.org>
> Subject: Re: [Marnew] RFC 6077
>
>
>
> On Thu, Sep 24, 2015 at 9:11 AM, Sri Gundavelli (sgundave) <
> sgundave@cisco.com> 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 <marnew-bounces@iab.org> on behalf of Vijay Devarapalli <
>> vijay@vasonanetworks.com>
>> Date: Thursday, September 24, 2015 at 6:31 AM
>> To: Blake Matheny <bmatheny@fb.com>om>, Ca By <cb.list6@gmail.com>
>> Cc: "Scharf, Michael (Michael)" <michael.scharf@alcatel-lucent.com>om>,
>> "Smith, Kevin, (R&D) Vodafone Group" <Kevin.Smith@vodafone.com>om>, "
>> marnew@iab.org" <marnew@iab.org>
>>
>> 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)", "
>> <marnew@iab.org>marnew@iab.org"
>> Subject: Re: [Marnew] RFC 6077
>>
>>
>>
>> On Thursday, September 24, 2015, Blake Matheny < <bmatheny@fb.com>
>> bmatheny@fb.com> 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" <marnew-bounces@iab.org on behalf of Kevin.Smith@vodafone.com>
>>> 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)" <michael.scharf@alcatel-lucent.com> 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
>>> >Marnew@iab.org
>>> >
>>> 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
>>> >Marnew@iab.org
>>> >
>>> 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
>>> Marnew@iab.org
>>> 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 listMarnew@iab.orghttps://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>
>>
>>
>>
> _________________________________________________________________________________________________________________________
>
> 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.
>
>
> _______________________________________________
> Marnew mailing list
> Marnew@iab.org
> https://www.iab.org/mailman/listinfo/marnew
>
>