From: Dave Taht <dave.taht@gmail.com>
To: bloat <bloat@lists.bufferbloat.net>
Subject: [Bloat] Three new diffserv codepoints suggested
Date: Sat, 11 Jun 2011 07:15:41 -0600 [thread overview]
Message-ID: <BANLkTikk8Tdj6+NSQ69hfMPOO33MPUrKkA@mail.gmail.com> (raw)
Before I go to the trouble of writing up an RFC, I thought perhaps
here (and the end-to-end list) would be a good place to discuss some
ideas towards adding 3 new codepoints to diffserv,
in an enhancement to rfc4594[1] - http://tools.ietf.org/html/rfc4594
I've named them with something of a sense of humor, in a ha-ha only
serious manner.
They are 'Information, Text', 'Large Bandwidth', and 'mice'[2].
1) The 'IT' codepoint would be suitable for interactive ssh and
textual chat (irc,jabber,etc), and merely codify existing practice
that uses the 'immediate' TOS field for this purpose in ssh. The OAM
codepoint seems unsuitable for this.
2) The 'LB' codepoint = 0x63 is an indicator that as soon as a packet
marked in this way arrives at a downstream site, it should be
immediately reclassified and shaped to fit the available bandwidth of
the downstream site.
(a suitable nickname for 'LB' would also be 'Lying Bastard', as there
exist many sites that set all the diffserv bits in the hope of getting
better service from elsewhere)
3) The 'MICE' codepoint consists of small, infrequent, but system
critical packets such as ARP, DHCP, various forms of ICMP needed for
ipv6 ND and RA to work, and DNS.
Arguably the MICE codepoint could be CS6 - the RFC recomends that NTP
be an EF service and says that (in section 4.9 of the standard) that
DNS, DHCP, and bootp must be 'best effort' services classes.
I will certainly argue that wireless is showing that the latter 3
packet types - and ARP, ND, RA, etc -
deserve a class of their own. CS6 could be used to wedge most of these
together, except for the elephant in its room, BGP, and the conflation
with longer-haul protocols. NTP consistently treated as EF would be
nice, too.
thoughts? What other unofficial codepoints are in use? Does anyone
still care about diffserv marking? is the core all MPLS? The edges are
certainly not using anything at the moment.
--
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://the-edge.blogspot.com
1: it was nice to run across at least two members of this list that
authored this RFC, and the idea of a MICE class comes from kathie
nichols pounding into my head that the mice are a problem.
2: I was unable to come up with a back-acronym for 'mice'. I got as
far as 'majorly important' before getting stuck on the 'c'.
next reply other threads:[~2011-06-11 12:53 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-11 13:15 Dave Taht [this message]
2011-06-12 5:05 ` Dave Taht
2011-06-13 14:10 ` Jonathan Morton
2011-06-13 14:35 ` Dave Taht
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/bloat.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=BANLkTikk8Tdj6+NSQ69hfMPOO33MPUrKkA@mail.gmail.com \
--to=dave.taht@gmail.com \
--cc=bloat@lists.bufferbloat.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox