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

From: Shahram Davari <[email-masked]>
Date: Fri, 22 Oct 1999 14:51:54 -0700

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/
>