Subject: Re: Bandwidth Brokers

From: Zheng Wang <[email-masked]>
Date: Mon, 05 Jan 1998 17:29:41 -0500

> > I think we do, but to make sure ;-) let me draw a small picture.
> > What I'd like to be able to have without too much headache is the
> > following:
> >
> >    ------        ----------------        ------
> >   /RSVP  \      /                \      /RSVP/ \
> >  /IntServ \    /                  \    /Intserv \
> >  |enabled |----| Diffserv Backbone|----|enabled |
> >  \network /    \                  /    \network /
> >   \      /      \                /      \      /
> >    ------        ----------------        ------
> >      AS1              AS2                  AS3

I think the above is fine for some applications such as video
conferencing
or maybe internet telephony where the session is long lasting.

However, for Web-based traffic (short-lived and rapidly changing
connections),
RSVP (or any on-demand signaling approaches) simply does not work. For
that,
we need bulk bandwidth allocation on an aggregated basis (something does
not
change all the time such as the network prefix to which the traffic
going to)
and better provisioning. 

Think about how we do timesharing on mainframes. We dont ask users to
make
cycles reservation before they start to run their programs. We allocate
cycles
to users and we police on a per-user basis rather than tracking
each process. The network sharing can essentially be viewed as a group
of users sharing multiple computers.

Cheers
Zheng

---

From: Roch Guerin <[email-masked]>
Date: Mon, 05 Jan 98 18:56:35 -0500

>However, for Web-based traffic (short-lived and rapidly changing connections),
>RSVP (or any on-demand signaling approaches) simply does not work. For that,
>we need bulk bandwidth allocation on an aggregated basis (something does not
>change all the time such as the network prefix to which the traffic going to)
>and better provisioning. 

Zheng,

I think that what you are pointing out here is that the current "filter specs"
are not adequate for all applications, i.e., have too fine a granularity.
I think there is agreement that it would be desirable to define new filter
specs that would allow coarser grain reservations, e.g., to a subnet prefix,
and as a matter of fact Jim Boyle had submitted such a proposal to define
new filter specs based on CIDR prefixes (draft-rsvp-cidr-ext-00.txt).

The issue is how do you install the reservation whenever a new request is made.
If they are very infrequent you can argue that you can rely on configuration, or
even simple provisioning as some people believe.  You could also introduce
yet another signalling protocol.  Alternatively, you could extend an existing
signalling protocol such as RSVP.  I would prefer this latter choice, but it
also does not mean that I would carry forward for new filters *all* the current
RSVP capabilities.  You can start with a rather simple subset and move from
there (I believe Yoram made that same point in one of his notes).

Roch

---

From: Zheng Wang <[email-masked]>
Date: Tue, 06 Jan 1998 10:46:17 -0500

Roch Guerin wrote

> The issue is how do you install the reservation whenever a new request is made.

Since we dont know where the destinations are web surfing, and 
we could go to several different places in a very short time interval, 
on-demand reservation does not work well in such situations. Also, 
with web traffic and some other traffic such as email, we dont
really know how much bandwidth reservation is appropriate. In many
cases, we dont really care that much. But we still want to know
that we are getting what we paid for.

I believe there is a case for two types of reservation/allocation:

1) Long-term aggregated bandwidth allocation. The allocation is decided
at the subscription time and applies to all traffic to and from a
customer
(including web traffic, email, ftp, telnet ...). Such long-term
allocation 
can really simplify charging since it is settled at the subscription
time.

Such long-term allocation provides a way of doing hierarchical 
provisioning. Customers provision for their own needs through the
long-term aggregated allocation, and ISPs can then plan and provision
their networks based on customers' subscription.

2) On-demand bandwidth reservation. Such reservation can be made
on-demand
for certain applications such as video conferencing, where the sessions
are long lasting and applications have fairly stringent bandwidth
requirements.  

Cheers
Zheng

-- 
Zheng Wang                  
Bell Labs Lucent Technologies
http://www.bell-labs.com/user/zhwang

---

From: Jon Crowcroft <[email-masked]>
Date: Tue, 06 Jan 1998 17:01:12 +0000

In message <[email-masked]>, Zheng Wang typed:

 >>on-demand reservation does not work well in such situations.

well i am not so sure about this
1/ assuming it is a surf/brose session and not a
robot/spider/altavistababy, then we are assured that there's ony 1
consumer
2/ web sites could (if caches and spiders were smart) tell us the
probability of spatial locality of references after a first reference
3/ such statistics could start to look like a sort of phonecall with a
roving termination at the far end from the user, but rather than zero
knowledge, we'd have a drunakards walk of possible succesive end points
- over a large number of connections at any one time, one could get
very good utilisation....since the walks would like follow similar
paths drawn from the well known set...so just like with POTS call
statistics, we could actually do quite well (eventually)
4/ in anycase, we can monitor the popularity of web sites and assume
that the statistics for the relatively smaller number of server sites
are accurate, and make a dimensioned call for each client on the basis
of this even without actual specific spatial locality knowledge....we
could still get good temporal aggregation....

5/ for spiders/robots, sicne they are probably also following a rate
controlled webcrawl pattern, we might even ask them for that as input
to our call admission deciscion.....if not, we just charge them a lot
on the basis that they can pass it on in their advertising fees:-)

 >>are long lasting and applications have fairly stringent bandwidth

 cheers

   jon

---

From: Bala Rajagopalan <[email-masked]>
Date: Tue, 06 Jan 1998 13:36:33 -0500

Zheng Wang wrote:

> on-demand reservation does not work well in such situations....
> 

You're still left with the problem above, i.e., not knowing the
set of destinations apriori and the traffic flow to each. Perhaps
the bandwidth on the access line from a customer to a provider
may be allocated this way, but the provider must still figure out
the traffic flow inside his network to make proper allocations.
May be the allocation can be done, but I don't see how
the charging can be simple when you don't know where a customer's
traffic actually goes? For instance, some customer
might generate a lot of traffic to Australia neccessiating crossing
many provider networks (with higher overall resource usage)
and another guy might be sending a lot
of his traffic next door. The obvious solution is 
resource-usage insensitive charging, but this doesn't
make good economic sense?

> are long lasting and applications have fairly stringent bandwidth

And you know the endpoints and can charge intelligently?

Regards,

-- 

Bala Rajagopalan
NEC USA, C&C Research Labs
4 Independence Way
Princeton, NJ 08540
U.S.A

Ph: +1-609-951-2969
Fax: +1-609-951-2499
Email: [email-masked]

---

From: David Black <[email-masked]>
Date: Tue, 06 Jan 1998 17:21:52 -0500

> set of destinations apriori and the traffic flow to each.

That's not a problem to be solved, that's a feature to be coped with.  There's
a granularity below which breaking out the traffic and charging for it
individually doesn't make sense.  There are also strong marketing advantages to
unlimited usage and increasing degrees of insensitivity to the destination.

> Perhaps
> of his traffic next door.

I think there's an incorrect assumption behind this.  Differentiated
Services need to work in an environment where one doesn't and can't know
all of this information down to the last detail.  The strategy is to rely
on average behavior (e.g., some customer might generate a lot of traffic
to Australia, but this is balanced out by the others who don't), and admit
that one is going to get nailed in extreme circumstances.  For web surfing,
it's sufficient to define a service that is better than the current best
effort service most of the time -- if this is done via drop preference, the
guarantee is not that the differentiated web traffic is never dropped, but
rather that if it starts seeing congestion effects, the undifferentiated
best effort traffic on the congested link is getting almost entirely dropped.

> The obvious solution is  resource-usage insensitive charging, but this
> doesn't make good economic sense?

I beg to differ.  This is the most common charging model for local phone
service, and is quite popular for regional toll calls.  For example, in
Mass., the local phone carrier was ordered to refund money to its customers
by introducing an unlimited usage plan that covered most of the eastern
part of the state.  It didn't work out as planned because a lot of people
who were spending less than the plan fee each month signed up for the plan.
The local phone companies seem to be doing quite nicely from a financial
standpoint.

--David

============================================================================
David L. Black            THE OPEN GROUP     Voice: +1 (617) 621-7347
The Open Group                                 Fax: +1 (617) 621-8696
Eleven Cambridge Center      RESEARCH       E-Mail: [email-masked]
Cambridge, MA  02142        INSTITUTE         http://www.opengroup.org/~dlb/
============================================================================

---

From: Zheng Wang <[email-masked]>
Date: Wed, 07 Jan 1998 10:15:43 -0500

Jon  

I agree that customers may collect statistics on their traffic and
provision
their bandwidth more accurately. But the allocation should still be
aggregated
and long-term, rather than on-demand for transaction-oriented
applications.

Cheers
Zheng

---

From: Zheng Wang <[email-masked]>
Date: Wed, 07 Jan 1998 10:35:17 -0500

> make good economic sense?

You can simplify the charging because you are essentially doing
"bulk purchase" of bandwidth. For example, Lucent can look at 
its Internet traffic requirements and discuss with its ISP (ATT)
then agree that Lucent will pay for a 1% slice of ATT's Internet
Backbone
plus some "virtual leased lines" over specific paths for VPN.
So the single subscription covers the majority of Lucent's Internet
traffic.
Sixe months later, Lucent may look at its traffic and increase its share
or maybe increase share just for some points (on the pipe to UK for
example).

Cheers
Zheng

---

From: Bala Rajagopalan <[email-masked]>
Date: Wed, 07 Jan 1998 10:44:30 -0500

David Black wrote:
> Differentiated

No arguments on the need for diff serv. What I'm trying to point out
are:

1. diff serv relies on fairly complex management and engineering
support.
Thus, it's not as "simple" as portrayed, but rather the complexity
is pushed offline.

2. the flat rate charging model may be convenient but is not
equitable and I think some evolution is needed for the sake
of profitability. If there's sufficient financial motivation,
I believe even per flow QoS will happen.

> service, and is quite popular for regional toll calls. 

But consider long distance calling, with different tarrif structures
for different countries. One would expect a service provider to
pay for using remote resources in one way or other and this cost
has to percolate to users in some fair manner.

Regards,
-- 

Bala Rajagopalan

Ph: +1-609-951-2969
Fax: +1-609-951-2499

---

From: Jon Crowcroft <[email-masked]>
Date: Wed, 07 Jan 1998 15:47:58 +0000

Zheng

sure....the idea i have is that if client a sequentially calls web sites A,B,C
and client b calls web sites B,C,A ad client c calls sites C,A,B, we
may well see an overal traffic statistic just like a calls A, b calls
B and c calls C for 3 times the duration

persistent HTTP (esp. if it can aggregate traffic) togerther with
cache hierarchies will make this all the more effective...

search engines may make it worse for the time being, but not in the
long runb when they should be co-located with the cache/proxy
servers...
 cheers

   jon

---

From: Rajesh Talpade <[email-masked]>
Date: Wed, 7 Jan 1998 11:09:03 -0500 (EST)

> and long-term, rather than on-demand for transaction-oriented

A heirarchical approach is possible. wherein the provisioning becomes
increasingly aggregated as we go away from the network edges and towards
the core.

So for example, inidividual users can provision on an application basis at 
the network edges, however the provisioning might be on a per client
level at the ISP interconnection point, where a client may be a company.

Then having individual users collect their statistics will help their
provisioning as well as enable the ISP's client to provision from the
ISP.

Ciao.
Rajesh.

-- 
Rajesh R. Talpade    [email-masked]   973 829-{4261, 5888(fax)}
Research Scientist, Bellcore, 445, South St, Morristown, NJ-07960