Re: [tcpm] Questions about TLP

Yuchung Cheng <ycheng@google.com> Tue, 07 May 2019 16:52 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 AEE901201C3 for <tcpm@ietfa.amsl.com>; Tue, 7 May 2019 09:52:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.509
X-Spam-Level:
X-Spam-Status: No, score=-17.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, 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 VkfXgbmFoHHp for <tcpm@ietfa.amsl.com>; Tue, 7 May 2019 09:52:22 -0700 (PDT)
Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) (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 D6DE812018A for <tcpm@ietf.org>; Tue, 7 May 2019 09:52:21 -0700 (PDT)
Received: by mail-wm1-x335.google.com with SMTP id y5so21037009wma.2 for <tcpm@ietf.org>; Tue, 07 May 2019 09:52:21 -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; bh=qMXYOnvuxZB2+iLCEh3jQ5HV35rhPMIhZoYw7erauOc=; b=fmiVfaYvh8VH34oZ7bJWVVywEScYzkISZgH90hxr9vjd7E1p4j1CvuTL3yjfzd6pNF pBW57zoWDi639D/VEB4/heDlHxgTJb74U1NehlMZ1TtfNIaRStv4tpYJWPrVHTx2x9KH NUVKwpUvYrjOYr7ojsPuaAke6nUmBHHAqxiQJLMFrfORZTH5NlJ/fpJrlUUGN173HEW+ fLyn9ufr8MNlOjJfIHtkYNYGX/kQR7QN4wWUyP1WCqxEyL//qg3/21CEJYYmWE4PB34L CKm7szzqUcTqxLvCun5VzyGeZq/CIrzf2UUG+mZpYfVekIOSZAodK2Ugrb1uS8tjLsQ3 srmg==
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; bh=qMXYOnvuxZB2+iLCEh3jQ5HV35rhPMIhZoYw7erauOc=; b=HX4LZgACPOAtqknEf05sdFCaTfvQBmwmxWUB9QRoMinwofc+Rn5RNz9xrU0qs6wY7H P3BlFvuN++6CxKjjntRCcGIyhVAwAnrdocwuFgFnGXNO7fPQmD9Ktan2bZM6/VxGWHf5 oy06Mqfxl5YhFKXUfyPY/CxaIU0/iD1WwQ7vIAxgphipDFK6vtOarovP4VD6NNx6fqgo ptPtYllFqFl5mLKGEDYir4HoVo6iSZnvtLdmh09vfOxDeDRGna5C125xZrMAgIYENi5n MCHjfpKO+yUlTqneWEVW9BH9oU1N1ziEoDqUoT2OTxe3Q9JPlTVOBDRsyYyE7oeDwyWk M5zA==
X-Gm-Message-State: APjAAAWFPlhbjl6FWm+QG+XtQw6L45LCy8wxMx4woIujYNe2oO8qVklE z8rUoj900dggQ8L+xSk5KxaNSzFBq+WiAFPNhrN74Q==
X-Google-Smtp-Source: APXvYqzfbDSS/w8SImsC8RNUzTValf9ZHfUByEb3VBGADSzpXK0Av0c8SijP74Zqmw2mdxxbQtDkOusgnVIfrb+z/Q8=
X-Received: by 2002:a05:600c:2101:: with SMTP id u1mr11790706wml.36.1557247939749; Tue, 07 May 2019 09:52:19 -0700 (PDT)
MIME-Version: 1.0
References: <BL0PR2101MB1043C5ABE55E48572EB20C62C3340@BL0PR2101MB1043.namprd21.prod.outlook.com> <CAK6E8=fFR_VT8wMCzUW288HrN91NrbryerVLjOH5=6=bCEJLjw@mail.gmail.com> <BYAPR21MB125645C6DFCD605AE73E97FEBC340@BYAPR21MB1256.namprd21.prod.outlook.com> <CAK6E8=d06pqD=VY1t4rKeLTpcrAGaNCYJgjkLWTH0fhxbsML9w@mail.gmail.com> <BL0PR2101MB1043868EC0F299BFDED33A49C3340@BL0PR2101MB1043.namprd21.prod.outlook.com>
In-Reply-To: <BL0PR2101MB1043868EC0F299BFDED33A49C3340@BL0PR2101MB1043.namprd21.prod.outlook.com>
From: Yuchung Cheng <ycheng@google.com>
Date: Tue, 7 May 2019 09:52:07 -0700
Message-ID: <CAK6E8=cUCx9E21d5ig9cuFKgNY_taEWEdu9EK-OV_gaAWqUxaQ@mail.gmail.com>
To: Yi Huang <huanyi=40microsoft.com@dmarc.ietf.org>
Cc: Yuchung Cheng <ycheng=40google.com@dmarc.ietf.org>, Matt Olson <maolson@microsoft.com>, "tcpm@ietf.org" <tcpm@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000004728ee05884f0a6f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/1SXFSCSMsnC0vQ94m40ObObnFBo>
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: Tue, 07 May 2019 16:52:27 -0000

Thanks for the review as well!

*From: *Yi Huang <huanyi=40microsoft.com@dmarc.ietf.org>;
*Date: *Thu, May 2, 2019, 11:47 AM
*To: *Yuchung Cheng, Matt Olson
*Cc: *tcpm@ietf.org

If TLPRxtOut is checked in TLP_send_probe(), a new PTO can cancel an
> already running RTO timer armed by sending TLP previously. If
> TLP_send_probe() decides not to send the probe for the new PTO, what should
> the sender do next? Rearm RTO or treat it as RTO timeout? The draft states
> we must arm an RTO after transmitting TLP but in this case, no probe will
> be sent.
>
> Also, in page 17, the draft says "This is important to avoid TLP loops if
> an application writes periodically at an interval less than PTO." but if
> the app writes periodically at an interval less than PTO, PTO will just be
> pushed out and not fire until the sender cannot send anything due to window
> limit. Then in this case, TLP loops do not seem to exist if TLP loops means
> back-to-back TLP probes. Am I missing anything here?
>
> Thanks,
>
> Yi
>
> -----Original Message-----
> From: Yuchung Cheng <ycheng=40google.com@dmarc.ietf.org>;
> Sent: Thursday, May 2, 2019 10:25 AM
> To: Matt Olson <maolson@microsoft.com>;
> Cc: Yi Huang <huanyi@microsoft.com>;; tcpm@ietf.org
> Subject: Re: [tcpm] Questions about TLP
>
> On Thu, May 2, 2019 at 10:09 AM Matt Olson <maolson@microsoft.com>; wrote:
> >
> > Also, section 6.5.1 Step 1 is presented as a complete set of conditions
> for scheduling a PTO, but it is missing a bullet point for TLPRxtOut.
> Thanks for checking: but checking TLPRxtOut is not necessary and is not
> preferred when scheduling a probe -- the goal is to prevent more than one
> probe inflight, so checking right before TLPRxtOut sending the next one
> allows the best coverage of application-limited writes
> (burst-idle-burst-....).
>
>
>
>
> >
> > -----Original Message-----
> > From: Yuchung Cheng <ycheng@google.com>;
> > Sent: Wednesday, May 1, 2019 11:33 PM
> > To: Yi Huang <huanyi=40microsoft.com@dmarc.ietf.org>;
> > Cc: tcpm@ietf.org; Matt Olson <maolson@microsoft.com>;
> > Subject: Re: [tcpm] Questions about TLP
> >
> > 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
> ..
> > > ietf.org%2Fmailman%2Flistinfo%2Ftcpm&amp;data=01%7C01%7Cmaolson%40mi
> > > cr
> > > osoft.com%7C66db44672e3d4101d72908d6cec82001%7C72f988bf86f141af91ab2
> > > d7
> > > cd011db47%7C1&amp;sdata=n8rp5Emowm459iSKolhIP1hFXBs8pZjsGG2iy3OBAno%
> > > 3D
> > > &amp;reserved=0
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>