IETF Logo Mail Archive

Re: [sipcore] Spencer Dawkins' Yes on draft-ietf-sipcore-dns-dual-stack-07: (with COMMENT)

worley@ariadne.com (Dale R. Worley) Fri, 19 August 2016 19:13 UTC

Return-Path: <worley@alum.mit.edu>
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 BC10C12DB14 for <sipcore@ietfa.amsl.com>; Fri, 19 Aug 2016 12:13:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.934
X-Spam-Level:
X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
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 f0Nm62cRiNmc for <sipcore@ietfa.amsl.com>; Fri, 19 Aug 2016 12:13:37 -0700 (PDT)
Received: from resqmta-ch2-05v.sys.comcast.net (resqmta-ch2-05v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4528312DB31 for <sipcore@ietf.org>; Fri, 19 Aug 2016 12:13:35 -0700 (PDT)
Received: from resomta-ch2-20v.sys.comcast.net ([69.252.207.116]) by resqmta-ch2-05v.sys.comcast.net with SMTP id apEKbkBxH2FGMapEUbcyw1; Fri, 19 Aug 2016 19:13:34 +0000
Received: from hobgoblin.ariadne.com ([73.100.16.189]) by resomta-ch2-20v.sys.comcast.net with SMTP id apESbhHA36coJapETbH8g2; Fri, 19 Aug 2016 19:13:34 +0000
Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u7JJDW6q013002; Fri, 19 Aug 2016 15:13:32 -0400
Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u7JJDVfo012996; Fri, 19 Aug 2016 15:13:31 -0400
X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f
From: worley@ariadne.com
To: Spencer Dawkins <spencerdawkins.ietf@gmail.com>
In-Reply-To: <147140468741.19939.3811368106001545602.idtracker@ietfa.amsl.com> (spencerdawkins.ietf@gmail.com)
Sender: worley@ariadne.com
Date: Fri, 19 Aug 2016 15:13:31 -0400
Message-ID: <87mvk87esk.fsf@hobgoblin.ariadne.com>
X-CMAE-Envelope: MS4wfCo09Kb/Jkwv/u1JcQchMpE+uoN9Khh+ab4OWblojmlbHVUMrd6HHcID9kJK//YpMRCasrlQM0RIZtQsqKAUJetwmWOMG5/MlXGpk0BUxgLD+Nig93LJ n9ToIQ7NC/X1L67+gJvEA2KiI9HrpmKvtggT9+ZOSqi91pDzci7H4O28xrjLPrtYkD3mmQ/4z+X/891bfOieDFx5zxccFJx5ylW/cawDCe31qdBeCgY0GMc8 Zvb2Dj7a/p5vSYQLRyN1K67I8d/hxa/4QhWeRvwnr5POjlAw+dtSJV9GRj8xSqBW4sIOMnpfYMOp8urEhf7849sjdQEFhv+PlRwOfM4uCDrYAhh9H+AN621U SD4ODZGPDes9/80odd4WUyE7zxR2+A==
Archived-At: <https://mailarchive.ietf.org/arch/msg/sipcore/E66a8n8o_LFKI2Q_WAZUzd0-FoI>
Cc: sipcore@ietf.org, draft-ietf-sipcore-dns-dual-stack@ietf.org, iesg@ietf.org, sipcore-chairs@ietf.org
Subject: Re: [sipcore] Spencer Dawkins' Yes on draft-ietf-sipcore-dns-dual-stack-07: (with COMMENT)
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: Fri, 19 Aug 2016 19:13:39 -0000

"Spencer Dawkins" <spencerdawkins.ietf@gmail.com> writes:
> Could you provide some explanation for the reader as to why SIP is
> "different", following this statement? Even an example would be useful.
>
>    Unfortunately, in common SIP situations, it is not possible to "race"
>    simultaneous request attempts using two address families.

That's a good point, because the reason is non-obvious to a reader who
hasn't hassled with SIP in unreliable network environments.

Racing in HTTP is the sending of simultaneous TCP SYNs to two different
addresses.  The client then continues the handshake and sends the
request to the address that responds first.  The crucial fact is that
opening a TCP connection to an HTTP server alone does not change the
server's state.

SIP requests are usually transmitted as single UDP packets, so sending
two copies of the request to two different addresses risks having two
copies of the request propagating through the SIP network at the same
time -- the difference from HTTP is that the SIP element cannot test the
route in a non-state-changing way.

If two copies of the same request arrive at one client, the client must
reject the second of them with a 482 response.  But this rule is not
sufficient to prevent user-visible differences in behavior because a
proxy that is upstream of the second request to arrive at the client may
(almost immediately!) serially fork the second request to further
destinations.  A version of this scenario that I saw in the wild is
diagrammed in
https://www.ietf.org/mail-archive/web/sipcore/current/msg06853.html.

I've added this explanation to section 3.2.  You can see the change in

https://www.ietf.org/rfcdiff?url1=draft-ietf-sipcore-dns-dual-stack-07&url2=http://svn.resiprocate.org/rep/ietf-drafts/worley/draft-ietf-sipcore-dns-dual-stack-08.txt

Dale

v2.23.0 | Report a Bug | By Email