Re: [Ieprep] re-charter

Janet P Gunn <jgunn6@csc.com> Fri, 15 July 2005 20:38 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtWwr-0008GZ-B2; Fri, 15 Jul 2005 16:38:17 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtWwp-0008DX-FE; Fri, 15 Jul 2005 16:38:15 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01610; Fri, 15 Jul 2005 16:38:10 -0400 (EDT)
Received: from amer-mta02.csc.com ([20.137.2.248]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtXPd-0006xU-NR; Fri, 15 Jul 2005 17:08:04 -0400
Received: from amer-gw09.csc.com (amer-gw09.csc.com [20.6.39.245]) by amer-mta02.csc.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id j6FKbp1h004329; Fri, 15 Jul 2005 16:37:59 -0400 (EDT)
In-Reply-To: <BBF4FFEC-7E68-4923-A539-5F3C8D61B8C9@g11.org.uk>
Subject: Re: [Ieprep] re-charter
To: ken carlberg <carlberg@g11.org.uk>
X-Mailer: Lotus Notes 652HF83 November 04, 2004
Message-ID: <OFD34CD50B.A0E98A27-ON8525703F.006FB346-8525703F.00705C03@csc.com>
From: Janet P Gunn <jgunn6@csc.com>
Date: Fri, 15 Jul 2005 16:25:17 -0400
X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 6.5.3|September 14, 2004) at 07/15/2005 04:37:46 PM
MIME-Version: 1.0
Content-type: text/plain; charset="US-ASCII"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe
Cc: ieprep-bounces@ietf.org, ieprep@ietf.org
X-BeenThere: ieprep@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Internet Emergency Preparedness Working Group <ieprep.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ieprep>, <mailto:ieprep-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ieprep@ietf.org>
List-Help: <mailto:ieprep-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ieprep>, <mailto:ieprep-request@ietf.org?subject=subscribe>
Sender: ieprep-bounces@ietf.org
Errors-To: ieprep-bounces@ietf.org






ieprep-bounces@ietf.org wrote on 07/14/2005 03:48:57 PM:

>
> On Jul 13, 2005, at 5:19 PM, Richard F Kaczmarek wrote:
>
> > <snip>
>
> > With the Cisco routers we were using,
> > we could allocate bandwidth in the EF queue for emergency
> > communications
> > and for normal traffic. In this latter case, some sort of marker
> > (e.g.,
> > DSCP) may be needed for emergency traffic, but a unique per hop
> > behavior
> > may not be needed.
>
> for this last sentence, if what you are advocating is defining
> another DSCP value but with no distinctive corresponding per hop
> behavior, then I think that is a non-starter.
>

>From RFC 3246
"   Finally, it is possible to implement hierarchical scheduling
   algorithms, such that some non-FIFO scheduling algorithm is run on
   sub-flows within the EF aggregate, while the EF aggregate as a whole
   could be served at high priority or with a large weight by the top-
   level scheduler.  Such an algorithm might perform per-input
   scheduling or per-microflow scheduling within the EF aggregate, for
   example. "

This is one way of describing the functionality above.

Also from RFC 3246
"It should be noted that it is quite acceptable for a Diffserv domain
   to provide multiple instances of EF.  Each instance should be
   characterizable by the equations in Section 2.2 of this
   specification.  The effect of having multiple instances of EF on the
   E_a and E_p values of each instance will depend considerably on how
   the multiple instances are implemented.  For example, in a multi-
   level priority scheduler, an instance of EF that is not at the
   highest priority may experience relatively long periods when it
   receives no service while higher priority instances of EF are served.
   This would result in relatively large values of E_a and E_p.  By
   contrast, in a WFQ-like scheduler, each instance of EF would be
   represented by a queue served at some configured rate and the values
   of E_a and E_p could be similar to those for a single EF instance."

And at the San Diego meeting, one of the authors of RFC 3246 (sorry, I
forget who) explicitly said in his presentation that there was never any
intention to restrict EF to a single DSCP.


There do, of course, remain issues as to whether it is a good idea or not.
But it is permissible under RFC 3246.

Janet


_______________________________________________
Ieprep mailing list
Ieprep@ietf.org
https://www1.ietf.org/mailman/listinfo/ieprep