Re: vnet with interfaces

2024-03-28 Thread Tom Jones 



On Tue, Mar 26, 2024, at 18:31, Benoit Chesneau wrote:
> How does work VNET with interfaces? Is this as efficient as using pci 
> passtrough in a vm ? 

Overhead should be minimal, while the device is logically missing from the 
default vnet there isn't any more "in the way" for actual usage. Marco's paper 
might be a good starting point for further digging: 
https://papers.freebsd.org/2003/zec-vimage/

Tom

CFT: VPP on FreeBSD

2024-02-12 Thread Tom Jones 
Hi freebsd-net,

I have been working for the last few months of porting VPP to FreeBSD and this 
work is now ready for very early testing. This porting work is sponsored by the 
FreeBSD Foundation in partnership with RG Nets.

If you would like to experiment with VPP on FreeBSD then you can work from my 
freebsd-vpp branch available here: 
https://github.com/adventureloop/vpp/tree/freebsd-vpp

The README.freebsd offers a walk through of build and configuration based on 
the configuration of my bhyve test machine.
The port has been tested in bhyve with virtio interfaces and on real hardware 
using Chelsio T62100-LP-CR 100Gbit NICs.

With this branch you should be able to launch VPP and configure it to run as a 
router on FreeBSD CURRENT and 14 using both DPDK and netmap.

This branch represents my upstreaming queue of changes heading towards VPP and 
some FreeBSD specific patches required to build and run right now which I 
expect not to need in the future.

If you test and encounter issues or want to get in touch I’m happy to receive 
bug reports via that issues on that github repo or directly via email to 
t...@freebsd.org.

I’m looking forward to hearing the exciting ways this breaks and the VPP 
configurations that FreeBSD users expect to be available.

Thanks

Tom

Re: where is happening the development of vpp of freebsd?

2024-02-03 Thread Tom Jones 



On Sat, Feb 3, 2024, at 20:20, Benoit Chesneau wrote:
> I there any public source repository for the development of VPP on 
> FreeBSD? Any link to follow? 
>
> Benoît

I’m working to upstream changes right now and plan to start a development 
branch early next week.

- Tom

Re: Too aggressive TCP ACKs

2022-10-26 Thread Tom Jones 
On Wed, Oct 26, 2022 at 02:55:21PM +0200, tue...@freebsd.org wrote:
> > On 26. Oct 2022, at 10:57, Tom Jones  wrote:
> > 
> > On Sat, Oct 22, 2022 at 12:14:25PM +0200, Hans Petter Selasky wrote:
> >> Hi,
> >> 
> >> Some thoughts about this topic.
> >> 
> >> Delaying ACKs means loss of performance when using Gigabit TCP 
> >> connections in data centers. There it is important to ACK the data as 
> >> quick as possible, to avoid running out of TCP window space. Thinking 
> >> about TCP connections at 30 GBit/s and above!
> >> 
> >> I think the implementation should be exactly like it is.
> >> 
> >> There is a software LRO in FreeBSD to coalesce the ACKs before they hit 
> >> the network stack, so there are no real problems there.
> >> 
> > 
> > Changing the ACK ratio seems to be okay in most cases, a paper I wrote
> > about this was published this week:
> > 
> > https://onlinelibrary.wiley.com/doi/10.1002/sat.1466
> > 
> > It focuses on QUIC, but congestion control dynamics don't change with
> > the protocol. You should be able to read there, but if not I'm happy to
> > send anyone a pdf.
> Is QUIC using an L=2 for ABC?

I think that is the rfc recommendation, actual deployed reality is more
scattershot.

- Tom

Re: Too aggressive TCP ACKs

2022-10-26 Thread Tom Jones 
On Sat, Oct 22, 2022 at 12:14:25PM +0200, Hans Petter Selasky wrote:
> Hi,
> 
> Some thoughts about this topic.
> 
> Delaying ACKs means loss of performance when using Gigabit TCP 
> connections in data centers. There it is important to ACK the data as 
> quick as possible, to avoid running out of TCP window space. Thinking 
> about TCP connections at 30 GBit/s and above!
> 
> I think the implementation should be exactly like it is.
> 
> There is a software LRO in FreeBSD to coalesce the ACKs before they hit 
> the network stack, so there are no real problems there.
> 

Changing the ACK ratio seems to be okay in most cases, a paper I wrote
about this was published this week:

https://onlinelibrary.wiley.com/doi/10.1002/sat.1466

It focuses on QUIC, but congestion control dynamics don't change with
the protocol. You should be able to read there, but if not I'm happy to
send anyone a pdf.

- Tom

Re: TCP Congestion Control

2019-10-24 Thread Tom Jones 
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:

$ iperf3 -c host -C cubic



- [tj]
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: kernel: in6_delayed_cksum: delayed m_pullup

2018-05-10 Thread Tom Jones 
On Mon, Apr 30, 2018 at 09:54:48AM +0200, Dries Michiels wrote:
> 
> Tom,
> 
> I’m using the igb (intel I210) driver for my LAN interface and the em
> (intel I219-V) driver for the WAN interface.  I use this FreeBSD box
> as my home server so I wouldn’t say that it has a heavy ipv6 workload.
> 

Hi Dries,

Does this bug persist on later snapshots? Or have you stayed with the
same one from the original question?

Could you send me the ifconfig flags lines for igb0 and em0?

like this

$ ifconfig em0
em0: flags=8943 metric 0 mtu 
1500
options=40098

$ ifconfig igb0
igb0: flags=8843 metric 0 mtu 1500

options=6403bb
 


My em interfaces don't have flags for ipv6 checksum offload, I suspect
the issue is from the em side of your network. 

I have tried moving 100GB of v6 tcp through each interface with iperf3
to see if I could stimulate the bug, but no luck so far. I will leave
the test box sitting exposed to my network for a while.

- [tj]
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: Bug: Newreno; Seems Memory leak in newreno_cb_init

2018-05-08 Thread Tom Jones 
On Tue, May 08, 2018 at 05:14:49PM +0530, Harsh Jain wrote:
> Hi All,
> 
> We have observed memory leak with TCP network traffic in "newreno".
> 
> Output of vmstat -m
> 
>    in_mfilter 3 3K   -    3  1024
>  in_multi 4 1K   -    4  256
>   ip_moptions 6 1K   -    6  64,256
> encap_export_host 2 2K   -    2  1024
>  newreno data 394849273 6169520K   - 394849273  16
>     sctp_a_it 0 0K   -    5  16
>  sctp_vrf 1 1K   -    1  64
>  sctp_ifa 7 1K   -    7  128
>  sctp_ifn 4 1K   -    4  128
> 
> There is 1 malloc in "newreno_cb_init" whose pointer is not saved in any 
> global structure to free the same.
> 
> Is this a BUG?


Hi Harsh,

Adding Lawrence in cc

It looks like it, running nc in a loop I can watch MemUse grow. 

I think this should address the leak

https://reviews.freebsd.org/D15358

- [tj]
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: kernel: in6_delayed_cksum: delayed m_pullup

2018-04-29 Thread Tom Jones 
On Sun, Apr 29, 2018 at 08:30:28PM +0200, Dries Michiels wrote:
> Dear mailing list,
> 
> After upgrading my FreeBSD server from source from:
> FreeBSD 11.1-STABLE (VADOS) #9 r331859: Sun Apr  1 12:09:18 CEST 2018 
> to
> FreeBSD 11.2-PRERELEASE (VADOS) #10 r333091: Sun Apr 29 16:48:44 CEST 2018
> 
> My /var/log/messages is getting spammed by the following notice/error:
> Apr 29 19:51:42 vados kernel: in6_delayed_cksum: delayed m_pullup, m->len: 48 
> plen 68 off 56 csum_flags=400
> Apr 29 19:55:34 vados last message repeated 11 times
> Apr 29 20:11:56 vados last message repeated 10 times
> Apr 29 20:12:42 vados last message repeated 4 times
> 
> Does anyone have a clue what this indicates?

An error it seems:

 if (offset + sizeof(u_short) > m->m_len) {
 printf("%s: delayed m_pullup, m->len: %d plen %u off %u "
 "csum_flags=%b\n", __func__, m->m_len, plen, offset,
 (int)m->m_pkthdr.csum_flags, CSUM_BITS);
 /*
  * XXX this should not happen, but if it does, the correct
  * behavior may be to insert the checksum in the appropriate
  * next mbuf in the chain.
  */
 return;
 }

> I did not have this message on my older system (r331859).

What network hardware are you using? 

Do you have a heavy ipv6 workload that might be a source?

- [tj]
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: QOS/TOS in carp/freebsd in general

2018-04-16 Thread Tom Jones 
On Sun, Apr 15, 2018 at 04:30:45PM -0400, Nick Wolff wrote:
>  Hi,
> 
> I currently have a review in to make carp use dscp values on outgoing
> packets. This will make it easier to preform QOS on modern switches as we
> have been able to drive carp insane on 10g links while throwing storage
> traffic at it.On an interesting side note apparently after 64k mac address
> moves for a single mac address in the cam table arista 7050t  seems to with
> out warning give up and stop moving address but leaves it in the table
> where ever it last was.
> 
> I was originally going to just toggle between cs7 and the old TOS low delay
> setting. But it was requested that I just make it a settable Integer value.
> In this case I'm planning to do 0-63 to match dscp with a default of 54
> (CS7) (Network Control) but you could still set the old value by setting
> the sysctl to 4. Anything larger then 64 would be truncated as two shifts
> are needed to align with the field leading.
> 
> Does anybody do anything anywhere with the old TOS values like low delay in
> there networking infrastructure? Should this be updated in other places in
> kernel and userland? It's been 20 years since TOS was deprecated and
> replaced with DSCP.
> 
> Any other comments or thought are always welcome.

I cannot speak to network stacks, but we have performed some large scale
DSCP measurements of the Internet and found TOS semantics still in use.
You might want to look up:

Exploring DSCP modification pathologies in mobile edge networks: IEEE/IFIP 
Workshop on Mobile Network Measurement 

I think there is more work in line to be published based on similar
measurement campaigns.

> References:
> 
> Open Review - https://reviews.freebsd.org/D14536
> General DSCP reference - https://www.tucny.com/Home/dscp-tos
> 
> 
> Thanks,
> 
> Nick "darkfiberiru" Wolff
> ___
> freebsd-net@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

-- 
- [tj]
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: Congestion Control Modification

2015-04-18 Thread Tom Jones 
On Sat, Apr 18, 2015 at 09:59:01AM +0300, Karlis Laivins wrote:
 Hello,
 
 I have read an interesting publication about a proposed modification of TCP
 Congestion Control algorithm that would allow to improve it (the CC) by
 dynamic bandwidth estimation. The idea seems so interesting that I would
 like to try to implement it by modifying the NewReno code.

What are you trying to implement? There might already be an out of tree
implementation.

 Do I understand correctly that to do the above stated, I would create a
 copy of source file (in my case - cc_newreno.c) located in /usr/src/sys/
 and rename it to, for example, cc_newreno_test.c and make changes to it?
 How would I then compile it, and how would I create a newreno_test.ko file
 that can be loaded into Kernel and tested?

There is quite a bit of documentation for the modular congestion control
framework[0][1] in the man pages. I think you can actually build the cc as a
kernel module and use kldload, this is how we did our initial implementation of
NewCWV on Linux at $work.

You can build and work on kernel modules out of tree, this tutorial[2] is a
reasonable introduction.

[0]: https://www.freebsd.org/cgi/man.cgi?query=mod_cc
[1]: 
https://www.freebsd.org/cgi/man.cgi?query=mod_ccsektion=9apropos=0manpath=FreeBSD+10.1-RELEASE
[2]: 
http://www.freesoftwaremagazine.com/articles/writing_a_kernel_module_for_freebsd

-- 
Tom
@adventureloop
adventurist.me

'You realize night time makes up half of all time?'
:wq


pgpXeFdn2tlQY.pgp
Description: PGP signature

Re: TCP Fast Open support

2015-01-21 Thread Tom Jones 
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/
 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 server support
 is in 3.16. I am trying to find out if TFO is likely to be supported on
 FreeBSD? Is there any interest in this?

You have voiced interest so that is the first step towards. Depending on how
things go in $work in the next month I will start looking at an implementation.

There are three experimental TCP modifications (NewCWV[1], PRR[2], TCP
Stealth[3]) that have implementations, but have not seen any discussion. These
are only the ones I know of, there might be others. 

These patches didn't really get any discussion, this makes me reluctant to put
time into an implementation if it is just going to go stale on the list.

[1]:https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191520
[2]:
http://freebsd.1045724.n5.nabble.com/Patches-for-RFC6937-and-draft-ietf-tcpm-newcwv-00-td5882835.html
[3]:https://gnunet.org/sites/default/files/tcp_stealth_freebsd_10_0_0.diff

-- 
Tom
@adventureloop
adventurist.me

:wq
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

Re: Patches for RFC6937 and draft-ietf-tcpm-newcwv-00

2014-09-08 Thread Tom Jones 
Hi Folks,


On Thu, Aug 28, 2014 at 12:39:09PM -0400, George Neville-Neil wrote:
 Adrian,
 
 Can you put this into a Phabricator for review?
 
 Lars,
 
 How have you been testing this?

Did the newcwv patch make its way into Phabricator? I don't think I would have
seen if it did.

 
 On 27 Aug 2014, at 4:01, Eggert, Lars wrote:
 
  Yep
 
  On 2014-8-27, at 9:53, Adrian Chadd adr...@freebsd.org wrote:
 
  Ok. Is it the same patch you sent out in Feb?
 
 
  -a
 
 
  On 27 August 2014 00:43, Eggert, Lars l...@netapp.com wrote:
  Not as far as I know.
 
  Lars
 
  On 2014-8-27, at 9:39, Adrian Chadd adr...@freebsd.org wrote:
 
  Is there a PR for it?
 
 
  -a
 
 
  On 27 August 2014 00:23, Eggert, Lars l...@netapp.com wrote:
  It would be great if people could also review Aris' PRR patch - RFC6937 
  has been out for a while.
 
  Lars
 
 
 
 
  On 2014-8-26, at 20:09, Adrian Chadd adr...@freebsd.org wrote:
 
  Hi!
 
  I'm going to merge Tom's work in a week unless someone gives me a
  really good reason not to.
 
  I think there's been enough work and discussion about it since the
  first post from Lars in Feburary and enough review opportunity.
 
 
  -a
 
 
  On 26 August 2014 07:55, Tom Jones jo...@sdf.org wrote:
  On Tue, Aug 26, 2014 at 02:43:49PM +, Eggert, Lars wrote:
  Hi,
 
  the newcwv patch is probably stale now with Tom Jones' recent patch 
  based on
  a more up-to-date version of the Internet-Draft, but the PRR patch 
  should
  still be useful?
 
  My newcwv patch is much more up to date than Aris's, but it is 
  slightly
  different in implementation. I have had a few suggestions from 
  Adrian, but he
  couldn't comment on how it relates to the tcp internals.
 
  There is a PR: 
  https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191520
 
  The biggest difference in structure between mine and Aris's patch is 
  the use of
  tcp timers. It would be good to hear if my approach or Aris's is 
  prefered.
 
  On 2014-6-19, at 23:35, George Neville-Neil g...@neville-neil.com 
  wrote:
 
  On 4 Feb 2014, at 1:38, Eggert, Lars wrote:
 
  Hi,
 
  below are two patches that implement RFC6937 (Proportional Rate 
  Reduction for TCP) and draft-ietf-tcpm-newcwv-00 (Updating TCP 
  to support Rate-Limited Traffic). They were done by Aris 
  Angelogiannopoulos for his MS thesis, which is at 
  https://eggert.org/students/angelogiannopoulos-thesis.pdf.
 
  The patches should apply to -CURRENT as of Sep 17, 2013. (Sorry 
  for the delay in sending them, we'd been trying to get some 
  feedback from committers first, without luck.)
 
  Please note that newcwv is still a work in progress in the IETF, 
  and the patch has some limitations with regards to the pipeACK 
  Sampling Period mentioned in the Internet-Draft. Aris says this 
  in his thesis about what exactly he implemented:
 
  The second implementation choice, is in regards with the 
  measurement of pipeACK. This variable is the most important 
  introduced by the method and is used to compute the phase that the 
  sender currently lies in. In order to compute pipeACK the approach 
  suggested by the Internet Draft (ID) is followed [ncwv]. During 
  initialization, pipeACK is set to the maximum possible value. A 
  helper variable prevHighACK is introduced that is initialized to 
  the initial sequence number (iss). prevHighACK holds the value of 
  the highest acknowledged byte so far. pipeACK is measured once per 
  RTT meaning that when an ACK covering prevHighACK is received, 
  pipeACK becomes the difference between the current ACK and 
  prevHighACK. This is called a pipeACK sample.  A newer version of 
  the draft suggests that multiple pipeACK samples can be used 
  during the pipeACK sampling period.
 
  Lars
 
 
  [prr.patch]
 
  [newcwv.patch]
 
  Apologies for not looking at this as yet.  It is now closer to the 
  top of my list.
 
  Best,
  George
 
 
 
 
  --
  Tom
  @adventureloop
  adventurist.me
 
  :wq
  ___
  freebsd-net@freebsd.org mailing list
  http://lists.freebsd.org/mailman/listinfo/freebsd-net
  To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
 
 
 



-- 
Tom
@adventureloop
adventurist.me

#pragma summon cthulhu
:wq


pgps6xi2Ux6Do.pgp
Description: PGP signature

Re: Patches for RFC6937 and draft-ietf-tcpm-newcwv-00

2014-08-26 Thread Tom Jones 
On Tue, Aug 26, 2014 at 02:43:49PM +, Eggert, Lars wrote:
 Hi,
 
 the newcwv patch is probably stale now with Tom Jones' recent patch based on
 a more up-to-date version of the Internet-Draft, but the PRR patch should
 still be useful?

My newcwv patch is much more up to date than Aris's, but it is slightly
different in implementation. I have had a few suggestions from Adrian, but he
couldn't comment on how it relates to the tcp internals.

There is a PR: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191520

The biggest difference in structure between mine and Aris's patch is the use of
tcp timers. It would be good to hear if my approach or Aris's is prefered.

 On 2014-6-19, at 23:35, George Neville-Neil g...@neville-neil.com wrote:
 
  On 4 Feb 2014, at 1:38, Eggert, Lars wrote:
  
  Hi,
  
  below are two patches that implement RFC6937 (Proportional Rate Reduction 
  for TCP) and draft-ietf-tcpm-newcwv-00 (Updating TCP to support 
  Rate-Limited Traffic). They were done by Aris Angelogiannopoulos for his 
  MS thesis, which is at 
  https://eggert.org/students/angelogiannopoulos-thesis.pdf.
  
  The patches should apply to -CURRENT as of Sep 17, 2013. (Sorry for the 
  delay in sending them, we'd been trying to get some feedback from 
  committers first, without luck.)
  
  Please note that newcwv is still a work in progress in the IETF, and the 
  patch has some limitations with regards to the pipeACK Sampling Period 
  mentioned in the Internet-Draft. Aris says this in his thesis about what 
  exactly he implemented:
  
  The second implementation choice, is in regards with the measurement of 
  pipeACK. This variable is the most important introduced by the method and 
  is used to compute the phase that the sender currently lies in. In order 
  to compute pipeACK the approach suggested by the Internet Draft (ID) is 
  followed [ncwv]. During initialization, pipeACK is set to the maximum 
  possible value. A helper variable prevHighACK is introduced that is 
  initialized to the initial sequence number (iss). prevHighACK holds the 
  value of the highest acknowledged byte so far. pipeACK is measured once 
  per RTT meaning that when an ACK covering prevHighACK is received, pipeACK 
  becomes the difference between the current ACK and prevHighACK. This is 
  called a pipeACK sample.  A newer version of the draft suggests that 
  multiple pipeACK samples can be used during the pipeACK sampling period.
  
  Lars
  
  
  [prr.patch]
  
  [newcwv.patch]
  
  Apologies for not looking at this as yet.  It is now closer to the top of 
  my list.
  
  Best,
  George
 



-- 
Tom
@adventureloop
adventurist.me

:wq
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

Re: [PATCH] Implementation of draft-ietf-tcpm-newcwv-06

2014-08-01 Thread Tom Jones 
On Mon, Jun 30, 2014 at 09:53:59PM +0100, Tom Jones wrote:
 On Mon, Jun 30, 2014 at 12:29:44PM -0700, Adrian Chadd wrote:
  Hi!
  
  Cool! Would you mind throwing it into a bugzilla ticket so it's not
  lost and it can be assigned for some review?
  
  http://bugs.freebsd.org/submit/
 
 Done.
 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191520
 
  Is there any benefit in hanging this state off of it as a pointer to
  some other struct, rather than having it in the tcpcb? Is it always
  going to be used?
 
 The draft recommends newcwv be used as a default, so there is a chance it will
 always be around. What would the impact to performance be by moving the state
 out into a struct?

I have updated the patch to move the new variable introduced with newcwv into a
struct within the tcpcb.

-- 
Tom | I don't see how we are going to build the dystopian megapoli
@adventureloop  | we were promised in 80s and early 90s cyberpunk fiction if
adventurist.me  | you guys keep complaining.

:wq
Index: sys/conf/files
===
--- sys/conf/files  (revision 269231)
+++ sys/conf/files  (working copy)
@@ -3383,6 +3383,7 @@
 netinet/tcp_sack.c optional inet | inet6
 netinet/tcp_subr.c optional inet | inet6
 netinet/tcp_syncache.c optional inet | inet6
+netinet/tcp_newcwv.c   optional inet | inet6
 netinet/tcp_timer.coptional inet | inet6
 netinet/tcp_timewait.c optional inet | inet6
 netinet/tcp_usrreq.c   optional inet | inet6
Index: sys/netinet/tcp_input.c
===
--- sys/netinet/tcp_input.c (revision 269231)
+++ sys/netinet/tcp_input.c (working copy)
@@ -105,6 +105,7 @@
 #include netinet6/tcp6_var.h
 #include netinet/tcpip.h
 #include netinet/tcp_syncache.h
+#include netinet/tcp_newcwv.h
 #ifdef TCPDEBUG
 #include netinet/tcp_debug.h
 #endif /* TCPDEBUG */
@@ -174,6 +175,11 @@
 VNET_NAME(tcp_abc_l_var), 2,
 Cap the max cwnd increment during slow-start to this number of segments);
 
+VNET_DEFINE(int, tcp_do_newcwv) = 0;
+SYSCTL_VNET_INT(_net_inet_tcp, OID_AUTO, newcwv, CTLFLAG_RW,
+VNET_NAME(tcp_do_newcwv), 0,
+Enable draft-ietf-tcpm-newcwv-06 (New Congestion Window Validation));
+
 static SYSCTL_NODE(_net_inet_tcp, OID_AUTO, ecn, CTLFLAG_RW, 0, TCP ECN);
 
 VNET_DEFINE(int, tcp_do_ecn) = 0;
@@ -285,9 +291,12 @@
INP_WLOCK_ASSERT(tp-t_inpcb);
 
tp-ccv-bytes_this_ack = BYTES_THIS_ACK(tp, th);
-   if (tp-snd_cwnd = tp-snd_wnd)
+   /* draft-ietf-tcpm-newcwv relaxes conditions for growing cwnd */
+   if (tp-snd_cwnd = tp-snd_wnd || 
+   (V_tcp_do_newcwv  tp-newcwv.pipeack = (tp-snd_cwnd  1)) 
) {
tp-ccv-flags |= CCF_CWND_LIMITED;
-   else
+   tp-newcwv.cwnd_valid_ts = ticks;
+   } else
tp-ccv-flags = ~CCF_CWND_LIMITED;
 
if (type == CC_ACK) {
@@ -309,6 +318,12 @@
tp-ccv-curack = th-th_ack;
CC_ALGO(tp)-ack_received(tp-ccv, type);
}
+
+   /*
+* update draft-ietf-newcwv-06 pipeack
+*/
+   if(V_tcp_do_newcwv  !IN_FASTRECOVERY(tp-t_flags))
+   tcp_newcwv_update_pipeack(tp);
 }
 
 static void inline
@@ -378,6 +393,12 @@
tp-snd_cwnd = 4 * tp-t_maxseg;
}
 
+   /* 
+* Initialise NewCWV state
+*/
+   tp-newcwv.init_cwnd = tp-snd_cwnd;
+   tcp_newcwv_reset(tp);
+
if (CC_ALGO(tp)-conn_init != NULL)
CC_ALGO(tp)-conn_init(tp-ccv);
 }
@@ -426,6 +447,11 @@
tp-t_badrxtwin = 0;
break;
}
+   
+   if (V_tcp_do_newcwv  
+   (type == CC_NDUPACK || type == CC_ECN) 
+   tp-newcwv.pipeack = (tp-snd_cwnd  1) )
+   tcp_newcwv_enter_recovery(tp);
 
if (CC_ALGO(tp)-cong_signal != NULL) {
if (th != NULL)
@@ -447,6 +473,13 @@
}
/* XXXLAS: EXIT_RECOVERY ? */
tp-t_bytes_acked = 0;
+
+   if(V_tcp_do_newcwv) {
+   if(tp-newcwv.loss_flight_size)
+   tcp_newcwv_end_recovery(tp);
+   tcp_newcwv_reset(tp);   
+   }
+   tp-newcwv.loss_flight_size = 0;
 }
 
 #ifdef TCP_SIGNATURE
Index: sys/netinet/tcp_output.c
===
--- sys/netinet/tcp_output.c(revision 269231)
+++ sys/netinet/tcp_output.c(working copy)
@@ -74,6 +74,7 @@
 #include netinet/tcp_timer.h
 #include netinet/tcp_var.h
 #include netinet/tcpip.h
+#include netinet/tcp_newcwv.h
 #ifdef TCPDEBUG
 #include netinet/tcp_debug.h
 #endif
@@ -691,6 +692,10 @@
 #endif
hdrlen = sizeof (struct tcpiphdr);
 
+   /* Trigger the newcwv timer */
+   if(V_tcp_do_newcwv)
+   tcp_newcwv_datalim_closedown(tp

Re: [PATCH] Implementation of draft-ietf-tcpm-newcwv-06

2014-08-01 Thread Tom Jones 
On Fri, Aug 01, 2014 at 03:19:20PM +0100, Tom Jones wrote:
 
 I have updated the patch to move the new variable introduced with newcwv into 
 a
 struct within the tcpcb.

Forgot some files in the diff.

-- 
Tom | I don't see how we are going to build the dystopian megapoli
@adventureloop  | we were promised in 80s and early 90s cyberpunk fiction if
adventurist.me  | you guys keep complaining.

:wq
Index: sys/conf/files
===
--- sys/conf/files  (revision 269231)
+++ sys/conf/files  (working copy)
@@ -3383,6 +3383,7 @@ netinet/tcp_reass.c   optional inet | inet6
 netinet/tcp_sack.c optional inet | inet6
 netinet/tcp_subr.c optional inet | inet6
 netinet/tcp_syncache.c optional inet | inet6
+netinet/tcp_newcwv.c   optional inet | inet6
 netinet/tcp_timer.coptional inet | inet6
 netinet/tcp_timewait.c optional inet | inet6
 netinet/tcp_usrreq.c   optional inet | inet6
Index: sys/netinet/tcp_input.c
===
--- sys/netinet/tcp_input.c (revision 269231)
+++ sys/netinet/tcp_input.c (working copy)
@@ -105,6 +105,7 @@ __FBSDID($FreeBSD$);
 #include netinet6/tcp6_var.h
 #include netinet/tcpip.h
 #include netinet/tcp_syncache.h
+#include netinet/tcp_newcwv.h
 #ifdef TCPDEBUG
 #include netinet/tcp_debug.h
 #endif /* TCPDEBUG */
@@ -174,6 +175,11 @@ SYSCTL_VNET_INT(_net_inet_tcp, OID_AUTO, abc_l_var
 VNET_NAME(tcp_abc_l_var), 2,
 Cap the max cwnd increment during slow-start to this number of segments);
 
+VNET_DEFINE(int, tcp_do_newcwv) = 0;
+SYSCTL_VNET_INT(_net_inet_tcp, OID_AUTO, newcwv, CTLFLAG_RW,
+VNET_NAME(tcp_do_newcwv), 0,
+Enable draft-ietf-tcpm-newcwv-06 (New Congestion Window Validation));
+
 static SYSCTL_NODE(_net_inet_tcp, OID_AUTO, ecn, CTLFLAG_RW, 0, TCP ECN);
 
 VNET_DEFINE(int, tcp_do_ecn) = 0;
@@ -285,9 +291,12 @@ cc_ack_received(struct tcpcb *tp, struct tcphdr *t
INP_WLOCK_ASSERT(tp-t_inpcb);
 
tp-ccv-bytes_this_ack = BYTES_THIS_ACK(tp, th);
-   if (tp-snd_cwnd = tp-snd_wnd)
+   /* draft-ietf-tcpm-newcwv relaxes conditions for growing cwnd */
+   if (tp-snd_cwnd = tp-snd_wnd || 
+   (V_tcp_do_newcwv  tp-newcwv.pipeack = (tp-snd_cwnd  1)) 
) {
tp-ccv-flags |= CCF_CWND_LIMITED;
-   else
+   tp-newcwv.cwnd_valid_ts = ticks;
+   } else
tp-ccv-flags = ~CCF_CWND_LIMITED;
 
if (type == CC_ACK) {
@@ -309,6 +318,12 @@ cc_ack_received(struct tcpcb *tp, struct tcphdr *t
tp-ccv-curack = th-th_ack;
CC_ALGO(tp)-ack_received(tp-ccv, type);
}
+
+   /*
+* update draft-ietf-newcwv-06 pipeack
+*/
+   if(V_tcp_do_newcwv  !IN_FASTRECOVERY(tp-t_flags))
+   tcp_newcwv_update_pipeack(tp);
 }
 
 static void inline
@@ -378,6 +393,12 @@ cc_conn_init(struct tcpcb *tp)
tp-snd_cwnd = 4 * tp-t_maxseg;
}
 
+   /* 
+* Initialise NewCWV state
+*/
+   tp-newcwv.init_cwnd = tp-snd_cwnd;
+   tcp_newcwv_reset(tp);
+
if (CC_ALGO(tp)-conn_init != NULL)
CC_ALGO(tp)-conn_init(tp-ccv);
 }
@@ -426,6 +447,11 @@ cc_cong_signal(struct tcpcb *tp, struct tcphdr *th
tp-t_badrxtwin = 0;
break;
}
+   
+   if (V_tcp_do_newcwv  
+   (type == CC_NDUPACK || type == CC_ECN) 
+   tp-newcwv.pipeack = (tp-snd_cwnd  1) )
+   tcp_newcwv_enter_recovery(tp);
 
if (CC_ALGO(tp)-cong_signal != NULL) {
if (th != NULL)
@@ -447,6 +473,13 @@ cc_post_recovery(struct tcpcb *tp, struct tcphdr *
}
/* XXXLAS: EXIT_RECOVERY ? */
tp-t_bytes_acked = 0;
+
+   if(V_tcp_do_newcwv) {
+   if(tp-newcwv.loss_flight_size)
+   tcp_newcwv_end_recovery(tp);
+   tcp_newcwv_reset(tp);   
+   }
+   tp-newcwv.loss_flight_size = 0;
 }
 
 #ifdef TCP_SIGNATURE
Index: sys/netinet/tcp_newcwv.c
===
--- sys/netinet/tcp_newcwv.c(revision 0)
+++ sys/netinet/tcp_newcwv.c(working copy)
@@ -0,0 +1,175 @@
+/*
+ * Copyright (c) 2014 Tom Jones jo...@sdf.org
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED

[PATCH] Implementation of draft-ietf-tcpm-newcwv-06

2014-06-30 Thread Tom Jones 
Hello,

Attached is a patch which implements draft-ietf-tcpm-newcwv-06, Updating TCP
to support Rate-Limited Traffic. The patch is a port of the Linux
implementation by Raffaello Secchi with influence from Aris
Angelogiannopoulos's patch set that was sent to the list earlier this year.

-- 
Tom | I don't see how we are going to build the dystopian megapoli
@adventureloop  | we were promised in 80s and early 90s cyberpunk fiction if
adventurist.me  | you guys keep complaining.
Index: sys/conf/files
===
--- sys/conf/files  (revision 268040)
+++ sys/conf/files  (working copy)
@@ -3380,6 +3380,7 @@ netinet/tcp_reass.c   optional inet | inet6
 netinet/tcp_sack.c optional inet | inet6
 netinet/tcp_subr.c optional inet | inet6
 netinet/tcp_syncache.c optional inet | inet6
+netinet/tcp_newcwv.c   optional inet | inet6
 netinet/tcp_timer.coptional inet | inet6
 netinet/tcp_timewait.c optional inet | inet6
 netinet/tcp_usrreq.c   optional inet | inet6
Index: sys/netinet/tcp_input.c
===
--- sys/netinet/tcp_input.c (revision 268040)
+++ sys/netinet/tcp_input.c (working copy)
@@ -105,6 +105,7 @@ __FBSDID($FreeBSD$);
 #include netinet6/tcp6_var.h
 #include netinet/tcpip.h
 #include netinet/tcp_syncache.h
+#include netinet/tcp_newcwv.h
 #ifdef TCPDEBUG
 #include netinet/tcp_debug.h
 #endif /* TCPDEBUG */
@@ -174,6 +175,11 @@ SYSCTL_VNET_INT(_net_inet_tcp, OID_AUTO, abc_l_var
 VNET_NAME(tcp_abc_l_var), 2,
 Cap the max cwnd increment during slow-start to this number of segments);
 
+VNET_DEFINE(int, tcp_do_newcwv) = 0;
+SYSCTL_VNET_INT(_net_inet_tcp, OID_AUTO, newcwv, CTLFLAG_RW,
+VNET_NAME(tcp_do_newcwv), 0,
+Enable draft-ietf-tcpm-newcwv-06 (New Congestion Window Validation));
+
 static SYSCTL_NODE(_net_inet_tcp, OID_AUTO, ecn, CTLFLAG_RW, 0, TCP ECN);
 
 VNET_DEFINE(int, tcp_do_ecn) = 0;
@@ -309,6 +315,12 @@ cc_ack_received(struct tcpcb *tp, struct tcphdr *t
tp-ccv-curack = th-th_ack;
CC_ALGO(tp)-ack_received(tp-ccv, type);
}
+
+   /*
+* update draft-ietf-newcwv-06 pipeack
+*/
+   if(V_tcp_do_newcwv  !IN_FASTRECOVERY(tp-t_flags))
+   tcp_newcwv_update_pipeack(tp);
 }
 
 static void inline
@@ -378,6 +390,12 @@ cc_conn_init(struct tcpcb *tp)
tp-snd_cwnd = 4 * tp-t_maxseg;
}
 
+   /* 
+* Initialise NewCWV state
+*/
+   tp-init_cwnd = tp-snd_cwnd;
+   tcp_newcwv_reset(tp);
+
if (CC_ALGO(tp)-conn_init != NULL)
CC_ALGO(tp)-conn_init(tp-ccv);
 }
@@ -426,6 +444,11 @@ cc_cong_signal(struct tcpcb *tp, struct tcphdr *th
tp-t_badrxtwin = 0;
break;
}
+   
+   if (V_tcp_do_newcwv  
+   (type == CC_NDUPACK || type == CC_ECN) 
+   tp-pipeack = (tp-snd_cwnd  1) )
+   tcp_newcwv_enter_recovery(tp);
 
if (CC_ALGO(tp)-cong_signal != NULL) {
if (th != NULL)
@@ -447,6 +470,13 @@ cc_post_recovery(struct tcpcb *tp, struct tcphdr *
}
/* XXXLAS: EXIT_RECOVERY ? */
tp-t_bytes_acked = 0;
+
+   if(V_tcp_do_newcwv) {
+   if(tp-loss_flight_size)
+   tcp_newcwv_end_recovery(tp);
+   tcp_newcwv_reset(tp);   
+   }
+   tp-loss_flight_size = 0;
 }
 
 #ifdef TCP_SIGNATURE
Index: sys/netinet/tcp_newcwv.c
===
--- sys/netinet/tcp_newcwv.c(revision 0)
+++ sys/netinet/tcp_newcwv.c(working copy)
@@ -0,0 +1,174 @@
+/*
+ * Copyright (c) 2014 Tom Jones jo...@sdf.org
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY

Re: [PATCH] Implementation of draft-ietf-tcpm-newcwv-06

2014-06-30 Thread Tom Jones 
On Mon, Jun 30, 2014 at 12:29:44PM -0700, Adrian Chadd wrote:
 Hi!
 
 Cool! Would you mind throwing it into a bugzilla ticket so it's not
 lost and it can be assigned for some review?
 
 http://bugs.freebsd.org/submit/

Done.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191520

 Is there any benefit in hanging this state off of it as a pointer to
 some other struct, rather than having it in the tcpcb? Is it always
 going to be used?

The draft recommends newcwv be used as a default, so there is a chance it will
always be around. What would the impact to performance be by moving the state
out into a struct?

 
 On 30 June 2014 10:04, Tom Jones jo...@sdf.org wrote:
  Hello,
 
  Attached is a patch which implements draft-ietf-tcpm-newcwv-06, Updating 
  TCP
  to support Rate-Limited Traffic. The patch is a port of the Linux
  implementation by Raffaello Secchi with influence from Aris
  Angelogiannopoulos's patch set that was sent to the list earlier this year.
 
  --
  Tom | I don't see how we are going to build the dystopian 
  megapoli
  @adventureloop  | we were promised in 80s and early 90s cyberpunk fiction if
  adventurist.me  | you guys keep complaining.
 
  Index: sys/conf/files
  ===
  --- sys/conf/files  (revision 268040)
  +++ sys/conf/files  (working copy)
  @@ -3380,6 +3380,7 @@ netinet/tcp_reass.c   optional inet | 
  inet6
   netinet/tcp_sack.c optional inet | inet6
   netinet/tcp_subr.c optional inet | inet6
   netinet/tcp_syncache.c optional inet | inet6
  +netinet/tcp_newcwv.c   optional inet | inet6
   netinet/tcp_timer.coptional inet | inet6
   netinet/tcp_timewait.c optional inet | inet6
   netinet/tcp_usrreq.c   optional inet | inet6
  Index: sys/netinet/tcp_input.c
  ===
  --- sys/netinet/tcp_input.c (revision 268040)
  +++ sys/netinet/tcp_input.c (working copy)
  @@ -105,6 +105,7 @@ __FBSDID($FreeBSD$);
   #include netinet6/tcp6_var.h
   #include netinet/tcpip.h
   #include netinet/tcp_syncache.h
  +#include netinet/tcp_newcwv.h
   #ifdef TCPDEBUG
   #include netinet/tcp_debug.h
   #endif /* TCPDEBUG */
  @@ -174,6 +175,11 @@ SYSCTL_VNET_INT(_net_inet_tcp, OID_AUTO, abc_l_var
   VNET_NAME(tcp_abc_l_var), 2,
   Cap the max cwnd increment during slow-start to this number of 
  segments);
 
  +VNET_DEFINE(int, tcp_do_newcwv) = 0;
  +SYSCTL_VNET_INT(_net_inet_tcp, OID_AUTO, newcwv, CTLFLAG_RW,
  +VNET_NAME(tcp_do_newcwv), 0,
  +Enable draft-ietf-tcpm-newcwv-06 (New Congestion Window Validation));
  +
   static SYSCTL_NODE(_net_inet_tcp, OID_AUTO, ecn, CTLFLAG_RW, 0, TCP ECN);
 
   VNET_DEFINE(int, tcp_do_ecn) = 0;
  @@ -309,6 +315,12 @@ cc_ack_received(struct tcpcb *tp, struct tcphdr *t
  tp-ccv-curack = th-th_ack;
  CC_ALGO(tp)-ack_received(tp-ccv, type);
  }
  +
  +   /*
  +* update draft-ietf-newcwv-06 pipeack
  +*/
  +   if(V_tcp_do_newcwv  !IN_FASTRECOVERY(tp-t_flags))
  +   tcp_newcwv_update_pipeack(tp);
   }
 
   static void inline
  @@ -378,6 +390,12 @@ cc_conn_init(struct tcpcb *tp)
  tp-snd_cwnd = 4 * tp-t_maxseg;
  }
 
  +   /*
  +* Initialise NewCWV state
  +*/
  +   tp-init_cwnd = tp-snd_cwnd;
  +   tcp_newcwv_reset(tp);
  +
  if (CC_ALGO(tp)-conn_init != NULL)
  CC_ALGO(tp)-conn_init(tp-ccv);
   }
  @@ -426,6 +444,11 @@ cc_cong_signal(struct tcpcb *tp, struct tcphdr *th
  tp-t_badrxtwin = 0;
  break;
  }
  +
  +   if (V_tcp_do_newcwv 
  +   (type == CC_NDUPACK || type == CC_ECN) 
  +   tp-pipeack = (tp-snd_cwnd  1) )
  +   tcp_newcwv_enter_recovery(tp);
 
  if (CC_ALGO(tp)-cong_signal != NULL) {
  if (th != NULL)
  @@ -447,6 +470,13 @@ cc_post_recovery(struct tcpcb *tp, struct tcphdr *
  }
  /* XXXLAS: EXIT_RECOVERY ? */
  tp-t_bytes_acked = 0;
  +
  +   if(V_tcp_do_newcwv) {
  +   if(tp-loss_flight_size)
  +   tcp_newcwv_end_recovery(tp);
  +   tcp_newcwv_reset(tp);
  +   }
  +   tp-loss_flight_size = 0;
   }
 
   #ifdef TCP_SIGNATURE
  Index: sys/netinet/tcp_newcwv.c
  ===
  --- sys/netinet/tcp_newcwv.c(revision 0)
  +++ sys/netinet/tcp_newcwv.c(working copy)
  @@ -0,0 +1,174 @@
  +/*
  + * Copyright (c) 2014 Tom Jones jo...@sdf.org
  + * All rights reserved.
  + *
  + * Redistribution and use in source and binary forms, with or without
  + * modification, are permitted provided that the following conditions
  + * are met:
  + * 1. Redistributions of source code must retain the above

Re: Patches for RFC6937 and draft-ietf-tcpm-newcwv-00

2014-06-20 Thread Tom Jones 
On Thu, Jun 19, 2014 at 02:35:13PM -0700, George Neville-Neil wrote:
 On 4 Feb 2014, at 1:38, Eggert, Lars wrote:
 
  Hi,
 
  below are two patches that implement RFC6937 (Proportional Rate Reduction 
  for TCP) and draft-ietf-tcpm-newcwv-00 (Updating TCP to support 
  Rate-Limited Traffic). They were done by Aris Angelogiannopoulos for his 
  MS thesis, which is at 
  https://eggert.org/students/angelogiannopoulos-thesis.pdf.
 
  The patches should apply to -CURRENT as of Sep 17, 2013. (Sorry for the 
  delay in sending them, we'd been trying to get some feedback from 
  committers first, without luck.)
 
  Please note that newcwv is still a work in progress in the IETF, and the 
  patch has some limitations with regards to the pipeACK Sampling Period 
  mentioned in the Internet-Draft. Aris says this in his thesis about what 
  exactly he implemented:
 
  The second implementation choice, is in regards with the measurement of 
  pipeACK. This variable is the most important introduced by the method and 
  is used to compute the phase that the sender currently lies in. In order to 
  compute pipeACK the approach suggested by the Internet Draft (ID) is 
  followed [ncwv]. During initialization, pipeACK is set to the maximum 
  possible value. A helper variable prevHighACK is introduced that is 
  initialized to the initial sequence number (iss). prevHighACK holds the 
  value of the highest acknowledged byte so far. pipeACK is measured once per 
  RTT meaning that when an ACK covering prevHighACK is received, pipeACK 
  becomes the difference between the current ACK and prevHighACK. This is 
  called a pipeACK sample.  A newer version of the draft suggests that 
  multiple pipeACK samples can be used during the pipeACK sampling period.
 
  Lars
 
 
  [prr.patch]
 
  [newcwv.patch]
 
 Apologies for not looking at this as yet.  It is now closer to the top of my 
 list.
 
 Best,
 George


Hi George,

I have a set of patches for draft-ietf-tcpm-newcwv-06 that I was going to bring
to the list in the next few days. My implementation is a port of the Linux
implementation by a colleague of mine at the University of Aberdeen.

Feeback on how Aris hooked in his newcwv calls would be helpful.

-- 
Tom
@adventureloop
adventurist.me

#pragma summon cthulhu
:wq
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org