From owner-freebsd-transport@freebsd.org Wed Oct 7 16:18:24 2015 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 2E2D39D1C48 for ; Wed, 7 Oct 2015 16:18:24 +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 08167F28 for ; Wed, 7 Oct 2015 16:18:24 +0000 (UTC) (envelope-from rrs@netflix.com) Received: by mailman.ysv.freebsd.org (Postfix) id 04F3C9D1C47; Wed, 7 Oct 2015 16:18:24 +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 DEAA79D1C46 for ; Wed, 7 Oct 2015 16:18:23 +0000 (UTC) (envelope-from rrs@netflix.com) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) (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 AC4D3F26 for ; Wed, 7 Oct 2015 16:18:23 +0000 (UTC) (envelope-from rrs@netflix.com) Received: by pablk4 with SMTP id lk4so25593653pab.3 for ; Wed, 07 Oct 2015 09:18:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netflix.com; s=google; h=from:content-type:subject:message-id:date:to:mime-version; bh=8wwMeOdk6UnlowtIWsUrXwbHSy8B78AkOExV9y504lE=; b=I4a5KPLPaRNC2z2F91jmgiCLNigsoD/WxXa3EGNg4PVZdRzsaKnewuOyEs1n//Zw9c f5JLTHukxZ3Wfuol62eb5AYoCU5J3iUQc/bhIuIx8k/lsdf2eJqfmwXjPX6M9cON9Yww xr4mV33PdWhoql5HcnJtJGRUwY19v+e3yNZ5c= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:subject:message-id:date:to :mime-version; bh=8wwMeOdk6UnlowtIWsUrXwbHSy8B78AkOExV9y504lE=; b=mo0DdC1ZbgQ0Xwq9+7yL2O0MDYdjvQcEmvMr2qPP0f/pKyibBdHr+VkdsEddVb+u/f ss4MscurJKTSKOVZ8a3ClV++fzE3KeXJl9bchWNy9Ml5R6jUHiXp0zcHzQQgJLEQs0Sf 2VL17p/JXSxn3GOhZLAtrY5T9+PVuG+3sKxvSj1lsC0fGx6OlA5N7aeTlFIShNyRpEnE kDDmn+HOVrrMs6KV6o+j6ufL9F+Bq/nAPdtWJVJ+KF+726/KcMQbOohKBNhff7YIGvji MOuSYgtRXM9VOzNRhjUU2fpCMxy+7tZCo58fYMB/0yXpMR+b1/LWObNrRiTHLQ2NLbYp ijPQ== X-Gm-Message-State: ALoCoQm1iZQ7H1zfnDZQx/CDe8yLZiG24JhoJuZ+C6LFozSltyOxRy70f5ruun6rJT1mToeKSfZe X-Received: by 10.69.26.5 with SMTP id iu5mr2065551pbd.12.1444234703144; Wed, 07 Oct 2015 09:18:23 -0700 (PDT) Received: from [192.168.120.14] ([69.53.245.112]) by smtp.gmail.com with ESMTPSA id ql7sm40354502pbc.45.2015.10.07.09.18.20 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 07 Oct 2015 09:18:21 -0700 (PDT) From: Randall Stewart Subject: The trouble with sack.. Message-Id: Date: Wed, 7 Oct 2015 12:17:40 -0400 To: FreeBSD Transports Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-transport@freebsd.org X-Mailman-Version: 2.1.20 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, 07 Oct 2015 16:18:24 -0000 Greetings all: Hiren and I have been poking a little bit with the TCP-Sack = implementation in FreeBSD and I think we have pretty much determined its sub-optimal to = phrase it nicely :-) All the sack-scoreboard stuff works, but what we do with the scoreboard = and how we handle SACKs really does not match what the TCP RFC=92s say we = should. Here are a few of examples (there are probably more that we will yet = discover): 1) When we finally recognize its time to Fast Retransmit we shut the = cwnd to 1MTU. The SACK RFC=92s tell us to go to 1/2 of the pervious cwnd (which is = also stored in ssthresh). 2) When we recognize a dup-ack we *will not* recognize it if for example = if the rwnd changes even if new SACK information is reported in the sack blocks. This is due = to the fact that in non-SACK you don=92t (on purpose) recognize ACK=92s where the window changed (since you = can=92t really tell if its a plain window update or a dup-ack).. This means we occasionally miss = out on stroking the dup-ack counter and getting out of recovery.... 3) When we have more than one hole the goal of SACK was to retransmit = every time that a hole had 3 dup-acks so that one could recover multiple blocks that = were lost. We just plain don=92t track dup-acks per hole. We do continue to count, but = we will wait to retransmit anything until after we have drained 1/2 the data in flight from the = network at a minimum. And only then do we start incrementing cwnd (remember we crashed it to 1 MTU) so = that we can retransmit. There may be some other twists in the code that we are missing but this is = what we believe (this could could probably win the C obfuscation contest if someone were willing to = enter it :-D) 4) The way we calculate what is in flight with SACK is wrong, basically = we don=92t arrive at whats really in flight, which with SACK you can know if you have a = properly maintained=20 scoreboard (which we do have). Hiren and I have a few ideas on how to fix some of these, but I think we = may want to discuss first what Gleb talked about doing at BSD-Canada, at least so I am = told, which is to have each inpcb have a set of function pointers so we can create =93new=94= versions of say tcp_do_segment and tcp_output.. without changing original ones.. This way, has we develop fixes and improvements, we can keep the old = code in place without disrupting everyone and then after everyone has vetted and played with = the =93new=94 code we can switch things out :-) By the way just looking around at NF and doing some quick survery=92s of = SACK, about 99% of NF connections seem to have sack enabled, so its pretty much widely = deployed now.. and its rare we are *not* using the SACK cases in our TCP stack.. Best wishes R -------- Randall Stewart rrs@netflix.com 803-317-4952 From owner-freebsd-transport@freebsd.org Wed Oct 7 17:26:12 2015 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 9957D9D03EE for ; Wed, 7 Oct 2015 17:26:12 +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 7DBF41A9D for ; Wed, 7 Oct 2015 17:26:12 +0000 (UTC) (envelope-from hiren@strugglingcoder.info) Received: by mailman.ysv.freebsd.org (Postfix) id 7ABF39D03ED; Wed, 7 Oct 2015 17:26:12 +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 607109D03EC for ; Wed, 7 Oct 2015 17:26:12 +0000 (UTC) (envelope-from hiren@strugglingcoder.info) Received: from mail.strugglingcoder.info (strugglingcoder.info [65.19.130.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.strugglingcoder.info", Issuer "mail.strugglingcoder.info" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 513561A99 for ; Wed, 7 Oct 2015 17:26:11 +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 D1166D442D for ; Wed, 7 Oct 2015 10:26:10 -0700 (PDT) Date: Wed, 7 Oct 2015 10:26:10 -0700 From: hiren panchasara To: transport@FreeBSD.org Subject: Correct inflight/pipe calculation Message-ID: <20151007172610.GA42742@strugglingcoder.info> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="mP3DRpeJDSE+ciuQ" Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-transport@freebsd.org X-Mailman-Version: 2.1.20 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, 07 Oct 2015 17:26:12 -0000 --mP3DRpeJDSE+ciuQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Randall and I have been poking at different ways to improve FreeBSD tcp's reaction to loss. One of the major issue we found is that we do not use information provided by SACK efficiently even though we do keep the SACK scoreboard well in shape. Knowing amount of data in flight can be really crucial and can help us use available capacity of the path more efficiently. We currently do not have an accurate way of knowing this information. For example, inside tcp_do_segment(), while processing duplicate acks, we try to compute amount of data inflight with: awnd =3D (tp->snd_nxt - tp->snd_fack) + tp->sackhint.sack_bytes_rexmit; Which is incorrect as it doesn't take into account whats been already sacked by the receiver. There are definitely other places in the stack where we do this incorrectly. RFC 6675 provides guidance on how to implement calculations for bytes in flight at any point in time. Randall and I came to a conclusion that following can provide us inflight information almost(!) accurately with least amount of code changes: pipe =3D snd_max - snd_una - sackhint.sacked_bytes + sackhint.sack_bytes_re= xmit; here, snd_max: highest sequence number sent snd_una: lowest sequence number sent but not yet cumulatively acked sacked_bytes: total bytes sacked by receiver reported via SACK holes sack_bytes_rexmit: total bytes retransmitted from holes in this recovery period Only missing piece in FreeBSD is sackd_bytes. This is basically total bytes sacked by the receiver and it can be extracted from SACK holes reported by the receiver. The approach we've decided to take is pretty simple: we already process each ACK with sack holes in=20 tcp_sack_doack() and extract sack blocks out of it. We'd now also track this new variable there which keeps track of total sacked bytes reported. The downside with this approach is: There is no persistent information about sacked bytes. We recalculate it every time we get an ACK with sack holes in it. So if, for any reason, receiver decides to drop sack info than we get incorrect value for inflight. This may be also true when there are more holes but receiver can only report 3 at a time. I have actual code that I've been testing and if people see no major problem with this approach, I can put it up for review in phabricator. Cheers, Hiren --mP3DRpeJDSE+ciuQ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAABCgBmBQJWFVWrXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4 QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/lvV4IAJrQzV89VABQubkmmjuby0cC LgXoZ6nF7bEgK3W4SNWHJ+fQpgZC2JR9db08R6yQIdB4hb3sxwehqi/ySaiw9vix y0YL73Ohj4H5N9SZU7BXbWUl1PH0UWWh/SQLkArs3hkQw+uQWo43Ewcu1IO8xHcl 06LqNMqdbXbz0psuyyjyq9KSOnZ0qHq3XZhj2QNWJQr9uLqNY2baft1JGcLGG91u f6RFUhaRiopF0aQSs+9dDWyKLd9GTQjHFtdl77GCf0RN8SpSg7+jZiHzexoXpmMw 6jwqD7ut3/5p+TXhFbFemcB0wn7///pXEnE8CCZO9dvY6ncoR4rfcZW0RI5T/Z8= =sD2k -----END PGP SIGNATURE----- --mP3DRpeJDSE+ciuQ-- From owner-freebsd-transport@freebsd.org Wed Oct 7 19:54:51 2015 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 E73C09D0B0A for ; Wed, 7 Oct 2015 19:54:51 +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 D12A61C9 for ; Wed, 7 Oct 2015 19:54:51 +0000 (UTC) (envelope-from hiren@strugglingcoder.info) Received: by mailman.ysv.freebsd.org (Postfix) id D076C9D0B09; Wed, 7 Oct 2015 19:54:51 +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 D00EE9D0B08 for ; Wed, 7 Oct 2015 19:54:51 +0000 (UTC) (envelope-from hiren@strugglingcoder.info) Received: from mail.strugglingcoder.info (strugglingcoder.info [65.19.130.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.strugglingcoder.info", Issuer "mail.strugglingcoder.info" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C10111C8 for ; Wed, 7 Oct 2015 19:54:51 +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 3F735D4FF3 for ; Wed, 7 Oct 2015 12:54:45 -0700 (PDT) Date: Wed, 7 Oct 2015 12:54:45 -0700 From: hiren panchasara To: transport@FreeBSD.org Subject: Setting congestion window on loss detection Message-ID: <20151007195445.GC42742@strugglingcoder.info> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="0vzXIDBeUiKkjNJl" Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-transport@freebsd.org X-Mailman-Version: 2.1.20 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, 07 Oct 2015 19:54:52 -0000 --0vzXIDBeUiKkjNJl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Found this issue about a month ago and started a discussion on -net: https://lists.freebsd.org/pipermail/freebsd-net/2015-September/043249.html I feel this forum is a better place to discuss this further now. Problem: We set cwnd to 1mss when we detect loss via arrivals of 3 dupacks. That is wrong as we severely underutilizing network capacity by doing so. Next question is, what should we set cwnd to? RFC6675 (TCP SACK) suggests following on detecting loss: ssthresh = cwnd = (FlightSize / 2) RFC5681 (TCP Congestion control) suggest: ssthresh = max (FlightSize / 2, 2*SMSS) cwnd = (ssthresh + 3*SMSS) (Here, FlightSize is bytes in flight.) OR should we let whatever congestion control (CC) algo in control decide that value? Cheers, Hiren --0vzXIDBeUiKkjNJl Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAABCgBmBQJWFXiBXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4 QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/lRAUH/2wsJssQ1BkEbbMERnVTQfLB SsM1+mJwu5BZDz39l+Z5HtxmNmN5Rz18oMkFxWFOEmbhxXAU3NWXwEyFiPZpwHvY r2SDrlNjUfy2d/D/uH4IHgLrq/zweD7w3zPrpn1j4zcm/g4rNl3HV+ATb8DUEzhg LXWMy1kSc2v/Qg6EcqCmO01EitBh7NI0xqgMB/BQF1y00enoi4UJAguDqLNEZPLV 9AlI6hkHI5txekm2BQTfLVXRcetSqd74bI99reTtqYiMUABj/c5Iz189LXPXQJq6 SBXsn+Dc67EWyWR3QKKP0hMIxZ31tCZwseeKj3uYrbzGDUqmNvcsqtaZSG4Kt/0= =lOoe -----END PGP SIGNATURE----- --0vzXIDBeUiKkjNJl-- From owner-freebsd-transport@freebsd.org Fri Oct 9 14:32:49 2015 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 44DB89D16FF for ; Fri, 9 Oct 2015 14:32:49 +0000 (UTC) (envelope-from gnn@neville-neil.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 29108881 for ; Fri, 9 Oct 2015 14:32:49 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: by mailman.ysv.freebsd.org (Postfix) id 282D79D16FE; Fri, 9 Oct 2015 14:32:49 +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 27C2E9D16FD for ; Fri, 9 Oct 2015 14:32:49 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from smtp.hungerhost.com (smtp.hungerhost.com [216.38.53.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 02C92880 for ; Fri, 9 Oct 2015 14:32:49 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from pan3.nycourts.gov ([207.29.45.2]:30382 helo=[192.168.141.0]) by vps.hungerhost.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.85) (envelope-from ) id 1ZkYiy-00063k-HK; Fri, 09 Oct 2015 10:32:44 -0400 From: "George Neville-Neil" To: "Eitan Adler" Cc: "hiren panchasara" , transport@freebsd.org Subject: Re: TCP rfc compliance Date: Fri, 09 Oct 2015 10:32:44 -0400 Message-ID: In-Reply-To: References: <20150926225750.GE19325@strugglingcoder.info> <391A3F4B-84B9-4681-8F5C-A68319C2E0D6@neville-neil.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.2r5141) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vps.hungerhost.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - neville-neil.com X-Get-Message-Sender-Via: vps.hungerhost.com: authenticated_id: gnn@neville-neil.com X-Source: X-Source-Args: X-Source-Dir: X-BeenThere: freebsd-transport@freebsd.org X-Mailman-Version: 2.1.20 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, 09 Oct 2015 14:32:49 -0000 Thanks for the formatting, it's quite nice. Hiren, before I dig into these, and its quite a list, are all of these RFCs listed RFCs that we want to support or are they just a list of RFCs that relate to TCP? If its that latter we'll need another column (WANT) for those that are as yet unsupported or unknown. I will eventually add a TEST column to point to somewhere that we keep a canonical test, once we have some :-) Best, George On 26 Sep 2015, at 20:10, Eitan Adler wrote: > Thanks! I reformatted it, intending to keep all the content the same. > > On 26 September 2015 at 16:39, George Neville-Neil > wrote: >> Excellent. Thanks! >> >> Best >> George >> >> >> On 26 Sep 2015, at 16:57, hiren panchasara wrote: >> >>> As discussed in the transport group meeting (and because it's a good >>> idea anyways), I've created a page to list what rfcs we do and don't >>> support here: >>> https://wiki.freebsd.org/TransportProtocols/tcp_rfc_compliance >>> >>> Treat it as just a starting point and please add/modify/edit as you >>> see fit. >>> >>> Cheers, >>> Hiren > > > > -- > Eitan Adler From owner-freebsd-transport@freebsd.org Fri Oct 9 15:35:20 2015 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 0CC8F9D21E7 for ; Fri, 9 Oct 2015 15:35:20 +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 E6C3B647 for ; Fri, 9 Oct 2015 15:35:19 +0000 (UTC) (envelope-from hiren@strugglingcoder.info) Received: by mailman.ysv.freebsd.org (Postfix) id E5E259D21E6; Fri, 9 Oct 2015 15:35:19 +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 E57909D21E5 for ; Fri, 9 Oct 2015 15:35:19 +0000 (UTC) (envelope-from hiren@strugglingcoder.info) Received: from mail.strugglingcoder.info (strugglingcoder.info [65.19.130.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.strugglingcoder.info", Issuer "mail.strugglingcoder.info" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D2693646 for ; Fri, 9 Oct 2015 15:35:19 +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 BBD63106969; Fri, 9 Oct 2015 08:35:12 -0700 (PDT) Date: Fri, 9 Oct 2015 08:35:12 -0700 From: hiren panchasara To: George Neville-Neil Cc: Eitan Adler , transport@freebsd.org Subject: Re: TCP rfc compliance Message-ID: <20151009153512.GD96320@strugglingcoder.info> References: <20150926225750.GE19325@strugglingcoder.info> <391A3F4B-84B9-4681-8F5C-A68319C2E0D6@neville-neil.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="vni90+aGYgRvsTuO" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-transport@freebsd.org X-Mailman-Version: 2.1.20 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, 09 Oct 2015 15:35:20 -0000 --vni90+aGYgRvsTuO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 10/09/15 at 10:32P, George Neville-Neil wrote: > Thanks for the formatting, it's quite nice. >=20 > Hiren, before I dig into these, and its quite a list, are all of these=20 > RFCs listed RFCs that we want to support > or are they just a list of RFCs that relate to TCP? If its that latter= =20 > we'll need another column (WANT) for those > that are as yet unsupported or unknown. https://wiki.freebsd.org/TransportProtocols/tcp_rfc_compliance It's just a list of all possible TCP related RFCs Eitan could find through some script. I still find some missing and keep adding them to the list. My intention was more for just the informational purpose as what is supported and what is not. I see that you also want this to reflect whats needed for FreeBSD and we can point interested people to point to it. You can add a "Want" column and if it's checked, its something we want in near future (or something like that). > I will eventually add a TEST=20 > column to point to somewhere > that we keep a canonical test, once we have some :-) > Sounds good :-) Cheers, Hiren --vni90+aGYgRvsTuO Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAABCgBmBQJWF96tXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4 QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/ljdYH/jp5XCZTwk7PdBwLzq4da5bB t2nwZfFafLp3bfp7XoFgH/1CYHzuB6hqOPrP7wPtTwCy1wzHsnvRFQg06l/OI+43 sAG1UUbrWxHHYsuwuRUh5JWZsoKTe0qqyTUNbsbEuQS9Z7Ec+gVd2wxP008U+hZh IlOONX7PcTF0U+I4sdNYPVCc/OWj7ae/tdah3UI6Wk9KfJ6DwERlZii0u327ngz5 q4SJeMy3rBZLMd/p4WkQQN8eeriOgvKz+jUkM7Yx320DUGwjQJuATUIbsKhHOBgU rVU08xKwlLRzOa8ChU933U6GVD5q7H6H74DtpQ92KZubA6TjSa2NM9yxf4mxmUc= =AGji -----END PGP SIGNATURE----- --vni90+aGYgRvsTuO-- From owner-freebsd-transport@freebsd.org Sat Oct 10 15:27:50 2015 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 ADD7EA10A4F for ; Sat, 10 Oct 2015 15:27:50 +0000 (UTC) (envelope-from gnn@neville-neil.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 95391C0 for ; Sat, 10 Oct 2015 15:27:50 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: by mailman.ysv.freebsd.org (Postfix) id 945FAA10A4D; Sat, 10 Oct 2015 15:27:50 +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 94048A10A4C for ; Sat, 10 Oct 2015 15:27:50 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from smtp.hungerhost.com (smtp.hungerhost.com [216.38.53.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 72447BF for ; Sat, 10 Oct 2015 15:27:49 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from pool-108-54-164-204.nycmny.fios.verizon.net ([108.54.164.204]:58444 helo=[192.168.1.7]) by vps.hungerhost.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.85) (envelope-from ) id 1Zkw3o-0005D7-Gh for transport@freebsd.org; Sat, 10 Oct 2015 11:27:48 -0400 From: "George Neville-Neil" To: transport@freebsd.org Subject: Documents from Peter Sewell on TCP stack... Date: Sat, 10 Oct 2015 11:27:48 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.2r5141) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vps.hungerhost.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - neville-neil.com X-Get-Message-Sender-Via: vps.hungerhost.com: authenticated_id: gnn@neville-neil.com X-Source: X-Source-Args: X-Source-Dir: X-BeenThere: freebsd-transport@freebsd.org X-Mailman-Version: 2.1.20 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: Sat, 10 Oct 2015 15:27:50 -0000 Howdy, These are a bit long but this is the work that Peter (who I think is now on this list) and his group did in 2005 on the FreeBSD TCP stack. http://www.cl.cam.ac.uk/~pes20/Netsem/tr.pdf http://www.cl.cam.ac.uk/~pes20/Netsem/alldoc.pdf Much of the overview material including the "Quick Introduction" which I recommend you read first, is here http://www.cl.cam.ac.uk/~pes20/Netsem/index.html Best, George From owner-freebsd-transport@freebsd.org Sat Oct 10 15:30:51 2015 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 C8733A10BFB for ; Sat, 10 Oct 2015 15:30:51 +0000 (UTC) (envelope-from p.m.sewell@googlemail.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 A75133B5 for ; Sat, 10 Oct 2015 15:30:51 +0000 (UTC) (envelope-from p.m.sewell@googlemail.com) Received: by mailman.ysv.freebsd.org (Postfix) id A6182A10BFA; Sat, 10 Oct 2015 15:30:51 +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 8BE19A10BF9 for ; Sat, 10 Oct 2015 15:30:51 +0000 (UTC) (envelope-from p.m.sewell@googlemail.com) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (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 570793B4 for ; Sat, 10 Oct 2015 15:30:51 +0000 (UTC) (envelope-from p.m.sewell@googlemail.com) Received: by iow1 with SMTP id 1so118409378iow.1 for ; Sat, 10 Oct 2015 08:30:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=0RIO8O5mj099V/RqJS1gcxmyKF200PFK+5/Y8PfcVYg=; b=Nx7IpAxCksM0WP6KzPsz4Md5r7Y0huWttyMyeKhfAY6dO97f4tFX8xpTplfUjBsQCk 1cKK30MKjJ8ruxHTSRbll+gy4eR479K5M9BdDSJyoFCP8SiWAeu9Siwc3v5CDZHHPDkT +DW+gu28gyN4cTQrlrxSqU1jLfZBnFjOjiAazFZhoBSkgOS6jMicHiPryez6YQSvHprM OZpYBj+iOA1mzD/TKM8cWcq4/DvBQBzcdPxoLXgun2Po+fB7prJGijVndGKQ4o9ZsUBp Kl50MGyvu/R6SHUwq1NroXnRNbZ7i/6frgFB0eJ5ZfsacCL1Ehm8ncwKLJdXiqL6F0Qb So1w== MIME-Version: 1.0 X-Received: by 10.107.46.101 with SMTP id i98mr20736350ioo.17.1444491050615; Sat, 10 Oct 2015 08:30:50 -0700 (PDT) Reply-To: Peter.Sewell@cl.cam.ac.uk Sender: p.m.sewell@googlemail.com Received: by 10.64.251.130 with HTTP; Sat, 10 Oct 2015 08:30:50 -0700 (PDT) In-Reply-To: References: Date: Sat, 10 Oct 2015 16:30:50 +0100 X-Google-Sender-Auth: WwuD9mpzRcJvPfXhOZF3WlqtaRo Message-ID: Subject: Re: Documents from Peter Sewell on TCP stack... From: Peter Sewell To: George Neville-Neil Cc: transport@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-transport@freebsd.org X-Mailman-Version: 2.1.20 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: Sat, 10 Oct 2015 15:30:51 -0000 On 10 October 2015 at 16:27, George Neville-Neil wrote: > Howdy, > > These are a bit long but this is the work that Peter (who I think is now > on this list) and his group > did in 2005 on the FreeBSD TCP stack. > > http://www.cl.cam.ac.uk/~pes20/Netsem/tr.pdf > http://www.cl.cam.ac.uk/~pes20/Netsem/alldoc.pdf > > Much of the overview material including the "Quick Introduction" which I > recommend you read first, > is here http://www.cl.cam.ac.uk/~pes20/Netsem/index.html > > (probably the SIGCOMM paper [http://www.cl.cam.ac.uk/~pes20/Netsem/paper.ps] comes after that) > Best, > George > _______________________________________________ > 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" >