Subject: Re: [Marnew] RFC 6077

From: Natasha Rooney <[email-masked]>
Date: Mon, 19 Oct 2015 09:50:39 +0000

Hi all! This conversation has been written up here for the benefit of making sure everyone has access to the details and to help with the planning of solutions going forward. PRs will be welcome:

https://github.com/MaRNEW/Output_Documents/blob/master/6077_mail_discussion.md

Natasha

Natasha Rooney | Technologist, Web and Internet, W3C & IETF | GSMA | [email-masked]<mailto:[email-masked]> | +44 (0) 7730 219 765 | @thisNatasha | Skype: [email-masked]<mailto:[email-masked]>
Tokyo, Japan

On Sep 27, 2015, at 11:03 PM, Istvan Lajtos <[email-masked]<mailto:[email-masked]>> wrote:

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]<mailto:[email-masked]>>; Blake Matheny <[email-masked]<mailto:[email-masked]>>; Ca By <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; KSmith <[email-masked]<mailto:[email-masked]>>; Scharf, Michael (Michael) <[email-masked]<mailto:[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 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” :)

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

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)", "[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]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> 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]<mailto:[email-masked]>> 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
>[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=sfDv5HORjurZqK2gt%2FlxX1SHIUOTFXmXhNMlEycm9DI%3D%0A&s=287c4a2ca16575e5bb0b89f8a38b2058107aa632016e43ad3d5820b036687265
>
>_______________________________________________
>Marnew mailing list
>[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=sfDv5HORjurZqK2gt%2FlxX1SHIUOTFXmXhNMlEycm9DI%3D%0A&s=287c4a2ca16575e5bb0b89f8a38b2058107aa632016e43ad3d5820b036687265
_______________________________________________
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=Jss0283WJ77x215YTlEiFoCnppBsdgDltN16tKkCNn0%3D%0A&s=89899417f5b429204a349b6420a315e537ba5bac6608bfaf44f3af11cc8a1b17>

_______________________________________________

Marnew mailing list

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

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.

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

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.