-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I'm setting up ALTQ and hfsc to prioritize VoIP traffic. The pf.conf(5)
 says pf uses TOS values to assign packets to queues.

Question: Can OpenBSD and/or pf itself set TOS and/or DSCP values?

Only some of my VoIP gear does DSCP marking.

Also, I noticed today that Google marks all their stuff with a DSCP of
0x38 (high throughput, low delay). Nice trick, but also an excellent
argument for re-marking capability in all routers.

Is marking/re-marking supported, and if so how?

thanks

dn
iD8DBQFGyz4ayPxGVjntI4IRAi/MAJ9Fhs3Di2+XyN4B16pct0W9PqafawCg7jvT
fPyu9fhGY+5DcWgTJiy60tQ=
=j+kp
-----END PGP SIGNATURE-----

not for forwarded traffic, no.

nice trick? rather useless. I'd be extremely surprised if it makes any 
difference at all.
i mean, who is really
1) looking at DSCP/TOS at all, 
- and -
2) using them for different forward9ng priorities
- and -
3) has congestion/fwd capa shortage  so that it actually makes a 
   difference,
- and -
4) trusts externally set TOS/DSCP
?

-- 
Henning Brauer, hb@bsws.de, henning@openbsd.org
BS Web Services, http://bsws.de
Full-Service ISP - Secure Hosting, Mail and DNS Services
Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



For various reasons I can't name names, but I can tell you that there
are some VERY large service provider and enterprise networks using DSCP
classification and prioritization.

ISPs tend to run at much higher utilization levels than enterprises and
congestion is a reality on at least some of their pipes. So is the
layer-8 urge to charge a premium to one set of customers over another.
And even in the absence of congestion, there's still a desire to service

No one should trust external TOS or DSCP markings. Again, what Google is
doing is an excellent argument for re-marking capability in all routers.

And here we come full circle. Given the OpenBSD now IS a router --
whether it's a little two-interface pf box for home use or some big
studly hardware running OpenBGPD and OpenOSPFD box for ISPs, I would say
the addition of support for DSCP re-marking would be a very desirable
feature.

dn
iD8DBQFGzMWnyPxGVjntI4IRAnFKAKDKwBLLfP1prDk3Sk1JR3Ltg+E/twCaAsjk
/ScJ34YXcBDS7rvxvpIjozs=
=J2WL
-----END PGP SIGNATURE-----

i know the ISP market very well, and I have yet to see that. at least 
in europe, basically everybody has spare capacity like beer on 

true. I have my doubts wether all this tos/dscp dance really makes much 


i'd call it a nice-to-have, yes.

-- 
Henning Brauer, hb@bsws.de, henning@openbsd.org
BS Web Services, http://bsws.de
Full-Service ISP - Secure Hosting, Mail and DNS Services
Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam

Just curious: Where would DSCP re-marking be implemented?

My question was about pf, but I can see cases where an OpenBGPD and/or
OpenOSPFD box could use re-marking with or without pf.

thanks

dn

but that would be silly.
why would you do that? performance reasons? hey, then rather lets make 
pf even faster. wait, that's what we're working on already :)

-- 
Henning Brauer, hb@bsws.de, henning@openbsd.org
BS Web Services, http://bsws.de
Full-Service ISP - Secure Hosting, Mail and DNS Services
Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam

It should probably be only done in pf.

pf is the only policy engine we have that manipulates packets.  Other
services like routing daemons make decisions at the route level, or
the network layer moves packets according to the RFC rules, but
nothing else changes packets outside those rules.

If you want to do it, run pf.  Doing it elsewhere will hurt the non-pf
case.  That's silly.

Extending "scrub" for this makes the most sense to me, headers
are already adjusted there (e.g. with max-mss).

on transit/peering/backbone, sure, but it's different on the access
side - in .uk, backhaul to ADSL wholesalers is usually run seriously hot
for at least some hours every day and I'd be surprised if this is unusual
in other places. I guess that in some parts of the world backbones
normally run quite hot too.


can't say I experience this from my local google instance, though
the packets have traversed a couple of AS before I see them so this
may have been adjusted by someone else.

Yeah, really. Maybe we are misunderstanding, but wouldn't remarking
capability be exactly the ability to say "I don't trust these
externally set TOS/DSCP bits"? Henning, could you explain to the

you really want to reset them.
you don't want your random router/switch somewhere in the core that 
looks at these (be it because of stupid defaults, misconfig, or you're 
actually using tos/dscp internally) obey these bits. so resetting them 
at the edge is the best thing to do.

-- 
Henning Brauer, hb@bsws.de, henning@openbsd.org
BS Web Services, http://bsws.de
Full-Service ISP - Secure Hosting, Mail and DNS Services
Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam

On a related note, I work with some equipment that uses TOS values and
some that uses DSCP.

When you see a TOS value in tcpdump (0x68 for instance) just divide by 4
to get the DSCP (and throw away any remainder.)  The DSCP value uses the same
field in the IP packet as TOS, but ignores the last bits.  So, DSCP to TOS
is simply multiply by 4 (and convert to hex)


-- 
"I'm a conservative liberal - and not afraid of calling myself one either.
Both parties can take their anti-constitutional activity and shove it up my
fat american ass." - Be More Social (kuro5hin.org troll)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Yes and no. TOS field definitions have changed over the years; there's a
history of this moving target in RFC 3168, section 22.

The 6-bit DSCP field is defined in RFC 2474. It does not ignore anything
in TOS; if anything it's a superset.

dn
iD8DBQFGzMLgyPxGVjntI4IRAlYLAKDFgai2XDnrKb/hKXqGgdF7HhR4HwCfU0kZ
HuUfxAcSHTW6oNohod7TcZA=
=J8lb
-----END PGP SIGNATURE-----