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 From owner-freebsd-transport@freebsd.org Wed Oct 12 06:28:16 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 9229DC0E416 for ; Wed, 12 Oct 2016 06:28:16 +0000 (UTC) (envelope-from hiren@strugglingcoder.info) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 7F9411FC for ; Wed, 12 Oct 2016 06:28:16 +0000 (UTC) (envelope-from hiren@strugglingcoder.info) Received: by mailman.ysv.freebsd.org (Postfix) id 7C275C0E415; Wed, 12 Oct 2016 06:28:16 +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 7A0BEC0E414 for ; Wed, 12 Oct 2016 06:28:16 +0000 (UTC) (envelope-from hiren@strugglingcoder.info) Received: from mail.strugglingcoder.info (strugglingcoder.info [104.236.146.68]) by mx1.freebsd.org (Postfix) with ESMTP id 531341FB; Wed, 12 Oct 2016 06:28:16 +0000 (UTC) (envelope-from hiren@strugglingcoder.info) Received: from localhost (unknown [10.1.1.3]) (Authenticated sender: hiren@strugglingcoder.info) by mail.strugglingcoder.info (Postfix) with ESMTPA id 9232517092; Tue, 11 Oct 2016 23:28:10 -0700 (PDT) Date: Tue, 11 Oct 2016 23:28:10 -0700 From: hiren panchasara To: Randall Stewart Cc: FreeBSD Transports , lstewart@FreeBSD.org Subject: Re: Exiting from loss recovery Message-ID: <20161012062810.GO20670@strugglingcoder.info> References: <20161007002211.GO50669@strugglingcoder.info> <1BC53E8D-08B9-4C4C-8E7B-6346CA83F66E@netflix.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="s9pXJW6w71JX4l3T" Content-Disposition: inline In-Reply-To: <1BC53E8D-08B9-4C4C-8E7B-6346CA83F66E@netflix.com> User-Agent: Mutt/1.5.23 (2014-03-12) 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: Wed, 12 Oct 2016 06:28:16 -0000 --s9pXJW6w71JX4l3T Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Randall, I am a bit confused. :-) Can you please clarify what you mean here? Are you talking about=20 cc_ack_received(tp, th, nsegs, CC_ACK); ? Probably I am being a bit slow here but any explanation around how stretch acks can be a problem here would be great. :-) Thanks, Hiren On 10/10/16 at 09:56P, Randall Stewart wrote: > Hiren: >=20 > I have a bit of experience now with this code. >=20 > 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 ?stretch? ack.. making cwnd spike up incorrectly by standard > new-reno terms?=20 >=20 > If you do move exit recover to there, you probably need to have a limit > on how big the cwnd can move? i.e. some sort of segment limit. >=20 > R >=20 > > 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 >=20 > -------- > Randall Stewart > rrs@netflix.com > 803-317-4952 >=20 >=20 >=20 >=20 >=20 --s9pXJW6w71JX4l3T Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAABCgBmBQJX/df2XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4 QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/lzssH/j6iDwkhb5ROOglhGY3leuKG MlI2x12+aTvZ7I4fLHtrvpm1kPbxxXbtXEkueaYLW+J/Cq0GnmZg+cmUQg5gg73t u8P3DvU1/xGQsLZW/ij3diyfiNDiLUt4SkudTiHUQI72pkn0eY2QUo6C+HcMcgBY lg1MmgR4QKor68da1c+NFmZ7lfpX7NzpBV8pTEhxlWzU2zUKePYlvTbp75MPwtEI 2urB1tA2uEbPpflDLAU5hl3EpqaOkMbxRm3hscbkDnW1aKtUjPaapRFTkQFEjrjp 4asQeRmch0Rt/7QJhwPt3ffFUazc78QNZn+A2A6Obw9RM3CoJQDtLSkG7sFXRE4= =R6XX -----END PGP SIGNATURE----- --s9pXJW6w71JX4l3T-- From owner-freebsd-transport@freebsd.org Wed Oct 12 06:33:47 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 9A17DC0E658 for ; Wed, 12 Oct 2016 06:33:47 +0000 (UTC) (envelope-from hiren@strugglingcoder.info) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 8765A77D for ; Wed, 12 Oct 2016 06:33:47 +0000 (UTC) (envelope-from hiren@strugglingcoder.info) Received: by mailman.ysv.freebsd.org (Postfix) id 837E6C0E657; Wed, 12 Oct 2016 06:33:47 +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 81801C0E655 for ; Wed, 12 Oct 2016 06:33:47 +0000 (UTC) (envelope-from hiren@strugglingcoder.info) Received: from mail.strugglingcoder.info (strugglingcoder.info [104.236.146.68]) by mx1.freebsd.org (Postfix) with ESMTP id 6AF0377C for ; Wed, 12 Oct 2016 06:33:46 +0000 (UTC) (envelope-from hiren@strugglingcoder.info) Received: from localhost (unknown [10.1.1.3]) (Authenticated sender: hiren@strugglingcoder.info) by mail.strugglingcoder.info (Postfix) with ESMTPA id 65F2A1709C for ; Tue, 11 Oct 2016 23:33:46 -0700 (PDT) Date: Tue, 11 Oct 2016 23:33:46 -0700 From: hiren panchasara To: transport@FreeBSD.org Subject: Re: Setting congestion window on loss detection Message-ID: <20161012063346.GP20670@strugglingcoder.info> References: <20151007195445.GC42742@strugglingcoder.info> <20151012171927.GB92230@strugglingcoder.info> <20151031003324.GI5261@strugglingcoder.info> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="k8r0khnpBuGu0wUi" Content-Disposition: inline In-Reply-To: <20151031003324.GI5261@strugglingcoder.info> User-Agent: Mutt/1.5.23 (2014-03-12) 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: Wed, 12 Oct 2016 06:33:47 -0000 --k8r0khnpBuGu0wUi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline A slightly different and probably more correct approach at: https://reviews.freebsd.org/D8225 Cheers, Hiren --k8r0khnpBuGu0wUi Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAABCgBmBQJX/dlKXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4 QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/l2VwH+wc+sQlKp+znh2bbBfqq9jLV rEsOjBpotmP6WPR81acGXO2S8evLhcnxj8vQvYn2z41/WnCr/e4c++1VJ0xjXRDF 4Gr6bAC5uvspARP+Zhgd63BfdEjQiTfdI7lkWbYv2r0JKuBnX/x+iAzArSilXXZp Uu3Og3HzwEO8tCIqZZbcuilyG1HIG5qFnV5K2wHF4WSL8Rcm/xi9jBCRbdmpwsWQ ukMAbL2qBtKCSbxLj87DkyMDwOi0+t3UEBHiXPzLY8JSfiHCxpyObawRmMHYlXnY 0bAHs7mflt5FXcMKh7BFlaMH2XbKT0n3aLjuuRAJiCFrR0OQjrHm71P+/3hWdhw= =+7OF -----END PGP SIGNATURE----- --k8r0khnpBuGu0wUi-- From owner-freebsd-transport@freebsd.org Wed Oct 12 18:10: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 B101DC0F9FD for ; Wed, 12 Oct 2016 18:10:28 +0000 (UTC) (envelope-from rrs@netflix.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 2D7D7DA4 for ; Wed, 12 Oct 2016 18:10:27 +0000 (UTC) (envelope-from rrs@netflix.com) Received: by mailman.ysv.freebsd.org (Postfix) id 2CB97C0F9FC; Wed, 12 Oct 2016 18:10:27 +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 2C4EBC0F9FB for ; Wed, 12 Oct 2016 18:10:27 +0000 (UTC) (envelope-from rrs@netflix.com) Received: from mail-qt0-f182.google.com (mail-qt0-f182.google.com [209.85.216.182]) (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 CCCDAD9F for ; Wed, 12 Oct 2016 18:10:26 +0000 (UTC) (envelope-from rrs@netflix.com) Received: by mail-qt0-f182.google.com with SMTP id f6so25671761qtd.2 for ; Wed, 12 Oct 2016 11:10:26 -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=4kboYObefBvUZyxkfJYqcpT1GnSxfM0Acp+CubF9pXg=; b=nvIPKs6ilhsCF8mVGoZ22TjVRalPCuGiqRFKDi76pDc2Us3DgKIIpuICKIUHSKZnLk FhpEm0nOj+cJ09PYyd+ET8IYcSQ5HmcYfyiRQ9LF2HXhEFd0z7/QV+0qJYQgQ03FqQqP PFWN9lSqYruUOU60c24Clhq1gdZxFiEmOxfaA= 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=4kboYObefBvUZyxkfJYqcpT1GnSxfM0Acp+CubF9pXg=; b=KXAUrP4mNeNBzKFwdVHWQJfALl5dvYz1SMEvS5zlTovNO3sk4dQYCoKZrqvx7PG9Or e9UQWljsMX5NhTPZ+dXhYJn8gsLPmA8rXArbcex2OJMGrlSyhoLQmQPCcEAK7Yw3k7KD XsbId6EDyU6+KWvimr3wt1b1B8SDGlJCh+PHQfXoXOCbiWSMJrGbQQzDmxLENPjkbhLE YrKT5WFDgVsUr7fLqMCKgcoo7RmAvt6XiwG4qWlgychKl7ztYWNzlbdWBZKSdgzoegUG bDtU50b2tsQbFkpxxopvWeD8pr4aKH8ngyWQa+XBsc05uX8Ps4VXzNphV7usu8t+3ax0 p/Cw== X-Gm-Message-State: AA6/9RnYOnoaYkcrU0vacpVshesQLh20tRpdfTB23t60TBtoFxpzvL+1IoBpp+bz4uOHJ47V X-Received: by 10.200.44.75 with SMTP id e11mr2652001qta.9.1476295759614; Wed, 12 Oct 2016 11:09:19 -0700 (PDT) Received: from [100.127.87.177] ([69.53.246.16]) by smtp.gmail.com with ESMTPSA id a94sm3208407qkh.11.2016.10.12.11.09.18 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 12 Oct 2016 11:09:18 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: Exiting from loss recovery From: Randall Stewart In-Reply-To: <20161012062810.GO20670@strugglingcoder.info> Date: Wed, 12 Oct 2016 14:09:17 -0400 Cc: FreeBSD Transports , lstewart@FreeBSD.org Content-Transfer-Encoding: quoted-printable Message-Id: <42CDE950-9D49-46FE-8D56-B19BA07B9DD4@netflix.com> References: <20161007002211.GO50669@strugglingcoder.info> <1BC53E8D-08B9-4C4C-8E7B-6346CA83F66E@netflix.com> <20161012062810.GO20670@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: Wed, 12 Oct 2016 18:10:28 -0000 Yes what happens is you receive a stretch ack often at the end of recovery.. i.e all the holes have been filled and now you are asking a lot of data (lets say 10 segments).. Now if you are in recovery cc_ack_received() does not add it all to the cwnd. If you are not in recovery then it does add it in.. and so you get a huge bounce upwards in your cwnd. R > On Oct 12, 2016, at 2:28 AM, hiren panchasara = wrote: >=20 > Randall, >=20 > I am a bit confused. :-) > Can you please clarify what you mean here? Are you > talking about=20 > cc_ack_received(tp, th, nsegs, CC_ACK); ? >=20 > Probably I am being a bit slow here but any explanation around how > stretch acks can be a problem here would be great. :-) >=20 > Thanks, > Hiren >=20 > On 10/10/16 at 09:56P, Randall Stewart wrote: >> Hiren: >>=20 >> I have a bit of experience now with this code. >>=20 >> 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 ?stretch? ack.. making cwnd spike up incorrectly by standard >> new-reno terms?=20 >>=20 >> If you do move exit recover to there, you probably need to have a = limit >> on how big the cwnd can move? i.e. some sort of segment limit. >>=20 >> R >>=20 >>> 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 >>=20 >> -------- >> Randall Stewart >> rrs@netflix.com >> 803-317-4952 >>=20 >>=20 >>=20 >>=20 >>=20 -------- Randall Stewart rrs@netflix.com 803-317-4952