Network Team Status and Plans

[Siddharth Vijayakrishnan]

Within Google, we’ve been publishing semi-regular updates of what transpires in the world of networking and protocol security. We thought it’d be a good idea to publish them externally as well.

QUIC

Current Status:

QUIC is now running at 0.2% on the stable channel on desktop and 2% on Android. On beta, QUIC is rolled out to 25% on desktop and 50% on mobile. We are looking at data on latency and stability on various Google properties across all platforms.

What’s Next:

There is a big focus on metrics and analysis to make sure that latency reduction meets the expectation of various latency sensitive products at Google. With M37, we are planning on increasing the rollout to 5% on stable on all platforms, excluding video traffic.

HTTP/2.0 a.k.a SPDY

Current Status:

Spec updates have slowed down as it prepares to enter last call. The last IETF saw concerns raised from carriers and other interested parties on the increase of encrypted traffic overall on the web. They worry that HTTP/2 will accelerate this trend. In Chrome, we are aiming to get HTTP2 draft 14 support in M39, and recent Chrome canary builds support this when the “Enable SPDY/4” flag is turned on via about:flags.

Cronet : Chrome networking stack as a library

Current Status:

We’ve made good progress on getting Cronet into a shape where it can be used by other apps on Android. G+/Photos on Android uses Cronet exclusively.  Various other apps have also started experimenting with using Cronet.   On the infrastructure side, we have bots that build Cronet for multiple machine architectures. We’ve also done some work to bring down the binary size, though it is still larger than desired.

What’s Next:

Right now our focus is mainly on implementing new asynchronous APIs

Make Chrome robust in the presence of spotty networks :  

Ubiquitous connectivity exists very rarely and if at all, especially on mobile. Our goal here is to minimize the number of network errors the user sees or recover quickly from those errors.

Current Status:

Starting M37 on desktop and android, if the active tab errs out due to no connectivity, Chrome will reload it when it detects that connectivity has come back.  iOS is WIP.

 

In M37, the Netinfo API is shipping by default.  This will allow developers to make use of connection information while requesting resources.  

Our domain reliability monitoring system is shipping for Google properties in M38. This will allow the traffic-team to become aware of outages and DNS errors much faster than before.

What’s Next:

In M39, we plan to add multi-network support to Chrome using the new multi-network APIs in Android.. Over time, we hope to expose some of these capabilities through enhanced APIs. We are also starting to think of enhancements to the Netinfo API to expose more granular information (2/3/4G for example).

Networking Security

Current Status:

WebCrypto is shipping by default in M37 with a number of cryptographic algorithms implemented. For security reasons, these APIs are only available when the resources are delivered securely, such as via TLS or as Chrome Extensions and Apps..

In late June, we announced BoringSSL - our version of OpenSSL. Chrome for Android has moved from OpenSSL to BoringSSL in M38.

We also announced policies for Certificate Transparency in June. We plan to require EV certificates be logged starting in 2015, and publishing our requirements for Log Operators has allowed Certificate Transparency logs time to request inclusion within Chrome before then.

What’s Next

Our initial plan to shift to OpenSSL everywhere has now become BoringSSL everywhere. The next target is OSX for M39. Other preliminary work is being done on Windows, Linux and ChromeOS.

We’re also working on deprecating SHA-1 in certificates, while helping more sites use SSL exclusively and automatically.

Faster Web

With SDCH being enabled via an experiment on M37, Search is setting up a field trial to measure the latency impact. We are also working on some improvements to SDCH which will hopefully improve performance on Android.

Link based prefetch has been dormant on both desktop and on mobile. We are now enabling it on both platforms, primarily for search to take advantage of as they experiment with speculative prefetching to speed up the first click from the search results page.

Websockets

Current Status:

The new implementation will ship by default in M38, fixing several long-standing bugs and paving the way for security and scalability enhancements.

What’s Next

Websockets over HTTP/2 is in the process of being standardized, allowing WebSockets to share a TCP/IP socket with other WebSockets along with HTTP(S) traffic.

Streams API (in Blink)

Current Status:

The Streams API is being standardized at https://github.com/whatwg/streams.  It has gotten more stable recently.  ReadableStream has been implemented experimentally in Blink and integrated with XMLHttpRequest behind a flag.

What’s Next

We’re moving onto integrating the Streams API with the Fetch API rather than XHR. The goal is to try to resolve outstanding issues and ship ReadableStream and the Fetch API with the asStream() method on  FetchBodyStream.

[J Yu]

Hi Siddharth,

I have built the cornet library (out/Release_arm32/libcronet.61.0.3120.0.so) for the arm 32 platform to be used on Android phone with my Java application. Currently it is around 5 MB. I only need basic http send/receive functionality. Do you know anyway I can strip it down further ? Maybe by playing on the compilation flags or removing modules/features not needed ? But how ?

I have seen some discussion here regarding stripping out some feature : 

# cronet_static_small target has reduced binary size through using

          # ICU alternatives which requires file and ftp support be disabled.

          'target_name': 'cronet_static_small', 

I Cannot find the above lines in any files in the latest chromium codes I download in July 2017. Or from this code browsing

Any suggestion will be helpful.

Thanks

James

[Misha Efimov]

Hi J,

current size of armv7a release version of libcronet.61.0.3163.13.so is 2.8M, so there are definitely some optimizations missing.

Are you building it according to these instructions: https://chromium.googlesource.com/chromium/src/+/364f6cc647b48b74473b8be0b1ae1551660ec809/components/cronet/android/build_instructions.md#Building-Cronet-for-releases ?

It should essentially boil down to these 2 commands:

$ ./components/cronet/tools/cr_cronet.py -r gn 
$ ninja -C out/Release cronet_package

Please let us know if it doesn't work for you.

On Tue, Aug 1, 2017 at 11:48 PM, J Yu <ypyu...@gmail.com> wrote:

Hi Siddharth,

I have built the cornet library (out/Release_arm32/libcronet.61.0.3120.0.so) for the arm 32 platform to be used on Android phone with my Java application. Currently it is around 5 MB. I only need basic http send/receive functionality. Do you know anyway I can strip it down further ? Maybe by playing on the compilation flags or removing modules/features not needed ? But how ?

 

I have seen some discussion here regarding stripping out some feature : 

# cronet_static_small target has reduced binary size through using

          # ICU alternatives which requires file and ftp support be disabled.

          'target_name': 'cronet_static_small', 

I Cannot find the above lines in any files in the latest chromium codes I download in July 2017. Or from this code browsing

 

There were few changes in build files, so cronet_static_small target is no longer present, but its functionality is preserved.

--
You received this message because you are subscribed to the Google Groups "net-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+unsubscribe@chromium.org.
To post to this group, send email to net...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/3ae6c7ba-dc6c-43b9-bb5c-84a63862c08d%40chromium.org.

[J Yu]

Hi Siddharth,

Thanks for your quick response. It's a mistake from my end not commenting out target_cpu="x64" from gn_args in cr_cronet.py before I built arm32 which is the default and does not need to set the target_cpu. I am able to built it at around the size you mentioned. Is there any other way to shrink it further such as the one 'target_name': 'cronet_static_small'

mentioned at https://groups.google.com/a/chromium.org/forum/#!search/cronet$20library$20size/chromium-checkins/joQYTA-d8AA/Li10QMqZ2RIJ to remove features not needed down to minimum to reduce the cornet library further ?

Thanks

James

To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+u...@chromium.org.