Change initial DTLS retransmission timer from 1 second to 50ms.

Change initial DTLS retransmission timer from 1 second to 50ms.

This will help ensure a timely DTLS handshake when there's packet
loss. It will likely result in spurious retransmissions (since the
RTT is usually > 50ms), but since exponential backoff is still used,
there will at most be ~4 extra retransmissions. For a time-sensitive
application like WebRTC this seems like a reasonable tradeoff.

R=pthatcher@webrtc.org, juberti@chromium.org, juberti@webrtc.org

Committed: https://crrev.com/1e435628366fb9fed71632369f05928ed857d8ef
Cr-Commit-Position: refs/heads/master@{#12853}
Committed: https://chromium.googlesource.com/external/webrtc/+/4f0dfbd213aaad0b8b32b0cf0101b47aea039770

[Taylor Brandstetter, 2016-05-13 17:46:41]

deadbeef@webrtc.org changed reviewers:
+ pthatcher@webrtc.org

[Taylor Brandstetter, 2016-05-13 17:46:42]

Note that a BoringSSL/Chromium roll will be needed before I can land this.

[Taylor Brandstetter, 2016-05-13 17:47:19]

Also: do you still prefer a flat 50ms timer over one based on RTT?

[pthatcher1, 2016-05-13 19:02:29]

lgtm

Yes, I still think 50ms sounds good.  It's easier, usually faster, and has
practically no downside that I can think of.  Plus, Firefox has tried the idea
already, and I assume nothing caught on fire.

But I'd like to hear what Justin thinks about it.

[Taylor Brandstetter, 2016-05-13 19:26:25]

On 2016/05/13 19:02:29, pthatcher1 wrote:
> lgtm
> 
> Yes, I still think 50ms sounds good.  It's easier, usually faster, and has
> practically no downside that I can think of.  Plus, Firefox has tried the idea
> already, and I assume nothing caught on fire.
> 
> But I'd like to hear what Justin thinks about it.

After our standup I discovered that it's only in Firefox nightly so far. So
there's still a chance for something to catch on fire.

[Taylor Brandstetter, 2016-05-13 19:26:38]

deadbeef@webrtc.org changed reviewers:
+ juberti@webrtc.org

[juberti2, 2016-05-13 19:27:50]

On 2016/05/13 19:26:38, Taylor Brandstetter wrote:

Backoff results in rtx at 50, 150, 350, 750?

[juberti2, 2016-05-13 19:28:32]

juberti@chromium.org changed reviewers:
+ juberti@chromium.org

[juberti2, 2016-05-13 19:28:33]

lgtm assuming my understanding is correct

[juberti1, 2016-05-13 19:29:08]

webrtc lgtm

[Taylor Brandstetter, 2016-05-13 19:29:25]

On 2016/05/13 19:27:50, juberti2 wrote:
> On 2016/05/13 19:26:38, Taylor Brandstetter wrote:
> 
> Backoff results in rtx at 50, 150, 350, 750?

Yep. Hence my rough calculation of "at most ~4 extra retransmissions".

[Taylor Brandstetter, 2016-05-23 17:28:54]

The CQ bit was checked by deadbeef@webrtc.org

[Taylor Brandstetter, 2016-05-23 17:28:55]

The patchset sent to the CQ was uploaded after l-g-t-m from juberti@webrtc.org,
juberti@chromium.org, pthatcher@webrtc.org
Link to the patchset: https://codereview.webrtc.org/1981463002/#ps20001 (title:
"Put the new method in "if boringssl", not the other way around...")

[commit-bot: I haz the power, 2016-05-23 17:29:07]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1981463002/20001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1981463002/20001

[commit-bot: I haz the power, 2016-05-23 19:29:52]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-05-23 19:29:53]

Try jobs failed on following builders:
  android_arm64_rel on tryserver.webrtc (JOB_TIMED_OUT, no build URL)
  android_dbg on tryserver.webrtc (JOB_TIMED_OUT, no build URL)

[Taylor Brandstetter, 2016-05-23 19:49:04]

Description was changed from

==========
Change initial DTLS retransmission timer from 1 second to 50ms.

This will help ensure a timely DTLS handshake when there's packet
loss. It will likely result in spurious retransmissions (since the
RTT is usually > 50ms), but since exponential backoff is still used,
there will at most be ~4 extra retransmissions. For a time-sensitive
application like WebRTC this seems like a reasonable tradeoff.
==========

to

==========
Change initial DTLS retransmission timer from 1 second to 50ms.

This will help ensure a timely DTLS handshake when there's packet
loss. It will likely result in spurious retransmissions (since the
RTT is usually > 50ms), but since exponential backoff is still used,
there will at most be ~4 extra retransmissions. For a time-sensitive
application like WebRTC this seems like a reasonable tradeoff.

R=juberti@chromium.org, juberti@webrtc.org, pthatcher@webrtc.org

Committed:
https://chromium.googlesource.com/external/webrtc/+/1e435628366fb9fed71632369...
==========

[Taylor Brandstetter, 2016-05-23 19:49:06]

Committed patchset #2 (id:20001) manually as
1e435628366fb9fed71632369f05928ed857d8ef (presubmit successful).

[commit-bot: I haz the power, 2016-05-23 19:49:07]

Description was changed from

==========
Change initial DTLS retransmission timer from 1 second to 50ms.

This will help ensure a timely DTLS handshake when there's packet
loss. It will likely result in spurious retransmissions (since the
RTT is usually > 50ms), but since exponential backoff is still used,
there will at most be ~4 extra retransmissions. For a time-sensitive
application like WebRTC this seems like a reasonable tradeoff.

R=juberti@chromium.org, juberti@webrtc.org, pthatcher@webrtc.org

Committed:
https://chromium.googlesource.com/external/webrtc/+/1e435628366fb9fed71632369...
==========

to

==========
Change initial DTLS retransmission timer from 1 second to 50ms.

This will help ensure a timely DTLS handshake when there's packet
loss. It will likely result in spurious retransmissions (since the
RTT is usually > 50ms), but since exponential backoff is still used,
there will at most be ~4 extra retransmissions. For a time-sensitive
application like WebRTC this seems like a reasonable tradeoff.

R=juberti@chromium.org, juberti@webrtc.org, pthatcher@webrtc.org

Committed: https://crrev.com/1e435628366fb9fed71632369f05928ed857d8ef
Cr-Commit-Position: refs/heads/master@{#12853}
==========

[philipel, 2016-05-24 08:49:30]

A revert of this CL (patchset #2 id:20001) has been created in
https://codereview.webrtc.org/2002403002/ by philipel@webrtc.org.

The reason for reverting is: Seems like this CL cause
DtlsTransportChannelTest.TestReceiveClientHelloBeforeRemoteFingerprint
DtlsTransportChannelTest.TestReceiveClientHelloBeforeWritable
to consistently fail on Win DrMemory Full and for
DtlsTransportChannelTest.TestReceiveClientHelloBeforeRemoteFingerprint
DtlsTransportChannelTest.TestReceiveClientHelloBeforeWritable
to consistently fail on Linux Memcheck.

[Taylor Brandstetter, 2016-06-15 00:00:22]

Description was changed from

==========
Change initial DTLS retransmission timer from 1 second to 50ms.

This will help ensure a timely DTLS handshake when there's packet
loss. It will likely result in spurious retransmissions (since the
RTT is usually > 50ms), but since exponential backoff is still used,
there will at most be ~4 extra retransmissions. For a time-sensitive
application like WebRTC this seems like a reasonable tradeoff.

R=juberti@chromium.org, juberti@webrtc.org, pthatcher@webrtc.org

Committed: https://crrev.com/1e435628366fb9fed71632369f05928ed857d8ef
Cr-Commit-Position: refs/heads/master@{#12853}
==========

to

==========
Change initial DTLS retransmission timer from 1 second to 50ms.

This will help ensure a timely DTLS handshake when there's packet
loss. It will likely result in spurious retransmissions (since the
RTT is usually > 50ms), but since exponential backoff is still used,
there will at most be ~4 extra retransmissions. For a time-sensitive
application like WebRTC this seems like a reasonable tradeoff.

R=juberti@chromium.org, juberti@webrtc.org, pthatcher@webrtc.org

Committed: https://crrev.com/1e435628366fb9fed71632369f05928ed857d8ef
Cr-Commit-Position: refs/heads/master@{#12853}
==========

[Taylor Brandstetter, 2016-06-15 00:04:11]

deadbeef@webrtc.org changed reviewers:
- juberti@chromium.org, juberti@webrtc.org

[Taylor Brandstetter, 2016-06-15 00:04:12]

Please review again. I was able to fix the flaky tests in one line of code by
using the fake clock, but I also made some other various changes and added a new
test.

https://codereview.webrtc.org/1981463002/diff/60001/webrtc/base/opensslstream...
File webrtc/base/opensslstreamadapter.cc (right):

https://codereview.webrtc.org/1981463002/diff/60001/webrtc/base/opensslstream...
webrtc/base/opensslstreamadapter.cc:1004: // SSL_CTX_set_current_time_cb(ctx,
&TimeCallback);
I can't use this method until a Chromium roll is relanded. Remind me to wait for
that before landing this CL.

[pthatcher1, 2016-06-15 21:20:20]

lgtm

https://codereview.webrtc.org/1981463002/diff/60001/webrtc/base/logging.cc
File webrtc/base/logging.cc (right):

https://codereview.webrtc.org/1981463002/diff/60001/webrtc/base/logging.cc#ne...
webrtc/base/logging.cc:128: // in log messages represents the real system time.
SystemTimeNanos or SystemTimeMillis?

[Taylor Brandstetter, 2016-06-16 00:15:05]

https://codereview.webrtc.org/1981463002/diff/60001/webrtc/base/logging.cc
File webrtc/base/logging.cc (right):

https://codereview.webrtc.org/1981463002/diff/60001/webrtc/base/logging.cc#ne...
webrtc/base/logging.cc:128: // in log messages represents the real system time.
On 2016/06/15 21:20:20, pthatcher1 wrote:
> SystemTimeNanos or SystemTimeMillis?

Fixed.

[commit-bot: I haz the power, 2016-06-16 00:15:40]

Description was changed from

==========
Change initial DTLS retransmission timer from 1 second to 50ms.

This will help ensure a timely DTLS handshake when there's packet
loss. It will likely result in spurious retransmissions (since the
RTT is usually > 50ms), but since exponential backoff is still used,
there will at most be ~4 extra retransmissions. For a time-sensitive
application like WebRTC this seems like a reasonable tradeoff.

R=juberti@chromium.org, juberti@webrtc.org, pthatcher@webrtc.org

Committed: https://crrev.com/1e435628366fb9fed71632369f05928ed857d8ef
Cr-Commit-Position: refs/heads/master@{#12853}
==========

to

==========
Change initial DTLS retransmission timer from 1 second to 50ms.

This will help ensure a timely DTLS handshake when there's packet
loss. It will likely result in spurious retransmissions (since the
RTT is usually > 50ms), but since exponential backoff is still used,
there will at most be ~4 extra retransmissions. For a time-sensitive
application like WebRTC this seems like a reasonable tradeoff.

R=pthatcher@webrtc.org, juberti@chromium.org, juberti@webrtc.org

Committed: https://crrev.com/4f0dfbd213aaad0b8b32b0cf0101b47aea039770
Committed: https://crrev.com/1e435628366fb9fed71632369f05928ed857d8ef
Cr-Original-Commit-Position: refs/heads/master@{#12853}
Cr-Commit-Position: refs/heads/master@{#13159}
==========

[Taylor Brandstetter, 2016-06-16 00:15:40]

Description was changed from

==========
Change initial DTLS retransmission timer from 1 second to 50ms.

This will help ensure a timely DTLS handshake when there's packet
loss. It will likely result in spurious retransmissions (since the
RTT is usually > 50ms), but since exponential backoff is still used,
there will at most be ~4 extra retransmissions. For a time-sensitive
application like WebRTC this seems like a reasonable tradeoff.

R=pthatcher@webrtc.org, juberti@chromium.org, juberti@webrtc.org

Committed: https://crrev.com/4f0dfbd213aaad0b8b32b0cf0101b47aea039770
Committed: https://crrev.com/1e435628366fb9fed71632369f05928ed857d8ef
Cr-Original-Commit-Position: refs/heads/master@{#12853}
Cr-Commit-Position: refs/heads/master@{#13159}
==========

to

==========
Change initial DTLS retransmission timer from 1 second to 50ms.

This will help ensure a timely DTLS handshake when there's packet
loss. It will likely result in spurious retransmissions (since the
RTT is usually > 50ms), but since exponential backoff is still used,
there will at most be ~4 extra retransmissions. For a time-sensitive
application like WebRTC this seems like a reasonable tradeoff.

R=pthatcher@webrtc.org, juberti@chromium.org, juberti@webrtc.org

Committed: https://crrev.com/1e435628366fb9fed71632369f05928ed857d8ef
Cr-Commit-Position: refs/heads/master@{#12853}
Committed:
https://chromium.googlesource.com/external/webrtc/+/4f0dfbd213aaad0b8b32b0cf0...
==========

[commit-bot: I haz the power, 2016-06-16 00:15:41]

Patchset 5 (id:??) landed as
https://crrev.com/4f0dfbd213aaad0b8b32b0cf0101b47aea039770
Cr-Commit-Position: refs/heads/master@{#13159}

[Taylor Brandstetter, 2016-06-16 00:15:42]

Committed patchset #5 (id:80001) manually as
4f0dfbd213aaad0b8b32b0cf0101b47aea039770 (presubmit successful).

[Taylor Brandstetter, 2016-06-16 00:16:52]

Oops. I forgot to switch to the API for setting the time callback. I'll get it
on a new CL.