Re: [tcpm] Questions about TLP

Yuchung Cheng <ycheng@google.com> Thu, 02 May 2019 06:33 UTC

Return-Path: <ycheng@google.com>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6331E12004C for <tcpm@ietfa.amsl.com>; Wed, 1 May 2019 23:33:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.501
X-Spam-Level:
X-Spam-Status: No, score=-17.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
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 Mua7wwieWFr8 for <tcpm@ietfa.amsl.com>; Wed, 1 May 2019 23:33:45 -0700 (PDT)
Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA925120006 for <tcpm@ietf.org>; Wed, 1 May 2019 23:33:44 -0700 (PDT)
Received: by mail-wr1-x42c.google.com with SMTP id a12so1579191wrq.10 for <tcpm@ietf.org>; Wed, 01 May 2019 23:33:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=xeOrSmjczwx4TICWotjjMmnoUPS6+vpMl1oBIBaxl7k=; b=ZXjA0UKZrw8kDMwboqbBSc3gWNvMSuJsjLILXkYBBrbCu/dV3pnCM0fKvHKSTBXkdj I4OLLUfWgSbMPukE+BbItarlD4/WQLSK98w9U9CcoIJDBVZ+CL+9VSwXANJ0khZUl38X qf0EnP1YdTItVTJanElPFUTecGYNIBnFfIMWRwMNNhNu4Od7+ANFiLofyQJ3L+ak8f7I sRmNsRxR2lvJExXZUqEuupfnIrvSkZAGMy66W64xERVPyNUvBGdAoPOylxOz4Czhq/mw Ex+ohJ6CWMGl8kcxjKyGp9Kmrz23B9GfPu8UXWbqXXpPaXLMMrv7mk6TrD03GYNQqLIY cAgw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=xeOrSmjczwx4TICWotjjMmnoUPS6+vpMl1oBIBaxl7k=; b=QjLapQ+rpbbGtShLDMa7AdYJDXZ23mxKX/dg33y1Ii74lLUVsluyhYmzitQi5kWgAO b45GkCCYP/OM+bUWA0WlTnSTe8413q8whD+oBXHxjsHKYQTDzr0urwkYArj8hgCBUGIg XYT9dWdA3jpLzehJvrKNG0G1UO3bj2j1ObujLcXJ07+DjNIzwx39wzAEHzF7d24r/WYE Z5rTOzbSST0sAeJazQAwNXfgOjDUJvqQSDassJsZHoz4xDLPNeJ5SJ/ThL55V4rHYvWC DHU094htLF91fmEygZn/WnZ2QlMcJs5xJM3JZX3ai1uv7e0pgClxzFoLdPM3m7Ojhx2x bsjg==
X-Gm-Message-State: APjAAAWhcm6tp29skicDY2ZA6FWR9uFqntU6dawgOkBagtbJZmw+NCTH qb4IHcWjkWX0A4jvgVsv1y3AXtNR4MKF15j6Zr2u4w==
X-Google-Smtp-Source: APXvYqwXR+2CFfxBOWbIYD6S4pEIdTpdjsgrEBZT3T7kGAsLi98aDCQvUneLof1omUnKKCZP8vajbmmoRNUARSTwobQ=
X-Received: by 2002:a05:6000:104c:: with SMTP id c12mr1331667wrx.35.1556778822610; Wed, 01 May 2019 23:33:42 -0700 (PDT)
MIME-Version: 1.0
References: <BL0PR2101MB1043C5ABE55E48572EB20C62C3340@BL0PR2101MB1043.namprd21.prod.outlook.com>
In-Reply-To: <BL0PR2101MB1043C5ABE55E48572EB20C62C3340@BL0PR2101MB1043.namprd21.prod.outlook.com>
From: Yuchung Cheng <ycheng@google.com>
Date: Wed, 1 May 2019 23:33:04 -0700
Message-ID: <CAK6E8=fFR_VT8wMCzUW288HrN91NrbryerVLjOH5=6=bCEJLjw@mail.gmail.com>
To: Yi Huang <huanyi=40microsoft.com@dmarc.ietf.org>
Cc: "tcpm@ietf.org" <tcpm@ietf.org>, Matt Olson <maolson@microsoft.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/m9_6pu6fhMnj4PY32LlaDYuymDE>
Subject: Re: [tcpm] Questions about TLP
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 May 2019 06:33:47 -0000

On Wed, May 1, 2019 at 10:48 PM Yi Huang
<huanyi=40microsoft.com@dmarc.ietf.org>; wrote:
>
> Hi RACK/TLP authors,
>
>
>
> I have the following questions (page numbers refer to draft-ietf-tcpm-rack-05):
>
>
>
> 1.In page 16, it says “Finally, if the time at which an RTO would fire (here denoted "TCP_RTO_expire") is sooner than the computed time for the PTO, then a probe is scheduled to be sent at that earlier time.” What does this TCP_RTO_expire actually mean? Does it mean there is another RTO timer (possibly started some time in the past) running along with PTO or just RTT + 4*RTTVar + Now()? Also, why would another probe be sent at RTO expiration time instead of treating it like RTO and collapsing the cwnd?

TCP_RTO_expire() should return a timeout value for regular RTO, i.e.
SRTT + 4*RTTVAR + Now()
We use TCP_RTO_expire() because many implementations including Linux
do not use the exact RFC formula

The reason it's not treated as a regular RTO is to avoid resetting
congestion window to 1. The rationale is if the probe was sent within
min(PTO, RTO) and was delivered successfully, there's no need to reset
congestion window and re-start slow-start, similar to the rationale of
Reno's fast recovery reducing window to ssthresh instead of 1. We have
found this strategy benefits wireless connections, as the chance of
spurious RTO is high due to the delay variation.

>
>
>
> 2.In page 18 section 6.6, a new variable TLPRxtOut is defined and it is stated that TLPRxtOut is used to guarantee that there is only one outstanding TLP retransmission.. However, it is not clear to me when TLPRxtOut should be really used. Should it be used in 6.5.1 Step. 1 (checking whether we should and can schedule a TLP) or in TLP_send_probe()?

This is in

6.6.2.  Recording loss probe states

   Senders MUST only send a TLP loss probe retransmission if TLPRxtOut
   is false.  This ensures that at any given time a connection has at
   most one outstanding TLP retransmission.  This allows the sender to

but I agree it'd be more clear to include this in TLP_send_probe()
pseudo code. I'd incorporate in the next rev.
>
>
>
> Thanks,
>
>
>
> Yi
>
>
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm