From nobody Tue Aug 11 15:53:16 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C9C73A0861; Tue, 11 Aug 2020 15:53:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.047 X-Spam-Level: X-Spam-Status: No, score=-3.047 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.949, 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=gmail.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 yR6I6M6OUvmn; Tue, 11 Aug 2020 15:53:14 -0700 (PDT) Received: from mail-pg1-x534.google.com (mail-pg1-x534.google.com [IPv6:2607:f8b0:4864:20::534]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E489F3A0D3B; Tue, 11 Aug 2020 15:53:13 -0700 (PDT) Received: by mail-pg1-x534.google.com with SMTP id 128so18249pgd.5; Tue, 11 Aug 2020 15:53:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=s0a967FB2wgbsQ8cEiLQzpMq7pqv126tj+OlwtXwSLo=; b=YD6EImg5eiOGTvVIcTifbLM3VERCL1cjeT2EoJNTszfDoOSia4KxEVdc62MNDpCxV3 42EUPBwOGVSOettOLr4KFjpxclnLHrOrw8BOi6jRAvyGCCxAMWt/mCFhu5uySyP0lXEk JSwT1xjuBekQNlvds2FfuiLu95YXIZqPv/yhwdjPDFEWrlwshSXD2vcnMFaGZs9Ip3wB 5lxHDQMP5HB5q7KwztAuFXkUaJJSIEmvPo9WAeJ8Z8YQQn9NzilJjUxBXi2FYmM4ZavX AQn4lAZ691/K6Ns2mIyzsO8kwJ3vZgoQK1Ze3oTlUSvDUsh/sJXV5XDqJlezg1GZPpRL kgZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=s0a967FB2wgbsQ8cEiLQzpMq7pqv126tj+OlwtXwSLo=; b=Mv2WFpbHOVkq3gVpPIpxHS16p25Cv045KXZYd3YJWQn8NL2P3j7dhrPxwOFQs9Zs8s 2cPGEabg55ur7q3JG6l/0IUPtFqAJvii9QvpQC5FrvRGfR8+unMhwhGhJNumH23VXPMD j9t9UjzqVJdwPutE82Yb0RowS4kHpyuJcTKk5EyPD22hl5GuaJ5t20i6m38lu5natR0J rhj6g39mDlgfHN5rlZYoJH4i5d+eBHQHps47EgI3kl99k229F1AyAJk45HK/1m06Wab2 SmlY7vokajFmV3ufzCou1+Xauuawho8JGN3ecq7lKHPjilpKxKfQU0Ds/kXTyaBQ4xZ3 cSmg== X-Gm-Message-State: AOAM533icR38w0zwX1zRH8ytQhNznxKsO6Czi2qgrGQKNGmgS5uZFqzu QtvQmZ0NDEltctwTBU3rUxRjKPTAdTU= X-Google-Smtp-Source: ABdhPJwxOuVk+4c5Zt7XEX0fg9PzcNG9D+5KnvhlGUPLuOAuU+sdAUJR54n4nU+TK3z4iQV36Iq+5g== X-Received: by 2002:aa7:9390:: with SMTP id t16mr8035116pfe.311.1597186393052; Tue, 11 Aug 2020 15:53:13 -0700 (PDT) Received: from [192.168.178.20] ([151.210.139.192]) by smtp.gmail.com with ESMTPSA id 202sm131944pfy.6.2020.08.11.15.53.10 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Aug 2020 15:53:12 -0700 (PDT) To: Lars Eggert References: <6F47F8A6-CE4D-46B4-852C-702B9B8A5724@eggert.org> Cc: architecture-discuss@ietf.org From: Brian E Carpenter Message-ID: Date: Wed, 12 Aug 2020 10:53:09 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <6F47F8A6-CE4D-46B4-852C-702B9B8A5724@eggert.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [arch-d] A Public Option for the Core X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2020 22:53:15 -0000 (Bcc to the IETF list and Cc to the architecture-discuss list) Thanks for circulating this. On 12-Aug-20 06:50, Lars Eggert wrote: > Hi, >=20 > Scott Shenker et al. just presented a pretty thought-provoking "public = option" for the Internet's core backbone at SIGCOMM: https://dl.acm.org/d= oi/abs/10.1145/3387514.3405875 Hmm. "The technical Internet community has long embraced the notion that the Internet should be application-neutral; that notion later became known as network neutrality (a term coined in [57])." I dispute that assertion. "Network neutrality" is a slippery term, but certainly there is antipathy between some interpretations of it and RFC2474 and other QoS technologies. "We choose instead to initially create the POC=E2=80=99s backbone network= out of a set of leased lines, and use the interconnections to one or more ISPs as a fallback if the POC=E2=80=99s backbone does not have sufficient= connectivity." That sounds like a fairly accurate description of the Internet in about 1995, when ISPs had emerged but the de facto backbone was still largely non-profit and/or settlement-free. And note that non-profit transit networks existed then, and actively migrated to a for-profit model after about 1998. See https://en.wikipedia.org/wiki/EBONE for an example. So I think history would likely repeat itself if this proposal was adopted. Maybe it's time to update https://tools.ietf.org/html/draft-carpenter-met= rics Reactions to that draft from the then major transit ISPs were interesting= ly negative. Brian >=20 > If you scroll down (or go to https://dl.acm.org/doi/abs/10.1145/3387514= =2E3405875#sec-supp), his recorded talk video gives a high-level overview= =2E >=20 > (PDF and video *should* be open access and work for me, but you never k= now with the ACM...) >=20 > Lars >=20 From nobody Wed Aug 12 04:52:29 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBB783A1246 for ; Wed, 12 Aug 2020 04:52:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.847 X-Spam-Level: X-Spam-Status: No, score=-2.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.949, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 4n75A63-dPnf for ; Wed, 12 Aug 2020 04:52:18 -0700 (PDT) Received: from know-smtprelay-omc-4.server.virginmedia.net (know-smtprelay-omc-4.server.virginmedia.net [80.0.253.68]) (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 07FDA3A1267 for ; Wed, 12 Aug 2020 04:52:17 -0700 (PDT) Received: from [192.168.0.16] ([80.0.21.207]) by cmsmtp with ESMTPA id 5pIkkh4l91XIf5pIkkcUzv; Wed, 12 Aug 2020 12:52:15 +0100 X-Originating-IP: [80.0.21.207] X-Authenticated-User: john.s.grant@ntlworld.com X-Spam: 0 X-Authority: v=2.3 cv=d+PbNyrE c=1 sm=1 tr=0 a=ZJrsehNnOEfaj4OPFeyFaA==:117 a=ZJrsehNnOEfaj4OPFeyFaA==:17 a=IkcTkHD0fZMA:10 a=le6d79QuAAAA:8 a=i8NGiMk4ZtaTVKRuoSEA:9 a=QEXdDO2ut3YA:10 a=QbAMNLWdp4a7deKPGBBn:22 To: architecture-discuss@ietf.org References: <6F47F8A6-CE4D-46B4-852C-702B9B8A5724@eggert.org> From: John Grant Message-ID: Date: Wed, 12 Aug 2020 12:52:19 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB X-CMAE-Envelope: MS4wfOSwTRePV9NQb6I0U9XlHAUdho3QwudMdE/agAryHZ3hesQy+ov8cFHXlfzIrWxhqs9Zw5eDo3hHbaZ48I4z4nINZpOgGL1XZK8JdCkwOlro5PXVtC4o zJrxB5v41mIb1tqFLR644mGpEgZquAOQfToEx/LtAvl0VkMVQau3ePhR Archived-At: Subject: Re: [arch-d] A Public Option for the Core X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2020 11:52:27 -0000 On 11/08/2020 23:53, Brian E Carpenter wrote: > "The technical Internet community has long embraced the notion > that the Internet should be application-neutral; that notion later > became known as network neutrality (a term coined in [57])." It isn't application-neutral, though; the service it provides is much better suited to applications that don't care about time, so can easily tolerate queuing delays and retransmission of lost packets. It's fine for fetching web pages, or downloading media files and playing them out locally, but the service we get with video conferencing etc can be pretty rubbish. -- John Grant Nine Tiles, Cambridge, England +44 1223 862599 and +44 1223 511455 http://www.ninetiles.com From nobody Wed Aug 12 05:08:31 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBD9D3A122E for ; Wed, 12 Aug 2020 05:08:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 oHzRRiI0ER80 for ; Wed, 12 Aug 2020 05:08:27 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [204.42.254.5]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77EEB3A0F86 for ; Wed, 12 Aug 2020 05:08:27 -0700 (PDT) Received: from [10.0.0.129] (c-68-49-104-93.hsd1.mi.comcast.net [68.49.104.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by puck.nether.net (Postfix) with ESMTPSA id E3C505400FC; Wed, 12 Aug 2020 08:08:24 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Jared Mauch In-Reply-To: Date: Wed, 12 Aug 2020 08:08:23 -0400 Cc: Lars Eggert , architecture-discuss@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <5AA852D6-585E-48A6-975D-D45A9B8D551E@puck.nether.net> References: <6F47F8A6-CE4D-46B4-852C-702B9B8A5724@eggert.org> To: Brian E Carpenter X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [arch-d] A Public Option for the Core X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2020 12:08:29 -0000 > On Aug 11, 2020, at 6:53 PM, Brian E Carpenter = wrote: >=20 > Maybe it's time to update = https://tools.ietf.org/html/draft-carpenter-metrics > Reactions to that draft from the then major transit ISPs were = interestingly > negative. Looking at this 20+ years in the future, there=E2=80=99s some = interesting dynamics going on, which many of us are interested in for = the centralization discussions that are ongoing. There=E2=80=99s the usual last-mile vs major city dynamics at play when = it comes to cost. Construction is expensive, but the fiber isn=E2=80=99t = the expensive bit, it=E2=80=99s the dirt movement that costs quite a = bit. With more traffic traversing private backbones vs public ones, there is = also a lack of measurements that are feasible. You can=E2=80=99t = measure from within the Akamai backbone as it=E2=80=99s our private = network. Public networks, you can utilize things like RIPE Atlas or = similar, but there are significant limitations to it. Cellular network = measurement either require some applications at scale that run in the = background, but the various charging cultures that exist globally around = voice/sms/data pose challenges. Public sources of routing data are generally available from the major = backbones (route-views, ripe ris, etc) but not for the private clouds = (Microsoft, google, amazon, ovh, ibm/oracle). =20 The costs of running these backbones are often much lower than public = and allow us to optimize for our business use cases in a way a public = network can=E2=80=99t solve for everyone. This is in part a natural economic progression. Why cloud computing? = Because power is expensive at my house, so I put data on a VM somewhere = else for $5/mo. If I put it in a colocation facility I may pay up to = 2500/mo for colocation plus the server and bandwidth costs, plus then I = have to deal with swapping failed disk vs $5/mo as a service. We don=E2=80=99t often talk about these economic factors that drive the = shift, but look at the architecture. It=E2=80=99s not devoid of = economic costs or impacts. Someone is paying for all that compute at = Google/Facebook and power, it=E2=80=99s often not a direct expense we = see, like we don=E2=80=99t see the credit card fees that merchants pay. Why are things like neutral IX not successful? It requires people to = sacrifice and value their time very low. It=E2=80=99s not a surprise = that some of the larger IX points operate their own networks to extend = their reach (their own private backbones). Not everyone can = interconnect at the speeds necessary at the neighborhood level, there = must be some aggregation and it may not be close. My personal telecom expenses are relatively fixed over time, but the = bits/second tend to go up over time. I am hoping speeds continue to go up, costs go down and the risk of = centralization of the network follows the same risk evaluations that = people have done in 2020 with their supply chain risks and how they were = often centralized. Diversity is helpful, but if we are always driving = for the lowest cost as a consumer, it will take a few shocks to restore = that diversity and supply chain depth and balance the ecosystem. - jared= From nobody Wed Aug 12 06:19:36 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44CB13A1285 for ; Wed, 12 Aug 2020 06:19:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=icsi-berkeley-edu.20150623.gappssmtp.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 4SQfja7zMuqR for ; Wed, 12 Aug 2020 06:19:33 -0700 (PDT) Received: from mail-pf1-x443.google.com (mail-pf1-x443.google.com [IPv6:2607:f8b0:4864:20::443]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95AFE3A1273 for ; Wed, 12 Aug 2020 06:19:33 -0700 (PDT) Received: by mail-pf1-x443.google.com with SMTP id k18so1017125pfp.7 for ; Wed, 12 Aug 2020 06:19:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icsi-berkeley-edu.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=4NwXI8Sk5yTJYCaMOVJvd9YHi+W9SrT4JQ7sy3og0i8=; b=zNvhZ/9ENfeBa3vXSC78TkVx85jNGiOH5GIBazwuBFz9WUIq5lQF2XStWjpWvRqnNz CAYlLFXYCKOC1QLP3kgZhmBfxGKsG8qkghHRtWvBRi8jrJ3HF+PFkA+ejZtyJlidlP2D qwIAxFOsOjEfcvZdYruE7oXL0X9T5QvYlaKMvmppAZo+QQGUbqtS+716yASwahSa6uQH F8gh9kwMNxCdCWeU8B6pv2JsKcJsDE7zj2sRjNVo2Ul2Cgh7q9AvAmzKjy4U9Caw0Xux m30VqMRyPnNI6ume/+0GJSsg1fIaFAxjWzsTiajN49HkPgOBSOFIpOan4p3QBUPdOUZg w6bw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=4NwXI8Sk5yTJYCaMOVJvd9YHi+W9SrT4JQ7sy3og0i8=; b=N/de8bnaVVB65PBPXQOWOQL+ztLZB8X7HZe1rK3Y2XGplrDxmxMb/1b56776z2btWo rDSON8N4zsozl39B14DAxRyzzzY4i4gkfg4Nk0Yki5Tp55PD/FXVph8Q4d4dweDeEBZp Yc4Pb+K7c6fv/d2HmaNFavyqcLe7GhKZMhuTL1KprkWYqxekAkP7x7BRAQjb3sbG8Ixg ez6zje6qObOIeDjHYqTl1NMmsZqNeUqY8WoLuFRq66Z+z60AUWCPplM1vghZsRUbXvPe QBjAMFMELhQnI02owBiY+9TiZRUXKXAF8n+VUAIbjrDzcEEkMbMJ+TFiNNMGY0xhy1m6 kcSA== X-Gm-Message-State: AOAM532Lzp3KrTKMX6yY50D2Uj1c7i3as0mMFP+3+T2VxinWSpfsOJZ2 Jfy7saJD29XiEDjqkimuVuuaOg== X-Google-Smtp-Source: ABdhPJyenAUfnRN6O3UHUpiyhIqLWl3qwp/Rw69fBzYoklev3j/3pOmiJsFeJR9XGAwk9H0YYjw7Qw== X-Received: by 2002:a63:517:: with SMTP id 23mr4907521pgf.377.1597238372866; Wed, 12 Aug 2020 06:19:32 -0700 (PDT) Received: from [10.0.1.5] (135-180-3-160.static.sonic.net. [135.180.3.160]) by smtp.gmail.com with ESMTPSA id g8sm2421583pgr.70.2020.08.12.06.19.31 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Aug 2020 06:19:32 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Scott Shenker In-Reply-To: Date: Wed, 12 Aug 2020 06:19:30 -0700 Cc: lars@eggert.org, architecture-discuss@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <47EBBED2-2FE9-42B3-BD37-C81DA84A42F8@icsi.berkeley.edu> References: <6F47F8A6-CE4D-46B4-852C-702B9B8A5724@eggert.org> To: Brian E Carpenter X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [arch-d] A Public Option for the Core X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2020 13:19:35 -0000 > On Aug 11, 2020, at 3:53 PM, Brian E Carpenter = wrote: >=20 > (Bcc to the IETF list and Cc to the architecture-discuss list) >=20 > Thanks for circulating this. >=20 > On 12-Aug-20 06:50, Lars Eggert wrote: >> Hi, >>=20 >> Scott Shenker et al. just presented a pretty thought-provoking = "public option" for the Internet's core backbone at SIGCOMM: = https://dl.acm.org/doi/abs/10.1145/3387514.3405875 >=20 > Hmm. >=20 > "The technical Internet community has long embraced the notion > that the Internet should be application-neutral; that notion later > became known as network neutrality (a term coined in [57])." >=20 > I dispute that assertion. "Network neutrality" is a slippery term, > but certainly there is antipathy between some interpretations of it > and RFC2474 and other QoS technologies. We did not mean to imply that the two are notions are identical, and = indeed we discuss the no-QoS interpretation of network neutrality later = in the paper. However, I think it is undeniable that conceptually the = notion of network neutrality is the descendant of = application-neutrality, which was the intent of this sentence. I = apologize if our writing was unclear. >=20 > "We choose instead to initially create the POC=E2=80=99s backbone = network out > of a set of leased lines, and use the interconnections to one or more > ISPs as a fallback if the POC=E2=80=99s backbone does not have = sufficient > connectivity." >=20 > That sounds like a fairly accurate description of the Internet in > about 1995, when ISPs had emerged but the de facto backbone was still > largely non-profit and/or settlement-free. And note that non-profit > transit networks existed then, and actively migrated to a for-profit > model after about 1998. See https://en.wikipedia.org/wiki/EBONE for > an example. >=20 > So I think history would likely repeat itself if this proposal was > adopted. The world of today is very different from what it was in 1995, = particularly in terms of the market forces at work. We discuss our = reasoning for why our proposal might become a reality later in the paper = (in a section called =E2=80=9CAre We Crazy?=E2=80=9D), and I would be = interested in your reaction. Do you think the market forces we identify = might lead to a different result now? More generally, as an academic working on issues related to the = Internet, I view it as my mission to identify designs and paradigms that = would make for a better Internet, and to explore whether there are = plausible paths to such eventualities. We recognize that our proposed = change is a long-shot. In fact, almost all attempts to effect = large-scale changes in the Internet (whether its design or its = structure) are likely to fail. My responsibility as a researcher is to = not let that stop me, and my mission as a member of the Internet = community is to try to make such changes happen, despite great odds. I = hope that people on this list and elsewhere read this paper in that = spirit. =E2=80=94Scott >=20 > Maybe it's time to update = https://tools.ietf.org/html/draft-carpenter-metrics > Reactions to that draft from the then major transit ISPs were = interestingly > negative. >=20 > Brian >=20 >>=20 >> If you scroll down (or go to = https://dl.acm.org/doi/abs/10.1145/3387514.3405875#sec-supp), his = recorded talk video gives a high-level overview. >>=20 >> (PDF and video *should* be open access and work for me, but you never = know with the ACM...) >>=20 >> Lars >>=20 >=20 > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss From nobody Wed Aug 12 06:20:17 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1FA63A128F for ; Wed, 12 Aug 2020 06:20:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.117 X-Spam-Level: X-Spam-Status: No, score=-1.117 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] 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 nftKvP8mNrZt for ; Wed, 12 Aug 2020 06:20:13 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FB493A1285 for ; Wed, 12 Aug 2020 06:20:13 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id B29B9548019; Wed, 12 Aug 2020 15:20:07 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id AA5FF440059; Wed, 12 Aug 2020 15:20:07 +0200 (CEST) Date: Wed, 12 Aug 2020 15:20:07 +0200 From: Toerless Eckert To: Jared Mauch Cc: Brian E Carpenter , architecture-discuss@ietf.org Message-ID: <20200812132007.GO62842@faui48f.informatik.uni-erlangen.de> References: <6F47F8A6-CE4D-46B4-852C-702B9B8A5724@eggert.org> <5AA852D6-585E-48A6-975D-D45A9B8D551E@puck.nether.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5AA852D6-585E-48A6-975D-D45A9B8D551E@puck.nether.net> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [arch-d] A Public Option for the Core X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2020 13:20:16 -0000 Inline On Wed, Aug 12, 2020 at 08:08:23AM -0400, Jared Mauch wrote: > > On Aug 11, 2020, at 6:53 PM, Brian E Carpenter wrote: > > > > Maybe it's time to update https://tools.ietf.org/html/draft-carpenter-metrics > > Reactions to that draft from the then major transit ISPs were interestingly > > negative. > > Looking at this 20+ years in the future, there???s some interesting dynamics going on, which many of us are interested in for the centralization discussions that are ongoing. > > There???s the usual last-mile vs major city dynamics at play when it comes to cost. Construction is expensive, but the fiber isn???t the expensive bit, it???s the dirt movement that costs quite a bit. > > With more traffic traversing private backbones vs public ones, there is also a lack of measurements that are feasible. You can???t measure from within the Akamai backbone as it???s our private network. Public networks, you can utilize things like RIPE Atlas or similar, but there are significant limitations to it. Cellular network measurement either require some applications at scale that run in the background, but the various charging cultures that exist globally around voice/sms/data pose challenges. At the same time, operators try to make money by selling data about their customers including amounts of traffic or even location on a mobile network. > Public sources of routing data are generally available from the major backbones (route-views, ripe ris, etc) but not for the private clouds (Microsoft, google, amazon, ovh, ibm/oracle). > > The costs of running these backbones are often much lower than public and allow us to optimize for our business use cases in a way a public network can???t solve for everyone. Indeed, in many cases a lot of business including that from Akamai is built on expoiting value from underlying infrastructure by layering on top of it and creating a service that sells at a higher margin. Often by market vertical monopolization financed for years on loss by large investments to grow and replace competition before the service breaks even. Aka: Internet technologies have enabled a food chain not unlike the one we see in biology where arguably the human species is on top. And like the humans, one can argue that companies on the top of the vertical internet food chain also destroy the eco system they exploit. The Internet economy is quite the darwinistic playground. Lets see how long it will take to realize the need for an evolution beyond that. Like wee did for most other infrastructures and aspects of economy. > This is in part a natural economic progression. Why cloud computing? Because power is expensive at my house, so I put data on a VM somewhere else for $5/mo. If I put it in a colocation facility I may pay up to 2500/mo for colocation plus the server and bandwidth costs, plus then I have to deal with swapping failed disk vs $5/mo as a service. > > We don???t often talk about these economic factors that drive the shift, but look at the architecture. It???s not devoid of economic costs or impacts. Someone is paying for all that compute at Google/Facebook and power, it???s often not a direct expense we see, like we don???t see the credit card fees that merchants pay. If the "We" means IETF, i agree, and it would be lovely if we would have more of an economic discussion track. > Why are things like neutral IX not successful? It requires people to sacrifice and value their time very low. It???s not a surprise that some of the larger IX points operate their own networks to extend their reach (their own private backbones). Not everyone can interconnect at the speeds necessary at the neighborhood level, there must be some aggregation and it may not be close. Wondering: I am sure you can study how to build roads and highways somewhere. Is there any public study course for these core aspects of the Internet economy ? Is there even enough public data to build such course work ? > My personal telecom expenses are relatively fixed over time, but the bits/second tend to go up over time. > > I am hoping speeds continue to go up, costs go down and the risk of centralization of the network follows the same risk evaluations that people have done in 2020 with their supply chain risks and how they were often centralized. Diversity is helpful, but if we are always driving for the lowest cost as a consumer, it will take a few shocks to restore that diversity and supply chain depth and balance the ecosystem. I think we already have good steps beyond network darwinism on crucial points in some countries. Such as the last-mile subscriber ownership model to create more LMA competition and even diversity. And we see a lot of darwinism to counter such trends, such as the history of DSL vectoring to further monopolization. I am more excited/worried about access than core, and when i am worried about core it is more about the IMHO complete unkown best balance between transparency and lawfulness. The old Internet meme "complying to all regulations by offering services from another country" is still a core unresolved problem statement, and a POC from a single country doesn't change that. Toerless > > - jared > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss -- --- tte@cs.fau.de From nobody Wed Aug 12 08:41:26 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04ADA3A11E8 for ; Wed, 12 Aug 2020 08:41:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.849 X-Spam-Level: X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.949, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham 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 OFL6ARIQ_DOK for ; Wed, 12 Aug 2020 08:41:23 -0700 (PDT) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 5311B3A11BE for ; Wed, 12 Aug 2020 08:41:23 -0700 (PDT) Received: from xse105.mail2web.com ([66.113.196.105] helo=xse.mail2web.com) by mx168.antispamcloud.com with esmtp (Exim 4.92) (envelope-from ) id 1k5ssI-000EgH-RZ for architecture-discuss@ietf.org; Wed, 12 Aug 2020 17:41:17 +0200 Received: from xsmtp21.mail2web.com (unknown [10.100.68.60]) by xse.mail2web.com (Postfix) with ESMTPS id 4BRYjL2X02z429m for ; Wed, 12 Aug 2020 08:37:10 -0700 (PDT) Received: from [10.5.2.18] (helo=xmail08.myhosting.com) by xsmtp21.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1k5soQ-0003Er-85 for architecture-discuss@ietf.org; Wed, 12 Aug 2020 08:37:10 -0700 Received: (qmail 17318 invoked from network); 12 Aug 2020 15:44:24 -0000 Received: from unknown (HELO [192.168.1.107]) (Authenticated-user:_huitema@huitema.net@[172.58.35.190]) (envelope-sender ) by xmail08.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 12 Aug 2020 15:44:24 -0000 To: Scott Shenker , Brian E Carpenter Cc: architecture-discuss@ietf.org References: <6F47F8A6-CE4D-46B4-852C-702B9B8A5724@eggert.org> <47EBBED2-2FE9-42B3-BD37-C81DA84A42F8@icsi.berkeley.edu> From: Christian Huitema Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mDMEXtavGxYJKwYBBAHaRw8BAQdA1ou9A5MHTP9N3jfsWzlDZ+jPnQkusmc7sfLmWVz1Rmu0 J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PoiWBBMWCAA+FiEEw3G4 Nwi4QEpAAXUUELAmqKBYtJQFAl7WrxsCGwMFCQlmAYAFCwkIBwIGFQoJCAsCBBYCAwECHgEC F4AACgkQELAmqKBYtJQbMwD/ebj/qnSbthC/5kD5DxZ/Ip0CGJw5QBz/+fJp3R8iAlsBAMjK r2tmyWyJz0CUkVG24WaR5EAJDvgwDv8h22U6QVkAuDgEXtavGxIKKwYBBAGXVQEFAQEHQJoM 6MUAIqpoqdCIiACiEynZf7nlJg2Eu0pXIhbUGONdAwEIB4h+BBgWCAAmFiEEw3G4Nwi4QEpA AXUUELAmqKBYtJQFAl7WrxsCGwwFCQlmAYAACgkQELAmqKBYtJRm2wD7BzeK5gEXSmBcBf0j BYdSaJcXNzx4yPLbP4GnUMAyl2cBAJzcsR4RkwO4dCRqM9CHpVJCwHtbUDJaa55//E0kp+gH Message-ID: <3702d78d-87d9-ac56-6a45-4aa8a0483b5b@huitema.net> Date: Wed, 12 Aug 2020 08:37:13 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <47EBBED2-2FE9-42B3-BD37-C81DA84A42F8@icsi.berkeley.edu> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US X-Originating-IP: 66.113.196.105 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 66.113.196.105/32 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.196.105/32@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.15) X-Recommended-Action: accept X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0X2OOYwfFINEXkW0Te3GMuqpSDasLI4SayDByyq9LIhVUZbR67CQ7/vm /hHDJU4RXkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDsYLBcJLyHnVrULITPs15U6ts NHuRxlWqWR9fNqLY1ai4Dcwf+CZK8NXgy3In+fX7STxj9vMdY81nbjTbhBHxwVO05s+oip5EC/YK rMQ9+O9t+TYaqvvx766D6vBkj4PutP0Dzal8myJ8vVhoWnSKP2MRQY4sL7fGBhvCp6oW0F28pnvZ XWSe7jV34Pxn0vH1Lz/y+awqhw7CmTPsWtYsCV/oEQh3zFZ7AJOfdc5NLopVCPmS+MVojfDUugvn Zl+jhHQOLtWk4clq0P6Ltvr/5Zl+BJt+8hYKwgejR0Z9YPn97p3CKmEi95YYeXPNWMiahaC2TJpF rGrq1WX76kTmg5w7R2/M+XaT5BLifEp8KpWu41J1t4cteGI4vH6PuMQp0kaOEXLuWd+6zLg4wp8u XxPcpGyeyPXKNTABBN67jV7JvFCbAD7w3FUirQwmJIqD2OUMeHyTpNN0eXybX/w7/3ZCM0u5uBlK VwmNWN494pWaZ30sdVozPGNttYaP6Q9/2E4JvzZwv3PGBEOc6AcTtNsXDz8en/EE5Mu5lEzai0nS Xv2CmOR0Wfx2I86r3bYPVD1XJsdUC/l4in++svwYCrDy/+Q1ZTVfbcn/dRwQvYbymNgFzWRkuRvd 2hsh/DKjJTkETFTHdBwnk7JDmeUy/EyWiuIoV9YoAM9dq9BlFcU14O9uIBc4R2FHvu2iptL18h43 FQgqqVyFj3sBZx4mEk4vidrAbzPztKfs4s5XguL2uhT3KQx41zCmSSvPnIYm5nmJl5dvo1wdXBOh afnvDu3E7PNP9hZ2YPyDLCAHXnUsy647Mn0zwmGzAi3Zn+Ydr38cN0L29hpYqOQomv/Sn4OJCdFr QGG66XtzjgLUDW/OzgRwsx26JIrnuz41QdUugEEc+Eql4Tj+X3YkLe5buSZuZ5OAUoGBziSYFLZu u6wUZYupFCxOQUA2Zz77xVbE X-Report-Abuse-To: spam@quarantine11.antispamcloud.com Archived-At: Subject: Re: [arch-d] A Public Option for the Core X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2020 15:41:25 -0000 On 8/12/2020 6:19 AM, Scott Shenker wrote: > The world of today is very different from what it was in 1995, particul= arly in terms of the market forces at work. We discuss our reasoning for = why our proposal might become a reality later in the paper (in a section = called =E2=80=9CAre We Crazy?=E2=80=9D), and I would be interested in you= r reaction. Do you think the market forces we identify might lead to a di= fferent result now? The market forces are leading to the "hollowing of the core". Last time I checked, over 50% of the top Internet servers were served by a dozen or less top ASes, belonging to large CDN or large content hosters, both of which may well be providing their edge points and delivery networks. Your paper does not address that. It seems that you are very concerned with market players using access to "the core" as a choke point to enforce their own version of "pay to play". This has been an issue a few years ago, but I am not sure it is an issue now. What I see instead is local ISP making arrangements like "zero rating" with large content providers. This is a play with local access bandwidth, not with core transit bandwidth. We also have evidence of local ISP prioritizing access to Facebook, YouTube or Netflix without any commercial arrangement with these content providers. Apparently, the reasoning is that "ISP quality" is measured by the populace as "can I easily stream this popular content", and so ISPs use tricks to improve delivery of the most popular content and compete with other ISPs. (I remember these discussions as part of the MARNEWS workshop.) That kind of feedback loop is not affected by the state of core transit. > > More generally, as an academic working on issues related to the Interne= t, I view it as my mission to identify designs and paradigms that would m= ake for a better Internet, and to explore whether there are plausible pat= hs to such eventualities. We recognize that our proposed change is a long= -shot. In fact, almost all attempts to effect large-scale changes in the = Internet (whether its design or its structure) are likely to fail. My r= esponsibility as a researcher is to not let that stop me, and my mission = as a member of the Internet community is to try to make such changes happ= en, despite great odds. I hope that people on this list and elsewhere rea= d this paper in that spirit. Bravo! But then, what about a public option for the edge? -- Christian Huitema From nobody Wed Aug 12 11:47:38 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AEB23A07D4 for ; Wed, 12 Aug 2020 11:47:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=icsi-berkeley-edu.20150623.gappssmtp.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 onlfDP6LvnU6 for ; Wed, 12 Aug 2020 11:47:31 -0700 (PDT) Received: from mail-pg1-x533.google.com (mail-pg1-x533.google.com [IPv6:2607:f8b0:4864:20::533]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B9853A07BE for ; Wed, 12 Aug 2020 11:47:31 -0700 (PDT) Received: by mail-pg1-x533.google.com with SMTP id o13so1511060pgf.0 for ; Wed, 12 Aug 2020 11:47:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icsi-berkeley-edu.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=+5itNcktwIetpQXMuk1a59B9EedlgnAO9UTuoQBmTfs=; b=1OeYhxjnMdSLgzlMnbcc4hnc8sH5webyaeLfpalqc2DpKHsTcTjqYK8Fa1A2E1nzSs 9I2vhOwod7WIP5sXdW57g4OLUQn2sxlK54OSCuViVDQruT7FkMYPx0d6gnjIZr3OB/ui 0+dbOuaB7pox6x0ggqxOWOr8GrN8S8K14eMl6mc6HGMzf4HrhEBoTtbjq562SOb3xKfv hKfRw6YnJFPxxHLozYVpoW6Xu+NwoAz7gLmCxgoyA23xZTFGU1lwGE2HvBiR+2AX5XsS gyhcSsMybaHao3Dzdm4dgFBzbYnE1+EInxl3GC/9iGk3TA+3cfD0YePNfJjpi8DnJpoo zX2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=+5itNcktwIetpQXMuk1a59B9EedlgnAO9UTuoQBmTfs=; b=IfgqMg4J2yDM8EUN3CgqgUQ/loun9W8+gn6tl3NFfELGz56zSP8+Adg+qkRxtjF/M6 uV4HpHJfxcY/BbjcQ8oxhv9dwYB+YZw25u7SzgFjDFi8qRsKwp3ipyMbujw6aRBKIuPp XyDOeIRjeRSIVJJYNViTqHTmGQKQPgHQPiqykR0LPyAdKxbPAToioVuWWUvI0nrkYFN4 hQTaPx553hPdeVSrOAAr53t8IPUn6i4tIDUcUupCDz2xbg4+HdTNcFCKfTibd3yXNxw4 Cj+SUi8gGl8Q01x6oq+eszkC2oqfMsO9fozo6DPZ1gfq9SLZ0ArLA22dGc91uOMjQBlU a79g== X-Gm-Message-State: AOAM533VsFZ7ds1tEJPeYG/odFSSGVcCol3CDSp2jsp58YRl+LkVupEZ z2Zdi70Gs7MmYD0ThmqC+TL2/g== X-Google-Smtp-Source: ABdhPJwMlbi6EVuAvN9tnSnvxfwE2RdZROR9Q5EhKt0u2Z6WFXgBcYyy2ZJ6lykkKDZMNxCB2y8QoA== X-Received: by 2002:a62:82c1:: with SMTP id w184mr870323pfd.202.1597258050903; Wed, 12 Aug 2020 11:47:30 -0700 (PDT) Received: from [10.0.1.5] (135-180-3-160.static.sonic.net. [135.180.3.160]) by smtp.gmail.com with ESMTPSA id x9sm3164122pff.145.2020.08.12.11.47.29 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Aug 2020 11:47:29 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_ADFC0E42-BA88-43B7-946A-B1B4742B176F" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Scott Shenker In-Reply-To: <3702d78d-87d9-ac56-6a45-4aa8a0483b5b@huitema.net> Date: Wed, 12 Aug 2020 11:47:28 -0700 Cc: Brian E Carpenter , architecture-discuss@ietf.org Message-Id: References: <6F47F8A6-CE4D-46B4-852C-702B9B8A5724@eggert.org> <47EBBED2-2FE9-42B3-BD37-C81DA84A42F8@icsi.berkeley.edu> <3702d78d-87d9-ac56-6a45-4aa8a0483b5b@huitema.net> To: Christian Huitema X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [arch-d] A Public Option for the Core X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2020 18:47:36 -0000 --Apple-Mail=_ADFC0E42-BA88-43B7-946A-B1B4742B176F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 To avoid misconceptions, I would encourage everyone who is interested to = look at the 20 minute video online = (https://dl.acm.org/doi/abs/10.1145/3387514.3405875#sec-supp = ). Or if = you really want to punish yourself, you can read the paper at = (https://dl.acm.org/doi/pdf/10.1145/3387514.3405875 = ). Christian, the hollowing out of the core is precisely what we are = addressing (in the video, it is the first motivating problem). Moreover, = we are structuring the POC to encourage competition and open access at = the edge. So you may not agree with our proposed approach, but I think = we are trying to address the problems you raised! =E2=80=94Scott > On Aug 12, 2020, at 8:37 AM, Christian Huitema = wrote: >=20 >=20 > On 8/12/2020 6:19 AM, Scott Shenker wrote: >> The world of today is very different from what it was in 1995, = particularly in terms of the market forces at work. We discuss our = reasoning for why our proposal might become a reality later in the paper = (in a section called =E2=80=9CAre We Crazy?=E2=80=9D), and I would be = interested in your reaction. Do you think the market forces we identify = might lead to a different result now? >=20 > The market forces are leading to the "hollowing of the core". Last = time > I checked, over 50% of the top Internet servers were served by a dozen > or less top ASes, belonging to large CDN or large content hosters, = both > of which may well be providing their edge points and delivery = networks. > Your paper does not address that. >=20 > It seems that you are very concerned with market players using access = to > "the core" as a choke point to enforce their own version of "pay to > play". This has been an issue a few years ago, but I am not sure it is > an issue now. What I see instead is local ISP making arrangements like > "zero rating" with large content providers. This is a play with local > access bandwidth, not with core transit bandwidth. >=20 > We also have evidence of local ISP prioritizing access to Facebook, > YouTube or Netflix without any commercial arrangement with these = content > providers. Apparently, the reasoning is that "ISP quality" is measured > by the populace as "can I easily stream this popular content", and so > ISPs use tricks to improve delivery of the most popular content and > compete with other ISPs. (I remember these discussions as part of the > MARNEWS workshop.) That kind of feedback loop is not affected by the > state of core transit. >=20 >>=20 >> More generally, as an academic working on issues related to the = Internet, I view it as my mission to identify designs and paradigms that = would make for a better Internet, and to explore whether there are = plausible paths to such eventualities. We recognize that our proposed = change is a long-shot. In fact, almost all attempts to effect = large-scale changes in the Internet (whether its design or its = structure) are likely to fail. My responsibility as a researcher is to = not let that stop me, and my mission as a member of the Internet = community is to try to make such changes happen, despite great odds. I = hope that people on this list and elsewhere read this paper in that = spirit. >=20 > Bravo! But then, what about a public option for the edge? >=20 > -- Christian Huitema >=20 >=20 --Apple-Mail=_ADFC0E42-BA88-43B7-946A-B1B4742B176F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
To avoid misconceptions, I would encourage everyone who is = interested to look at the 20 minute video online (https://dl.acm.org/doi/abs/10.1145/3387514.3405875#sec-supp= ). Or if you really want to punish yourself, you can read the paper at = (https://dl.acm.org/doi/pdf/10.1145/3387514.3405875).
<= div class=3D"">
Christian, the = hollowing out of the core is precisely what we are addressing (in the = video, it is the first motivating problem). Moreover, we are structuring = the POC to encourage competition and open access at the edge. So you may = not agree with our proposed approach, but I think we are trying to = address the problems you raised!

=E2=80=94Scott

On Aug = 12, 2020, at 8:37 AM, Christian Huitema <huitema@huitema.net>= wrote:


On 8/12/2020 6:19 AM, Scott Shenker wrote:
The world of today is = very different from what it was in 1995, particularly in terms of the = market forces at work. We discuss our reasoning for why our proposal = might become a reality later in the paper (in a section called =E2=80=9CAr= e We Crazy?=E2=80=9D), and I would be interested in your reaction. Do = you think the market forces we identify might lead to a different result = now?

The market forces are = leading to the "hollowing of the core". Last time
I = checked, over 50% of the top Internet servers were served by a dozen
or less top ASes, belonging to large CDN or large content = hosters, both
of which may well be providing their edge = points and delivery networks.
Your paper does not address = that.

It seems that you are very concerned = with market players using access to
"the core" as a choke = point to enforce their own version of "pay to
play". This = has been an issue a few years ago, but I am not sure it is
an issue now. What I see instead is local ISP making = arrangements like
"zero rating" with large content = providers. This is a play with local
access bandwidth, not = with core transit bandwidth.

We also have = evidence of local ISP prioritizing access to Facebook,
YouTube or Netflix without any commercial arrangement with = these content
providers. Apparently, the reasoning is that = "ISP quality" is measured
by the populace as "can I easily = stream this popular content", and so
ISPs use tricks to = improve delivery of the most popular content and
compete = with other ISPs. (I remember these discussions as part of the
MARNEWS workshop.) That kind of feedback loop is not affected = by the
state of core transit.


More = generally, as an academic working on issues related to the Internet, I = view it as my mission to identify designs and paradigms that would make = for a better Internet, and to explore whether there are plausible paths = to such eventualities. We recognize that our proposed change is a = long-shot. In fact, almost all attempts to effect large-scale changes in = the Internet (whether its design or its structure) are likely to fail. =   My responsibility as a researcher is to not let that stop = me, and my mission as a member of the Internet community is to try to = make such changes happen, despite great odds. I hope that people on this = list and elsewhere read this paper in that spirit.

Bravo! But then, what about a = public option for the edge?

-- Christian = Huitema



= --Apple-Mail=_ADFC0E42-BA88-43B7-946A-B1B4742B176F-- From nobody Wed Aug 12 21:25:28 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34BC03A1680; Wed, 12 Aug 2020 21:25:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 h2PIslc8-fwe; Wed, 12 Aug 2020 21:25:24 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 6D1223A167F; Wed, 12 Aug 2020 21:25:24 -0700 (PDT) Received: from lhreml737-chm.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 7A72A245A807BFF40555; Thu, 13 Aug 2020 05:25:21 +0100 (IST) Received: from lhreml737-chm.china.huawei.com (10.201.108.187) by lhreml737-chm.china.huawei.com (10.201.108.187) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Thu, 13 Aug 2020 05:25:21 +0100 Received: from DGGEMM404-HUB.china.huawei.com (10.3.20.212) by lhreml737-chm.china.huawei.com (10.201.108.187) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1913.5 via Frontend Transport; Thu, 13 Aug 2020 05:25:21 +0100 Received: from DGGEMM512-MBS.china.huawei.com ([169.254.4.119]) by DGGEMM404-HUB.china.huawei.com ([10.3.20.212]) with mapi id 14.03.0487.000; Thu, 13 Aug 2020 12:25:14 +0800 From: Lizhenbin To: "architecture-discuss@ietf.org" , "rtgwg@ietf.org" CC: "daniel@olddog.co.uk" Thread-Topic: APN (Application-aware Networking) Mailing List Thread-Index: AQHWcSm9UxJHPHzNC0CSrL07iXeXlQ== Date: Thu, 13 Aug 2020 04:25:14 +0000 Message-ID: <5A5B4DE12C0DAC44AF501CD9A2B01A8D9381CC52@dggemm512-mbs.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.153.194.223] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [arch-d] APN (Application-aware Networking) Mailing List X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Aug 2020 04:25:26 -0000 SGkgRm9sa3MsDQoNClRoZSBBUE4gbWFpbGluZyBsaXN0IGhhcyBiZWVuIGNyZWF0ZWQuIElmIHlv dSBoYXZlIGludGVyZXN0IGluIHRoZSB3b3JrLCBwbGVhc2Ugc3Vic2NyaWJlLg0KDQpMaXN0IGFk ZHJlc3M6IGFwbkBpZXRmLm9yZw0KQXJjaGl2ZTogaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9y Zy9hcmNoL2Jyb3dzZS9hcG4NClRvIHN1YnNjcmliZTogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9hcG4NCg0KUHVycG9zZToNClRoaXMgZW1haWwgbGlzdCBpcyB0aGUgZGlz Y3Vzc2lvbiBsaXN0IGZvciB0aGUgQXBwbGljYXRpb24tYXdhcmUgTmV0d29ya2luZyAoQVBOKS4g QXBwbGljYXRpb24tYXdhcmUgTmV0d29ya2luZyBpcyBhIG1lY2hhbmlzbSB3aGVyZWJ5IHRyYWZm aWMgZmxvd3MgY2FuIGJlIHN0ZWVyZWQgYW5kIHJvdXRlZCB3aXRoaW4gdGhlIG5ldHdvcmsgdG8g ZW5zdXJlIHRoYXQgdGhlIHNwZWNpZmljIHNlcnZpY2UgbGV2ZWxzIG5lZWRlZCBieSBhcHBsaWNh dGlvbnMgY2FuIGJlIGRlbGl2ZXJlZC4gIA0KDQpUaGlzIGxpc3QgYmVsb25ncyB0byBJRVRGIGFy ZWE6IFJURw0KDQoNCkxvb2sgZm9yd2FyZCB0byBnb2luZyBvbiB0byBoYXZlIG1vcmUgZGlzY3Vz c2lvbiBpbiB0aGUgbWFpbGluZyBsaXN0Lg0KDQoNCg0KQmVzdCByZWdhcmRzLCANClpoZW5iaW4g KFJvYmluKQ0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K t6K8/sjLOiBBcmNoaXRlY3R1cmUtZGlzY3VzcyBbYXJjaGl0ZWN0dXJlLWRpc2N1c3MtYm91bmNl c0BpZXRmLm9yZ10gtPqx7SBMaXpoZW5iaW4gW2xpemhlbmJpbkBodWF3ZWkuY29tXQ0Kt6LLzcqx vOQ6IDIwMjDE6jfUwjI5yNUgMDoxNw0KytW8/sjLOiBhcmNoaXRlY3R1cmUtZGlzY3Vzc0BpZXRm Lm9yZzsgcnRnd2dAaWV0Zi5vcmcNCrOty806IGRhbmllbEBvbGRkb2cuY28udWsNCtb3zOI6IFth cmNoLWRdIEFQTiAoQXBwbGljYXRpb24tYXdhcmUgTmV0d29ya2luZykgU2lkZSBNZWV0aW5nDQoN CkhpIEFsbCwNCldlIHdpbGwgaGF2ZSB0aGUgQVBOIHNpZGUgbWVldGluZyBhdCAxMjozMCAtIDE0 OjAwIFVUQyBvbiBKdWx5IDMwIChUaHVyc2RheSkuIFRoZSBhZ2VuZGEgYW5kIHRoZSBXZWJFeCBp bmZvcm1hdGlvbiBpcyBwcm92aWRlZCBpbiB0aGUgZm9sbG93aW5nIGxpbmsuDQpodHRwczovL2dp dGh1Yi5jb20vQVBOLUNvbW11bml0eS9JRVRGMTA4LVNpZGUtTWVldGluZy1BUE4NCg0KVGhlcmUg aGFzIGJlZW4gc2V2ZXJhbCBzaW1pbGFyIHdvcmsgbGlrZSBBUE4gc3VjaCBhcyBTUFVEIGFuZCBQ TFVTLiBSZWNlbnRseSBOZXR3b3JrIFRva2VuIHdvcmsgd2FzIGFsc28gcHJvcG9zZWQuIFRoZSBz aWRlIG1lZXRpbmcgaXMgdG8gdHJ5IHRvIGNsYXJpZnkgdGhlIHNjb3BlIG9mIEFQTiBjb21wYXJp bmcgd2l0aCBvdGhlciB3b3JrLiBUaGUgcG9zc2libGUgdXNlY2FzZXMgYXJlIGFsc28gcHJvcG9z ZWQgZm9yIHRoZSBBUE4gd29yay4gQW5vdGhlciBnb2FsIG9mIHRoZSBzaWRlIG1lZXRpbmcgaXMg dG8gY2xhcmlmeSB0aGUgc2VjdXJpdHkgYW5kIHByaXZhY3kgaXNzdWVzIHdoaWNoIGFyZSBhbHdh eXMgcHJvcG9zZWQgYWdhaW5zdCBzdWNoIGFwcGxpY2F0aW9uLXdhcmUgbmV0d29ya2luZyB3b3Jr LiBJbiBSVEdXRyBzZXNzaW9uIGhlbGQgeWVzdGVyZGF5LCB0aGUgcHJlc2VudGF0aW9uIG9mIEFQ TiB3b3JrIGRpc2N1c3NlZCB0aGUgcG9zc2libGUgc2NlbmFyaW9zIHJlbGF0ZWQgd2l0aCB0aGUg c2VjdXJpdHkgYW5kIHByaXZhY3kgaXNzdWVzLiBUaGUgZm9sbG93aW5nIHNsaWRlcyBpcyBmb3Ig eW91ciByZWZlcmVuY2U6DQpodHRwczovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy8xMDgvc2xp ZGVzL3NsaWRlcy0xMDgtcnRnd2ctOC1ydGd3Zy1hcG42LTAxDQoNClNpbmNlIGl0IGlzIGEgY29t cGxleCBjcm9zcy1hcmVhIHdvcmsgYW5kIHRoZXJlIGlzIG11Y2ggYmFja2dyb3VuZCBpbmZvcm1h dGlvbiwgd2lzaCB5b3UgY291bGQgam9pbiB0aGUgc2lkZSBtZWV0aW5nIGlmIHlvdSBoYXZlIGlu dGVyZXN0IGluIHRoZSB3b3JrIGFuZCB5b3VyIGNvbW1lbnRzIGFuZCBzdWdnZXN0aW9ucyBhcmUg YXBwcmVjaWF0ZWQuDQoNCg0KQmVzdCBSZWdhcmRzLA0KRGFuaWVsICYgWmhlbmJpbiAoUm9iaW4p DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KQXJjaGl0 ZWN0dXJlLWRpc2N1c3MgbWFpbGluZyBsaXN0DQpBcmNoaXRlY3R1cmUtZGlzY3Vzc0BpZXRmLm9y Zw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hcmNoaXRlY3R1cmUtZGlz Y3Vzcw== From nobody Fri Aug 14 17:37:31 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 961943A0B2F; Fri, 14 Aug 2020 17:37:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.319 X-Spam-Level: X-Spam-Status: No, score=-1.319 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 2t5tN1TJcRN0; Fri, 14 Aug 2020 17:37:28 -0700 (PDT) Received: from server217-4.web-hosting.com (server217-4.web-hosting.com [198.54.116.98]) (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 20E6C3A14DF; Fri, 14 Aug 2020 17:37:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Transfer-Encoding:Content-Type:Sender: Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender :Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=Fx/TU+ZuvEtlxt/3IUNV08Sqs+1rkMkbT4jpWIiDrOY=; b=rv6SbC92mptndsbz/AQIAB4Wm3 4xYJFH2bXzZnc8LvclQvkV9NBrF3lh+xoVUIc8zayz2wjlTS2MhghlskC9PtYqjFptN7YH6DL8XfO Fivs/kYHjjTkQ96CIEQmNpSEqPHoM8p++PnhvIwE7R+EDIn8QoE3p/JqaSpkMh+Pfu8ZS+JT2G6zs zS2HtXOyBn9gkOjKJm1PptPYT6OMqvxpz3qywQc/oKhEmqNruYNvxqA3SLQnKdx14IB4Ukpk/DZ/s b/hjLgIh7EL7acizgDflUNbWU9CX7IcgMSb7Isj9gBer2W2wVOrJD0NAZEQ71yd1UZkEER5JBCZO8 xUtAVLyQ==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:49182 helo=[192.168.1.5]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1k6kCG-002tyR-3i; Fri, 14 Aug 2020 20:37:24 -0400 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) From: Joe Touch In-Reply-To: <5A5B4DE12C0DAC44AF501CD9A2B01A8D9381CC52@dggemm512-mbs.china.huawei.com> Date: Fri, 14 Aug 2020 17:37:19 -0700 Cc: "architecture-discuss@ietf.org" , "rtgwg@ietf.org" , "daniel@olddog.co.uk" Message-Id: <171DEAE6-BC06-44B8-88E9-64BA20850450@strayalpha.com> References: <5A5B4DE12C0DAC44AF501CD9A2B01A8D9381CC52@dggemm512-mbs.china.huawei.com> To: Lizhenbin X-Mailer: iPhone Mail (17G80) X-OutGoing-Spam-Status: No, score=-0.2 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [arch-d] APN (Application-aware Networking) Mailing List X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2020 00:37:30 -0000 This WG appears to be revisiting the issues of the expired trigtran wg. It m= ight be useful to understand why that did not succeed and whether you are as= king the same question twice and expecting a different answer.=20 Joe > On Aug 12, 2020, at 9:25 PM, Lizhenbin wrote: >=20 > =EF=BB=BFHi Folks, >=20 > The APN mailing list has been created. If you have interest in the work, p= lease subscribe. >=20 > List address: apn@ietf.org > Archive: https://mailarchive.ietf.org/arch/browse/apn > To subscribe: https://www.ietf.org/mailman/listinfo/apn >=20 > Purpose: > This email list is the discussion list for the Application-aware Networkin= g (APN). Application-aware Networking is a mechanism whereby traffic flows c= an be steered and routed within the network to ensure that the specific serv= ice levels needed by applications can be delivered. =20 >=20 > This list belongs to IETF area: RTG >=20 >=20 > Look forward to going on to have more discussion in the mailing list. >=20 >=20 >=20 > Best regards,=20 > Zhenbin (Robin) >=20 >=20 >=20 > ________________________________________ > =E5=8F=91=E4=BB=B6=E4=BA=BA: Architecture-discuss [architecture-discuss-bo= unces@ietf.org] =E4=BB=A3=E8=A1=A8 Lizhenbin [lizhenbin@huawei.com] > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2020=E5=B9=B47=E6=9C=8829=E6=97=A5 0= :17 > =E6=94=B6=E4=BB=B6=E4=BA=BA: architecture-discuss@ietf.org; rtgwg@ietf.org= > =E6=8A=84=E9=80=81: daniel@olddog.co.uk > =E4=B8=BB=E9=A2=98: [arch-d] APN (Application-aware Networking) Side Meeti= ng >=20 > Hi All, > We will have the APN side meeting at 12:30 - 14:00 UTC on July 30 (Thursda= y). The agenda and the WebEx information is provided in the following link. > https://github.com/APN-Community/IETF108-Side-Meeting-APN >=20 > There has been several similar work like APN such as SPUD and PLUS. Recent= ly Network Token work was also proposed. The side meeting is to try to clari= fy the scope of APN comparing with other work. The possible usecases are als= o proposed for the APN work. Another goal of the side meeting is to clarify t= he security and privacy issues which are always proposed against such applic= ation-ware networking work. In RTGWG session held yesterday, the presentatio= n of APN work discussed the possible scenarios related with the security and= privacy issues. The following slides is for your reference: > https://www.ietf.org/proceedings/108/slides/slides-108-rtgwg-8-rtgwg-apn6-= 01 >=20 > Since it is a complex cross-area work and there is much background informa= tion, wish you could join the side meeting if you have interest in the work a= nd your comments and suggestions are appreciated. >=20 >=20 > Best Regards, > Daniel & Zhenbin (Robin) > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss From nobody Fri Aug 14 20:12:06 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEC093A1535 for ; Fri, 14 Aug 2020 20:12:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.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 8ig8zt5XcYme for ; Fri, 14 Aug 2020 20:11:58 -0700 (PDT) Received: from resqmta-ch2-02v.sys.comcast.net (resqmta-ch2-02v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:34]) (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 48A6F3A1536 for ; Fri, 14 Aug 2020 20:11:58 -0700 (PDT) Received: from resomta-ch2-01v.sys.comcast.net ([69.252.207.97]) by resqmta-ch2-02v.sys.comcast.net with ESMTP id 6mbkkmTpzP03C6mbtkFHa8; Sat, 15 Aug 2020 03:11:57 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=20190202a; t=1597461117; bh=SZEl9+gyp6REz7DZwLzMAcwc75XlZDQIvyMiWhEVszM=; h=Received:Received:Content-Type:Mime-Version:Subject:From:Date: Message-Id:To; b=gQL/AtlMzWLXzYEdXq2iMpqMWwt+2qEb2BAjrAF0/NbzOCexiIyQuCmLlnRQgexxo geyQDKu6CKnDoBssWg03GLXTflzG/oQF64rXvX4m3VZUhLLyIOEJvUGMxp+9YKgodh oOvWWb+ndlRULFBYziBkat24PysNY3b82aiDZfLhubMNRWpUZe3NIZ1KJMZJR4/wUn 8CSnhTim8J7Tu0UtY2X8hSbERP0uVG8NPm/aOWptgikzhKuS+ddecNljPeZvIGjpMJ hRiLlivG3UOz+Fv7KdIXvyyEOGWy2pUoPg8wsj/rhB8U+JwIvhY9l/ti0LgX1DSa0T KEwD36Hp/J8dA== Received: from [IPv6:2601:189:4300:cee9:6dcd:ffa6:b2b:581f] ([IPv6:2601:189:4300:cee9:6dcd:ffa6:b2b:581f]) by resomta-ch2-01v.sys.comcast.net with ESMTPSA id 6mbqk85GahXo46mbrkVkO5; Sat, 15 Aug 2020 03:11:56 +0000 X-Xfinity-VMeta: sc=-100.00;st=legit Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.15\)) From: John Day In-Reply-To: <171DEAE6-BC06-44B8-88E9-64BA20850450@strayalpha.com> Date: Fri, 14 Aug 2020 23:11:52 -0400 Cc: Lizhenbin , "architecture-discuss@ietf.org" , "daniel@olddog.co.uk" , "rtgwg@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <8E7FA3E3-21FF-4E84-8A89-B1CB2445A6AA@comcast.net> References: <5A5B4DE12C0DAC44AF501CD9A2B01A8D9381CC52@dggemm512-mbs.china.huawei.com> <171DEAE6-BC06-44B8-88E9-64BA20850450@strayalpha.com> To: Joe Touch X-Mailer: Apple Mail (2.3445.104.15) Archived-At: Subject: Re: [arch-d] APN (Application-aware Networking) Mailing List X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2020 03:12:01 -0000 No, these are the ones who think that your browser should be able to = tell Windows what order to do the disk queue. John > On Aug 14, 2020, at 20:37, Joe Touch wrote: >=20 > This WG appears to be revisiting the issues of the expired trigtran = wg. It might be useful to understand why that did not succeed and = whether you are asking the same question twice and expecting a different = answer.=20 >=20 > Joe >=20 >> On Aug 12, 2020, at 9:25 PM, Lizhenbin wrote: >>=20 >> =EF=BB=BFHi Folks, >>=20 >> The APN mailing list has been created. If you have interest in the = work, please subscribe. >>=20 >> List address: apn@ietf.org >> Archive: https://mailarchive.ietf.org/arch/browse/apn >> To subscribe: https://www.ietf.org/mailman/listinfo/apn >>=20 >> Purpose: >> This email list is the discussion list for the Application-aware = Networking (APN). Application-aware Networking is a mechanism whereby = traffic flows can be steered and routed within the network to ensure = that the specific service levels needed by applications can be = delivered. =20 >>=20 >> This list belongs to IETF area: RTG >>=20 >>=20 >> Look forward to going on to have more discussion in the mailing list. >>=20 >>=20 >>=20 >> Best regards,=20 >> Zhenbin (Robin) >>=20 >>=20 >>=20 >> ________________________________________ >> =E5=8F=91=E4=BB=B6=E4=BA=BA: Architecture-discuss = [architecture-discuss-bounces@ietf.org] =E4=BB=A3=E8=A1=A8 Lizhenbin = [lizhenbin@huawei.com] >> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2020=E5=B9=B47=E6=9C=8829=E6=97=A5= 0:17 >> =E6=94=B6=E4=BB=B6=E4=BA=BA: architecture-discuss@ietf.org; = rtgwg@ietf.org >> =E6=8A=84=E9=80=81: daniel@olddog.co.uk >> =E4=B8=BB=E9=A2=98: [arch-d] APN (Application-aware Networking) Side = Meeting >>=20 >> Hi All, >> We will have the APN side meeting at 12:30 - 14:00 UTC on July 30 = (Thursday). The agenda and the WebEx information is provided in the = following link. >> https://github.com/APN-Community/IETF108-Side-Meeting-APN >>=20 >> There has been several similar work like APN such as SPUD and PLUS. = Recently Network Token work was also proposed. The side meeting is to = try to clarify the scope of APN comparing with other work. The possible = usecases are also proposed for the APN work. Another goal of the side = meeting is to clarify the security and privacy issues which are always = proposed against such application-ware networking work. In RTGWG session = held yesterday, the presentation of APN work discussed the possible = scenarios related with the security and privacy issues. The following = slides is for your reference: >> = https://www.ietf.org/proceedings/108/slides/slides-108-rtgwg-8-rtgwg-apn6-= 01 >>=20 >> Since it is a complex cross-area work and there is much background = information, wish you could join the side meeting if you have interest = in the work and your comments and suggestions are appreciated. >>=20 >>=20 >> Best Regards, >> Daniel & Zhenbin (Robin) >> _______________________________________________ >> Architecture-discuss mailing list >> Architecture-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/architecture-discuss >> _______________________________________________ >> Architecture-discuss mailing list >> Architecture-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/architecture-discuss >=20 > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss From nobody Sat Aug 15 09:35:50 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 690C73A041A; Sat, 15 Aug 2020 09:35:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.319 X-Spam-Level: X-Spam-Status: No, score=-1.319 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 hrhSwzjeyvm2; Sat, 15 Aug 2020 09:35:46 -0700 (PDT) Received: from server217-4.web-hosting.com (server217-4.web-hosting.com [198.54.116.98]) (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 F21013A0402; Sat, 15 Aug 2020 09:35:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=KCl8jaYLaK30vCXTSrmz/hkEwWHmxZDMSyhE83M2QGU=; b=iYGpMGsjn71mNGaLYH9y36V3P JR3VUBg2fYnj6581P562fMLFnuoGZulcYMTRea9Ei1kEKXc4ph4HUQk2CKqU2uYxmMsF/Kqlcym9B qA0AB8NpwYLzZvEJ5WZfncsIgiiLjK86kVgZ7VVY1y7kyJcDKCeWxH+3oDRFwopy7EBWujB/QWLAF E3KKS9I1CrSiGFd/tqQcE1AAVK2KLMKTMGn1sC/L7fOelWOPaPwzyjQ0ZTIgVV1Jh/0DQEwwn0GNy Ve/yFhANPFz6B56SPUuEv0woyDL/fVBPOgYIulCbWFbEpp1gh3PA4HtzhjPScwndaN8xzLeIXrqM2 rJeqSzZEw==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:52653 helo=[192.168.1.14]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1k6z9f-002aGS-4u; Sat, 15 Aug 2020 12:35:43 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Joseph Touch In-Reply-To: <8E7FA3E3-21FF-4E84-8A89-B1CB2445A6AA@comcast.net> Date: Sat, 15 Aug 2020 09:35:38 -0700 Cc: Lizhenbin , "architecture-discuss@ietf.org" , "daniel@olddog.co.uk" , "rtgwg@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <5A5B4DE12C0DAC44AF501CD9A2B01A8D9381CC52@dggemm512-mbs.china.huawei.com> <171DEAE6-BC06-44B8-88E9-64BA20850450@strayalpha.com> <8E7FA3E3-21FF-4E84-8A89-B1CB2445A6AA@comcast.net> To: John Day X-Mailer: Apple Mail (2.3608.120.23.2.1) X-OutGoing-Spam-Status: No, score=-0.2 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [arch-d] APN (Application-aware Networking) Mailing List X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2020 16:35:49 -0000 TRIGTRAN did look at signals both up and down the network stack. (Browser to OS to disk doesn=E2=80=99t involve that stack) Joe > On Aug 14, 2020, at 8:11 PM, John Day wrote: >=20 > No, these are the ones who think that your browser should be able to = tell Windows what order to do the disk queue. >=20 > John >=20 >> On Aug 14, 2020, at 20:37, Joe Touch wrote: >>=20 >> This WG appears to be revisiting the issues of the expired trigtran = wg. It might be useful to understand why that did not succeed and = whether you are asking the same question twice and expecting a different = answer.=20 >>=20 >> Joe >>=20 >>> On Aug 12, 2020, at 9:25 PM, Lizhenbin wrote: >>>=20 >>> =EF=BB=BFHi Folks, >>>=20 >>> The APN mailing list has been created. If you have interest in the = work, please subscribe. >>>=20 >>> List address: apn@ietf.org >>> Archive: https://mailarchive.ietf.org/arch/browse/apn >>> To subscribe: https://www.ietf.org/mailman/listinfo/apn >>>=20 >>> Purpose: >>> This email list is the discussion list for the Application-aware = Networking (APN). Application-aware Networking is a mechanism whereby = traffic flows can be steered and routed within the network to ensure = that the specific service levels needed by applications can be = delivered. =20 >>>=20 >>> This list belongs to IETF area: RTG >>>=20 >>>=20 >>> Look forward to going on to have more discussion in the mailing = list. >>>=20 >>>=20 >>>=20 >>> Best regards,=20 >>> Zhenbin (Robin) >>>=20 >>>=20 >>>=20 >>> ________________________________________ >>> =E5=8F=91=E4=BB=B6=E4=BA=BA: Architecture-discuss = [architecture-discuss-bounces@ietf.org] =E4=BB=A3=E8=A1=A8 Lizhenbin = [lizhenbin@huawei.com] >>> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2020=E5=B9=B47=E6=9C=8829=E6=97=A5= 0:17 >>> =E6=94=B6=E4=BB=B6=E4=BA=BA: architecture-discuss@ietf.org; = rtgwg@ietf.org >>> =E6=8A=84=E9=80=81: daniel@olddog.co.uk >>> =E4=B8=BB=E9=A2=98: [arch-d] APN (Application-aware Networking) Side = Meeting >>>=20 >>> Hi All, >>> We will have the APN side meeting at 12:30 - 14:00 UTC on July 30 = (Thursday). The agenda and the WebEx information is provided in the = following link. >>> https://github.com/APN-Community/IETF108-Side-Meeting-APN >>>=20 >>> There has been several similar work like APN such as SPUD and PLUS. = Recently Network Token work was also proposed. The side meeting is to = try to clarify the scope of APN comparing with other work. The possible = usecases are also proposed for the APN work. Another goal of the side = meeting is to clarify the security and privacy issues which are always = proposed against such application-ware networking work. In RTGWG session = held yesterday, the presentation of APN work discussed the possible = scenarios related with the security and privacy issues. The following = slides is for your reference: >>> = https://www.ietf.org/proceedings/108/slides/slides-108-rtgwg-8-rtgwg-apn6-= 01 >>>=20 >>> Since it is a complex cross-area work and there is much background = information, wish you could join the side meeting if you have interest = in the work and your comments and suggestions are appreciated. >>>=20 >>>=20 >>> Best Regards, >>> Daniel & Zhenbin (Robin) >>> _______________________________________________ >>> Architecture-discuss mailing list >>> Architecture-discuss@ietf.org >>> https://www.ietf.org/mailman/listinfo/architecture-discuss >>> _______________________________________________ >>> Architecture-discuss mailing list >>> Architecture-discuss@ietf.org >>> https://www.ietf.org/mailman/listinfo/architecture-discuss >>=20 >> _______________________________________________ >> Architecture-discuss mailing list >> Architecture-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/architecture-discuss >=20 From nobody Sat Aug 15 17:03:04 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB7683A0B37 for ; Sat, 15 Aug 2020 17:03:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.047 X-Spam-Level: X-Spam-Status: No, score=-3.047 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.949, 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=gmail.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 6gPFUrJMRbkD for ; Sat, 15 Aug 2020 17:03:01 -0700 (PDT) Received: from mail-pl1-x643.google.com (mail-pl1-x643.google.com [IPv6:2607:f8b0:4864:20::643]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B1B13A0B36 for ; Sat, 15 Aug 2020 17:03:01 -0700 (PDT) Received: by mail-pl1-x643.google.com with SMTP id t11so5757532plr.5 for ; Sat, 15 Aug 2020 17:03:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=QCULlA/6eMkUFuaC9YIQd6HgHi5mh8vCNhV/BWeN83w=; b=sa2cJwtUBk5Hxa+X5GUOm1iOittX2N5rj3b/6DoJsOgYtyTH/AUYy/CVmNN/swufYg cSphS8mjmESEEVnpSIkIPIJLgJTda7dB64qZ6dCMfrV4khrHEe6OKEvc5u81Iy5PkRI7 2YfH9NL13NOCLiSCQL4oMEcFBJzdBX0G1+wk3hOXzXDcw1d9zUffE5WK974NRx4sImni fyhrQXY7CAkYyA154rijO7PVjsMEnrqY5Kt/8lwW5LvIGYWdS+OmcRNmezYbukQPAl8h d87+KBHIdhtVGpf31FlhzcgF4KEz6DFayFcYYXkViIOMGqBwrJ07arNDq/ympb7IQYRx 2Dag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=QCULlA/6eMkUFuaC9YIQd6HgHi5mh8vCNhV/BWeN83w=; b=rzXW3gcnJBbZAVBKBxv1ghyy6c+a73NIrSHB1vIQq58gNblMeWNyUc5F+rdSQsPRN4 IgoLZ22n8LhWr6upsWpy0d5fQ4roBUe/K66xPXCr2L/vnSdqVt0/Z6UO9sR5Zw28Sl48 A7t9E8fwitKMTImPOApfIFZyaWcro02+KtLOZugS8xZsupTT757OYBQQABa4nIJi/BUn 5oEimGVVD21Yi0Zg/wZpFinYy43BWVB5M10fgGZMD1tcFnYRYWtZoullm7ZhBWx7oWX8 roEasIeLzdxHe3wakYfnHlJ/fpy0/ZjNvxZ0xRJiS9nvsMlhLyj46UcW/FJURbMqWRxK 1dSw== X-Gm-Message-State: AOAM533K4h4+AYsZwuy8LdTDRaMN5K0c7XNjncicFEarP6/XZWbGIvBg rRJDOPoG4iJdkur9uONeZh/+QGzFir8/ew== X-Google-Smtp-Source: ABdhPJxMdZYJ6h9BfqNGqjs/ws2fx0b9BDBu+n0EcJD3vdSPXOochPLF7YNB4Xb/7VMj/CCEP9hvGg== X-Received: by 2002:a17:90a:21c6:: with SMTP id q64mr7258610pjc.119.1597536180267; Sat, 15 Aug 2020 17:03:00 -0700 (PDT) Received: from [192.168.178.20] ([151.210.139.192]) by smtp.gmail.com with ESMTPSA id l63sm11771867pgl.24.2020.08.15.17.02.57 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 15 Aug 2020 17:02:59 -0700 (PDT) To: Scott Shenker Cc: lars@eggert.org, architecture-discuss@ietf.org References: <6F47F8A6-CE4D-46B4-852C-702B9B8A5724@eggert.org> <47EBBED2-2FE9-42B3-BD37-C81DA84A42F8@icsi.berkeley.edu> From: Brian E Carpenter Message-ID: <101d7750-5744-5607-663f-4e2ad0f4ff6e@gmail.com> Date: Sun, 16 Aug 2020 12:02:56 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <47EBBED2-2FE9-42B3-BD37-C81DA84A42F8@icsi.berkeley.edu> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [arch-d] A Public Option for the Core X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Aug 2020 00:03:03 -0000 On 13-Aug-20 01:19, Scott Shenker wrote: >=20 >=20 >> On Aug 11, 2020, at 3:53 PM, Brian E Carpenter wrote: >> >> (Bcc to the IETF list and Cc to the architecture-discuss list) >> >> Thanks for circulating this. >> >> On 12-Aug-20 06:50, Lars Eggert wrote: >>> Hi, >>> >>> Scott Shenker et al. just presented a pretty thought-provoking "publi= c option" for the Internet's core backbone at SIGCOMM: https://dl.acm.org= /doi/abs/10.1145/3387514.3405875 >> >> Hmm. >> >> "The technical Internet community has long embraced the notion >> that the Internet should be application-neutral; that notion later >> became known as network neutrality (a term coined in [57])." >> >> I dispute that assertion. "Network neutrality" is a slippery term, >> but certainly there is antipathy between some interpretations of it >> and RFC2474 and other QoS technologies. >=20 > We did not mean to imply that the two are notions are identical, and in= deed we discuss the no-QoS interpretation of network neutrality later in = the paper. However, I think it is undeniable that conceptually the notion= of network neutrality is the descendant of application-neutrality, which= was the intent of this sentence. I apologize if our writing was unclear.= I'd go a bit further. We don't want application-type neutrality, because = (e.g.) video streams require different service characteristics from (e.g.= ) software update distribution. What we want is application-service-provi= der neutrality, so that streaming from CarpenterTube gets the same servic= e as streaming from ShenkerTube. I know that the authors know this, but t= he policy-level debates have often been unclear on this point. >> >> "We choose instead to initially create the POC=E2=80=99s backbone netw= ork out >> of a set of leased lines, and use the interconnections to one or more >> ISPs as a fallback if the POC=E2=80=99s backbone does not have suffici= ent >> connectivity." >> >> That sounds like a fairly accurate description of the Internet in >> about 1995, when ISPs had emerged but the de facto backbone was still >> largely non-profit and/or settlement-free. And note that non-profit >> transit networks existed then, and actively migrated to a for-profit >> model after about 1998. See https://en.wikipedia.org/wiki/EBONE for >> an example. >> >> So I think history would likely repeat itself if this proposal was >> adopted. >=20 > The world of today is very different from what it was in 1995, particul= arly in terms of the market forces at work. We discuss our reasoning for = why our proposal might become a reality later in the paper (in a section = called =E2=80=9CAre We Crazy?=E2=80=9D), and I would be interested in you= r reaction. Do you think the market forces we identify might lead to a di= fferent result now? As you say: "Our alternative is to cleanly separate transit and last-mile= -delivery" and indeed that would be a good thing. I appreciate this comme= nt: "If more and more LMPs find the POC attractive (and the success of IXPs in Europe suggest that this is not farfetched)...". As it happens it= was Olivier Martin in my group at CERN who set up the CERN neutral IXP i= n [thinks hard] late 1995, and it's still going strong today (https://cix= p.net/about-cixp). In the world of 1995/96, ISPs jumped onto to the CIXP = precisely because it was non-profit and neutral. My question is whether today's LMPs are able to take independent decision= s to migrate to the POC. The difference from 1995 is surely that most LMP= s are not independent so cannot take such a decision. Incidentally I would expect a real deployment of the POC to start by peer= ing with as many of the non-profit IXPs as possible. That would create an= instant flash mob of POC users. Successful peering is its own best adver= tisement. =20 > More generally, as an academic working on issues related to the Interne= t, I view it as my mission to identify designs and paradigms that would m= ake for a better Internet, and to explore whether there are plausible pat= hs to such eventualities. We recognize that our proposed change is a long= -shot. In fact, almost all attempts to effect large-scale changes in the = Internet (whether its design or its structure) are likely to fail. My r= esponsibility as a researcher is to not let that stop me, and my mission = as a member of the Internet community is to try to make such changes happ= en, despite great odds. I hope that people on this list and elsewhere rea= d this paper in that spirit. Absolutely, and thanks for working on this. Brian >=20 > =E2=80=94Scott >=20 >=20 >> >> Maybe it's time to update https://tools.ietf.org/html/draft-carpenter-= metrics >> Reactions to that draft from the then major transit ISPs were interest= ingly >> negative. >> >> Brian >> >>> >>> If you scroll down (or go to https://dl.acm.org/doi/abs/10.1145/33875= 14.3405875#sec-supp), his recorded talk video gives a high-level overview= =2E >>> >>> (PDF and video *should* be open access and work for me, but you never= know with the ACM...) >>> >>> Lars >>> >> >> _______________________________________________ >> Architecture-discuss mailing list >> Architecture-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/architecture-discuss >=20 > . >=20 From nobody Sat Aug 15 18:48:28 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DEA73A0B89 for ; Sat, 15 Aug 2020 18:48:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.318 X-Spam-Level: X-Spam-Status: No, score=-1.318 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 pX3Dtu5ZhPwG for ; Sat, 15 Aug 2020 18:48:24 -0700 (PDT) Received: from server217-4.web-hosting.com (server217-4.web-hosting.com [198.54.116.98]) (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 278A03A0B79 for ; Sat, 15 Aug 2020 18:48:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=frcJminT57AmTnnXkk1ozPbqKLfwoYnhg9JHPvItfa0=; b=DtrKhV0Cl88vkW8uPFFi8UZRU Ikhk8Rqz4TRJcJXEpUrHphH7UgnUm+ykW2SGy1DTPex3Nnca4YUPEKmNzjm44GoILUQLR9Iwci45k BWbIakk/Vbs6v6WwKUbB9Q1dbE88UubUNgF8ydrthxCal5IlU4yqtigC3qJxFUYcxF4JLf1qn3Fbz QVXcl+SLKujmjc6xn6XdrvSCjO9RmXLUen9+7ZVXvX6Wk1hAQu9mnODq5zVQkmCOAiqNvclO/i9jl +RrRDNiwX19VJRMlsIMqKyKAf4ZUWTUd+MTGhYmapWLm2mctE/TbeIYuWaa+uGV57aJJT/opNJxnd Ed5fPvP0Q==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:53806 helo=[192.168.1.14]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1k77mV-003MxU-5i; Sat, 15 Aug 2020 21:48:23 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_90521504-C57D-4EB3-8114-2CF8A18BA850" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Joseph Touch In-Reply-To: <101d7750-5744-5607-663f-4e2ad0f4ff6e@gmail.com> Date: Sat, 15 Aug 2020 18:48:18 -0700 Cc: Scott Shenker , architecture-discuss@ietf.org Message-Id: <6BBE7B4B-E32B-4F78-88C9-A769F2BF4827@strayalpha.com> References: <6F47F8A6-CE4D-46B4-852C-702B9B8A5724@eggert.org> <47EBBED2-2FE9-42B3-BD37-C81DA84A42F8@icsi.berkeley.edu> <101d7750-5744-5607-663f-4e2ad0f4ff6e@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3608.120.23.2.1) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [arch-d] A Public Option for the Core X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Aug 2020 01:48:26 -0000 --Apple-Mail=_90521504-C57D-4EB3-8114-2CF8A18BA850 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Aug 15, 2020, at 5:02 PM, Brian E Carpenter = wrote: >=20 > On 13-Aug-20 01:19, Scott Shenker wrote: >>=20 >>=20 >>> On Aug 11, 2020, at 3:53 PM, Brian E Carpenter = > = wrote: >>>=20 >>> (Bcc to the IETF list and Cc to the architecture-discuss list) >>>=20 >>> Thanks for circulating this. >>>=20 >>> On 12-Aug-20 06:50, Lars Eggert wrote: >>>> Hi, >>>>=20 >>>> Scott Shenker et al. just presented a pretty thought-provoking = "public option" for the Internet's core backbone at SIGCOMM: = https://dl.acm.org/doi/abs/10.1145/3387514.3405875 = >>>=20 >>> Hmm. >>>=20 >>> "The technical Internet community has long embraced the notion >>> that the Internet should be application-neutral; that notion later >>> became known as network neutrality (a term coined in [57])." It=E2=80=99s presumptive at best to claim anything in one voice about = any community; this one perhaps moreso (esp. on the main list = recently)... >>> I dispute that assertion. "Network neutrality" is a slippery term, >>> but certainly there is antipathy between some interpretations of it >>> and RFC2474 and other QoS technologies. >>=20 >> We did not mean to imply that the two are notions are identical, and = indeed we discuss the no-QoS interpretation of network neutrality later = in the paper. However, I think it is undeniable that conceptually the = notion of network neutrality is the descendant of = application-neutrality, which was the intent of this sentence. I = apologize if our writing was unclear. >=20 > I'd go a bit further. We don't want application-type neutrality, = because (e.g.) video streams require different service characteristics = from (e.g.) software update distribution. I agree only that there are many interpretations of the term, many at = odds with each other. Again, =E2=80=9Cwe=E2=80=9D is hard to define, but it certainly = doesn=E2=80=99t include me... > What we want is application-service-provider neutrality, so that = streaming from CarpenterTube gets the same service as streaming from = ShenkerTube. *I* want apps to be able to get different service from the network and = to pay differently for them if needed, but *never* to have the network = infer or enforce that mapping. Just like the USPS, variable fee for = variable service, but there=E2=80=99s absolutely no reason the price of = a letter should be determined by who wrote it or what it says. If a user = wants to run software update over low-latency, slightly lossy service, = that=E2=80=99s their decision; same for someone who wants to stream over = best-effort. Providers that do otherwise only force us to run a whole Internet = *inside* a single port number - e.g., as is starting with the merging of = DNS and HTTP over 443. Joe --Apple-Mail=_90521504-C57D-4EB3-8114-2CF8A18BA850 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Aug 15, 2020, at 5:02 PM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:

On 13-Aug-20 01:19, Scott = Shenker wrote:


On Aug 11, 2020, at 3:53 = PM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:

(Bcc to the IETF list and Cc to the architecture-discuss = list)

Thanks for circulating this.

On 12-Aug-20 06:50, Lars Eggert wrote:
Hi,

Scott Shenker et al. just presented a pretty = thought-provoking "public option" for the Internet's core backbone at = SIGCOMM: https://dl.acm.org/doi/abs/10.1145/3387514.3405875

Hmm.

"The technical Internet community has long embraced the = notion
that the Internet should be application-neutral; = that notion later
became known as network neutrality (a = term coined in [57])."

It=E2=80=99s presumptive at best to claim anything = in one voice about any community; this one perhaps moreso (esp. on the = main list recently)...

I dispute that = assertion. "Network neutrality" is a slippery term,
but = certainly there is antipathy between some interpretations of it
and RFC2474 and other QoS technologies.

We did not mean to imply that the = two are notions are identical, and indeed we discuss the no-QoS = interpretation of network neutrality later in the paper. However, I = think it is undeniable that conceptually the notion of network = neutrality is the descendant of application-neutrality, which was the = intent of this sentence. I apologize if our writing was unclear.

I'd go a bit further. We don't want application-type = neutrality, because (e.g.) video streams require different service = characteristics from (e.g.) software update = distribution.

I = agree only that there are many interpretations of the term, many at odds = with each other.

Again, =E2=80=9Cwe=E2= =80=9D is hard to define, but it certainly doesn=E2=80=99t include = me...

What we want is application-service-provider neutrality, so = that streaming from CarpenterTube gets the same service as streaming = from ShenkerTube.

*I* want apps to be able to get different service = from the network and to pay differently for them if needed, but *never* = to have the network infer or enforce that mapping. Just like the USPS, = variable fee for variable service, but there=E2=80=99s absolutely no = reason the price of a letter should be determined by who wrote it or = what it says. If a user wants to run software update over low-latency, = slightly lossy service, that=E2=80=99s their decision; same for someone = who wants to stream over best-effort.

Providers that do otherwise only force us to run a = whole Internet *inside* a single port number - e.g., as is starting with = the merging of DNS and HTTP over 443.

Joe



= --Apple-Mail=_90521504-C57D-4EB3-8114-2CF8A18BA850-- From nobody Sun Aug 16 03:02:09 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD4FA3A0AE3 for ; Sun, 16 Aug 2020 03:02:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.847 X-Spam-Level: X-Spam-Status: No, score=-2.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.949, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 nKkXzHoE5lyf for ; Sun, 16 Aug 2020 03:02:05 -0700 (PDT) Received: from know-smtprelay-omc-4.server.virginmedia.net (know-smtprelay-omc-4.server.virginmedia.net [80.0.253.68]) (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 5B8BF3A0AA2 for ; Sun, 16 Aug 2020 03:02:05 -0700 (PDT) Received: from [192.168.0.16] ([80.0.21.207]) by cmsmtp with ESMTPA id 7FUIkO6tnJ6QC7FUIklC8t; Sun, 16 Aug 2020 11:02:03 +0100 X-Originating-IP: [80.0.21.207] X-Authenticated-User: john.s.grant@ntlworld.com X-Spam: 0 X-Authority: v=2.3 cv=BpmzP7f5 c=1 sm=1 tr=0 a=ZJrsehNnOEfaj4OPFeyFaA==:117 a=ZJrsehNnOEfaj4OPFeyFaA==:17 a=IkcTkHD0fZMA:10 a=le6d79QuAAAA:8 a=zNN82u1Z8fhV9qkCa7wA:9 a=QEXdDO2ut3YA:10 a=QbAMNLWdp4a7deKPGBBn:22 To: architecture-discuss@ietf.org References: <6F47F8A6-CE4D-46B4-852C-702B9B8A5724@eggert.org> <47EBBED2-2FE9-42B3-BD37-C81DA84A42F8@icsi.berkeley.edu> <101d7750-5744-5607-663f-4e2ad0f4ff6e@gmail.com> <6BBE7B4B-E32B-4F78-88C9-A769F2BF4827@strayalpha.com> From: John Grant Message-ID: Date: Sun, 16 Aug 2020 11:02:05 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <6BBE7B4B-E32B-4F78-88C9-A769F2BF4827@strayalpha.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB X-CMAE-Envelope: MS4wfFq19CI17t/TZ+Yl4uMJ0bu/c2/aP0YTZy7i9iLg7wR8LKpe4rhcqmaQ4dCU9/ETJYRfLwL1Y/CDfYkY0z7nC6HW/FzpEQ3zmDHqm+s7EV77iKM6W5g1 R9Y3S8shlEwjW4o9yJZDv4P+J5nGVTtWD1wl4cxxY/Z3m9H4DHx4p+s9 Archived-At: Subject: Re: [arch-d] A Public Option for the Core X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Aug 2020 10:02:07 -0000 On 16/08/2020 02:48, Joseph Touch wrote: > *I* want apps to be able to get different service from the network and > to pay differently for them if needed, but *never* to have the network > infer or enforce that mapping. Of course, if you're going to do that -- have the application negotiate a particular kind of service rather than have the network "inspect" the packets and guess what service is needed -- you need a control plane protocol (let's call it "signalling") to do the negotiation, and you no longer have the connectionless/stateless paradigm on which IP is founded. -- John Grant Nine Tiles, Cambridge, England +44 1223 862599 and +44 1223 511455 http://www.ninetiles.com From nobody Sun Aug 16 03:18:58 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E01803A0B36 for ; Sun, 16 Aug 2020 03:18:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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=comcast.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 M7RIETaDg_jk for ; Sun, 16 Aug 2020 03:18:55 -0700 (PDT) Received: from resqmta-ch2-03v.sys.comcast.net (resqmta-ch2-03v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:35]) (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 7CF693A0B35 for ; Sun, 16 Aug 2020 03:18:55 -0700 (PDT) Received: from resomta-ch2-14v.sys.comcast.net ([69.252.207.110]) by resqmta-ch2-03v.sys.comcast.net with ESMTP id 7FjukKRdudzWm7FkckLrN2; Sun, 16 Aug 2020 10:18:54 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=20190202a; t=1597573134; bh=ARU3/6NfUf+/UEGxfF9aS1Q5mXlXiS2L3iWhX+Od8wM=; h=Received:Received:From:Content-Type:Mime-Version:Subject: Message-Id:To:Date; b=CMcuBtn7isjtXpZ2c86DBL+G94tgLD9An++Idl5J5xry7tv8dr+R0+zL+fNtuwfVU 2xoVdgO/YR2AxXa/6qJdU81sFlIUEHBpZa9d03wzxK057G3DFJGSHk6InL9vyWEQs6 J9n7HEcMBpiU8HWC1WcEndynvA2lwtQado/lDjI05RWqhGUkULX604kSJgFXPl65lh efuZj/1J0M6YMtlGULxNEtLHb4wCTovr5rQ8MABk7X37FRicR532xOMZi+JgcfbOUE 5O6VBICDVkQXLGpMTs2Kz1QVEsSUbGDVHc7VdQrCBCOy5fWWfnv0yPMFFfS2tkYwH6 I2k3PL1x0tDdA== Received: from [IPv6:2601:189:4300:cee9:dc0e:8ac8:fa2d:8901] ([IPv6:2601:189:4300:cee9:dc0e:8ac8:fa2d:8901]) by resomta-ch2-14v.sys.comcast.net with ESMTPSA id 7Fjpkv5kltNzu7FkPkmcKS; Sun, 16 Aug 2020 10:18:42 +0000 X-Xfinity-VMeta: sc=0.00;st=legit From: John Day Content-Type: multipart/alternative; boundary="Apple-Mail=_CE16C22F-720D-4148-93C2-75B8CFD081D8" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.15\)) Message-Id: <754DE168-DF3B-4471-A145-39C6143E538A@comcast.net> References: To: architecture-discuss@ietf.org Date: Sun, 16 Aug 2020 06:18:41 -0400 X-Mailer: Apple Mail (2.3445.104.15) Archived-At: Subject: [arch-d] Fwd: A Public Option for the Core X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Aug 2020 10:18:57 -0000 --Apple-Mail=_CE16C22F-720D-4148-93C2-75B8CFD081D8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > Begin forwarded message: >=20 > From: John Day > Subject: Re: [arch-d] A Public Option for the Core > Date: August 16, 2020 at 06:18:04 EDT > To: John Grant >=20 > No, that is not true. Your first mistake is that there is a control = plane. >=20 > John >=20 >> On Aug 16, 2020, at 06:02, John Grant wrote: >>=20 >> On 16/08/2020 02:48, Joseph Touch wrote: >>> *I* want apps to be able to get different service from the network = and to pay differently for them if needed, but *never* to have the = network infer or enforce that mapping. >> Of course, if you're going to do that -- have the application = negotiate a particular kind of service rather than have the network = "inspect" the packets and guess what service is needed -- you need a = control plane protocol (let's call it "signalling") to do the = negotiation, and you no longer have the connectionless/stateless = paradigm on which IP is founded. >>=20 >> --=20 >> John Grant >> Nine Tiles, Cambridge, England >> +44 1223 862599 and +44 1223 511455 >> http://www.ninetiles.com >>=20 >> _______________________________________________ >> Architecture-discuss mailing list >> Architecture-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/architecture-discuss >=20 --Apple-Mail=_CE16C22F-720D-4148-93C2-75B8CFD081D8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

Begin forwarded message:

From: = John Day <jeanjour@comcast.net>
Subject: = Re: [arch-d] A = Public Option for the Core
Date: = August 16, 2020 at 06:18:04 = EDT
To: = John Grant <j@ninetiles.com>

No,= that is not true.  Your first mistake is that there is a control = plane.

John

On Aug 16, 2020, at = 06:02, John Grant <j@ninetiles.com> wrote:

On = 16/08/2020 02:48, Joseph Touch wrote:
*I* want apps to be able to get different = service from the network and to pay differently for them if needed, but = *never* to have the network infer or enforce that mapping.
Of course, if you're going to do that -- have = the application negotiate a particular kind of service rather than have = the network "inspect" the packets and guess what service is needed -- = you need a control plane protocol (let's call it "signalling") to do the = negotiation, and you no longer have the connectionless/stateless = paradigm on which IP is founded.

--
John Grant
Nine Tiles, Cambridge, England
+44 1223 862599 and +44 1223 511455
http://www.ninetiles.com

_______________________________________________
Architecture-discuss mailing list
Architecture-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/architecture-discuss


= --Apple-Mail=_CE16C22F-720D-4148-93C2-75B8CFD081D8-- From nobody Sun Aug 16 08:01:27 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 364973A0CCF for ; Sun, 16 Aug 2020 08:01:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.317 X-Spam-Level: X-Spam-Status: No, score=-1.317 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 8bnRVWPNcwoX for ; Sun, 16 Aug 2020 08:01:24 -0700 (PDT) Received: from server217-4.web-hosting.com (server217-4.web-hosting.com [198.54.116.98]) (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 B8E333A0CCE for ; Sun, 16 Aug 2020 08:01:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Transfer-Encoding:Content-Type:Sender: Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender :Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=yRmnKUHyadF1CGmx4MdOvzBrwyO+IbQnM0wdg6jICwE=; b=cU6wTA7kVC6ZG3q1d+LEC2W+8f BtvBQ0ALBTmwz6n+4deOfOy7/YqaW/coKSiHD0eadQetN8UrKaLSghUqp7/hNXF0nA1rjof9HUuys hgSaI9JQXdkqePAx9QokmE97xZolHIlQ6HU226Cv9sOiFPouWa3kpNsDae2QqwEPqjP+C0gNwgxHk ME7zva3RNxerYTQOV0+SC1pf3gW87qxu15Cs1F/Aw6L49NJ+qQEfStyKqx1/UsuxG7C2MZQXWAgWG 64zbDW8gHBsz48Yafzv8wEakTX8hKrZpT84hYxqYcRNb1inDm4u9+85wJNDn+Zy7XqjhFCPxTvMGf 16Swt/qQ==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:52559 helo=[192.168.1.6]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1k7K9v-003t3M-Td; Sun, 16 Aug 2020 11:01:24 -0400 Content-Type: multipart/alternative; boundary=Apple-Mail-6CDF80B3-62A9-4BDD-A369-192CBBA7931A Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) From: Joe Touch In-Reply-To: <754DE168-DF3B-4471-A145-39C6143E538A@comcast.net> Date: Sun, 16 Aug 2020 08:01:19 -0700 Cc: architecture-discuss@ietf.org Message-Id: References: <754DE168-DF3B-4471-A145-39C6143E538A@comcast.net> To: John Day X-Mailer: iPad Mail (17G68) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [arch-d] Fwd: A Public Option for the Core X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Aug 2020 15:01:26 -0000 --Apple-Mail-6CDF80B3-62A9-4BDD-A369-192CBBA7931A Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable And the second is that service level implies connection. It only requires th= e network understands a label *I* control, rather than trying to infer one f= rom the packet contents.=20 Joe > On Aug 16, 2020, at 3:19 AM, John Day wrote: >=20 > =EF=BB=BF >=20 >> Begin forwarded message: >>=20 >> From: John Day >> Subject: Re: [arch-d] A Public Option for the Core >> Date: August 16, 2020 at 06:18:04 EDT >> To: John Grant >>=20 >> No, that is not true. Your first mistake is that there is a control plan= e. >>=20 >> John >>=20 >>> On Aug 16, 2020, at 06:02, John Grant wrote: >>>=20 >>>> On 16/08/2020 02:48, Joseph Touch wrote: >>>> *I* want apps to be able to get different service from the network and t= o pay differently for them if needed, but *never* to have the network infer o= r enforce that mapping. >>> Of course, if you're going to do that -- have the application negotiate a= particular kind of service rather than have the network "inspect" the packe= ts and guess what service is needed -- you need a control plane protocol (le= t's call it "signalling") to do the negotiation, and you no longer have the c= onnectionless/stateless paradigm on which IP is founded. >>>=20 >>> --=20 >>> John Grant >>> Nine Tiles, Cambridge, England >>> +44 1223 862599 and +44 1223 511455 >>> http://www.ninetiles.com >>>=20 >>> _______________________________________________ >>> Architecture-discuss mailing list >>> Architecture-discuss@ietf.org >>> https://www.ietf.org/mailman/listinfo/architecture-discuss >>=20 >=20 > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss --Apple-Mail-6CDF80B3-62A9-4BDD-A369-192CBBA7931A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
And the second is that ser= vice level implies connection. It only requires the network understands a la= bel *I* control, rather than trying to infer one from the packet contents.&n= bsp;

Joe

On Aug 16, 2020, at 3:19 AM, John Day <= jeanjour@comcast.net> wrote:

=EF=BB=BF

Begin forwarded message:
From: John Day <jeanjour@comcast.net>
Subje= ct: Re: [arch-d] A Public O= ption for the Core
Date: August 16, 2020 at 06:18:04 EDT
To: John Grant <<= a href=3D"mailto:j@ninetiles.com" class=3D"">j@ninetiles.com>

No, that i= s not true.  Your first mistake is that there is a control plane.

John

On Aug 16, 2020, at 06:02, John Grant <j@ninetiles.com> wrote:
<= br class=3D"">On 16/08/2020 02:48, Joseph Touch wrote:
*I* want apps to be able to get different serv= ice from the network and to pay differently for them if needed, but *never* t= o have the network infer or enforce that mapping.
Of course, if you're going to do that -- have the application negotiate a p= articular kind of service rather than have the network "inspect" the packets= and guess what service is needed -- you need a control plane protocol (let'= s call it "signalling") to do the negotiation, and you no longer have the co= nnectionless/stateless paradigm on which IP is founded.

--
John Grant
Nine Tiles, Cambridge, E= ngland
+44 1223 862599 and +44 1223 511455
http://www.ninetiles.com

_______________________________________________
Architecture-discuss mailing list
Architecture-discu= ss@ietf.org
https://www.ietf.org/mailman/listinfo/architecture= -discuss

=
_______________________________________________
Architecture-discuss mailing list
Architectur= e-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/arc= hitecture-discuss
= --Apple-Mail-6CDF80B3-62A9-4BDD-A369-192CBBA7931A-- From nobody Sun Aug 16 13:24:14 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CCCD3A10FC for ; Sun, 16 Aug 2020 13:24:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.047 X-Spam-Level: X-Spam-Status: No, score=-2.047 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, NICE_REPLY_A=-0.949, 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=gmail.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 N8dg8lJeVZYa for ; Sun, 16 Aug 2020 13:24:12 -0700 (PDT) Received: from mail-pl1-x643.google.com (mail-pl1-x643.google.com [IPv6:2607:f8b0:4864:20::643]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F8553A10FA for ; Sun, 16 Aug 2020 13:24:11 -0700 (PDT) Received: by mail-pl1-x643.google.com with SMTP id q19so6473550pll.0 for ; Sun, 16 Aug 2020 13:24:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=sjej3nB1QZdPtND2tgLNzXJcL/o5U1Xm88S1SbKohdk=; b=sNu/Oq7gzHXThc30eq62o9mMrQwr3W4Qc+Eldd5+WoQvX+RpCUCxDIysHvN5yaT6Eq +h5rH3dBoLu2fWJEB/sjtfNdA8rAOTeZYyJG/ChBTvY8/ywAw539crtWSxNxk+OC4+zw h+F09/3Q6Lk2L3TItqt0Ez6CMBMdfG6LTOyTilLKVtMhdxH9fbbFe+bxel7yEVOTAFml 9uXk7b+csHr6eYLY9R0EI9B7IobAQAmOwLKTpRGc/9W0zvPaEdtpJ2UJXzOKSjTFqw90 8PGTFjVd6fjZKAH5ZOh1ojezJj7PfJNIGtDKWWlDL3sDgjodWUypyXR9BI5KVU4cNVNH /zug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=sjej3nB1QZdPtND2tgLNzXJcL/o5U1Xm88S1SbKohdk=; b=LSjT0083kSd4ZuiH327DeTixcNskmcY4lMBaEL9LfLUAimwWYWxiu8H+wws7u3PMBs KGXZUug0XIZVrTpqFjeBX8Nybj6KNrE7wcWX1A+bGAyfBPFBs43dd1cLrMxUv3xjtgfr fiBhEgZ8VX7GJm64IqjL3Dj9HgiVA8qSnYWKjQcZ4SB+Lf8vyI5ZexFFS8c+1DSie+ws nny+ONalnz/eIRx1mKvqU5JNEA4T3YtCcTstPdy4mckq0CW3zJxilDqBck/MnTY4n0ls ZutRegatsy/ZP34Zt76tC0SCK3briyZuFa2NlEa4f1bICpFDKrTkYSdkymZ7Cy4QKy3C l7Mw== X-Gm-Message-State: AOAM532NwVe82KD3wTvVIcdKRtuVUiqOR4NsMhjJzPb76nOwEOJx0zX8 9/UxY9H2ppntUpktL9G+asPVMpwaPOuBUA== X-Google-Smtp-Source: ABdhPJwZ+yAorGlGwGMaNp+lmK60Y7XuCZmRzo5FGp/wAGWY4xynMaaukw7rl06bFkhT8sC3/bovCw== X-Received: by 2002:a17:90a:c781:: with SMTP id gn1mr9766065pjb.151.1597609451040; Sun, 16 Aug 2020 13:24:11 -0700 (PDT) Received: from [192.168.178.20] ([151.210.139.192]) by smtp.gmail.com with ESMTPSA id n3sm16560714pfq.131.2020.08.16.13.24.08 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 16 Aug 2020 13:24:10 -0700 (PDT) To: Joe Touch , John Day Cc: architecture-discuss@ietf.org References: <754DE168-DF3B-4471-A145-39C6143E538A@comcast.net> From: Brian E Carpenter Message-ID: <1fd2ed7d-d4bc-c5b7-9a4a-7966d5e60513@gmail.com> Date: Mon, 17 Aug 2020 08:24:06 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [arch-d] Fwd: A Public Option for the Core X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Aug 2020 20:24:14 -0000 On 17-Aug-20 03:01, Joe Touch wrote: > And the second is that service level implies connection. It only requir= es the network understands a label *I* control, rather than trying to inf= er one from the packet contents. However, it does need some kind of flow state (whether flows are individu= al or aggregated) in the forwarding queues. Not that this is a new argume= nt; we had it in the diffserv WG many years ago and it continues to this = day in TSVWG. I don't think this really affects the basic arguments for a "public core"= =2E It just indicates that transit networks don't need to be strictly bes= t effort and stateless in order to be neutral. Brian =C2=A0 >=20 > Joe >=20 >> On Aug 16, 2020, at 3:19 AM, John Day wrote: >> >> =EF=BB=BF >> >>> Begin forwarded message: >>> >>> *From: *John Day >= >>> *Subject: **Re: [arch-d] A Public Option for the Core* >>> *Date: *August 16, 2020 at 06:18:04 EDT >>> *To: *John Grant > >>> >>> No, that is not true. =C2=A0Your first mistake is that there is a con= trol plane. >>> >>> John >>> >>>> On Aug 16, 2020, at 06:02, John Grant > wrote: >>>> >>>> On 16/08/2020 02:48, Joseph Touch wrote: >>>>> *I* want apps to be able to get different service from the network = and to pay differently for them if needed, but *never* to have the networ= k infer or enforce that mapping. >>>> Of course, if you're going to do that -- have the application negoti= ate a particular kind of service rather than have the network "inspect" t= he packets and guess what service is needed -- you need a control plane p= rotocol (let's call it "signalling") to do the negotiation, and you no lo= nger have the connectionless/stateless paradigm on which IP is founded. >>>> >>>> --=20 >>>> John Grant >>>> Nine Tiles, Cambridge, England >>>> +44 1223 862599 and +44 1223 511455 >>>> http://www.ninetiles.com >>>> >>>> _______________________________________________ >>>> Architecture-discuss mailing list >>>> Architecture-discuss@ietf.org >>>> https://www.ietf.org/mailman/listinfo/architecture-discuss >>> >> >> _______________________________________________ >> Architecture-discuss mailing list >> Architecture-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/architecture-discuss >=20 > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss >=20 From nobody Mon Aug 17 00:46:48 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A4543A13E7 for ; Mon, 17 Aug 2020 00:46:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.118 X-Spam-Level: X-Spam-Status: No, score=-1.118 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] 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 DZeBDFyr6ebj for ; Mon, 17 Aug 2020 00:46:44 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 298553A13E6 for ; Mon, 17 Aug 2020 00:46:43 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 7C61D548624; Mon, 17 Aug 2020 09:46:37 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 74975440059; Mon, 17 Aug 2020 09:46:37 +0200 (CEST) Date: Mon, 17 Aug 2020 09:46:37 +0200 From: Toerless Eckert To: Brian E Carpenter Cc: Joe Touch , John Day , architecture-discuss@ietf.org Message-ID: <20200817074637.GW62842@faui48f.informatik.uni-erlangen.de> References: <754DE168-DF3B-4471-A145-39C6143E538A@comcast.net> <1fd2ed7d-d4bc-c5b7-9a4a-7966d5e60513@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1fd2ed7d-d4bc-c5b7-9a4a-7966d5e60513@gmail.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [arch-d] Fwd: A Public Option for the Core X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2020 07:46:47 -0000 John, Joe, Brian: All great discussion points, but i am not sure if JohnD's starting point of "no deductive adaptation of behavior" is really mandatory and/or sufficient for *I* net neutrality. Aka: Do we even have an approved and complete *I* "net neutrality" definition ? If so, where ? Btw, IMHO: Having an application tell the network exactly what it wants from the network is quite a challenging task for applications. When i worked with enterprise application developers, they wouldn't even want to bother to understand what differences in service from the network would best help the application. Hence we thought of a framework where the application would instead attribute traffic as to what it is, e.g.: application FOO, wihthin FOO floX, e.g.: X = audio/video/... Aka: Whatever the application developer was able/ willing to tell. Then one can have a trusted layer that would map this information to actual network service requirements/advisory information. In classical enterprise environments, this trusted mapping layer could typically be a nework device (given how applications in enterprise are subject to a lot of control by the enterprise operator anyhow). In typical residential environment, the trusted mapping would likely best be the browser, given how that performs all type of control operations against applications anyhow. Cheers Toerless On Mon, Aug 17, 2020 at 08:24:06AM +1200, Brian E Carpenter wrote: > On 17-Aug-20 03:01, Joe Touch wrote: > > And the second is that service level implies connection. It only requires the network understands a label *I* control, rather than trying to infer one from the packet contents. > > However, it does need some kind of flow state (whether flows are individual or aggregated) in the forwarding queues. Not that this is a new argument; we had it in the diffserv WG many years ago and it continues to this day in TSVWG. > > I don't think this really affects the basic arguments for a "public core". It just indicates that transit networks don't need to be strictly best effort and stateless in order to be neutral. > > Brian > > > > > Joe > > > >> On Aug 16, 2020, at 3:19 AM, John Day wrote: > >> > >> ??? > >> > >>> Begin forwarded message: > >>> > >>> *From: *John Day > > >>> *Subject: **Re: [arch-d] A Public Option for the Core* > >>> *Date: *August 16, 2020 at 06:18:04 EDT > >>> *To: *John Grant > > >>> > >>> No, that is not true. Your first mistake is that there is a control plane. > >>> > >>> John > >>> > >>>> On Aug 16, 2020, at 06:02, John Grant > wrote: > >>>> > >>>> On 16/08/2020 02:48, Joseph Touch wrote: > >>>>> *I* want apps to be able to get different service from the network and to pay differently for them if needed, but *never* to have the network infer or enforce that mapping. > >>>> Of course, if you're going to do that -- have the application negotiate a particular kind of service rather than have the network "inspect" the packets and guess what service is needed -- you need a control plane protocol (let's call it "signalling") to do the negotiation, and you no longer have the connectionless/stateless paradigm on which IP is founded. > >>>> > >>>> -- > >>>> John Grant > >>>> Nine Tiles, Cambridge, England > >>>> +44 1223 862599 and +44 1223 511455 > >>>> http://www.ninetiles.com > >>>> > >>>> _______________________________________________ > >>>> Architecture-discuss mailing list > >>>> Architecture-discuss@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/architecture-discuss > >>> > >> > >> _______________________________________________ > >> Architecture-discuss mailing list > >> Architecture-discuss@ietf.org > >> https://www.ietf.org/mailman/listinfo/architecture-discuss > > > > _______________________________________________ > > Architecture-discuss mailing list > > Architecture-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/architecture-discuss > > > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss -- --- tte@cs.fau.de From nobody Mon Aug 17 04:43:03 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC4E33A14CC for ; Mon, 17 Aug 2020 04:43:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=comcast.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 urTuXWW9LsrX for ; Mon, 17 Aug 2020 04:43:00 -0700 (PDT) Received: from resqmta-ch2-12v.sys.comcast.net (resqmta-ch2-12v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:44]) (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 262E13A14D1 for ; Mon, 17 Aug 2020 04:43:00 -0700 (PDT) Received: from resomta-ch2-20v.sys.comcast.net ([69.252.207.116]) by resqmta-ch2-12v.sys.comcast.net with ESMTP id 7dVTkoJpF8dHA7dXWkXfOl; Mon, 17 Aug 2020 11:42:58 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=20190202a; t=1597664578; bh=PQDxZlyOHxxxkbKfXK/JjhPSVwa3gTc2LrVthyOHHZQ=; h=Received:Received:Content-Type:Mime-Version:Subject:From:Date: Message-Id:To; b=1p7Xa33M8Oiklu851u6rUvmZMQX0FpwG8UbqznUW3DLtCwxilzFZgfYZJ7d7T7Dgx 5B4QHWcWVpnq+1xyTI4jk7e/OnuWYxn/4hfnQxvjNXCfra0mwCP5DbVMOmWl1yFIAm 5HFn0EfcxSXFwVOle5zTY7we0T4vBGgCEbyrzNJU/ZcWjShRt48IGoRNX4gbRwETrn NrJVRTEmtmHotXHKUXgsh8/o3XtuNxMbnLpOi9uWqQIIt67y4QEacDbiWiJNoUUyYU yKyGX+t5VhXhvWDJJHrXg+1JM5tTOVALqsiYgXagqKe/fgwJSN7P2hbS5W/dyd5xyx lK0T9NbPWV6OQ== Received: from [IPv6:2601:189:4300:cee9:e4a0:2eb4:8c8a:c734] ([IPv6:2601:189:4300:cee9:e4a0:2eb4:8c8a:c734]) by resomta-ch2-20v.sys.comcast.net with ESMTPSA id 7dXAk8f9FHxi27dXBk4myK; Mon, 17 Aug 2020 11:42:57 +0000 X-Xfinity-VMeta: sc=-100.00;st=legit Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.15\)) From: John Day In-Reply-To: <20200817074637.GW62842@faui48f.informatik.uni-erlangen.de> Date: Mon, 17 Aug 2020 07:42:36 -0400 Cc: Brian E Carpenter , Joe Touch , architecture-discuss@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <754DE168-DF3B-4471-A145-39C6143E538A@comcast.net> <1fd2ed7d-d4bc-c5b7-9a4a-7966d5e60513@gmail.com> <20200817074637.GW62842@faui48f.informatik.uni-erlangen.de> To: Toerless Eckert X-Mailer: Apple Mail (2.3445.104.15) Archived-At: Subject: Re: [arch-d] Fwd: A Public Option for the Core X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2020 11:43:02 -0000 > On Aug 17, 2020, at 03:46, Toerless Eckert wrote: >=20 > John, Joe, Brian: >=20 > All great discussion points, but i am not sure if JohnD's starting > point of "no deductive adaptation of behavior" is really mandatory > and/or sufficient for *I* net neutrality. Aka: Do we even have > an approved and complete *I* "net neutrality" definition ? If so, = where ? Really? I said that? Interesting. I wonder, when and even more, why? >=20 > Btw, IMHO: Having an application tell the network exactly what it > wants from the network is quite a challenging task for applications. > When i worked with enterprise application developers, they wouldn't > even want to bother to understand what differences in service from the > network would best help the application. >=20 > Hence we thought of a framework where the application would instead > attribute traffic as to what it is, e.g.: application FOO, wihthin FOO = floX, > e.g.: X =3D audio/video/... Aka: Whatever the application developer = was able/ > willing to tell. >=20 > Then one can have a trusted layer that would map this information to > actual network service requirements/advisory information. >=20 > In classical enterprise environments, this trusted mapping layer > could typically be a nework device (given how applications in = enterprise > are subject to a lot of control by the enterprise operator anyhow). > In typical residential environment, the trusted mapping would likely > best be the browser, given how that performs all type of control > operations against applications anyhow. Interesting conjecture. O, well. John >=20 > Cheers > Toerless >=20 > On Mon, Aug 17, 2020 at 08:24:06AM +1200, Brian E Carpenter wrote: >> On 17-Aug-20 03:01, Joe Touch wrote: >>> And the second is that service level implies connection. It only = requires the network understands a label *I* control, rather than trying = to infer one from the packet contents. >>=20 >> However, it does need some kind of flow state (whether flows are = individual or aggregated) in the forwarding queues. Not that this is a = new argument; we had it in the diffserv WG many years ago and it = continues to this day in TSVWG. >>=20 >> I don't think this really affects the basic arguments for a "public = core". It just indicates that transit networks don't need to be strictly = best effort and stateless in order to be neutral. >>=20 >> Brian >> =20 >>>=20 >>> Joe >>>=20 >>>> On Aug 16, 2020, at 3:19 AM, John Day wrote: >>>>=20 >>>> ??? >>>>=20 >>>>> Begin forwarded message: >>>>>=20 >>>>> *From: *John Day > >>>>> *Subject: **Re: [arch-d] A Public Option for the Core* >>>>> *Date: *August 16, 2020 at 06:18:04 EDT >>>>> *To: *John Grant > >>>>>=20 >>>>> No, that is not true. Your first mistake is that there is a = control plane. >>>>>=20 >>>>> John >>>>>=20 >>>>>> On Aug 16, 2020, at 06:02, John Grant > wrote: >>>>>>=20 >>>>>> On 16/08/2020 02:48, Joseph Touch wrote: >>>>>>> *I* want apps to be able to get different service from the = network and to pay differently for them if needed, but *never* to have = the network infer or enforce that mapping. >>>>>> Of course, if you're going to do that -- have the application = negotiate a particular kind of service rather than have the network = "inspect" the packets and guess what service is needed -- you need a = control plane protocol (let's call it "signalling") to do the = negotiation, and you no longer have the connectionless/stateless = paradigm on which IP is founded. >>>>>>=20 >>>>>> --=20 >>>>>> John Grant >>>>>> Nine Tiles, Cambridge, England >>>>>> +44 1223 862599 and +44 1223 511455 >>>>>> http://www.ninetiles.com >>>>>>=20 >>>>>> _______________________________________________ >>>>>> Architecture-discuss mailing list >>>>>> Architecture-discuss@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/architecture-discuss >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> Architecture-discuss mailing list >>>> Architecture-discuss@ietf.org >>>> https://www.ietf.org/mailman/listinfo/architecture-discuss >>>=20 >>> _______________________________________________ >>> Architecture-discuss mailing list >>> Architecture-discuss@ietf.org >>> https://www.ietf.org/mailman/listinfo/architecture-discuss >>>=20 >>=20 >> _______________________________________________ >> Architecture-discuss mailing list >> Architecture-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/architecture-discuss >=20 > --=20 > --- > tte@cs.fau.de From nobody Mon Aug 17 06:23:41 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4C853A153F for ; Mon, 17 Aug 2020 06:23:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 BR8IhCA9rjJL for ; Mon, 17 Aug 2020 06:23:37 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FE7D3A0C06 for ; Mon, 17 Aug 2020 06:23:36 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 91ABB54802F; Mon, 17 Aug 2020 15:23:31 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 86251440059; Mon, 17 Aug 2020 15:23:31 +0200 (CEST) Date: Mon, 17 Aug 2020 15:23:31 +0200 From: Toerless Eckert To: John Day Cc: Brian E Carpenter , Joe Touch , architecture-discuss@ietf.org Message-ID: <20200817132331.GX62842@faui48f.informatik.uni-erlangen.de> References: <754DE168-DF3B-4471-A145-39C6143E538A@comcast.net> <1fd2ed7d-d4bc-c5b7-9a4a-7966d5e60513@gmail.com> <20200817074637.GW62842@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [arch-d] Fwd: A Public Option for the Core X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2020 13:23:40 -0000 On Mon, Aug 17, 2020 at 07:42:36AM -0400, John Day wrote: > > > > On Aug 17, 2020, at 03:46, Toerless Eckert wrote: > > > > John, Joe, Brian: > > > > All great discussion points, but i am not sure if JohnD's starting > > point of "no deductive adaptation of behavior" is really mandatory > > and/or sufficient for *I* net neutrality. Aka: Do we even have > > an approved and complete *I* "net neutrality" definition ? If so, where ? > > Really? I said that? Interesting. I wonder, when and even more, why? Didn't say you said. Was referring to this, from Joe: >>>> On 16/08/2020 02:48, Joseph Touch wrote: >>>> *I* want apps to be able to get different service from the network and to pay differently for them if needed, but +*never* to have the network infer or enforce that mapping. > > Btw, IMHO: Having an application tell the network exactly what it > > wants from the network is quite a challenging task for applications. > > When i worked with enterprise application developers, they wouldn't > > even want to bother to understand what differences in service from the > > network would best help the application. > > > > Hence we thought of a framework where the application would instead > > attribute traffic as to what it is, e.g.: application FOO, wihthin FOO floX, > > e.g.: X = audio/video/... Aka: Whatever the application developer was able/ > > willing to tell. > > > > Then one can have a trusted layer that would map this information to > > actual network service requirements/advisory information. > > > > In classical enterprise environments, this trusted mapping layer > > could typically be a nework device (given how applications in enterprise > > are subject to a lot of control by the enterprise operator anyhow). > > In typical residential environment, the trusted mapping would likely > > best be the browser, given how that performs all type of control > > operations against applications anyhow. > > Interesting conjecture. O, well. That second part was just my view of how beyond best effort service differentiation would likely best be embodied into prevailing architectures in different market segments. Opinions welcome. Cheers Toerless > John > > > > > Cheers > > Toerless > > > > On Mon, Aug 17, 2020 at 08:24:06AM +1200, Brian E Carpenter wrote: > >> On 17-Aug-20 03:01, Joe Touch wrote: > >>> And the second is that service level implies connection. It only requires the network understands a label *I* control, rather than trying to infer one from the packet contents. > >> > >> However, it does need some kind of flow state (whether flows are individual or aggregated) in the forwarding queues. Not that this is a new argument; we had it in the diffserv WG many years ago and it continues to this day in TSVWG. > >> > >> I don't think this really affects the basic arguments for a "public core". It just indicates that transit networks don't need to be strictly best effort and stateless in order to be neutral. > >> > >> Brian > >> > >>> > >>> Joe > >>> > >>>> On Aug 16, 2020, at 3:19 AM, John Day wrote: > >>>> > >>>> ??? > >>>> > >>>>> Begin forwarded message: > >>>>> > >>>>> *From: *John Day > > >>>>> *Subject: **Re: [arch-d] A Public Option for the Core* > >>>>> *Date: *August 16, 2020 at 06:18:04 EDT > >>>>> *To: *John Grant > > >>>>> > >>>>> No, that is not true. Your first mistake is that there is a control plane. > >>>>> > >>>>> John > >>>>> > >>>>>> On Aug 16, 2020, at 06:02, John Grant > wrote: > >>>>>> > >>>>>> On 16/08/2020 02:48, Joseph Touch wrote: > >>>>>>> *I* want apps to be able to get different service from the network and to pay differently for them if needed, but *never* to have the network infer or enforce that mapping. > >>>>>> Of course, if you're going to do that -- have the application negotiate a particular kind of service rather than have the network "inspect" the packets and guess what service is needed -- you need a control plane protocol (let's call it "signalling") to do the negotiation, and you no longer have the connectionless/stateless paradigm on which IP is founded. > >>>>>> > >>>>>> -- > >>>>>> John Grant > >>>>>> Nine Tiles, Cambridge, England > >>>>>> +44 1223 862599 and +44 1223 511455 > >>>>>> http://www.ninetiles.com > >>>>>> > >>>>>> _______________________________________________ > >>>>>> Architecture-discuss mailing list > >>>>>> Architecture-discuss@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/architecture-discuss > >>>>> > >>>> > >>>> _______________________________________________ > >>>> Architecture-discuss mailing list > >>>> Architecture-discuss@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/architecture-discuss > >>> > >>> _______________________________________________ > >>> Architecture-discuss mailing list > >>> Architecture-discuss@ietf.org > >>> https://www.ietf.org/mailman/listinfo/architecture-discuss > >>> > >> > >> _______________________________________________ > >> Architecture-discuss mailing list > >> Architecture-discuss@ietf.org > >> https://www.ietf.org/mailman/listinfo/architecture-discuss > > > > -- > > --- > > tte@cs.fau.de -- --- tte@cs.fau.de From nobody Mon Aug 17 06:55:28 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B0D03A156C for ; Mon, 17 Aug 2020 06:55:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netorgft5189650.onmicrosoft.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 0T8Ok6Wd3uL2 for ; Mon, 17 Aug 2020 06:55:25 -0700 (PDT) Received: from GBR01-LO2-obe.outbound.protection.outlook.com (mail-eopbgr100082.outbound.protection.outlook.com [40.107.10.82]) (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 B86D13A156A for ; Mon, 17 Aug 2020 06:55:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kpSIH+lGdNfkzV8oUUFrzlDJomMLsHnS5g9JEHov2lZgDcUepyS5X7ou5fQdpTrVivpYHo9MF1S0QOkbgUM9HCnbo8FOMkYrKaTHDC90YIyJW2otPcTRnWarmLlcjfcJyYt5snwrSji0+VIRM4dQSolTnhMAIBXMFiTOJ49ZQlRtQBpS576vZ6h1qBBHrzV1rFS7/xsXErFlenyYlnmhF9u8GD4cCg6L4sc0lc0UfGBvQRvmk1ttC//3wlnn7abFiqQ2aLT6UI8mg7BpUTsWiknD7WM1Y5g8SIqKFyGDhQTyDOTfidnbDSTAALt0pI0SKjwNC5Pc7kr7RTTSr+AYxg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=u9eJEu6XXXYCe1Qs8xGUh7TWIEZIfcgg7QFuxFjMM0A=; b=bNgvsIoehXB5rtonDgtPSk4TCr0EGxuByXdAa+3xo19TLKUTdrMOYiShc/kNw0Lr5ryjLvXRc+O55mNeempMH/8XtpxsBKs3S+X9UrW54UA3zPmuFYdA+3woQi07Ojy/Z8Vl1heoEK46bDsxMF8bHBG+6KsnFwxQqDq4mU21vbb02HKqw5RNUx/IzVGpdF3d8srtXXz78gA5SFBvRcZ7xpyZlUFKbheId1MEV1wEU4F1WPL7l4SW58SYm8YyziJhnpCoU8U1VygjXJw96BKhef3F61wJIJEOLoApbC0QoOXVU1E/WDRID4VB48fE0JOftJ+qou3tIhyK9otqZ3fzhw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=419.consulting; dmarc=pass action=none header.from=419.consulting; dkim=pass header.d=419.consulting; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT5189650.onmicrosoft.com; s=selector1-NETORGFT5189650-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=u9eJEu6XXXYCe1Qs8xGUh7TWIEZIfcgg7QFuxFjMM0A=; b=h6PvB53L44c+X3mIF1JQb5nubYhqhtETKm29Ggpj/jie7xfTGwrIZlsWaNikSjMi/tWZcrEFrXl2v+pxvgAlgrsYfIQD2sDl5H2iaUB44yiJwGj+Zxg4X8go91kFBBFFI4uclycJgjgiRJSs9sNi+uzmUavUais35iBGecJqcww= Received: from LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:71::15) by LO2P265MB0830.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:6b::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3283.16; Mon, 17 Aug 2020 13:55:14 +0000 Received: from LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM ([fe80::91fb:af23:a084:10cf]) by LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM ([fe80::91fb:af23:a084:10cf%7]) with mapi id 15.20.3283.027; Mon, 17 Aug 2020 13:55:14 +0000 From: Andrew Campling To: Toerless Eckert , Brian E Carpenter CC: Joe Touch , John Day , "architecture-discuss@ietf.org" Thread-Topic: [arch-d] Fwd: A Public Option for the Core Thread-Index: AQHWdJmqEQ4JuXcUG0Sv0cTNGUdaaKk8T1QQ Date: Mon, 17 Aug 2020 13:55:13 +0000 Message-ID: References: <754DE168-DF3B-4471-A145-39C6143E538A@comcast.net> <1fd2ed7d-d4bc-c5b7-9a4a-7966d5e60513@gmail.com> <20200817074637.GW62842@faui48f.informatik.uni-erlangen.de> In-Reply-To: <20200817074637.GW62842@faui48f.informatik.uni-erlangen.de> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: cs.fau.de; dkim=none (message not signed) header.d=none;cs.fau.de; dmarc=none action=none header.from=419.consulting; x-originating-ip: [2a00:23c4:a499:2e00:a064:d5c5:8b3b:ec1b] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 830e7297-a1e8-4a03-0cfa-08d842b52a65 x-ms-traffictypediagnostic: LO2P265MB0830: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: kFWvJgJ9Qh69eK0mMJoD72oBW6MpT6yz+uGotpsfLBLTsNJlhlFa+NRyah8ZU/CVqQkzz0iu/5IzvhWTaK3j8NLTJQ8UVOXwowK6NmpEadEq7KVCHPwpvB9dE+DDRDW+oKkcSlDjisqizq38D/NKrdPPVa2BEtGpK3NUE8qXf51gEaqfhnGAjgPdilWs3UpCC4IPeO4T49v6cyTIFZ6oTJo7KiHD0UZQh0a/YK2vwL3Mex+zETcL2zpG3NSN63176zlI66u0jSQaJZlOBSEEX9AEIluPKr5ESbKs7UDb7Lc9lHz5cr9sJbJlTFDsO/huIiqZ672KHjMUJ+s7KSET3uW5G2rsPMuodXfutOKwdg137R0RSM0+YCAQusuomxCMsksQmvIbhPjkUqmlfph/H4L+ZPaH/j5lIz7oVV+AQYeo7Ub2RvbkbuWe3ie+yIr+Phc+7tygiNEJxCHHhXpAMw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(136003)(39830400003)(396003)(366004)(346002)(376002)(76116006)(6506007)(316002)(4326008)(53546011)(71200400001)(186003)(8676002)(33656002)(966005)(5660300002)(66574015)(54906003)(83380400001)(44832011)(478600001)(8936002)(55016002)(9686003)(2906002)(7696005)(64756008)(66556008)(66476007)(66946007)(110136005)(86362001)(66446008)(52536014)(46492007); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: H9pz/rHi3VGZUa09++SDcZWb6N/zG1ukNaINN17wXbswJGXJXOJoYWIJJhnbzxplDVm9hfRcn+5oLEUeXf/OBVAQBiv1M27gWdPfpp8ByZE79FT31YoU4VZI9v0Tk1rFnCZksXWAY+l0lrcggaI+Dg0HGQ/jkqhSGSCMhs3oSQSIAWc86doVNyDRI5SZfJ8vov14XxO6YpOQCG75IJyNYcO8779vaYliBwraN4KfGSWytCVCp7N7a6dQN1tQ9cRMqt/wFFveGb2Er2gGzQHT2MeDIvpVUdJy7tZ5OID8ywE4M1CnTPk84awzz3+Sc3qyMvZWopZH717Dq/FJ5j3QgSZJKkeiv5Z1KNjW1YkbIHBxXPKu7cda+dnmmbZpdNhahZlWEjtx5SR4XEdmAGSnxFP9OvyyshoYsghtK35QevkJFqCCkTIF1c4OsvP0y6ieMnal5Nds/WWMl4FGNQPUW6zRyd1gOecuFaGps8yHOigNpGG8Fu15Bho7Um03GQY6wqinjFiJVfDObPFUyoJDYoXdRW5Vcc/q08ZQqx5sNZuDlKshcwaSb+qLu9xdvRIv9vM97NbAmjFg0Hf28eixyPovQ9WY6asByCfFHaGXOLABpgMnspVCaC74oHgkQ34g0xCWF9ziSOwGh55bkZv4rBO/1dUt9wmR7e5o9s9/rjd3ke1zR7RHarupnb1iYxmybTAgUOVGiTy1Cglz/blJkw== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: 419.consulting X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 830e7297-a1e8-4a03-0cfa-08d842b52a65 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Aug 2020 13:55:13.9944 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9c2ced3e-7522-4755-87dc-f983abc66ec3 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: aDAcJVzuzhLkrhVyqcoEyVDf7Cn1TM2FYuV5d/Jy19/dSKBHW+KlvrgJH6P8Ll8J2I7MDSHKiqjqIP+ISYJv9PW9Ia3MQpd0oLuMLYYkMeM= X-MS-Exchange-Transport-CrossTenantHeadersStamped: LO2P265MB0830 Archived-At: Subject: Re: [arch-d] Fwd: A Public Option for the Core X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2020 13:55:27 -0000 > On Aug 17, 2020, at 03:46, Toerless Eckert wrote: >=20 > John, Joe, Brian: >=20 > All great discussion points, but i am not sure if JohnD's starting=20 > point of "no deductive adaptation of behavior" is really mandatory=20 > and/or sufficient for *I* net neutrality. Aka: Do we even have an=20 > approved and complete *I* "net neutrality" definition ? If so, where ? You seem to be assuming that "net neutrality" is always a good thing? My p= ersonal preference is for networks to be transparent in the way that they m= anage traffic (if at all) so that I can choose my network based on what the= y do. A network without, for example, any form of QoS might perform very p= oorly for at least some applications. =20 > Btw, IMHO: Having an application tell the network exactly what it=20 > wants from the network is quite a challenging task for applications. > When i worked with enterprise application developers, they wouldn't=20 > even want to bother to understand what differences in service from the=20 > network would best help the application. This point I agree with. In general, the level of knowledge of networks by= applications developers can be very low (and vice versa), they exist in ve= ry different worlds. =20 =20 > Hence we thought of a framework where the application would instead=20 > attribute traffic as to what it is, e.g.: application FOO, wihthin FOO=20 > floX, e.g.: X =3D audio/video/... Aka: Whatever the application develope= r was=20 > able/ willing to tell. >=20 > Then one can have a trusted layer that would map this information to=20 > actual network service requirements/advisory information. >=20 > In classical enterprise environments, this trusted mapping layer could=20 > typically be a nework device (given how applications in enterprise are=20 > subject to a lot of control by the enterprise operator anyhow). > In typical residential environment, the trusted mapping would likely=20 > best be the browser, given how that performs all type of control=20 > operations against applications anyhow. Whilst I believe that I understand your point, I'm not at all convinced tha= t, in residential environments, delegation of trusted mapping to browsers m= akes a lot of sense. That seems to present a fine attack service for futur= e exploitation. No doubt others will have different views though. =20 Andrew -----Original Message----- From: Toerless Eckert =20 Sent: 17 August 2020 08:47 To: Brian E Carpenter Cc: Joe Touch ; John Day ; arch= itecture-discuss@ietf.org Subject: Re: [arch-d] Fwd: A Public Option for the Core John, Joe, Brian: All great discussion points, but i am not sure if JohnD's starting point of= "no deductive adaptation of behavior" is really mandatory and/or sufficien= t for *I* net neutrality. Aka: Do we even have an approved and complete *I*= "net neutrality" definition ? If so, where ? Btw, IMHO: Having an application tell the network exactly what it wants fro= m the network is quite a challenging task for applications. When i worked with enterprise application developers, they wouldn't even wa= nt to bother to understand what differences in service from the network wou= ld best help the application. Hence we thought of a framework where the application would instead attribu= te traffic as to what it is, e.g.: application FOO, wihthin FOO floX, e.g.: X =3D audio/video/... Aka: Whatever the application developer was ab= le/ willing to tell. Then one can have a trusted layer that would map this information to actual= network service requirements/advisory information. In classical enterprise environments, this trusted mapping layer could typi= cally be a nework device (given how applications in enterprise are subject = to a lot of control by the enterprise operator anyhow). In typical residential environment, the trusted mapping would likely best b= e the browser, given how that performs all type of control operations again= st applications anyhow. Cheers Toerless On Mon, Aug 17, 2020 at 08:24:06AM +1200, Brian E Carpenter wrote: > On 17-Aug-20 03:01, Joe Touch wrote: > > And the second is that service level implies connection. It only requir= es the network understands a label *I* control, rather than trying to infer= one from the packet contents. >=20 > However, it does need some kind of flow state (whether flows are individu= al or aggregated) in the forwarding queues. Not that this is a new argument= ; we had it in the diffserv WG many years ago and it continues to this day = in TSVWG. >=20 > I don't think this really affects the basic arguments for a "public core"= . It just indicates that transit networks don't need to be strictly best ef= fort and stateless in order to be neutral. >=20 > Brian > =A0 > >=20 > > Joe > >=20 > >> On Aug 16, 2020, at 3:19 AM, John Day wrote: > >> > >> ??? > >> > >>> Begin forwarded message: > >>> > >>> *From: *John Day >>> > > >>> *Subject: **Re: [arch-d] A Public Option for the Core* > >>> *Date: *August 16, 2020 at 06:18:04 EDT > >>> *To: *John Grant > > >>> > >>> No, that is not true. =A0Your first mistake is that there is a contro= l plane. > >>> > >>> John > >>> > >>>> On Aug 16, 2020, at 06:02, John Grant > wrote: > >>>> > >>>> On 16/08/2020 02:48, Joseph Touch wrote: > >>>>> *I* want apps to be able to get different service from the network = and to pay differently for them if needed, but *never* to have the network = infer or enforce that mapping. > >>>> Of course, if you're going to do that -- have the application negoti= ate a particular kind of service rather than have the network "inspect" the= packets and guess what service is needed -- you need a control plane proto= col (let's call it "signalling") to do the negotiation, and you no longer h= ave the connectionless/stateless paradigm on which IP is founded. > >>>> > >>>> -- > >>>> John Grant > >>>> Nine Tiles, Cambridge, England > >>>> +44 1223 862599 and +44 1223 511455 > >>>> http://www.ninetiles.com > >>>> > >>>> _______________________________________________ > >>>> Architecture-discuss mailing list Architecture-discuss@ietf.org=20 > >>>> https://www.ietf.org/mailman/listinfo/architecture-discuss > >>> > >> > >> _______________________________________________ > >> Architecture-discuss mailing list > >> Architecture-discuss@ietf.org > >> https://www.ietf.org/mailman/listinfo/architecture-discuss > >=20 > > _______________________________________________ > > Architecture-discuss mailing list > > Architecture-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/architecture-discuss > >=20 >=20 > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss -- --- tte@cs.fau.de From nobody Mon Aug 17 07:47:22 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6AFD3A0E89 for ; Mon, 17 Aug 2020 07:47:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.318 X-Spam-Level: X-Spam-Status: No, score=-1.318 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 OW5VQwPo5n8b for ; Mon, 17 Aug 2020 07:47:11 -0700 (PDT) Received: from server217-4.web-hosting.com (server217-4.web-hosting.com [198.54.116.98]) (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 4E5B33A0E8D for ; Mon, 17 Aug 2020 07:47:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=NM344jbiu1Iq73g3phcuZ7IWB8PAy/bS/s2iP/trGiU=; b=1TGLN7hGYqFzfyU7/oSuXsi4a YVG4k4ZB3xbHcxmu0D2IaeKU4g+Z4mL9jYeYjB1ePWL55QkbbywDxTzyo2zszK4MHA+X50ZTx0KrY GzUHk2BgJzvQ0PEchO6xQV+lJgnhdo8AbZxweGd153eWAha2skSDN0SbReQrGkpzr67R7gZu4wTLT lJqIZRwJ2N6hPmbvaiTAOQtp3j171c/wIaB279qNu8ahDQ7OvRDlKffJO3wQgOb+N7W4CXKz3PQUx KVnj8AM0zOKWcN5PZ0a5Nm9ueeVbyQbAjt7/cyY78ch9MfMcutC+zaw6X12vAfNBScCfyOnL89/9m MDvIbi5hw==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:61385 helo=[192.168.1.14]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1k7gPh-002rDx-M0; Mon, 17 Aug 2020 10:47:10 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_9E1060C4-57CB-45C1-A330-F30B008B3A1E" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Joseph Touch In-Reply-To: <20200817074637.GW62842@faui48f.informatik.uni-erlangen.de> Date: Mon, 17 Aug 2020 07:47:04 -0700 Cc: architecture-discuss@ietf.org Message-Id: <60B2B44D-5E6D-4CB2-AD63-1A8CB846BFA3@strayalpha.com> References: <754DE168-DF3B-4471-A145-39C6143E538A@comcast.net> <1fd2ed7d-d4bc-c5b7-9a4a-7966d5e60513@gmail.com> <20200817074637.GW62842@faui48f.informatik.uni-erlangen.de> To: Toerless Eckert X-Mailer: Apple Mail (2.3608.120.23.2.1) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [arch-d] A Public Option for the Core X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2020 14:47:20 -0000 --Apple-Mail=_9E1060C4-57CB-45C1-A330-F30B008B3A1E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Toerless, > On Aug 17, 2020, at 12:46 AM, Toerless Eckert wrote: >=20 > Btw, IMHO: Having an application tell the network exactly what it > wants from the network is quite a challenging task for applications. > ... >=20 > Hence we thought of a framework where the application would instead > attribute traffic as to what it is, e.g.: application FOO, wihthin FOO = floX, > e.g.: X =3D audio/video/... Aka: Whatever the application developer = was able/ > willing to tell. >=20 > Then one can have a trusted layer that would map this information to > actual network service requirements/advisory information. That=E2=80=99s an implementation detail inside the endpoint. The = *network* should not be doing that inference: a) because it is typically made to favor the provider, not the user b) because it=E2=80=99s often incorrect, either because the needed info = isn=E2=80=99t available (encryption) or deliberately obscured (running = DNS over ports other than 53) My broader concern is the latter part of the second one: I don=E2=80=99t = like the impact of anti-inference strategies on network architecture. It = tends to force designers to reinvent the Internet at other layers = (inside HTTP, e.g.). Ultimately, there are only a few things the network can do with a = packet: forward it, queue it, or drop it. Having classes of service that = don=E2=80=99t map directly to those behaviors is an invitation for = unnecessary state and complexity anyway. Back to neutrality, though, the point is that the *network* should be = neutral to the user and use of a service, not that there should be only = one service. Joe --Apple-Mail=_9E1060C4-57CB-45C1-A330-F30B008B3A1E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi, = Toerless,

On Aug 17, 2020, at 12:46 AM, Toerless Eckert = <tte@cs.fau.de> = wrote:

Btw, IMHO: Having an application = tell the network exactly what it
wants from the network is quite a challenging task for = applications.
...

Hence we thought of a framework where the application would = instead
attribute = traffic as to what it is, e.g.: application FOO, wihthin FOO = floX,
e.g.: X =3D = audio/video/...  Aka: Whatever the application developer was = able/
willing to = tell.

Then one can = have a trusted layer that would map this information to
actual network service = requirements/advisory information.

That=E2=80=99s an implementation detail inside the = endpoint. The *network* should not be doing that = inference:

a) because it is = typically made to favor the provider, not the user
b) because = it=E2=80=99s often incorrect, either because the needed info isn=E2=80=99t= available (encryption) or deliberately obscured (running DNS over ports = other than 53)

My broader concern is = the latter part of the second one: I don=E2=80=99t like the impact of = anti-inference strategies on network architecture. It tends to force = designers to reinvent the Internet at other layers (inside HTTP, = e.g.).

Ultimately, there are only a = few things the network can do with a packet: forward it, queue it, or = drop it. Having classes of service that don=E2=80=99t map directly to = those behaviors is an invitation for unnecessary state and complexity = anyway.

Back to neutrality, though, = the point is that the *network* should be neutral to the user and use of = a service, not that there should be only one service.

Joe

= --Apple-Mail=_9E1060C4-57CB-45C1-A330-F30B008B3A1E-- From nobody Mon Aug 17 08:04:27 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D79223A0CA4 for ; Mon, 17 Aug 2020 08:04:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.318 X-Spam-Level: X-Spam-Status: No, score=-1.318 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 9HcfYbc27iXg for ; Mon, 17 Aug 2020 08:04:23 -0700 (PDT) Received: from server217-4.web-hosting.com (server217-4.web-hosting.com [198.54.116.98]) (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 90CD83A10C7 for ; Mon, 17 Aug 2020 08:04:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=/xBv5oKSzFnHZuXM15iOeTR46m0pZFuwaBAOkOFtCPA=; b=0j/phERaFX8UlsStJs7GF0TiZ oYn84j8zM3xW7dqUqgOkXX4D3+oykir9K3I/Lucd71YAlMqS898sHU4UZnXzMUFhL30Ph0tC6jZGD g+d8uWIMbbHObawCgmglkA+gSdj/kpf4+0puRWAkeoOCjLiU3IZta5vAE6PXd75n0McqkyR90LgoM GrcbV2h0wjXXEWurbmw8zZcyxtxTnTKz6BOB1WntEEeYIjNwnbOhNJ+eHpGoaWNY3iDwZntfUCegs 7xkmoIAWecl0kqiKF6waCG8dTfxDk0boUqScm3RinYWpTycDum9+e+IeOLoH97kqT5YGru/FFH+gb ZiAI3vCXQ==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:61727 helo=[192.168.1.14]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1k7gg3-003DsE-ST; Mon, 17 Aug 2020 11:04:04 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_A2ABF8F2-4625-4D88-9D75-1362E4B94DAC" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Joseph Touch In-Reply-To: Date: Mon, 17 Aug 2020 08:03:59 -0700 Cc: "architecture-discuss@ietf.org" Message-Id: <3E4ACDE8-2DA4-45FC-9890-71CE93982182@strayalpha.com> References: <754DE168-DF3B-4471-A145-39C6143E538A@comcast.net> <1fd2ed7d-d4bc-c5b7-9a4a-7966d5e60513@gmail.com> <20200817074637.GW62842@faui48f.informatik.uni-erlangen.de> To: Andrew Campling X-Mailer: Apple Mail (2.3608.120.23.2.1) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [arch-d] A Public Option for the Core X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2020 15:04:25 -0000 --Apple-Mail=_A2ABF8F2-4625-4D88-9D75-1362E4B94DAC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Aug 17, 2020, at 6:55 AM, Andrew Campling = wrote: >=20 >> ... My personal preference is for networks to be transparent in the = way that they manage traffic (if at all) so that I can choose my network = based on what they do. Hmm. How many *choices* do you have? The last time I looked, over 1/3 of the US had only one ISP, i.e., no = choice. I=E2=80=99m in the metro area of the second largest US city and = have 2 =E2=80=9Cchoices=E2=80=9D for high-capacity connectivity (i.e., = not cellular), one of which is nearly bankrupt. And let=E2=80=99s say I get both of those - it=E2=80=99s not like I can = run apps connected to different WIFI access points at the same time from = a single host. Joe --Apple-Mail=_A2ABF8F2-4625-4D88-9D75-1362E4B94DAC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Aug 17, 2020, at 6:55 AM, Andrew Campling <andrew.campling@419.consulting> wrote:

... =  My personal preference is for networks to be transparent in the = way that they manage traffic (if at all) so that I can choose my network = based on what they = do.

Hmm. How many *choices* do you have?

The last time I looked, over 1/3 of the US had = only one ISP, i.e., no choice. I=E2=80=99m in the metro area of the = second largest US city and have 2 =E2=80=9Cchoices=E2=80=9D for = high-capacity connectivity (i.e., not cellular), one of which is nearly = bankrupt.

And let=E2=80=99s say I = get both of those - it=E2=80=99s not like I can run apps connected to = different WIFI access points at the same time from a single = host.

Joe

= --Apple-Mail=_A2ABF8F2-4625-4D88-9D75-1362E4B94DAC-- From nobody Mon Aug 17 08:41:10 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE9783A0B94 for ; Mon, 17 Aug 2020 08:41:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 5QCx5byzCw4G for ; Mon, 17 Aug 2020 08:41:06 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAD443A0EC8 for ; Mon, 17 Aug 2020 08:40:49 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 62A29548621; Mon, 17 Aug 2020 17:40:44 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 5C036440059; Mon, 17 Aug 2020 17:40:44 +0200 (CEST) Date: Mon, 17 Aug 2020 17:40:44 +0200 From: Toerless Eckert To: Andrew Campling Cc: Brian E Carpenter , Joe Touch , John Day , "architecture-discuss@ietf.org" Message-ID: <20200817154044.GZ62842@faui48f.informatik.uni-erlangen.de> References: <754DE168-DF3B-4471-A145-39C6143E538A@comcast.net> <1fd2ed7d-d4bc-c5b7-9a4a-7966d5e60513@gmail.com> <20200817074637.GW62842@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [arch-d] Fwd: A Public Option for the Core X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2020 15:41:09 -0000 On Mon, Aug 17, 2020 at 01:55:13PM +0000, Andrew Campling wrote: > > > On Aug 17, 2020, at 03:46, Toerless Eckert wrote: > > > > John, Joe, Brian: > > > > All great discussion points, but i am not sure if JohnD's starting > > point of "no deductive adaptation of behavior" is really mandatory > > and/or sufficient for *I* net neutrality. Aka: Do we even have an > > approved and complete *I* "net neutrality" definition ? If so, where ? > > You seem to be assuming that "net neutrality" is always a good thing? My personal preference is for networks to be transparent in the way that they manage traffic (if at all) so that I can choose my network based on what they do. A network without, for example, any form of QoS might perform very poorly for at least some applications. I was only asking for definitions of net neutrality. I fully agree with your statement. I hope there is no definition of net neutrality that would prohibit such differentiation of service level objectives of different traffic (which hopefully is a broder and more accurate term than QoS). > > Btw, IMHO: Having an application tell the network exactly what it > > wants from the network is quite a challenging task for applications. > > When i worked with enterprise application developers, they wouldn't > > even want to bother to understand what differences in service from the > > network would best help the application. > > This point I agree with. In general, the level of knowledge of networks by applications developers can be very low (and vice versa), they exist in very different worlds. Most advanced SLO (service level objective) knowledge IMHO can be found in applications resulting from vertically integrated development. Aka: Applications written on behalf of an organization that is capable and happy to provision network services to support SLO that makes the application perform best: enterprises, self-owned data-centers, defense, space, IoT (transportation, oil&gas, building integration,...). service provider networks only came into play when all those mission centric networks where outsourced or had to be merged into common infrastructures. Forgetting this history is one of the key reason why we are struggling of driving QoS/SLO support forward. > > In classical enterprise environments, this trusted mapping layer could > > typically be a nework device (given how applications in enterprise are > > subject to a lot of control by the enterprise operator anyhow). > > In typical residential environment, the trusted mapping would likely > > best be the browser, given how that performs all type of control > > operations against applications anyhow. > > Whilst I believe that I understand your point, I'm not at all convinced that, in residential environments, delegation of trusted mapping to browsers makes a lot of sense. That seems to present a fine attack service for future exploitation. No doubt others will have different views though. Browsers do provide a well constrained environment for applications, and there is an active SDO (w3c) defining those standards. Even with some help from IETF (RTCweb for example). Thats why purely from the perspective of an SDO, the chance to define standards is better for this option. If you take a random app and tried for the OS to do the mapping, there is no standard.For example, microsoft had a great mapping scheme as early as windows XP (or before, i only started to use it with XP) to trigger diffserv/intserv. configured for different apps by the windows administrator (e.g.: across an enterprise). I have seen enterprises well utilizing this windows infrastructure. Alas, AFAIK, this never trickled through across other OSs because obviously Microsoft tried to leverage this as a competitive differentiator, and the more application traffic became Internet centric, the less relevant this became. Likewise, all DPI/QoS mapping in routers is of course also vendor proprietary, even though there is of course a lot of commonality across many vendors. Aka: From the perspective of an SDO the question is firt what the architectural APIs are to be defined. The instances through which the mapping could be done (browser,OS, router, other?) could then even be proprietary adaptations (ideally standardized too). Cheers Toerless > Andrew > > -----Original Message----- > From: Toerless Eckert > Sent: 17 August 2020 08:47 > To: Brian E Carpenter > Cc: Joe Touch ; John Day ; architecture-discuss@ietf.org > Subject: Re: [arch-d] Fwd: A Public Option for the Core > > John, Joe, Brian: > > All great discussion points, but i am not sure if JohnD's starting point of "no deductive adaptation of behavior" is really mandatory and/or sufficient for *I* net neutrality. Aka: Do we even have an approved and complete *I* "net neutrality" definition ? If so, where ? > > Btw, IMHO: Having an application tell the network exactly what it wants from the network is quite a challenging task for applications. > When i worked with enterprise application developers, they wouldn't even want to bother to understand what differences in service from the network would best help the application. > > Hence we thought of a framework where the application would instead attribute traffic as to what it is, e.g.: application FOO, wihthin FOO floX, > e.g.: X = audio/video/... Aka: Whatever the application developer was able/ willing to tell. > > Then one can have a trusted layer that would map this information to actual network service requirements/advisory information. > > In classical enterprise environments, this trusted mapping layer could typically be a nework device (given how applications in enterprise are subject to a lot of control by the enterprise operator anyhow). > In typical residential environment, the trusted mapping would likely best be the browser, given how that performs all type of control operations against applications anyhow. > > Cheers > Toerless > > On Mon, Aug 17, 2020 at 08:24:06AM +1200, Brian E Carpenter wrote: > > On 17-Aug-20 03:01, Joe Touch wrote: > > > And the second is that service level implies connection. It only requires the network understands a label *I* control, rather than trying to infer one from the packet contents. > > > > However, it does need some kind of flow state (whether flows are individual or aggregated) in the forwarding queues. Not that this is a new argument; we had it in the diffserv WG many years ago and it continues to this day in TSVWG. > > > > I don't think this really affects the basic arguments for a "public core". It just indicates that transit networks don't need to be strictly best effort and stateless in order to be neutral. > > > > Brian > > > > > > > > Joe > > > > > >> On Aug 16, 2020, at 3:19 AM, John Day wrote: > > >> > > >> ??? > > >> > > >>> Begin forwarded message: > > >>> > > >>> *From: *John Day > >>> > > > >>> *Subject: **Re: [arch-d] A Public Option for the Core* > > >>> *Date: *August 16, 2020 at 06:18:04 EDT > > >>> *To: *John Grant > > > >>> > > >>> No, that is not true. Your first mistake is that there is a control plane. > > >>> > > >>> John > > >>> > > >>>> On Aug 16, 2020, at 06:02, John Grant > wrote: > > >>>> > > >>>> On 16/08/2020 02:48, Joseph Touch wrote: > > >>>>> *I* want apps to be able to get different service from the network and to pay differently for them if needed, but *never* to have the network infer or enforce that mapping. > > >>>> Of course, if you're going to do that -- have the application negotiate a particular kind of service rather than have the network "inspect" the packets and guess what service is needed -- you need a control plane protocol (let's call it "signalling") to do the negotiation, and you no longer have the connectionless/stateless paradigm on which IP is founded. > > >>>> > > >>>> -- > > >>>> John Grant > > >>>> Nine Tiles, Cambridge, England > > >>>> +44 1223 862599 and +44 1223 511455 > > >>>> http://www.ninetiles.com > > >>>> > > >>>> _______________________________________________ > > >>>> Architecture-discuss mailing list Architecture-discuss@ietf.org > > >>>> https://www.ietf.org/mailman/listinfo/architecture-discuss > > >>> > > >> > > >> _______________________________________________ > > >> Architecture-discuss mailing list > > >> Architecture-discuss@ietf.org > > >> https://www.ietf.org/mailman/listinfo/architecture-discuss > > > > > > _______________________________________________ > > > Architecture-discuss mailing list > > > Architecture-discuss@ietf.org > > > https://www.ietf.org/mailman/listinfo/architecture-discuss > > > > > > > _______________________________________________ > > Architecture-discuss mailing list > > Architecture-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/architecture-discuss > > -- > --- > tte@cs.fau.de > -- --- tte@cs.fau.de From nobody Mon Aug 17 08:47:12 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D59193A0DAA for ; Mon, 17 Aug 2020 08:47:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.847 X-Spam-Level: X-Spam-Status: No, score=-2.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.949, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 M0yeFF-W_uzN for ; Mon, 17 Aug 2020 08:47:09 -0700 (PDT) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 B530B3A0EC8 for ; Mon, 17 Aug 2020 08:47:08 -0700 (PDT) Received: from xse505.mail2web.com ([66.113.197.251] helo=xse.mail2web.com) by mx18.antispamcloud.com with esmtp (Exim 4.92) (envelope-from ) id 1k7hKw-0004n1-R6 for architecture-discuss@ietf.org; Mon, 17 Aug 2020 17:46:49 +0200 Received: from xsmtp21.mail2web.com (unknown [10.100.68.60]) by xse.mail2web.com (Postfix) with ESMTPS id 4BVd59229czVns for ; Mon, 17 Aug 2020 08:19:57 -0700 (PDT) Received: from [10.5.2.14] (helo=xmail04.myhosting.com) by xsmtp21.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1k7gvV-0002TW-4b for architecture-discuss@ietf.org; Mon, 17 Aug 2020 08:19:57 -0700 Received: (qmail 14629 invoked from network); 17 Aug 2020 15:19:57 -0000 Received: from unknown (HELO [192.168.1.107]) (Authenticated-user:_huitema@huitema.net@[172.58.43.0]) (envelope-sender ) by xmail04.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 17 Aug 2020 15:19:56 -0000 To: Joseph Touch , Toerless Eckert Cc: architecture-discuss@ietf.org References: <754DE168-DF3B-4471-A145-39C6143E538A@comcast.net> <1fd2ed7d-d4bc-c5b7-9a4a-7966d5e60513@gmail.com> <20200817074637.GW62842@faui48f.informatik.uni-erlangen.de> <60B2B44D-5E6D-4CB2-AD63-1A8CB846BFA3@strayalpha.com> From: Christian Huitema Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mDMEXtavGxYJKwYBBAHaRw8BAQdA1ou9A5MHTP9N3jfsWzlDZ+jPnQkusmc7sfLmWVz1Rmu0 J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PoiWBBMWCAA+FiEEw3G4 Nwi4QEpAAXUUELAmqKBYtJQFAl7WrxsCGwMFCQlmAYAFCwkIBwIGFQoJCAsCBBYCAwECHgEC F4AACgkQELAmqKBYtJQbMwD/ebj/qnSbthC/5kD5DxZ/Ip0CGJw5QBz/+fJp3R8iAlsBAMjK r2tmyWyJz0CUkVG24WaR5EAJDvgwDv8h22U6QVkAuDgEXtavGxIKKwYBBAGXVQEFAQEHQJoM 6MUAIqpoqdCIiACiEynZf7nlJg2Eu0pXIhbUGONdAwEIB4h+BBgWCAAmFiEEw3G4Nwi4QEpA AXUUELAmqKBYtJQFAl7WrxsCGwwFCQlmAYAACgkQELAmqKBYtJRm2wD7BzeK5gEXSmBcBf0j BYdSaJcXNzx4yPLbP4GnUMAyl2cBAJzcsR4RkwO4dCRqM9CHpVJCwHtbUDJaa55//E0kp+gH Message-ID: <0e575946-dfd4-7753-8c34-47987d0b3c7e@huitema.net> Date: Mon, 17 Aug 2020 08:19:59 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <60B2B44D-5E6D-4CB2-AD63-1A8CB846BFA3@strayalpha.com> Content-Type: multipart/alternative; boundary="------------2071ABA806FF67575C1C2484" Content-Language: en-US X-Originating-IP: 66.113.197.251 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 66.113.197.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.197.0/24@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.15) X-Recommended-Action: accept X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0Uc1Z+hCSaILZIw3vLzlsGSpSDasLI4SayDByyq9LIhVUZbR67CQ7/vm /hHDJU4RXkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDsYLBcJLyHnVrULITPs15U6ts NHuRxlWqWR9fNqLY1ai4Dcwf+CZK8NXgy3In+fX7qYHlpECSsoxLtktFfjAAAFO05s+oip5EC/YK rMQ9+O9t+TYaqvvx766D6vBkj4PuYZsDfA+C63qRuwF/FjcGPDzNg5nLVJLqiE3T2fGty7mOo0r3 6TvtZGZKJo7Ywel+UOUPX0VHiKUyAtskn6r56i8KMZYGrZmgW9KwYivcW5A61Ks3CiInn/dDFS2W PS2yGYffiENaEvSwZ91SD/eSc+7o0ZSfcEjJYb2rnSV2fRCARv6mkfvK/UihTJjyS3/OdDr2WLJq FULjiIcCiyuiCgTQeC2dL1Bxyk8yV+29SYS0kEOL0o9EBIpturfzKMtFD1+RO9x9UH6x/+ZJK1fw q9G5tr1naPLrD+uYvNqtQnWYBq6S+OMHcfXl6o0I271KKTjECb0PwpN4olPuA0AI937kIM09yvSV B0zYhsH8AJscf1pPDHIpzyRJIAFazjKWyDxxCxxrsm1URHCkCrGekkK4G+F9iVA2rkbFj7qgW3L2 E1fQaKDDAkslbTQXAHOWL1MD8t8dBWLQjRG9dLB8kAixxLw9Tqj+m4GeC+uhnIAYOuoLOTrs2MSY MOWrSMXjQ74yPwmHuVj8tPrdUT9Gs8+ADlOi46n1PALad1UBUTOcTD53rSwSTIedTYkUaByAMod+ Su3cUNt/0umLnsd0MJoiu8eNlY3cwoWTHujvw4nfv4Rl05n4RPg8dvzcszF60JczxCjNbhVGwrVA ijGFu7zpwlGzT4HD3EMMzICh8kMVKPqpdskk5LxBR/9t1zMMNgZ00xRl+f8iOCsvtWSXGxqnOR+D xGR3qCP3ei1hX999s+yzMCxnaIvRTEOY/XUFLzItWCgLp9eSUEiS8gk+ZPjEzm1SsR8v3aJbN/NZ fa/X7fXWg6J5cHei57l/ibtd X-Report-Abuse-To: spam@quarantine11.antispamcloud.com Archived-At: Subject: Re: [arch-d] A Public Option for the Core X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2020 15:47:11 -0000 This is a multi-part message in MIME format. --------------2071ABA806FF67575C1C2484 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 8/17/2020 7:47 AM, Joseph Touch wrote: > Hi, Toerless, > >> On Aug 17, 2020, at 12:46 AM, Toerless Eckert > > wrote: >> >> Btw, IMHO: Having an application tell the network exactly what it >> wants from the network is quite a challenging task for applications. >> ... >> >> Hence we thought of a framework where the application would instead >> attribute traffic as to what it is, e.g.: application FOO, wihthin >> FOO floX, >> e.g.: X =3D audio/video/... =C2=A0Aka: Whatever the application develo= per >> was able/ >> willing to tell. >> >> Then one can have a trusted layer that would map this information to >> actual network service requirements/advisory information. > > That=E2=80=99s an implementation detail inside the endpoint. The *netwo= rk* > should not be doing that inference: > > a) because it is typically made to favor the provider, not the user > b) because it=E2=80=99s often incorrect, either because the needed info= isn=E2=80=99t > available (encryption) or deliberately obscured (running DNS over > ports other than 53) At the bottom are issues of knowledge and trust. As Toerless points out, knowledge itself is hard. Application developers have a hard time understanding the network service that they actually want. Even examples that appear trivial, like video, are not: the video refresh rate and the desired definition depends on whether the video is displayed as a post stamp, as a square in a grid, or full screen, not to mention adaptive coding to actual images. Asking applications to label their traffic leads to compromises. =46rom the provider point of view, trusting the labels set by application= s is fraught with a different kind of compromise. What if every application pretended to be a real time service requiring super high quality of service? What prevents the application from lying? Would that lead to collapse? Those fears are very much there, which is why network providers tend to rely on DPI, and not use application labels much. In theory, labels could be trusted if the users were paying for the extra service. In practice, paying for extra service happens very rarely. First, there is the knowledge issue, why would applications incur extra costs without knowing why? Then, there is the interconnection issue. Most network paths involve several network providers. The one with a business relation with the user might be paid for the extra service, but what about the others? That would require an agreed framework allowing for example traffic providers to charge the ISP for the labelled traffic that they emit. Good luck with that. > > My broader concern is the latter part of the second one: I don=E2=80=99= t like > the impact of anti-inference strategies on network architecture. It > tends to force designers to reinvent the Internet at other layers > (inside HTTP, e.g.). Or to encrypt everything, which is very much the current trend. And to add padding and cover traffic to try defeat fingerprinting. And possibly to deploy end-to-end FEC. > Ultimately, there are only a few things the network can do with a > packet: forward it, queue it, or drop it. Having classes of service > that don=E2=80=99t map directly to those behaviors is an invitation for= > unnecessary state and complexity anyway. > > Back to neutrality, though, the point is that the *network* should be > neutral to the user and use of a service, not that there should be > only one service. I don't know that. Given the knowledge and trust issue, one-size-fits-all looks actually very practical. That does mean a compromise, because the network should allow those applications that want low latency to get it, but should not limit the bandwidth that applications can use if it is available. That probably requires more research and development in active queue management, and in congestion control algorithms that can cooperate with active queue management and deliver the profile that fits the application. -- Christian Huitema --------------2071ABA806FF67575C1C2484 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 8/17/2020 7:47 AM, Joseph Touch wrote:
Hi, Toerless,

On Aug 17, 2020, at 12:46 AM, Toerless Eckert <tte@cs.fau.de> wrote:

Btw, IMHO: Having an application tell the network exactly what it
wants from the network is quite a challenging task for applications.
...

Hence we thought of a framework where the application would instead
attribute traffic as to what it is, e.g.: application FOO, wihthin FOO floX,
e.g.: X = audio/video/...  Aka: Whatever the application developer was able/
willing to tell.

Then one can have a trusted layer that would map this information to
actual network service requirements/advisory information.

That’s an implementation detail inside the endpoint. The *network* should not be doing that inference:

a) because it is typically made to favor the provider, not the user
b) because it’s often incorrect, either because the needed info isn’t available (encryption) or deliberately obscured (running DNS over ports other than 53)

At the bottom are issues of knowledge and trust. As Toerless points out, knowledge itself is hard. Application developers have a hard time understanding the network service that they actually want. Even examples that appear trivial, like video, are not: the video refresh rate and the desired definition depends on whether the video is displayed as a post stamp, as a square in a grid, or full screen, not to mention adaptive coding to actual images. Asking applications to label their traffic leads to compromises.

From the provider point of view, trusting the labels set by applications is fraught with a different kind of compromise. What if every application pretended to be a real time service requiring super high quality of service? What prevents the application from lying? Would that lead to collapse? Those fears are very much there, which is why network providers tend to rely on DPI, and not use application labels much.

In theory, labels could be trusted if the users were paying for the extra service. In practice, paying for extra service happens very rarely. First, there is the knowledge issue, why would applications incur extra costs without knowing why? Then, there is the interconnection issue. Most network paths involve several network providers. The one with a business relation with the user might be paid for the extra service, but what about the others? That would require an agreed framework allowing for example traffic providers to charge the ISP for the labelled traffic that they emit. Good luck with that.


My broader concern is the latter part of the second one: I don’t like the impact of anti-inference strategies on network architecture. It tends to force designers to reinvent the Internet at other layers (inside HTTP, e.g.).

Or to encrypt everything, which is very much the current trend. And to add padding and cover traffic to try defeat fingerprinting. And possibly to deploy end-to-end FEC.


Ultimately, there are only a few things the network can do with a packet: forward it, queue it, or drop it. Having classes of service that don’t map directly to those behaviors is an invitation for unnecessary state and complexity anyway.

Back to neutrality, though, the point is that the *network* should be neutral to the user and use of a service, not that there should be only one service.

I don't know that. Given the knowledge and trust issue, one-size-fits-all looks actually very practical. That does mean a compromise, because the network should allow those applications that want low latency to get it, but should not limit the bandwidth that applications can use if it is available. That probably requires more research and development in active queue management, and in congestion control algorithms that can cooperate with active queue management and deliver the profile that fits the application.

-- Christian Huitema


--------------2071ABA806FF67575C1C2484-- From nobody Mon Aug 17 09:17:48 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F034C3A11F9 for ; Mon, 17 Aug 2020 09:17:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.119 X-Spam-Level: X-Spam-Status: No, score=-1.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779] 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 qDhqabbryNJP for ; Mon, 17 Aug 2020 09:17:45 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA4513A11F6 for ; Mon, 17 Aug 2020 09:17:44 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 95C1654802F; Mon, 17 Aug 2020 18:17:38 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 8DDE0440059; Mon, 17 Aug 2020 18:17:38 +0200 (CEST) Date: Mon, 17 Aug 2020 18:17:38 +0200 From: Toerless Eckert To: Joseph Touch Cc: architecture-discuss@ietf.org Message-ID: <20200817161738.GA62842@faui48f.informatik.uni-erlangen.de> References: <754DE168-DF3B-4471-A145-39C6143E538A@comcast.net> <1fd2ed7d-d4bc-c5b7-9a4a-7966d5e60513@gmail.com> <20200817074637.GW62842@faui48f.informatik.uni-erlangen.de> <60B2B44D-5E6D-4CB2-AD63-1A8CB846BFA3@strayalpha.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <60B2B44D-5E6D-4CB2-AD63-1A8CB846BFA3@strayalpha.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [arch-d] A Public Option for the Core X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2020 16:17:47 -0000 On Mon, Aug 17, 2020 at 07:47:04AM -0700, Joseph Touch wrote: > > Then one can have a trusted layer that would map this information to > > actual network service requirements/advisory information. > > That???s an implementation detail inside the endpoint. See my prior answeer to andrew. Just because something may end up as an implementation inside an endpoint doesn't mean it couldn't be good work to standardize the abstract API. Also, what is a host. A bog with a bunch of containers orchestrated together via linux bridges ? ;-) Scott McNealy: The Network is the Computer. Aka: Just a matter of how we model things. I know, for a lot of old-time IETF'er, looking inside a physical box s heresy, but hey, we are even getting TAPS interface RFCs as standards track documents (horray!). > The *network* should not be doing that inference: > > a) because it is typically made to favor the provider, not the user And folks in ISOC may argue that in other countries it will favour governments. And i think we understand these challenges and can build solutions accordingly. > b) because it???s often incorrect, either because the needed info isn???t available (encryption) or deliberately obscured (running DNS over ports other than 53) Sure, IMHO just a technical challenge we can solve. And remember that in vertically integrated networks (see BrianC limited domains) visibility by the network is desired: In a vertial network solution, the application LOVEs to expose the RTP header so that jitter,latency,loss,reordering per flow can be monitored hop-by-hop by the network, problems quickly be isolated and fixed. If an OOT application does not want that service, it can encrypt everything. Why not.. I am sure the OOT will do exactly the same unencypted headers within its own DC for troubleshooting, diagnostics. Aka: the only problem we have in IETF is that we hear mostly from only one side of the spectrum of relevant options, and thats the OTT that do want to prohibit anything more than cheapest cost best effort service, because that type of network service is the basis of their business model and anything better wold be competitive to their business. > My broader concern is the latter part of the second one: I don???t like the impact of anti-inference strategies on network architecture. It tends to force designers to reinvent the Internet at other layers (inside HTTP, e.g.). Yes. But even worse is as i said above the influence mongering to ensure that no alternative technologies are allowed to be worked on in the IETF - by making the sham argument about what is or is not good for "the Internet". Such as when SPUD/PLUS where acted against. To make a funny analogy: There are use cases that rightfully so go even much further in their anti-inference/perpass strategy than the OTT, but they do not go running around the IETF trying to argue their way is the only way the IETF should go. Aka: If you want to see the (crrent) final word on protection against perpass: draft-ietf-ipsecme-iptfs ;-)) > Ultimately, there are only a few things the network can do with a packet: forward it, queue it, or drop it. Having classes of service that don???t map directly to those behaviors is an invitation for unnecessary state and complexity anyway. You forgot FEC insert/delete , duplication&merge, or even more general network coding). And of course there is a huge variety of differences in service level objective outcomes by how you forward (QoS routing), and/or how you queue. Having worked for decades on per-flow behavior in routers i do think that the most interesting area to explore is one which does not require per-flow state but allows to distinguish SLO on a per-packet level. This would allow us to introduce INtServ like functionality with even better than DiffServ scalability. > Back to neutrality, though, the point is that the *network* should be neutral to the user and use of a service, not that there should be only one service. Well... I would love to say "exactly right", but: a) Is there actually any accepted definition of net neutrality that says exactly this ? b) Even that definition goes way beyond differentiation in any other type of market. E.g.: If you are a tier1 OTT like e.g.: netflix, amazom prime, your ability to get your cache into pops of access SPs or peering bandwidth etc. is just going to be a lot better than a tier2 OTT will get. Aka: We already today have the same type of "volume of the deal" negotiations. But we have this in any other market as well. German example of course being: oh, you want to buy 50,000 cars for your employees... of yourse you get better pricing and/or get them earlier or get specials we don't offer to other customers. Aka: How do we argue that selling of packets should be different than selling of cars ? Toerless > Joe > From nobody Mon Aug 17 09:43:07 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 017DE3A0D47 for ; Mon, 17 Aug 2020 09:43:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.118 X-Spam-Level: X-Spam-Status: No, score=-1.118 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] 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 vzKDt4TrSzAn for ; Mon, 17 Aug 2020 09:43:01 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF8083A0D42 for ; Mon, 17 Aug 2020 09:43:00 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 3ECBD54802F; Mon, 17 Aug 2020 18:42:56 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 370A5440059; Mon, 17 Aug 2020 18:42:56 +0200 (CEST) Date: Mon, 17 Aug 2020 18:42:56 +0200 From: Toerless Eckert To: Christian Huitema Cc: Joseph Touch , architecture-discuss@ietf.org Message-ID: <20200817164256.GB62842@faui48f.informatik.uni-erlangen.de> References: <754DE168-DF3B-4471-A145-39C6143E538A@comcast.net> <1fd2ed7d-d4bc-c5b7-9a4a-7966d5e60513@gmail.com> <20200817074637.GW62842@faui48f.informatik.uni-erlangen.de> <60B2B44D-5E6D-4CB2-AD63-1A8CB846BFA3@strayalpha.com> <0e575946-dfd4-7753-8c34-47987d0b3c7e@huitema.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0e575946-dfd4-7753-8c34-47987d0b3c7e@huitema.net> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [arch-d] A Public Option for the Core X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2020 16:43:06 -0000 On Mon, Aug 17, 2020 at 08:19:59AM -0700, Christian Huitema wrote: > Given the knowledge and trust issue, > one-size-fits-all looks actually very practical. That does mean a > compromise, because the network should allow those applications that > want low latency to get it, but should not limit the bandwidth that > applications can use if it is available. That probably requires more > research and development in active queue management, and in congestion > control algorithms that can cooperate with active queue management and > deliver the profile that fits the application. Thats again the look for networks we currently call "the Internet", and quite valid there. But certainly not the only type of networks IETF should be interested in. When you look at managing traffic flows in e.g.: networks of an airplane, you will see every individual flow being designed, and planned for before the plane is built. And those parameters ar then embodied into the network during plane building. I would call this the other end of the spectrum. Instead of just talking about some of the tools (CC, ACM), it would be nice to try to set goals first, to see if we could get agreement there: -> I would like traffic to get the same throughput under congestion whatever its RTT is. -> I would like for traffic to get bandwidth share indpendent of the number of 5 tuple flows it utilizes (no gaming the system). But rather fair per subscriber (weighted by how much the subscriber pays). -> I would like to be able for traffic to indicate preferences for lower latency or higher throughput... If you ask for lower latency, you get less throughput. -> Goodput always > 95% That would be a start for the most simple "one-size-fits" all i could imagine. But there is a lot more things i would like to factor in beyond that. Cheers Toerless > -- Christian Huitema > > -- --- tte@cs.fau.de From nobody Mon Aug 17 10:43:58 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11C303A0D95 for ; Mon, 17 Aug 2020 10:43:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.849 X-Spam-Level: X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.949, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham 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 BfEJ0u-BX5Tu for ; Mon, 17 Aug 2020 10:43:54 -0700 (PDT) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 26D2E3A0D89 for ; Mon, 17 Aug 2020 10:43:51 -0700 (PDT) Received: from xse475.mail2web.com ([66.113.197.221] helo=xse.mail2web.com) by mx168.antispamcloud.com with esmtp (Exim 4.92) (envelope-from ) id 1k7jAY-0012l1-MJ for architecture-discuss@ietf.org; Mon, 17 Aug 2020 19:43:42 +0200 Received: from xsmtp21.mail2web.com (unknown [10.100.68.60]) by xse.mail2web.com (Postfix) with ESMTPS id 4BVgs51Qz6zCGxS for ; Mon, 17 Aug 2020 10:24:41 -0700 (PDT) Received: from [10.5.2.16] (helo=xmail06.myhosting.com) by xsmtp21.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1k7isD-0008Q1-34 for architecture-discuss@ietf.org; Mon, 17 Aug 2020 10:24:41 -0700 Received: (qmail 10115 invoked from network); 17 Aug 2020 17:24:40 -0000 Received: from unknown (HELO [192.168.1.107]) (Authenticated-user:_huitema@huitema.net@[172.58.43.0]) (envelope-sender ) by xmail06.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 17 Aug 2020 17:24:40 -0000 To: Toerless Eckert Cc: Joseph Touch , architecture-discuss@ietf.org References: <754DE168-DF3B-4471-A145-39C6143E538A@comcast.net> <1fd2ed7d-d4bc-c5b7-9a4a-7966d5e60513@gmail.com> <20200817074637.GW62842@faui48f.informatik.uni-erlangen.de> <60B2B44D-5E6D-4CB2-AD63-1A8CB846BFA3@strayalpha.com> <0e575946-dfd4-7753-8c34-47987d0b3c7e@huitema.net> <20200817164256.GB62842@faui48f.informatik.uni-erlangen.de> From: Christian Huitema Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mDMEXtavGxYJKwYBBAHaRw8BAQdA1ou9A5MHTP9N3jfsWzlDZ+jPnQkusmc7sfLmWVz1Rmu0 J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PoiWBBMWCAA+FiEEw3G4 Nwi4QEpAAXUUELAmqKBYtJQFAl7WrxsCGwMFCQlmAYAFCwkIBwIGFQoJCAsCBBYCAwECHgEC F4AACgkQELAmqKBYtJQbMwD/ebj/qnSbthC/5kD5DxZ/Ip0CGJw5QBz/+fJp3R8iAlsBAMjK r2tmyWyJz0CUkVG24WaR5EAJDvgwDv8h22U6QVkAuDgEXtavGxIKKwYBBAGXVQEFAQEHQJoM 6MUAIqpoqdCIiACiEynZf7nlJg2Eu0pXIhbUGONdAwEIB4h+BBgWCAAmFiEEw3G4Nwi4QEpA AXUUELAmqKBYtJQFAl7WrxsCGwwFCQlmAYAACgkQELAmqKBYtJRm2wD7BzeK5gEXSmBcBf0j BYdSaJcXNzx4yPLbP4GnUMAyl2cBAJzcsR4RkwO4dCRqM9CHpVJCwHtbUDJaa55//E0kp+gH Message-ID: <439caeb9-481d-6123-ba59-ce25717cd4ae@huitema.net> Date: Mon, 17 Aug 2020 10:24:43 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <20200817164256.GB62842@faui48f.informatik.uni-erlangen.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US X-Originating-IP: 66.113.197.221 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 66.113.197.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.197.0/24@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.15) X-Recommended-Action: accept X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0Uc1Z+hCSaILZIw3vLzlsGSpSDasLI4SayDByyq9LIhVUZbR67CQ7/vm /hHDJU4RXkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDsYLBcJLyHnVrULITPs15U6ts NHuRxlWqWR9fNqLY1ai4Dcwf+CZK8NXgy3In+fX7xVMi9kSynkyW1vKeVUyeulO05s+oip5EC/YK rMQ9+O9t+TYaqvvx766D6vBkj4PutP0Dzal8myJ8vVhoWnSKP2MRQY4sL7fGBhvCp6oW0F28pnvZ XWSe7jV34Pxn0vH1Lz/y+awqhw7CmTPsWtYsCV/oEQh3zFZ7AJOfdc5NLopVCPmS+MVojfDUugvn Zl+jhHQOLtWk4clq0P6Ltvr/5Zl+BJt+8hYKwgejR0Z9YPn97p3CKmEi95YYeXPNWMiahaC2TJpF rGrq1WX76kTmg5w7R2/M+XaT5BLifEp8KpWu41J1t4cteGI4vH6PuMQp0kaOEXLuWd+6zLg4wp8u XxPcpGyeyPXKNTABBN67jV7JvFCbAD7w3FUirQwmJIqD2OUMeHyTpNN0eXybX/w7/3ZCM0u5uBlK VwmNWN494pWaZ30sdVozPGNttYaP6Q9/2E4JvzZwv3PGBEOc6AcTtGid8j6h6mzVhFB3UGjfs8Kk 1FZ5SzpWjtNrAe6rpkdW7+aVm/NqgKA5dyCxkhdL5g7yNAxIoTne18wgCHBWXWNdeu+6D1xe6+c7 Ft92TZYqkFl4iutyAZRMsedMRRS9foYXc9qTwyHkpkddwmvVLSYan9u1XhzpF3vNmn81pQyLs79q wWQ9VXX3j3CiZ1dw4xxwEiTVJqDh0qKoKsXx5lkVnK0YS3gd+LN4VG99hjvtzI2M6ZNcTIsrWx+O Oa5/69PEFdzaPktprEQ3qb+cP5JBtL9ewJnoHKUNLZpf7DfZZjMv6PN41V03H2/ZNJy1m5Scu7sV encPI85bGjWXuocpzCXI8Q8ncbCRI7u+gO19UCFcnal6WejB4YisLPSIrrdvK/cKOEqlCIPGIfYQ DNJ9yy88fxdoE98JfCUCbwYa X-Report-Abuse-To: spam@quarantine11.antispamcloud.com Archived-At: Subject: Re: [arch-d] A Public Option for the Core X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2020 17:43:57 -0000 On 8/17/2020 9:42 AM, Toerless Eckert wrote: > ... > Instead of just talking about some of the tools (CC, ACM), it would be > nice to try to set goals first, to see if we could get agreement there:= > > -> I would like traffic to get the same throughput under congestion > whatever its RTT is. I agree, but there is a fundamental issue. Flows with short RTT will react faster to changing conditions than flows with shorter RTT, so short term averages will always show some benefit to short delays. > -> I would like for traffic to get bandwidth share indpendent of the > number of 5 tuple flows it utilizes (no gaming the system). But > rather fair per subscriber (weighted by how much the subscriber pays= ). Yes. Basic fairness means all subscribers should be treated the same. At the same time, there are some interesting questions. Assume that the same function could be implemented as an app on my PC and or as a self contained IOT device. Should the IOT device that has its own IP address get more bandwidth than the app that shares the IP address with other apps on the PC? I suppose that this is only a problem for local area networks, since after that all traffic gets to share the subscribed bandwidth, but I could see some needs here. > > -> I would like to be able for traffic to indicate preferences for > lower latency or higher throughput... If you ask for lower latency, > you get less throughput. No. That's where we differ. We have tried designing this sort of two-classes system in the past, modelling that as a game between the application and the network, and trying to define strategies that were robust against player's misbehavior. There is no sign that applications would be ready for that. On the other hand, there is plenty of research and deployment experience for CC algorithms that deliver low latency if the network cooperates: LEDBAT, BBR and L4S come to mind. There is also evidence of algorithms that can lead to large delays especially in presence of buffer bloat: Reno and Cubic. Let's assume that delay-sensitive applications use a delay-minimizing CC algorithm. If the network "isolates" each application in its own queue and serves them fairly, then the LEDBAT users get low delay and the Cubic users get high bandwidth, and everybody is happy. > > -> Goodput always > 95% I don't know how to measure that. But yes of course, we don't want congestion collapse. > > That would be a start for the most simple "one-size-fits" all i could > imagine. But there is a lot more things i would like to factor in beyon= d > that. Sure. But I like your general approach. -- Christian Huitema From nobody Mon Aug 17 11:52:15 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BAE53A0962 for ; Mon, 17 Aug 2020 11:52:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.318 X-Spam-Level: X-Spam-Status: No, score=-1.318 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 Nvrmek0Pupdt for ; Mon, 17 Aug 2020 11:52:12 -0700 (PDT) Received: from server217-4.web-hosting.com (server217-4.web-hosting.com [198.54.116.98]) (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 4D1193A095C for ; Mon, 17 Aug 2020 11:52:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=7EvUKMUGw+deZfZFsKs7TD3rG/x/ZwzXsRojUfoPLGA=; b=BloSI/QNMpkN+L+2t6aiv8Pct 8UQbMMAaAXwUIqcDj77/AnHveZr9f7bl/DpRx7ejWQgAX6SaGkU2+Jp3K0m2QDkLH9R5mOhaK8IVS HG0puPgCC5X6a05hw4cJ9qrcsfBDNj0ucl97OLGSxmAvWEksRWSYXdtS059r03GITYWaX0uUbGf7k jLpJdG++gFzB0wsjh6+okk0uaGgpNjYkuq2RMHkfV1omUPwbNY14Q7V4oCPETCOG6HV6DsaOujNhy d9xg8yHX693kKMJSCYW8e6+dn5TLn9epc2ygY0+sefQ6iHVBzeMb6IT2OUkZ9Yd90HuFu4aqH7XUQ YM4ifpzmQ==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:61916 helo=[192.168.1.14]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1k7kEp-003Daf-5J; Mon, 17 Aug 2020 14:52:11 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_D5E6F9C1-4E65-4455-8FF2-9E9A456B518D" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Joseph Touch In-Reply-To: <0e575946-dfd4-7753-8c34-47987d0b3c7e@huitema.net> Date: Mon, 17 Aug 2020 11:52:06 -0700 Cc: Toerless Eckert , architecture-discuss@ietf.org Message-Id: References: <754DE168-DF3B-4471-A145-39C6143E538A@comcast.net> <1fd2ed7d-d4bc-c5b7-9a4a-7966d5e60513@gmail.com> <20200817074637.GW62842@faui48f.informatik.uni-erlangen.de> <60B2B44D-5E6D-4CB2-AD63-1A8CB846BFA3@strayalpha.com> <0e575946-dfd4-7753-8c34-47987d0b3c7e@huitema.net> To: Christian Huitema X-Mailer: Apple Mail (2.3608.120.23.2.1) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [arch-d] A Public Option for the Core X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2020 18:52:14 -0000 --Apple-Mail=_D5E6F9C1-4E65-4455-8FF2-9E9A456B518D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Aug 17, 2020, at 8:19 AM, Christian Huitema = wrote: >=20 >>> hen one can have a trusted layer that would map this information to >>> actual network service requirements/advisory information. >>=20 >> That=E2=80=99s an implementation detail inside the endpoint. The = *network* should not be doing that inference: >>=20 >> a) because it is typically made to favor the provider, not the user >> b) because it=E2=80=99s often incorrect, either because the needed = info isn=E2=80=99t available (encryption) or deliberately obscured = (running DNS over ports other than 53) > At the bottom are issues of knowledge and trust. >=20 The mapping is hard, but inferring it is only harder (vs. letting the = user/host decide). As to trust, it only matters that an intermediate hasn=E2=80=99t forged = a new header. You don=E2=80=99t need to trust the user - if they want to = map their email to high-priority and pay for that usage, that=E2=80=99s = their business (literally). If that=E2=80=99s more service than they = paid for, then drop packets. Or do you think UPS/DHL/etc should open every 2-day delivery to make = sure it actually had to be there in 2 days? Joe= --Apple-Mail=_D5E6F9C1-4E65-4455-8FF2-9E9A456B518D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Aug 17, 2020, at 8:19 AM, Christian Huitema <huitema@huitema.net>= wrote:

hen one can have a trusted layer that would = map this information to
actual = network service requirements/advisory = information.

That=E2=80=99s an implementation detail inside the endpoint. = The *network* should not be doing that inference:
a) because it is typically made to = favor the provider, not the user
b) because it=E2=80=99= s often incorrect, either because the needed info isn=E2=80=99t = available (encryption) or deliberately obscured (running DNS over ports = other than 53)

At the bottom are issues of knowledge = and trust.

The mapping = is hard, but inferring it is only harder (vs. letting the user/host = decide).

As to = trust, it only matters that an intermediate hasn=E2=80=99t forged a new = header. You don=E2=80=99t need to trust the user - if they want to map = their email to high-priority and pay for that usage, that=E2=80=99s = their business (literally). If that=E2=80=99s more service than they = paid for, then drop packets.

Or do you think UPS/DHL/etc should open = every 2-day delivery to make sure it actually had to be there in 2 = days?

Joe
= --Apple-Mail=_D5E6F9C1-4E65-4455-8FF2-9E9A456B518D-- From nobody Mon Aug 17 11:52:41 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB1A53A1055; Mon, 17 Aug 2020 11:52:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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=gmail.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 VL58exIEwYt0; Mon, 17 Aug 2020 11:52:36 -0700 (PDT) Received: from mail-yb1-xb2b.google.com (mail-yb1-xb2b.google.com [IPv6:2607:f8b0:4864:20::b2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D289C3A0FA9; Mon, 17 Aug 2020 11:52:33 -0700 (PDT) Received: by mail-yb1-xb2b.google.com with SMTP id y134so9994453yby.2; Mon, 17 Aug 2020 11:52:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xZHYRn6htPC2hDmXfSirSouzOkMsZGPSRoOV8DWtao4=; b=ngcC5IAHzMPOn7HhsH7Usf3t3zF4F4eSl/zVSPJfq/scI9ozRIVvsdXPaCIrUpO+L3 ZAXQPhJxsJRkGrlCzQKW2Z3EHsRIFxF4J495HKYdJTduZAYnfIjJjxvIKXNl84CGYjya cnOqE+PBZzjY1OpF1ScOCjO1XbDNrdh72RBPYzGyIyb+O+I0txH67Ds6uSvLmA5clChV QQqKzEXoEXQtpmiJH6ABKBgkZM054+JrgYOGZucd6G0kqxn4za5DRwhKcqKEeJFBz/Qr HEfqO1CdhNawT+PYhs+JnJugzgt2+6NwKrCGyj61lNM2ZeRwSDG5xafoIK2OjyJVgdt9 9d6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xZHYRn6htPC2hDmXfSirSouzOkMsZGPSRoOV8DWtao4=; b=d/1gzwW1Zp/yNFe5EUFiECrfOPYLmjhQpYIuskjZyUJBdVH4EoBXklPKB5poryRxIq qFjl4gCDn3Co4BtlowIqB8fg7y0CuvUttZTRiQyp8xXsToLxFiVQFRayGhsNbreK3Z4y pINlC3lFaOVjfu4x/ZwY2/awvkbh6AN4Ccg/hON35tInnHP1ZUzySr1H/3FQI1j6iWck aSfJ5ENFkB958kl/Rx5XSkQzktqBHW3HC7xJk8O47rJZNZh09ys+MEDMUmBqOTc79D1t 34r8q62DsIkgKIj43UpvCjHO3uuwsB82mqVTRVlrVYS3q+upWa7wkxLW8mHtMw/yOxqG zVVg== X-Gm-Message-State: AOAM530UJ+xf09vWF2QzLlYGPue9jkiRfutAkplfPkM/3eJRIoW5dWXN gwl6Ep+TLTJFMXEtEjE5TFR8fU8z6GRUIdkdpJQ= X-Google-Smtp-Source: ABdhPJwndBZvRC2TytoRaUIf7KDx4LvJAYv9XxpK3/rGd3rGsDlUKeRoWts1LVUPtzEKfJNy2a8IlcN3kCPQMHZsmUU= X-Received: by 2002:a25:40cb:: with SMTP id n194mr21940561yba.380.1597690353019; Mon, 17 Aug 2020 11:52:33 -0700 (PDT) MIME-Version: 1.0 References: <5A5B4DE12C0DAC44AF501CD9A2B01A8D9381CC52@dggemm512-mbs.china.huawei.com> <171DEAE6-BC06-44B8-88E9-64BA20850450@strayalpha.com> In-Reply-To: <171DEAE6-BC06-44B8-88E9-64BA20850450@strayalpha.com> From: Spencer Dawkins at IETF Date: Mon, 17 Aug 2020 13:52:06 -0500 Message-ID: To: Lizhenbin Cc: "architecture-discuss@ietf.org" , "daniel@olddog.co.uk" , "rtgwg@ietf.org" , Joe Touch , panrg-chairs@irtf.org Content-Type: multipart/alternative; boundary="000000000000f3eee905ad1745df" Archived-At: Subject: Re: [arch-d] APN (Application-aware Networking) Mailing List X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2020 18:52:41 -0000 --000000000000f3eee905ad1745df Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Adding the PANRG chairs, in case I get something wrong about PANRG ... On Fri, Aug 14, 2020 at 7:37 PM Joe Touch wrote: > This WG appears to be revisiting the issues of the expired trigtran wg. I= t > might be useful to understand why that did not succeed and whether you ar= e > asking the same question twice and expecting a different answer. > Joe. thank you for nudging me on this thread. PANRG (https://datatracker.ietf.org/rg/panrg/about/) has a draft about the history of Path-Aware Networking ( https://datatracker.ietf.org/doc/draft-irtf-panrg-what-not-to-do/), and why most path-aware networking technologies haven't been deployed, although it seems they should have been deployed (especially to the people who proposed them). TRIGTRAN specifically is covered in https://tools.ietf.org/html/draft-irtf-panrg-what-not-to-do-12#section-5.5, but TRIGTRAN was one of eight technologies considered, and we found enough commonality to justify summarizing what we learned in 12 lessons ( https://tools.ietf.org/html/draft-irtf-panrg-what-not-to-do-12#section-2), and then considering whether what we've learned is still relevant ( https://tools.ietf.org/html/draft-irtf-panrg-what-not-to-do-12#section-3). Some are, some aren't. This document doesn't have any standing in the IETF, other than providing information, but I hope it's helpful for you (full disclosure, I'm the editor). Best, Spencer > Joe > > > On Aug 12, 2020, at 9:25 PM, Lizhenbin wrote: > > > > =EF=BB=BFHi Folks, > > > > The APN mailing list has been created. If you have interest in the work= , > please subscribe. > > > > List address: apn@ietf.org > > Archive: https://mailarchive.ietf.org/arch/browse/apn > > To subscribe: https://www.ietf.org/mailman/listinfo/apn > > > > Purpose: > > This email list is the discussion list for the Application-aware > Networking (APN). Application-aware Networking is a mechanism whereby > traffic flows can be steered and routed within the network to ensure that > the specific service levels needed by applications can be delivered. > > > > This list belongs to IETF area: RTG > > > > > > Look forward to going on to have more discussion in the mailing list. > > > > > > > > Best regards, > > Zhenbin (Robin) > > > > > > > > ________________________________________ > > =E5=8F=91=E4=BB=B6=E4=BA=BA: Architecture-discuss [architecture-discuss= -bounces@ietf.org] =E4=BB=A3=E8=A1=A8 > Lizhenbin [lizhenbin@huawei.com] > > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2020=E5=B9=B47=E6=9C=8829=E6=97= =A5 0:17 > > =E6=94=B6=E4=BB=B6=E4=BA=BA: architecture-discuss@ietf.org; rtgwg@ietf.= org > > =E6=8A=84=E9=80=81: daniel@olddog.co.uk > > =E4=B8=BB=E9=A2=98: [arch-d] APN (Application-aware Networking) Side Me= eting > > > > Hi All, > > We will have the APN side meeting at 12:30 - 14:00 UTC on July 30 > (Thursday). The agenda and the WebEx information is provided in the > following link. > > https://github.com/APN-Community/IETF108-Side-Meeting-APN > > > > There has been several similar work like APN such as SPUD and PLUS. > Recently Network Token work was also proposed. The side meeting is to try > to clarify the scope of APN comparing with other work. The possible > usecases are also proposed for the APN work. Another goal of the side > meeting is to clarify the security and privacy issues which are always > proposed against such application-ware networking work. In RTGWG session > held yesterday, the presentation of APN work discussed the possible > scenarios related with the security and privacy issues. The following > slides is for your reference: > > > https://www.ietf.org/proceedings/108/slides/slides-108-rtgwg-8-rtgwg-apn6= -01 > > > > Since it is a complex cross-area work and there is much background > information, wish you could join the side meeting if you have interest in > the work and your comments and suggestions are appreciated. > > > > > > Best Regards, > > Daniel & Zhenbin (Robin) > > _______________________________________________ > > Architecture-discuss mailing list > > Architecture-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/architecture-discuss > > _______________________________________________ > > Architecture-discuss mailing list > > Architecture-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/architecture-discuss > > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss > --000000000000f3eee905ad1745df Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Adding the PANRG chairs, in case I get something=C2= =A0wrong about=C2=A0PANRG ...=C2=A0

On Fri, Aug 14, 2020 at 7:37 PM Joe Touc= h <touch@strayalpha.com> = wrote:
This WG a= ppears to be revisiting the issues of the expired trigtran wg. It might be = useful to understand why that did not succeed and whether you are asking th= e same question twice and expecting a different answer.

Joe. thank you for nudging me on this thread.=C2=A0
=

PANRG (https://datatracker.ietf.org/rg/panrg/about/) has a draft abou= t the history=C2=A0of Path-Aware Networking (https://datatracker.ietf.or= g/doc/draft-irtf-panrg-what-not-to-do/), and why most path-aware networ= king technologies haven't been deployed, although it seems they should = have been deployed (especially to the people who proposed them).=C2=A0


This document doesn't have any standing in the IETF, other than = providing information, but I hope it's helpful for you (full disclosure= , I'm the editor).

Best,

<= div>Spencer
=C2=A0
Joe

> On Aug 12, 2020, at 9:25 PM, Lizhenbin <lizhenbin@huawei.com> wrote:
>
> =EF=BB=BFHi Folks,
>
> The APN mailing list has been created. If you have interest in the wor= k, please subscribe.
>
> List address: apn@ie= tf.org
> Archive: https://mailarchive.ietf.org/arch/browse/= apn
> To subscribe: https://www.ietf.org/mailman/listinfo/ap= n
>
> Purpose:
> This email list is the discussion list for the Application-aware Netwo= rking (APN). Application-aware Networking is a mechanism whereby traffic fl= ows can be steered and routed within the network to ensure that the specifi= c service levels needed by applications can be delivered.=C2=A0
>
> This list belongs to IETF area: RTG
>
>
> Look forward to going on to have more discussion in the mailing list.<= br> >
>
>
> Best regards,
> Zhenbin (Robin)
>
>
>
> ________________________________________
> =E5=8F=91=E4=BB=B6=E4=BA=BA: Architecture-discuss [architecture-discus= s-bounces@ietf.org] =E4=BB=A3=E8=A1=A8 Lizhenbin [lizhenbin@huawei.com]
> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2020=E5=B9=B47=E6=9C=8829=E6=97= =A5 0:17
> =E6=94=B6=E4=BB=B6=E4=BA=BA: architecture-discuss@ietf.org; rtgwg@ietf.org
> =E6=8A=84=E9=80=81: daniel@olddog.co.uk
> =E4=B8=BB=E9=A2=98: [arch-d] APN (Application-aware Networking) Side M= eeting
>
> Hi All,
> We will have the APN side meeting at 12:30 - 14:00 UTC on July 30 (Thu= rsday). The agenda and the WebEx information is provided in the following l= ink.
> https://github.com/APN-Community/IETF1= 08-Side-Meeting-APN
>
> There has been several similar work like APN such as SPUD and PLUS. Re= cently Network Token work was also proposed. The side meeting is to try to = clarify the scope of APN comparing with other work. The possible usecases a= re also proposed for the APN work. Another goal of the side meeting is to c= larify the security and privacy issues which are always proposed against su= ch application-ware networking work. In RTGWG session held yesterday, the p= resentation of APN work discussed the possible scenarios related with the s= ecurity and privacy issues. The following slides is for your reference:
> https://www.ietf.or= g/proceedings/108/slides/slides-108-rtgwg-8-rtgwg-apn6-01
>
> Since it is a complex cross-area work and there is much background inf= ormation, wish you could join the side meeting if you have interest in the = work and your comments and suggestions are appreciated.
>
>
> Best Regards,
> Daniel & Zhenbin (Robin)
> _______________________________________________
> Architecture-discuss mailing list
> Arc= hitecture-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo= /architecture-discuss
> _______________________________________________
> Architecture-discuss mailing list
> Arc= hitecture-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo= /architecture-discuss

_______________________________________________
Architecture-discuss mailing list
Architec= ture-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/arc= hitecture-discuss
--000000000000f3eee905ad1745df-- From nobody Mon Aug 17 11:59:23 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B75F93A09D9 for ; Mon, 17 Aug 2020 11:59:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 t3fOiknwOqIw for ; Mon, 17 Aug 2020 11:59:15 -0700 (PDT) Received: from server217-4.web-hosting.com (server217-4.web-hosting.com [198.54.116.98]) (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 29E3D3A09CC for ; Mon, 17 Aug 2020 11:59:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=r2B1ij3HOkKboNP1dUSCAhXQyD8QCClxkLe/dRDA20U=; b=KeWi02Z/Ri2iplsxh7pZ/hahO XVQpvLUJDhppmP2QZD5WJWD1ruQ1AnSygb8thiim4vhpZo7HwyonKs/rbtpPh8j8CwUg/jyjyKZ19 6i/4of926ShYzUD6WnplGM1Agww1WhSt3TpwXDD9PoftElGMYso8z9giu8GRbZk/QEi3y30iamTls pE8BTRflvl5JVpEksaq1VmROpOHttjhD80is5QJBWh23CaFDwHN/rK0GyyNR5QUqgYUB50PD2lx83 9mQRmMX87mYiGWPMyvKV5OtqBfnmzhVijSQqb7MCE1/xzzl7frM0jiLlMxxhp1cik1Cpn15Ei5x1u JWY9TNQyw==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:61993 helo=[192.168.1.14]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1k7kLe-003KaV-2l; Mon, 17 Aug 2020 14:59:14 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_4A31397B-9855-4713-9CB7-DAFFFF911E16" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Joseph Touch In-Reply-To: <20200817164256.GB62842@faui48f.informatik.uni-erlangen.de> Date: Mon, 17 Aug 2020 11:59:09 -0700 Cc: Christian Huitema , architecture-discuss@ietf.org Message-Id: References: <754DE168-DF3B-4471-A145-39C6143E538A@comcast.net> <1fd2ed7d-d4bc-c5b7-9a4a-7966d5e60513@gmail.com> <20200817074637.GW62842@faui48f.informatik.uni-erlangen.de> <60B2B44D-5E6D-4CB2-AD63-1A8CB846BFA3@strayalpha.com> <0e575946-dfd4-7753-8c34-47987d0b3c7e@huitema.net> <20200817164256.GB62842@faui48f.informatik.uni-erlangen.de> To: Toerless Eckert X-Mailer: Apple Mail (2.3608.120.23.2.1) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [arch-d] A Public Option for the Core X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2020 18:59:22 -0000 --Apple-Mail=_4A31397B-9855-4713-9CB7-DAFFFF911E16 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Aug 17, 2020, at 9:42 AM, Toerless Eckert wrote: >=20 > Instead of just talking about some of the tools (CC, ACM), it would be > nice to try to set goals first, to see if we could get agreement = there: >=20 > -> I would like traffic to get the same throughput under congestion > whatever its RTT is. Yes, as long as the issue isn=E2=80=99t that the ISP does something = differently based on RTT> If they run feedback loops whose recovery depends on RTT, then it=E2=80=99= s their fault if they don=E2=80=99t get a fair share. It=E2=80=99s not = the ISPs job to compensate for that. > -> I would like for traffic to get bandwidth share indpendent of the > number of 5 tuple flows it utilizes (no gaming the system). But > rather fair per subscriber (weighted by how much the subscriber = pays). That=E2=80=99s 1 class of service. There can be more than one (or are = you just treating that as =E2=80=98different subscribers=E2=80=99?). > -> I would like to be able for traffic to indicate preferences for > lower latency or higher throughput... If you ask for lower latency, > you get less throughput. Three network decisions: - go now - take up space and go later - drop It seems like there ought to be three service classes (at least): - low latency and low loss (go now) - low loss with increased latency (go later) - everything else (drop if you can=E2=80=99t handle it) That roughly maps to a few of the DSCPs. The rest are there largely to = ensure that =E2=80=9Csome pigs are more equal than others=E2=80=9D, = i.e., that network management/control protocols can bump others. That = sort of priority - with a single =E2=80=98reserved=E2=80=99 level - may = be important to operations, but shouldn=E2=80=99t be sold out to users. > -> Goodput always > 95% I have no idea what goodput is. Nothing ensures that a packet that = =E2=80=98wins=E2=80=99 on a link now won=E2=80=99t be dropped downstream = when competing for other resources. If you want goodput to be high, then = load has to be low (vs. capacity), i.e., under 50-60%-ish. Joe --Apple-Mail=_4A31397B-9855-4713-9CB7-DAFFFF911E16 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Aug 17, 2020, at 9:42 AM, Toerless Eckert <tte@cs.fau.de> = wrote:

Instead of just talking about = some of the tools (CC, ACM), it would be
nice to try to set goals first, to see if we could get = agreement there:

-> I would like traffic to get the same throughput under = congestion
  whatever its RTT is.

Yes, as = long as the issue isn=E2=80=99t that the ISP does something differently = based on RTT>

If they run = feedback loops whose recovery depends on RTT, then it=E2=80=99s their = fault if they don=E2=80=99t get a fair share. It=E2=80=99s not the ISPs = job to compensate for that.

-> I would like for traffic to get bandwidth share = indpendent of the
  number of 5 tuple flows it utilizes (no gaming = the system). But
  rather fair per subscriber (weighted by how much = the subscriber pays).

That=E2=80=99s 1 class of service. There can be = more than one (or are you just treating that as =E2=80=98different = subscribers=E2=80=99?).

-> I would like to be able for traffic to indicate = preferences for
  lower latency or higher throughput... If you ask = for lower latency,
  you get less throughput.

Three = network decisions:
- go now
- take up = space and go later
- drop

It seems like there ought to be three service = classes (at least):
- low latency and low loss (go = now)
= - low loss with increased latency (go later)
- = everything else (drop if you can=E2=80=99t handle it)

That roughly maps to a few of the DSCPs. The rest = are there largely to ensure that =E2=80=9Csome pigs are more equal than = others=E2=80=9D, i.e., that network management/control protocols can = bump others. That sort of priority - with a single =E2=80=98reserved=E2=80= =99 level - may be important to operations, but shouldn=E2=80=99t be = sold out to users.

-> Goodput always > 95%

I have no idea what goodput is. Nothing ensures = that a packet that =E2=80=98wins=E2=80=99 on a link now won=E2=80=99t be = dropped downstream when competing for other resources. If you want = goodput to be high, then load has to be low (vs. capacity), i.e., under = 50-60%-ish.

Joe

= --Apple-Mail=_4A31397B-9855-4713-9CB7-DAFFFF911E16-- From nobody Mon Aug 17 13:53:46 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B407C3A117F for ; Mon, 17 Aug 2020 13:53:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=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=iecc.com header.b=uhjlJC/W; dkim=pass (2048-bit key) header.d=taugh.com header.b=T+xJO1GK 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 CUWPLHihVrQo for ; Mon, 17 Aug 2020 13:53:43 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 3ED0C3A117B for ; Mon, 17 Aug 2020 13:53:43 -0700 (PDT) Received: (qmail 68189 invoked from network); 17 Aug 2020 20:53:40 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=10a5b.5f3aee54.k2008; bh=pqxi6pGWSaxxLtzEo+TtqKO5JssGFKSNo0SA0k4qxoU=; b=uhjlJC/WonV74FLIggLRvoyiIVIqSe9ZjQICk5QddSpUmGO8BCWUqaiiV8EJzUK4bkigD0hxEb5QEbmxuK747QocQeIpw+Y9lMLDUaftMZMv1FTh1aycrK2dIgCG9qtRMASg33tad4Z4r1OE8pXYUvymRqBRYFv1EDLkraYTQ2niG1DLi6vqgYPm0dEhjP3mXnlVtWkP+iXBpr/+64rUx3gToGzTVY0KUF+NT3n/OKVWnwpHTQMRO7h+rf5Ylozp0nQQGpMOtt2vMQyqOYlvpEhO7G73JpsI6JXAMK8UTh5lPUA4D5mip5+EXr9fkrj6TzphNFm9kviaTjHHojygJg== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=10a5b.5f3aee54.k2008; bh=pqxi6pGWSaxxLtzEo+TtqKO5JssGFKSNo0SA0k4qxoU=; b=T+xJO1GKqhWn/RUB+1sAWYVhdwPBht6u0AnWqYF9DRiMsC4iDaF5CdFZ0YiisyvQxjZJI6HB8JkzaJJuQAUwQg2P6H5+344nJDc0C5JLUNLjHa1uE7Q19Sa0rHkp9w5J17w6S4NtzSwzm3vQ81A7lqY3O4xxyDMrqhc0mH/xMD+g3spWFpOzJKFGCuxnrsQ9iCGozVUAdDqZz7Ea7fRakjYv8KIVerHm7oPWam4e2XzOBN0OhIO5DYdF939ubWCcSaupULTBjEb61GVcrDW8QlUJbWPi6Rip4QZkYZxGQ7pAA5cbrU7TfYGafo7GPzKnK5MsEbTP1OmQ3Czsnvjn3A== Received: from ary.local ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 17 Aug 2020 20:53:40 -0000 Received: by ary.local (Postfix, from userid 501) id 593BA1EE58DA; Mon, 17 Aug 2020 16:53:40 -0400 (EDT) Date: 17 Aug 2020 16:53:40 -0400 Message-Id: <20200817205340.593BA1EE58DA@ary.local> From: "John Levine" To: architecture-discuss@ietf.org In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [arch-d] A Public Option for the Core X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2020 20:53:45 -0000 In article you write: >As to trust, it only matters that an intermediate hasn’t forged a new header. You don’t need to trust the user - if >they want to map their email to high-priority and pay for that usage, that’s their business (literally). If that’s more >service than they paid for, then drop packets. The problem is when you have networks connected A-B-C, network A sets the header for deluxe service, then complains to B that C isn't providing the service they're paying for. What service? says C. I realize that in the real world there's tons of VPNs and overlays that provide various sorts of guarantees but they're a direct arrangement between a customer and the network providing the service. R's, John From nobody Mon Aug 17 15:50:35 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E1203A13F8 for ; Mon, 17 Aug 2020 15:50:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 XMxLHuAg6XBB for ; Mon, 17 Aug 2020 15:50:31 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 474863A13F7 for ; Mon, 17 Aug 2020 15:50:30 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 37311548621; Tue, 18 Aug 2020 00:50:26 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 30ABE440059; Tue, 18 Aug 2020 00:50:26 +0200 (CEST) Date: Tue, 18 Aug 2020 00:50:26 +0200 From: Toerless Eckert To: Joseph Touch Cc: Christian Huitema , architecture-discuss@ietf.org Message-ID: <20200817225026.GD62842@faui48f.informatik.uni-erlangen.de> References: <754DE168-DF3B-4471-A145-39C6143E538A@comcast.net> <1fd2ed7d-d4bc-c5b7-9a4a-7966d5e60513@gmail.com> <20200817074637.GW62842@faui48f.informatik.uni-erlangen.de> <60B2B44D-5E6D-4CB2-AD63-1A8CB846BFA3@strayalpha.com> <0e575946-dfd4-7753-8c34-47987d0b3c7e@huitema.net> <20200817164256.GB62842@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [arch-d] A Public Option for the Core X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2020 22:50:34 -0000 On Mon, Aug 17, 2020 at 11:59:09AM -0700, Joseph Touch wrote: > > > > On Aug 17, 2020, at 9:42 AM, Toerless Eckert wrote: > > > > Instead of just talking about some of the tools (CC, ACM), it would be > > nice to try to set goals first, to see if we could get agreement there: > > > > -> I would like traffic to get the same throughput under congestion > > whatever its RTT is. > > Yes, as long as the issue isn???t that the ISP does something differently based on RTT> > > If they run feedback loops whose recovery depends on RTT, then it???s their fault if they don???t get a fair share. It???s not the ISPs job to compensate for that. Thats a matter of opinion. many transportation services have elements of equalization in them. postal charges within countries for example (for most parts equal cost even when you live far away). Financial market information needs to get more and more latency equalized for market fairness. > > -> I would like for traffic to get bandwidth share indpendent of the > > number of 5 tuple flows it utilizes (no gaming the system). But > > rather fair per subscriber (weighted by how much the subscriber pays). > > That???s 1 class of service. There can be more than one (or are you just treating that as ???different subscribers????). Yes, i was talking about granularity of fairness. > > -> I would like to be able for traffic to indicate preferences for > > lower latency or higher throughput... If you ask for lower latency, > > you get less throughput. > > Three network decisions: > - go now > - take up space and go later > - drop Yes. There is IMHO the not well explored opportunity to take up space in already provisioned but unused buffers - for example for equalization of latency where that is desirable. But when you want lower latency you might want to get into one of the fewer buffers served faster. And there would be fewer of those than when you have more time to hang around. What impact would that have on relative throughput ? > It seems like there ought to be three service classes (at least): > - low latency and low loss (go now) > - low loss with increased latency (go later) > - everything else (drop if you can???t handle it) We understand how to manage classical diffserv/intserv solutions. And how managing them is limited by scale and cost of management vs. incremental sales revenue. The interesting question is what different services you can reasonably multiplex so different apps get different benefits but it doesn't end up simply every app wanting to game the system by picking the one "winner" service. For example, theoretically something like scavenger sounds like a nice option. But applications would only use it if the non-scavenger traffic was more expensive. Eg.: go beyond your monthly volume limit with scavenger. Likewise the use of best-effort vs. low latency would self regulate if the throughput loss of low-latency was making it only worth for traffic that really needed lower latency. > That roughly maps to a few of the DSCPs. The rest are there largely to ensure that ???some pigs are more equal than others???, i.e., that network management/control protocols can bump others. That sort of priority - with a single ???reserved??? level - may be important to operations, but shouldn???t be sold out to users. > > > -> Goodput always > 95% > > I have no idea what goodput is. Nothing ensures that a packet that ???wins??? on a link now won???t be dropped downstream when competing for other resources. If you want goodput to be high, then load has to be low (vs. capacity), i.e., under 50-60%-ish. True, goodput is ambiguous as fairness. I was primarily thinking of retransmissions to be below 5% (of course for non-low-latency traffic only). Cheers Toerless > > Joe > -- --- tte@cs.fau.de From nobody Mon Aug 17 16:54:41 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 037D83A1489 for ; Mon, 17 Aug 2020 16:54:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.047 X-Spam-Level: X-Spam-Status: No, score=-3.047 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.949, 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=gmail.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 D-6vDgJrNZXS for ; Mon, 17 Aug 2020 16:54:38 -0700 (PDT) Received: from mail-pg1-x52e.google.com (mail-pg1-x52e.google.com [IPv6:2607:f8b0:4864:20::52e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC8E13A1484 for ; Mon, 17 Aug 2020 16:54:38 -0700 (PDT) Received: by mail-pg1-x52e.google.com with SMTP id h12so8871425pgm.7 for ; Mon, 17 Aug 2020 16:54:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=mWdAr33wPGWenZvWQEiqBkP/JDiAOONH1gOE3h9bAw8=; b=hjZMmuVZwndeS1PjTumPREOuS5p73j10aFfGmL+PnY1ZGmWdy1KX0GlTt7JOGFw+Ca 79eYVnRVi0SwTCJ01ciKcujIBNXLq7r+CggfAG37fy8KseNgkwgneyQo8ATUqOxd/CPW WFGMD2CgDLn+64Z5Bq4MdfU16rJToCaLX/53FIt6Uk6PYgoLbwx43jE0547vtAljZcjB wwjnW/8OI15qaAbCzZzqhAxxCLYw4F0OAu6+nuEvvMmSmiBXnwMaxCT3Kwpw7MbUjmnI A8tOumdsTHBTwGDAxVhPxoFPZtM0iCsKMkYH4v+BfEEdBsy69XH+ICcV1jqUlKqigjVQ NWlg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=mWdAr33wPGWenZvWQEiqBkP/JDiAOONH1gOE3h9bAw8=; b=gCvR27ikTi9Huzo/YTFvgIYVWNYOkf5lhDHfA/8ZmMXlQB3gWGHrqN5ulDtPArrRgp BOkfsuvxRVnusq8gN7qnJ45J1sjjY05U6QUkOjA+TrmIAbs3EPbRAMQdeDTNYMxmta74 0P6EslNgAAvqrFADEf5I0Mm+BXS2G1xn68Che3XFxDODa5rvAR2RVlZanRuJ70wEJqiF AZhJXDzDXvvMpILEXnbHIIT4ypLaY8iFnPcjXsg8RvQl+ZniDIs624kG5j2z1vzd1J3x qTKFm8QitDjGvgP8jB22mujc2S8tKKGsPoF77dlIsu0FJJAlz/uOn1wA4Bmug3xtndN/ kLxg== X-Gm-Message-State: AOAM531KHzyBGQWmZHezWUZFS3AQGlll4zlglpTHKam761x+wMHbQwNe 2viVU/El0u01JWE0XD0Zz+nEqXfoEu1uCg== X-Google-Smtp-Source: ABdhPJwNZdEBguhYHE064phCIMj+oswQwsJunMA6sU9cgyMFYCbTcJ8ysXIvj9COI9kRsCSmSPWirg== X-Received: by 2002:a63:d20e:: with SMTP id a14mr11404916pgg.231.1597708477826; Mon, 17 Aug 2020 16:54:37 -0700 (PDT) Received: from [192.168.178.20] ([151.210.139.192]) by smtp.gmail.com with ESMTPSA id jb1sm19897634pjb.9.2020.08.17.16.54.35 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Aug 2020 16:54:37 -0700 (PDT) To: Toerless Eckert Cc: architecture-discuss@ietf.org References: <754DE168-DF3B-4471-A145-39C6143E538A@comcast.net> <1fd2ed7d-d4bc-c5b7-9a4a-7966d5e60513@gmail.com> <20200817074637.GW62842@faui48f.informatik.uni-erlangen.de> <60B2B44D-5E6D-4CB2-AD63-1A8CB846BFA3@strayalpha.com> <0e575946-dfd4-7753-8c34-47987d0b3c7e@huitema.net> <20200817164256.GB62842@faui48f.informatik.uni-erlangen.de> From: Brian E Carpenter Message-ID: Date: Tue, 18 Aug 2020 11:54:34 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <20200817164256.GB62842@faui48f.informatik.uni-erlangen.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [arch-d] A Public Option for the Core X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2020 23:54:40 -0000 On 18-Aug-20 04:42, Toerless Eckert wrote: ... > -> I would like for traffic to get bandwidth share indpendent of the > number of 5 tuple flows it utilizes (no gaming the system). But > rather fair per subscriber (weighted by how much the subscriber pays). You just broke GridFTP, used in Big Science to move terabyte datasets around the world efficiently. It's not gaming, it's achieving throughput despite defects in TCP. But the topic is very much alive there, since GridFTP is now unsupported. For further reading: https://twiki.cern.ch/twiki/bin/view/LCG/ThirdPartyCopy Brian From nobody Mon Aug 17 22:27:15 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EA2B3A17DB for ; Mon, 17 Aug 2020 22:26:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.118 X-Spam-Level: X-Spam-Status: No, score=-1.118 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] 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 DyvKLhXhsEAQ for ; Mon, 17 Aug 2020 22:26:49 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90CF83A17D3 for ; Mon, 17 Aug 2020 22:26:47 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 1532B548621; Tue, 18 Aug 2020 07:26:42 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 08FED440059; Tue, 18 Aug 2020 07:26:42 +0200 (CEST) Date: Tue, 18 Aug 2020 07:26:41 +0200 From: Toerless Eckert To: Brian E Carpenter Cc: architecture-discuss@ietf.org Message-ID: <20200818052641.GE62842@faui48f.informatik.uni-erlangen.de> References: <754DE168-DF3B-4471-A145-39C6143E538A@comcast.net> <1fd2ed7d-d4bc-c5b7-9a4a-7966d5e60513@gmail.com> <20200817074637.GW62842@faui48f.informatik.uni-erlangen.de> <60B2B44D-5E6D-4CB2-AD63-1A8CB846BFA3@strayalpha.com> <0e575946-dfd4-7753-8c34-47987d0b3c7e@huitema.net> <20200817164256.GB62842@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [arch-d] A Public Option for the Core X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2020 05:26:59 -0000 Multiple parallel TCP connections to overcome TCP issues with high capacity high loss paths even in the absence of congestion was always a bad workaround. Digital Fountain was already selling software 15 years ago with scatter storage and network coding gather retrieval. Still network coding researchers seem to claim this stuff is new today. A lot of of the network side problems of this are the result of the traditional, uncontrolled transit SP paths, aka: the classical Internet model. Cheers Toerless On Tue, Aug 18, 2020 at 11:54:34AM +1200, Brian E Carpenter wrote: > On 18-Aug-20 04:42, Toerless Eckert wrote: > ... > > > -> I would like for traffic to get bandwidth share indpendent of the > > number of 5 tuple flows it utilizes (no gaming the system). But > > rather fair per subscriber (weighted by how much the subscriber pays). > > You just broke GridFTP, used in Big Science to move terabyte datasets > around the world efficiently. It's not gaming, it's achieving throughput > despite defects in TCP. But the topic is very much alive there, since > GridFTP is now unsupported. > > For further reading: > https://twiki.cern.ch/twiki/bin/view/LCG/ThirdPartyCopy > > Brian From nobody Tue Aug 18 12:11:41 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AC683A0A4D for ; Tue, 18 Aug 2020 12:11:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.319 X-Spam-Level: X-Spam-Status: No, score=-1.319 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 5q0O2Cnjqwvo for ; Tue, 18 Aug 2020 12:11:36 -0700 (PDT) Received: from server217-4.web-hosting.com (server217-4.web-hosting.com [198.54.116.98]) (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 EEEB23A0A41 for ; Tue, 18 Aug 2020 12:11:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=CdMgvPbrUMtUDEwTsLyPZbAvdxvu69B9kQh1cweAKa4=; b=A2cwsstNaMWAG3KdMweduVmfz PmqdYeF3hyHchiw/2Bmn+lO6JazKzq5GU4PV1Jy+a2B3+BU9c1BJAbkTkUVZtKl6lFr0HavmHAysb ewOpwv1iKxpbkSN0eQNozpoxHPo+jbTso5tdYtgr+Kw8VBTaF6igX6nmb0Bcwjcv2+ifFbbng6unD FDkDlJfBPCbot3WUwO3DXzc40WdSEXKNGJczZnZMmwdIsB8AbxDC1z1w4S5IALb+WLeMXHjE1GF7/ LC5Qh/DFpIGG0BFd8uIqpN8kLtNbks64WbKsWiGyIBg+Ih93ru56OG0jS+foApIYIQYj+U8USxsvB UIvw98YVw==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:65394 helo=[192.168.1.14]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1k8719-001L82-Da; Tue, 18 Aug 2020 15:11:35 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Joseph Touch In-Reply-To: <20200817205340.593BA1EE58DA@ary.local> Date: Tue, 18 Aug 2020 12:11:30 -0700 Cc: architecture-discuss@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <43A691EE-CA6D-4F76-A02A-3335D2CAB27E@strayalpha.com> References: <20200817205340.593BA1EE58DA@ary.local> To: John Levine X-Mailer: Apple Mail (2.3608.120.23.2.1) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [arch-d] A Public Option for the Core X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2020 19:11:40 -0000 > On Aug 17, 2020, at 1:53 PM, John Levine wrote: >=20 > In article you = write: >> As to trust, it only matters that an intermediate hasn=E2=80=99t = forged a new header. You don=E2=80=99t need to trust the user - if >> they want to map their email to high-priority and pay for that usage, = that=E2=80=99s their business (literally). If that=E2=80=99s more >> service than they paid for, then drop packets. >=20 > The problem is when you have networks connected A-B-C, network A sets > the header for deluxe service, then complains to B that C isn't > providing the service they're paying for. What service? says C. That=E2=80=99s not a problem. That=E2=80=99s just a contract and = (potentially) a lawsuit, depending on which network claims that = traversal would support deluxe service. If you can=E2=80=99t trust your = ISP - from whom you buy deluxe service - to contract the correct service = out to parties that honor the tags, then you=E2=80=99ve chosen poorly. I.e., that isn=E2=80=99t a protocol problem.=20 > I realize that in the real world there's tons of VPNs and overlays > that provide various sorts of guarantees but they're a direct > arrangement between a customer and the network providing the service. Direct or subcontract - at some point, if you don=E2=80=99t have that = relationship with a peer, you can=E2=80=99t offer that as a transit. Joe= From nobody Tue Aug 18 14:23:39 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BA793A0D01 for ; Tue, 18 Aug 2020 14:23:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.047 X-Spam-Level: X-Spam-Status: No, score=-3.047 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.949, 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=gmail.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 qd6OKb0a2_7K for ; Tue, 18 Aug 2020 14:23:36 -0700 (PDT) Received: from mail-pf1-x444.google.com (mail-pf1-x444.google.com [IPv6:2607:f8b0:4864:20::444]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF35A3A0CFC for ; Tue, 18 Aug 2020 14:23:36 -0700 (PDT) Received: by mail-pf1-x444.google.com with SMTP id y206so10572931pfb.10 for ; Tue, 18 Aug 2020 14:23:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=rm7Gy22Ni6nHgVDs5CwvgZ6OWaJunp4ElB0hWT9S3kk=; b=pDh519tbDCvOejtiiK9O0KLi+9+Sm+PX+qNsEcNtTsZvkxAqBc8NbWcPa40ICOfCxg 01EX4bT+Vb5V6Z+uGKE8FEVY6eXRXlxHsU+xdU6ziVktwxh9sh5tvFqxRmyT7ygVhIUu h0V6kZPXUVqkaw/kANh1M81mTslnekJtn3pfu4bN4YY3xKlJuG/9xqNeb832z29Qjfy6 cFyiCLMnxT3pWz0Eawsa8FwIDxx541QgOPzmM2Knfx35S4v2vHSRw5TinH5B8cv9iX2q F2Owkoymle93/P3BBx8VERjqPNsImjikvulzEAOp77seweqtzvduN3OPA0SFDChQpvtw 1nOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=rm7Gy22Ni6nHgVDs5CwvgZ6OWaJunp4ElB0hWT9S3kk=; b=DIAQk84L6YoIRdE1dUBXufleWPoV+4mkXgLZ3efNTB4QoDoIZvrtD8hopLCcPUtIZI fQefku4C2btMAviW8Njm+RvbzpbX50TLVb9sfVjJrwPxEkF+4wdXY1jvxukebTGVKwJb mzp7ABRELCyJsoECL+fjff2CLn3aNWPlrMzzTu55/knRTdbPTRQCrxJqWDZdLhc2mCBQ jacx5JqsD7k9cg2EJoj9KmuIqgLE9TNd5uZ0hrllmduOuByR3D0CmOOBwJVXr45Jrodo rutUdG8e+2Dow7ps/GkOyG7v2GjdLjuSEY60dE57dxOcOEBjEsH3GTBZ5SyuJhcYYDkj cRwQ== X-Gm-Message-State: AOAM5330fnWwKL2fwXT/xUZGRrVbEifmOj1176Yed1Xvrjq9Sxeni4Ys Dmu+uHdcTmyb0KHkHrFiwG1mZkEa/dgk6Q== X-Google-Smtp-Source: ABdhPJyilqOpT+wkyJ+VstwCcq1zlQN6Hj4624rxkAINBFkaV1lg3YcqCLbjyLOAKGOJfA0cfoVbZg== X-Received: by 2002:a62:164a:: with SMTP id 71mr16826833pfw.266.1597785816001; Tue, 18 Aug 2020 14:23:36 -0700 (PDT) Received: from [192.168.178.20] ([151.210.139.192]) by smtp.gmail.com with ESMTPSA id v2sm783238pjd.18.2020.08.18.14.23.33 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Aug 2020 14:23:35 -0700 (PDT) To: Toerless Eckert Cc: architecture-discuss@ietf.org References: <754DE168-DF3B-4471-A145-39C6143E538A@comcast.net> <1fd2ed7d-d4bc-c5b7-9a4a-7966d5e60513@gmail.com> <20200817074637.GW62842@faui48f.informatik.uni-erlangen.de> <60B2B44D-5E6D-4CB2-AD63-1A8CB846BFA3@strayalpha.com> <0e575946-dfd4-7753-8c34-47987d0b3c7e@huitema.net> <20200817164256.GB62842@faui48f.informatik.uni-erlangen.de> <20200818052641.GE62842@faui48f.informatik.uni-erlangen.de> From: Brian E Carpenter Message-ID: <6998f7af-7834-3aa3-300d-410036cd2466@gmail.com> Date: Wed, 19 Aug 2020 09:23:31 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <20200818052641.GE62842@faui48f.informatik.uni-erlangen.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [arch-d] A Public Option for the Core X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2020 21:23:38 -0000 On 18-Aug-20 17:26, Toerless Eckert wrote: >=20 > Multiple parallel TCP connections to overcome TCP issues with high > capacity high loss paths even in the absence of congestion was always > a bad workaround.=20 It's certainly a workaround, but why was it particularly bad? The context where GridFTP was developed and used was the world of very high capacity links between major Big Data sites; it's actually a good example for RFC8799 that we overlooked. If you really want maximum throughput on such links, which also have very low bit error rates, you can use a non-windowing, rate-controlled transport protocol with simplified error handling. But that's not an IETF problem, really. > Digital Fountain was already selling software 15 years > ago with scatter storage and network coding gather retrieval. Still > network coding researchers seem to claim this stuff is new today. The network coding literature goes back to at least 2000**. The network coding people I know are aiming at a different problem area today: poor quality wireless and/or overloaded satellite links. Exactly the opposite of the Big Data scenario. (However, I am not tracking the NWCRG. I am rather amazed by the lack of references to the extensive literature in RFC8406, but draft-irtf-nwcrg-nwc-ccn-reqs= does better.) =20 > A lot of of the network side problems of this are the result of the > traditional, uncontrolled transit SP paths, aka: the classical Internet= > model.=20 Indeed.=20 Regards Brian ** R. Ahlswede, N. Cai, S.-Y.R. Li and R.W. Yeung, =E2=80=9CNetwork Information Flow=E2=80=9D, IEEE-IT, vol. 46, pp. 1204-1216, 2000. >=20 > Cheers > Toerless >=20 > On Tue, Aug 18, 2020 at 11:54:34AM +1200, Brian E Carpenter wrote: >> On 18-Aug-20 04:42, Toerless Eckert wrote: >> ... >> =20 >>> -> I would like for traffic to get bandwidth share indpendent of the >>> number of 5 tuple flows it utilizes (no gaming the system). But >>> rather fair per subscriber (weighted by how much the subscriber pa= ys). >> >> You just broke GridFTP, used in Big Science to move terabyte datasets >> around the world efficiently. It's not gaming, it's achieving throughp= ut >> despite defects in TCP. But the topic is very much alive there, since >> GridFTP is now unsupported. >> >> For further reading: >> https://twiki.cern.ch/twiki/bin/view/LCG/ThirdPartyCopy >> >> Brian >=20 From nobody Tue Aug 18 14:30:48 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82D433A0E0B for ; Tue, 18 Aug 2020 14:30:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.894 X-Spam-Level: X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=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=mjmontpetit-com.20150623.gappssmtp.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 UYbwmZaCmTKa for ; Tue, 18 Aug 2020 14:30:44 -0700 (PDT) Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10BEF3A0DDB for ; Tue, 18 Aug 2020 14:30:43 -0700 (PDT) Received: by mail-lj1-x233.google.com with SMTP id t23so23096518ljc.3 for ; Tue, 18 Aug 2020 14:30:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mjmontpetit-com.20150623.gappssmtp.com; s=20150623; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=5foLxCpdG0szEiglsjXW5MT9fo/HO+1L1megaxFIhEo=; b=ZMEca2dvnxFXYMafp8zfiGN/kofyM9dMuxI/oAq36VXqRqRvGwmVWskVAZ2mEL2qYZ +wDb5h/quF6pQ/n7OQ3NnMysHFulyJoQ31t5Joc5zL6HpiDh5/w4t+9j1iUUTxz/GCZ9 rT6Oexl2j7ff30LTBpheuSqbKHn56W6mwGhpTqF3eEx9CEN5MwTlVk3+cgw1qtNtvr2d TJ0GRiuP5XU7a30Qo0IlVh0ByFnRcJ8cddRzvtmMEYalYvWiDPoYCdir+Dl1ty3RR4vB UiWmHszG5lmBTvirt2NzY1fqODflyY+QpBKyylsl8xsTFKbnf01lpz6b5nQLAB/4QLvz /P0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=5foLxCpdG0szEiglsjXW5MT9fo/HO+1L1megaxFIhEo=; b=QeCVCQZQiqmGSxx5Q04PWBmWAOacU6hLH3g0ILoOXLPKt59LZciFnIft1HyIVfKzzW lqLnmAP6otevYAZX2jKUYl67C4J13G22RzQCnlvYRan58/c8YNyimP4v5pjswkGCQnZV tF8m6+vgYucwfiSqZWrN05MoWhq/MAsBXKbiq3LZOutFmvXjtNmQ6vBbw/cVo69D/Lg9 bFkUYAm97RoXQN/v8XlDvZ7TQEA6hFY8umOepZ5HemGk04LW5ufaM05J0J0KYWAPdoIc 9G+6lUWrIcgKQYoEfyCZb/3BU081kD4HsZQoR1Z5gVg22CRGByYcLxxLytmSIcX6ijtS HkWQ== X-Gm-Message-State: AOAM5301SU9javsiFuXECUaUd5M7pCNJ65RUOTH4rjuLg2nVEifiT16u dgH0cY8J3gO4FpXjNX0r9zRdtmtcaQVDbvJfCxPphY+KusM1og== X-Google-Smtp-Source: ABdhPJwfx6s24YtuL7s1U1qXjR/97tc2bvfUrCt674LGjGpbmbb9G0wmRpD2STMM68rIbi97WSpm6LVpSCeQhn5bxVw= X-Received: by 2002:a2e:a497:: with SMTP id h23mr10145205lji.154.1597786242034; Tue, 18 Aug 2020 14:30:42 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 18 Aug 2020 14:30:41 -0700 From: Marie-Jose Montpetit In-Reply-To: <6998f7af-7834-3aa3-300d-410036cd2466@gmail.com> References: <754DE168-DF3B-4471-A145-39C6143E538A@comcast.net> <1fd2ed7d-d4bc-c5b7-9a4a-7966d5e60513@gmail.com> <20200817074637.GW62842@faui48f.informatik.uni-erlangen.de> <60B2B44D-5E6D-4CB2-AD63-1A8CB846BFA3@strayalpha.com> <0e575946-dfd4-7753-8c34-47987d0b3c7e@huitema.net> <20200817164256.GB62842@faui48f.informatik.uni-erlangen.de> <20200818052641.GE62842@faui48f.informatik.uni-erlangen.de> <6998f7af-7834-3aa3-300d-410036cd2466@gmail.com> MIME-Version: 1.0 Date: Tue, 18 Aug 2020 14:30:41 -0700 Message-ID: To: Brian E Carpenter , Toerless Eckert Cc: architecture-discuss@ietf.org Content-Type: multipart/alternative; boundary="0000000000006242c905ad2d99cd" Archived-At: Subject: Re: [arch-d] A Public Option for the Core X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2020 21:30:47 -0000 --0000000000006242c905ad2d99cd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Just a note: while in nwcrg we have not addressed coding and storage there is indeed a large amount of work in the area. Marie-Jos=C3=A9 Montpetit, Ph.D. marie@mjmontpetit.com On August 18, 2020 at 5:23:50 PM, Brian E Carpenter ( brian.e.carpenter@gmail.com) wrote: On 18-Aug-20 17:26, Toerless Eckert wrote: > > Multiple parallel TCP connections to overcome TCP issues with high > capacity high loss paths even in the absence of congestion was always > a bad workaround. It's certainly a workaround, but why was it particularly bad? The context where GridFTP was developed and used was the world of very high capacity links between major Big Data sites; it's actually a good example for RFC8799 that we overlooked. If you really want maximum throughput on such links, which also have very low bit error rates, you can use a non-windowing, rate-controlled transport protocol with simplified error handling. But that's not an IETF problem, really. > Digital Fountain was already selling software 15 years > ago with scatter storage and network coding gather retrieval. Still > network coding researchers seem to claim this stuff is new today. The network coding literature goes back to at least 2000**. The network coding people I know are aiming at a different problem area today: poor quality wireless and/or overloaded satellite links. Exactly the opposite of the Big Data scenario. (However, I am not tracking the NWCRG. I am rather amazed by the lack of references to the extensive literature insurance, but draft-irtf-nwcrg-nwc-ccn-reqs does better.) > A lot of of the network side problems of this are the result of the > traditional, uncontrolled transit SP paths, aka: the classical Internet > model. Indeed. Regards Brian ** R. Ahlswede, N. Cai, S.-Y.R. Li and R.W. Yeung, =E2=80=9CNetwork Information Flow=E2=80=9D, IEEE-IT, vol. 46, pp. 1204-1216, 2000. > > Cheers > Toerless > > On Tue, Aug 18, 2020 at 11:54:34AM +1200, Brian E Carpenter wrote: >> On 18-Aug-20 04:42, Toerless Eckert wrote: >> ... >> >>> -> I would like for traffic to get bandwidth share indpendent of the >>> number of 5 tuple flows it utilizes (no gaming the system). But >>> rather fair per subscriber (weighted by how much the subscriber pays). >> >> You just broke GridFTP, used in Big Science to move terabyte datasets >> around the world efficiently. It's not gaming, it's achieving throughput >> despite defects in TCP. But the topic is very much alive there, since >> GridFTP is now unsupported. >> >> For further reading: >> https://twiki.cern.ch/twiki/bin/view/LCG/ThirdPartyCopy >> >> Brian > _______________________________________________ Architecture-discuss mailing list Architecture-discuss@ietf.org https://www.ietf.org/mailman/listinfo/architecture-discuss --0000000000006242c905ad2d99cd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
Just= a note: while in nwcrg we have not addressed coding and storage there is i= ndeed a large amount of work in the area.

Marie-Jos=C3=A9 Montpetit, Ph.D.

On August 18, 2020 at 5:23:50 P= M, Brian E Carpenter (brian.= e.carpenter@gmail.com) wrote:

On 18-Aug-20 17:26, Toerless Eckert wrot= e:
>
> Multiple parallel TCP connections to overcome TCP issue= s with high
> capacity high loss paths even in the absence of congest= ion was always
> a bad workaround.

It's certainly a worka= round, but why was it particularly bad? The
context where GridFTP was de= veloped and used was the world of very
high capacity links between major= Big Data sites; it's actually a
good example for RFC8799 that we ov= erlooked.

If you really want maximum throughput on such links, which= also have
very low bit error rates, you can use a non-windowing, rate-c= ontrolled
transport protocol with simplified error handling. But that= 9;s not an
IETF problem, really.

> Digital Fountain was alread= y selling software 15 years
> ago with scatter storage and network co= ding gather retrieval. Still
> network coding researchers seem to cl= aim this stuff is new today.

The network coding literature goes back= to at least 2000**.
The network coding people I know are aiming at a di= fferent problem
area today: poor quality wireless and/or overloaded sate= llite links.
Exactly the opposite of the Big Data scenario. (However, I = am not
tracking the NWCRG. I am rather amazed by the lack of references<= br>to the extensive literature insurance, but draft-irtf-nwcrg-nwc-ccn-reqs=
does better.)

> A lot of of the network side problems of thi= s are the result of the
> traditional, uncontrolled transit SP paths,= aka: the classical Internet
> model.

Indeed.

Regards=
Brian

** R. Ahlswede, N. Cai, S.-Y.R. Li and R.W. Yeung, =E2= =80=9CNetwork
Information Flow=E2=80=9D, IEEE-IT, vol. 46, pp. 1204-1216= , 2000.
>
> Cheers
> Toerless
>
> On Tu= e, Aug 18, 2020 at 11:54:34AM +1200, Brian E Carpenter wrote:
>> O= n 18-Aug-20 04:42, Toerless Eckert wrote:
>> ...
>>
= >>> -> I would like for traffic to get bandwidth share indpende= nt of the
>>> number of 5 tuple flows it utilizes (no gaming= the system). But
>>> rather fair per subscriber (weighted b= y how much the subscriber pays).
>>
>> You just broke Gri= dFTP, used in Big Science to move terabyte datasets
>> around the = world efficiently. It's not gaming, it's achieving throughput
&g= t;> despite defects in TCP. But the topic is very much alive there, sinc= e
>> GridFTP is now unsupported.
>>
>> For furth= er reading:
>> https://twiki.cern.ch/twiki/bin/view/LCG/ThirdPartyCopy
>>
>> Brian
>

_______________________= ________________________
Architecture-discuss mailing list
Architecture-discuss@ietf.orghtt= ps://www.ietf.org/mailman/listinfo/architecture-discuss
=
--0000000000006242c905ad2d99cd-- From nobody Tue Aug 18 14:52:35 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 130F43A0D06 for ; Tue, 18 Aug 2020 14:52:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netorgft5189650.onmicrosoft.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 P9kjEbP7UW35 for ; Tue, 18 Aug 2020 14:52:28 -0700 (PDT) Received: from GBR01-LO2-obe.outbound.protection.outlook.com (mail-eopbgr100075.outbound.protection.outlook.com [40.107.10.75]) (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 0CAD13A0DD1 for ; Tue, 18 Aug 2020 14:52:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CW8BypnRFBDjfx6YF6+JD6Dxo6kBLHJPkCVHecMnxYmTwWmzf09qiu2NGdVzyzNQpDf004acg+KtUgrLMf/Wl2vpIuD5xOd796gMbl5QnL0R6FAS3kXR1Q2DZ/LQ+yFf93iAj4aBiSmCHZnr5xu+joiXMxGKW59u8xugrjkpPnerDrHBWqPRL1ZOqCPa+NDrUVj6U9YEeCXh/rDHoc67ZvFzeTHTcDJRsiU2x6xqoBBAH5tnj282HoQCUssDvAhgrfmyJ3texAwyMYi7u1BXkM7kTswIgNcAjsbfcDN/z3z/Z0Z5DDKeggQ406GxBvoqj9ejqC6LOKLRGVBXxoFjRA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wfsi8NsPgfQfqurOiKpzasFakivhEHsKXGlr7eOS4H8=; b=aqLOoegy47SsGiTM/O5R1zYCC53eh3lZoPxZyJvBzJp+hEJCzv0I39lVmwrlGB5Xi0xTfC5WH8zHdlw66caMocDjWJnoeayJao9oZv4Di/wWPHZ2nse3vWwe13XGURZkvOo563h7/CxwFveTxLgdMaYKOFIYI92+4fQzTgQcca/U9WOcKyFCCwrh81UOCRQ0c84vqPHgKHA7SMrd0CH+5P/wrk1Spb35e8th+NnCCOhV4WRnvomVWGP1Cbc4jES3OgdxisCTCeVVd5c5VJWY8QT3QWsznQNKa8bv//jP6ZVAvXdpySdI9xzuZD/BM5DV4oED7dHSqz56BlnjDRuwAg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=419.consulting; dmarc=pass action=none header.from=419.consulting; dkim=pass header.d=419.consulting; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT5189650.onmicrosoft.com; s=selector1-NETORGFT5189650-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wfsi8NsPgfQfqurOiKpzasFakivhEHsKXGlr7eOS4H8=; b=orzFAhnPvOc1hPP51zY58VAP98p87pBt+21XjAyAYRhVdKnfYAIjcZ4+LllG/znzL3Q3mzM24HhXdsTnoVc91gYCTv8KpSqnXu+2+cnhOBirqBVk6v3FBv3eyWMZrBFXu/XqZu/YDFzL+0/FzGjpSyOZPK8gUz4dJRo8NLSRa2c= Received: from LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:71::15) by LO2P265MB0510.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:65::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3305.24; Tue, 18 Aug 2020 21:52:22 +0000 Received: from LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM ([fe80::91fb:af23:a084:10cf]) by LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM ([fe80::91fb:af23:a084:10cf%7]) with mapi id 15.20.3283.028; Tue, 18 Aug 2020 21:52:22 +0000 From: Andrew Campling To: Joseph Touch CC: "architecture-discuss@ietf.org" Thread-Topic: [arch-d] A Public Option for the Core Thread-Index: AQHWdKenK98fLDHpWkWL9AhywtYz5qk+amNQ Date: Tue, 18 Aug 2020 21:52:22 +0000 Message-ID: References: <754DE168-DF3B-4471-A145-39C6143E538A@comcast.net> <1fd2ed7d-d4bc-c5b7-9a4a-7966d5e60513@gmail.com> <20200817074637.GW62842@faui48f.informatik.uni-erlangen.de> <3E4ACDE8-2DA4-45FC-9890-71CE93982182@strayalpha.com> In-Reply-To: <3E4ACDE8-2DA4-45FC-9890-71CE93982182@strayalpha.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: strayalpha.com; dkim=none (message not signed) header.d=none;strayalpha.com; dmarc=none action=none header.from=419.consulting; x-originating-ip: [89.34.98.114] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 55f3ae7d-f56c-43de-700e-08d843c0fc8a x-ms-traffictypediagnostic: LO2P265MB0510: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: DMJzLcxHtPnSDOShbJhtqrRwH9IO4pWpvIeeORNKmmHtIt9j9qQGlNM0uivk7x9+ZZ3iENuIQ0K7RCXADgsgU7hINthHBOTTR1XOJrFiDwASdwomLcSVHoSaavEKsyu3bJwzGJdcdwJ31J5bJcGbCuv9OlXeTNb749I6K8n0rWfNBNNcVtmW7Cevsh+3x9KFZwu74gawd+5CCo3N976d1MY+6jUhNrPuSpmYqjKrmN9Qyan2z0vNPfBlyYnZfYZx54DhXabv/XNZPeNfw2iIKWp82Bnbnq7myeggl7/y+rI176t5ksCMqiGkAqSSp+R+8XH1kocy3ZZ0rOUpRkyokS+WwRUJ4iC1ErdVcY3MMNvl7jP6++H4ImxDBvKHrAWx x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(39830400003)(366004)(346002)(136003)(396003)(376002)(478600001)(55016002)(26005)(44832011)(186003)(8936002)(86362001)(6916009)(33656002)(71200400001)(52536014)(316002)(76116006)(66946007)(9686003)(7696005)(83380400001)(53546011)(6506007)(8676002)(4326008)(64756008)(66556008)(66446008)(66476007)(5660300002)(2906002)(46492007); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: fBiP4RWf2usEAwy5UB9/232fr2Qq6vaqQFlGvHhZIajBZ7TEOaBAXaP5BmZCzsIrK7KI/kCGdGwadWbqzcnDw5sTE8OODvtcnFIAuVfudYQo1mZGBkIoRhE+P46ySaGgVbdteVORMkfb3DfDrdXx+5dV/UXQO7nLqVOnkvRtlW7psdEK3K3a37dqHK46qmgm/WsLmEylvHsLc/aTToxHev46t0sZF/x7kb/L7uOECmCftBlW+9JHDXNfxcB6baN185Epeghql9+1tIk5QLSui7CLv+k8caiSBxXkmtvcXlc2y81A1K8GC3ALZcaRQEJA4EaY/IxSPgxN17EVr1BJgBqv/sooxF0+xchp0ZBQEJQnzMS2QpbUGweCbL38VSO5p0FZeG0mlRoVsGrM9qR2wODepasaiaPEPaPdLfcYXA9hzltS86MNVt2Ztut8Q39F1p/T62A4dmdGPbi/FtQfO42Lkguo+zWBhUw8BwscFa2u4F7dE99b1UNFHGMS76PZmbyXYo8q4k6c3Kp3P1Wp06YTj7jcMp48StafXTnLdPMLYwdjSLRl8CL9yrZygyRF1e2reMduUy9OlJ0li17DvBA7m/+e08Zh0pbJOS/q4IpP5hBkuaNL1IS16ktGm7xH6Znx3HiR7N9mfyqEojH+hA== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_LO2P265MB0573C531502D8B7203B551A4C25C0LO2P265MB0573GBRP_" MIME-Version: 1.0 X-OriginatorOrg: 419.consulting X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 55f3ae7d-f56c-43de-700e-08d843c0fc8a X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Aug 2020 21:52:22.1818 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9c2ced3e-7522-4755-87dc-f983abc66ec3 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 2boc5Lozw03+e7n1B7Jl+kb8FqOBaeHQLdVH9nYwLubk8b6y7yXGQwck6JaYNkXUekbJ4K4iakSurIL3LYh9f8c5mGbky7ZHkvakIZ2PlGU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: LO2P265MB0510 Archived-At: Subject: Re: [arch-d] A Public Option for the Core X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2020 21:52:34 -0000 --_000_LO2P265MB0573C531502D8B7203B551A4C25C0LO2P265MB0573GBRP_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T24gQXVnIDE3LCAyMDIwLCBhdCAxNjo2NCwgSm9zZXBoIFRvdWNoIDx0b3VjaEBzdHJheWFscGhh LmNvbT4gd3JvdGU6DQoNCj4gT24gQXVnIDE3LCAyMDIwLCBhdCA2OjU1IEFNLCBBbmRyZXcgQ2Ft cGxpbmcgPGFuZHJldy5jYW1wbGluZ0A0MTkuY29uc3VsdGluZzxtYWlsdG86YW5kcmV3LmNhbXBs aW5nQDQxOS5jb25zdWx0aW5nPj4gd3JvdGU6DQo+Pg0KPj4gLi4uICBNeSBwZXJzb25hbCBwcmVm ZXJlbmNlIGlzIGZvciBuZXR3b3JrcyB0byBiZSB0cmFuc3BhcmVudCBpbiB0aGUgd2F5IHRoYXQg dGhleSBtYW5hZ2UgdHJhZmZpYyAoaWYgYXQgYWxsKSBzbyB0aGF0DQo+PiBJIGNhbiBjaG9vc2Ug bXkgbmV0d29yayBiYXNlZCBvbiB3aGF0IHRoZXkgZG8uDQo+DQo+IEhtbS4gSG93IG1hbnkgKmNo b2ljZXMqIGRvIHlvdSBoYXZlPw0KPg0KPiBUaGUgbGFzdCB0aW1lIEkgbG9va2VkLCBvdmVyIDEv MyBvZiB0aGUgVVMgaGFkIG9ubHkgb25lIElTUCwgaS5lLiwgbm8gY2hvaWNlLiBJ4oCZbSBpbiB0 aGUgbWV0cm8gYXJlYSBvZg0KPiB0aGUgc2Vjb25kIGxhcmdlc3QgVVMgY2l0eSBhbmQgaGF2ZSAy IOKAnGNob2ljZXPigJ0gZm9yIGhpZ2gtY2FwYWNpdHkgY29ubmVjdGl2aXR5IChpLmUuLCBub3Qg Y2VsbHVsYXIpLCBvbmUNCj4gb2Ygd2hpY2ggaXMgbmVhcmx5IGJhbmtydXB0Lg0KPg0KPiBBbmQg bGV04oCZcyBzYXkgSSBnZXQgYm90aCBvZiB0aG9zZSAtIGl04oCZcyBub3QgbGlrZSBJIGNhbiBy dW4gYXBwcyBjb25uZWN0ZWQgdG8gZGlmZmVyZW50IFdJRkkgYWNjZXNzDQo+IHBvaW50cyBhdCB0 aGUgc2FtZSB0aW1lIGZyb20gYSBzaW5nbGUgaG9zdC4NCg0KQmVjYXVzZSB0aGUgVUsgbWFuZGF0 ZXMgY29tcGV0aXRpb24gYmV0d2VlbiBJU1BzIGF0IHRoZSByZXRhaWwgbGV2ZWwgd2l0aCB3aG9s ZXNhbGUgbmV0d29yayBhY2Nlc3MsIHRoZXJlIGlzIHF1aXRlIGdvb2QgY2hvaWNlIGZyb20gYSBy YW5nZSBvZiBkaWZmZXJlbnQgSVNQcyBpbmNsdWRpbmcgYm90aCBtYXNzIG1hcmtldCBhbmQgbW9y ZSBuaWNoZSBwcm92aWRlcnMuICBJIGRvIG5vdGUgdGhvdWdoIHRoYXQgdGhlIHNpdHVhdGlvbiBp biB0aGUgVVMgaXMgdmVyeSBkaWZmZXJlbnQuDQoNClRoaXMgZG9lcyBvZiBjb3Vyc2UgaGVscGZ1 bGx5IHVuZGVybGluZSB0aGUgaW1wb3J0YW5jZSBvZiBub3QgZGVzaWduaW5nIHNjaGVtZXMgYmFz ZWQgb24gdGhlIGFzc3VtcHRpb24gdGhhdCBhbGwgbWFya2V0cyBhcmUgdGhlIHNhbWUgYXMgdGhl IG9uZSB3aXRoIHdoaWNoIHdlIGFyZSBtb3N0IGZhbWlsaWFyLg0KDQoNCkFuZHJldw0K --_000_LO2P265MB0573C531502D8B7203B551A4C25C0LO2P265MB0573GBRP_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5k b3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3 OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRT ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIg Lz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVs YXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8 L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJF Ti1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlv bjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQi Pk9uIEF1ZyAxNywgMjAyMCwgYXQgMTY6NjQsIDwvc3Bhbj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Sm9zZXBoIFRvdWNoICZsdDt0b3VjaEBzdHJheWFscGhh LmNvbSZndDsgPC9zcGFuPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPndyb3RlOjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Jmd0OyBPbiBBdWcgMTcs IDIwMjAsIGF0IDY6NTUgQU0sIEFuZHJldyBDYW1wbGluZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFu ZHJldy5jYW1wbGluZ0A0MTkuY29uc3VsdGluZyI+YW5kcmV3LmNhbXBsaW5nQDQxOS5jb25zdWx0 aW5nPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZndDsmZ3Q7PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQiPiZndDsmZ3Q7IC4uLiAmbmJzcDtNeSBwZXJzb25hbCBwcmVmZXJlbmNlIGlz IGZvciBuZXR3b3JrcyB0byBiZSB0cmFuc3BhcmVudCBpbiB0aGUgd2F5IHRoYXQgdGhleSBtYW5h Z2UgdHJhZmZpYyAoaWYgYXQgYWxsKSBzbyB0aGF0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZndDsmZ3Q7 IEkgY2FuIGNob29zZSBteSBuZXR3b3JrIGJhc2VkIG9uIHdoYXQgdGhleSBkby48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdCI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mZ3Q7IEhtbS4gSG93IG1hbnkg KmNob2ljZXMqIGRvIHlvdSBoYXZlPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mZ3Q7PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQiPiZndDsgVGhlIGxhc3QgdGltZSBJIGxvb2tlZCwgb3ZlciAxLzMgb2YgdGhl IFVTIGhhZCBvbmx5IG9uZSBJU1AsIGkuZS4sIG5vIGNob2ljZS4gSeKAmW0gaW4gdGhlIG1ldHJv IGFyZWEgb2YNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mZ3Q7IHRoZSBzZWNvbmQgbGFyZ2VzdCBVUyBj aXR5IGFuZCBoYXZlIDIg4oCcY2hvaWNlc+KAnSBmb3IgaGlnaC1jYXBhY2l0eSBjb25uZWN0aXZp dHkgKGkuZS4sIG5vdCBjZWxsdWxhciksIG9uZQ0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZndDsgb2Yg d2hpY2ggaXMgbmVhcmx5IGJhbmtydXB0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mZ3Q7PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQiPiZndDsgQW5kIGxldOKAmXMgc2F5IEkgZ2V0IGJvdGggb2YgdGhvc2Ug LSBpdOKAmXMgbm90IGxpa2UgSSBjYW4gcnVuIGFwcHMgY29ubmVjdGVkIHRvIGRpZmZlcmVudCBX SUZJIGFjY2Vzcw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZndDsgcG9pbnRzIGF0IHRoZSBzYW1lIHRp bWUgZnJvbSBhIHNpbmdsZSBob3N0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O21zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDttc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUyI+QmVjYXVzZSB0aGUgVUsgbWFuZGF0ZXMgY29tcGV0aXRpb24gYmV0d2VlbiBJU1BzIGF0 IHRoZSByZXRhaWwgbGV2ZWwgd2l0aCB3aG9sZXNhbGUgbmV0d29yayBhY2Nlc3MsIHRoZXJlIGlz IHF1aXRlIGdvb2QgY2hvaWNlIGZyb20gYSByYW5nZSBvZiBkaWZmZXJlbnQgSVNQcyBpbmNsdWRp bmcgYm90aCBtYXNzDQogbWFya2V0IGFuZCBtb3JlIG5pY2hlIHByb3ZpZGVycy4mbmJzcDsgSSBk byBub3RlIHRob3VnaCB0aGF0IHRoZSBzaXR1YXRpb24gaW4gdGhlIFVTIGlzIHZlcnkgZGlmZmVy ZW50LiZuYnNwOyAmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDttc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi PlRoaXMgZG9lcyBvZiBjb3Vyc2UgaGVscGZ1bGx5IHVuZGVybGluZSB0aGUgaW1wb3J0YW5jZSBv ZiBub3QgZGVzaWduaW5nIHNjaGVtZXMgYmFzZWQgb24gdGhlIGFzc3VtcHRpb24gdGhhdCBhbGwg bWFya2V0cyBhcmUgdGhlIHNhbWUgYXMgdGhlIG9uZSB3aXRoIHdoaWNoIHdlIGFyZSBtb3N0IGZh bWlsaWFyLiZuYnNwOw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+QW5k cmV3DQo8bzpwPjwvbzpwPjwvc3Bhbj48L2I+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+ DQo= --_000_LO2P265MB0573C531502D8B7203B551A4C25C0LO2P265MB0573GBRP_-- From nobody Tue Aug 18 20:10:37 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03DCA3A10E6 for ; Tue, 18 Aug 2020 20:10:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.118 X-Spam-Level: X-Spam-Status: No, score=-1.118 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] 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 JXpl0klZqiAl for ; Tue, 18 Aug 2020 20:10:33 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF2A33A10E4 for ; Tue, 18 Aug 2020 20:10:32 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id C80C4548622; Wed, 19 Aug 2020 05:02:39 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id BBE3F440059; Wed, 19 Aug 2020 05:02:39 +0200 (CEST) Date: Wed, 19 Aug 2020 05:02:39 +0200 From: Toerless Eckert To: Brian E Carpenter Cc: architecture-discuss@ietf.org Message-ID: <20200819030239.GJ62842@faui48f.informatik.uni-erlangen.de> References: <754DE168-DF3B-4471-A145-39C6143E538A@comcast.net> <1fd2ed7d-d4bc-c5b7-9a4a-7966d5e60513@gmail.com> <20200817074637.GW62842@faui48f.informatik.uni-erlangen.de> <60B2B44D-5E6D-4CB2-AD63-1A8CB846BFA3@strayalpha.com> <0e575946-dfd4-7753-8c34-47987d0b3c7e@huitema.net> <20200817164256.GB62842@faui48f.informatik.uni-erlangen.de> <20200818052641.GE62842@faui48f.informatik.uni-erlangen.de> <6998f7af-7834-3aa3-300d-410036cd2466@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6998f7af-7834-3aa3-300d-410036cd2466@gmail.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [arch-d] A Public Option for the Core X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2020 03:10:36 -0000 On Wed, Aug 19, 2020 at 09:23:31AM +1200, Brian E Carpenter wrote: > On 18-Aug-20 17:26, Toerless Eckert wrote: > > > > Multiple parallel TCP connections to overcome TCP issues with high > > capacity high loss paths even in the absence of congestion was always > > a bad workaround. > > It's certainly a workaround, but why was it particularly bad? Ships in the night (no coupled CC) between the multiple parallel TCP sessions across the same path. Given how DoE HEP money was repsonsible for a lot of US/EU transcontinental capacity even in the 80th/90th, there must have been enough money around to look at this problem before 2000, but alas progress was limited by having to muck around in BSD kernel for the most part. > The context where GridFTP was developed and used was the world of very > high capacity links between major Big Data sites; it's actually a > good example for RFC8799 that we overlooked. No worries. Everything exccept the paths used to grow amazon, facebook and google was and is is limited domains ;-)) > If you really want maximum throughput on such links, which also have > very low bit error rates, you can use a non-windowing, rate-controlled > transport protocol with simplified error handling. I think one of the issues was that in the 90th a lot of the paths used by researchers where still controlled/limited-domains, and when they started to buy more into general purpose internet capacity, the available paths became even worse due to bufferbloat, which maybe explaining more focus on hose really bad high capacity, high loss paths later on. > But that's not an IETF problem, really. Why not. AFAIK it was, is and should be. Even had an FECFRAME WG for a while. > > Digital Fountain was already selling software 15 years > > ago with scatter storage and network coding gather retrieval. Still > > network coding researchers seem to claim this stuff is new today. > > The network coding literature goes back to at least 2000**. Yes, but at that time the more exciting new usse of it was multicast, only a few yers later did the technology became a mayor player to solve the supposedly easer problem of bad high capacity unicast paths (a least from the one off stories i was told). > The network coding people I know are aiming at a different problem > area today: poor quality wireless and/or overloaded satellite links. Sure. research wise they probably think the other areas are done, but that still doesn't mean we have a good ubiquitously availale NC based unicast reliable transport standardized. IPR played a big roole IMHO in throttling wide ranging adoption/standardization. Cheers Toerless > Exactly the opposite of the Big Data scenario. (However, I am not > tracking the NWCRG. I am rather amazed by the lack of references > to the extensive literature in RFC8406, but draft-irtf-nwcrg-nwc-ccn-reqs > does better.) > > > A lot of of the network side problems of this are the result of the > > traditional, uncontrolled transit SP paths, aka: the classical Internet > > model. > > Indeed. > > Regards > Brian > > ** R. Ahlswede, N. Cai, S.-Y.R. Li and R.W. Yeung, ???Network > Information Flow???, IEEE-IT, vol. 46, pp. 1204-1216, 2000. > > > > Cheers > > Toerless > > > > On Tue, Aug 18, 2020 at 11:54:34AM +1200, Brian E Carpenter wrote: > >> On 18-Aug-20 04:42, Toerless Eckert wrote: > >> ... > >> > >>> -> I would like for traffic to get bandwidth share indpendent of the > >>> number of 5 tuple flows it utilizes (no gaming the system). But > >>> rather fair per subscriber (weighted by how much the subscriber pays). > >> > >> You just broke GridFTP, used in Big Science to move terabyte datasets > >> around the world efficiently. It's not gaming, it's achieving throughput > >> despite defects in TCP. But the topic is very much alive there, since > >> GridFTP is now unsupported. > >> > >> For further reading: > >> https://twiki.cern.ch/twiki/bin/view/LCG/ThirdPartyCopy > >> > >> Brian > > -- --- tte@cs.fau.de From nobody Tue Aug 25 14:47:47 2020 Return-Path: X-Original-To: architecture-discuss@ietf.org Delivered-To: architecture-discuss@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EB3733A0C26; Tue, 25 Aug 2020 14:47:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: IAB Executive Administrative Manager To: Cc: edm@iab.org X-Test-IDTracker: no X-IETF-IDTracker: 7.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159839206489.26388.9889652884666821@ietfa.amsl.com> Date: Tue, 25 Aug 2020 14:47:44 -0700 Archived-At: Subject: [arch-d] New IAB Program: Evolvability, Deployability, & Maintainability (EDM) X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2020 21:47:45 -0000 A new IAB Program has been formed on Evolvability, Deployability, & Maintainability (EDM). For additional information, please contact the IAB or the Program Lead. Evolvability, Deployability, & Maintainability (EDM) Program ----------------------------------------------------------------------- IAB Lead: Tommy Pauly Mailing list: Address: edm@iab.org To subscribe: https://www.iab.org/mailman/listinfo/edm Archive: https://mailarchive.ietf.org/arch/browse/edm/ Program Page: https://www.iab.org/activities/programs/evolvability-deployability-maintainability-edm-program/ Program Description: This program will focus on how to practically encourage best practices within the IETF to ensure that the IETF’s standards process considers protocol evolution, deployability, and long-term maintainability. This group will work on documents that catalog and analyze successful strategies for protocol evolution, deployment, and maintenance, such as updating and extending RFC 6709. Moreover, it will focus on ways to help promote and increase awareness of these strategies within the IETF via program meetings, workshops, and helping organize efforts within working groups and various IETF teams. The program will include members of the IESG and the tools team to help implement these strategies. The topics this group will consider include: * Evolvability: Encourage protocols to design for extensibility and greasing, and promote the use of extension points to prevent ossification. Make it easy for people, especially those who aren’t steeped in IETF process, to know which extension points are the right ones to use for a given protocol (and which ones should be considered more stable/ossified), and make sure there aren’t high allocation barriers to use those extension points. * Deployability: Focus on how we make “running code” something that is better integrated into the working group process. Look at methods to catalog implementations, tools for tracking interoperability testing on different protocol versions, or repositories of which versions of protocols are implemented and used on the Internet. Discuss how deployments can advertise experiments they are running. * Maintainability: Many working groups have expressed a desire to have ways for the community of protocol designers and implementers to keep track of the current state of affairs in deployment patterns, known errata/bugs, or best practices. Help promote consistent ways to host non-RFC working group output, like FAQs, wikis, and discussion venues. Consider how this community involvement can continue and involve the right experts, even after a working group closes. The program will: * Engage with the IETF community and implementers outside of the IETF to identity successes and problem areas, and collect ideas for improvements. * Work with the IESG and directorates to determine how best practices for evolvability can best be applied during IESG review and IETF last call. * Work with the IESG and tools team on ways to connect implementers and communities that develop and maintain protocols, both while a working group is active, and after a working group has concluded its charter. From nobody Tue Aug 25 14:53:49 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EDDA3A0C34 for ; Tue, 25 Aug 2020 14:53:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.4 X-Spam-Level: X-Spam-Status: No, score=0.4 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 2OqsvDjmtZvC for ; Tue, 25 Aug 2020 14:53:46 -0700 (PDT) Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com [IPv6:2607:f8b0:4864:20::52f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12F4A3A0C27 for ; Tue, 25 Aug 2020 14:53:46 -0700 (PDT) Received: by mail-pg1-x52f.google.com with SMTP id v15so7754797pgh.6 for ; Tue, 25 Aug 2020 14:53:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=+4ivqI2lqd/3YU4etj7lrvtxytVtpsWr1WMmFxvuVDc=; b=VSgb5lySf0fYqERenbe9I+S7pvaVdLgqJnBjfZtQmNJiEsxQKZaNhvrl2b3LD3SvkA K4igN1hXEc+XhxMhQdLfnC78yQZmxQQKuQm2ZE73a+nXKdfGLbkdvIEWymmwQpTH030U +CuXo/EPsMG9zcGcp3yj7UG7J8m2q38gYvMwk8Gy9YXXNHlhn7QwmtPilrsZa4Q/lWZ/ 7HNSbSdNTngmh+PmtJnyNAXDR7xM9pvJfBbqTVFgfPg3WndQLemlRTv3JeUSdIZC6Wdq z5eBiy5Nre/UHAvjY3z53UYEhpeY+XfxSDZXHtkfnl3dFESO/0HG1iiLfLr9tq8PP7y5 ddwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:mime-version:subject:from:in-reply-to :date:cc:content-transfer-encoding:message-id:references:to; bh=+4ivqI2lqd/3YU4etj7lrvtxytVtpsWr1WMmFxvuVDc=; b=dE85AU/oXDerynVWzAibGwPj/UQguL14fgAN9J0QnHp96lBO473vaWh5aEW6sRn62f SLhE9Lc4emK3UZW/RH7ytjAHlcJV2EBeCQkz/ir9k/ETrH37dHJGHlXa8GOuNAW1i7Qj nc/vioYJZ3xrHc2eaHuzZ1xE3ewH5bBHjTtZdD2b37fT1dfkmmMNWl/ro3eHPtZIXD4C qLTCopHVLYbSEmWT7juHkjZPgJP9O6Xyr/Ur/JZxfRVkP7yKtHlx0BMTXLMHr+0l1fkA L1W2dWTjLPF5M/44u/9G6i03BcokyA9BydLuy0xXhsOJzdyg9hYvgfaZ156auYHP87V2 fkOg== X-Gm-Message-State: AOAM530m6ncF6DYf+2FY+RE6lLw7Bg1F4Clw6E2MiNNni+eB8eiJjRk2 eMx0S45fNWQwzQbSGxpBqFQ1iPJosQA= X-Google-Smtp-Source: ABdhPJw7xgzaIjFS3vEXoglMczL0CXQXURdMf+ELFIYnG623SlqjZD+JRuKfVcNm8Aik6L6Ak0PmFQ== X-Received: by 2002:a63:f70e:: with SMTP id x14mr6250903pgh.407.1598392425498; Tue, 25 Aug 2020 14:53:45 -0700 (PDT) Received: from [10.95.82.114] ([162.210.129.5]) by smtp.gmail.com with ESMTPSA id j13sm201724pfn.166.2020.08.25.14.53.43 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 25 Aug 2020 14:53:44 -0700 (PDT) Sender: Tony Li Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: tony.li@tony.li In-Reply-To: <159839206489.26388.9889652884666821@ietfa.amsl.com> Date: Tue, 25 Aug 2020 14:53:41 -0700 Cc: architecture-discuss@ietf.org, edm@iab.org Content-Transfer-Encoding: quoted-printable Message-Id: <1D675EBC-4AC7-4E01-87CC-4DF4F0D9DD3C@tony.li> References: <159839206489.26388.9889652884666821@ietfa.amsl.com> To: IAB Executive Administrative Manager X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [arch-d] New IAB Program: Evolvability, Deployability, & Maintainability (EDM) X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2020 21:53:48 -0000 Seems like point 1 should be ignoring pointless IAB programs. There=E2=80=99s work to be done. This isn=E2=80=99t it. Tony > On Aug 25, 2020, at 2:47 PM, IAB Executive Administrative Manager = wrote: >=20 > A new IAB Program has been formed on Evolvability, Deployability, &=20 > Maintainability (EDM). For additional information, please contact the=20= > IAB or the Program Lead. >=20 > Evolvability, Deployability, & Maintainability (EDM) Program > = ----------------------------------------------------------------------- >=20 > IAB Lead: > Tommy Pauly >=20 > Mailing list: > Address: edm@iab.org > To subscribe: https://www.iab.org/mailman/listinfo/edm > Archive: https://mailarchive.ietf.org/arch/browse/edm/ >=20 >=20 > Program Page: = https://www.iab.org/activities/programs/evolvability-deployability-maintai= nability-edm-program/ >=20 > Program Description: >=20 > This program will focus on how to practically encourage best practices=20= > within the IETF to ensure that the IETF=E2=80=99s standards process = considers=20 > protocol evolution, deployability, and long-term maintainability. This=20= > group will work on documents that catalog and analyze successful=20 > strategies for protocol evolution, deployment, and maintenance, such = as=20 > updating and extending RFC 6709. Moreover, it will focus on ways to = help=20 > promote and increase awareness of these strategies within the IETF via=20= > program meetings, workshops, and helping organize efforts within = working=20 > groups and various IETF teams. The program will include members of the=20= > IESG and the tools team to help implement these strategies. >=20 > The topics this group will consider include: >=20 > * Evolvability: Encourage protocols to design for extensibility and=20 > greasing, and promote the use of extension points to prevent=20 > ossification. Make it easy for people, especially those who aren=E2=80=99= t=20 > steeped in IETF process, to know which extension points are the right=20= > ones to use for a given protocol (and which ones should be considered=20= > more stable/ossified), and make sure there aren=E2=80=99t high = allocation=20 > barriers to use those extension points. >=20 > * Deployability: Focus on how we make =E2=80=9Crunning code=E2=80=9D = something that is=20 > better integrated into the working group process. Look at methods to=20= > catalog implementations, tools for tracking interoperability testing=20= > on different protocol versions, or repositories of which versions of=20= > protocols are implemented and used on the Internet. Discuss how=20 > deployments can advertise experiments they are running. >=20 > * Maintainability: Many working groups have expressed a desire to have=20= > ways for the community of protocol designers and implementers to keep=20= > track of the current state of affairs in deployment patterns, known=20= > errata/bugs, or best practices. Help promote consistent ways to host=20= > non-RFC working group output, like FAQs, wikis, and discussion = venues.=20 > Consider how this community involvement can continue and involve the=20= > right experts, even after a working group closes. >=20 > The program will: >=20 > * Engage with the IETF community and implementers outside of the IETF = to=20 > identity successes and problem areas, and collect ideas for=20 > improvements. > * Work with the IESG and directorates to determine how best practices=20= > for evolvability can best be applied during IESG review and IETF last=20= > call. > * Work with the IESG and tools team on ways to connect implementers = and=20 > communities that develop and maintain protocols, both while a working=20= > group is active, and after a working group has concluded its charter. >=20 > _______________________________________________ > Architecture-discuss mailing list > Architecture-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/architecture-discuss From nobody Tue Aug 25 23:11:45 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 658783A0DDF for ; Tue, 25 Aug 2020 23:11:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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=mnot.net header.b=dy7cUXWT; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=stNpIhUo 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 BLXkG-ddMxaI for ; Tue, 25 Aug 2020 23:11:41 -0700 (PDT) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 935A13A0DDA for ; Tue, 25 Aug 2020 23:11:41 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id A10CAEB4; Wed, 26 Aug 2020 02:11:40 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Wed, 26 Aug 2020 02:11:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm3; bh=6 3Sx16ye2dasZ4UA2ND2jrB08HHGQSXaivdvvhDWYEk=; b=dy7cUXWTVZztWDhqb vWiC/j44i3WCPKxa4BOUdU004nXuG/Meik8Xbq7vlRILcToxGTl8sb25mj8gyj0S EjTJtf8iAj6A4Y4BC9cCa13EJNJKc9KplwyDZayBiUZYk0J1PxvU4lEiflHNzHAF TQxXtoFSo9yz4hitGdCtMUW3xcp2QWGmcCNIRYV00tpxivKuEaZdM9oEhQNFqa/P r4rVnVyoUSux81VyCwWLspA3gvywKjSVFbipBGZP7EQlzjWYjkhst/dmmV1eNZ9Y wRcEi4uRUxhwqxIoO9q/IAd4WutrSCST1f+v6/Nun0KDKOyqnaxcgHHTOvJQ1NiG J0Mug== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=63Sx16ye2dasZ4UA2ND2jrB08HHGQSXaivdvvhDWY Ek=; b=stNpIhUo0M+DHXiFhFutW5/86LeOFRdKO0t7sz18rcbYZFcf05fehYn2G jLOd4wB3Sim843CynlfoBQEyO0oeD3ffycnd8bG5qKR8AbHFatqPxeajLMALBw+/ j7DMjfvBmcJ1jQ4BQzTvA1ThofTbQmRHVQrQKnEHGeHsJSal843akcwcz4LiUqFU hKgkpETsHW8VHdR3Tl3LTsm0c+qU0KixOkjmu9ITIRUpjvx6S4gUCuoUMbhHzKoe T+VEntm6+uIJtxRon5BdIqpQrlCpnsqVO2YLbGAlhnUvnJfUyf8gkJh0Ff905Z/b WLxmpTumsyvmhs+MrRFo/SPlR2xzg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedruddvuddguddtkecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtdejnecuhfhrohhmpeforghr khcupfhothhtihhnghhhrghmuceomhhnohhtsehmnhhothdrnhgvtheqnecuggftrfgrth htvghrnhepudfhtddugeeftdefkeevveeghfevveffteejfeekheetgeelhfdvhfffvdef hffgnecuffhomhgrihhnpehirggsrdhorhhgpdhivghtfhdrohhrghdpmhhnohhtrdhnvg htnecukfhppeduudelrddujedrudehkedrvdehudenucevlhhushhtvghrufhiiigvpedt necurfgrrhgrmhepmhgrihhlfhhrohhmpehmnhhothesmhhnohhtrdhnvght X-ME-Proxy: Received: from [192.168.7.30] (119-17-158-251.77119e.mel.static.aussiebb.net [119.17.158.251]) by mail.messagingengine.com (Postfix) with ESMTPA id 80900328005D; Wed, 26 Aug 2020 02:11:37 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Mark Nottingham In-Reply-To: <1D675EBC-4AC7-4E01-87CC-4DF4F0D9DD3C@tony.li> Date: Wed, 26 Aug 2020 16:11:33 +1000 Cc: IAB Executive Administrative Manager , edm@iab.org, architecture-discuss@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <6BC67FE7-5517-4733-96F1-A7991ABD9AF7@mnot.net> References: <159839206489.26388.9889652884666821@ietfa.amsl.com> <1D675EBC-4AC7-4E01-87CC-4DF4F0D9DD3C@tony.li> To: tony.li@tony.li X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [arch-d] [Edm] New IAB Program: Evolvability, Deployability, & Maintainability (EDM) X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2020 06:11:43 -0000 Tony, Do you have any constructive feedback about the program, or other work = that we should focus on? Just calling it 'pointless' doesn't help. > On 26 Aug 2020, at 7:53 am, tony.li@tony.li wrote: >=20 >=20 > Seems like point 1 should be ignoring pointless IAB programs. >=20 > There=E2=80=99s work to be done. This isn=E2=80=99t it. >=20 > Tony >=20 >=20 >> On Aug 25, 2020, at 2:47 PM, IAB Executive Administrative Manager = wrote: >>=20 >> A new IAB Program has been formed on Evolvability, Deployability, &=20= >> Maintainability (EDM). For additional information, please contact the=20= >> IAB or the Program Lead. >>=20 >> Evolvability, Deployability, & Maintainability (EDM) Program >> = ----------------------------------------------------------------------- >>=20 >> IAB Lead: >> Tommy Pauly >>=20 >> Mailing list: >> Address: edm@iab.org >> To subscribe: https://www.iab.org/mailman/listinfo/edm >> Archive: https://mailarchive.ietf.org/arch/browse/edm/ >>=20 >>=20 >> Program Page: = https://www.iab.org/activities/programs/evolvability-deployability-maintai= nability-edm-program/ >>=20 >> Program Description: >>=20 >> This program will focus on how to practically encourage best = practices=20 >> within the IETF to ensure that the IETF=E2=80=99s standards process = considers=20 >> protocol evolution, deployability, and long-term maintainability. = This=20 >> group will work on documents that catalog and analyze successful=20 >> strategies for protocol evolution, deployment, and maintenance, such = as=20 >> updating and extending RFC 6709. Moreover, it will focus on ways to = help=20 >> promote and increase awareness of these strategies within the IETF = via=20 >> program meetings, workshops, and helping organize efforts within = working=20 >> groups and various IETF teams. The program will include members of = the=20 >> IESG and the tools team to help implement these strategies. >>=20 >> The topics this group will consider include: >>=20 >> * Evolvability: Encourage protocols to design for extensibility and=20= >> greasing, and promote the use of extension points to prevent=20 >> ossification. Make it easy for people, especially those who aren=E2=80=99= t=20 >> steeped in IETF process, to know which extension points are the right=20= >> ones to use for a given protocol (and which ones should be considered=20= >> more stable/ossified), and make sure there aren=E2=80=99t high = allocation=20 >> barriers to use those extension points. >>=20 >> * Deployability: Focus on how we make =E2=80=9Crunning code=E2=80=9D = something that is=20 >> better integrated into the working group process. Look at methods to=20= >> catalog implementations, tools for tracking interoperability testing=20= >> on different protocol versions, or repositories of which versions of=20= >> protocols are implemented and used on the Internet. Discuss how=20 >> deployments can advertise experiments they are running. >>=20 >> * Maintainability: Many working groups have expressed a desire to = have=20 >> ways for the community of protocol designers and implementers to keep=20= >> track of the current state of affairs in deployment patterns, known=20= >> errata/bugs, or best practices. Help promote consistent ways to host=20= >> non-RFC working group output, like FAQs, wikis, and discussion = venues.=20 >> Consider how this community involvement can continue and involve the=20= >> right experts, even after a working group closes. >>=20 >> The program will: >>=20 >> * Engage with the IETF community and implementers outside of the IETF = to=20 >> identity successes and problem areas, and collect ideas for=20 >> improvements. >> * Work with the IESG and directorates to determine how best practices=20= >> for evolvability can best be applied during IESG review and IETF last=20= >> call. >> * Work with the IESG and tools team on ways to connect implementers = and=20 >> communities that develop and maintain protocols, both while a working=20= >> group is active, and after a working group has concluded its charter. >>=20 >> _______________________________________________ >> Architecture-discuss mailing list >> Architecture-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/architecture-discuss >=20 > --=20 > Edm mailing list > Edm@iab.org > https://www.iab.org/mailman/listinfo/edm -- Mark Nottingham https://www.mnot.net/ From nobody Wed Aug 26 07:37:16 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41BE93A1533 for ; Wed, 26 Aug 2020 07:37:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 fezsY99o8Mxr for ; Wed, 26 Aug 2020 07:37:13 -0700 (PDT) Received: from mail-pg1-f177.google.com (mail-pg1-f177.google.com [209.85.215.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 933BC3A0D4D for ; Wed, 26 Aug 2020 07:37:13 -0700 (PDT) Received: by mail-pg1-f177.google.com with SMTP id i10so1134168pgk.1 for ; Wed, 26 Aug 2020 07:37:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=8m8QpXN/8Zg1H1piYtMy1KWOWjR9z0Qr+rhxWdpOBVU=; b=madRab/X9fJl0l2b7FAh1B3S0XuIaVUhd04xTZLhlyMMhxcEHRmJLHqMJCzEQyWaPu G2CcrETKzljUH/jkUMRFeLWpLpLeKEvynviCkHHQLgtA0ZfDPXEk2UP1bBeeCh+eOrU0 xT8V4ZgNvQcXJpg2M8a5sa65F9TIDwPmt44g65JUG88aZxWuMvS19ygIHB/BFRCeMrTE VFeA1TUi4HeCJ5ArriHt0Nml0uZ9wfUso7HHtgbjJl2XsHBuL0Lue60TwptOKgIOoMtS p04OLDV/dMQWoqMWtLfnbFg8E0y1rjrk1qa3Gpty+T3XNk1K//kIohT+HyxFAPU9kfSp 2R3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:mime-version:subject:from:in-reply-to :date:cc:content-transfer-encoding:message-id:references:to; bh=8m8QpXN/8Zg1H1piYtMy1KWOWjR9z0Qr+rhxWdpOBVU=; b=kcDuVkgqgu1rD2H1O2Pw5sI9fOnHzZNiHOFJy0xOMAkFtdoW3ATp9CuA7ff8zbDtQ1 GeyfwS2M6nqfF9vh8hMetTMgkXisZpQkaSgNR6UckEz54qaw7PQ9e5Jd90E+xZlblGZR saki5bMAwZMlrKXPgYGb4wlubVqvMShioKVmU6uDDY1VyY5tlYJiH56MfJ9R2kD0UAZv ELl4lTcyvgl0B6/bsfWtD5zIM+KAu7C+SHJCLB3wQlgyLpcE3nG+ujgH5MscYt/WUhN7 +H7EWsHfcPWkBL0mHM+BPM4T1269J3v6RE3nl9gN88G0mp5qEkIU+X3z3wSE06U1dldN nvFQ== X-Gm-Message-State: AOAM533LSSA+zTtU9kkBjk52+mkjeiO5gJyN7rWSFaVrWeEUyRUV3LjX QAgJBs4mFQMN8/GJW7iJ7M3DdPhexKc= X-Google-Smtp-Source: ABdhPJyA2pekcnN1dkKl7LdlnBt7D1rrtxJ1+bXghqqsLfDPlLvfBeXnS3GQuc1e6vG6wAGiooT9Qg== X-Received: by 2002:a63:1457:: with SMTP id 23mr11028526pgu.80.1598452572892; Wed, 26 Aug 2020 07:36:12 -0700 (PDT) Received: from [10.95.80.107] ([162.210.129.5]) by smtp.gmail.com with ESMTPSA id v78sm3508920pfc.121.2020.08.26.07.36.11 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 26 Aug 2020 07:36:12 -0700 (PDT) Sender: Tony Li Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: tony.li@tony.li In-Reply-To: <6BC67FE7-5517-4733-96F1-A7991ABD9AF7@mnot.net> Date: Wed, 26 Aug 2020 07:36:07 -0700 Cc: IAB Executive Administrative Manager , edm@iab.org, architecture-discuss@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <6B5BBDD0-32F5-4E96-ADB8-813E4EA2A2A9@tony.li> References: <159839206489.26388.9889652884666821@ietfa.amsl.com> <1D675EBC-4AC7-4E01-87CC-4DF4F0D9DD3C@tony.li> <6BC67FE7-5517-4733-96F1-A7991ABD9AF7@mnot.net> To: Mark Nottingham X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [arch-d] [Edm] New IAB Program: Evolvability, Deployability, & Maintainability (EDM) X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2020 14:37:15 -0000 Mark, The starting point should be a clear problem statement. With examples. Tony > On Aug 25, 2020, at 11:11 PM, Mark Nottingham wrote: >=20 > Tony, >=20 > Do you have any constructive feedback about the program, or other work = that we should focus on? Just calling it 'pointless' doesn't help. >=20 >=20 >> On 26 Aug 2020, at 7:53 am, tony.li@tony.li wrote: >>=20 >>=20 >> Seems like point 1 should be ignoring pointless IAB programs. >>=20 >> There=E2=80=99s work to be done. This isn=E2=80=99t it. >>=20 >> Tony >>=20 >>=20 >>> On Aug 25, 2020, at 2:47 PM, IAB Executive Administrative Manager = wrote: >>>=20 >>> A new IAB Program has been formed on Evolvability, Deployability, &=20= >>> Maintainability (EDM). For additional information, please contact = the=20 >>> IAB or the Program Lead. >>>=20 >>> Evolvability, Deployability, & Maintainability (EDM) Program >>> = ----------------------------------------------------------------------- >>>=20 >>> IAB Lead: >>> Tommy Pauly >>>=20 >>> Mailing list: >>> Address: edm@iab.org >>> To subscribe: https://www.iab.org/mailman/listinfo/edm >>> Archive: https://mailarchive.ietf.org/arch/browse/edm/ >>>=20 >>>=20 >>> Program Page: = https://www.iab.org/activities/programs/evolvability-deployability-maintai= nability-edm-program/ >>>=20 >>> Program Description: >>>=20 >>> This program will focus on how to practically encourage best = practices=20 >>> within the IETF to ensure that the IETF=E2=80=99s standards process = considers=20 >>> protocol evolution, deployability, and long-term maintainability. = This=20 >>> group will work on documents that catalog and analyze successful=20 >>> strategies for protocol evolution, deployment, and maintenance, such = as=20 >>> updating and extending RFC 6709. Moreover, it will focus on ways to = help=20 >>> promote and increase awareness of these strategies within the IETF = via=20 >>> program meetings, workshops, and helping organize efforts within = working=20 >>> groups and various IETF teams. The program will include members of = the=20 >>> IESG and the tools team to help implement these strategies. >>>=20 >>> The topics this group will consider include: >>>=20 >>> * Evolvability: Encourage protocols to design for extensibility and=20= >>> greasing, and promote the use of extension points to prevent=20 >>> ossification. Make it easy for people, especially those who aren=E2=80= =99t=20 >>> steeped in IETF process, to know which extension points are the = right=20 >>> ones to use for a given protocol (and which ones should be = considered=20 >>> more stable/ossified), and make sure there aren=E2=80=99t high = allocation=20 >>> barriers to use those extension points. >>>=20 >>> * Deployability: Focus on how we make =E2=80=9Crunning code=E2=80=9D = something that is=20 >>> better integrated into the working group process. Look at methods to=20= >>> catalog implementations, tools for tracking interoperability testing=20= >>> on different protocol versions, or repositories of which versions of=20= >>> protocols are implemented and used on the Internet. Discuss how=20 >>> deployments can advertise experiments they are running. >>>=20 >>> * Maintainability: Many working groups have expressed a desire to = have=20 >>> ways for the community of protocol designers and implementers to = keep=20 >>> track of the current state of affairs in deployment patterns, known=20= >>> errata/bugs, or best practices. Help promote consistent ways to host=20= >>> non-RFC working group output, like FAQs, wikis, and discussion = venues.=20 >>> Consider how this community involvement can continue and involve the=20= >>> right experts, even after a working group closes. >>>=20 >>> The program will: >>>=20 >>> * Engage with the IETF community and implementers outside of the = IETF to=20 >>> identity successes and problem areas, and collect ideas for=20 >>> improvements. >>> * Work with the IESG and directorates to determine how best = practices=20 >>> for evolvability can best be applied during IESG review and IETF = last=20 >>> call. >>> * Work with the IESG and tools team on ways to connect implementers = and=20 >>> communities that develop and maintain protocols, both while a = working=20 >>> group is active, and after a working group has concluded its = charter. >>>=20 >>> _______________________________________________ >>> Architecture-discuss mailing list >>> Architecture-discuss@ietf.org >>> https://www.ietf.org/mailman/listinfo/architecture-discuss >>=20 >> --=20 >> Edm mailing list >> Edm@iab.org >> https://www.iab.org/mailman/listinfo/edm >=20 > -- > Mark Nottingham https://www.mnot.net/ >=20 From nobody Wed Aug 26 19:56:53 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E91063A0C95; Wed, 26 Aug 2020 19:56:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 fXfS2TmPtj7A; Wed, 26 Aug 2020 19:56:50 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AA173A0C8F; Wed, 26 Aug 2020 19:56:50 -0700 (PDT) Received: from [IPv6:2800:810:464:965:9d59:45f9:db60:7ba8] (unknown [IPv6:2800:810:464:965:9d59:45f9:db60:7ba8]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 6B148281519; Thu, 27 Aug 2020 02:56:46 +0000 (UTC) From: Fernando Gont To: last-call@ietf.org Cc: The IESG , Internet Architecture Board , architecture-discuss@iab.org Message-ID: Date: Wed, 26 Aug 2020 23:56:39 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [arch-d] Last Call: (Internet Architecture?) X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2020 02:56:52 -0000 Folks, I'd like to note that this document seems to be going three major aspects of the Internet and IPv6 architecture: * The basic Internet architecture with its removal of extension headers in the middle of the network. * The addressing architecture -- where addresses are employED for means other than those specified in RFC4291 * The processing of segment routing headers, with th PSP behaviour specified in this document (as already noted by Brian Carpenter). While it is always possible for documents to update or go against the current architecture, I believe the community should discuss these behaviors as such (changes to the architecture), and make an explicit decision in this respect. The implications and consequences of these changes should be carefully analyzed, since the implications are non-trivial. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Sun Aug 30 04:48:05 2020 Return-Path: X-Original-To: architecture-discuss@ietfa.amsl.com Delivered-To: architecture-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 963193A1614 for ; Sun, 30 Aug 2020 04:48:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.68 X-Spam-Level: X-Spam-Status: No, score=-1.68 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, T_SPF_HELO_TEMPERROR=0.01, T_SPF_TEMPERROR=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.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 4-WkRGlNfLpB for ; Sun, 30 Aug 2020 04:47:46 -0700 (PDT) Received: from mx.elandsys.com (mx.elandsys.com [162.213.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id 420813A08EB for ; Sun, 30 Aug 2020 04:47:21 -0700 (PDT) Received: from DESKTOP-K6V9C2L.elandsys.com ([102.115.143.240]) (authenticated bits=0) by mx.elandsys.com (8.15.2/8.14.5) with ESMTPSA id 07UBkvBR029347 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 30 Aug 2020 04:47:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1598788028; x=1598874428; i=@elandsys.com; bh=66NYjnII5CQo2RhwKNt/L8xrmGS1+5IGcCEiH1l0zO4=; h=Date:To:From:Subject:In-Reply-To:References; b=gWc4ZgMShRVqbLvaEhI3ZIKVRO4xz4CRHEwsfmBlRWJB4N8C8Y1wrBfyhQs0tE62V YuvMsTnJ65/GCT8cUoqkuXSAlBLoWLo3H0HDtNeYqXWccJ/apHESE9LQmw9nwCy81X +XsOcargKI/9YsOmv2tMhINoPEV4AUHCX4ab/5iM= Message-Id: <6.2.5.6.2.20200830031843.0f773f70@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 30 Aug 2020 04:45:35 -0700 To: Mirja Kuehlewind , architecture-discuss@ietf.org From: S Moonesamy In-Reply-To: <23A7182C-B168-47F2-BDC0-1161BA418E01@kuehlewind.net> References: <159798064208.3623.5922220323843951634@ietfa.amsl.com> <734c5859-e2f0-c3ed-c0b5-964c82c14365@gmail.com> <590E1794-EBDA-4BA7-A12B-4CC82710EE16@tzi.org> <2aa0c458-2f4f-a818-e25c-223e8187b212@nthpermutation.com> <31D31ACE-B235-46D6-A94F-805516697621@tzi.org> <569362d2-f04d-046f-d1d3-e08a909dd0f9@gmail.com> <32e47d54-daff-c42b-7a6c-d1ee30cebbad@gmail.com> <23A7182C-B168-47F2-BDC0-1161BA418E01@kuehlewind.net> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [arch-d] The six points (was: I-D Action: draft-carpenter-rfced-model-00.txt) X-BeenThere: architecture-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: open discussion forum for long/wide-range architectural issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Aug 2020 11:48:03 -0000 Hi Mirja, I am replying on a different mailing list as my=20 response is not directly related to what is being discussed on RFC Future. At 04:54 AM 25-08-2020, Mirja Kuehlewind wrote: >So I'm not sure what exactly you mean by "this=20 >whole class of issue"=9D but given the IAB also=20 >appoints the ISE and the IRTF chair, as well as=20 >reviews RGs, I would actually say that the IAB does already deal with that. > >I agree that I would also like to see the IAB=20 >focusing more on architecture but I think this=20 >is not because the IAB itself is too busy. It=20 >depends a lot on the specific people on IAB=20 >which topics are discussed and I would=20 >charterize the work of the IAB rather as=20 >identifying and flagging problem/gaps than=20 >developing technology. After all I would say=20 >that often members of the IAB are people who are=20 >deeply involved in the work in the IETF and=20 >would probably do this architectural thinking=20 >and analysis anyway but the IAB and IAB program=20 >provide a forum to anchor this work and discuss=20 >in a group. Progress on these things however=20 >often strongly depends on how busy these people=20 >are in their day jobs otherwise. However, I=20 >believe that's rather a separate topic. > >But because the members of the IAB do usually=20 >cover a board set of expertise in different=20 >areas of the IETF, usually including ex-ADs,=20 >working group chairs, and of course document=20 >authors, and have experience with interactions=20 >for all RFC streams that we have currently, I=20 >actually believe that this group of people is=20 >well set up for the task. However, I don't=20 >necessarily want to argue for the IAB being the=20 >right choice but I definitely think it's the=20 >better choice than ISOC. What's missing in the=20 >current setup is a clear description of responsibilities. One of the roles of the Internet Architecture=20 Board (IAB) is "to perform in-depth reviews of=20 particular architectural issues". The results of=20 that is to produce a report which may give advice=20 to the IETF community. Over the years, I don't=20 remember seeing (IAB) reports which are used by=20 the "IETF community" to resolve architectural=20 issues or architectural debates. I'll mention an=20 issue related to the IPv6 standard even though it=20 might end up being a distraction. I did not see=20 any "thinking of analysis" from the IAB to=20 identify or flag problems or gaps in what became an Internet Standard. I have seen messages on various topics in which=20 it was pointed out that people are busy or that=20 the people have day jobs. It conveys the idea=20 that the activities are usually carried out as a hobby. The responsibilities of the IAB are described in=20 six points, with architectural oversight being=20 one of them. One of the points, which is RFC=20 Series and IANA, turned into an appointment role=20 either because IAB members were busy or for some=20 other reason. I don't recall the IAB doing much=20 in policy matters except for the occasional=20 statement which would be relevant to one's special interests. Nowadays, we have the 4+1 internets. Things like=20 that when one takes a one-sided approach to what was once the Internet. Regards, S. Moonesamy