Re: [MMUSIC] ICE candidate address selection update draft
"Dan Wing" <dwing@cisco.com> Thu, 09 August 2012 17:40 UTC
Return-Path: <dwing@cisco.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 934F821F879E for <mmusic@ietfa.amsl.com>; Thu, 9 Aug 2012 10:40:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.504
X-Spam-Level:
X-Spam-Status: No, score=-110.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sBLe9ouaBZup for <mmusic@ietfa.amsl.com>; Thu, 9 Aug 2012 10:40:33 -0700 (PDT)
Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 9FB3921F878E for <mmusic@ietf.org>; Thu, 9 Aug 2012 10:40:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=6716; q=dns/txt; s=iport; t=1344534033; x=1345743633; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=EOysE1rGzvTIWGGXsA08fJ5K8N9SUmZitu2hYQDZb5o=; b=NTPFuBvAXAk/65BGxPQ0TgMpk95e+xvtqeCOz1nM3n0R07XyK6+TFNVY tUe8Xxi6Mo9mvVrtTOKQc6ktDClHu961QCwmo93XCgOJrZguTmC8hLKSU /NJM6jTEpSjEqH85zqTqoboEmxfSZ0AXq7CJHJA0p+6jg3vi0DbEBLTsA w=;
X-IronPort-AV: E=Sophos;i="4.77,741,1336348800"; d="scan'208";a="54482175"
Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 09 Aug 2012 17:40:33 +0000
Received: from dwingWS (sjc-vpn7-1991.cisco.com [10.21.151.199]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q79HeX1l017339; Thu, 9 Aug 2012 17:40:33 GMT
From: Dan Wing <dwing@cisco.com>
To: "'Pal Martinsen (palmarti)'" <palmarti@cisco.com>
References: <5019BD3A.6020907@nomadiclab.com> <5019C1AB.1030709@viagenie.ca> <5019DF32.80603@nomadiclab.com> <501A08F4.9050609@viagenie.ca> <501C1F38.8050307@nomadiclab.com> <501C208C.1060207@viagenie.ca> <501C2639.60000@nomadiclab.com> <EF7F16D1-4BAB-49CA-9052-E5FE87B03271@vidyo.com> <501FDD75.3090506@nomadiclab.com> <C3759687E4991243A1A0BD44EAC823034DF5B10A45@BE235.mail.lan> <092c01cd746c$5e7c8040$1b7580c0$@com> <C3759687E4991243A1A0BD44EAC823034DF5B10A86@BE235.mail.lan> <B1B5B0AF-97CE-47EC-A533-62EAFDCBAF60@cisco.com> <0e2801cd757f$98a72680$c9f57380$@com> <E7E7FFBC-D6FE-4444-8AA3-9DCE43E02FE4@cisco.com>
In-Reply-To: <E7E7FFBC-D6FE-4444-8AA3-9DCE43E02FE4@cisco.com>
Date: Thu, 09 Aug 2012 10:40:33 -0700
Message-ID: <04c701cd7656$13b9ef70$3b2dce50$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AQHNcD4JBLVzrxTUlUON4i4MPEKn1pdF9UOAgAAjMwCAADHIAIACfOUAgAABlQCAAAbEgIAA1OmAgAOZDYCAALjLgIAAVdMAgAAsKgCAAJB/AIABDntwgAIAu4D//7Jz4A==
Content-Language: en-us
Cc: 'Jonathan Lennox' <jonathan@vidyo.com>, mmusic@ietf.org
Subject: Re: [MMUSIC] ICE candidate address selection update draft
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Aug 2012 17:40:34 -0000
> -----Original Message----- > From: Pal Martinsen (palmarti) [mailto:palmarti@cisco.com] > Sent: Thursday, August 09, 2012 10:13 AM > To: Dan Wing (dwing) > Cc: Jonathan Lennox; Ari Keranen; <mmusic@ietf.org> > Subject: Re: [MMUSIC] ICE candidate address selection update draft > > > On Aug 8, 2012, at 6:05 PM, Dan Wing <dwing@cisco.com> wrote: > > >> -----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. > > > 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 > >>> jonathan@vidyo.com > >>> _______________________________________________ > >>> mmusic mailing list > >>> mmusic@ietf.org > >>> https://www.ietf.org/mailman/listinfo/mmusic > >
- [MMUSIC] ICE candidate address selection update d… Ari Keranen
- Re: [MMUSIC] ICE candidate address selection upda… Simon Perreault
- Re: [MMUSIC] ICE candidate address selection upda… Ari Keranen
- Re: [MMUSIC] ICE candidate address selection upda… Simon Perreault
- Re: [MMUSIC] ICE candidate address selection upda… Pal Martinsen (palmarti)
- Re: [MMUSIC] ICE candidate address selection upda… Ari Keranen
- Re: [MMUSIC] ICE candidate address selection upda… Ari Keranen
- Re: [MMUSIC] ICE candidate address selection upda… Simon Perreault
- Re: [MMUSIC] ICE candidate address selection upda… Ari Keranen
- Re: [MMUSIC] ICE candidate address selection upda… Jonathan Lennox
- Re: [MMUSIC] ICE candidate address selection upda… Pal Martinsen (palmarti)
- Re: [MMUSIC] ICE candidate address selection upda… Ari Keranen
- Re: [MMUSIC] ICE candidate address selection upda… Jonathan Lennox
- Re: [MMUSIC] ICE candidate address selection upda… Dan Wing
- Re: [MMUSIC] ICE candidate address selection upda… Jonathan Lennox
- Re: [MMUSIC] ICE candidate address selection upda… Pal Martinsen (palmarti)
- Re: [MMUSIC] ICE candidate address selection upda… Tom Taylor
- Re: [MMUSIC] ICE candidate address selection upda… Dan Wing
- Re: [MMUSIC] ICE candidate address selection upda… Pal Martinsen (palmarti)
- Re: [MMUSIC] ICE candidate address selection upda… Dan Wing
- Re: [MMUSIC] ICE candidate address selection upda… Dan Wing
- Re: [MMUSIC] ICE candidate address selection upda… Jonathan Lennox
- Re: [MMUSIC] ICE candidate address selection upda… Pal Martinsen (palmarti)