Subject: RE: [Diffserv] RE: Two new Internet-Drafts submitted

From: "Black, David" <[email-masked]>
Date: Fri, 22 Oct 1999 18:08:59 -0400

Two more options:

(1) Customer runs an inbound traffic classifier at
each interface from the ISP to remark the traffic
for its internal network.

(2) The ISP structure is fully tunneled (e.g., IP in IP)
so that the inner header is preserved.  This is easy
to do if the ISP is providing a VPN via IPsec tunnels.

In general, it strikes me that the service of "preserve
the customer's DSCP values" is added value that an ISP
could charge for.

The tunnels draft I recently submitted,
draft-black-diffserv-tunnels-00.txt has some related material.
http://www.ultranet.com/~dlb237/drafts/draft-black-diffserv-tunnels-00.txt
can be used until the draft makes it to the I-D servers.

--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140, FAX: +1 (508) 497-6909
[email-masked]
---------------------------------------------------

> -----Original Message-----
> From:	Shahram Davari [SMTP:[email-masked]]
> Sent:	Friday, October 22, 1999 5:52 PM
> To:	'Chiu, Angela L, ALSVC'; Tony Hain (Exchange); Kathleen Nichols;
> Brian E Carpenter
> Cc:	[email-masked]
> Subject:	RE: [Diffserv] RE: Two new Internet-Drafts submitted
> 
> Hi,
> 
> Since there is only a single DS field in the IP header, the only practical
> way to preserve the enterprise marking, is to use a tunnel such as MPLS
> tunnel, and use the Label as an extra level of Diffserv hierarchy.
> 
> Regards,
> Shahram  
> 
> > -----Original Message-----
> > From: Chiu, Angela L, ALSVC [mailto:[email-masked]]
> > Sent: Friday, October 22, 1999 2:06 PM
> > To: Tony Hain (Exchange); Kathleen Nichols; Brian E Carpenter
> > Cc: [email-masked]
> > Subject: RE: [Diffserv] RE: Two new Internet-Drafts submitted
> > 
> > 
> > Tony, Kathy, and Brian,
> > 
> > I would like to raise a related issue (I don't know if this has been
> > discussed before).
> > 
> > When an ISP offers Diffserv-based service classes, it needs to perform
> > traffic policing/marking at all edges. What happens to some customers'
> > traffic if they only want the current "best effort" service 
> > while using
> > 6-bit DSCP to prioratize their traffic to be used at customer 
> > premises at
> > both ends? 
> > 
> > I can see two options:
> > 
> > (1) Remark all traffic from those customers with Default PHB 
> > marking, and
> > tell customers that they should not use any of the Diffserv 
> > DSCP marking
> > that the ISP uses. 
> > This option is easy for the ISP, but may not be friendly to 
> > the customers
> > since they need to design their marking scheme according to 
> > what the ISP
> > uses, which might be changed from time to time.
> > 
> > (2) Remark the packets that have non-default marking from 
> > those non-QoS
> > customers with some DSCP setting that the ISP is not using, 
> > and map (i.e.,
> > remark) it back to the original value at the exist point. 
> > This option is customer-friendly, but puts more burden to ISPs.
> > 
> > Just some simple thoughts for discussions. I can see the 
> > cases can get more
> > complicated when a customer subscribed to one of the N 
> > classes of services,
> > but use the DSCP marking for the other N-1 classes.
> > 
> > Angela Chiu
> > 
> > AT&T Worldnet
> > Room C4-3A22
> > 200 Laurel Ave.
> > Middletown, NJ 07748
> > Tel. (732) 420-2290
> > Fax (732) 368-1746
> > Email: [email-masked]
> > 
> > > -----Original Message-----
> > > From:	Tony Hain (Exchange) [SMTP:[email-masked]]
> > > Sent:	Friday, October 22, 1999 1:54 PM
> > > To:	Kathleen Nichols; Brian E Carpenter
> > > Cc:	[email-masked]
> > > Subject:	[Diffserv] RE: Two new Internet-Drafts submitted
> > > 
> > > Kathie & Brian,
> > > 
> > > What this definition provides is an elevation of the 
> > Default BA to one
> > > step
> > > above the strictly defined Best Effort service. In that 
> > context it is new.
> > > 
> > > Brian was calling for more deployment experience before 
> > defining something
> > > new, but I have been in several meetings recently where 
> > there will be no
> > > deployments until a service behavior is defined which 
> > treats existing
> > > traffic (the Default BA) as protected from the new 
> > background traffic
> > > service. We are at a deadlock without this spec.
> > > 
> > > In a perfect world you could argue that all traffic needs 
> > to be marked
> > > appropriately, but the deployed net isn't perfect. It is 
> > incumbent on the
> > > new service to provide the hooks to work around the legacy 
> > traffic, so
> > > elevating the default behavior requires the definition of 
> > LBE, unless you
> > > want to rework all the previous text to change 'best 
> > effort' to 'default
> > > behavior'. 
> > > 
> > > Tony
> > > 
> > >  -----Original Message-----
> > > From: 	Kathleen Nichols [mailto:[email-masked]] 
> > > Sent:	Thursday, September 23, 1999 10:00 AM
> > > To:	Brian E Carpenter
> > > Cc:	[email-masked]
> > > Subject:	Re: Two new Internet-Drafts submitted
> > > 
> > > 
> > > Right. With this definition, LBE requires a "certain share". Since
> > > that would mean non-starvation (if you have a share, no matter how
> > > small, you aren't starved), then I think this PHB doesn't really
> > > add anything new.
> > > 
> > > 	Kathie
> > > 
> > > Brian E Carpenter wrote:
> > > > 
> > > > Thanks for the clarification.
> > > > 
> > > > RFC 2474 says nothing about link shares for the default PHB.
> > > > It just says that default traffic gets whatever is left when
> > > > all other PHBs have been satisfied, subject to a fuzzy
> > > > non-starvation rule. I still don't see how that leaves any space
> > > > for LBE, or any useful application.
> > > > 
> > > >    Brian
> > > > 
> > > > Roland Bless wrote:
> > > > >
> > > > > Brian Carpenter said:
> > > > > > I must confess I have a deep intellectual problem 
> > with LBE. Since
> > > the
> > > > > > definition of BE seems to me to mean "whatever is 
> > left after all
> > > > > > other PHBs have been satisfied", then the capacity available
> > > > > > for LBE is identically zero.
> > > > >
> > > > > No, that's not the LBE PHB definition from the draft. 
> > There are some
> > > > > examples for its usage given in the draft. Maybe I 
> > should have better
> > > > > used another name for this PHB if it's so confusing for 
> > people. To
> > > quote
> > > > > the LBE PHB definition from the draft:
> > > > >
> > > > > "The LBE PHB is essentially defined by its relation to 
> > the default
> > > PHB:
> > > > > an LBE packet is of minor relative importance compared to a
> > > best-effort
> > > > > packet.  Thus, in case of contention for bandwidth 
> > (i.e., a congestion
> > > > > situation), packets receiving best-effort treatment 
> > preempt packets of
> > > > > the LBE behavior aggregate down to a certain share.  
> > This share must
> > > be
> > > > > considerably lower than that of the best-effort BA, but 
> > should not be
> > > > > equal to zero in order to retain a low portion of LBE 
> > traffic even
> > > when
> > > > > best-effort traffic takes up all available residual bandwidth.
> > > > > Therefore, a minimum configured bandwidth share for LBE 
> > traffic exists
> > > > > as a lower bound that guarantees transport of LBE 
> > packets even in case
> > > > > of congestion.  On the other hand, this bound also 
> > constitutes an
> > > upper
> > > > > limit for the share of LBE traffic during congestion.  
> > This upper
> > > bound
> > > > > may be static, that is, fixed in relation to the 
> > overall available
> > > > > bandwidth on a particular link (a constant value for 
> > 100-Y in Fig. 2),
> > > > > or it may be dynamic, i.e., fixed relative to the BE 
> > traffic share,
> > > thus
> > > > > variable in relation to the overall available 
> > bandwidth, because BE
> > > > > traffic may consume resources currently not used by other BAs (a
> > > dynamic
> > > > > value for Y that depends on the amount of BE traffic; 
> > corresponding to
> > > a
> > > > > constant ratio of (100-Y)/(100-X) in Fig. 2)."
> > > > 
> > > > --
> > > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> > > > Brian E Carpenter (IAB Chair)
> > > > Program Director, Internet Standards & Technology, IBM 
> > Internet Div
> > > > On assignment for IBM at http://www.iCAIR.org
> > > > Non-IBM email: [email-masked]
> > > 
> > > _______________________________________________
> > > diffserv mailing list
> > > [email-masked]
> > > http://www.ietf.org/mailman/listinfo/diffserv
> > > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/
> > 
> > _______________________________________________
> > diffserv mailing list
> > [email-masked]
> > http://www.ietf.org/mailman/listinfo/diffserv
> > Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/
> > 
> 
> _______________________________________________
> diffserv mailing list
> [email-masked]
> http://www.ietf.org/mailman/listinfo/diffserv
> Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/

---

From: JR Rivers <[email-masked]>
Date: Fri, 22 Oct 1999 15:53:44 -0700

It seems that the ISP could use locally administered DSCPs to
provide EF/AF type services.  Customers that pay for that type
of service could have the DSCP values of their frames "translated"
at from/to the "well-known" values at ingress/egress.  Inside
the ISP's domain, the "well-known" values would all be treated
as best effort, and the special treatment applied to the locally
administered values.

This perspective seems to make reasonable business sense since
you only "touch" interfaces that belong to people who pay more 
money.

JR