Re: Diffserv service classes
Sean Donelan wrote: On Sat, 20 Nov 2004, Vicky wrote: interesting read at: http://qbone.internet2.edu/papers/non-architectural-problems.txt 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? Hardly, the greatest demand so far has been for cheap if not free packets which your transit provider can drop if he so decides. Bandwidth that is used for redundancy planning, etc. Queuing/diffserv is useful on thin (sub 2Mbps) edge links. Pete
Re: Diffserv service classes
On Sun, 21 Nov 2004 00:09:31 -0500 (EST) Sean Donelan [EMAIL PROTECTED] wrote: On Sat, 20 Nov 2004, Vicky wrote: interesting read at: http://qbone.internet2.edu/papers/non-architectural-problems.txt 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? 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.
Re: Diffserv service classes
Hi, Less-than-best effort traffic as implemented via the Internet2 Scavenger Service (see: http://qbone.internet2.edu/qbss/ ) never really took off; for example, see http://netflow.internet2.edu/weekly/20041108/#dscp which notes that Scavenger Service (DSCP=8) tagged traffic makes up less than 1% of all octets and less than 1% of all packets. One can argue chicken-and-egg (e.g., had it been supported on the commodity Internet, it would have been more successful), but I think the bottom line reality was that because -- Internet2 was/is uncongested, and because -- the typical university user of I2 pays $0/Mbps used anyhow, the motivation for users to tag traffic as Scavenger was typically non-existent (offering a discount from a price of zero is hard unless the model would involve PAYING people who generate less-than-best-effort traffic, a model which strikes me as, well, somewhat unsustainable/politically difficult). A network administrator at a site might unilaterally tag all traffic of a particular type as less-than-best-effort, but again, unless there is congestion, that tagging would be to no effect. Regards, Joe St Sauver ([EMAIL PROTECTED]) University of Oregon Computing Center
Re: Diffserv service classes
No doubt what you say is true, however, the typical eVLBI site is not part of the Internet2 (and also doesn't need the TCP aspects of the Scavenger service). There are certainly applications and users out there that would like to use all of the bandwidth possible, but do not need to step on other, more bit sensitive, services. Regards Marshall On Sun, 21 Nov 2004 10:04:53 -0800 (PST) Joe St Sauver [EMAIL PROTECTED] wrote: Hi, Less-than-best effort traffic as implemented via the Internet2 Scavenger Service (see: http://qbone.internet2.edu/qbss/ ) never really took off; for example, see http://netflow.internet2.edu/weekly/20041108/#dscp which notes that Scavenger Service (DSCP=8) tagged traffic makes up less than 1% of all octets and less than 1% of all packets. One can argue chicken-and-egg (e.g., had it been supported on the commodity Internet, it would have been more successful), but I think the bottom line reality was that because -- Internet2 was/is uncongested, and because -- the typical university user of I2 pays $0/Mbps used anyhow, the motivation for users to tag traffic as Scavenger was typically non-existent (offering a discount from a price of zero is hard unless the model would involve PAYING people who generate less-than-best-effort traffic, a model which strikes me as, well, somewhat unsustainable/politically difficult). A network administrator at a site might unilaterally tag all traffic of a particular type as less-than-best-effort, but again, unless there is congestion, that tagging would be to no effect. Regards, Joe St Sauver ([EMAIL PROTECTED]) University of Oregon Computing Center
Re: Diffserv service classes
Hi, #There are certainly applications and users out there that would #like to use all of the bandwidth possible, but do not need #to step on other, more bit sensitive, services. They might want to, but unfortunately we (the Internet2 community as a whole) have had limited success in helping them routinely achieve higher throughput for bulk transfers. Again refering to http://netflow.internet2.edu/weekly/20041108/ see Table 1: -- The median throughput for bulk TCP flows is still less than 3Mbps. -- The 95th percentile for bulk TCP flows is still less than 15Mbps. There is an I2 end-to-end performance initiative designed to improve those numbers, but at root, because most of the PCs that scientists and students work from are not shipped from the vendor pre-tuned for high throughput, average throughput numbers remain low. When PC vendors begin to read http://www.psc.edu/networking/perf_tune.html or http://www.web100.org and offer higher education special SKU's preloaded with OS's tweaked per those approaches, then, maybe, we'll see average performance routinely increase and congestion become a pragmatic issue. Until then, it will be routine to see most Abilene connectors run at only a fraction of their potential capacity, e.g., see: http://stryper.uits.iu.edu/abilene/aggregate/html/report-2004-11-20.html Shrug. Regards, Joe
Re: Diffserv service classes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 ietfreport is timing outhere'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: | 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 SIGNATURE- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBn8EfpbZvCIJx1bcRAn4mAKCAjZu5k89IVIDXajJW9tp2MmO4+QCgrFmM ojED2CtlqNO92BqCcnWcG6Y= =5lJL -END PGP SIGNATURE-
Re: Diffserv service classes
On Sat, 20 Nov 2004, Vicky wrote: interesting read at: http://qbone.internet2.edu/papers/non-architectural-problems.txt 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?
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?
