Diffserv service classes

In the continuing effort to make Diffserv useful on the Internet,
the Transport Area working group has the draft:

http://ietfreport.isoc.org/idref/draft-baker-diffserv-basic-classes/

The draft has a little bit for everyone. Lots of rope/flexibility for
application developers. But have any network operators thought how they
could actually support the framework in any meaningful way? And assuming
the network actually supported it, what happens when you throw such fine
grain differentiated traffic at the network?

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

ietfreport is timing out....here's another url for this draft.

http://www.ietf.org/internet-drafts/draft-baker-diffserv-basic-classes-04.txt

interesting read at:
http://qbone.internet2.edu/papers/non-architectural-problems.txt

regards,
/vicky

Sean Donelan wrote:

There is a long history of problems. But Internet2 also shows a success
for Diffserv, namely there is demand for a "worse" effort.

Are a dozen differnt classes useful to a network operator?

Sean Donelan wrote:

Dear Sean;

You raise an interesting point. There are some emerging wide bandwidth
applications (eVLBI is one, particle physics experiments are another) where
bandwidth demands are high but the value of each individual bit is low.
(In VLBI it is typical for each bit sent to only contain about 10^-3 to 10^-4 bits
of actual information.) As a result, these applications are (or can be made to be)
very tolerant of packet losses. eVLBI, for example, would take 1 Gbps with 25% loss
over 100 Mbps with no loss any day.

An "Internet standby" worse than best effort QOS would be easy to implement, according to
router vendors, and there
seems no reason why ISP's would not want to propagate such a COS flag.

This is not really a new idea. When I was programming on a mainframe as a student (back when
dinosaurs walked the Earth) I routinely used a service class that only gave me CPU when there were
no other uses for the system. This would extend the same idea to the Internet, and it fits with
with the QBone experience that it's hard to impossible to raise priorities interdomain, but easy to
lower them.

Would commercial operators support a reduced cost standby system with a "do not queue" or
"drop these bits first" policy flag attached ? I would be curious to receive re-world experiences
or suggestions off list, and would be glad to summarize later on list.

Regards
Marshall Eubanks

P.S. Note that such a system would easily interoperate with non-participating networks, who
could either drop such traffic entirely (it is worse than best effort, after all), or
forward it with normal priority, as they see fit.