Re: [sipcore] Happy Eyeballs for SIP / Summa Beatitudinem

"Asveren, Tolga" <tasveren@sonusnet.com> Sun, 18 December 2016 13:49 UTC

Return-Path: <tasveren@sonusnet.com>
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E311E12941A for <sipcore@ietfa.amsl.com>; Sun, 18 Dec 2016 05:49:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Level:
X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sonusnetworks.onmicrosoft.com
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 SkHkc6b6r6-8 for <sipcore@ietfa.amsl.com>; Sun, 18 Dec 2016 05:49:21 -0800 (PST)
Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0043.outbound.protection.outlook.com [104.47.37.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0C22128B38 for <sipcore@ietf.org>; Sun, 18 Dec 2016 05:49:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=9JtPkT8N+GvsaVo9VPb2Hc/b6y10NVdXjDKUnlQ+9qo=; b=EVNhiLrZ/Rw+OwvzYRu/9gji4iCSwYKzDW9dbI0GR2f1Nj1AWcQ7M8iNbhURepwot+9tbYLJfEYuC68yO0PfnV1Ro3FvV+ovhqlknd2Gm0ClICmxpeP/Ak3j/chJ/RppSMYX9OWjm2g9LkGEjAwOAF36JP4+8MCG2zxn/ZNe8D4=
Received: from CO2PR03MB2342.namprd03.prod.outlook.com (10.166.93.14) by CO2PR03MB2343.namprd03.prod.outlook.com (10.166.93.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.789.14; Sun, 18 Dec 2016 13:49:19 +0000
Received: from CO2PR03MB2342.namprd03.prod.outlook.com ([10.166.93.14]) by CO2PR03MB2342.namprd03.prod.outlook.com ([10.166.93.14]) with mapi id 15.01.0789.018; Sun, 18 Dec 2016 13:49:19 +0000
From: "Asveren, Tolga" <tasveren@sonusnet.com>
To: "Dale R. Worley" <worley@ariadne.com>
Thread-Topic: [sipcore] Happy Eyeballs for SIP / Summa Beatitudinem
Thread-Index: AdJZFHrOvyU+dWmrSZmJnOs13D51Dg==
Date: Sun, 18 Dec 2016 13:49:19 +0000
Message-ID: <CO2PR03MB2342238C90A7F9D3AC291AC1B29E0@CO2PR03MB2342.namprd03.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=tasveren@sonusnet.com;
x-originating-ip: [73.29.18.75]
x-ms-office365-filtering-correlation-id: 3797829a-c8f2-41b3-0c59-08d4274caa6b
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CO2PR03MB2343;
x-microsoft-exchange-diagnostics: 1; CO2PR03MB2343; 7:HeL4E56NthbqFfulWNlSjG7i7LRm1s6+xg1X8GguanAgWmh6JgarEzQv1CPxtPpfQi6yu59XBGaHz8YAeRrsIjffVuZYcwEZfDk8VkmO4l8QGTsg4JZiPjMkOGTZBvQBNyjMeN+HB6ogtFbbIzXtXqSUU3Ef/OzmuRZrxNpQyYH7XljS9v+7c/shVQi5n1I4ScI8V1QIWznmhZD+h5Y5g6hYmgKeVwgLurALyHxC1OHFYS4aSJIp/BQYWvXG7QMll+WrhDZe2F6dcqs0C7o++lqH87jGvZ1Wu4TzxnLmbYSEusK8l9FxH0EKtSnJSaurBtE24AB8T/xgBkaSD9cWtVpeUoT+oHOuqcnuLnvQyGAOnkhD4BUmJHvxhBg88Q+wKE/oVb5H08PMJ5/sTeGf/ceS3J7UbewT+e4RRRFbOpmxCzqcztiX3KRuvHHk9fcwfzhTytGOiMMyQrzEI7rOTw==
x-microsoft-antispam-prvs: <CO2PR03MB2343B5497277C96DFA83BF2BB29E0@CO2PR03MB2343.namprd03.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(158342451672863)(150554046322364)(100405760836317);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123560025)(20161123564025)(20161123562025)(20161123555025)(6072148)(6047074); SRVR:CO2PR03MB2343; BCL:0; PCL:0; RULEID:; SRVR:CO2PR03MB2343;
x-forefront-prvs: 01604FB62B
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(189002)(199003)(305945005)(66066001)(74316002)(99286002)(7736002)(81156014)(81166006)(8676002)(68736007)(122556002)(189998001)(8936002)(9686002)(54356999)(101416001)(50986999)(3660700001)(3280700002)(106356001)(105586002)(76576001)(33656002)(2906002)(4326007)(92566002)(2900100001)(86362001)(3846002)(102836003)(6116002)(6436002)(77096006)(38730400001)(6506006)(25786008)(229853002)(97736004)(6916009)(110136003)(7696004)(5660300001); DIR:OUT; SFP:1101; SCL:1; SRVR:CO2PR03MB2343; H:CO2PR03MB2342.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None (protection.outlook.com: sonusnet.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: sonusnet.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Dec 2016 13:49:19.2939 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR03MB2343
Archived-At: <https://mailarchive.ietf.org/arch/msg/sipcore/S8tW0ZkmnkyWkkac6vlsUDJKfDY>
Cc: "sipcore@ietf.org" <sipcore@ietf.org>
Subject: Re: [sipcore] Happy Eyeballs for SIP / Summa Beatitudinem
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sipcore/>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 18 Dec 2016 13:49:24 -0000

Slightly changing the subject line for easier tracking...

I think it would be useful to get on a common understanding/consensus on "what needs to be covered and in which document" as far as use of multiple IP Address Families/Multiple Interfaces are concerned. Here is a first attempt for "Summary of Happiness":


A) Use of Multiple IP Address Families
i- RFC2782
Defines how to resolve SRV Records
All SRVs are resolved with DNS query ordering according to priority/weight
Does not mandate any procedure regarding how/in which order learned addressed are used

ii- RFC6555 
Defines parallel connection attempt for different IP address families. 
Restricts itself -I don't know exactly why- to a single hostname for IPv4/IPv6 and does not cover other ways of learning IP Addresses, e.g. provisioning, DHCP based. AFAICS, procedure described in this specification can be applied for those cases as well. 
Use of mechanism is allowed for connectionless transports as long as request/response semantics are achieved by application layer

iii- RFC7984
Defines DNS lookup for all IP address families instead of just one of them
The end result is that all SRV records are fully resolved. I think this covers all cases like multiple SRVs for a single IP address family as well although it is not directly mentioned in the specification.
	
iv- draft-worley-sip-he-connection-00
Defines SIP related procedures to use RFC6555 for SIP. This includes probing/keep-alive for existing connections, using an existing connection for all requests.
Would any "fast-failover after connection failure", e.g. toward the standby server after failure of the primary server, related procedures be in scope? For connection oriented protocols, any possible recommendations/improvements in this area would probably be limited to reusing the TLS connection. Is there anything SIP specific, which could help here?

B) Use of Multiple Interfaces
v- I think the ideal place to cover this would be RFC6555-bis (also by considering other restrictions as mentioned in ii- above). I wouldn't think that there would be a need for defining anything new in draft-worley-sip-he-connection-00 (?).

C) Connectionless protocols
Will be handled by another draft

D) SIP/UDP/DTLS
Requires a new draft


Thanks,
Tolga