Subject: Re: [Diffserv] RE:

From: Brian E Carpenter <[email-masked]>
Date: Fri, 01 Feb 2002 09:25:07 +0100

Now we really are getting into implementation and deployment questions,
which are suitable for
http://www.atnf.csiro.au/news/exploders/dsimplementation.html

   Brian

Lei Yao wrote:
> 
> Would the access links be the most likely congestion points to protect?
> 
> Lei
> 
> -----Original Message-----
> From: Andrzej Czerczak [mailto:Andrzej_Czerczak/[email-masked]]
> Sent: Thursday, January 31, 2002 10:31 AM
> To: [email-masked]
> Cc: [email-masked]; Brian E Carpenter; Steve Silverman
> Subject:
> 
> Hi,
> I hope you agree, that it has to be provisioned only in the places where it
> makes sense -> where you have scare resources and where you need to
> differentiate treatment of the traffic, eg. to schedule it differently or
> route it to different TE-tunnel (with different traffic parameters) -> I
> hope that none will claim that's the violation of diffserv architecture.
> Openly, with xDSL concetrators/routers the gain of implementation of
> complicated scheduling mechanism would probably be to high to be returned.
> This approach reduce the number of routers where you configure treatment
> per group of users.
> 
> rgrds,
> Andrzej
> 
> >Andrzej,
> 
> >Even for a single service provider's network, your suggested approach is
> not
> >trivial to implement. You have to proxy on EVERY edge router for the
> >"priority" groups and "non-priority" groups. How can it be provisioned?
> 
> > Lei
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Andrzej Czerczak
> Sent: Thursday, January 31, 2002 9:30 AM
> To: Steve Silverman
> Cc: [email-masked]; Brian E Carpenter
> Subject: Re: [Diffserv] Bidirectional flows, Emergency Services
> 
> Hi Steve,
> I believe, that at the momoment it is more technical than diff-serv
> standarization problem.
> If you group your users say into 2 groups, using addressing, every router
> in your network will know exactly how to treat returning packet: if your
> customer belongs to "priority" group then he will get priority treatment
> even for return traffic, if it belongs to "standard" group he will get
> "standard" treatment. And so on.
> It will easily work in your AS, and no "states" need to be introduced.
> 
> If you want to have such treatment all over internet, then you need to
> think about such solutions as receiver-based traffic control.
> 
> rgrds
> Andrzej
> 
> Steve Silverman wrote:
> >
> > In response to my question about bidirectional flows, Fred Baker didn't
> want
> > to impose the requirement on the routers to mark return packets because
> that
> > would mean keeping state info on every flow.  I sympathize with the
> desire
> > to avoid complicating the switch but:
> >
> > If the system is going to allow DSCP marking to affect packet treatment,
> the
> > access router is going to have to be a gatekeeper to ensure that such
> > markings aren't abused.  Otherwise most spam will be sent at high
> priority.
> > One would assume that Service Providers will want to limit use of and/or
> > charge for high priority markings.  This creates a state-keeping burden
> that
> > can't be avoided.  If UserA has premium service, and sends a packet to
> > ServerX, packets from ServerX to UserA should get that premium service
> but
> > not packets from ServerX to other users.  The only way for the network to
> > validate these service requests is to note the packet from UserA to
> ServerX,
> > keep this state, and allow ServerX to UserA traffic to use this Diffserv
> > marking.
> >
> > If IP is to be the global data/voice network of the future, I think
> > emergency services (and bidirectional flows) are going to be an
> unavoidable
> > part of the package even though it complicates the switch.
> >
> > As I remember, when the Diffserv WG was first set up, allowing SPs to
> create
> > a premium service was a major driver for the WG.  This was presumed to
> > include web browsing.  Web browsing with Diffserv only makes sense if
> > priority is given to the return packets.
> >
> > Steve Silverman
> > Houston Associates
> > [email-masked]

_______________________________________________
diffserv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html