From owner-freebsd-transport@freebsd.org Thu Sep 21 18:47:42 2017 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 A0610E18FE4 for ; Thu, 21 Sep 2017 18:47:42 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.franken.de", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6959B65A42 for ; Thu, 21 Sep 2017 18:47:39 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from [192.168.1.204] (p57BB4EC8.dip0.t-ipconnect.de [87.187.78.200]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id F1A1471E3F8CF for ; Thu, 21 Sep 2017 20:47:34 +0200 (CEST) From: Michael Tuexen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: D12430 Message-Id: <6D595B79-5495-40C8-8114-C5824EF3D798@freebsd.org> Date: Thu, 21 Sep 2017 20:47:33 +0200 To: freebsd-transport@freebsd.org X-Mailer: Apple Mail (2.3273) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=disabled version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail-n.franken.de 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: Thu, 21 Sep 2017 18:47:42 -0000 Dear all, when FreeBS sends a SYN-ACK, it never sends an MSS larger than the one received in the SYN. This consideration of the peer's MSS is what the patch removes. Personally, I found this neat although not described in an RFC. The reasoning could be that the client uses its MTU to deduce the MSS and you make the assumption that this is symmetric. Best regards Michael From owner-freebsd-transport@freebsd.org Fri Sep 22 01:50:06 2017 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 6983FE080BF for ; Fri, 22 Sep 2017 01:50:06 +0000 (UTC) (envelope-from sepherosa@gmail.com) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (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 14FB074204; Fri, 22 Sep 2017 01:50:06 +0000 (UTC) (envelope-from sepherosa@gmail.com) Received: by mail-qk0-x233.google.com with SMTP id b23so7540648qkg.1; Thu, 21 Sep 2017 18:50:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jTLcBNtOGigq+RUqIHuhKxJbgnJyaz62ZfV+QNCnw8k=; b=XUZa5lC+ERLVm51kncWa4P3CnyHIz3pjM8fG0+YUUdjmDCHRlw6x4l6IFHwb3ot459 VhMD557rP+bo2W7qT3n+0EH2BPwdpoAWTSS+Pmru0rpbOWyzpgbTxGQ/CdY2CKU4xxJY sGdIPf0x77zzVHv2ef98m91tZnAcyJ1u645lcLd7LYOCslw/dtQoIlVwgi8deLM6WUWT TrLDAwod5frvfmikpJzRtkVcaOzyFV5JUE4aU30S2qatYSBQvSDZVVUb6xaeCcdbwmrZ fxHo2iUxmUaXh8qxSEPtx4fC9cD/vkJhxQdF4BjJ9sZDa1kgSuwlbcukQC9EIfSxppdP yaWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jTLcBNtOGigq+RUqIHuhKxJbgnJyaz62ZfV+QNCnw8k=; b=dcTyrBqyDZ1N1RXtLrOY3FzZgvv8WSDBap71KLFCMoIoQqB4JqO0Yf20a7Yj56zTba plLEet+s22mz29IY/36wCXw4PuI6uSY+S1zbwVjioTu0MChx3TrWEk8eEogIQ1VQlacZ +pfwXe5C7sgmln4ipdW+/87PzktW+HDKkDJLpTGDDfYzksw++ZOa7/c7XqJdzoLT4WH0 geuGte4RzfoBukXEVpG6KmpIePG/Pfj5jJ5kEpNS1GY61AXzcZRXEtG5OIxZcfH9p9mV rfT5na66EyrfPF651pqb1hWt60SdvSbm0k8gwKua+uCL7JcshfTGeZykrCx1d7lmuDR4 i5gw== X-Gm-Message-State: AHPjjUgzRLdAZKrYNGNBEQiADrHF5I/nsd5I6w89+shyO4xWggUI7j9V jA0KFQ9rey+TJhVCdc5CRVaFNCM6c0a0d1SmKmfr X-Google-Smtp-Source: AOwi7QBr7kB+p7hSw7fg0DUgQI6JTx/V/j7baUH+5oUOoZF0F7YKU5kcg6dLTnTYtdflQURHirUWNQeheCsybW0Oi50= X-Received: by 10.55.21.5 with SMTP id f5mr6374967qkh.335.1506045004026; Thu, 21 Sep 2017 18:50:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.21.20 with HTTP; Thu, 21 Sep 2017 18:50:03 -0700 (PDT) In-Reply-To: <6D595B79-5495-40C8-8114-C5824EF3D798@freebsd.org> References: <6D595B79-5495-40C8-8114-C5824EF3D798@freebsd.org> From: Sepherosa Ziehau Date: Fri, 22 Sep 2017 09:50:03 +0800 Message-ID: Subject: Re: D12430 To: Michael Tuexen Cc: freebsd-transport@freebsd.org Content-Type: text/plain; charset="UTF-8" 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: Fri, 22 Sep 2017 01:50:06 -0000 The situation I encountered is in Azure. Azure automatically subtracts 42 bytes (NVGRE encap overhead) from the MSS option. The flow is generally like this: Tcpdump on client side: 13:00:25.099465 IP 10.0.1.5.19614 > 10.0.1.4.12865: Flags [S], seq 2686655391, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 4628516 ecr 0], length 0 13:00:25.102567 IP 10.0.1.4.12865 > 10.0.1.5.19614: Flags [S.], seq 1982641632, ack 2686655392, win 65535, options [mss 1376,nop,wscale 6,sackOK,TS val 872848224 ecr 4628516], length 0 Tcpdump on the server side: 13:00:24.979913 IP 10.0.1.5.19614 > 10.0.1.4.12865: Flags [S], seq 2686655391, win 65535, options [mss 1418,nop,wscale 6,sackOK,TS val 4628516 ecr 0], length 0 13:00:24.981228 IP 10.0.1.4.12865 > 10.0.1.5.19614: Flags [S.], seq 1982641632, ack 2686655392, win 65535, options [mss 1418,nop,wscale 6,sackOK,TS val 872848224 ecr 4628516], length 0 As you can see if we unnecessarily "negotiate" the MSS, the client side will see 1376 as MSS instead of 1418. And I believe this kind of MSS adjustment is quite common in various cloud platform. BTW, as I indicated in the description of the review request, _no_ OSes actually "negotiate" the MSS. Thanks, sephe On Fri, Sep 22, 2017 at 2:47 AM, Michael Tuexen wrote: > Dear all, > > when FreeBS sends a SYN-ACK, it never sends an MSS larger than the one > received in the SYN. This consideration of the peer's MSS is what the > patch removes. > > Personally, I found this neat although not described in an RFC. The > reasoning could be that the client uses its MTU to deduce the MSS > and you make the assumption that this is symmetric. > > Best regards > Michael > _______________________________________________ > freebsd-transport@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-transport > To unsubscribe, send any mail to "freebsd-transport-unsubscribe@freebsd.org" -- Tomorrow Will Never Die