Subject: Re: More than sender tagging?

From: Scott Huddle <[email-masked]>
Date: Thu, 6 Nov 1997 15:49:25 -0500

> >Upon further thought, I may have written too quickly, so
> >	(1) No it doesn't have to look anything like RSVP, AND
> >	(2) It could be easy via reuse of a common marking mechanism
> >What's required is that sufficient care be taken to avoid overspecification
> >of the sender-based marking mechanism to unnecessarily prohibit receiver-
> >based marking.  I.e., as Eric said:
> >
> >> What I'm trying to separate here is the mechanism from the economics.  We
> >> don't want to choose the economic models for the service providers.  We
> >> want to provide a set of tools for them to create service offerings that
> >> they can use to stay competitive.

Indeed.  Don't all of these boil down to ...

	"Let the providers mark the headers however they want
	[perhaps with cues from their users] and map services
	as best they can betwen providers"

And let the market decide on the abilites of providers to deliver
services	
	.	on their network
	.	across their network and to other providers

rather than roping off specific bit settings as sacrosanct

> I agree. And this is why I oppose to allocating (possibly unnecessarily)
> large number of bits to drop preference and delay levels before even having
> a chance to consider other problem dimensions like receiver-based marking (who
> knows what else to come), and before we have some technical conviction
> that so many bits are really necessary for particular fields.
 
Like geographic based marking, policy based marking, destination based
marking, application based marking, etc

-scott

---

From: "Alessio Casati" <[email-masked]>
Date: Fri, 7 Nov 1997 12:04:33 +0100

On  6 Nov 97 at 15:49, Scott Huddle wrote:

[...]
> rather than roping off specific bit settings as sacrosanct

Scott,
In principle no comment about it.What you say is equivalent to let ISPs to be 
free on both syntax and semantic. But the problem you are going to run into is
that at some point, where packets from many different ISPs get mixed, if too much a degree
of freedom is left to each and every ISP to offer services, then you would need
either too a fine granularity or incur in resorce wasting. We definetly need to define the
semantic of some differential sevices (using as few bits as possible), then any provider
can make the best use of them.

As to the Zheng's User-Share Based Differentiation (USD) it has some
interesting properties, though I have some comments.

1) Is the buffer managed somehow?
2) How a user requiring an average x bit/s throughput is accomodated in your framework?
3) How do weights migrate from router to router as route changes?
4) How do you explain to the residential or business user you must buy 3 shares instead of 4 if he
   has not (even statistical) guarantee at all on the bandwih advantage, in terms of
   Kbit/s?
5) If you aggregate in some hierachy, then you loose flow protection if congestion occurs
   after the ISP aggreagation point, shares are not at all guaranteed.

---

From: Zheng Wang <[email-masked]>
Date: Fri, 07 Nov 1997 11:59:53 -0500

> 1) Is the buffer managed somehow?

There are a lot of ways of managing the buffers under WFQ. There is a paper
in the forthcoming INFOCOM'98 on various schemes.

> 2) How a user requiring an average x bit/s throughput is accomodated in your framework?

WFQ allows you to do that if that's what you want to do.

> 3) How do weights migrate from router to router as route changes?

The weights are agreed at the subscription time and dont change
unless the subscription changes.

>    has not (even statistical) guarantee at all on the bandwih advantage, in terms of

This issue is independent of the scheme we will use (think about what one
does with tagging).

If an ISP knows the average number of users on a link, it is very easy 
to translate "shares" into actually bandwidth.

>    after the ISP aggreagation point, shares are not at all guaranteed.  

An ISP can become a user of its backbone provider and its aggregated flow
will be protected. Sure, the individual flows are aggregated but it is
just impossible to do aggregation and still protect individual flows
inside the aggregated flow.

Cheers
Zheng

---

From: "Alessio Casati" <[email-masked]>
Date: Mon, 10 Nov 1997 10:16:37 +0100

> in the forthcoming INFOCOM'98 on various schemes.

Yes, ok, but I think it must be managed in FQ, oterwise we get back to the
old lock-out problems we talked about somethimes ago. So yours isn't a framework
but an implementation of differentiated services.

> WFQ allows you to do that if that's what you want to do.

Yes, but was your new service proposal the suggestion of how to use WFQ?  It doesn't seem
a good way of getting on with our standardization effort. Please tell me if I'm wrong or
missing some major point.

> unless the subscription changes.

Maybe I'm missing something. Are you sure this is the reply to my question?

> This issue is independent of the scheme we will use (think about what one

With tagging a user is allowed to send packets according to a profile. The profile may be
defined in terms of allowed Kbit/s. The provider must try its best (and on unsuccess the customer 
may complain) to grant the committed profile.

> to translate "shares" into actually bandwidth.

yes, so why would you define a sevice in terms of shares? And why a user shouldn't be
provided with a threshold on his allowed sending rate? This would make him aware when is
behaviour is considered bad by the network.

> inside the aggregated flow.

So It definetly isn't true a user with 3 shares is always guaranteed 3 times more
resources than a user with 1 share.

I ask you to help me in having a better understanding of your service.
As I understood it it's an implementation of a service to be defined in a
different way.

alessio

---

From: Jon Crowcroft <[email-masked]>
Date: Mon, 10 Nov 1997 09:27:59 +0000

here is a possible alternate view...

 >resources than a user with 1 share.
 
the point about differential services (i believe) is that they are an
extrension of the "fair share" approximation that we currently get IFF
everyone operates a perfect TCP like algorithm (and everyone operates
a fairly reasonable RED implementation), and  basically, this
gives a form of fairness which is a proporitional share of scarce
resources:
see:
http://www.statslab.cam.ac.uk/~frank/rate.html
for why

a neat consequence of this, if implemented right, is that you do not
need to specify any compelx parameters AT ALL

now, the differential we are trying to introduce is JUST a weight to
this share (i.e. the ability for a single sessio nto use multiple
shares) - i.e. to let the user ask for n shares

this needs more complex policing than RED, but not much....

the point of having a bit of any kind is to say that EVEN in this 
simple scenario, only some users wnat more than 1 share per session,
so we only want to implemnt this minmal extra complexity for those
users, and the bit is the clue who they are.....

the rest is achieved by pricing..

 jon

---

From: Zheng Wang <[email-masked]>
Date: Mon, 10 Nov 1997 11:49:32 -0500

> So yours isn't a framework

What I proposed is a framework but I also show that it can be implemented
with known techniques. WFQ (and its many variations for fast
implementation) is well understood in the int-serv work in the past.

> Yes, but was your new service proposal the suggestion of how to use WFQ?  

No. Whether an ISP can guarantee x bps is a issue of provision. If an ISP
dimensions its network right, the number of "shares" can be translated into
x bps and vice verse. But the User-Share proposal does not impose provision
as a condition. If a link is congested for some reasons, the sharing is
determined by the shares assigned to the users.

> > > 3) How do weights migrate from router to router as route changes?

The weights, like profiles, do not change from routes to routes.
They will be distributed via some protocols such as SNMP ...

> may complain) to grant the committed profile.

As I said before, it is difficult to come up with a good x bps 
unless an ISP is well provisioned for the worst case.

> yes, so why would you define a sevice in terms of shares?  

Because I dont want to impose the provision as a condition to ISPs. 
If you define the service in relative term (i.e., shares). It will 
work when the provision is not perfect (sharing according to the weights).
When the provision is right, the equivalent x bps of a share becomes
stable.
  
Cheers
Zheng