Subject: [TSVWG] Multi-Level Expedited Forwarding

From: "Steve Silverman" <[email-masked]>
Date: Mon, 24 Oct 2005 15:46:25 -0400

Multi-Level Expedited Forwarding

I (along with Mike Pierce and other people) have been proposing
Multi-Level Expedited Forwarding as a way to implement a form of MLPP
(Multi-level Precedence & Preemption) for some years.
All we want to get approval as an Experimental RFC.
This would create a stable document that would allow the proper
experimentation to see if this is necessary and what else is needed to
support the MLPP feature.

I want to point out:

The DOD (and many other organizations) have limited bandwidth and
consequently do have a congestion problem.

The DOD really does need a multi-level priority voice system.
They have spent a large amount of money to implement this over 40
years.

MLEF works at a different level than a CAC (Call Admission Control)
and does not conflict in any way.  They work at different layers.
This allows rapid response but does not allow MLEF to do call control.
They compliment each other.

If there is no congestion, MLEF does not affect the data stream.

MLEF is very simple to implement and has several implementations been
done and worked.

MLEF is simple enough that there is no significant processing load at
execution time.

As has been pointed out, packet losses are in general confined to the
routine traffic.
In a congested network, something has to be discarded and routine
traffic is
by definition where we want necessary losses to occur.

"MLPP-that Works" will NOT meet DOD requirements.
The DOD network packet encryptors (High Assurance Packet Encryptors)
will
hide the RSVP messages from the network.
We have no problem with approval of this document but think it
should be made more explicit that this ID may be useful for
other networks but won't meet DOD needs. This is mentioned in the ID
but a great deal of the current draft is DOD related and
one might conclude that the draft is pertinent to the DOD.
MLEF is part of a solution to the MLPP problem that will work despite
network packet encryption.

Given the demand for voice in networks that may occasionally be
congested,
I still think this draft (currently
draft-silverman-tsvwg-mlefphb-03.txt)
should be considered by the WG.  I would ask others that think this
should be worked by this group (or another) to support this.

Steve Silverman

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

---

From: ken carlberg <[email-masked]>
Date: Tue, 25 Oct 2005 16:37:20 -0400

> should be worked by this group (or another) to support this.

pardon my confusion, but I was under the impression from the last  
Minneapolis-IETF (#62) that both the Polk & Baker MLPP draft as well  
as the Silverman/MLEF draft were to be taken on as official TSVWG  
documents.  I thought that Scott Bradner had recommended this course  
of action (and the minutes *seem* to bear this out) and that the  
chairs agreed.

but please correct me if I'm mistaken.

-ken

---

From: Fred Baker <[email-masked]>
Date: Tue, 25 Oct 2005 05:12:33 +0200

On Oct 24, 2005, at 9:46 PM, Steve Silverman wrote:
> The DOD network packet encryptors (High Assurance Packet  
> Encryptors) will hide the RSVP messages from the network.

As you know, DoD does not intend to deploy MLEF either. If MLEF is  
published as an RFC, the the document that points out the issues it  
raises should also be published. That note has been allowed to expire  
at Mike Pierce's request, as it should be generalized to cover the  
issues with heuristic-based algorithms in general, including the  
proposed heuristics related to ECN, and I have not done that. The  
water has, however, flown quite a way beyond that particular bridge,  
and now DoD was present officially at the last IETF meeting and will  
be conducting an ad hoc BOF at this one.

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 27 Oct 2005 17:33:52 -0500

As an author of the counter to this ID, I remember the discussion involving 
Scott wrt modifying MLEF-Concerns for a wider audience being acceptable to 
the WG.  I can't say I remember the MLEF spec document clearing WG 
consensus to become a WG item though. This can be discussed in Vancouver.

>but please correct me if I'm mistaken.

cheers,
James

                                 *******************
                 Truth is not to be argued... it is to be presented.