From owner-freebsd-net@freebsd.org Sun Aug 23 19:56:58 2020 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id EBC2E3C810E; Sun, 23 Aug 2020 19:56:58 +0000 (UTC) (envelope-from Richard.Scheffenegger@netapp.com) Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12on20618.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe59::618]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "GlobalSign Organization Validation CA - SHA256 - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BZQxy2RNwz4LYl; Sun, 23 Aug 2020 19:56:52 +0000 (UTC) (envelope-from Richard.Scheffenegger@netapp.com) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=YKv4GZEsKRpaJNkHMwrh67ej5BAWKYiqaQO/gTMG8UX+eiugQPhTr0rMtJEJc9qvmDU5yov3tX0KXPhl3uBI3aOFIw5SyCxgi234Oc/UI8L63JWBQcm67ZIw57hDhbBM3H1KGnTTmCus1+smRQ60ux1dFmTLZ1zKY0CXOkSw2ZrAQjG1fEYYucBJiej8ekDVNXPqZhM/vmaphynfkksKvceHDsW1xSDfjR1dPsF6x7GNUC0ruh5Y1sqbmlsDbujEfgc6w+CaQ1Pa0e7M/g0Ya8SigcKb4CQTALswYowYriOJRnOMiATMxqUMXS5fD8hXq4Q3ZsTGPKCS7M4n24Lw0g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=c8Kc5bD2uBZGpbt8RuhHHzkHROe2x5FZWb04P7q0o+I=; b=QhuUWoAxkiLQ63oIXGmk+dsowzv3l48dy5d2fXkPohQr9RNv+izf5bk+oi9k0qZSnBTCPB1w+U1zAnLMe0JDKq/Lv1Stk7CVY396DN51GTiLkJUt/yDMuoCqrqRndPCRd1e5nb0gHshzYjOjlfdpY3G55IG2dwFHO6iCaBorecgpOw2+4qPGjC85c+IDwgGvqtM/nVHz2m2JqVUJKIYBf1CQqsnneiySPZmmGwOj8h8Ui5lc8pBecdDrpudGrEtKakzFsQvifdo7rXvgLXWjIL7ee0Ekyv4g//iAsYG6cv/isX4xWUtHCIdlWPSvl1XMBGZQ/luC5ljeE5iog/vaSQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=netapp.com; dmarc=pass action=none header.from=netapp.com; dkim=pass header.d=netapp.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netapp.onmicrosoft.com; s=selector1-netapp-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=c8Kc5bD2uBZGpbt8RuhHHzkHROe2x5FZWb04P7q0o+I=; b=fEq3p8blpNbvYMuh1nklEoabp3Al0bbjDuX0WtpAHZAo6hBeK7V5Jj9YsWHzqgNJMBUSLydlXkEsVwWX3S3uEqvffEQFaAJDimIR+dhYvRiqo2+JbAboeAZ6wNjsq8guZg4otEN4nyUx5ePhBqmCKOGQCpRalg2mbfaHm3CJVOQ= Received: from SN4PR0601MB3728.namprd06.prod.outlook.com (2603:10b6:803:51::24) by SN4PR0601MB3631.namprd06.prod.outlook.com (2603:10b6:803:4f::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3305.26; Sun, 23 Aug 2020 19:56:45 +0000 Received: from SN4PR0601MB3728.namprd06.prod.outlook.com ([fe80::b155:6e3d:2116:e638]) by SN4PR0601MB3728.namprd06.prod.outlook.com ([fe80::b155:6e3d:2116:e638%2]) with mapi id 15.20.3305.025; Sun, 23 Aug 2020 19:56:45 +0000 From: "Scheffenegger, Richard" To: Liang Tian , FreeBSD Transport CC: freebsd-net Subject: RE: Fast recovery ssthresh value Thread-Topic: Fast recovery ssthresh value Thread-Index: AQHWeNGXKLXrd0Ypk0G/FpBfyhwhfqlGGMBA Date: Sun, 23 Aug 2020 19:56:45 +0000 Message-ID: References: In-Reply-To: Accept-Language: de-AT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [185.236.167.136] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8f609e53-bc6c-40db-e293-08d8479eaa1c x-ms-traffictypediagnostic: SN4PR0601MB3631: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: lcDNmnc7efzQ5yXoJUiPjnitFXMzLkQlxsHHKvAv1aH0h631M+4VRgKqnp0MQm5v+FDuHVYq3lWg5T41cm/JhrA5KJlK+W7ewp/XKePeO4p4NsE1MHljUstAPLarixVIqgfhDsmiIGQnCd9q85Bi4L6o3JG7Am1kuUH4jqdtRpfzxeDYmPKhTxMvrS305YGx6aoz8csPmW9Rrq2B6pmBnThzF4cevOBWniDmh++jZdgIOyLHi0sniJLHHonoq3lZoC3bloveSu06IZp91uznxmQgLs93oq6NjdPliTgpBPA9EhTRD3J91KIHi5UV14QR/PSG/oYk+zsZV4eBd7jaxoIT9YTqhYidu8uV7BLK3ogZvm6NMIuDDC0vPDwp5ECiR1zu09B8hjGY6A9i7ikTDA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SN4PR0601MB3728.namprd06.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(346002)(376002)(136003)(366004)(39860400002)(966005)(52536014)(8676002)(55016002)(316002)(6506007)(53546011)(3480700007)(5660300002)(86362001)(110136005)(2906002)(33656002)(7696005)(8936002)(66446008)(66946007)(83380400001)(66476007)(76116006)(9686003)(71200400001)(186003)(26005)(4326008)(478600001)(66556008)(64756008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: fhVSBkTiKiY6t4lhiVjYELiSrMl7iyXTXp2WPiJIFW1zH/VCaIs88awb+6UOkM6RCsgl2rEXrl7C0J7TvnYNVN8yHXE9tstuOTgkoFxmr14mOrO7XmyU1m/2XmxsEd//v30DMRwvc1lzbGlb9PpbtSOnoLOoHz5VsSIIrKnabMdQiE29mRp/mASGa21fstU5U2IMT8+2bT4eZAwx0tR+j1dizqCVPgpiX4ZsPatDOW9g0tFGeaEeBZ+UKa3PfjJfsmEDm9YTH9hPJbjTHqU0YsIF8glWgjIqK3c3MTCg4cztwGOImsExOjW2EWokKTkibjByMLNZLehOOg4fxeukjH6OGssmfybEUoBSfdGwZPq5K+uRSYHdc+1mbjOKr644cP6b9HTc4jTT/vRIE8U9p76GqtaS+jDsjS1YMDcvNB4v3QAxpFuWj9le8lRKOZdzNJZan4j5lbnKvvDvReF0eX7OuzBsL6aKPJcATLis3B7lsGch7KRJO3Cdx7STS+pY1yK/T0W/qMoLQSkTy+Mha1xVPRoRi8EGyLbDEgughIdSTaLRnBL/ce4i1tRVa6XlnQngj/ehIKntGDHY4Gi55YByTUmEkloNwftbXrY8fmmW94M0oY1Iz/8RKN9CsQuJAENICOmnrfkQgmRxAI34RA== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: netapp.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SN4PR0601MB3728.namprd06.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8f609e53-bc6c-40db-e293-08d8479eaa1c X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Aug 2020 19:56:45.6656 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: eZfMcLncmSGbLuMHhcoa7aWRujxF+98Qa3M4v8NwFFOaWGc6MUwWS4iyQ9GvU9OKfI2/tfjguSdNTKYPE8Kz3A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN4PR0601MB3631 X-Rspamd-Queue-Id: 4BZQxy2RNwz4LYl X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=netapp.onmicrosoft.com header.s=selector1-netapp-onmicrosoft-com header.b=fEq3p8bl; dmarc=none; spf=pass (mx1.freebsd.org: domain of Richard.Scheffenegger@netapp.com designates 2a01:111:f400:fe59::618 as permitted sender) smtp.mailfrom=Richard.Scheffenegger@netapp.com X-Spamd-Result: default: False [-2.21 / 15.00]; R_DKIM_ALLOW(-0.20)[netapp.onmicrosoft.com:s=selector1-netapp-onmicrosoft-com]; HAS_XOIP(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip6:2a01:111:f400::/48]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[netapp.com]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[netapp.onmicrosoft.com:+]; NEURAL_HAM_SHORT(-0.71)[-0.706]; FREEMAIL_TO(0.00)[gmail.com,freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:8075, ipnet:2a01:111:f000::/36, country:US]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; MAILMAN_DEST(0.00)[freebsd-transport,freebsd-net] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Aug 2020 19:56:59 -0000 Hi Liang, In SACK loss recovery, you can recover up to ssthresh (prior cwnd/2 [or 70%= in case of cubic]) lost bytes - at least in theory. In comparison, (New)Reno can only recover one lost packet per window, and t= hen keeps on transmitting new segments (ack + cwnd), even before the receip= t of the retransmitted packet is acked. For historic reasons, the semantic of the variable cwnd is overloaded durin= g loss recovery, and it doesn't "really" indicate cwnd, but rather indicate= s if/when retransmissions can happen. In both cases (also the simple one, with only one packet loss), cwnd should= be equal (or near equal) to ssthresh by the time loss recovery is finished= - but NOT before! While it may appear like slow-start, the value of the cw= nd variable really increases by acked_bytes only per ACK (not acked_bytes += SMSS), since the left edge (snd_una) doesn't move right - unlike during sl= ow-start. But numerically, these different phases (slow-start / sack loss-r= ecovery) may appear very similar. You could check this using the (loadable) SIFTR module, which captures t_fl= ags (indicating if cong/loss recovery is active), ssthresh, cwnd, and other= parameters. That is at least how things are supposed to work; or have you investigated = the timing and behavior of SACK loss recovery and found a deviation to RFC3= 517? Note that FBSD currently has not fully implemented RFC6675 support (wh= ich deviates slightly from 3517 under specific circumstances; I have a patc= h pending to implemente 6675 rescue retransmissions, but haven't tweaked th= e other aspects of 6675 vs. 3517. BTW: While freebsd-net is not the wrong DL per se, TCP, UDP, SCTP specific = questions can also be posted to freebsd-transport, which is more narrowly f= ocused. Best regards, Richard Scheffenegger -----Original Message----- From: owner-freebsd-net@freebsd.org On Beha= lf Of Liang Tian Sent: Sonntag, 23. August 2020 00:14 To: freebsd-net Subject: Fast recovery ssthresh value NetApp Security WARNING: This is an external email. Do not click links or o= pen attachments unless you recognize the sender and know the content is saf= e. Hi all, When 3 dupacks are received and TCP enter fast recovery, if SACK is used, t= he CWND is set to maxseg: 2593 if (tp->t_flags & TF_SACK_PERMIT) { 2594 TCPSTAT_INC( 2595 tcps_sack_recovery_episode); 2596 tp->snd_recover =3D tp->snd_nxt; 2597 tp->snd_cwnd =3D maxseg; 2598 (void) tp->t_fb->tfb_tcp_output(tp); 2599 goto drop; 2600 } Otherwise(SACK is not in use), CWND is set to maxseg before tcp_output() and then set back to snd_ssthresh+inflation 2601 tp->snd_nxt =3D th->th_ack; 2602 tp->snd_cwnd =3D maxseg; 2603 (void) tp->t_fb->tfb_tcp_output(tp); 2604 KASSERT(tp->snd_limited <=3D 2, 2605 ("%s: tp->snd_limited too big", 2606 __func__)); 2607 tp->snd_cwnd =3D tp->snd_ssthresh + 2608 maxseg * 2609 (tp->t_dupacks - tp->snd_limited); 2610 if (SEQ_GT(onxt, tp->snd_nxt)) 2611 tp->snd_nxt =3D onxt; 2612 goto drop; I'm wondering in the SACK case, should CWND be set back to ssthresh(which h= as been slashed in cc_cong_signal() a few lines above) before line 2599, li= ke non-SACK case, instead of doing slow start from maxseg? I read rfc6675 and a few others, and it looks like that's the case. I appre= ciate your opinion, again. Thanks, Liang _______________________________________________ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"