Page MenuHomeFreeBSD

transportUmbrella
ActivePublic

Recent Activity

Jun 29 2022

chris_cretaforce.gr added a watcher for transport: chris_cretaforce.gr.
Jun 29 2022, 9:47 PM

Jan 27 2022

gnn removed a member for transport: gnn.
Jan 27 2022, 3:56 PM

Jun 11 2021

heliocentric_gmail.com added a watcher for transport: heliocentric_gmail.com.
Jun 11 2021, 12:32 AM

Mar 17 2021

cy added a member for transport: cy.
Mar 17 2021, 2:15 PM

Jan 24 2021

donner removed a member for transport: donner.
Jan 24 2021, 10:21 PM

Jul 17 2020

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

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)

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

Jul 16 2020

donner 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.

Jul 16 2020, 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.
Jul 16 2020, 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.

Jul 16 2020, 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.
Jul 16 2020, 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.
Jul 16 2020, 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.

Jul 16 2020, 6:19 AM · network, transport
nc abandoned D25681: if_spppsubr: Define a few LCP options, Recognize (but still reject) multilink PPP config options.
Jul 16 2020, 2:23 AM · network, transport
nc 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

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

Jul 7 2020

cc added a member for transport: cc.
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
nc 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
donner 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

nc 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
nc reclaimed D24403: ipfw(8): In fill_ip6(), use a single statement for both "me" and "me6".
Jun 24 2020, 3:02 PM · transport, network
nc 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

nc 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
nc 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

donner added a member for transport: donner.
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

cc 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.
In D17614#402480, @chengc_netapp.com wrote:

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

cc 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