Re: [tsvwg] Another tunnel/VPN scenario (was RE: Reasons for WGLC/RFC asap)

Bob Briscoe <in@bobbriscoe.net> Tue, 08 December 2020 21:30 UTC

Return-Path: <in@bobbriscoe.net>
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 3BC283A0C04 for <tsvwg@ietfa.amsl.com>; Tue, 8 Dec 2020 13:30:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level:
X-Spam-Status: No, score=-2.101 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, NICE_REPLY_A=-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=bobbriscoe.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 fPo3q626rEqz for <tsvwg@ietfa.amsl.com>; Tue, 8 Dec 2020 13:29:55 -0800 (PST)
Received: from cl3.bcs-hosting.net (cl3.bcs-hosting.net [3.11.37.202]) (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 78E123A0B36 for <tsvwg@ietf.org>; Tue, 8 Dec 2020 13:29:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject: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=g+ofgOXnUVf4CriOgeo9JBvDJ2Y0/nMWdngpeQepvIw=; b=A9LYVjQUTWo7taNjtRiiCin5Le LcVdITEJSIAfBf24tHGzXRRd2/rGWX0GuqsUDZNnw3iwWXE506SDJhPks2ZSUFS7r04acWZxWqdAj 27W8Jx5tSocwSL4X8Bs50qS6vLYALp1uWVhfCx9RkSMGRWnp+lkOJhmGBiEqDYmLSTlG2oWD6+6Ue tPN1M6W+AoBp4BIdl6NR/pg88S65ysGIqTvbqqoYtcG48QCgS57EwL3gwXmcjAHEs/d+6PShsDzY3 zPtWCEDhTl+r4Ig+shCb/3lHa2XhkNVKt10k9Ujfy4zup9fEINh6f6dhr7aQCXJsregFTc6U3ro1P pKhBl7VA==;
Received: from 67.153.238.178.in-addr.arpa ([178.238.153.67]:54078 helo=[192.168.1.11]) by cl3.bcs-hosting.net with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from <in@bobbriscoe.net>) id 1kmkYS-00H7vj-R2; Tue, 08 Dec 2020 21:29:53 +0000
To: Steven Blake <slblake@petri-meat.com>
Cc: Gorry Fairhurst <gorry@erg.abdn.ac.uk>, tsvwg IETF list <tsvwg@ietf.org>
References: <MN2PR19MB4045A76BC832A078250E436483E00@MN2PR19MB4045.namprd19.prod.outlook.com> <HE1PR0701MB2876A45ED62F1174A2462FF3C2FF0@HE1PR0701MB2876.eurprd07.prod.outlook.com> <56178FE4-E6EA-4736-B77F-8E71915A171B@gmx.de> <0763351c-3ba0-2205-59eb-89a1aa74d303@bobbriscoe.net> <25D05011-8193-482F-8186-A433AE3FE5C3@gmail.com> <494cd867-58ad-2cb5-4682-0b4c4f003326@erg.abdn.ac.uk> <44e2d6be0ecb93cc0163a8f73d368f65048b7dc4.camel@petri-meat.com>
From: Bob Briscoe <in@bobbriscoe.net>
Message-ID: <a114c8cf-e586-d3b7-209a-74af2013446c@bobbriscoe.net>
Date: Tue, 08 Dec 2020 21:29:52 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <44e2d6be0ecb93cc0163a8f73d368f65048b7dc4.camel@petri-meat.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
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 - cl3.bcs-hosting.net
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - bobbriscoe.net
X-Get-Message-Sender-Via: cl3.bcs-hosting.net: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: cl3.bcs-hosting.net: in@bobbriscoe.net
X-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/9jKdcFHUEHWS6Ib9Clr5NjPoWW0>
Subject: Re: [tsvwg] Another tunnel/VPN scenario (was RE: Reasons for WGLC/RFC asap)
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: Tue, 08 Dec 2020 21:30:00 -0000

Steven,

On 04/12/2020 01:54, Steven Blake wrote:
> On Thu, 2020-12-03 at 16:40 +0000, Gorry Fairhurst wrote:
>> Just on that last point, perhaps we should be clearer by what
>> "experiment" means.
>>
>> On 03/12/2020 15:52, Jonathan Morton wrote:
>>> Frankly, the sooner the WG understands and accepts that basic fact,
>>> the sooner we can move to a viable solution - one which does not
>>> redefine CE from the semantics established by RFC-3168 and RFC-
>>> 8511, and hence does not place burdens on networks which have no
>>> interest in the L4S experiment.
>> I think we need to be clear that I understand the proposal is to an
>> Internet-wide experimental deployment.
> Have single network experiments been attempted? Have cooperating
> peering network experiments been attempted? Why is an *Internet-wide*
> experiment the appropriate next step, especially when potential
> detrimental impacts to traffic flows of non-participating networks &
> hosts have been identified?

[BB] As I understand it, until the IETF assigns ECT(1) to the L4S 
experiment, no-one should be deploying L4S on the public Internet, 
whether in single networks, or pairs of peered networks. This confines 
us to experiments where one can only try to generate realistic traffic.

Or do you mean a single *isolated* network (or peered *isolated* 
networks)? If so, isn't that what DCTCP has been doing for some years now?

Put another way, if implementers/operators started deploying L4S on 
ECT(1), even in single networks but within the public Internet, wouldn't 
that mean that ECT(1) had become de facto assigned to L4S?


Bob

>
>> If succesful, I'd expect we'll discover things in the deployment
>> that
>> will make us consider new things, before this is approved as a PS.
>> The
>> WG might later decide to obsolete RFC-3168, or L4S, or neither, or
>> both.
>> That will be to decide in future. In persepective, about 15 years
>> passed
>> before the previous EXP use of ECT(1) was made made historic,
>> enabling this.
>>
>> Gorry
> Is there a planned deadline to evaluate the results of the experiment,
> and either advance to PS or revert the allocation of ECT(1)?
>
>
> Regards,
>
> // Steve
>
>
>
>

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
                PRIVILEGED AND CONFIDENTIAL