Re: TCP socket handling errors

On Fri, Dec 20, 2024 at 07:48:05AM +, Sad Clouds wrote: S> > Please take a look at https://reviews.freebsd.org/D48148 S> S> Thanks for the info. I have some ifdefs in my user space code to handle S> this FreeBSD bug. Is it possible to tell at this stage in which stable S> FreeBSD release versi

Re: TCP socket handling errors

On Wed, Apr 03, 2024 at 01:14:34PM +0100, Sad Clouds wrote: S> Hello, I have a client/server networking application that exhibits S> TCP socket handling errors. This only happens on FreeBSD, while NetBSD, S> Linux, Solaris, etc. all seem to work correctly. I was hoping to get S> some advice on what

Re: TCP Success Story (was Re: TCP_RACK, TCP_BBR, and firewalls)

On Wed, Jul 17, 2024 at 02:00:31PM -0600, Alan Somers wrote: So I benchmarked all available congestion control algorithms for single download streams. The results are summarized in the table below. Sorry for resurrecting an old thread, but I note your testing was with single streams. What ar

Re: TCP Success Story (was Re: TCP_RACK, TCP_BBR, and firewalls)

> On 19. Jul 2024, at 05:07, Junho Choi wrote: > > RACK is a loss detection algorithm and BBR is a congestion control algorithm > so it's on a different layer. > e.g. linux can configure them independently. > > However in FreeBSD it looks like it is using the same configuration sysctl > (net.i

Re: TCP Success Story (was Re: TCP_RACK, TCP_BBR, and firewalls)

RACK is a loss detection algorithm and BBR is a congestion control algorithm so it's on a different layer. e.g. linux can configure them independently. However in FreeBSD it looks like it is using the same configuration sysctl (net.inet.tcp.functions_default=tcp_rack|tcp_bbr), so not able to set i

Re: TCP Success Story (was Re: TCP_RACK, TCP_BBR, and firewalls)

> On 18. Jul 2024, at 20:37, Alan Somers wrote: > > Coexist how? Do you mean that one socket can use one and a different > socket uses the other? That makes sense. Correct. Best regards Michael > > On Thu, Jul 18, 2024 at 10:34 AM wrote: >> >>> On 18. Jul 2024, at 15:00, Junho Choi wrote:

Re: TCP Success Story (was Re: TCP_RACK, TCP_BBR, and firewalls)

Coexist how? Do you mean that one socket can use one and a different socket uses the other? That makes sense. On Thu, Jul 18, 2024 at 10:34 AM wrote: > > > On 18. Jul 2024, at 15:00, Junho Choi wrote: > > > > Alan - this is a great result to see. Thanks for experimenting. > > > > Just curious

Re: TCP Success Story (was Re: TCP_RACK, TCP_BBR, and firewalls)

> On 18. Jul 2024, at 16:03, Alan Somers wrote: > > On Wed, Jul 17, 2024 at 2:27 PM wrote: >> >>> On 17. Jul 2024, at 22:00, Alan Somers wrote: >>> >>> On Sat, Jul 13, 2024 at 1:50 AM wrote: > On 13. Jul 2024, at 01:43, Alan Somers wrote: > > I've been experimenting wi

Re: TCP Success Story (was Re: TCP_RACK, TCP_BBR, and firewalls)

> On 18. Jul 2024, at 15:00, Junho Choi wrote: > > Alan - this is a great result to see. Thanks for experimenting. > > Just curious why bbr and rack don't co-exist? Those are two separate things. > Is it a current bug or by design? Technically RACK and BBR can coexist. The problem was with pf an

Re: TCP Success Story (was Re: TCP_RACK, TCP_BBR, and firewalls)

> On 18. Jul 2024, at 15:00, Junho Choi wrote: > > Alan - this is a great result to see. Thanks for experimenting. > > Just curious why bbr and rack don't co-exist? Those are two separate things. > Is it a current bug or by design? Technically RACK and BBR can coexist. The problem was with pf an

Re: TCP Success Story (was Re: TCP_RACK, TCP_BBR, and firewalls)

On Wed, Jul 17, 2024 at 2:27 PM wrote: > > > On 17. Jul 2024, at 22:00, Alan Somers wrote: > > > > On Sat, Jul 13, 2024 at 1:50 AM wrote: > >> > >>> On 13. Jul 2024, at 01:43, Alan Somers wrote: > >>> > >>> I've been experimenting with RACK and BBR. In my environment, they > >>> can dramatical

Re: TCP Success Story (was Re: TCP_RACK, TCP_BBR, and firewalls)

I'm not sure what you're asking. BBR and RACK are two different algorithms that accomplish the same thing. It wouldn't make sense to use both on the same socket at the same time. On Thu, Jul 18, 2024 at 7:01 AM Junho Choi wrote: > > Alan - this is a great result to see. Thanks for experimenting

Re: TCP Success Story (was Re: TCP_RACK, TCP_BBR, and firewalls)

Alan - this is a great result to see. Thanks for experimenting. Just curious why bbr and rack don't co-exist? Those are two separate things. Is it a current bug or by design? BR, On Thu, Jul 18, 2024 at 5:27 AM wrote: > > On 17. Jul 2024, at 22:00, Alan Somers wrote: > > > > On Sat, Jul 13, 2

Re: TCP Success Story (was Re: TCP_RACK, TCP_BBR, and firewalls)

> On 17. Jul 2024, at 22:00, Alan Somers wrote: > > On Sat, Jul 13, 2024 at 1:50 AM wrote: >> >>> On 13. Jul 2024, at 01:43, Alan Somers wrote: >>> >>> I've been experimenting with RACK and BBR. In my environment, they >>> can dramatically improve single-stream TCP performance, which is >>>

Re: TCP socket handling errors

> On 3. Apr 2024, at 19:46, Sad Clouds wrote: > > On Wed, 3 Apr 2024 17:28:52 +0200 > Michael Tuexen wrote: > >>> On 3. Apr 2024, at 15:44, Sad Clouds wrote: >>> >>> I found a bug that is still open from May 2010 and describes the same >>> behaviour that I see with my application: >>> >>> ht

Re: TCP socket handling errors

On Wed, 3 Apr 2024 17:28:52 +0200 Michael Tuexen wrote: > > On 3. Apr 2024, at 15:44, Sad Clouds wrote: > > > > I found a bug that is still open from May 2010 and describes the same > > behaviour that I see with my application: > > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=146845 >

Re: TCP socket handling errors

> On 3. Apr 2024, at 15:44, Sad Clouds wrote: > > I found a bug that is still open from May 2010 and describes the same > behaviour that I see with my application: > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=146845 > > If this hasn't been fixed over the last 14 years, then I guess I w

Re: TCP socket handling errors

I found a bug that is still open from May 2010 and describes the same behaviour that I see with my application: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=146845 If this hasn't been fixed over the last 14 years, then I guess I will add some code to simply ignore ECONNRESET on close(2) for

Re: tcp and udp traffic over IPv6 does not work from the latest e1000 git change 918c25677d

Hi Cheng, Have you applied https://reviews.freebsd.org/D41170? Can you also try 'ifconfig emXX -txcsum6' on the DUT? On Wed, Jul 26, 2023 at 12:37 PM Cheng Cui wrote: > > Hello Kevin, > > TCP and UDP traffic over IPv4 are working, but not over IPv6. > On a pair of FreeBSD 14.0-CURRENT nodes tha

Re: TCP connection ignore RST

> On 7. Sep 2021, at 11:47, Rozhuk Ivan wrote: > > On Tue, 7 Sep 2021 10:47:01 +0200 > Michael Tuexen wrote: > > I have strange case: FreeBSD 12.2 ignore TCP RST from windows host > and continue retransmitting packets. sockstat show that socket > connected even after many tcp rst pa

Re: TCP connection ignore RST

On Tue, 7 Sep 2021 10:47:01 +0200 Michael Tuexen wrote: > >>> I have strange case: FreeBSD 12.2 ignore TCP RST from windows host > >>> and continue retransmitting packets. sockstat show that socket > >>> connected even after many tcp rst packets received. > >>> > >>> Any ideas how to fix it?

Re: TCP connection ignore RST

> On 7. Sep 2021, at 04:10, Rozhuk Ivan wrote: > > On Sat, 4 Sep 2021 13:19:52 +0200 > Michael Tuexen wrote: > >>> On 4. Sep 2021, at 01:37, Rozhuk Ivan wrote: >>> >>> Hi! >>> >>> >>> I have strange case: FreeBSD 12.2 ignore TCP RST from windows host >>> and continue retransmitting packets.

Re: TCP connection ignore RST

> On 7 Sep 2021, at 04:11, Rozhuk Ivan wrote: > > On Sat, 4 Sep 2021 13:19:52 +0200 > Michael Tuexen wrote: > On 4. Sep 2021, at 01:37, Rozhuk Ivan wrote: >>> >>> Hi! >>> >>> >>> I have strange case: FreeBSD 12.2 ignore TCP RST from windows host >>> and continue retransmitting packe

Re: TCP connection ignore RST

On Sat, 4 Sep 2021 13:19:52 +0200 Michael Tuexen wrote: > > On 4. Sep 2021, at 01:37, Rozhuk Ivan wrote: > > > > Hi! > > > > > > I have strange case: FreeBSD 12.2 ignore TCP RST from windows host > > and continue retransmitting packets. sockstat show that socket > > connected even after many

Re: TCP connection ignore RST

04.09.2021 6:37, Rozhuk Ivan wrote: > Hi! > > > I have strange case: FreeBSD 12.2 ignore TCP RST from windows host and > continue retransmitting packets. > sockstat show that socket connected even after many tcp rst packets received. > > Any ideas how to fix it? First make sure your packet fil

Re: TCP connection ignore RST

> On 4. Sep 2021, at 01:37, Rozhuk Ivan wrote: > > Hi! > > > I have strange case: FreeBSD 12.2 ignore TCP RST from windows host and > continue retransmitting packets. > sockstat show that socket connected even after many tcp rst packets received. > > Any ideas how to fix it? Where is the trac

Re: TCP Connection hang - MSS again

> On 6. Apr 2021, at 19:02, Rodney W. Grimes > wrote: > >> 06.04.2021 19:54, Rodney W. Grimes wrote: 05.04.2021 19:44, Rozhuk Ivan wrote: >>> As I understand, in some cases remote host does not reply with MSS >>> option, and host behind router continue use mss 8960, that dropp

Re: TCP Connection hang - MSS again

> On 6. Apr 2021, at 19:02, Rodney W. Grimes > wrote: > >> 06.04.2021 19:54, Rodney W. Grimes wrote: 05.04.2021 19:44, Rozhuk Ivan wrote: >>> As I understand, in some cases remote host does not reply with MSS >>> option, and host behind router continue use mss 8960, that dropp

Re: TCP Connection hang - MSS again

> 06.04.2021 19:54, Rodney W. Grimes wrote: > >> 05.04.2021 19:44, Rozhuk Ivan wrote: > >> > > As I understand, in some cases remote host does not reply with MSS > > option, and host behind router continue use mss 8960, that dropped > > by router. > If the peer does not provide a

Re: TCP Connection hang - MSS again

06.04.2021 19:54, Rodney W. Grimes wrote: >> 05.04.2021 19:44, Rozhuk Ivan wrote: >> > As I understand, in some cases remote host does not reply with MSS > option, and host behind router continue use mss 8960, that dropped > by router. If the peer does not provide an MSS option,

Re: TCP Connection hang - MSS again

> 05.04.2021 19:44, Rozhuk Ivan wrote: > > >>> As I understand, in some cases remote host does not reply with MSS > >>> option, and host behind router continue use mss 8960, that dropped > >>> by router. > >> If the peer does not provide an MSS option, your local FreeBSD based > >> host should u

Re: TCP Connection hang - MSS again

05.04.2021 19:44, Rozhuk Ivan wrote: >>> As I understand, in some cases remote host does not reply with MSS >>> option, and host behind router continue use mss 8960, that dropped >>> by router. >> If the peer does not provide an MSS option, your local FreeBSD based >> host should use an MSS of n

Re: TCP Connection hang - MSS again

On Mon, 5 Apr 2021 13:04:19 +0200 tue...@freebsd.org wrote: > > As I understand, in some cases remote host does not reply with MSS > > option, and host behind router continue use mss 8960, that dropped > > by router. > If the peer does not provide an MSS option, your local FreeBSD based > host s

Re: TCP Connection hang - MSS again

> On 5. Apr 2021, at 11:44, Rozhuk Ivan wrote: > > Hi! > > > TCP Connection hang then I try to open > https://online.sberbank.ru/CSAFront/index.do#/ > > FreeBSD 13 desktop + FreeBSD 13 router (pf). > http://www.netlab.linkpc.net/download/software/os_cfg/FBSD/13/base/etc/sysctl.conf > FreeBSD

Re: TCP Connection hang - MSS again

On Mon, 5 Apr 2021 17:23:39 +0700 Eugene Grosbein wrote: > > Is any other other options to work around this? > > Yes. Each entry in the routing table has "mtu" attribute limiting TCP > MSS, too. You should use default route with -mtu 1500 attribute. For > example, in /etc/rc.conf: > > default

Re: TCP Connection hang - MSS again

05.04.2021 16:44, Rozhuk Ivan wrote: > Is any other other options to work around this? Yes. Each entry in the routing table has "mtu" attribute limiting TCP MSS, too. You should use default route with -mtu 1500 attribute. For example, in /etc/rc.conf: defaultroute="X.X.X.X -mtu 1500" _

Re: TCP Connection hang - MSS again

On Mon, 5 Apr 2021 12:44:50 +0300 Rozhuk Ivan wrote: > FreeBSD 13 desktop have no known problems with other websites. > Only with one remonte FreeBSD 12 with same sysctl.conf and mtu 9k. Forgot. FreeBSD 12 reply with MSS 8960, and I fix it in PF: > scrub in on $ext_v4_if0 all max-mss 1400 so o

Re: tcp-testsuite into src?

Kevin Bowling wrote this message on Mon, Mar 22, 2021 at 18:31 -0700: > I was talking with gnn and kevans on IRC about the tcp testsuite > (https://github.com/freebsd-net/tcp-testsuite). > > Currently we maintain this in ports, although the way the port is set > up doesn't make a lot of sense beca

Re: tcp-testsuite into src?

> On 23. Mar 2021, at 12:26, George Neville-Neil wrote: > > > > On 22 Mar 2021, at 22:45, Alan Somers wrote: > >> On Mon, Mar 22, 2021 at 7:31 PM Kevin Bowling >> wrote: >> >>> Hi, >>> >>> I was talking with gnn and kevans on IRC about the tcp testsuite >>> (https://github.com/freebsd-net/t

Re: tcp-testsuite into src?

> On 23. Mar 2021, at 03:45, Alan Somers wrote: > > On Mon, Mar 22, 2021 at 7:31 PM Kevin Bowling > wrote: > Hi, > > I was talking with gnn and kevans on IRC about the tcp testsuite > (https://github.com/freebsd-net/tcp-testsuite). > > Currently we maintain this in ports, although the way the

Re: tcp-testsuite into src?

> On 23. Mar 2021, at 02:31, Kevin Bowling wrote: > > Hi, > > I was talking with gnn and kevans on IRC about the tcp testsuite > (https://github.com/freebsd-net/tcp-testsuite). > > Currently we maintain this in ports, although the way the port is set > up doesn't make a lot of sense because

Re: tcp-testsuite into src?

On 22 Mar 2021, at 22:45, Alan Somers wrote: > On Mon, Mar 22, 2021 at 7:31 PM Kevin Bowling > wrote: > >> Hi, >> >> I was talking with gnn and kevans on IRC about the tcp testsuite >> (https://github.com/freebsd-net/tcp-testsuite). >> >> Currently we maintain this in ports, although the way t

Re: tcp-testsuite into src?

On Mon, Mar 22, 2021 at 7:31 PM Kevin Bowling wrote: > Hi, > > I was talking with gnn and kevans on IRC about the tcp testsuite > (https://github.com/freebsd-net/tcp-testsuite). > > Currently we maintain this in ports, although the way the port is set > up doesn't make a lot of sense because the

[RESOLVED] --was: Re: TCP 3-way-handshake fails

After router startup, its routingtable shows entries like this: 2a05:bec0:26:2::70 0c:c4:7a:ce:9e:90 UHLc 2a05:bec0:26:2::71 link#1 UHLc The 2nd one is an alias address for the 1st one (a jail). After ping6 from the router to this 2nd addres

Re: TCP Congestion Control

The per socket method is used at a large commercial CDN On Thu, Oct 24, 2019 at 12:30 AM vm finance wrote: > Ok - I see there is a socket option to pick a different cc per-socket > basis. > Any experiences on loading / using different cc per socket...does it work > seamlessly? > > Thanks! > > O

Re: TCP Congestion Control

On Wed, Oct 23, 2019 at 11:29:50PM -0700, vm finance wrote: > Ok - I see there is a socket option to pick a different cc per-socket > basis. > Any experiences on loading / using different cc per socket...does it work > seamlessly? I have not heard of any problems and have happily done recently:

Re: TCP Congestion Control

Ok - I see there is a socket option to pick a different cc per-socket basis. Any experiences on loading / using different cc per socket...does it work seamlessly? Thanks! On Wed, Oct 23, 2019 at 11:19 PM Kevin Oberman wrote: > Have you loaded kernel modules for other algorithms? I believe only

Re: TCP Congestion Control

Have you loaded kernel modules for other algorithms? I believe only newreno is in the default kernel. "man 4 mod_cc" for available modules and other information. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B3

Re: TCP-forwarding with netcat - weird failures ...

Hi Eugene, > Am 04.03.2019 um 12:21 schrieb Eugene Grosbein : > > 04.03.2019 17:43, Patrick M. Hausen wrote: > >> Needless to say: doesn’t work. And no, it’s not the obvious ARP caches. >> Connections can be established but then abort spontaneously without >> an observable pattern or reason. >

Re: TCP-forwarding with netcat - weird failures ...

04.03.2019 17:43, Patrick M. Hausen wrote: > Needless to say: doesn’t work. And no, it’s not the obvious ARP caches. > Connections can be established but then abort spontaneously without > an observable pattern or reason. Each "abort" of TCP connection has its own distinct reason: TCP FIN or TCP

Re: TCP Zero Window Advertisement.

On 07/18/17 at 11:28P, KVK Singh wrote: > Hi, > > By going through the Zero Window advertisement concept What I found is that > if sender has transmitted packet 2,3,4,5,6,7 i.e packet from 2-7 total 6 > packets in flight then By chance if sender received a Zero Window > Advertisement (ZWA) for s

Re: tcp between tap interfaces

On 11/12/2016 07:54, dkle...@phy.ucsf.edu wrote: I'm trying to setup a private testing environment using the bhyve hypervisor and some virtual machines connected with tap interfaces to a bridge. My network configuration for this environment looks like this: I have a bridge interface with 5 tap

Re: TCP stack lock contention with short-lived connections

Hi, On 7/14/16 7:38 PM, Julien Charbon wrote: > On 6/28/16 12:06 PM, Julien Charbon wrote: >> On 12/7/15 4:36 PM, Julien Charbon wrote: >>> On 30/05/14 06:12, k simon wrote: Does any plan commit and MFC to the 10-stable ? >>> >>> I got a bit of interest of having the performance improvem

Re: TCP route caching panic

On Thu, Oct 20, 2016 at 12:32:17AM -0500, Mike Karels wrote: M> > On Wed, Oct 19, 2016 at 07:26:44PM -0500, Mike Karels wrote: M> > M> > On Wed, Oct 19, 2016 at 02:29:14PM -0700, Gleb Smirnoff wrote: M> > M> > T> Hi! M> > M> > T> M> > M> > T> I got this panic in a bhyve VM, which was just comp

Re: TCP route caching panic

> On Wed, Oct 19, 2016 at 07:26:44PM -0500, Mike Karels wrote: > M> > On Wed, Oct 19, 2016 at 02:29:14PM -0700, Gleb Smirnoff wrote: > M> > T> Hi! > M> > T> > M> > T> I got this panic in a bhyve VM, which was just compiling stuff > M> > T> and had two ssh sessions open. It has static network c

Re: TCP route caching panic

On Wed, Oct 19, 2016 at 07:26:44PM -0500, Mike Karels wrote: M> > On Wed, Oct 19, 2016 at 02:29:14PM -0700, Gleb Smirnoff wrote: M> > T> Hi! M> > T> M> > T> I got this panic in a bhyve VM, which was just compiling stuff M> > T> and had two ssh sessions open. It has static network configuration

Re: TCP route caching panic

> On Wed, Oct 19, 2016 at 02:29:14PM -0700, Gleb Smirnoff wrote: > T> Hi! > T> > T> I got this panic in a bhyve VM, which was just compiling stuff > T> and had two ssh sessions open. It has static network configuration, > T> one interfaces, one IP address, IPv4 only and it sees only hardware >

Re: TCP route caching panic

On Wed, Oct 19, 2016 at 02:29:14PM -0700, Gleb Smirnoff wrote: T> Hi! T> T> I got this panic in a bhyve VM, which was just compiling stuff T> and had two ssh sessions open. It has static network configuration, T> one interfaces, one IP address, IPv4 only and it sees only hardware T> address of

Re: TCP stack lock contention with short-lived connections

Hi, On 6/28/16 12:06 PM, Julien Charbon wrote: > On 12/7/15 4:36 PM, Julien Charbon wrote: >> On 30/05/14 06:12, k simon wrote: >>> Does any plan commit and MFC to the 10-stable ? >> >> I got a bit of interest of having the performance improvements for >> short-lived TCP connections in 10-sta

Re: TCP stack lock contention with short-lived connections

Hi -net, On 12/7/15 4:36 PM, Julien Charbon wrote: > On 30/05/14 06:12, k simon wrote: >> Does any plan commit and MFC to the 10-stable ? > > I got a bit of interest of having the performance improvements for > short-lived TCP connections in 10-stable. Just to share the current > status to

Re: TCP packets Drop !!

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 04/05/16 06:26, shahzaib mushtaq wrote: > Here is the full output of netstat -s : > > http://pastebin.com/pyxDtJkL > > > > On Tue, Apr 5, 2016 at 3:38 PM, shahzaib mushtaq > wrote: > >> Hi Guys, >> >> Hopes i've landed on the correct foru

Re: TCP packets Drop !!

Here is the full output of netstat -s : http://pastebin.com/pyxDtJkL On Tue, Apr 5, 2016 at 3:38 PM, shahzaib mushtaq wrote: > Hi Guys, > > Hopes i've landed on the correct forum for tcp network queries. We've seen > tons of packets being dropped via command netstat -s in our production with

Re: tcp window scaling + syn cookies problem

On 2016-03-07 4:26 PM, Hooman Fazaeli wrote: Hi, In our network, Windows clients connect to internet via our custom developed transparent tcp proxy (running on 7.3). Things work fine, except that _sometimes_ downloads from the some windows clients become very slow. To debug the problem, we in

Re: tcp keep-alive message sent without timestamp option

On Thursday, 24 December 2015, Yongmin Cho wrote: > Hi, all. > > I have checked tcp keep-alive in freebsd head. > According to RFC7323, tcp timestamp option must be sent with > keep-alive packet after timestamp option has been negotiated. > So I have tested this on linux-3.13.0. > tcp keep-alive

Re: TCP regression between 288167 and 291456

+ net@ On 12/03/15 at 06:24P, Slawa Olhovchenkov wrote: > After upgrading STABLE to r291456 I am see bunch of sockets in > TIME_WAIT state. In normal situation I am expect about 30k-50k such > sockets. Now I am see all of net.inet.tcp.maxtcptw (440k currently). > Setting net.inet.tcp.msl to low val

Re: TCP stack lock contention with short-lived connections

Hi, On 30/05/14 06:12, k simon wrote: > Does any plan commit and MFC to the 10-stable ? I got a bit of interest of having the performance improvements for short-lived TCP connections in 10-stable. Just to share the current status to a wider audience: - I maintain a stack of our TCP perfor

Re: TCP notes and incast recommendations

On 11/26/15 at 05:57P, Matthew Macy wrote: > In an effort to be somewhat current on the state TCP I've collected a small > bibliography. This is beyond awesome! Thank you for this work. Cheers, Hiren pgpkKqeRjYvXJ.pgp Description: PGP signature

Re: TCP Initial Window 10 MFC

Resurrecting this old thread. On 04/23/15 at 01:29P, hiren panchasara wrote: > On 03/04/14 at 10:22P, hiren panchasara wrote: > > On Tue, Mar 4, 2014 at 7:38 PM, Lawrence Stewart > > wrote: > > > > > > > I lost the battle of wills on this topic and 10.0 shipped with IW10 > > > enabled by defau

Re: TCP Fast Open (RFC7413) for FreeBSD

> On Sep 2, 2015, at 12:21 PM, Rui Paulo wrote: > >> On Wed, 2015-09-02 at 01:30 -0400, Patrick Kelsey wrote: >> >> >> On Sep 2, 2015, at 12:54 AM, Rui Paulo wrote: On Tue, 2015-09-01 at 21:19 -0400, Patrick Kelsey wrote: Hi, About two weeks from now, I wil

Re: TCP Fast Open (RFC7413) for FreeBSD

On Wed, 2015-09-02 at 01:30 -0400, Patrick Kelsey wrote: > > > > > On Sep 2, 2015, at 12:54 AM, Rui Paulo wrote: > > > > > On Tue, 2015-09-01 at 21:19 -0400, Patrick Kelsey wrote: > > > Hi, > > > > > > About two weeks from now, I will be starting work on server-side > > > TCP > > > Fast > >

Re: TCP Fast Open (RFC7413) for FreeBSD

> On 2 Sep 2015, at 02:19, Patrick Kelsey wrote: > > Hi, > > About two weeks from now, I will be starting work on server-side TCP Fast > Open (TFO) support for FreeBSD head and stable/10, with the intention of > having patches up for review by November. This message is an attempt to > uncov

Re: TCP Fast Open (RFC7413) for FreeBSD

On 09/01/15 at 09:19P, Patrick Kelsey wrote: > Hi, > > About two weeks from now, I will be starting work on server-side TCP Fast > Open (TFO) support for FreeBSD head and stable/10, with the intention of > having patches up for review by November. Awesome! Looking forward to it. Cheers, Hiren

Re: TCP Fast Open (RFC7413) for FreeBSD

> On Sep 2, 2015, at 12:54 AM, Rui Paulo wrote: > >> On Tue, 2015-09-01 at 21:19 -0400, Patrick Kelsey wrote: >> Hi, >> >> About two weeks from now, I will be starting work on server-side TCP >> Fast >> Open (TFO) support for FreeBSD head and stable/10, with the intention >> of >> having p

Re: TCP Fast Open (RFC7413) for FreeBSD

On Tue, 2015-09-01 at 21:19 -0400, Patrick Kelsey wrote: > Hi, > > About two weeks from now, I will be starting work on server-side TCP > Fast > Open (TFO) support for FreeBSD head and stable/10, with the intention > of > having patches up for review by November. This message is an attempt > t

Re: tcp window scaling (rfc1323) problem

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 07/30/15 07:38, Hooman Fazaeli wrote: > Hi, > > We connect to the Internet through a TCP proxy running on FreeBSD > 8.3-RELEASE. Everything works except that instagram clients > frequently fail to get/refresh some images and feeds. I have > chec

Re: tcp window scaling (rfc1323) problem

On 07/30/15 at 07:08P, Hooman Fazaeli wrote: > Hi, > > We connect to the Internet through a TCP proxy running on FreeBSD 8.3-RELEASE. > Everything works except that instagram clients frequently fail to get/refresh > some images and feeds. I have checked anything that may be the cause of > problem

Re: TCP stack lock contention with short-lived connections

On 20/05/15 16:57, Adrian Chadd wrote: > On 20 May 2015 at 06:27, Julien Charbon wrote: >> On 26/05/14 15:36, Julien Charbon wrote: >> [...] >> >> For people interested about this short-lived TCP connection scalability >> effort, you can subscribe to the review of our latest (and biggest so >> fa

Re: TCP stack lock contention with short-lived connections

On 20 May 2015 at 06:27, Julien Charbon wrote: > > Hi, > > On 26/05/14 15:36, Julien Charbon wrote: >> On 23/05/14 23:37, Navdeep Parhar wrote: >>> On 05/23/14 13:52, Julien Charbon wrote: On 23/05/14 14:06, Julien Charbon wrote: > On 27/02/14 11:32, Julien Charbon wrote: >> On 07/11

Re: TCP stack lock contention with short-lived connections

Hi, On 26/05/14 15:36, Julien Charbon wrote: > On 23/05/14 23:37, Navdeep Parhar wrote: >> On 05/23/14 13:52, Julien Charbon wrote: >>> On 23/05/14 14:06, Julien Charbon wrote: On 27/02/14 11:32, Julien Charbon wrote: > On 07/11/13 14:55, Julien Charbon wrote: >> On Mon, 04 Nov 2013

Re: TCP Initial Window 10 MFC

On 03/04/14 at 10:22P, hiren panchasara wrote: > On Tue, Mar 4, 2014 at 7:38 PM, Lawrence Stewart wrote: > > > > I lost the battle of wills on this topic and 10.0 shipped with IW10 > > enabled by default :( > > > > As for having it configurable, it is a trivial patch which perhaps, > > Hiren, yo

Re: TCP Fast Open support

On Wed, Jan 21, 2015 at 01:54:16PM +, Sara Dickinson wrote: > Hi, > > I am an application developer and I’m interested in using TCP Fast Open, > which now has an Experimental RFC (https://datatracker.ietf.org/doc/rfc7413/ > ). IPv4 TFO has been avail

RE: TCP Fast Open support

Hi, I am an application developer and I’m interested in using TCP Fast Open, which now has an Experimental RFC (https://datatracker.ietf.org/doc/rfc7413/ ). IPv4 TFO has been available in the Linux kernel since 3.7 and is on by default in 3.13, IPv6 s

Re: TCP stack lock contention with short-lived connections

Hi, On 03/11/14 14:29, Julien Charbon wrote: > On 03/10/14 15:16, Julien Charbon wrote: >> On 23/05/14 14:06, Julien Charbon wrote: >>> On 27/02/14 11:32, Julien Charbon wrote: On 07/11/13 14:55, Julien Charbon wrote: > On Mon, 04 Nov 2013 22:21:04 +0100, Julien Charbon > wrote: >>

Re: TCP stack lock contention with short-lived connections

Great job. It would help me a lot. Simon 在 14/11/3 21:29, Julien Charbon 写道: Hi, On 03/10/14 15:16, Julien Charbon wrote: On 23/05/14 14:06, Julien Charbon wrote: On 27/02/14 11:32, Julien Charbon wrote: On 07/11/13 14:55, Julien Charbon wrote: On Mon, 04 Nov 2013 22:21:04 +0100, Julie

Re: TCP stack lock contention with short-lived connections

Hi, On 03/10/14 15:16, Julien Charbon wrote: > On 23/05/14 14:06, Julien Charbon wrote: >> On 27/02/14 11:32, Julien Charbon wrote: >>> On 07/11/13 14:55, Julien Charbon wrote: On Mon, 04 Nov 2013 22:21:04 +0100, Julien Charbon wrote: > I have put technical and how-to-repeat detai

Re: TCP stack lock contention with short-lived connections

Hi, On 23/05/14 14:06, Julien Charbon wrote: > On 27/02/14 11:32, Julien Charbon wrote: >> On 07/11/13 14:55, Julien Charbon wrote: >>> On Mon, 04 Nov 2013 22:21:04 +0100, Julien Charbon >>> wrote: I have put technical and how-to-repeat details in below PR: kern/183659: TCP stack

Re: TCP Rx window auto sizing relies on TCP timestamp option?

The TL;DR is - yes, I bet it'd be nice to have. :) -a On 12 August 2014 04:49, Vlad Zolotarov wrote: > > On Aug 11, 2014 8:06 PM, "John-Mark Gurney" > wrote: >> >> Vlad Zolotarov wrote this message on Mon, Aug 11, 2014 at 15:16 +0300: >> > Hi, I have the most strange

Re: TCP Rx window auto sizing relies on TCP timestamp option?

On Aug 11, 2014 8:06 PM, "John-Mark Gurney" > wrote: > > Vlad Zolotarov wrote this message on Mon, Aug 11, 2014 at 15:16 +0300: > > Hi, I have the most strange question about the TCP Rx window auto sizing > > implementation in a FreeBSD networking stack. > > When I lo

Re: TCP Rx window auto sizing relies on TCP timestamp option?

On Aug 11, 2014 8:40 PM, "hiren panchasara" wrote: > > On Mon, Aug 11, 2014 at 5:16 AM, Vlad Zolotarov > wrote: > > Hi, I have the most strange question about the TCP Rx window auto sizing > > implementation in a FreeBSD networking stack. > > When I looked at the FreeBSD code (hash > > 9abce0e567

Re: TCP Rx window auto sizing relies on TCP timestamp option?

On Mon, Aug 11, 2014 at 5:16 AM, Vlad Zolotarov wrote: > Hi, I have the most strange question about the TCP Rx window auto sizing > implementation in a FreeBSD networking stack. > When I looked at the FreeBSD code (hash > 9abce0e567c9a5a0520cdd94d5c633c7baf9a184) I noticed that > the mentioned abo

Re: TCP Rx window auto sizing relies on TCP timestamp option?

Vlad Zolotarov wrote this message on Mon, Aug 11, 2014 at 15:16 +0300: > Hi, I have the most strange question about the TCP Rx window auto sizing > implementation in a FreeBSD networking stack. > When I looked at the FreeBSD code (hash > 9abce0e567c9a5a0520cdd94d5c633c7baf9a184) I noticed that >

Re: TCP stack lock contention with short-lived connections

Hi Simon, On 30/05/14 06:12, k simon wrote: Does any plan commit and MFC to the 10-stable ? These patches are still under active review and testing, no plan to commit soon yet. As usual having more people testing these changes (and reporting found issues - or no issue) might accelerat

Re: TCP stack lock contention with short-lived connections

Hi, Does any plan commit and MFC to the 10-stable ? Regards Simon 于 14-5-29 0:42, Julien Charbon 写道: Hi, On 23/05/14 22:52, Julien Charbon wrote: On 23/05/14 14:06, Julien Charbon wrote: On 27/02/14 11:32, Julien Charbon wrote: On 07/11/13 14:55, Julien Charbon wrote: On Mon, 04 Nov

Re: TCP stack lock contention with short-lived connections

Hi, On 23/05/14 22:52, Julien Charbon wrote: On 23/05/14 14:06, Julien Charbon wrote: On 27/02/14 11:32, Julien Charbon wrote: On 07/11/13 14:55, Julien Charbon wrote: On Mon, 04 Nov 2013 22:21:04 +0100, Julien Charbon wrote: I have put technical and how-to-repeat details in below PR: ke

Re: TCP stack lock contention with short-lived connections

Hi Navdeep On 23/05/14 23:37, Navdeep Parhar wrote: On 05/23/14 13:52, Julien Charbon wrote: On 23/05/14 14:06, Julien Charbon wrote: On 27/02/14 11:32, Julien Charbon wrote: On 07/11/13 14:55, Julien Charbon wrote: On Mon, 04 Nov 2013 22:21:04 +0100, Julien Charbon wrote: I have put tec

Re: TCP stack lock contention with short-lived connections

On 05/23/14 13:52, Julien Charbon wrote: > > Hi, > > On 23/05/14 14:06, Julien Charbon wrote: >> On 27/02/14 11:32, Julien Charbon wrote: >>> On 07/11/13 14:55, Julien Charbon wrote: On Mon, 04 Nov 2013 22:21:04 +0100, Julien Charbon wrote: > I have put technical and how-to-repeat

Re: TCP stack lock contention with short-lived connections

Hi, On 27/02/14 11:32, Julien Charbon wrote: On 07/11/13 14:55, Julien Charbon wrote: On Mon, 04 Nov 2013 22:21:04 +0100, Julien Charbon wrote: I have put technical and how-to-repeat details in below PR: kern/183659: TCP stack lock contention with short-lived connections http://www.freebsd

Re: TCP packets remain unsent

On Sat, 29 Mar 2014 15:02:29 +0100, Willy Offermans wrote: > Dear FreeBSD friends, > > On Fri, Mar 28, 2014 at 05:25:54PM +0100, Willy Offermans wrote: > > Dear FreeBSD friends, > > > > I have a problem with my relatively new FreeBSD server. I came across the > > problem when sending e-mai

Re: TCP packets remain unsent

Dear FreeBSD friends, On Fri, Mar 28, 2014 at 05:25:54PM +0100, Willy Offermans wrote: > Dear FreeBSD friends, > > I have a problem with my relatively new FreeBSD server. I came across the > problem when sending e-mails of larger size and copying files with scp. > The e-mails were not sent out be

Re: TCP stack lock contention with short-lived connections

Hi John, On 07/03/14 13:43, Julien Charbon wrote: On 06/03/14 22:57, John-Mark Gurney wrote: Julien Charbon wrote this message on Thu, Feb 27, 2014 at 11:32 +0100: [...] Any thoughts on this particular behavior? One thing that I noticed is that you now lock/unlock the tw and inp lock a l

  1   2   3   4   5   6   >