Re: [tsvwg] L4S drafts: Next Steps

Wesley Eddy <> Fri, 11 December 2020 19:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CCFB63A0E6E for <>; Fri, 11 Dec 2020 11:24:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id S5cap3j5SIZW for <>; Fri, 11 Dec 2020 11:24:00 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::82f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3D75A3A0E71 for <>; Fri, 11 Dec 2020 11:24:00 -0800 (PST)
Received: by with SMTP id n12so1605774qti.7 for <>; Fri, 11 Dec 2020 11:24:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=NAXk6B9cweFZLZSafW/U5spE2pnlOO52eVHcJbA1RY4=; b=i9iT7iBNoGrPM/AG7sC0owY0pSM2R+dr5cBl58j4NVRb/bApQYIMol/9/ipgbb6iQp 8WrJVbM1CJBR2FjfLRESmXsFjlcRkxI6VGRN43V8JCwvyhyhvAHYLuDoLoP4EG2ww/7h Ivy5fJjIFQLN8K/GETQbv+wtAyVrk5lT0RjlCTJS3Ur/erNL46E9ZYmfTgi5if17iAXJ 4uyQDRRcs3gxWvbTf7G2sTW0tKSXdedjQk7et7sm2DeKWd5wNy1UYpFP2E4OatnMVN3n 1XFwtfcOn1eartCgtqyxkTN+U0/VCoO6gAqVJHMJKllSnwjCJ+kMqHFqtzzlf8+VKdEA qE2g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=NAXk6B9cweFZLZSafW/U5spE2pnlOO52eVHcJbA1RY4=; b=riu3gBWgInkX8HIce7XTax6CP64cYtfNgxwAgMvweh+HaacEHTvl05AiCyENsV9wZE PTdbHIqQpOB6EgDzy+mWldljYXHVuCvmwBwtJVgjp/nGBf9CY/jz2qwWXYYJ1KTFDFMz lQl9rYkrUQiXt6uTQ8pyTwmhywNdmr55On2QSdlnUrf+hJgJ68+e5LGqU5cb4Ug40kWw 8MrIHVtWkJY5L01a1Bqpc7OOg2e8p5h4EVWTxgqOOal9YB1nuv0EDDe0g3d+e7llyxZ1 Uj7Hi2nM0N3/D4Bz/xwZVWb+Nqw/LSL7mls25vZlzKYs2zE+3TCm6Iwwir5642tQemA/ zU+g==
X-Gm-Message-State: AOAM530m853L5NGXua9SkJIuGzny7pj0CRgCySnR5Lmet8x+eVMo+1YH aAbKssYoaVtcmqACYg3cYcTaeIP3lFgb5VmO
X-Google-Smtp-Source: ABdhPJwZ0pCtfEgbqZXiVJ7JtPg7odRprazxWlvhmOog1ZYbY/7Pf3eZ7tjxcZq9yxvhr2r2yL2m5g==
X-Received: by 2002:ac8:4c8c:: with SMTP id j12mr17390307qtv.133.1607714638664; Fri, 11 Dec 2020 11:23:58 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id u7sm7966528qke.116.2020. for <> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 11 Dec 2020 11:23:57 -0800 (PST)
References: <> <>
From: Wesley Eddy <>
Message-ID: <>
Date: Fri, 11 Dec 2020 14:23:56 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <>
Subject: Re: [tsvwg] L4S drafts: Next Steps
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 11 Dec 2020 19:24:02 -0000

Just replying to clarify the goal on splitting of the requirements:

On 12/8/2020 6:00 PM, Bob Briscoe wrote:
> Now I've explained, I hope the chairs will all agree that "rework the 
> Prague Requirements into two entities" (normative requirements and 
> design and implementation guidelines) is already done and dusted.
As I'm seeing it at the moment, the problem is that there seems to be 
disagreement about whether it's possible to create transport algorithms 
or ensembles that meet the requirements.  Some people are fine with 
this, while others are uncomfortable that there isn't a clear "existence 
proof" yet that this can be done.

I believe everyone would agree that there are viable research projects 
(and some results have been shared in the WG) to address the 
requirements in various ways, and that those are of strong interest to 
the IETF and ICCRG now and in the future.

I think it's fine if we can have agreement that additional transport 
work to further this research is part of the experimental scope for L4S, 
but we should be hearing people saying they're comfortable to be 
contributing to that and make transports that will coherently meet all 
of the MUSTs.  Or, this is an opportunity for them to say if some of the 
requirements should be altered/relaxed in the split.