Re: My comments to the press about RFC 2474

 With respect, Brian, I don't think this is simply the failure of 
journalists to discern the distinction between Informational RFCs and 
Standards Track RFCs. Nobody has made the claim that the IETF produced a 
standard for accounting and billing for QoS or anything else. 
Informational RFCs are a perfectly fine record of what certain people in 
the IETF community may be "envisioning" at a given time, as long as 
people understand that "envisioning" is not the same as "requiring," 
which is basic English literacy.
This debate was also not started by AT&T throwing the name of IETF in to 
the regulatory stew as Russ was quoted as saying to CNET's Declan 
McCullagh. ("We didn't foresee AT&T throwing our name into this 
discussion," the IETF's Housley said. He added: "This characterization 
of the IETF standard and the use of the term 'paid prioritization' by 
AT&T is misleading.")
The immediate debate was started by a letter filed with the FCC by a 
group called National Organizations on Aug. 2nd addressing DiffServ and 
IntServ. This letter drew a reply from Free Press invoking the name of 
IETF and interpreting DiffServ. AT&T's letter offering their view of 
DiffServ was a reply to the Free Press letter, which said:
"Second, it is nonsensical to portray DiffServ as something that a 
third-party content provider could pay an ISP to use for 
paid-prioritization. Either an ISP respects DiffServ flags as outlined 
by IETF and chosen by the application or they do not -- and if they do 
not, then it isn’t DiffServ. By way of analogy, an individual customer 
cannot pay a restaurant to obey the health code -- they either do or 
they don’t. If an ISP is using DiffServ, but not respecting application 
flags, then that is not the standard as outlined by the IETF. Similar to 
how Comcast was improperly using RST packets to block BitTorrent, such a 
nonstandard use of DiffServ would be entirely new, improper, and not at 
all in line with that outlined by the IETF."
So there was a chain of "throwings of the name of IETF into this 
discussion" before AT&T jumped into to it. It would have been pretty 
damn hard for them to address the arguments that had already been made 
by Free Press without referring to IETF, so Russ' remark is, well, not 
very well informed. Perhaps he's not a professional FCC-watcher.
So what we have at the FCC at the moment is a number of people arguing 
about the meaning of RFCs because they think the RFCs (even the 
Informational ones) hold the key to understanding the spirit of the 
Internet. I think this is wonderful, because it's much more productive 
-- potentially -- than a bunch of law professors invoking end-to-end 
arguments as the First Commandment, a binding law that bans anything 
beyond best efforts as far as the eye can see.
I can see how technical people would find this whole process 
distasteful. Journalists don't understand what they're told, they don't 
ask the right questions, and they don't repeat the right comments. 
Regulators are even worse. It's no wonder that Dave Clark used his time 
addressing the FCC after me at the Harvard hearing on Comcast in 2008 to 
talk about economics. These are hard questions for the network 
engineering community to resolve, and even harder for regulators. No 
doubt about it.
But you can't blame people for trying, and you can't say "go regulate 
the Internet however you want but keep the IETF's name out of it." That 
would lead to a result you really don't want to see.
RB

On 9/3/2010 3:53 PM, Brian E Carpenter wrote:
> Richard,
>
> This will be my last message on these points, which were beaten to death
> in the diffserv WG some years ago.
>
> > assured or expedited services, except nobody really knows how that might 
> > actually work in a real scenario (or maybe they do, and it's just us humble 
> > developers who don't.)
> I can't speak for those who have implemented EF and AF queuing algorithms;
> they will have to speak for themselves.
>
> > Am I missing something when I find a gap in the dialog?
> I don't see the gap. There are a few references to possible differential
> payments in some of the informational documents concerning diffserv, and nobody
> denies that differential pricing is possible. There are no elements in the
> normative specifications of diffserv that serve in any way to support
> accounting, pricing or charging. We can't control what choices the carriers
> in one particular country such as the USA adopt; and it's not our business.
>
> The fact that journalists don't read the bit at the beginning of each
> RFC that defines its status is something that we've been used to for
> many years.
>
> Regards
>     Brian
>
> On 2010-09-04 10:36, Richard Bennett wrote:
> >   Let's go back to your original comment, the one that Russ has quoted
> > elsewhere. You said: "It has been consistently hard to explain that
> > diffserv is not a prioritisation scheme, even within the technical
> > community, let alone to the regulators and the media." Your
> > clarification is that "DiffServ deals with multiple queuing disciplines,
> > which may or may not be priority based" and you get into EF and AF that
> > in most implementations will end up using dedicated facilities of some
> > sort, although service providers may be able to use these dedicated
> > facilities for generic traffic if there's no EF or AF to send.
> >
> > I can see why it's hard to explain this subtle distinction. You're
> > saying here on the list that DiffServ is a higher level abstraction than
> > prioritization that neither requires nor precludes prioritization to
> > implement premium services. That's fine, but if you want to say that
> > DiffServ is *completely removed from the realm of prioritization,* you
> > have to explain away the grandfathering of IP Precedence into the
> > standard. I think that you mean to say that DiffServ is *more than* a
> > prioritization scheme, it's a general architecture for Internet QoS."
> >
> > But even that's not correct. In fact, DiffServ is an Internet QoS
> > architecture that explicitly offers priority-based services by design,
> > and may also offer other types of assured or expedited services, except
> > nobody really knows how that might actually work in a real scenario (or
> > maybe they do, and it's just us humble developers who don't.)
> >
> > Russ said to the press that he considers AT&T's belief that the RFCs
> > envisioned payment for premium services implemented over DiffServ or
> > MPLS to be "invalid." I find this puzzling as there are numerous
> > references to payment for premium services in the RFCs AT&T cites, such
> > as RFC 2638:
> >
> > "At the risk of belaboring an analogy, we are motivated to provide
> > services tiers in somewhat the same fashion as the airlines do with
> > first class, business class and coach class. The latter also has
> > tiering built in due to the various restrictions put on the purchase.
> > A part of the analogy we want to stress is that best effort traffic,
> > like coach class seats on an airplane, is still expected to make up
> > the bulk of internet traffic. Business and first class carry a small
> > number of passengers, but are quite important to the economics of the
> > airline industry. The various economic forces and realities combine
> > to dictate the relative allocation of the seats and to try to fill
> > the airplane. We don't expect that differentiated services will
> > comprise all the traffic on the internet, but we do expect that new
> > services will lead to a healthy economic and service environment."
> >
> >
> > Am I missing something when I find a gap in the dialog?
> >
> > RB
> >
> > On 9/3/2010 3:11 PM, Brian E Carpenter wrote:
> > > Er, exactly what in your quotation is incompatible with what
> > > I wrote:
> > >
> > > > > > Diffserv deals with multiple different queuing disiplines, which
> > > > > > may or may not be priority based.
> > > ?
> > >
> > > Regards
> > >      Brian Carpenter
> > >
> > > On 2010-09-04 09:34, Richard Bennett wrote:
> > > >     Brian's paper on DiffServ confirms the fact that prioritization is
> > > > part of the
> > > > standard. Here are the two relevant quotes:
> > > >
> > > > "In the original design of IP [33], a byte known as the “type of
> > > > service (TOS)
> > > > octet” was reserved in the header of every packet. This was defined
> > > > to contain
> > > > two important fields: a three-bit “precedence” value and three TOS
> > > > bits. The
> > > > precedence was intended as a simple priority marker, where priority 0
> > > > got the
> > > > worst treatment and priority 7 got the best." (p. 1480)
> > > >
> > > > "The Diffserv working group has taken the approach that a few
> > > > fundamental PHBs
> > > > should be standardized early. These should derive from some existing
> > > > experience
> > > > (primarily from limited deployment and experimentation with use of
> > > > the IP
> > > > precedence field to select forwarding behaviors) and might be
> > > > implemented using
> > > > a variety of specific mechanisms. The PHBs standardized so far are as
> > > > follows...
> > > >
> > > > "• Class selector behaviors: here seven DSCP values run from 001 000
> > > > to 111 000
> > > > and are specified to select up to seven behaviors, each of which has
> > > > a higher
> > > > probability of timely forwarding than its predecessor. *Experts will
> > > > note that
> > > > the default behavior plus the class selectors exactly mirror the
> > > > original eight
> > > > IP Precedence values.*" (p. 1487)
> > > >
> > > > This is very straightforward.
> > > >
> > > > RB
> > > >
> > > > On 9/3/2010 1:06 PM, Brian E Carpenter wrote:
> > > > > Richard,
> > > > >
> > > > > Diffserv deals with multiple different queuing disiplines, which may
> > > > > or may not be priority based. Please read RFC 2475 and if
> > > > > you like, B.E. Carpenter and K. Nichols, Differentiated Services in
> > > > > the Internet, Proc. IEEE, 90 (9) (2002) 1479-1494.
> > > > >
> > > > >       Brian
> > > > >
> > > > > On 2010-09-04 07:57, Richard Bennett wrote:
> > > > > >    DiffServ is a prioritization scheme, Brian, how can you say it's
> > > > > > not?
> > > > > > IntServ is a reservation scheme, and DiffServ attempts to provide
> > > > > > desired PHBs in practice by sorting packets into priority queues and
> > > > > > invoking appropriate Link Layer  facilities, which are in most cases
> > > > > > priority-based, such as 802.11e traffic classes.
> > > > > >
> > > > > > What on earth could the value of DSCPs be if they didn't map to
> > > > > > traffic
> > > > > > classes in the data link?
> > > > > >
> > > > > > RB
> > > > > >
> > > > > >    Brian E Carpenter<brian(_dot_)e(_dot_)carpenter(_at_)gmail(_dot_)com>    
> > > > > > wrote:
> > > > > > > Russ,
> > > > > > > It has been consistently hard to explain that diffserv is not a
> > > > > > > prioritisation scheme, even within the technical community, let
> > > > > > > alone to the regulators and the media. I think your comments as
> > > > > > > quoted are as good as we can expect from journalists.
> > > > > > > It should be a matter of concern to all of us here that the US FCC
> > > > > > > isn't confused into regulating the technology. It would set a bad
> > > > > > > precedent for regulators in other countries. I am making no comment
> > > > > > > as to whether they should regulate carrier's charging practices;
> > > > > > > that's
> > > > > > > entirely a national matter that shouldn't concern the IETF in any
> > > > > > > way.
> > > > > > > Regards
> > > > > > > Brian Carpenter
> > > > > > > On 2010-09-03 05:47, Russ Housley wrote:
> > > > > > > > I want the whole community to be aware of the comments that I
> > > > > > > > made to
> > > > > > > > the press yesterday. Clearly, these comments do not represent IETF
> > > > > > > > consensus in any way. They are my opinion, and the reporter was
> > > > > > > > told to
> > > > > > > > express them as my opinion.
> > > > > > > >
> > > > > > > > One thing that I said was not captured quite right. The article
> > > > > > > > says:
> > > > > > > > "With services that require certain speeds to operate smoothly,
> > > > > > > > such as
> > > > > > > > Internet telephony, calls are given precedence over TV, Housley
> > > > > > > > said."
> > > > > > > > I actually said that DiffServ can be used to make sure that traffic
> > > > > > > > associated with applications that require timely delivery, like
> > > > > > > > voice
> > > > > > > > and video, to give preference over traffic associated with
> > > > > > > > applications
> > > > > > > > without those demands, like email.
> > > > > > > >
> > > > > > > > The whole article is copied below, and it is online here:
> > > > > > > > http://www.nationaljournal.com/njonline/tc_20100902_7144.php
> > > > > > > >
> > > > > > > > Russ
> > > > --
> > > > Richard Bennett
> > > > Senior Research Fellow
> > > > Information Technology and Innovation Foundation
> > > > Washington, DC
--
Richard Bennett
Senior Research Fellow
Information Technology and Innovation Foundation
Washington, DC

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf