Re: [DNSOP] Genart telechat review of draft-ietf-dnsop-session-signal-11

"Joel M. Halpern" <jmh@joelhalpern.com> Thu, 05 July 2018 22:41 UTC

Return-Path: <jmh@joelhalpern.com>
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 6A28C130DD9; Thu, 5 Jul 2018 15:41:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 THbYH6_WlSXl; Thu, 5 Jul 2018 15:41:17 -0700 (PDT)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 0EF1012777C; Thu, 5 Jul 2018 15:41:17 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id EB49B8A08BA; Thu, 5 Jul 2018 15:41:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1530830476; bh=cLlk75XZ59yQVadVoXzOn0h9rU/6DK9+zf8E0fIAgdY=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=LRHPxAYmPQKziuG/Edmdp9G1PjmuoudoWRYwQw1pH5rXtOUDkKvDD27qtgt6jp5aG qTflClNx9Kppj2njqULm6GhTgXuZitcI82nvVQvuOwzGYWtX4UNq7MWIiobGUqaFB9 /zt0kRbxg5PzE9ZyznzPSFmxEQK8bxmbeKaT3hIc=
X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net
Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 2BC548A08B7; Thu, 5 Jul 2018 15:41:16 -0700 (PDT)
To: Ted Lemon <mellon@fugue.com>
Cc: General area reviewing team <gen-art@ietf.org>, draft-ietf-dnsop-session-signal.all@ietf.org, dnsop WG <dnsop@ietf.org>, ietf <ietf@ietf.org>
References: <153082732415.26353.11898401544902479901@ietfa.amsl.com> <CAPt1N1m32w=74pA736wbbJGj3D-gcW93+DYcNfAp-M0vfov0dA@mail.gmail.com> <99295cd6-d9f0-a60d-381b-8d57658ed701@joelhalpern.com> <CAPt1N1kONQdS7oO5LGL+te0mBA+sLUGFpPwZZCBJrACzN1S1LA@mail.gmail.com>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <bb5a5e01-fdd4-1516-9815-61bb3444ff21@joelhalpern.com>
Date: Thu, 5 Jul 2018 18:41:15 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0
MIME-Version: 1.0
In-Reply-To: <CAPt1N1kONQdS7oO5LGL+te0mBA+sLUGFpPwZZCBJrACzN1S1LA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/GxmsAL-Ybkh1cWVOh_3xxLG4pUM>
Subject: Re: [DNSOP] Genart telechat review of draft-ietf-dnsop-session-signal-11
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.26
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, 05 Jul 2018 22:41:20 -0000

I will try to elaborate on the problems below.
Joel

On 7/5/18 6:28 PM, Ted Lemon wrote:
> The text also says that it's fine to blindly forward DSO messages if the 
> middlebox isn't modifying the stream, e.g. in a NAT.   It really is 
> quite clear on that point.   The case where it's bad to blindly forward 
> DSO messages is when there is no stream that's the same stream on both 
> sides of the middlebox.   In this case, it really is a MUST NOT.   What 
> reader's need are you trying to address here?   Who is going to be 
> reading the document and is going to be confused about this?

The text in 5.3.1 says that middleboxes MUST NOT do blind forwarding. 
Regarding the further text, given the wroding it is actually very hard 
to understand whether that is supposed to be an exception to the MUST 
NOT, or a description of some other case.
Even if the further text covers a lot of cases, the MUST NOT is 
presumably describing a situation that existing middleboxes do find 
themselves in.  I do think it is fair to ask for an explanation of why 
existing middleboxes that do fall into the relevant case will do the 
right thing.  Are there no such existing middleboxes (seems unlikely)? 
Do such existing middleboxes already for some reason do things that will 
prevent the blind forwarding (that would be great, just explain it)?  Or 
is it actually okay that existing middleboxes violate the MUST NOT (in 
which case, why is it a MUST NOT)?

> 
> As far as I can tell, the text on Nagle is correct, and you haven't 
> pointed to an error.  You appear to have said that you want it to place 
> a new requirement on the sender to respond within the 200ms DA window.   
> This is unnecessary.   What am I missing?

What the text in 5.4 actually says is that magically the data will be 
piggybacked.   It treats it as if there are only two cases, DSO requests 
that generate a response that automatically combine the two, and DSO 
requests that do not generate responses.  The reality is that there are 
three cases.
1) DSO requests that get responses and are responded fast enough to get 
nagle behavior and the resulting performance benefit,
2) DSO requests that get responses and for whatever reason are responded 
to more slowly
3) DSO requests that do not generate responses.

The fix, it seems to me is to make two small changes:
A) In the first sentence of 5.4, change "for DSO requests that generate 
a response" to "for DSO requests that generate a response and are 
responded to in a sufficiently timely fashion"
B) At the start of the second paragraph, change "For DSO requests that 
do not generate a response" to "For DSO requests that do not generate a 
response or those that generate a response but are not responded to in a 
sufficiently timely fashion"

This has the side benefit of making clear to implementors that ensuring 
responsiveness of their implementation will improve the network utilization.