Re: [MMUSIC] Updating the pacing of ICE connectivity checks

["Dan Wing" <[e-mail]>]

> -----Original Message-----
> From: Emil Ivov [mailto:[e-mail]]
> Sent: Friday, February 15, 2013 9:17 AM
> To: Gonzalo Camarillo
> Cc: Magnus Westerlund; Ari Keränen; 'mmusic'; Dan Wing
> Subject: Re: [MMUSIC] Updating the pacing of ICE connectivity checks
> 
> Well for one, we hadn't even noticed that there was different pacing for
> non-RTP traffic, so when we added support for Pseudo TCP to ice4j.org,
> we just let it use the default timers. It really didn't cross our
> collective minds that the same stack in the same application would have
> the right of going down to 20ms if it used the magic word (and RTP
> header) but then go back up to 500 ms if it didn't. It's almost as if it
> were punished for having bad non-RTP thoughts ;)
> 
> Anyways, I think that, had we known about the "MUST NOT drop below 500
> ms" limitation, we would have simply ignored it: these are user
> perceptible delays after all, and no one would like to wayt 10+ seconds
> for a file to start transferring.

A quick a analysis of what browsers have been doing in this area:  The 
TCP retransmit timer on most OSs is 3 seconds.  But Firefox and Chrome 
have backup connection timers that are more aggressive (250ms and 300ms,
if I recall correctly).  IE does not have a backup connection timer.  So
they are not as aggressive as 20ms (which would be too aggressive on a lot
of networks) but they also do not strictly follow the IETF TCP transport
guidelines to retry a TCP connection after a long 3 seconds.

-d


> Cheers,
> Emil
> 
> On 15.02.13, 17:47, Gonzalo Camarillo wrote:
> > Hi,
> >
> > to add to what Magnus said, it is important that we understand what
> > implementations have been doing so far (regardless of what the RFC
> > says) and that we come up with recommendations implementers will
> > actually follow. Keep in mind we are here to write specifications, not
> > fiction ;-)
> >
> > Thanks,
> >
> > Gonzalo
> >
> >
> > On 14/02/2013 5:51 PM, Magnus Westerlund wrote:
> >> Thus I would be careful with speeding up Ta for RTP to much, and I
> >> think someone needs to fine empiric data that it would work.
> >>
> >> For the the 500 ms that can likely be significantly lowered without
> >> any issues. But some considerations around the wider usage needs to
> >> be taken into account.
> >
> >
> 
> --
> https://jitsi.org