Re: [tcpPrague] [tcpm] Fwd: I-D Action: draft-bagnulo-tcpm-tcp-low-rtt-00.txt

Yuchung Cheng <> Fri, 19 August 2016 17:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 28AED12D623 for <>; Fri, 19 Aug 2016 10:11:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.948
X-Spam-Status: No, score=-3.948 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.247, 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 u9_JshFmdtbR for <>; Fri, 19 Aug 2016 10:11:08 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c0b::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2FE4712D5F0 for <>; Fri, 19 Aug 2016 10:11:08 -0700 (PDT)
Received: by with SMTP id f6so6183274ith.0 for <>; Fri, 19 Aug 2016 10:11:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HKK//jZo6Ukf7wuP/TqqjvIZfroiM5nrv+pBHcghv6M=; b=QyblFUFDfD+j48CJwp9jbWdfJr99DEYlq4EtJNsEMXI23QfZP6olOWZqcj/wv8RH7v bH9MRLtTQk5xvZNx09IB2eKJqWDamMLETtS3OLfTES+oZ4+fmVg+oK9SStbDzA13jX88 n3vt1lvQ7/UAL3WVXe2F65wCtY8rYQJkgPlugNgROTlqrKc+k83afolB3azR4Y3fIeOF 89Cs9XSE0yJv5bnRx+odLZLufzPM19KtAgj/R/DW/EpVZI14YKdzLHbXHj873gi3gR8S CXwiXdFWB8nJUNKqOf5jTg4bs7R7Cxhh0MtpSf3eQIWkSHROkhrtGEmLKXiSFVmfxFem D0ow==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=HKK//jZo6Ukf7wuP/TqqjvIZfroiM5nrv+pBHcghv6M=; b=J2yn2kxdy8kC/T3W2PNpSvLTpMW/XVSkhrdSLtzh481Mj/Z9+/wiKXd9zrBF/F6J6N ZOx+qi4Il/CloeQW6mju6wmXaOgPJ7H0AckYIZhVz3YfChXXeAfxAcS/11uqUIS9sT57 DMZj85XMQ3lgGZQG1Cm4ElyDbtqJcbypN0FUiYFvwZwCvK/WmsZGV/7gl1/T2S8XvxKU 16zjYnaQNx/j53gr0FfEqLupMQwKmosQJdGH04goeSFq3ylwYY7qE4+ampFfOvtLzOCz 7/j5BLD3wlIrIgrYiX0222RTSAsScQmodplagJCTYex5rjiQX1+uvrMdA6UB/gtkUP7d 9G4w==
X-Gm-Message-State: AEkoousvb6L9fq4v2qrI4+ZUUubH4JLIjhAzdeovDZLApXxQH4+Y68NibPLUuSPKPBQJ9E3+YCUebaDc4V+Q/KxW
X-Received: by with SMTP id d78mr7394747itb.65.1471626667205; Fri, 19 Aug 2016 10:11:07 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 19 Aug 2016 10:10:26 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <>
From: Yuchung Cheng <>
Date: Fri, 19 Aug 2016 10:10:26 -0700
Message-ID: <>
To: Karen Elisabeth Egede Nielsen <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Cc: marcelo bagnulo braun <>, tcpm IETF list <>, TCP Prague List <>
Subject: Re: [tcpPrague] [tcpm] Fwd: I-D Action: draft-bagnulo-tcpm-tcp-low-rtt-00.txt
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "To coordinate implementation and standardisation of TCP Prague across platforms. TCP Prague will be an evolution of DCTCP designed to live alongside other TCP variants and derivatives." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 19 Aug 2016 17:11:10 -0000

On Thu, Aug 18, 2016 at 1:05 AM, Karen Elisabeth Egede Nielsen
<> wrote:
> [Karen Elisabeth Egede Nielsen] I agree completely with your view and
> approach.
> In respect to the draft draft-bagnulo-tcpm-tcp-low-rtt-00.txt and the given
> recommendations for low RTO
> is that they do not (likely) take 2. Into account - meaning that they are
> looking for the low RTO to solve 2 for tail recovery.
> The bad thing is that they then also get the CWND reductions (as you also
> say).
> I would like for that this aspect is taken into consideration/given thoughts
> in the draft draft-bagnulo-tcpm-tcp-low-rtt-00.txt and the general 4LS
> effort.
> If we end with very low recommendations for RTO in order to handle 2. we
> risk undermining the RTO-retransmission function as well as the TLP function
> for now and forever.
> It might be that one for TCPs, that do not support TLP(/RACK), need to
> operate with very low RTOs to handle tail loss's "fast enough", but the
> recommendation for
> "future standard ?" TCP with TLP always enabled might be different. In this
> context lowering the RTO to handle 2. should be considered as a "temporary
> hack" ?

One feature worth discussion in the draft is the penalty of cwnd=1 on
spurious timeouts.

For DC, the RTT is so fairly low that we may consider a false reset of
cwnd to 1 is not a big deal. But consider in world of 100Gbps BDP will
still be hundreds of packets so it is going to be a non-trivial

Therefore it is important to discuss the timeouts with the remedy
operations: how well can the connection detect spurious timeouts:
F-RTO or Eifel are the two algorithms by IETF, Linux also supports
DSACK-based undo.

However, both F-RTO and Eifel have their limitations: F-RTO requires
the sender to have new data to transmit after the first DUPACK of
timeout. In the DC world, the requests or responses are often short
enough to prevent that. Eifel relies on timestamps which is ticked at
an interval higher than the DC RTT (e.g., Linux == jiffies == 1ms
often), therefore the timestamps fail to distinguish original and
retransmit if RTO was fired before the next tick.

I plan to cover these aspects in next RACK rev.

> BR, Karen