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 9 users

Issue metadata

Status: Assigned
Owner:
Last visit > 30 days ago
Cc:
Components:
NextAction: ----
OS: ----
Pri: 3
Type: Bug



Sign in to add a comment

Sending STUN pings every 50ms is too conservative

Project Member Reported by jiayl@webrtc.org, Dec 4 2014

Issue description

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 pthatcher@google.com, Dec 8 2014

Labels: EngTriaged Mstone-42
Owner: pthatcher@webrtc.org
We'll start working on this Q1 2015.
Project Member

Comment 3 by juberti@webrtc.org, 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 vrk@webrtc.org, Dec 17 2014

Labels: Area-PeerConnection
Project Member

Comment 5 by juberti@webrtc.org, Dec 18 2014

Labels: -Area-PeerConnection Area-Network
Project Member

Comment 6 by pthatcher@webrtc.org, 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 juberti@webrtc.org, Jun 4 2015

Labels: Performance
Project Member

Comment 8 by tnakamura@webrtc.org, 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 juberti@webrtc.org, Jan 30 2016

Right, this remains an open area of research.
Project Member

Comment 10 by pthatcher@webrtc.org, Nov 8 2016

Labels: Pri-3
Hmmm...

Sign in to add a comment