[MMUSIC] ICE IPv4/IPv6 DualStack Fairness and Tunneled Interfaces

"Pal Martinsen (palmarti)" <palmarti@cisco.com> Mon, 05 January 2015 13:15 UTC

Return-Path: <palmarti@cisco.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 930CB1A700F for <mmusic@ietfa.amsl.com>; Mon, 5 Jan 2015 05:15:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level:
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ddjKtBPdCpwE for <mmusic@ietfa.amsl.com>; Mon, 5 Jan 2015 05:15:50 -0800 (PST)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 971EC1A6F7C for <mmusic@ietf.org>; Mon, 5 Jan 2015 05:15:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6780; q=dns/txt; s=iport; t=1420463750; x=1421673350; h=from:to:subject:date:message-id:mime-version; bh=Z3VX9gdiPfobKK+1ff08md9bWxu8biT4FrfXp3nn+yg=; b=BRNz9bruAFb9/BU41Rt5HT3sAXw8ISiZJPzpDWWsmDzSgDArkEfEr1Cm oyz0hM5wlbusi2vMX4Kxog0ZXiqieaVy1kh0ZoQ5kosquHGhc/EMNGd87 xf8ZcxGuSVO3K6nLtWKgxJ+rf/LQrx/XA2TNhNFmg2PMOd6LI63+QUSbO Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AtMFAKiNqlStJV2S/2dsb2JhbABcgwZSWASDAcMchg9qFgEBAQEBfYQTI2gBDD4CBDAnBBwSiBENmUmPRJM/CwEBAQEBHJJmLoETBY4ViHORUCKDbm8BgUR+AQEB
X-IronPort-AV: E=Sophos;i="5.07,700,1413244800"; d="scan'208,217";a="381285859"
Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-1.cisco.com with ESMTP; 05 Jan 2015 13:15:50 +0000
Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t05DFnIZ015429 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <mmusic@ietf.org>; Mon, 5 Jan 2015 13:15:49 GMT
Received: from xmb-rcd-x06.cisco.com ([169.254.6.6]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0195.001; Mon, 5 Jan 2015 07:15:49 -0600
From: "Pal Martinsen (palmarti)" <palmarti@cisco.com>
To: mmusic <mmusic@ietf.org>
Thread-Topic: ICE IPv4/IPv6 DualStack Fairness and Tunneled Interfaces
Thread-Index: AQHQKOm5oGPDvpyUSU+ubMc8wTH4vA==
Date: Mon, 05 Jan 2015 13:15:48 +0000
Message-ID: <70C2FBDE-0117-4CEA-B320-DBADA1219BCC@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.61.206.125]
Content-Type: multipart/alternative; boundary="_000_70C2FBDE01174CEAB320DBADA1219BCCciscocom_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/PmtRtiy5wF5e4R0xPzcW5Kcqc7Y
Subject: [MMUSIC] ICE IPv4/IPv6 DualStack Fairness and Tunneled Interfaces
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
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: Mon, 05 Jan 2015 13:15:52 -0000

Hi

We just posted a new version of the ICE IPv4/IPv6 Fairness draft
(http://www.ietf.org/internet-drafts/draft-martinsen-mmusic-ice-dualstack-fairness-01.txt)

We tried to address the comments we got regarding tunnelled interfaces during the mmusic session in Hawaii.

We added the following text to the introduction:
"Applications should also take special care to prioritize network
 interfaces know to be unreliable.  For example certain tunnel
 services might provide unreliable connectivity.  This specification
 does not provide any guidelines on how to prioritize different
 network interfaces.  This is best solved by the application itself
 and the best solution would vary from use-case to use-case.”

And later in the algorithm description:
"This leaves enough address space
  to further play with the values if different interface priorities
  needs to be added.  This is especially useful if tunneled interfaces
  with bad connectivity are known to exist.”

We also moved the algorithm description to the main body and added:
"The algorithm described in this section MAY be used by an
  implementation to introduce IPv4/IPv6 dual stack fairness.
  Implementations implementing their own algorithm must take care not
  to break any ICE compatibility.  Se Section Section 4 for details.”


It is worth noticing that this drafts only aims to introduce some fairness among IPv4 and IPv6 to avoid excessive delays if one of the paths is completely broken. We feel that further checklist optimisation based on application knowledge regarding interface behaviour is out of scope (Not to say a difficult problem to solve if you want an optimal solution in all possible scenarios).

.-.
Pål-Erik