Subject: Questions and comments on CH

From: Göran Eriksson AP <[email-masked]>
Date: Fri, 25 Mar 2016 22:24:57 +0000

Hi!

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

1. Downlink hint relation to Netinfo

I assume the Downlink information will change similarly to how the NetInfo
API fires event on “network” change?

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?

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?

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?

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.

Many regards
Göran

---

From: Ilya Grigorik <[email-masked]>
Date: Tue, 29 Mar 2016 16:45:30 -0700

Hi Göran.

> 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

> API fires event on “network” change?

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

> “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

> “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!

> the theoretical downlink capacity of the network (technology) it is

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

> could mess with the headers, e.g. triggering a degradation of user

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

ig

---

From: Göran Eriksson AP <[email-masked]>
Date: Wed, 30 Mar 2016 15:00:37 +0000

Hi Ilya,

Tnx for response. See below for some answers

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

Murky area this, agree. If we wanted to get this straight in the future,
we would need to engage with device OS vendors, modem vendors and
eventually…(drum roll)…3GPP. But that’s another discussion for another
(TPAC) day perhaps!

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

Thanks for the pointer- will for sure!

The Downlink hint need should perhaps be clear on if it relates to
theoretical DL rate or “actual/measured/recommended”, some way of
signalling this to the server seem beneficial since the actions of it may
vary?

>time the request is created.

Thanks. This of course can be used such that the client updates the server
as the situation changes but that could be up the application to decide
whether to do or not.

---

From: Ilya Grigorik <[email-masked]>
Date: Wed, 30 Mar 2016 14:18:38 -0700

> signalling this to the server seem beneficial since the actions of it may

Well, the way we defined it [1] is:
- in absence of any other signals, we would use the theoretical max DL rate
- if we can refine the upper bound (e.g. WiFi drivers do communicate max
rate based on RSSI), then we would communicate that value

As such, the intent is to communicate the upper bound (with respect to
first network hop) to the best of our abilities.

[1] http://w3c.github.io/netinfo/#underlying-connection-technology

---

From: Göran Eriksson AP <[email-masked]>
Date: Wed, 30 Mar 2016 21:37:17 +0000

>first network hop) to the best of our abilities.

Right. The probability of the theoretical downlink rate to be anywhere
near the actual one is often pretty low. Now even if making educated
guesses is tricky in wireless (unless one uses QoS stuff), then it’s at
least more closer to the actual rate than the theoretical (marketing)
download rate.

This means the server may want to act differently depending on whether
it’s the theoretical downlink rate or an educated
guess/estimate/prediction of the client since these vary in terms of
likelihood of being an actual representation of what the DL bitrate will
be. Now server could deduce that by also keeping a list of the theoretical
rates given in [1] and assuming when DL rate == any_of_theoretical then
client has not other info.

Making the difference clear in the DL Hint could be useful.

But this is not necessarily a major thing. More food for thought at this
stage.

>
>
>[1] 
>http://w3c.github.io/netinfo/#underlying-connection-technology
><http://w3c.github.io/netinfo/#underlying-connection-technology>
>
>
>
>
>
>

---

From: Ilya Grigorik <[email-masked]>
Date: Thu, 31 Mar 2016 12:58:20 -0700

> Making the difference clear in the DL Hint could be useful.

Yep, we discussed exactly this in: https://github.com/w3c/netinfo/issues/27.
The conclusion there was that if the browser implements own ~quality
estimator metric, then it should probably be surfaced as a different
attribute.

ig