Re: [MMUSIC] ICE candidate address selection update draft

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

> -----Original Message-----
> From: Pal Martinsen (palmarti) [mailto:[e-mail]]
> Sent: Thursday, August 09, 2012 10:13 AM
> To: Dan Wing (dwing)
> Cc: Jonathan Lennox; Ari Keranen; <[e-mail]>
> Subject: Re: [MMUSIC] ICE candidate address selection update draft
> 
> 
> On Aug 8, 2012, at 6:05 PM, Dan Wing <[e-mail]> wrote:
> 
> >> -----Original Message-----
> >> From: Pal Martinsen (palmarti) [mailto:[e-mail]]
> >> Sent: Tuesday, August 07, 2012 11:30 AM
> >> To: Jonathan Lennox
> >> Cc: Dan Wing (dwing); Ari Keranen; [e-mail]
> >> Subject: Re: [MMUSIC] ICE candidate address selection update draft
> >>
> >>
> >> On Aug 7, 2012, at 11:53 AM, Jonathan Lennox <[e-mail]>
> >> wrote:
> >>
> >>> On Tuesday, August 7 2012, "Dan Wing" wrote to "'Jonathan Lennox',
> >> 'Ari Keranen', [e-mail]" 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.
> >
> Thanks for clearing that up.
> 
> >> 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.
> >
> More agressive STUN retransmits would help speeding up things for RFLX
> candidates.
> 
> > It is probably worth backing up and enumerating the problem(s) we
> > have with ICE, and then deciding what we want to solve.
> >
> Yes, you are right.
> 
> Keeping the number of connectivity checks at a minimum by removing the
> ones that will never work as this documents describes is probably what
> we want from this document.

Absolutely.


Solving additional problems might belong in other documents (e.g.,
faster STUN retransmissions).  

> >> 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.
> 
> Prioritising IPv6 over IPv4 is all about choosing from the valid_list
> and that is
> currently up to the different implementations to decide. Is it
> worthwhile having a separate document describing that?

To my mind, that seems appropriate for this ICE Candidate Address
Selection Update document.  Right now ICE is pretty circumspect in
its IPv6/IPv4 recommendation and says to follow what the OS would
order, if possible, but doesn't provide strong recommendations if
the OS doesn't have an order.

I know there are one or two APIs in Windows that accept a bunch
of IP addresses and will re-order them.  I dunno if a similar API
is available for Android, Linux, or iOS/OS X.  Without an API on
those OSs, the ICE Candidate Address Selection Update is a good
place to make recommendations for those OSs.

-d


> 
> .-.
> Pål-Erik
> 
> >
> > -d
> >
> >
> >>
> >> .-.
> >> Pål-Erik
> >>
> >>
> >>> --
> >>> Jonathan Lennox
> >>> [e-mail]
> >>> _______________________________________________
> >>> mmusic mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/mmusic
> >