Re: [tsvwg] Switch testing at 25G with ECN --SCE Draft

Wesley Eddy <> Sun, 11 August 2019 04:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8DA88120862 for <>; Sat, 10 Aug 2019 21:26:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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 2jWy0ooSB9vT for <>; Sat, 10 Aug 2019 21:25:27 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::833]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5F8B012007A for <>; Sat, 10 Aug 2019 18:31:55 -0700 (PDT)
Received: by with SMTP id u34so309730qte.2 for <>; Sat, 10 Aug 2019 18:31:55 -0700 (PDT)
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=eJT+TmMWRe1kZj9CGch2i3b4M9fTMulBz2vbGfhHKhE=; b=LlEWlsnDdVkrK/gAzMsVJDrDeV3nnTM5WinRRNhlBVrbmNxIBlL0LBB1Lz8wRB/su0 AmuEzfLx/O2Ag8EAy+5ctKRMbylCyZ1LRG9tbJXB3g5gLf1TTeAxiqQ2QbV/vgr4yFu+ 1t+a4395aQbuweIl1Hf1DXgX9z1PkpWj6cG8aTd8sSkDlrWZzBixUI9hzrJJ57aiu0ml hFUK3luB2xtk8EGSWRZArg4Nk/RxR/3tuiszdf2xMbTQ4FNp2SZpcF3cTrZbafpySDxJ Y5OS0z7/F8MdUT1lS4zGZeJknIsmckgEEiaX+HXNYuFe8aJnCRtGbWMY/7sPzBTtWW6R 8sPw==
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=eJT+TmMWRe1kZj9CGch2i3b4M9fTMulBz2vbGfhHKhE=; b=bGa2S0KVURWNeE/9ZFufGRvnzRvHelU+Gx79l8i5+XUX1JKCbvNF+/l7xtdVeRmUAJ QY95BTJOJWpCafapl8Ulm87UgT5J81RP4b97DZPd+XbQw+GLbZO8OK7m1ZEFbA3Vka+7 CXLRonH314FyVqtmfFrW4AV8KAGXRITYSAeG3ovXzsvJ/apt7cIGiORZkCGccjVpEHjI ezeI2l4/il8XcB1YfF2x55LtjLnUp8X8o9wWW5uAHTCAr3uHLndIptg1wkuk1BokNhTT uANSPJkXxLmrZsnQulIhrcsr6HkGf9wQkhFzceqBAxMFn0qrS7E1OxV7oiNEFG9euUVB whwA==
X-Gm-Message-State: APjAAAVrreWbv4XgTnEIbaUeS7XQZSM/bcNSA86iikuFoiOeDCC+Kfyh xfzaSzlNKlI1q1WoI99ABJLrDMrVpkg=
X-Google-Smtp-Source: APXvYqwvNCyxPHEPNfDi3KD61pV5b+7A9pkD1rBqXGsZo2K4FklmknXSw2/3b4uy51mzug7s84e9Ww==
X-Received: by 2002:ac8:22ac:: with SMTP id f41mr1647249qta.362.1565487114351; Sat, 10 Aug 2019 18:31:54 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id x69sm5235359qkb.4.2019. for <> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 10 Aug 2019 18:31:53 -0700 (PDT)
References: <>
From: Wesley Eddy <>
Message-ID: <>
Date: Sat, 10 Aug 2019 21:31:52 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
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] Switch testing at 25G with ECN --SCE Draft
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: Sun, 11 Aug 2019 04:26:20 -0000

On 8/9/2019 8:02 PM, Rodney W. Grimes wrote:
>> Right.  Per the SCE method, the switch would mark ECT(1) using a ramp, and then when the ramp would exceed 100% marking, it would change to using CE.
>> The implementation discussed here marks CE using a ramp, and when the ramp would exceed 100% marking, it changes to packet drop.  This, as you said, is simply RFC3168 ECN marking, not SCE ECN marking.
> Purely due to a choice to an expedient experiment.  This is not "simply RFC3168 ECN marking" which would occur at the point the switch was about to start dropping, it is "linear ramp response proportionaly to queue depth SCE marking" using the CE bit pattern.  I can not get into the details as to why this was done this way.

The advice in 3168 is to do marking based on average queue length, but 
*not* just before it needs to start dropping.  Is it more correct 
instead to understand what you're saying as the experiment being based 
on using the instantaneous queue length rather than average?

> RFC3168 ECN marking is already in the switch, the switch was modified to behave in a different manner, using the
> RFC3168 CE bits.  This different manner was turned OFF to do the dctcp tests and turned ON to do the dctcp-sce tests.

Since the marking probability function and marking decision isn't part 
of 3168/ECN, the description here sounds like the switch is always 
conforming to 3168 behavior, but just using some custom decision logic 
for marking.

Just trying to be clear on what we're really talking about ...