Subject: RE: [Diffserv] DHCP user class

From: "Manfredi, Albert E" <[email-masked]>
Date: Sun, 9 Jul 2000 17:14:15 -0400

-----Original Message-----
> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Sunday, July 09, 2000 2:35 PM
> To: Diff Serv
> Subject: [Diffserv] DHCP user class
> 
> 
> Diffservers might want to look at
> http://www.ietf.org/internet-drafts/draft-ietf-dhc-userclass-08.txt
> 
> It's already passed last call and is on the IESG's plate. But it
> says
> 
>    It is often desirable to provide different levels of service
>    to different users of an IP network.
>    In order for an IP network to implement this service
>    differentiation, it needs a way to classify users. A simple
>    solution to this is to use source IP addresses for classification.
>    Under this scheme, network administrators first configure network
>    devices such as routers to recognize traffic from a particular
>    source IP address (or address range) and handle it specially to
>    meet the desired level of service. 
> 
> If you think this is a good/bad idea, *now* is the time to say so.
> 
>    Brian

Here's a little more quoted:

"This document describes a simple extension of the DHCP protocol
that enables a DHCP server to assign IP addresses from different
address pools depending on the type of users from which it receives
DHCP requests. With this new extension, network administrators will
be able to use DHCP to hand out the appropriate addresses to clients."

The reason I quoted this is that it seemed strange to assign service
category based only on the source IP address, and that extension explains
that the address assigned by DHCP would indeed depend only on the host,
_not_ on the application_s_ the host was going to be running. The DHCP
server obviously won't know the applications that would be running until
after the IP address is assigned.

Reading further into the I-D does not dispell this notion.

Seems like a strange idea in a time of multimedia apps? Request for service
differentiation belongs at the application layer, maybe not exclusively, but
that should be the norm.

Bert
[email-masked]

_______________________________________________
diffserv mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/

---

From: "Yoram Bernet" <[email-masked]>
Date: Mon, 10 Jul 2000 10:27:31 -0700

I think I concur...

I think that it is important that the draft document the limitations of
the DHCP approach and acknowledge the recommendations in the issll
drafts on using RSVP, with user ID policy objects, for providing the
network with classification information. When such signaling is
available to provide the network with the classification information
corresponding to users, it seems to be a preferable approach. For cases
in which signaling is not available, the dhcp approach might be used.

Y 

> From: Grenville Armitage [mailto:[email-masked]]
> Sent: Sunday, July 09, 2000 4:02 PM
> To: Brian E Carpenter
> Cc: Diff Serv; [email-masked]
> Subject: Re: [Diffserv] DHCP user class
> 
> 
> Brian,
> 
> At the very least the first half of the current introduction
> is a speculative description of a service differentiation scheme
> that hasn't been documented anywhere else in the IETF to my
> knowledge. There are no citations to models. I hope the IESG will
> request that the document authors either clarify the relationship
> between Diffserv/Intserv and their service differentiation model,
> or simply remove the 'classify on source address' example.
> 
> cheers,
> gja
> 
> Brian E Carpenter wrote:
> > 
> -- 
> ______________________________________________________________
> __________
> Grenville Armitage                    
> http://members.home.net/garmitage/
> Bell Labs Research Silicon Valley
>

---

From: "Casati, Alessio (Alessio)" <[email-masked]>
Date: Mon, 10 Jul 2000 22:00:26 +0100

I'd share with this set of 
writers the things they tell us about, 
however it's also true that
there may be some hosts around (i.e. hosts 
not equipped with signaling capabilities) 
for which the mentioned router
feature assisted by DHCP is a good thing .

What the piece of text mentions is just an 
example and is not anything mandated by the 
document, so the IESG may not
have/want to use their time on this. 
Or, if they are in nit picking mode,
just suggest a cautionary statement 
on the fact that this example is limited
to the enterprise/local scope, and not for an 
end to end purpose.

alessio

> ----------
> From: 	Yoram Bernet[SMTP:[email-masked]]
> Sent: 	10 July 2000 18:27
> To: 	Grenville Armitage; Brian E Carpenter
> Subject: 	RE: [Diffserv] DHCP user class
> 
> I think I concur... 
> 
> the DHCP approach and acknowledge the recommendations in the issll drafts
> on using RSVP, with user ID policy objects, for providing the network with
> classification information. When such signaling is available to provide
> the network with the classification information corresponding to users, it
> seems to be a preferable approach. For cases in which signaling is not
> available, the dhcp approach might be used.
> 
> Y 
> 
> > From: Grenville Armitage [ mailto:[email-masked]]

---

From: "Gary Kenward" <[email-masked]>
Date: Mon, 17 Jul 2000 16:24:10 -0400

I believe the intent is to provide an additional dimension for service
differentiation
in addition to application stream related differentiation. For example, an
application
in use by user A would receive a different, perhaps improved, service over
the service
provided by the same application in use by user B. The actual
differentiation supported
would be up to the service provider.

The only issue that I can see with using the IP address is that all
applications
on the host using that IP address will be impacted. Thus, for example, if
the objective is
to give user A's video streams better service, then user A's email stream
will
likely be given relatively better service over other users email.

The only solution I can see o providing user differentiation on a per
application basis
is one based upon request/assignment (e.g. Diff Edge).

Gary Kenward

==========================================================================
Gary W. Kenward
[email-masked]
Advisor, Wireless Architecture               (613) 765-1437
Advanced Technology Labs                      ESN 395-1437
Wireless Solutions                                  FAX: (613) 763-2686
==========================================================================

As far as the laws of mathematics refer to reality, they are not certain;
and as far as they are certain, they do not refer to reality.
-- Albert Einstein

The contents of this email are Nortel Networks Confidential

> From: Manfredi, Albert E [mailto:[email-masked]]
> Sent: Sunday, July 09, 2000 5:14 PM
> To: 'Brian E Carpenter'; Diff Serv

---

From: Jay Wang <[email-masked]>
Date: Tue, 18 Jul 2000 10:33:10 -0700

I think the issue is realistic but irrelevant to the DHCP extension
because without this DHCP extension you still have the same issue,
namely how to provide differentiate service for a single IP address.
To address this, you can have a MF classifier which distinguished flows
based on multiple fields on top of the source IP address.
 
- Jay Wang

-----Original Message-----
From: Gary Kenward [mailto:[email-masked]]
Sent: Monday, July 17, 2000 1:24 PM
To: 'Manfredi, Albert E'; 'Brian E Carpenter'; Diff Serv
Subject: RE: [Diffserv] DHCP user class

Gary Kenward 

> From: Manfredi, Albert E [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> > From: Brian E Carpenter [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> > http://www.ietf.org/internet-drafts/draft-ietf-dhc-userclass-08.txt
<http://www.ietf.org/internet-drafts/draft-ietf-dhc-userclass-08.txt>  
> [email-masked] 
<http://www1.ietf.org/mailman/listinfo/diffserv>  
> Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/
<http://www-nrg.ee.lbl.gov/diff-serv-arch/>