W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2016

Re: Questions and comments on CH

From: Ilya Grigorik <ilya@igvita.com>
Date: Tue, 29 Mar 2016 16:45:30 -0700
Message-ID: <CAKRe7JH_Qv0Fu31w-8iFC9cKsGP=+JwheGFf=jy8NJDwr0zHug@mail.gmail.com>
To: Göran Eriksson AP <goran.ap.eriksson@ericsson.com>
Cc: HTTPWG <ietf-http-wg@w3.org>
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:

> 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! :)


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.

Received on Tuesday, 29 March 2016 23:46:40 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 29 March 2016 23:46:44 UTC