New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 6 users
Status: Assigned
Last visit > 30 days ago
NextAction: ----
OS: ----
Pri: 3
Type: Bug

Sign in to add a comment
Sending STUN pings every 50ms is too conservative
Project Member Reported by, Dec 4 2014 Back to list
We pace the STUN pings 50ms apart and send to one connection at a time, which means if the first ping is lost (e.g. due to NAT), the connection will not be pinged again until 50ms * N later, where N is the total number of connections. This makes ICE connection setup much slower when TURN servers are used.

From Justin:
I think the 50 ms interval is overly conservative. I think we should be able to reduce this to 20 ms or less. However, we need to measure what the proper lower bound is here (i.e. what typical NATs can support), I've talked to Guo-wei and Donald about this.
Experiment suggestion:

Pings on different source ports should do the trick. It hopefully should be as simple as
1) open socket on IP:port1
2) send ping1 to google
3) compute t=rand(0, 50)
4) wait(t)
5) open socket on IP:port2
5.1) compute ta=elapsed time since 2)
6) send ping2 to google
7) result = receive pong2 from google, or timeout
8) record { ta, result } in uma

If the theory is correct, we should see strong correlation between increasing t and success rate.
Project Member Comment 2 by, Dec 8 2014
Labels: EngTriaged Mstone-42
We'll start working on this Q1 2015.
Project Member Comment 3 by, Dec 8 2014
Based on the discussion at the meeting today, we should probably have one socket sending to many different remote addresses (i.e more than 2).

Comment 4 by, Dec 17 2014
Labels: Area-PeerConnection
Project Member Comment 5 by, Dec 18 2014
Labels: -Area-PeerConnection Area-Network
Project Member Comment 6 by, Feb 19 2015
Labels: -Mstone-42 Mstone-44
This looks like it's not hitting m42.  Update it if I'm wrong.
Project Member Comment 7 by, Jun 4 2015
Labels: Performance
Project Member Comment 8 by, Jan 29 2016
Labels: -Mstone-44
I don't see any recent CLs linked to this bug, so I don't think it's been fixed. I'm therefore leaving this in an open state, but I am removing the milestone label since this bug hasn't been updated in quite some time.
Project Member Comment 9 by, Jan 30 2016
Right, this remains an open area of research.
Project Member Comment 10 by, Nov 8 2016
Labels: Pri-3
Sign in to add a comment