On 2018/04/01 13:29, Job Snijders wrote:
> On Sun, Apr 01, 2018 at 11:29:55AM +0100, Stuart Henderson wrote:
> > On 2018/03/31 16:10, Job Snijders wrote:
> > > TL;DR: I propose to update the defaults to use DSCP "AF21" (Low
> > > Latency Data) for interactive session traffic, and CS1 ("Lower
> > > Effort") for non-interactive traffic. This applies to both IPv4 and
> > > IPv6.
> > 
> > I think this is the right thing to do, but needs handling in
> > conjunction with changes to PF, which has dual queue-setting
> > (IPTOS_LOWDELAY packets go in one queue along with empty TCP ACKs,
> > other packets can go in another lower priority queue).
> > 
> > Since firewalls are often updated less often than hosts I think it
> > would be better if the PF side was done first with some time to give
> > people chance to update, though it doesn't need to be too long (they
> > can set qos in sshd_config if they want to retain the old setting).
> > 
> > A few other pieces use IPTOS_LOWDELAY (pfsync, carp, vxlan, etherip)
> > which I think would want switching too.
> 
> What we're looking at is some kind of "migrate TOS to DSCP" project.
> There is a few tens of files where TOS values need to be examined and an
> appropiate DSCP value choosen.

Yes, that's clearly a much bigger scope. But if we're starting with ssh
those should be on the radar too IMO.

>                                I'm not sure I'd go as far as blindly
> replacing IPTOS_LOWDELAY with IPTOS_DSCP_AF21, but perhaps as a
> transition that is what is needed in some places.

Indeed. For some of these uses (like carp) something like CS7 seems
more appropriate. ssh seems a great place to start gaining more
experience with this - in particular any breakage can be handled
more easily than things like carp (since ssh already has config
options for this).

> We can start by treating IPTOS_LOWDELAY and IPTOS_DSCP_AF21 similarly in
> pf (see untested patch below), and then accept patches that migrate from
> TOS to DSCP?

That approach generally makes sense to me. It seems that some other
codepoints should probably also be treated as higher priority but
I'm not quite sure which yet...

> As far as I understand, out-of-the-box pf doesn't do anything with TOS
> values, so users wlil have to have explicitly configured something on
> the firewall or clients anyhow?

Yes, the firewall needs to have queues enabled and traffic assigned with
"set queue (foo, bar)" syntax.

> Kind regards,
> 
> Job
> 
>  share/man/man5/pf.conf.5 | 12 +++++++++---
>  sys/net/pf.c             |  8 +++++---
>  2 files changed, 14 insertions(+), 6 deletions(-)
> 
> diff --git share/man/man5/pf.conf.5 share/man/man5/pf.conf.5
> index 13e23423daa..f5a65e1b0d4 100644
> --- share/man/man5/pf.conf.5
> +++ share/man/man5/pf.conf.5
> @@ -679,7 +679,9 @@ interface, the queueing priority will also be written as 
> the priority
>  code point in the 802.1Q VLAN header.
>  If two priorities are given, TCP ACKs with no data payload and packets
>  which have a TOS of
> -.Cm lowdelay
> +.Cm lowdelay ,
> +or DSCP value
> +.Cm af21 ,
>  will be assigned to the second one.
>  Packets with a higher priority number are processed first,
>  and packets with the same priority are processed
> @@ -702,7 +704,9 @@ section.
>  Packets matching this rule will be assigned to the specified
>  .Ar queue .
>  If two queues are given, packets which have a TOS of
> -.Cm lowdelay
> +.Cm lowdelay ,
> +or DSCP value
> +.Cm af21 ,
>  and TCP ACKs with no data payload will be assigned to the second one.
>  See
>  .Sx QUEUEING
> @@ -1608,7 +1612,9 @@ Normally only one
>  .Ar queue
>  is specified; when a second one is specified it will instead be used for
>  packets which have a TOS of
> -.Cm lowdelay
> +.Cm lowdelay ,
> +or DSCP value
> +.Cm af21 ,
>  and for TCP ACKs with no data payload.
>  .Pp
>  To continue the previous example, the examples below would specify the
> diff --git sys/net/pf.c sys/net/pf.c
> index d841f834af1..aac20603a01 100644
> --- sys/net/pf.c
> +++ sys/net/pf.c
> @@ -2804,7 +2804,7 @@ pf_build_tcp(const struct pf_rule *r, sa_family_t af,
>               h->ip_len = htons(tlen);
>               h->ip_v = 4;
>               h->ip_hl = sizeof(*h) >> 2;
> -             h->ip_tos = IPTOS_LOWDELAY;
> +             h->ip_tos = IPTOS_DSCP_AF21;
>               h->ip_len = htons(len);
>               h->ip_off = htons(ip_mtudisc ? IP_DF : 0);
>               h->ip_ttl = ttl ? ttl : ip_defttl;
> @@ -7020,7 +7020,8 @@ done:
>                       pf_scrub(pd.m, s->state_flags, pd.af, s->min_ttl,
>                           s->set_tos);
>                       pf_tag_packet(pd.m, s->tag, s->rtableid[pd.didx]);
> -                     if (pqid || (pd.tos & IPTOS_LOWDELAY)) {
> +                     if (pqid || (pd.tos & IPTOS_LOWDELAY)
> +                         || (pd.tos & IPTOS_DSCP_AF21)) {
>                               qid = s->pqid;
>                               if (s->state_flags & PFSTATE_SETPRIO)
>                                       pd.m->m_pkthdr.pf.prio = s->set_prio[1];
> @@ -7032,7 +7033,8 @@ done:
>               } else {
>                       pf_scrub(pd.m, r->scrub_flags, pd.af, r->min_ttl,
>                           r->set_tos);
> -                     if (pqid || (pd.tos & IPTOS_LOWDELAY)) {
> +                     if (pqid || (pd.tos & IPTOS_LOWDELAY)
> +                         || (pd.tos & IPTOS_DSCP_AF21)) {
>                               qid = r->pqid;
>                               if (r->scrub_flags & PFSTATE_SETPRIO)
>                                       pd.m->m_pkthdr.pf.prio = r->set_prio[1];
> 

Reply via email to