Subject: Re: Congestion avoidance Re: [Ieprep] draft-ietf-ieprep-framework-02.txt

From: "Ayyasamy, Senthilkumar (UMKC-Student)" <[email-masked]>
Date: Fri, 1 Nov 2002 18:25:18 -0600

> While your view certainly represents the "traditional" Internet view and 
> current operational practice, one should not forget that there has been 
> a large body of more recent research work related to QoS routing.
[...]
> (I would be curious what concrete QoS routing has been deployed, tested 
> and discarded, given that none was ever really  standardized in the IETF, 
> as far as I can tell. RFC 2386 seems to be the only  output of the QOSR 
> working group that concluded in early 1999.)

  The non-deployment of many QoS technologies ( including QoS routing) is
mainly due to gap between the operational/engineering/research community.

- For example, scalability is not the only issue for lack of interest
  in Integrated services. Intserv expects reservation to cross administrative
  boundaries without any hurdle( which is highly impractical!!!) 

- Also, many of the QoS routing schemes are load-insensitive and assumes 
  connection-oriented nature, which is again impractical. QoS routing
  researchers assume many things which practical network doesn't support
 ( e.g. unequal splitting.) To be frank, most of the QoS routing schemes will
  be overkill for the network ( even if the operators are ready to deploy.)

- Lack of necessary business models. For example, Diffserv is supported 
  only edge to edge ( not e2e) due to lack of proper inter-domain
  economic models. 

  Their are many places (particularly access) where QoS techniques are 
necessary. But, we should try our best to rely on our heuristics & 
inference from operational experience to solve the problems of the Network.  

  I don't think, we have realized any of geoff's ideas for QoS 
deployement (RFC 2990.) So, it high time that we look back and restrategise 
ourself wrt QoS research. Though, its totally out of scope for ieprep, it 
is _necessary_ for IETF to look into the issues of complexity/overloading/arch 
in many of the QoS proposals. Some of the starting points:
http://www.nanog.org/mtg-0210/complexity.html
http://www.ietf.org/internet-drafts/draft-iab-considerations-03.txt
http://www.ieee-infocom.org/2002/images/Panel-2/2-6_Lixia_Zhang.pdf  

Thats said, lets stop the QoS/bandwidth/deployment discussion and worry about
other important issues.

  

_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep

---

From: Bill Woodcock <[email-masked]>
Date: Wed, 6 Nov 2002 09:45:06 -0800 (PST)

On Fri, 1 Nov 2002, Ayyasamy, Senthilkumar  (UMKC-Student) wrote:
    > Scalability is not the only issue for lack of interest
    > in Integrated services. Intserv expects reservation to cross
    > administrative boundaries without any hurdle( which is highly
    > impractical!!!)
    > Also, many of the QoS routing schemes are load-insensitive and
    > assumes connection-oriented nature, which is again impractical.
    > QoS routing researchers assume many things which practical network
    > doesn't support ( e.g. unequal splitting.) To be frank, most of the
    > QoS routing schemes will be overkill for the network ( even if the
    > operators are ready to deploy.)
    > Lack of necessary business models. For example, Diffserv is
    > supported only edge to edge ( not e2e) due to lack of proper
    > inter-domain economic models.
    > It high time that we look back and restrategise ourself wrt QoS
    > research. Though, its totally out of scope for ieprep, it is
    > _necessary_ for IETF to look into the issues of
    > complexity/overloading/arch in many of the QoS proposals.

I heartily agree with each of Senthilkumar's points in this email, and I
believe they represent the consensus view of operators generally.

			-Bill