<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:"Times New Roman \(Body CS\)";
        panose-1:2 11 6 4 2 2 2 2 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
span.EmailStyle19
        {mso-style-type:personal-reply;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
--></style>
</head>
<body lang="EN-US" link="blue" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal">I like the idea of doing just one STUN request to avoid the many semi-duplicate candidates.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Another interesting thing to think about is that in most cases (99.9% ish) the STUN query is going to return the same result as last time. In most cases the host computer has not moved networks and the external address has not changed.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">What if libnice could remember the previous external address and lead with that as a candidate. Libnice could still do one (or more) STUN queries to check if the external address has changed. But starting with the previously known external
 address could speed up connection a lot.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">The challenge is “how to remember the previous external address”. Libnice lives in somebody’s process and on some random host computer. Libnice might be completely shut down in-between uses, even if the process keeps running.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">What if libnice remembered the previous external address somewhere in process space. If the process shuts down the knowledge is lost. But if the process keeps running (e.g. a server or a long running browser) then the external address is
 remembered. Is there a cross-platform place to stash data? Environment variables might work. A persistent background thread might work.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">The reason I suggest optimizations like this is customer experience. I see chrome to gstreamer establish connections in less than a second. Gstreamer to gstreamer often takes much more time – easily five seconds plus.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Stuart<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="margin-bottom:12.0pt"><b><span style="font-size:12.0pt;color:black">From:
</span></b><span style="font-size:12.0pt;color:black">nice <nice-bounces@lists.freedesktop.org><br>
<b>Date: </b>Monday, October 19, 2020 at 11:00 AM<br>
<b>To: </b>Stuart Marshall <stuart@seelye.net><br>
<b>Cc: </b>Juan Navarro <juan.navarro@gmx.es>, nice@lists.freedesktop.org <nice@lists.freedesktop.org><br>
<b>Subject: </b>Re: [libnice] Force an external address (srflx) candidate?<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal">Hi Stuart,<br>
<br>
On 10/14/20 at 09:22pm, Stuart Marshall wrote:<br>
> In contrast, the ICE candidates emitted by Chrome are stunningly few and precise. I understand that the ICE protocols and the libnice implementation were/are meant to be general case. But they miss obvious efficiencies that can be provided by additional external
 information. STUN servers facilitate some of that additional information, but introduce a dependency and more latency.<br>
> <br>
> My knowledge of libnice internals is not great, but I kind of wish we could<br>
> <br>
>   1.  Feed some particular IP candidate addresses to it,<br>
>   2.  Tell it to skip a bunch of other candidate generation and testing<br>
<br>
I think of some optimisations, that could help to limit the number of<br>
candidates, without weakening the versatility of the ice method overall<br>
(except in *rare* cases where the server running libnice uses source<br>
routing, ie chooses the default route based on the source IP address):<br>
<br>
We could use a single server reflexive candidate and relay local<br>
candidate, per stream/component.<br>
<br>
Generally, there's no gain to send a stun request from each local<br>
interface, because all packets will reach the same stun server by the<br>
same default route. <br>
<br>
The consequence is that we obtain <N> distinct server-reflexive<br>
candidates from <N> distinct source IP addresses. These<br>
server-reflexives candidates are distinct because their IP address will<br>
be the same (this is our public IP address), but the port mapping will<br>
be different. The same applies to turn relay candidates too (including<br>
unnecessary resources reservations on the turn servers BTW).<br>
<br>
To avoid that, we could for example:<br>
  1. discard these redundant candidates when we discover them (when<br>
  processing the discovery stun response).<br>
  2. or more radically, just send a single stun and turn discovery request.<br>
<br>
In case of 2. the choice of the local interface used as the base address<br>
to send this unique stun/turn discoevry request is normally not<br>
relevant, because the routing table will hopefully make these packets go<br>
out by the same default route again, whatever source interface they come<br>
from.<br>
<br>
To summarize, I think that sending a single stun request from a single<br>
network interface during gathering phase to obtain our server-reflexive<br>
address is normally a cheap operation (one RTT when the thr stun server<br>
is available), but what is expensive from libnice point of view is to<br>
deal with many identical reflexive/relay candidates during the<br>
connecting phase, because it creates many possibilities to be tested.<br>
And the more possibilities we have to test, the more time it takes to<br>
complete.<br>
<br>
Best wishes,<br>
-- <br>
fabrice<br>
_______________________________________________<br>
nice mailing list<br>
nice@lists.freedesktop.org<br>
<a href="https://lists.freedesktop.org/mailman/listinfo/nice">https://lists.freedesktop.org/mailman/listinfo/nice</a><o:p></o:p></p>
</div>
</div>
</body>
</html>