New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 758011 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: Aug 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug



Sign in to add a comment

Delay TCP job on start

Project Member Reported by zhongyi@chromium.org, Aug 22 2017

Issue description

Background at  Issue 757548 .

Currently, we start the main job immediately on start if the QUIC job cannot succeed synchronously and QuicStreamFactory requires confirmation. 

When QuicStreamFactory is constructed, it requires confirmation by default, and TCP job will not be delayed as wait time is set to zero. The require confirmation mode can be turned off if
- the ip address has not been changed and quic was supported on this ip,
- a QUIC job has succeeded.

However, we delay checking the ip address and quic support until ConfigureSocket() which is after the host resolution. Potentially, upon the construction of QuicStreamFactory we could configure a socket preemptively, and turn off require confirmation if ip address is not changed while quic is supported. 
 
Components: Internals>Network>QUIC
Description: Show this description
Cc: xunji...@chromium.org
Labels: -Pri-3 Pri-2
Owner: zhongyi@chromium.org
Status: Assigned (was: Untriaged)
Project Member

Comment 4 by bugdroid1@chromium.org, Aug 25 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/a0cef10897bcf279a34f9e09b7cb06c9ad9fa778

commit a0cef10897bcf279a34f9e09b7cb06c9ad9fa778
Author: Zhongyi Shi <zhongyi@chromium.org>
Date: Fri Aug 25 01:49:50 2017

Aggressively delay TCP job on start when QUIC is known to be supported
last time.

QuicStreamFactory requires confirmation on start by default. If we know
QUIC was supported last time on some IP address, we should delay TCP job
so that if QuicStreamFactory figures out the local IP address doesn't
change and QUIC is still supported, spurious TLS handshake for TCP could
be elimiated. If the local IP address is changed and QUIC support is
unknown for the new locak IP address, QUIC and TCP will be raced.

Bug:  758011 
Change-Id: Iaac53a8720b68287406464f58329c05ea1d4a502
Reviewed-on: https://chromium-review.googlesource.com/631736
Reviewed-by: Ryan Hamilton <rch@chromium.org>
Commit-Queue: Zhongyi Shi <zhongyi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#497288}
[modify] https://crrev.com/a0cef10897bcf279a34f9e09b7cb06c9ad9fa778/net/quic/chromium/quic_network_transaction_unittest.cc
[modify] https://crrev.com/a0cef10897bcf279a34f9e09b7cb06c9ad9fa778/net/quic/chromium/quic_stream_factory.cc
[modify] https://crrev.com/a0cef10897bcf279a34f9e09b7cb06c9ad9fa778/net/quic/chromium/quic_stream_factory.h

Status: Fixed (was: Assigned)

Sign in to add a comment