[e2e] not quite the differentiated services I was thinking of

[Jing Shen]

Hi,

> 
> "The problem is, DiffServ mechanisms ( queueing,
> bandwidth allocation ) introduce too much of
> difficulties into ISP networks. An simple example,
> if
> we enable traffic classification and multiple queues
> in  ISP networks, QoS differentiation shows up only
> when congestion happens; DiffServ tries to solve
> bandwidth competition under congestion situation,
> ISP
> want to differentiate e2e QoS even when bandwidth is
> overprovisioned! "
> 
> I have yet to see any compelling evidence for claim
> 1 above once you
> have decided to actually serve the needs of users.  
> It is mantra for
> many, but where is the objective evidence for this
> claim? 

Problem exists with the following aspects:

1) Security 

If network traffic is classified to different QoS
level, CBWFQ is utilized to enable transmission
differentiation. If virus generating high volume of
traffic in priority queue, those low level traffic
will be squeezed to experience congestion. 


2) SLA verification 

How could we verify SLA of a special QoS level in
network ? When multiple end hosts try to verify QoS
service level with pressure test, could that be
considered a security problem?

3) Network planning 

When multiple queues are established to enable
differentiate packet forwarding, queueing mechanism
like WRR will blur the edge of SLAs between
gold/silver/bronze ( so why should someone pay for
high priority service? ), if hard limited queueing is
introduced how could network administrators plan and
adjust bandwidth allocation in an network with more
than 1000 routers, redunant links ? If the cost of
differentiated service is higher that the cost of
service establishment, why should we use it?is there
any ISP which implement DiffServ in its network?

At last, as those have been published some ISPs manage
traffic with special equipment, but to my limited
knowledge it's not with DiffServ(
classifying+tagging+transmiting ) but with traffic
management product like Packeteer's traffic shaper. 


>  Perhaps it
> has been repeated so often that it is now considered
> proved by emphatic
> assertion.  I have also yet to see any other
> mechanisms that when FULLY
> implemented doesn't haul in most of the Diffserv
> mechanisms (or their
> analogues, and thus their "complexity").

I take that a game between service differentiation
requirement and cost of implementation. ISPs want to
differentiate service between customers at individual
cutomer's application level,   diffserv tries to
tradeoff between scalablity and complexity , but it's
not the situation that simple assumption could
fullfill the requirement of commerical market. 
    



 
> In terms of the example: Diffserv, it can be more
> than happy to punt or
> delay packets in light of lightly congested
> networks.   
> 
> A shamein the whole Diffserv travelogue is that we
> have not adequately
> separated out the discussions of signaling, policies
> and operations so
> that the Internet might end up with a single
> signaling protocol with the
> ability to implement multiple policies (e.g.
> bandwidth, access - FW/NAT,
> security, etc.) to support different mechanism, not
> all of which have to
> do with BW/QoS/etc.

 That's another point current QoS mechanism is not
enough but ATM like QoS is too much and too complex.

So, is there any way to introduce more intellegence
into IP network?

Regards

Jing



	

	
		
___________________________________________________________ 
ÑÅ»¢Ãâ·ÑGÓÊÏ䣭ÖйúµÚÒ»¾øÎÞÀ¬»øÓʼþɧÈų¬´óÓÊÏä 
http://cn.mail.yahoo.com