Re: [MMUSIC] ICE candidate address selection update draft

> -----Original Message-----
> From: Pal Martinsen (palmarti) [mailto:palmarti@cisco.com]
> Sent: Tuesday, August 07, 2012 11:30 AM
> To: Jonathan Lennox
> Cc: Dan Wing (dwing); Ari Keranen; mmusic@ietf.org
> Subject: Re: [MMUSIC] ICE candidate address selection update draft
> 
> 
> On Aug 7, 2012, at 11:53 AM, Jonathan Lennox <jonathan@vidyo.com>
> wrote:
> 
> > On Tuesday, August 7 2012, "Dan Wing" wrote to "'Jonathan Lennox',
> 'Ari Keranen', mmusic@ietf.org" saying:
> >
> >> Mine would be to take the list of IPv6 and IPv4 addresses and try
> them
> >> in the order described by ICE (which currently recommends following
> >> the OS's default, which is sometimes hard to get depending on the
> OS).
> 
> From a ICE multi platform library developer that is somewhat of a
> nightmare.
> Guess it can be solved by having a reasonable interface that the
> application
> that uses the library can fill in the defaults. Having reasonable
> default values
> is important as some platforms might not be able to set the values.
> 
> >>
> >> But if the first IPv6 candidate didn't return a connectivity checks
> >> quickly (let's say, 150ms), initiate a connectivity check on the
> >> highest priority IPv4 address next.  In that 150ms, based on ICE's
> >> pacing, many IPv6 addresses will have been tried.  150ms gives
> plenty
> >> of time for IPv6 to 'win', before using an IPv4 resource that is
> >> likely shared with IPv4-only devices.
> >
> > Can't this result in the endpoints getting out of sync with the order
> of the checklist?  If one side has started IPv4 while the other hasn't,
> you won't have the outbound packets coming from one side to create the
> port bindings.
> >
> It can at least potentially introduce more "kamikaze" packets and delay
> the result. The STUN transaction have 10 retransmits and would timeout
> long after the checklist is empty.
> 
> To maintain the speed of ICE negotiation and keep call setup times low
> I think we should consider looking at the pacing of the conn checks.
> The rationale behind the pacing was not to overwhelm the NATs.

Yes.  And also to reduce the concern that ICE connectivity checks 
could flood a link.

> Have the
> world move slightly towards better NATs? Looking from the perspective
> of an endpoint sending 1080p60 video streams the pacing seem a bit
> conservative?

The problem, even at the time, was not pps or bandwidth throughput of
the NATs.  Rather, it was that NATs would not create new mappings
quick enough and drop the STUN Binding Request.  This would be re-
transmitted and make it through the NAT, but that retransmit was 
obviously harmful for call setup times.  As all the connectivity
checks are supposed to be sent from the same source address and
port on the client, a new mapping is only necessary for NATs which
have "address dependent mapping" or "address and port dependent
mapping" behavior.

I just checked, and couldn't find a test of UDP mapping speed
at http://nattest.net.in.tum.de/results.php, 
draft-jennings-behave-test-results, or 
http://eggert.org/papers/2010-imc-hgw-study.pdf.  Perhaps there
are tests available somewhere else.

> And how does the different paths (IPv4, IPv6, multi
> homed) impact the pacing? Could we do more in parallel without
> overwhelm the NATs?

I'm sure we could.

We could also be more aggressive with STUN retransmissions, and
less aggressive at trying new candidates.  That depends on our 
confidence that the candidates are in the proper order, and if
we can move a connection to a new candidate.  RTP can be moved
pretty easily; TCP cannot.  Before ICE completes, we could move
RTP sessions around without draft-wing-mmusic-ice-mobility.

It is probably worth backing up and enumerating the problem(s) we 
have with ICE, and then deciding what we want to solve.

> I am wondering if we could do something smart with prioritising the
> checklist and triggered checks to make sure IPv6 wins if there is
> connectivity? I have to little understanding if IPv6 and all the
> different addresses to clearly formulate the idea at the moment.
> (Hoping this may trigger something for someone.)

ICE was written before there was wide acceptance that the IPv6 path
is sometimes broken.  Tweaking ICE to better accommodate that reality
seems worthwhile.

-d

> 
> .-.
> Pål-Erik
> 
> 
> > --
> > Jonathan Lennox
> > jonathan@vidyo.com
> > _______________________________________________
> > mmusic mailing list
> > mmusic@ietf.org
> > https://www.ietf.org/mailman/listinfo/mmusic