Re: [PANRG] RG Last Call for draft-irtf-panrg-what-not-to-do-05
Theresa Enghardt <ietf@tenghardt.net> Fri, 10 January 2020 15:55 UTC
Return-Path: <ietf@tenghardt.net>
X-Original-To: panrg@ietfa.amsl.com
Delivered-To: panrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5E851208F2 for <panrg@ietfa.amsl.com>; Fri, 10 Jan 2020 07:55:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.297
X-Spam-Level:
X-Spam-Status: No, score=-4.297 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DOS_RCVD_IP_TWICE_B=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=tenghardt.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 lHogc_gcOzz0 for <panrg@ietfa.amsl.com>; Fri, 10 Jan 2020 07:54:57 -0800 (PST)
Received: from mail.hemio.de (mail.hemio.de [136.243.12.180]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 810A01208EF for <panrg@irtf.org>; Fri, 10 Jan 2020 07:54:57 -0800 (PST)
Received: from user.client.invalid (localhost [136.243.12.180]) by mail.hemio.de (Postfix) with ESMTPSA id 1E7B5B8; Fri, 10 Jan 2020 16:54:54 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tenghardt.net; s=20170414; t=1578671696; bh=1ds37jukL/ZK0oVfiKkNEDF7705XK3ud1I7iJjFnZ44=; h=From:Subject:To:Cc:References:Date:In-Reply-To:From; b=xddZl4pqzdci29bMPIaiBo4QAmMtwccWS9b8AgL0+2I3de+A/kMFXn0GL9CpQ0i4S qGPw53l9TN4EyXj6u/ZIY4bDG53iw/otMxy+6U8P3mS51UDS4Dh9HElE5Q/PuWYPYW sOxl19s4/2GtRvTj+lJEbL3wKPT+uSn568z0wFcdQ4/Yyqf4th/4Wx1Kf87AUmO5io V+5Z8uhTmuy5V3hQhfyP3HlfxulF3Bi5D0cKrG50MvkJPRQieNkgCXKj4lnKVJHVrd lLD+BDBH848CVx2P0YbldxBencMhMmv6GjWSQB9dsP0tv5kzOPtfLMFIauSCVbgolN HRBw6LxTaLyFw==
From: Theresa Enghardt <ietf@tenghardt.net>
To: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Cc: panrg-chairs@ietf.org, panrg@irtf.org, draft-irtf-panrg-what-not-to-do@ietf.org
References: <157656406442.24542.13576913839966234470.idtracker@ietfa.amsl.com> <CAFU7BAT+rhhOxf__HPTA6T83sOuwRophF1NJ7O_TemsP+dUEkw@mail.gmail.com> <069b0eb4-7ff1-f259-c36f-f432e72438d5@tenghardt.net> <CAKKJt-fNi780fhoyO2X6ScfQSEWMVjiT6YQ6d2rbBNZ2LKWTRw@mail.gmail.com>
Message-ID: <071b4d4d-d520-642b-e6d2-26de6c9daa0e@tenghardt.net>
Date: Fri, 10 Jan 2020 16:54:54 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <CAKKJt-fNi780fhoyO2X6ScfQSEWMVjiT6YQ6d2rbBNZ2LKWTRw@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------757AE7E051AC699D1256EEE7"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/panrg/ttxHxYa4rinMsDJgrqpPlzprLCo>
Subject: Re: [PANRG] RG Last Call for draft-irtf-panrg-what-not-to-do-05
X-BeenThere: panrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Path Aware Networking \(Proposed\) Research Group discussion list" <panrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/panrg>, <mailto:panrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/panrg/>
List-Post: <mailto:panrg@irtf.org>
List-Help: <mailto:panrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/panrg>, <mailto:panrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Fri, 10 Jan 2020 15:55:02 -0000
Hi, Thanks for the replies, Spencer and Michael, and thanks for the revision. This addresses all my comments. Best, Theresa On 10.01.20 01:08, Spencer Dawkins at IETF wrote: > Hi, Theresa, > > Thank you for your help with this document! Please see comments inline > below. > > Best, > > Spencer > > On Mon, Jan 6, 2020 at 6:22 AM Theresa Enghardt <ietf@tenghardt.net > <mailto:ietf@tenghardt.net>> wrote: > > Dear PANRG, > > I recently gave this document a thorough read from my perspective as a > researcher of Path Aware technologies. > > As I have not been around yet for the development of most of the > technologies listed in this document, I find its "lessons learned" > to be > quite a valuable resource. > So, again, thank you for writing it! > > To make this document even more accessible to researchers wanting to > learn from it, I have a few comments, see below. > > Once these are addressed, I think this document is ready for > publication. > > > Section 1: > > Maybe it's worth adding one paragraph with a short definition or > description of what we mean by Path Aware technologies here, e.g., at > the very beginning? > > > Done. > > > Section 2.1: > > What exactly does "Overcoming Entropy" mean? To me, entropy sounds > like > this is about the ecosystem of deployed hardware/software being too > diverse or chaotic, so the benefits of the proposed Path Aware > solution > do not outweigh the costs. But the rest of the paragraph also sounds > like this is about trying to solve a non-problem, or a problem with > insufficient motivation to solve it? Or is this both? > Maybe I just fail to capture all the nuances of the colloquial > American > English expression as a non-native English speaker. ;) > I think adding a clarifying sentence to make the lesson more explicit > would help here. > > > The intention was to say "insufficient motivation". I changed this > term to be "Justifying Deployment", which I hope is clearer. > > > Section 2.3: > > This is about multiple possible solutions to the same problem, right, > one being end-to-end and another being Path Aware? So is Path Aware > necessarily not end-to-end? This goes back to comment on > considering to > add a definition of Path Aware technologies to Section 1. > > > In addition to the new section 1.2, I tried to make this section clearer. > > > Section 2.7: > > What is the relationship between "Keeping Traffic on Router > Fast-paths" > and "Router Alert Options (RAO)"? Does RAO mean that the traffic > cannot > be fast-path anymore? This seems to be implicitly said here, but I > think > adding a sentence to make this explicit would help. > > > Good point. "Everybody" knows this, but enough people didn't know it > to justify the "Spherical Routers" session at IETF 104. > (https://datatracker.ietf.org/group/wgtlgo/meetings/). I added some > details here. > > > Section 2.9: > > The section heading says "Intermediate Devices Trusting > Endpoints", but > the text is about endpoints not relying on signals from intermediate > devices. This seems odd to me. > Maybe the headings of 2.8 and 2.9 should be swapped, because 2.8 > appears > to be about operators of intermediate devices not using signals from > endpoints and 2.9 seems to be about endpoints not using signals from > intermediate devices? > > > Well, THAT was embarrassing ... swapped now! > > > > Nit: "long term, term trust relatioship" -> duplicate "term" > > > Thanks for spotting this. > > > > Section 2.11: > > Does "Providing a new feature/signal [does not mean that that the > feature/signal will be used]" refer to the problem that a stack > implements the possibility to set, e.g., an additional variable, but > then an application using the stack fails to set this variable? Or is > this about the stack setting the variable, and then an application > would > have to interpret this variable, but fails to do so? Or both? > I guess here, in the first sentence, I am confused about what > exactly is > meant by "provide", "use", or "utilize" a signal - implementing > support > for setting a variable, actually setting the variable, or interpreting > the variable which has been previously set by someone else? > > > I wrote the text with a specific problem in mind, but you are pointing > to it being more general. I tried to make this clearer. > > > > I think another example of this problem is Section 5.8. > > Section 3: > > When categorizing the lessons as "invariant", "variable", or > "dragons", > I guess "dragons" is kept vague on purpose. Still, I'm wondering if we > could make this a bit more clear - Does "dragons" mean that we don't > know if the lesson is invariant or variable, or that we don't want to > comment on it, or that the problem is open-ended? > Maybe adding one more sentence here makes sense, especially for > non-native English speakers who might not be familiar with the phrase > "here be dragons". > > > Rephrased without dragons. :-) > > > > In the last paragraph, I fail to parse the following sentence: "[TAPS] > will justify consideration of the current state of play for Path Aware > Networking proposals for some time to come" - Does that mean that we > think TAPS might change this lesson, thus, the lesson should be > re-evaluated after some time? > > > Yeah, I failed to parse it, too. A long time ago, it made sense to me. > Rephrased. > > > > Section 5.3: > > "[…] In these cases, a sender cannot easily determine an appropriate > initial sending rate, given the lack of information about the path" > What does "these" refer to here? Isn't this a general problem? > > > I took Michael's suggestion to the limit - I deleted the reference to > DCCP QuickStart, because it wasn't adding any information to the > lesson. But too your larger point ... > > I agree this is a general problem, but the contribution I was > analyzing was a single mechanism exhibiting the problem. I rephrased > without "in these cases" - I don't think it added anything, but seemed > to be TRYING to add something. > > > > "One challenge is synchronization of information between different > packets […]" > What does synchronization mean here? That a router signals for two > flows > that there's capacity? > > > I took Michael's suggestion here as well. > > > > Section 5.5: > > "[…] somehow TCP could be signaled when that link returned to service" > Should this be "somehow TCP could signal when the link returned to > service"? > > > This is about waking up the TCP that's been sitting quietly, because > retransmitting over a known-out-of-service-interface doesn't help. > > The problem was that I was using the passive voice. Now it's "somehow > something along the path could signal TCP", which is about as much > clarity as we had in initial discussions about TRIGTRAN :D ... > > > Section 5.6: > > "work began on a protocol that would provide the same benefits for > multihomed IPv6 sites […]" > Same benefits as IPv4 multihomed sites? The previous sentence talks > about problems, not benefits. > > > This was phrased badly. Changed to "provide multihoming for IPv6 sites". > > > Is the sentence starting with "In addition, the usual concerns about > firewalls […]" missing a verb? > > Section 5.7.1: > > "One reason for the non-deployment of NSIS is the usage of the > IPv4 and IPv6 > Router Alert Option (RAO) to allow for an efficient interception of > those path-coupled signaling messages" > As someone not familiar with RAO, this sentence reads a bit > confusing to > me - it was not deployed because it is efficient? > > > This is the same issue you tagged in 2.7, which isn't surprising > because 2.7 is a lesson that references this contribution. Added > details here, too. > > > > "End-to-end signaling approaches were considered problematic […]" > So is NSIS an end-to-end signaling approach? I thought Path Aware > technologies were not end-to-end (Section 2.3)? To me, end-to-end by > default means "end host to end host", without considering any > intermediate device, but I think this paragraph means something > else by it. > I think adding a sentence explaining who the "end to end" is here > would > help. > > > This contribution expanded beyond NSIS a bit here - contributions in > Section 5 should be focused on a specific technology. I was able to > replace most occurrences of "end-to-end" referring to NSIS in this > section, which avoided the problem. > > > Best, > Theresa > >
- [PANRG] RG Last Call for draft-irtf-panrg-what-no… Jen Linkova
- Re: [PANRG] RG Last Call for draft-irtf-panrg-wha… Theresa Enghardt
- Re: [PANRG] RG Last Call for draft-irtf-panrg-wha… Scharf, Michael
- Re: [PANRG] RG Last Call for draft-irtf-panrg-wha… Spencer Dawkins at IETF
- Re: [PANRG] RG Last Call for draft-irtf-panrg-wha… Spencer Dawkins at IETF
- Re: [PANRG] RG Last Call for draft-irtf-panrg-wha… Theresa Enghardt
- Re: [PANRG] RG Last Call for draft-irtf-panrg-wha… Spencer Dawkins at IETF