Re: [DNSOP] Benjamin Kaduk's Discuss on draft-ietf-dnsop-session-signal-12: (with DISCUSS and COMMENT)

"Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net> Mon, 30 July 2018 18:18 UTC

Return-Path: <ietf@kuehlewind.net>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7992130E96 for <dnsop@ietfa.amsl.com>; Mon, 30 Jul 2018 11:18:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.net
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 Tv6TYHzgGocm for <dnsop@ietfa.amsl.com>; Mon, 30 Jul 2018 11:18:45 -0700 (PDT)
Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C10D1129619 for <dnsop@ietf.org>; Mon, 30 Jul 2018 11:18:38 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; b=mO75zoo82NWH0SHqjsG0OpzSmQHPpJKVWXB+sqbYHlQOoB7NXZCxx03lKMUqqAzSINVY60vqnut7O3Pnx274xpyxXef/pWT9YuxFKsD/C3sww+BOV9tw+etpylXGjMKl4SSNnSfx0mCKxfoUlsjxmDP9hpxn98kGOtrYOKjaozY=; h=Received:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-PPP-Message-ID:X-PPP-Vhost;
Received: (qmail 25665 invoked from network); 30 Jul 2018 20:11:54 +0200
Received: from i577bce38.versanet.de (HELO ?192.168.178.24?) (87.123.206.56) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 30 Jul 2018 20:11:53 +0200
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>
In-Reply-To: <153270509617.32757.1191915890190419981.idtracker@ietfa.amsl.com>
Date: Mon, 30 Jul 2018 20:11:52 +0200
Cc: The IESG <iesg@ietf.org>, tjw.ietf@gmail.com, dnsop@ietf.org, dnsop-chairs@ietf.org, draft-ietf-dnsop-session-signal@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <30017004-FF22-40B1-AEB6-97899F2110BD@kuehlewind.net>
References: <153270509617.32757.1191915890190419981.idtracker@ietfa.amsl.com>
To: Benjamin Kaduk <kaduk@MIT.EDU>
X-Mailer: Apple Mail (2.3445.9.1)
X-PPP-Message-ID: <20180730181153.25656.86615@lvps83-169-45-111.dedicated.hosteurope.de>
X-PPP-Vhost: kuehlewind.net
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/R32ftwvh844RMnEoIY0NNzJ1qgk>
Subject: Re: [DNSOP] Benjamin Kaduk's Discuss on draft-ietf-dnsop-session-signal-12: (with DISCUSS and COMMENT)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 30 Jul 2018 18:18:46 -0000

Hi Ben, hi all,

as you summoned an TSV AD...

> Am 27.07.2018 um 17:24 schrieb Benjamin Kaduk <kaduk@MIT.EDU>:
> 
> I should probably leave this to my (transport-area?) colleagues to discuss
> further, but I'm not sure that the interaction of this mechanism with
> high-RTT connections is fully covered -- for example, the inactivity
> timeout in Section 6.4(.x) could behave poorly when the timeout is set to a
> smaller value than the RTT, as the server would potentially end up starting
> the "forcibly abort" process (and potentially causing the client to lose
> for an hour) because the server's timer starts when it sends the DSO
> response that initiates its idea of the session, and would not recieve
> graceful shutdown messages from a properly-behaving client in time.

My understanding is that they require a minimum time-out of 5 second at the server side, which seems reasonably safe to me. However, maybe this could be further clarified or explained in the doc.

Mirja