Subject: [Tsvwg] comments on draft-baker-mlpp-that-works-00

From: "Eagan, Christopher" <[email-masked]>
Date: Wed, 03 Dec 2003 14:11:09 -0500

Thanks for putting out this draft.  As you know and have written, MLPP over IP is major concern that has to be dealt with sooner rather than later.  Also, having a standardized MLPP implementation will have a great benefit not only for traditional MLPP users but also will be a potential benefit to local first responders all over the world.

I think the technical substance of the proposed solution is a good start.  However, the proposed solution would be greatly enhanced by adding MLEF as a secondary mechanism to insure that priority calls get through (per the following email commenting the "mlef considered harmful" draft).

Chris

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Eagan, Christopher
> Sent: Wednesday, December 03, 2003 1:47 PM
> To: [email-masked]; [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: [Tsvwg] comments on draft-baker-mlef-concerns-00.txt
> 
> 
> Comments on draft-baker-tsvwg-mlef-concerns-00
> 
> Thanks for putting out this draft.  Although I don't agree 
> with it, it is easier to criticize your work than write a 
> whole new draft :)
> 
> The major problems with this draft are:
> 
> 1.  A mechanism implementing PHB "MUST include some means to 
> limit the damage EF traffic could inflict on other traffic 
> (e.g., a token bucket rate limiter)" [RFC 2598, Section 2].  
> This means EF packets will be dropped if the aggregate EF 
> traffic exceeds a policy driven rate limit - right?  So, in 
> some situations, EF packets will be dropped, whether one is 
> using EF or MLEF or something else.  The only thing MLEF adds 
> to this picture is to provide a mechanism to choose *which* 
> packets will be dropped.  The fact that packets will be 
> dropped in some situations does not change by including or 
> excluding MLEF.
> 
> 2.  This draft implicitly assumes MLEF being implemented 
> without other mechanisms also being implemented (e.g. without 
> call admission control).  Merits of other mechanisms aside, 
> what is the basis for this assumption?  Does an 
> implementation of MLEF exclude other QoS mechanisms or vice 
> versa?  Not that I have seen.  Maybe if you added 
> interoperability concerns between MLEF and other existing 
> mechanisms this would bolster your argument.
> 
> The major issue that MLEF solves is network resource priority 
> at a lower and more fundamental level than CAC.  
> Specifically, MLEF allows higher priority traffic to survive 
> without any prior state variables being set in the router.  I 
> can see the merits of CAC with respect to managing the 
> problem you describe as "congestive collapse" in section 2.5. 
>  But does CAC work in all situations?  Does it work in mobile 
> ad hoc environments? Does it recover fast enough when an 
> router routing voice traffic gets blown up or smashed?  It 
> makes a lot of sense to me that even using a great CAC 
> mechanism, one would want a backup mechanism to assure 
> important communications.  MLEF provides this backup in a 
> simple, easy to implement manner.
> 
> 3.  With regards to the last sentence in the last paragraph,  
> no one has to be reminded of the seriousness of emergencies 
> and how good or bad lines of communications can translate 
> into people's lives.
> 
> My comments are based on our own discussions within Lockheed 
> Martin and comments previously posted to the IEPREP working 
> group by participants there such as Mike Pierce and Steve 
> Silverman.  Having said that, these comments also represent 
> my personal opinions.
> 
> Christopher Eagan
> Software Engineer
> Lockheed Martin
> (301) 240 - 6328
> [email-masked]
> 
> 
> 
> _______________________________________________
> tsvwg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/tsvwg
> 

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