Subject: [Ieprep] Re: draft-talauliker-ieprep-diffserv-00.txt

From: "Talauliker, Salil Ulhas (UMKC-Student)" <[email-masked]>
Date: Wed, 10 Jul 2002 19:45:27 -0500

Dear Fred,
 
This is in response to your comment below on Friday, June 28 about my draft draft-talauliker-ieprep-diffserv-00.txt.
 
> I'm not sure what the intersection of talauliker and baker's drafts are; 
> from my perspective, it sounds like a submission to diffserv more than a 
> submission to ieprep. We'll discuss it given time, and see what we want to 
> with it. I note that diffserv didn't choose to standardize the RIO 
> chanism, or Cisco's WRED mechanism, or Lucent's approach, or the approach 
> commended by Van and Kathy called RED-Lite, or any of a list of others. 
> Diffserv rather chose to identify AQM mechanisms as a class of equally 
> acceptable algorithms. I also note that there is little substantive 
> difference between what this proposes and an AF service which treats all 
> emergency traffic as AFn1 traffic.
 
This draft is very much a submission to the IEPREP cause. If you notice, the draft is suggesting a solution for providing priority treatment for EMERGENCY TRAFFIC in a SPECIFIC domain - i.e. a 
DIFFSERV domain. We are also working on finding a solution for the same problem in a current "best effort network". However the solution space for best effort gets mired by the orthogonal issues 
like ISP compliance and economic feasibility etc. Although I cannot disagree that the draft can also be submitted to a purely diffserv WG.
 
> I note that diffserv didn't choose to standardize the RIO 
> chanism, or Cisco's WRED mechanism, or Lucent's approach, or the approach 
> commended by Van and Kathy called RED-Lite, or any of a list of others. 
> Diffserv rather chose to identify AQM mechanisms as a class of equally 
> acceptable algorithms.
 
I completely agree with this remark of yours as far as the Diffserv idealogy is concerned. However theres some misunderstanding of my ideas here. The draft is NOT proposing any proprietary solution 
from the list that you mentioned above. Rather it is proposing the use of RIO - (a much useful RED variant) - as a technology, an idea - not RED as a product developed by some company. 
I would like to reiterate that RFC 2597 recommends that AQM be used to realize the multiple DP in the AF PHB and that the most widely used AQM scheme is RED. We at UMKC have done a preliminary 
evaluation of the several ways to extend RED to a Multilevel RED (MRED) algorithm suitable for the AF PHB. And based upon our finding this draft suggests the use of RIO (RED with in/out) to protect 
Emergency traffic.
 
> I also note that there is little substantive 
> difference between what this proposes and an AF service which treats all 
> emergency traffic as AFn1 traffic.
 
I strongly disagree with this comment for the following reasons:
 
1. This draft does not say that we assign ALL emergency traffic with the highest possible AF codepoint such as say AFn1. Thats definitely NOT the case. We have clearly stated that the traffic 
conditioner used at the ingress router in a Diffserv domain would mark the incoming flows with appropriate AF/EF codepoints, NOT necessarily with AFn1. And we also mentioned in the draft that a 
standard allocation policy does not exist although you have given a good example configuration in draft-baker-ieps-requirements-00.txt.
 
2. Secondly we do NOT say give lowest drop precedence color to ALL emergency traffic. Instead the draft proposes a MULTI-LEVEL drop precedence over AF/EF queues. So it is quite possible that while 
an Emergency Voice packet might get GREEN color, another Emergency packet, say an Email packet, might be given YELLOW color. As of now, we are open to such a coloring scheme - again for the lack of 
any standard coloring scheme. 
 
This draft is fairly influenced by the idea mentioned in section 3.3 of  "draft-beard-ieprep-requirements-00.txt" that 
 
>>->   Quality of service for emergency communication services does not
>>->   necessarily mean better quality of voice/video as compared to what
>>->   is available to normal users. The same QoS classes, which are
>>->   already defined for normal traffic, can be utilized for emergency
>>->   traffic as well. The fundamental quality of service requirement for 
>>->   priority traffic is this - better than best effort service.
 
All this effort is based on one assumption that - simply assigning ALL Emergency traffic to AFn1 will NOT solve the problem EFFICIENTLY. If however you think my approach is wrong, then 
please let me know and also suggest an alternative if possible.
 
Also if you think its appropriate then these ideas can be merged with your draft - which might be a good idea too!
 
I understand that what I am proposing is to use Diffserv for a purpose that it was not designed for. And the networking community is not going to be very happy about it. But thats the best that can 
be done today if we want to provide a Priority (aka differentiated) Service to Emergency traffic in a Differentiated domain. Being the coauthor of the Diffserv RFC, you are the best person who can 
guide me in this.
 
Any questions comments are very welcome.

Regards,
 
Salil Talauliker
School of Interdisciplinary Computing and Engineering
University of Missouri-Kansas City.
[email-masked]

References:
----------
draft-talauliker-ieprep-diffserv-00.txt
draft-baker-ieps-requirements-00.txt
draft-beard-ieprep-requirements-00.txt

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