Re: [tsvwg] Follow-up to your DSCP and ECN codepoint comments at tsvwg interim

Sebastian Moeller <moeller0@gmx.de> Sun, 08 March 2020 16:31 UTC

Return-Path: <moeller0@gmx.de>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 904B73A0CD6 for <tsvwg@ietfa.amsl.com>; Sun, 8 Mar 2020 09:31:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.648
X-Spam-Level:
X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=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 (1024-bit key) header.d=gmx.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 FJb2X09_uQiJ for <tsvwg@ietfa.amsl.com>; Sun, 8 Mar 2020 09:31:23 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 C71C03A0CD7 for <tsvwg@ietf.org>; Sun, 8 Mar 2020 09:31:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1583684996; bh=6mPS8pyoxB88ap+QttGbvyRE2oFChiP7SQyHEK9pS5A=; h=X-UI-Sender-Class:Date:In-Reply-To:References:Subject:To:From; b=UTjep5IpGDNTso5nPQVSUJpE2YJdwCg3qoycK62e7AnxlkuWCzATXTdwTHqXLZd8l YnhEXOpjtT4rH3POkap4/j5Q1fd5rizkG5NjzzOGSiOJQ2qxgwNwUiu9TXmOZaL9OU WTi7mzTwPdDRsbQIaC5vgE6S6CNd8hb8NlKxcOyY=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.1.133] ([77.3.247.250]) by mail.gmx.com (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MTRMs-1illvz3hmu-00TifD; Sun, 08 Mar 2020 17:29:56 +0100
Date: Sun, 08 Mar 2020 16:34:18 +0100
User-Agent: K-9 Mail for Android
In-Reply-To: <dac8179d-1c39-b308-2c0a-4a6d0b43ddd6@bobbriscoe.net>
References: <7409b3a3-ba14-eb6d-154b-97c9d2da707b@bobbriscoe.net> <451679EC-B6F7-4176-B497-8189D238AF03@gmx.de> <dac8179d-1c39-b308-2c0a-4a6d0b43ddd6@bobbriscoe.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
To: Bob Briscoe <ietf@bobbriscoe.net>, tsvwg IETF list <tsvwg@ietf.org>, Steven Blake <slblake@petri-meat.com>
From: Sebastian Moeller <moeller0@gmx.de>
Message-ID: <B3163D46-F211-4AF8-8A14-AF9AB26ADA33@gmx.de>
X-Provags-ID: V03:K1:jS36MQJOboZwgEidyy8TSWzfSM2RgM+UrmWNvgapGwWAv/Tod5E w8ppt7Kpfob8MqpIKm8t3TDjWAVZ8+cqgPhVL4T//Sk/YlhsrdF82O1ygfsW0Zh2iBJQMGn b+YqYENJ1uWWEh++9dOYXbMxRGSqx49HV42TabCM51ZY63Kz93j8ShB0Pu3X1m7h55UCEB7 DFilmE3BqNECCCXlnP0+Q==
X-UI-Out-Filterresults: notjunk:1;V03:K0:j/AA2cQU96Q=:OxpS9E6NAGxQK3FMcLdoW0 TCXTMZfHJn5aVH8aV2IEQBZdrSOWAvTkJpBq8oEHiq67UU02r4KL3F9xFQmGvYoWLuGBhkxti CsAzcTKyvMIHFO+AJ0ZxMFcgjL5UHYdZqC7KHhqisHIwxwfAI26Zvov6+EsxC/0xlmgprfn8z NJCuiPqV++L6TlEyGn5LhnY065CAR7gE5LxtBWm8VuawEmFcboftvufUYlAcFxq/iFrFL1PHp nQBtFZ6SjEuN9hjc/Mkvm/1NVZDG8yqASg4h792cwxJdMVTVuDJvp2NUPillTlvYUJeyQXeET XtFmu0UgO8YztmrsS+6erH+qiovwzCo4hggwiLI4mbpL1PYhOZC597GJyk3UVb+GlM0r50UEV uYwnfo8oRN7OuoNoFHcqMe9TaJt8MfI6f31jPlSzGjjDXewKzqbq5d66hXY/uf0AKbaEFM8qw 8RNdcsLPhq8MnpNStpouVsu4oLHn6PJ9+uipyXN44m6hx8ly8kadeOeJeqjmnmZjEAfJbKvH5 7IG1L1Ueojk/hhqL7Zp2mu659NXwaKgmRRpzByKNBpkvDirQRuyDiPqeibsVJ+wmL3Q/s1fpC hhTqNnK2a3VKLErtDjeihj8tDa3q+CE+l+HRwqBfHjLGS86txp3+U81uQguEer1fmkwafwuLE rSUuxU86gj6eAVBsGHUU6FuK5M/vqMTEj2+0Z/t4mUT2olmKlhYA65q4KgqSnELvgSjcR/enq NtEVGTxROmEg1+0By6PYdqKCDfas+EURRSEkJnVYk2r3bvGdKKCTisNjdrusfgXUo915l+lMf zCwctcJbubU9Vj2A5m6YYZGQvqL/2aoUsX3sZS+AeDckbpBgkRvgwNOtXLeZCqzQKcGEUiQqP cCU/LsjevIgo7f889Fbw6G/LnatGE0aQJS/Lg6iCz6EnBKdP4X6my2beYZItNOD09fQnTqNbA Xq7J4EZ9fXd2Bs1hF0yjA5kGphlBHAD4CIYY9VwpljhGzoNkoYT9mTPywMsQjEfRdLxUo4tMd nEZb7xTbi066Idt0VMOWSCVUalS0Zo2p6f0PWcZxs8jOdppKLHLTG5xn49tnDRFH/IEWFjECG pDIUvnIzwG/TuNDfQLEDlee0w4RcxfaeFmFL7VrBj3PjMuyLKgM/ObMn7JBamp5mW5YrudkFu z4CbwrJ3uFUmoRvzVq7WQGQ9Zw5doawGe0TbdDIty2cUHHBKbnjehbcqJt+xY/ZYU8xILJSAb XVxvGlMUmpndziYRN
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/zpcNYQC3bYHyphKTN44DunLBMOU>
Subject: Re: [tsvwg] Follow-up to your DSCP and ECN codepoint comments at tsvwg interim
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 08 Mar 2020 16:31:28 -0000

Hi Bob,

More below.

On March 8, 2020 3:23:39 PM GMT+01:00, Bob Briscoe <ietf@bobbriscoe.net> wrote:
>Sebastian,
>
>On 07/03/2020 19:16, Sebastian Moeller wrote:
>>> Anyway, if user B's downstream is the bottleneck for user A, even if
>>> ISP
>>> B doesn't bleach Diffserv, the DSCP is still no use if ISP A
>bleaches,
>>> or if an intermediary does.
>> 	[SM] That really just would show that there is a business case for
>ISP A and B to connect directly in a DSCP conserving fashion....
>>
>This is a misunderstanding of the sequencing of adoption incentives. If
>
>something new doesn't work in the scenarios of interest, it will never 
>take off, and never affect anyone's business cases for doing anything.

[SM] That might pass as a cogent argument, but for the fact that ISPs (and CDNs) already use SLAs to define their interactions, e g. for VoIP traffic. The incremental effort to also include a LL-type traffic class/dscp seems pretty minor to me.

I also strongly believe that the only incentive for an ISP to roll-out L4S would be if that additional work/expense can be monetized, and the most viable route for that I can see, is to discrimination-free sell L4S access to the deploying ISP's eyeballs to all interested content suppliers, be it directly or via CDNs. In that case an SLA is not only not going to be a stumbling block, but rather a mandatory component of making this work.

What kind of deployment are you realistically expecting where this is going to be an issue?

And especially for the scope of the experimental deployment? The experiment is required to make sure that L4S can deployed in a safe and backward compatible fashion and that it can deliver it's promises under real-world conditions.
The experiment is NOT about how to deploy something in a fashion that offers the least part of resistance/the highest adoption rate. As a rule of thumb, I would assume the IETF be interested in the technical aspects and not the marketing side....

Regards
        Sebastian


>
>
>
>Bob

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.