From owner-freebsd-transport@freebsd.org Mon Oct 10 13:56:28 2016 Return-Path: Delivered-To: freebsd-transport@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C588FC077E3 for ; Mon, 10 Oct 2016 13:56:28 +0000 (UTC) (envelope-from rrs@netflix.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id A5435DD9 for ; Mon, 10 Oct 2016 13:56:28 +0000 (UTC) (envelope-from rrs@netflix.com) Received: by mailman.ysv.freebsd.org (Postfix) id A49D2C077E2; Mon, 10 Oct 2016 13:56:28 +0000 (UTC) Delivered-To: transport@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A447AC077E1 for ; Mon, 10 Oct 2016 13:56:28 +0000 (UTC) (envelope-from rrs@netflix.com) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 771E3DD7 for ; Mon, 10 Oct 2016 13:56:28 +0000 (UTC) (envelope-from rrs@netflix.com) Received: by mail-pa0-x22f.google.com with SMTP id ry6so55040280pac.3 for ; Mon, 10 Oct 2016 06:56:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netflix.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=t+TRemm8ViUWeSzGG9E0s7RYIwPXbvaY8/BUzG1V9cE=; b=qsZdWsQDFpwOvbf+xRoLfy6mJPhn0IL6v8LyW36deoHHFt0p5Du8W0nEdioo4Y3LHm FNjL59r98WJSB3RKAQR3QZZFNtn8wdUx3vT5N2zBoE5oqcWR1Ejv9sT9Tj4/ly0dLKN1 whQQRuHYlaxeWyCGFEpw5Gg4yEYfx0cCqvPbE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=t+TRemm8ViUWeSzGG9E0s7RYIwPXbvaY8/BUzG1V9cE=; b=lxqxV1HeUvPA8Iuhv5EoSax1DSSM3k9BUuGADOVAXiDGwsgnwz3wVRP5Ne5bApkWfj IzXmCVCY9ZXmBRLFePGBzgEIZ/iWkpIUAZdUf/eTyYwPKkQcjO+6Jkk56laXiqcC2TWp +AQvW0k1lMy4ldBmtX2fV0df5keFUF9D4l9+ZmfeHm3py/Zqb5k7TnEejtykdvzzs6zj QCg9XudUvVHQu6TOHT+nkWbncvTWeLMRE6j/Z0ZL81zYcdqnXMwrXknsMEHu6stsrpdz OmU21BSTXkbKNW3ZWcY8kJjXDO2A+DxhLKoaeky1hIHL+lLZosFevexTNwFSW7VjsBNT cHFQ== X-Gm-Message-State: AA6/9RllkviQYrkqd9z90gGyQsuh/LR53G9NXMKeo2YZ1/T/1jYfFlfJipYdn+AJ7rFLw4Y8 X-Received: by 10.66.230.199 with SMTP id ta7mr46944625pac.86.1476107788031; Mon, 10 Oct 2016 06:56:28 -0700 (PDT) Received: from lgml-rrs-2.corp.netflix.com ([69.53.231.133]) by smtp.gmail.com with ESMTPSA id yi2sm1702663pab.17.2016.10.10.06.56.26 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 10 Oct 2016 06:56:26 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: Exiting from loss recovery From: Randall Stewart In-Reply-To: <20161007002211.GO50669@strugglingcoder.info> Date: Mon, 10 Oct 2016 09:56:24 -0400 Cc: FreeBSD Transports , lstewart@FreeBSD.org Content-Transfer-Encoding: quoted-printable Message-Id: <1BC53E8D-08B9-4C4C-8E7B-6346CA83F66E@netflix.com> References: <20161007002211.GO50669@strugglingcoder.info> To: hiren panchasara X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-transport@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions of transport level network protocols in FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2016 13:56:28 -0000 Hiren: I have a bit of experience now with this code. If you exit recovery where Lawerence has marked, then when you go down a few lines and credit the ack to the cwnd it can be a very large =E2=80=9Cstretch=E2=80=9D ack.. making cwnd spike up incorrectly = by standard new-reno terms=E2=80=A6=20 If you do move exit recover to there, you probably need to have a limit on how big the cwnd can move=E2=80=A6 i.e. some sort of segment limit. R > On Oct 6, 2016, at 8:22 PM, hiren panchasara = wrote: >=20 > In tcp_do_segment(): >=20 > /* > * If the congestion window was inflated to account > * for the other side's cached packets, retract it. > */ > if (IN_FASTRECOVERY(tp->t_flags)) { > if (SEQ_LT(th->th_ack, tp->snd_recover)) { > if (tp->t_flags & TF_SACK_PERMIT) > tcp_sack_partialack(tp, th);=20 > else > tcp_newreno_partial_ack(tp, = th);=20 > } else=20 > cc_post_recovery(tp, th);=20 > } >=20 > Here, if we get an ack that marks recovery from loss i.e. >=3D > snd_recovery, we call cc_post_recovery() which in-turn calls CC = specific > post_recovery routine. But we don't reset TF_FASTRECOVERY | > TF_CONGRECOVERY flags by calling EXIT_RECOVERY()=20 >=20 > Later in the code we do this check again in 'process_ACK:' >=20 > /* XXXLAS: Can this be moved up into cc_post_recovery? = */ > if (IN_RECOVERY(tp->t_flags) && > SEQ_GEQ(th->th_ack, tp->snd_recover)) { > EXIT_RECOVERY(tp->t_flags); > } >=20 > And as it can be seen, Lawrence marked it as something that could > possibly be done here and at the end of cc_post_recovery().=20 >=20 > So, should we do it? i.e call EXIT_RECOVERY() at the end of > cc_post_recovery() and remove the block from 'process_ACK' section? or > there is something subtle I am not seeing? >=20 > Cheers, > Hiren -------- Randall Stewart rrs@netflix.com 803-317-4952