Page MenuHomeFreeBSD

transportUmbrella
ActivePublic

Recent Activity

Fri, Jul 17

neel_neelc.org added a comment to D25681: if_spppsubr: Define a few LCP options, Recognize (but still reject) multilink PPP config options.

ce(4) for PCI G.703/E1 card,
cp(4) for PCI V.35/RS-232/RS-530/RS-449/X.21/G.703/E1/E3/T3/STS-1 cards,
and cx(4)/ctau(4) for some ISA cards but these do not exist in FreeBSD 13 anymore,
removed by emaste@ recently.

Both ce(4) and cp(4) are i386-only drivers at present.

Such synchronous lines are still in use (here):

  • G.703 is common in phone systems.
  • X.21 for leased lines (with old contracts),
  • E1/E3 for SDH (carrier grade) leases lines.
  • RS-232 is the ordinary serial port, the other RS- are industry specific serials (mainly other voltages)

But you are right: Do we really need a specialized PPP hardware support these days?
Do we really want to run a recent kernel on this antique hardware? It would be a sacrilege.

Normal PPP over serial lines (currently available) does work using ppp(4)

Fri, Jul 17, 1:07 AM · network, transport

Thu, Jul 16

lutz_donnerhacke.de added a comment to D25681: if_spppsubr: Define a few LCP options, Recognize (but still reject) multilink PPP config options.

ce(4) for PCI G.703/E1 card,
cp(4) for PCI V.35/RS-232/RS-530/RS-449/X.21/G.703/E1/E3/T3/STS-1 cards,
and cx(4)/ctau(4) for some ISA cards but these do not exist in FreeBSD 13 anymore,
removed by emaste@ recently.

Both ce(4) and cp(4) are i386-only drivers at present.

Thu, Jul 16, 7:12 AM · network, transport
eugen_grosbein.net abandoned D25681: if_spppsubr: Define a few LCP options, Recognize (but still reject) multilink PPP config options.
Thu, Jul 16, 6:32 AM · network, transport
eugen_grosbein.net updated subscribers of D25681: if_spppsubr: Define a few LCP options, Recognize (but still reject) multilink PPP config options.

Sorry for the mess, my latest actions on this differential were unintentional, some problems with old Firefox.

Thu, Jul 16, 6:32 AM · network, transport
eugen_grosbein.net reclaimed D25681: if_spppsubr: Define a few LCP options, Recognize (but still reject) multilink PPP config options.
Thu, Jul 16, 6:26 AM · network, transport
eugen_grosbein.net commandeered D25681: if_spppsubr: Define a few LCP options, Recognize (but still reject) multilink PPP config options.
Thu, Jul 16, 6:25 AM · network, transport
eugen_grosbein.net updated subscribers of D25681: if_spppsubr: Define a few LCP options, Recognize (but still reject) multilink PPP config options.

CCing Roman Kurakin (ce(4)) and Serge Vakulenko (cp(4)), see later.

Thu, Jul 16, 6:19 AM · network, transport
neel_neelc.org abandoned D25681: if_spppsubr: Define a few LCP options, Recognize (but still reject) multilink PPP config options.
Thu, Jul 16, 2:23 AM · network, transport
neel_neelc.org added a comment to D25681: if_spppsubr: Define a few LCP options, Recognize (but still reject) multilink PPP config options.

In case anybody is wondering, the source of the commit is here: https://freshbsd.org/commit/netbsd/src/hRr2tvIj1vj7QI2C

Thu, Jul 16, 2:12 AM · network, transport
neel_neelc.org requested review of D25681: if_spppsubr: Define a few LCP options, Recognize (but still reject) multilink PPP config options.
Thu, Jul 16, 2:12 AM · network, transport

Jul 7 2020

chengc_netapp.com added a member for transport: chengc_netapp.com.
Jul 7 2020, 1:54 PM

Jun 25 2020

markj closed D24011: ipfw: Support [w:x:y::z]:port (bracketed) IPv6 addresses in the fwd command.
Jun 25 2020, 7:27 PM · transport, network
markj accepted D24011: ipfw: Support [w:x:y::z]:port (bracketed) IPv6 addresses in the fwd command.
Jun 25 2020, 6:02 PM · transport, network
neel_neelc.org updated the diff for D24011: ipfw: Support [w:x:y::z]:port (bracketed) IPv6 addresses in the fwd command.

Good catch on the tidbits, here's an revised patch.

Jun 25 2020, 4:12 PM · transport, network
markj accepted D24011: ipfw: Support [w:x:y::z]:port (bracketed) IPv6 addresses in the fwd command.

This looks ok to me modulo the nits I pointed out.

Jun 25 2020, 3:50 PM · transport, network
lutz_donnerhacke.de added inline comments to D24011: ipfw: Support [w:x:y::z]:port (bracketed) IPv6 addresses in the fwd command.
Jun 25 2020, 6:38 AM · transport, network

Jun 24 2020

neel_neelc.org updated the diff for D24011: ipfw: Support [w:x:y::z]:port (bracketed) IPv6 addresses in the fwd command.

Made the corrections.

Jun 24 2020, 5:54 PM · transport, network
markj added inline comments to D24011: ipfw: Support [w:x:y::z]:port (bracketed) IPv6 addresses in the fwd command.
Jun 24 2020, 5:15 PM · transport, network
allanjude added reviewers for D24011: ipfw: Support [w:x:y::z]:port (bracketed) IPv6 addresses in the fwd command: thj, markj.
Jun 24 2020, 4:33 PM · transport, network
markj closed D24403: ipfw(8): In fill_ip6(), use a single statement for both "me" and "me6".
Jun 24 2020, 3:06 PM · transport, network
neel_neelc.org reclaimed D24403: ipfw(8): In fill_ip6(), use a single statement for both "me" and "me6".
Jun 24 2020, 3:02 PM · transport, network
neel_neelc.org abandoned D24403: ipfw(8): In fill_ip6(), use a single statement for both "me" and "me6".
Jun 24 2020, 2:26 PM · transport, network

Jun 23 2020

neel_neelc.org added a project to D24011: ipfw: Support [w:x:y::z]:port (bracketed) IPv6 addresses in the fwd command: transport.
Jun 23 2020, 8:47 PM · transport, network
neel_neelc.org added a project to D24403: ipfw(8): In fill_ip6(), use a single statement for both "me" and "me6": transport.
Jun 23 2020, 8:46 PM · transport, network

Jan 20 2020

rscheff requested changes to D4294: modernize TCP constants.
Jan 20 2020, 6:42 PM · transport

Jan 16 2020

rscheff added a member for transport: rscheff.
Jan 16 2020, 4:17 PM

Dec 31 2019

melifaro added a member for transport: melifaro.
Dec 31 2019, 5:59 PM

Sep 30 2019

lutz_donnerhacke.de added a member for transport: lutz_donnerhacke.de.
Sep 30 2019, 7:35 AM

May 9 2019

tuexen closed D17614: RFC6582 - prevent cwnd to collapse down to 1 mss after exiting recovery.
May 9 2019, 7:11 AM · transport

Apr 25 2019

rscheff added a comment to D17614: RFC6582 - prevent cwnd to collapse down to 1 mss after exiting recovery.

Lawrence reviewed this during IETF104, Michael volunteered to follup up with the full commit process.

Apr 25 2019, 2:15 PM · transport

Apr 24 2019

scottl removed a member for transport: scottl.
Apr 24 2019, 3:29 PM

Mar 28 2019

lstewart accepted D17614: RFC6582 - prevent cwnd to collapse down to 1 mss after exiting recovery.
Mar 28 2019, 1:58 PM · transport

Feb 15 2019

lohithbsd_gmail.com added a member for transport: lohithbsd_gmail.com.
Feb 15 2019, 10:48 PM

Feb 5 2019

rscheff updated the diff for D17614: RFC6582 - prevent cwnd to collapse down to 1 mss after exiting recovery.
  • prepare to land
Feb 5 2019, 7:51 PM · transport
rscheff added a comment to D17614: RFC6582 - prevent cwnd to collapse down to 1 mss after exiting recovery.

Over the last two or three weeks, we have run a large number of performance regression tests including this patch, in particular again workloads with frequent app-stalls (no additional data to send for about an RTO interval). That type of workload very often causes burst to be transmitted, including self-inflicted packet drops.

Feb 5 2019, 1:01 PM · transport

Jan 31 2019

chengc_netapp.com accepted D17614: RFC6582 - prevent cwnd to collapse down to 1 mss after exiting recovery.

Looks good. I think Richard can update more that we recently tested this patch.

Jan 31 2019, 4:59 PM · transport

Jan 24 2019

rscheff added a comment to D17614: RFC6582 - prevent cwnd to collapse down to 1 mss after exiting recovery.

Looking at D8225, that all seems to be code while in loss recovery. This patch is to restore a sane minimum cwnd once exiting loss recovery - so I don't see how these would be directly related.

Jan 24 2019, 10:16 PM · transport
kbowling added a comment to D17614: RFC6582 - prevent cwnd to collapse down to 1 mss after exiting recovery.

I remember we tried to analyze and improve this and found some unintended consequences between @hiren and @lstewart https://reviews.freebsd.org/D8225 so it got backed out. @lstewart do you remember the details for backing it out?

Jan 24 2019, 9:25 PM · transport

Jan 18 2019

rscheff updated the diff for D17614: RFC6582 - prevent cwnd to collapse down to 1 mss after exiting recovery.
  • fixing trailing whitespaces
Jan 18 2019, 3:22 PM · transport
rscheff updated the diff for D17614: RFC6582 - prevent cwnd to collapse down to 1 mss after exiting recovery.
  • remove siftr patch
Jan 18 2019, 3:19 PM · transport
rscheff updated the diff for D17614: RFC6582 - prevent cwnd to collapse down to 1 mss after exiting recovery.
  • fixing trailing whitespaces
Jan 18 2019, 3:14 PM · transport
rscheff added a comment to D17614: RFC6582 - prevent cwnd to collapse down to 1 mss after exiting recovery.

Here is the output of the now functional siftr, without and with the patch;

Jan 18 2019, 12:09 PM · transport

Jan 16 2019

rscheff added a comment to D17614: RFC6582 - prevent cwnd to collapse down to 1 mss after exiting recovery.

I have been testing this patch against a stable/11 build. Over a 1Gb/s link with emulated 40ms RTT and (10^-4) loss rate, I use iperf from a FreeBSD node to send traffic to a 4.15.0-39-generic Ubuntu16.04 client.

[...]

Using siftr, I still see the single MSS cwnd, and sometimes with a 40ms delay to update a second cwnd. The full cwnd log is attached.

The congestion control in use is newreno.

timestamp cwnd ssthresh
...
1.92838096618652 115052 70875
1.92838382720947 1448 56940 <<< single MSS
1.96786689758301 2896 56940 <<< 40ms delay
1.96786999702454 4344 56940
1.96787786483765 5792 56940
1.96788096427917 7240 56940

Jan 16 2019, 12:08 AM · transport

Jan 15 2019

chengc_netapp.com added a comment to D17614: RFC6582 - prevent cwnd to collapse down to 1 mss after exiting recovery.

I have been testing this patch against a stable/11 build. Over a 1Gb/s link with emulated 40ms RTT and (10^-4) loss rate, I use iperf from a FreeBSD node to send traffic to a 4.15.0-39-generic Ubuntu16.04 client.

Jan 15 2019, 8:54 PM · transport

Jan 3 2019

rscheff added a comment to D17614: RFC6582 - prevent cwnd to collapse down to 1 mss after exiting recovery.

Attached is a tcptrace of a real-world observed issue, where the lack of RFC6582 results in cwnd shrinking down to 1 MSS, followed by delayed ACK timeout and congestion avoidance growth of cwnd (1 MSS per RTT).

Jan 3 2019, 9:09 AM · transport

Jan 2 2019

chengc_netapp.com added a comment to D17614: RFC6582 - prevent cwnd to collapse down to 1 mss after exiting recovery.

Thanks for the review request.
I will test this patch in Emulab.net before I give more feedback.

Jan 2 2019, 3:04 PM · transport

Dec 18 2018

rscheff added a comment to D17614: RFC6582 - prevent cwnd to collapse down to 1 mss after exiting recovery.

This packetdrill script should complete without error, when IW10 and the above patch are applied, for a SACK session, or non-SACK session.

Dec 18 2018, 4:15 PM · transport

Dec 15 2018

rscheff updated the diff for D17614: RFC6582 - prevent cwnd to collapse down to 1 mss after exiting recovery.

Minor comment edit
and moving to GIT/Phabricator/ARC workflow

Dec 15 2018, 8:40 PM · transport

Nov 29 2018

rscheff added a reviewer for D17614: RFC6582 - prevent cwnd to collapse down to 1 mss after exiting recovery: chengc_netapp.com.
Nov 29 2018, 10:33 PM · transport
rscheff added reviewers for D17614: RFC6582 - prevent cwnd to collapse down to 1 mss after exiting recovery: tuexen, rrs, hiren.
Nov 29 2018, 10:08 PM · transport