pf and dummynet

[Rodney W. Grimes]

> On 29 Jul 2019, at 22:15, Rodney W. Grimes wrote:
> >> On 29 Jul 2019, at 20:22, mike tancsa wrote:
> >>> On 7/29/2019 1:51 PM, Kristof Provost wrote:
> >> In general I?d expect quality of service and bandwidth limits to only
> >> be effective in the upstream direction (when going from a fast link to a
> >> slow one). There?s no good way to limit how much traffic other
> >> machines send to you.
> >
> > Though dummynet is most effective in on the outbound
> > stream (absolute control) it can be used to good effect
> > on an incoming stream due to the end-to-end paradigm of
> > the internet and the fact that congestion must be dealt
> > with.
> >
> > If dummynet holds packets and parcels them into a box at
> > a lower rate for things like TCP you'll end up reducing
> > the congestion window and hence the senders rate.  Or you
> > can get into the ACK clock situation here the sender simply
> > does not send any more data until it gets an ack back as
> > it already has filled the congestion window.
> >
> > I have been using dummynet for decades in this way,
> > and it more or less "just works."
> >
> True, with the caveat that that?s only for TCP of course.

All protocols transported over the internet should have some 
form of congestion control, sometimes that is packet loss :-)

Most protocols have similiar issues that do lead to self
clocking when the above is implemented.  If you slow down
the packets the protocol slows down overall except for
very short lived things.

>From our (Some Congestion Experienced developement group) recent
letter to the chairs of ietf tsvwg in regards to L4S working
group last call we rasied this point:

	RFC-8311 section 2.1:
	Effective congestion control is REQUIRED.

These principles applies to all traffic transported over
the internet and the ietf is not going to approve any
thing that ignores congestion.

Hence anything that does not respond to the above traffic
mettering (congestion) situation is fundemantally broken
by standard now.

People are now talking about pacing IW10 in TCP (I believe
this is already implemented in Linux, iirc Randall explained
to me what Netflix does as this burst tends to cause
subtle problems.

> Regards,
> Kristof
-- 
Rod Grimes                                                 rgrimes at freebsd.org