Subject: Any SPs using QoS ???

From: Martin Picard <[email-masked]>
Date: Tue, 26 Sep 2000 15:00:32 -0400

Hi,

  There's a lot of work and effort that has been put into QoS and
  QoS in MPLS networks.

  Service Providers tend to say that their backbone will never be
  congested and if it ever gets there, then, bandwidth will be increased
  and therefore no Congestion Management or Congestion Avoidance
  mechanisms are necessary. This makes Classification at the edge
  useless but we still hear that IP Precedence so and so is being used
  for this type of traffic, and another one for another type, etc...

  The question I have is are there any real Service Providers making
  use of QoS, and which part of it, and where ???

  I am not thinking of QoS over the Internet (ISPs) for residential clients
  but more for the SPs transporting corporate client networks with either
  IPSec tunneling, LAN Extension, MPLS-VPN, etc.

  Thanks in advance
  Martin

---

From: Sham Chakravorty <[email-masked]>
Date: Tue, 26 Sep 2000 15:53:07 -0400

Same thoughts here.

Like to know how many MPLS deployments are there that do QoS??!!

This is very reminiscent of IPv6 - a lot of talk from IETF and the
developers and we were on the verge of recommending to a large customer
that they deploy IPv6 but then backed out.  We could find only a few -
if any - decent deployments out there.

There has to be more to MPLS deployment than TE in the core of the
networks where such folks as Nortel engineers to Dr. Jain will tell you
that the optics is moving into circuit (read wavelength) switching in
the core. 

Like to hear some coherent, engineering thoughts.

Chakravorty
************************************************************

---

From: Sudheer Dharanikota <[email-masked]>
Date: Tue, 26 Sep 2000 16:44:15 -0500

Hi Sham and Martin:

	My thoughts.. purely mine...

  QoS - MPLS - Optical

	QoS is an issue in the access - no dispute.
	QoS is an issue in the core - where access is
	aggregated for SLA provisioning.
	QoS is an idirect issue where restoration is a concern
	in the optical domain. Although Dr. Jain will say that the 
	QoS for the optical is better service at Lambda- guarantee..

	MPLS is a layer 2 1/2 mechanism to expedite the forwarding
	and to do TE. It should neither add or delete anything to the
	basic QoS that we have from IP. Hence we talk about E, L-LSPs.

	So I feel we still have the problem to address everywhere
	in the network.

 ISP's view on QoS

	I am NOT from ISP.. but I guess they sell services (which
	are made around bandwidth) .. 

	If everybody has enough bandwidth and is not a commodity..
	that is another good reason to find new avenues to get
	more money :-) So sell QoS services on top of bandwidth.
	EF for VoIP, AF for blah blah blah etc.

Cheers,

sudheer

---

From: Lixia Zhang <[email-masked]>
Date: Wed, 27 Sep 2000 08:58:19 -0700 (PDT)

>  ......

at the last IETF, people from several big ISPs told me that bandwidth *is*
a commodity market now
Just to pass the info.

---

From: Panos Trimintzios <[email-masked]>
Date: Wed, 27 Sep 2000 17:15:25 +0100 (BST)

Lixia is right bandwidth is officially a market commodity see: 

Dow Jones to launch bandwidth index 
http://home.cnet.com/category/0-1004-200-1677726.html

PanOS

On Wed, 27 Sep 2000, Lixia Zhang wrote:

->  ......
->  ISP's view on QoS
-> 
-> 	I am NOT from ISP.. but I guess they sell services (which
-> 	are made around bandwidth) .. 
-> 
-> 	If everybody has enough bandwidth and is not a commodity..
-
-at the last IETF, people from several big ISPs told me that bandwidth *is*
-a commodity market now
-Just to pass the info.
-
-
-> 	that is another good reason to find new avenues to get
-> 	more money :-) So sell QoS services on top of bandwidth.
-> 	EF for VoIP, AF for blah blah blah etc.
-> 	
-> 
-> Cheers,
-> 
-> sudheer
-
-

=======================================================
 Panos Trimintzios                                                          
 Research Fellow, Networks Research Group
 Centre for Communication Systems Research (CCSR)
 Univ. of Surrey, Guildford, Surrey GU2 7XH, U.K.
 Office: U37 / BA Building                                                    
 Tel: +44 (0)1483 876005  Fax: +44 (0)1483 876011                             
 Email: <[email-masked]>                                    
 WWW:   <http://www.ee.surrey.ac.uk/CCSR/Networks>      
=======================================================

---

From: Graham Cope <[email-masked]>
Date: Wed, 27 Sep 2000 17:29:36 +0100

> http://home.cnet.com/category/0-1004-200-1677726.html

Being a commodity, however, should not be confused with being cheap.
There are also commodity markets in diamonds, gold and crude oil
(topical at the moment!).

That then leads back to the fundamental (and possibly off topic)
question as to whether IP QoS is really required.
  To do so a service provider must charge for the good QoS. Can they
really be bothered to put in such mechanisms? Where does that leave the
cosy transit agreements that ISPs traditionally have?
 If they cannot be bothered to charge (i.e. it costs more than they get
back from it) then the Internet will remain best effort. I suspect the
IP QoS will remain a niche opportunity for suppliers of premium class
business VPNs with over-provisioning being the long term solution for
most customers as bandwdith becomes cheap (it may be a commodity, but it
ain't negligibly cheap yet, especially in the access network).

Just a thought.

Graham

---

From: Sudheer Dharanikota <[email-masked]>
Date: Wed, 27 Sep 2000 12:48:02 -0500

Thank you all...

It only proves that sell bandwidth (disproving some people
from Seattle) AND services :-)

regards,

sudheer

---

From: Sudheer Dharanikota <[email-masked]>
Date: Wed, 27 Sep 2000 13:09:20 -0500

> cosy transit agreements that ISPs traditionally have?

My opinion...

	The need for QoS is driven by application users.
	Although IntServ model is more of an academic challenge (exceuse me
	Lixia).. DiffServ has real business implications.

	Almost all the equipment vendors has a story on the 
	QoS (DiffServ) and QoS-MPLS interaction. If ISPs ignore application
needs
	and cannot encash  on the equipment features ... too bad they
	are at loss.

> ain't negligibly cheap yet, especially in the access network).

QoS is an apparent need in the access but it has major implications
and revenue potential in the core (at ISP borders) also.

---

From: Sham Chakravorty <[email-masked]>
Date: Wed, 27 Sep 2000 13:20:48 -0400

Graham,

Excellent points.  I agree; just because BW is commodity (a market
started by Enron - a power trading/building co.),  it a'nt cheap.  Try
getting a T3-size BW for a week or a day.  Next, I like to argue you
will still need QoS - which is really prioritizing traffic.  If the
roads were as wide as a field (BW glut), it doesn't mean there ought not
to be some form of taffic control.  You will always need to let the
ambulance go before all the Toyotas (flow-based control => IP switching?
does not work, re Ipsilon, meaning larger users of BW getting all the
preference is not much good unless of course you ckt-switch [or
lambda-switch] them based on SLAs). 

Also, you will never have enough BW in the wireless media and possibly
in the last mile; not to mention we have not really put any voice or
video on the Internet (or enterprise networks) to speak about.  When
they come, watch out.  This BW commodity could be as pricy as "gold" and
major controls (of all kinds!) will be needed.

Finally, the mechanisms for QoS should be network-imbedded and not
necessarily be an operational issue on an on-going basis (for any SP or
enterprise).  See the attempts Cisco is making with its CDN concept
along with Cable and Wireless sort of a backdoor approach (VPN based?).
This means it is time for a new, robust, QoS technology.  Unfortunatly,
some of us believe that MPLS is not it.  After nearly four years of work
by hundreds(?) of people, we still don't have the framework for a
network-imbedded QoS concept or implementation. We still need ATM to run
MPLS for CBR, don't we? 

Chakravorty
***************************************************************

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 27 Sep 2000 13:21:17 -0400

> at the last IETF, people from several big ISPs told me that bandwidth *is*

Oil is also a commodity.  That doesn't mean its free.

The cost of lighting up fibers and therefore the cost of bandwidth is
still not negligible, even though the cost of a circuit may be an
order of magnitude cheaper than 5 years ago.

Long distance is also a commodity.  Long distance is under $.10/min
but that is still not free.  IP service is a commodity.  It still cost
money to get service and to deliver the service.

For services ranging from raw bandwidth to commodity IP or voice,
there is competition and being able to deliver service at a lower cost
is an advantage.

Better service will cost a little more to deliver and will cost the
end customer a little more.  That is the argument for QoS.  What is
debatable is whether there is a sufficient service differentiator to
demand a higher price and whether the cost of accounting and
administration (all the way down to router configuration) doesn't
exceed the price that this service would bear in the market.  That
point does bring into question the validity of the argument for QoS.
We'll just have to see which way the market goes on this one.

Curtis

ps- We're way off topic!  This is the MPLS list?  Right?

---

From: Hafid Seddouki <[email-masked]>
Date: Wed, 27 Sep 2000 10:25:17 -0700

So what was your response Lixia,
Did the business/1st class disappear in the airline industry ?
Hafid

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 27 Sep 2000 13:37:09 -0400

In message <[email-masked]>, Pan
> http://home.cnet.com/category/0-1004-200-1677726.html

Apparently the first two months were not a raging success.

Curtis

ps- Excerpt from:  http://biz.yahoo.com/e/000811/rtx.html

                                             Three Months Ended
                                                  June 30
                                    ---------------------------------
                                        2000                1999
                                    ------------        ------------ 
Revenue                             $      4,500                --
Expenses (including Selling,        $ (6,855,405)       $ (1,323,706)
  General and Administrative)  
Net Income (Loss)                   $ (8,346,587)       $ (1,278,487)

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 27 Sep 2000 13:54:26 -0400

In message <[email-masked]>, Sham Chakravorty writes:
>  
> After nearly four years of work by hundreds(?) of people, we still
> don't have the framework for a network-imbedded QoS concept or
> implementation.

I thought draft-ietf-mpls-diff-ext-07 had something to do with
this and went to last call.  :-)

Isn't there a diff-serv WG that does something along these lines?  :-)

> We still need ATM to run MPLS for CBR, don't we?

Not for very long.  When draft-ietf-mpls-diff-ext-07 is coded and
available in product you won't.

QoS using IP prec or DSCP is in FCS product from numerous vendors
today and (at least one, maybe all) can support CBR service including
very low jitter.  (on severely congested links, not just where
bandwidth is overprovisioned).

Curtis

---

From: Grenville Armitage <[email-masked]>
Date: Wed, 27 Sep 2000 11:31:39 -0700

B/W isn't QoS.

B/W may become cheap(er), but the premium service will
be constrained jitter/loss (or predictable delay/loss, take
your choice of poison).

It isn't even clear that one can solely say "overprovision"
as the magic words to clear up jitter and loss. Realities
such as slow provisioning schedules and technology limitations
can cause your B/W growth to fall behind the demand growth,
creating congestion points.

Which suggests anything that helps distribute congestion points
(e.g. MPLS TE) and helps differentiate traffic at congestion
points (e.g. Diffserv+MPLS) will find use.

cheers,
gja

---

From: Fred Baker <[email-masked]>
Date: Thu, 28 Sep 2000 08:44:05 +0200

At 03:00 PM 9/26/00 -0400, Martin Picard wrote:
>   mechanisms are necessary.

I know of a number of service providers, including BT etc, who are 
deploying services using QoS technologies. Whether or not the specific ones 
I am talking with are using MPLS in the same application, I can't say; I 
don't know, and I think some are and some aren't.

The above statement is indeed what most of the SPs say, but it misses a 
rather important fact. They are engineering their core to have enough 
bandwidth that they experience a low drop rate. That means that QoS 
perceived by their customers is not limited by their core. But it remains 
limited by the link between the edge network and the SP, which is supplied 
by the customer, and the delay and drop rates at the service provider end 
of that link are invisible to him. As often as not, it is specifically this 
link that will benefit from QoS technologies.

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 28 Sep 2000 11:54:23 -0400

> >   mechanisms are necessary.

Thats clearly what the ISP marketing people have to say.

The engineers have to deal with reality and some still assert that
timely delivery of bandwidth is not reality and an infinite budgest
doesn't make good business sense.  The engineers therefore have to
design for the possibility (which some still assert is inevitable)
that congestion will occur at times in various parts of the network.
If increase in access speeds outpace core deployment that includes in
the core.

The network also needs to degrade gracefully when massive outage
occurs.  A few examples in the past 5 or so years (from memory)
include earthquake in southern CA, CO fire in the Bay area, gas leak
(power everything down) in LA area, floods in the mid-west, Amtrak
wreck affecting both sides of track on East, gas company tearing up
wrong pipe (major fiber conduit), and a hurricanes in the East
affecting riverbed fiber, numerous smaller hurricane outages.  I'm not
in operations so this is just a very small subset covering only very
big outages.  The network can't just work well on sunny days.
Congestion avoidance is needed.

Curtis

---

From: Chris Cooper <[email-masked]>
Date: Thu, 28 Sep 2000 10:00:23 +0100

> link that will benefit from QoS technologies.

Yes, exactly.  I also have encountered this sort of assertion recently from
SPs.  But the basic issues seem not to have changed: see for example the
summary of the infinite bandwidth argument provided in RFC1633 by Bob
Braden, Dave Clark, and Scott Shenker in 1994.

Chris
-------------------------------------------------------------------
Chris Cooper			Email:	[email-masked]
Rutherford Appleton Laboratory	Tel:	+44 (0)1235 446211
Chilton 			Fax:	+44 (0)1235 445597 (NB.NEW)
Didcot,  Oxon  OX11 0QX,  UK

---

From: Ping Pan <[email-masked]>
Date: Thu, 28 Sep 2000 13:55:36 -0400

> Thats clearly what the ISP marketing people have to say.

Yes. 

From various studies (Vern Paxson...), it was shown that end-to-end
jitter can be quite high. Within core networks, packet delay and loss
may be low. But after going through multiple domains, NAP's and POP's,
not sure end-user service quality can be assured. (Some time back, I saw
data shown that Internet packets go through 5-6 domains on average....
That's quite a few networks to travel.)

> Congestion avoidance is needed.

Yep!

Another point here is the so-called Disruptive Innovation Effect (DIE).
Andrew Odlyzko of ATT Research had talked about that the Internet
traffic was doubled every 3-4 months in 1995 and 1996 due to the WEB
expansion. A similar traffic growth pattern was shown in some networks
last year sue to Napster. So unless SP's have some way (call it QoS
guarantees or Traffic Engineering or Flow Isolations...) to protect
existing users from sudden traffic bursts, I doubt that simply adding
bandwidth to the network is the solution. 

Finally, from all the conversations that I had with SP people, they all
complained about the complexity of managing QoS with the existing
protocols, tools and fancy architectures. I never hear any of them
saying that they don't need QoS.

> Curtis

- Ping

---

From: Randy Bush <[email-masked]>
Date: Thu, 28 Sep 2000 11:37:07 -0700

hi ping,

> jitter can be quite high.

i think it is actually less high inter-backbone than seems to be generally
thought.  e.g. i will append (humble apologies for the non-ascii, but it is
a picture) a ippm-style ripe traffic measurement between verio denver and
ripe in amsterdam.  there are outliers.

> Within core networks, packet delay and loss may be low. But after going
> through multiple domains, NAP's and POP's

i do not mean to be pedantic, but i am not aware of how, from a policy
routing perspective, traffic would go through multiple naps.  i push the
point because the suckyness (sp?) of some of the naps is one of the worst
sources of interprovider problems.

i am not sure what 'domains' are.  if you mean autonomous systems, then
this devolves to naps, inter-provider private circuits, and intra-provider
pops.

a few naps suck, but even they are supposedly being fixed.  and in the
interim, folk tend to route around them as much as possible.

as provisioning is the biggest pain in private peering engineering,
inter-provider private circuits tend to be overprovisioned just so they
don't have to be revisited.

intra-provider pops are back to the backbone overprovision issue.

> I saw data shown that Internet packets go through 5-6 domains on average.

i become more and more curious what a 'domain' is.

> saying that they don't need QoS.

complexity in the core is not known to improve reliability.

randy

---

From: Ping Pan <[email-masked]>
Date: Thu, 28 Sep 2000 15:20:50 -0400

> > jitter can be quite high.

Hello, Randy,
 
> ripe in amsterdam.  there are outliers.

Thanks for the info. Is it the data between two backbones over one NAP?
Is it generally the same for all inter-provider traffic?
 
> this devolves to naps, inter-provider private circuits, and intra-provider

I meant AS's. I first saw the data in http://moat.nlanr.net/ASPL/. I
chatted with one of my colleagues in Bell Labs (he had gone already) a
couple of months ago. He was working on inter-domain network topology
stuff, and collected bunch of more up to date traces. He told me that
the average AS length in his data was 5-6.

My point was that even though major transit ISP's (Verio and UUnet) can
control link congestion and transit delay within their networks, can all
your customers (regional ISP's) provide the same level of service to end
users? If no, what can we do about it? One solution may be to create a
MPLS tunnel with bandwidth guarantees from one regional ISP over the
backbones to another regional ISP...

Thanks!

--
Ping Pan         http://www.cs.columbia.edu/~pingpan

---

From: Randy Bush <[email-masked]>
Date: Thu, 28 Sep 2000 12:40:36 -0700

> Thanks for the info. Is it the data between two backbones over one NAP?

the picture was taken over something like the following route

[email-masked]> traceroute e01.overtoom.ripe.net    
traceroute to e01.overtoom.ripe.net (193.0.0.25), 30 hops max, 40 byte packets
 1  p1-1-0-0.r01.dnvrco01.us.bb.verio.net (129.250.3.62)  0.534 ms  0.489 ms  0.457 ms
 2  p1-2-0-1.r00.kscymo01.us.bb.verio.net (129.250.2.78)  11.269 ms  11.237 ms  11.257 ms
 3  p1-6-1-1.r01.dllstx01.us.bb.verio.net (129.250.2.217)  22.848 ms  22.899 ms  22.862 ms
 4  p4-2-0.r00.dllstx01.us.bb.verio.net (129.250.3.73)  22.818 ms  23.322 ms  22.811 ms
 5  209.245.240.153 (209.245.240.153)  86.399 ms  86.287 ms  86.496 ms
 6  so-6-0-0.mp1.Dallas1.level3.net (209.247.10.101)  86.477 ms  86.573 ms  86.574 ms
 7  209.247.10.42 (209.247.10.42)  92.251 ms  92.358 ms  92.316 ms
 8  209.244.3.189 (209.244.3.189)  165.139 ms  165.511 ms  165.184 ms
 9  loopback0.mp1.London1.l3.net (212.113.2.11)  161.098 ms  160.528 ms  160.053 ms
10  212.187.128.90 (212.187.128.90)  168.302 ms  168.535 ms  168.703 ms
11  loopback0.core1.Amsterdam1.Level3.net (212.72.32.1)  168.208 ms  168.320 ms  167.960 ms
12  loopback0.ams-ix.Amsterdam1.Level3.net (212.72.32.8)  168.958 ms  168.964 ms  168.704 ms
13  Amsterdam1.ripe.net (193.148.15.68)  170.335 ms  170.670 ms  169.932 ms
14  fe20.pampus.ripe.net (193.0.0.246)  170.295 ms  170.049 ms  170.053 ms
15  s10.overtoom.ripe.net (193.0.0.53)  171.447 ms *  171.890 ms

remembering that, due to hot potato (hmmm, time for lunch), symmetry should
not be assumed.

> Is it generally the same for all inter-provider traffic?

of large providers.

> the average AS length in his data was 5-6.

i can believe that is what is in the routing tables.  i suspect that the
average number of ass traversed by a packet is less.

> backbones to another regional ISP...

and this will manufacture bandwidth?  and this will scale for a few thousand
non-giant isps?

randy

---

From: Ping Pan <[email-masked]>
Date: Thu, 28 Sep 2000 15:52:18 -0400

Randy Bush wrote:
> and this will manufacture bandwidth?  

No. But it can provide admission control: if there is a bandwidth
bottleneck somewhere, don't send the data, or multi-homing to another
provider. 

> and this will scale for a few thousand non-giant isps?

Maybe not with the current mechanism. ;-)

---

From: Randy Bush <[email-masked]>
Date: Thu, 28 Sep 2000 13:08:26 -0700

> bottleneck somewhere, don't send the data

this has appeal.  but ecn looks much simpler.

randy

---

From: Olivier Bonaventure <[email-masked]>
Date: Fri, 29 Sep 2000 11:08:10 +0200

Ping,

> the average AS length in his data was 5-6.

Some time ago, we looked at the BGP routing table of the Belgian research ISP and
found a similar result. We looked at the number of reachable IP addresses
(i.e. IP addresses announced through BGP) and found that most
addresses were between two and 5 AS away from our small ISP. 

LEVEL = 1  ADDRESSES =  43131944   
LEVEL = 2  ADDRESSES = 177739421   
LEVEL = 3  ADDRESSES = 410798057   
LEVEL = 4  ADDRESSES = 347784802   
LEVEL = 5  ADDRESSES = 114262352   
LEVEL = 6  ADDRESSES =  14626560   
LEVEL = 7  ADDRESSES =    943360   
LEVEL = 8  ADDRESSES =    235264   
LEVEL = 9  ADDRESSES =      4352   

This concentration of the addresses is probably due to the fact that BGP
prefers shortest path (measured in AS path length) and thus ISPs tend
to establish as much peerings as possible to obtain short paths.
I'm not convinced that the shortest path in terms of BGP path length
is the best path, but that's how the market it working today.

Concerning QoS, an interesting point was mentionned this week at the COST263 QoS
workshop in Berlin, Germany by the IETF chairman (Fred Baker). Today, the main factor
againts the development of interdomain QoS are the ISPs themselves. They don't believe
that having interdomain QoS is the best solution from their selfish marketing/economical
point of view and they are relunctant to work on this topic. Since ISPs (at least big ones)
are not interested in interdomain QoS, network providers do not work on enhancing protocols
to support interdomain QoS since they don't see a business case for such features today.
The presentation is available from http://www.fokus.gmd.de/events/qofis2000/slides/25ix00/session-00/fred-baker-new.pdf

My personnal feeling is that interdomain QoS is key to the deployment of QoS within
the Internet. We won't really have QoS until we manage to find a suitable interdomain
method to provide it. I guess that small ISPs could have a strong interest in
such interdomain QoS, but they usually don't have people able to influence the work
within IETF or network equipment vendors. 

Olivier Bonaventure

---
http://www.infonet.fundp.ac.be

---

From: Randy Bush <[email-masked]>
Date: Fri, 29 Sep 2000 04:51:09 -0700

> is the best path, but that's how the market it working today.

not the market, the <bleep>ing protocol which has very weak metrics.

> Today, the main factor againts the development of interdomain QoS are the
> ISPs themselves. They don't believe that having interdomain QoS is the
> best solution from their selfish marketing/economical point of view

perhaps this charaterization is a bit off mark.  some large isps see a
complete lack of consideration of inter-provider issues in the protocols
going all the way back to the vendors who developed the requirements.

> My personnal feeling is that interdomain QoS is key to the deployment of
> QoS within the Internet. We won't really have QoS until we manage to find
> a suitable interdomain method to provide it. I guess that small ISPs could
> have a strong interest in such interdomain QoS, but they usually don't
> have people able to influence the work within IETF or network equipment
> vendors.

these days, no one can influence the vendors.

randy

---

From: Ping Pan <[email-masked]>
Date: Fri, 29 Sep 2000 13:01:44 -0400

Hi,

I am not sure shortest path is the default routing policy used by the
ISP's. But you also have to take two more things into consideration:

1. The AS-path information is what has been advertised by BGP. The
actual AS-path taken by data may be shorter depending routing
computation at border;
2. On the other hand, as I have noticed from a backbone route dump
months ago: the AS number received at border may be small due to *route
aggregation*. In reality, BGP route trace may not give us all the ISP
networks.

What will useful as an exercise is to run traceroute to/from many places
in the world, and take the results against the AS info in RADB. That may
give us better answer on the exact traversing ISP networks....

> point of view and they are relunctant to work on this topic.

That may not be ISP's fault. One critical issue is: how much data do you
want to reveal to your peers? You are inviting for trouble if you start
to propagate private peering information around.

Also, I feel that one of the major problems for Internet-wide QoS is the
protocols and the tools that we have. Unless we start to re-evaluate
what we have and present a better picture to the ISP's, they are not
going to risk their business to support a solution that is not reliable,
secure and scalable. 

The Paste solution from Yakov and Tony Li was a nice start. Please take
a look. 

Also, we have been working on an inter-domain solution based on some
measurement and the basic knowledge we had on ISP. Please check
http://www.cs.columbia.edu/~pingpan/projects/bgrp.html, and please
provide feedback.

- Ping

> Since ISPs (at least big ones)

---

From: Fred Baker <[email-masked]>
Date: Fri, 29 Sep 2000 15:07:24 +0200

>this has appeal.  but ecn looks much simpler.

Is ECN something that you would consider pushing toward standardization? I 
like it, but I'm looking for operator feedback, and some (notably Juha) 
distrust a mechanism that trusts the host.

---

From: Randy Bush <[email-masked]>
Date: Fri, 29 Sep 2000 23:00:39 -0700

> Is ECN something that you would consider pushing toward standardization?

i'm trying, i'm trying.

randy