Re: [Marnew] RFC 6077

[<[e-mail]>]

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)" , [e-mail]
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.

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: [phone]
Fax: [phone]
Email: [e-mail]<mailto:[e-mail]>
Web: http://www.cs.uiowa.edu/~mshafiq
-----------------------------------------------

On Thu, Sep 24, 2015 at 3:32 PM, Sri Gundavelli (sgundave) <[e-mail]<mailto:[e-mail]>> 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: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Date: Thursday, September 24, 2015 at 12:44 PM
To: Blake Matheny <[e-mail]<mailto:[e-mail]>>, Sri Gundavelli <[e-mail]<mailto:[e-mail]>>, Ca By <[e-mail]<mailto:[e-mail]>>
Cc: Vijay Devarapalli <[e-mail]<mailto:[e-mail]>>, "Smith, Kevin, (R&D) Vodafone Group" <[e-mail]<mailto:[e-mail]>>, "Scharf, Michael (Michael)" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
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)" , [e-mail]<mailto:[e-mail]>
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", "[e-mail]<mailto:[e-mail]>"
Subject: Re: [Marnew] RFC 6077

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<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
[e-mail]<mailto:[e-mail]>
https://www.iab.org/mailman/listinfo/marnew



_________________________________________________________________________________________________________________________

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.