Re: [tsvwg] TCP Prague's RFC 5033 guidelines status?

Wesley Eddy <> Mon, 11 November 2019 22:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8CD151201EF for <>; Mon, 11 Nov 2019 14:12:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
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, 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 xLkp0lbfaxpm for <>; Mon, 11 Nov 2019 14:12:27 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::f2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 41CE512008D for <>; Mon, 11 Nov 2019 14:11:48 -0800 (PST)
Received: by with SMTP id n12so5550795qvt.1 for <>; Mon, 11 Nov 2019 14:11:48 -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=c6cY1uEjPx0tC3+dzg7fJmRBjE/2RYNdiiiJ5CFMYFk=; b=BZfj60/ciglFh4P58cxikZ1OJTG8GMmtcxw8/dVz8SH9iaGIft2vFvXfRXPT/XCq1n VN8OeKmWeCKQP7sYwPsuHcxvgaqAA4NqqGdO/BT4HOeBDjMvqphKErj5MfjGgQhINbda VF0Va6Th1dvOW9wpPnSf9ZxQZAb7FDGSbztLXIXGyh7HBpIWDgrbWWgyDkSkvHq2QiOQ 3KjKSiN5T8b4kA+9HH/WTXOKO6kev/sXk7Tw+3tQLYx4wqVTlRmxlCP9Can5qBqfn8Mw 6MSEIylemfQ73FgAhczteHWp7tPf4oq3Vn8w+R8rL5tcyXxt4WhU8fubDMw3QwWwJN/h dHnw==
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=c6cY1uEjPx0tC3+dzg7fJmRBjE/2RYNdiiiJ5CFMYFk=; b=L9Y9lD0gzpL027JsZBh4UWWKGf2eWUNfHYFJ6aoUbv0s1534eJVFdhFCh2w+5Q+/yJ kpF9E1oxpAk+PeuPIuJE/wpHeomRjFWmkiUrDTbc4xfwfPerYYaeb/46/0PUZDcAJfhA MThi+XJAd/kszh1Y5p9jbok5cAxyqjOK6d7Nu+rqGv4/Of0O5eus828b7gWg189DOJ1V ok46Q2qDV6fxzt/rrsGTEU0ReGNYc7zMOcP711uJ/Z3CbQBLHzQvOTlF6rQYuo1Rdhvv vCI1BhsIzjKNylxZ/euYhhJlyHIXr6SiMAVlyn+lSIDIFqQ4rFPJ4/htbbUnWV8kZtl3 nPPw==
X-Gm-Message-State: APjAAAW0ft9HZsZ50jDa6tvaD7hAUS5GbkKcdrW65jJF99GI5XbjfXde UeAGLC7LFP0PDeT99scVHuDvQGqGMAA=
X-Google-Smtp-Source: APXvYqwjfqve+neHyREj9WWW6FzvTLFS3Bk2CnUc0lCgv7GDZYcVkaylfi5oq8TnlM5PahfSs5rM+A==
X-Received: by 2002:a05:6214:1427:: with SMTP id o7mr18446390qvx.83.1573510307112; Mon, 11 Nov 2019 14:11:47 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id c21sm9566917qtg.61.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 Nov 2019 14:11:46 -0800 (PST)
To: "Black, David" <>, "" <>
References: <> <> <>
From: Wesley Eddy <>
Message-ID: <>
Date: Mon, 11 Nov 2019 17:11:43 -0500
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; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <>
Subject: Re: [tsvwg] TCP Prague's RFC 5033 guidelines status?
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: Mon, 11 Nov 2019 22:12:29 -0000

On 11/11/2019 11:06 AM, Black, David wrote:
> Well, L4S imposes strict requirements on end-host algorithms for traffic that uses the low-latency service.  TCP Prague is the only known transport protocol that satisfies those requirements, i.e., no other existing TCP or DCTCP code satisfies those requirements, as far as I am aware (please correct this statement if it's wrong).
> For that reason, decisions about deploying L4S and TCP Prague appear to be linked, as it would be silly to deploy a network service (L4S) that cannot be used by end-systems, and end-system usage of L4S appears to require TCP Prague.

I believe you're referring to the congestion response requirements in 
the L4S ID draft.  I think those are a start to requiring an end-host 
algorithm to have good properties with regard to 5033 guidelines, rather 
than requiring some bad behavior (e.g. the first one is "MUST coexist 
safely with Reno" which speaks right to 5033 guideline 1 "Impact on 
Standard TCP, SCTP, and DCCP").  So, I'm not sure why those are a 
concern (i.e. which L4S ID congestion response requirements do we have 
5033 concerns with?).

If really needed, it seems like the 5033 guidelines could be mapped to 
sections of the L4S documents where the topics are discussed, but I'm 
not sure how meaningful it could be without regard to specific scalable 
end-host algorithms (e.g. Prague).