Re: Questions and comments on CH

Hi Göran.

On Fri, Mar 25, 2016 at 3:24 PM, Göran Eriksson AP <
goran.ap.eriksson@ericsson.com> wrote:

> Hi!
>
> A few minor questions and comments that came to my mind when reading
> draft-grigorik-http-client-hints:
>

FWIW, we've moved the location of the draft, so for future reference:
http://httpwg.org/http-extensions/client-hints.html


> 1. Downlink hint relation to Netinfo
>
> I assume the Downlink information will change similarly to how the NetInfo
> API fires event on “network” change?
>

Yes. I guess we can clarify that in the spec.


> Also, how will the UA handle handovers by the RAN (Radio Access network)
> between micro and macro when in some situations, a macro cell can be of
> one technology (say 4G) and the micro cell another (let’s assume 5G with
> >>1Gbps) and may “handover” between these cells on a quite short time
> >>frame?
>
> Assuming this is exposed in the modem API of a mobile handset and
> available to the browser UA for implementing CH Downlink, would every such
> “handover” be reflected in the Downlink hint?
>

Depends on how the OS surfaces this. As an example, Chrome for Android
relies on ConnectivityManger.CONNECTIVITY_ACTION [1]. When we receive the
intent, we query TelephonyManager.getNetworkType() [2] and, if a change has
occurred, fire the appropriate NetInfo event in the browser. For more, see
[3]. So, in this case, the question really boils down to: how does Android
react to such "micro <> macro" handovers? ... Honestly, not sure! :)

[1]
http://developer.android.com/reference/android/net/ConnectivityManager.html#CONNECTIVITY_ACTION
[2]
http://developer.android.com/reference/android/telephony/TelephonyManager.html#getNetworkType()
[3]
https://code.google.com/p/chromium/codesearch#chromium/src/net/android/java/src/org/chromium/net/NetworkChangeNotifierAutoDetect.java

The CH draft refers to the “Network Info API” which states:
>
> "Where possible, this value may be refined to report a more accurate
> upper bound based on current properties of the interface - e.g. signal
> strength, modulation algorithm, and other "network weather" variables.”
>
> This can mean several things including the client/UA measuring,
> calculating, prediction, getting network feedback and updating this
> “network info” very often since the “RAN weather” can change often indeed?
>

Indeed! FWIW, existing implementation in Chrome doesn't do this. We do have
an open issue for this: https://github.com/w3c/netinfo/issues/30 - if you
have any thoughts or recommendations, please chime in!


> Is this applicable to the CH Downlink? Or will CH Downlink “only” reflect
> the theoretical downlink capacity of the network (technology) it is
> connected to?
>

The intent is to mirror the same value as reported by downlinkMax at the
time the request is created.


> 2. Security considerations
>
> If HTTP/2 clear text is used (horrible thought) I guess an intermediate
> could mess with the headers, e.g. triggering a degradation of user
> experience.
>

Indeed, but they can already do whatever they want with regards to
rewriting both the request and the response, so.. nothing new.

ig