[Ieprep] e2e diffserv and ieprep

["Ayyasamy, Senthilkumar (UMKC-Student)" <[e-mail]>]

> There are quite a few ISPs who implement Diff-Serv in IP. 

1. Global crossing has deployed diffserv.
The whole Doctoral dissertation of Xipeng Xiao is about 
experience in deploying Diffserv across global crossing.

For people who have time/energy  can look into his PhD
work.
http://www.cse.msu.edu/~xiaoxipe/papers/thesis/thesis.pdf
( It will really be interesting to read his dissertation.
I could understand most of his thesis with less background.)


Else, read three of his papers published in IEEE communication/
networks magazine.)

1."A Practical Approach for Providing QoS in the Internet Backbone"
  with Thomas Telkamp
  IEEE Communications Magazine, Dec. 2002. 
2."Traffic Engineering with MPLS in the Internet" 
  IEEE Network Magazine, Mar. 2000.
3."Internet QoS: A Big Picture"
  IEEE Network Magazine, March 1999.

For people who dont have access to ieeexplorer, you can grab a copy 
from http://www.cse.msu.edu/~xiaoxipe/.


2. Operational view point:

For a more operation point of view, look for thomas telkamp's
presentation along with Dave/Randy/Lixia in oregon nanog.
http://www.nanog.org/mtg-0210/complexity.html

If you want to hear more on what thomas is saying:
http://www.nanog.org/mtg-0210/telkamp.html


3. If you have started liking QoS, look for Ash
submission to tewg.
http://www.research.att.com/~jrex/jerry/

Although, their is a lot of literature regarding QoS routing,
i think reading this draft sums up everything.

---------------------------------------------------
If your don't like QoS concept but still want to use 
operational heuristics/theoretical techniques to 
  - optimize your routing strategies (traffic aware routing etc.)
  - Do traffic engineering without MPLS
  - efficiently plan your capacity.
  - How to give high availability for demanding traffic.
  - know how much to provision your backbone
  - find the rogue (high bw flows, non-responsive flows, DoS aggregate
    traffic.)
see the works from
   http://ipmon.sprintlabs.com/
   http://www.research.att.com/~jrex/

esp. sprintlabs has works claiming that their backbone has 
less (burstiness, packet reordering). Also, about how 
they help high  availability for VoIP traffic without QoS.
If your a fan of applying theoretical principles like
teletraffic models,ARIMA modeling, Queuing theory,
and network calculus to practical network problems, sprintlabs
work has a lot to offer.

One caveat: Both sprintlabs/ATT have a very good measurement 
system for getting up to date details about Backbone. They
have passive measurement monitoring systems which samples
packets and gives them details about their backbone. Based on
those details, they can do all the above applications.
 But, lets take an ISP which doesn't have such a measurement
system(?) and do brute force over provisioning without 
effective planning. I don't know but in some cases, it might 
backfire(?). In transportation networks, their is a concept 
called Braess paradox. Braess' paradox is said 
to occur in a network if the addition of an extra link leads
to a worse performance. *Theoretically*, Frank Kelly proved its 
existence in loss networks. 
http://citeseer.nj.nec.com/bean95braes.html

But, sure ...it will not exist in practical network scenarios.
But, my point is, their might be some cases where unplanned 
provisioning can backfire. Might be operators help me understand
whether they occur or not...


Some related interesting Internet drafts:
http://www.ietf.org/internet-drafts/draft-liljenstolpe-tewg-cwbcp-02.txt
http://www.ietf.org/internet-drafts/draft-bhattacharyya-monitoring-sprint-00.txt
ftp://ftp.sprintlabs.com/diot/mpls-white-paper.txt


> In short, my point is we don't want to rule out anything at this EARLY
> stage.

Exactly.. the direction/tone of the discussion forced me to think that ieprep is 
ruling out many technologies standardized by IETF. For example, if end to
end diffserv is not standardized by IETF, it doesn't mean that ieprep cant 
work anything involving DIffserv. Operators cant still do end to end diffserv 
by using RFC 2998 or do static provisioning across the domains. 

The only point that stuck me for no enough input for continuing e2e Diffserv 
in IETF is, 
  - lack of wide spread diffserv deployment/Business models 
    for inter-domain. (but this should not be a criteria as IETF assumes
    all inter-domain contracting issues in place.)
  - Their is no enough control plane work. All that is standardized by 
    Diffserv WG is data plane work. Still, it needs a signaling mechanism to
    do control plane work (so, we have to wait for NSIS output
    http://www.ietf.org/internet-drafts/draft-salsano-bgrpp-arch-00.txt) 
    So, once we have inter-domain signaling in place, e2e Diffserv work can be 
    continued.

Other than this, we have seen many initiatives regarding e2e Diffserv/deployment.
For example, i2 Bandwidth broker architecture, BuDs RG in IRTF( It is now 
defunct..I don't know about their deliverables but it is about diffserv deployment)
and Diffserv deployment BOF( http://www.cs.ucl.ac.uk/research/decides/) 
IEPG meeting in Atlanta IETF had a presentation about Diffserv deployment
although in a research network (http://www.potaroo.net/iepg/november2002/geant.pdf)

I was forced to write this as the recent IAB minutes hints about ieprep WG and
its relation to e2e diffserv.

I still stand by my previous comments  
https://www1.ietf.org/mail-archive/working-groups/ieprep/current/msg00828.html
about many problems with QoS deployment.
But, the whole point is that, ieprep cannot simply reject a technology standardized
by IETF since most of the operators currently dont use them. We have to unravel
all the stones before coming to the conclusion that this particular extension works 
best for ieprep.









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