RE: WG last call: draft-ietf-tewg-diff-te-reqts-04.txt

["Lai, Wai S (Waisum), ALASO" <wlai@att.com>]

Jim,
   Per your request, here is the proposed text to replace the last
but one paragraph of Section 3.3.  Comments are welcome.
Thanks, Wai Sum.

At the time of writing this document, it is not clear whether a 
single model of Bandwidth Constraints is sufficient, which one it 
should be and how flexible this model really needs to be and what 
are the implications on the DS-TE technical solution and its 
implementations.  Work is currently in progress [Reference] to
investigate the performance and trade-offs of the different
operational aspects of Bandwidth Constraints.  For example,
preliminary results indicate that the use of a higher degree of
bandwidth sharing among different services can lead to a tighter
coupling among them, which can result in the impact of one service
on another.  Another preliminary observation is that there is the
need to balance overall efficiency and the avoidance of starvation
of any one service.  These factors should be considered in the
deployment of any bandwidth constraint model.

The DS-TE technical solution must specify one 
default bandwidth constraint model which must be supported by any 
DS-TE implementation.  Having a default bandwidth constraint model 
allows for the network administrator to have at least one 
consistent behavior when working with multiple implementations of 
DS-TE.  Additional bandwidth constraint models may also be specified.
In the selection of a default model, at least the following criteria
must be considered:
(1) addresses the scenarios in Section 2
(2) works well under both normal and overload conditions
(3) applies equally when preemption is either enabled or disabled
(4) minimizes signaling load processing requirements

[Reference] W.S. Lai, "Performance evaluation of bandwidth allocation
  models for Diffserv-aware MPLS traffic engineering," Internet-Draft,
  June 2002.

-----Original Message-----
From: Jim Boyle [mailto:jboyle@pdnets.com]
Sent: Tuesday, June 04, 2002 3:00 PM
To: Lai, Wai S (Waisum), ALASO
Cc: Ash, Gerald R (Jerry), ALASO; te-wg@ops.ietf.org
Subject: RE: WG last call: draft-ietf-tewg-diff-te-reqts-04.txt



You're text does not make it "clear" to me.

Can you propose some text which captures what you see as objective
criteria?

My pass would be to add a sentence at the end of the paragraph such as:

"The default bandwidth model should be one that can address the
scenarios
in section 2 in a manner which balances bandwidth efficiency as well as
signaling overhead."

I'm not sure if that will allow us to converge on a model, but at least
it
specifies some objective criteria to judge different models by.  Plus,
with just one sentence and no value statements on models as you had
previously suggested, I think we can add it in and progress the draft.

Does this sound ok?

Jim

On Tue, 4 Jun 2002, Lai, Wai S (Waisum), ALASO wrote:

> Jim,
>   I think our proposal to add some text in the requirements doc for
> BC model is in the same spirit as in Section 4 "Solution Evaluation
> Criteria" of this document for solutions supporting DS-TE.
>
>   Let me quote again the paragraph in question:
>     "At the time of writing this document, it is not clear whether a
>     single model of Bandwidth Constraints is sufficient, which one it
>     should be and how flexible this model really needs to be and what
>     are the implications on the DS-TE technical solution and its
>     implementations. The DS-TE technical solution must specify one
>     default bandwidth constraint model which must be supported by any
>     DS-TE implementation."
>
>   Regarding the first sentence, we have now some new information on
the
> implications of the BC models, which is contrary to what is stated as
> "it is not clear".
>
>   More importantly, the second sentence in above text only says that
> one default needs to be specified *without going into the specific
> selection criteria*.  We believe that some criteria to be considered
> include at least:
> (1) performance under normal conditions versus service protection
>     and isolation capability under overload (as stated in my previous
>     email)
> (2) signaling load processing requirements (as stated in the email by
>     Rudiger Geib)
>
>   As I explicitly stated in my previous email, we fully agree that the
> requirements doc is not the place to resolve what the default model
> should be.  Thus, we have no objection to continuing this discussion
> in the context of draft-ietf-tewg-diff-te-proto-00.txt, but see a
> need/value in identifying criteria and referencing relevant studies
> in the requirements document.
>
> Thanks, Wai Sum.
>
> -----Original Message-----
> From: Jim Boyle [mailto:jboyle@pdnets.com]
> Sent: Monday, June 03, 2002 10:15 AM
> To: Ash, Gerald R (Jerry), ALASO
> Cc: Lai, Wai S (Waisum), ALASO; te-wg@ops.ietf.org
> Subject: RE: WG last call: draft-ietf-tewg-diff-te-reqts-04.txt
>
>
>
> Jerry - it is already specified in the requirements document that the
> bandwidth constraint model must be specified in the technical solution
> document:
>
> 	"The DS-TE technical solution must specify one
>    default bandwidth constraint model which must be supported by any
>    DS-TE implementation"
>
> How = IETF process, Where = TEWG.  Do we really need to state that?
>
> As for making comparisons between models in the draft, I don't think
> it's
> called for.  I think making references to documents which describe
them
> is
> also something that isn't necessary in the requirements document.  As
> for
> adding some text as to the decision must be made on "hard information"
-
> I
> see that as a no-value addition to the document.
>
> What objection do you and Wai have to having this discussion in the
> context of draft-ietf-tewg-diff-te-proto-00.txt ?
>
> Jim
>
> On Mon, 3 Jun 2002, Ash, Gerald R (Jerry), ALASO wrote:
>
> > > The discussion on what should be the default bandwidth constraint
> > > model should be done in the context of the solution draft.
> >
> > This should be stated as a requirement in Section 3.3 of the
> requirements draft.
> >
> > > The paragraph you quote makes it clear that the requirements draft
> leaves that
> > > discussion squarely with the technical solution.
> >
> > Nowhere in Section 3.3 of the requirements draft is it stated how or
> where the technical solution will be decided.  It should be stated as
a
> requirement in Section 3.3 that "the default BC model will be decided
in
> the context of the technical solution draft."
> >
> > > I don't see a need for any text revision of the requirements draft
> before
> > > sending it on to the IESG.
> > > Anyone else have any comment?
> >
> > Yes.  An additional requirement should be added in Section 3.3:
> > "the default BC model must be based on available hard information,
> such as analysis given in [forthcoming lai-id] [other relevant
> references]."
> >
> > Also, Wai Sum's suggested short explanation of the essence of his
> analysis is highly relevant to Section 3.3, and shouldn't be rejected
> out of hand.
> >
> > Jerry
> >
>
>
>
>