Re: [DNSOP] Stuart and I had a discussion about the flow control issue in your DISCUSS (Mirja)

"Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net> Thu, 02 August 2018 22:15 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 C47EB130E3B for <dnsop@ietfa.amsl.com>; Thu, 2 Aug 2018 15:15:53 -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 4fxvcmK9T6kx for <dnsop@ietfa.amsl.com>; Thu, 2 Aug 2018 15:15:51 -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 39E1A130DD3 for <dnsop@ietf.org>; Thu, 2 Aug 2018 15:15:51 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; b=M4yVMBQSPPNJvnGHqcVnjSZ3nrh/uZur6UWYmksDyeqZLsN4jYx2IM4w7+LraUDhFXLD9qha0y7Eq9jiCgTRc0eVb/8FJJdovjpVIvHadIVDEJkirDxT7NvWk+iEFWLVEGxQfkzkw/b2KW1k8BNF772P+cXABVL0XQ2aKCz8gJY=; 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 10281 invoked from network); 3 Aug 2018 00:14:49 +0200
Received: from i577bceeb.versanet.de (HELO ?192.168.178.24?) (87.123.206.235) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 3 Aug 2018 00:14:49 +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: <CAPt1N1mVGfvtj0GG3zyFWgtsRGLDX=r=jH2fqeoOBivbBT150g@mail.gmail.com>
Date: Fri, 03 Aug 2018 00:14:46 +0200
Cc: Tim Wicinski <tjw.ietf@gmail.com>, dnsop WG <dnsop@ietf.org>, dnsop-chairs <dnsop-chairs@ietf.org>, The IESG <iesg@ietf.org>, draft-ietf-dnsop-session-signal@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <D4A52E97-60E9-424C-9C56-6098067A086D@kuehlewind.net>
References: <CAPt1N1mVGfvtj0GG3zyFWgtsRGLDX=r=jH2fqeoOBivbBT150g@mail.gmail.com>
To: Ted Lemon <mellon@fugue.com>
X-Mailer: Apple Mail (2.3445.9.1)
X-PPP-Message-ID: <20180802221449.10272.88197@lvps83-169-45-111.dedicated.hosteurope.de>
X-PPP-Vhost: kuehlewind.net
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/PfIQfA5MS-wna5hBOnr9Q2t9vtM>
Subject: Re: [DNSOP] Stuart and I had a discussion about the flow control issue in your DISCUSS (Mirja)
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: Thu, 02 Aug 2018 22:15:54 -0000

Hi Ted,

thanks for the quick reply and discussion.

> Am 02.08.2018 um 20:03 schrieb Ted Lemon <mellon@fugue.com>:
> 
> The issue is that turning on TCP_NODELAY doesn't actually do the right thing, nor does removing the delayed ACK timer.   Both of these are heuristic solutions that apply across the entire session, and have negative consequences (which is why they are on by default).
> 
> What we need is actually a very small thing, in a sense: the ability to say "I got the message, and will not be responding to it," so that the existing heuristic is satisfied in exactly the same way that sending a response satisfies it.
> 
> It's true that on a gigabit ethernet, just turning off the heuristics and sending whatever we have whenever we have it isn't likely to cause problems, but this stuff also has to work in home networks and over wide-area links and even low-bandwidth mobile links, where we can't assume that we have as much headroom as we do on a gigabit ethernet link.
> 
> We think that it is probably worth the IETF thinking about this problem, yet at the same time that's out of scope for the current work.   But not talking about the problem at all in the current work means that when the solution to this problem starts appearing in APIs, which seems likely, there will be no advice in the document about what the implementation should do.
> 
> What we propose to do therefore is to put in a paragraph that briefly mentions the issue and says "when unacknowledged messages are received, if an API is present to inform the TCP layer that no response will be sent, the responder SHOULD do so."   And then the text from the section as it was when you put the DISCUSS on it would go in an Appendix, so that it's clear what's going on.   We can then reference this section in the text telling the implementation what to do.
> 
> Will this satisfy your DISCUSS (assuming that we don't make mistakes in how we document this)?

Yes, please proceed and make the changes. I guess we can work on the wording if you have text and if needed but moving it to the appendix makes it less critical and is probably the right thing to do.

Thanks!
Mirja