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

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

Francois,
  Your first two comments are fine.  Regarding your comments on
(2) works well under both normal and overload conditions,
I do NOT mean "when there is contention across CTs" in the way
you described.

By "normal condition," I mean the network is carrying traffic
at a level that it is designed to support.
There will always be contention even under normal conditions,
because of the stochastic nature of traffic flows, i.e., the
fluctuating activities of establishment and teardown of LSPs
(otherwise, why do we need to define preemption priority in
the first place).
Perhaps adding some text as follows may be suseful.
Thaks, Wai Sum.

"Normal condition" means the network is carrying traffic
at a level that it is designed to support.
"Overload condition" means that the network is carrying traffic
higher than its normal level.
"Works well" means that under these conditions, the
network should be able to sustain the expected performance,
e.g., under overload it is x times worse than its normal
performance.

-----Original Message-----
From: Francois Le Faucheur [mailto:flefauch@cisco.com]
Sent: Wednesday, June 05, 2002 11:39 AM
To: Jim Boyle
Cc: Lai, Wai S (Waisum), ALASO; Ash, Gerald R (Jerry), ALASO;
te-wg@ops.ietf.org
Subject: RE: WG last call: draft-ietf-tewg-diff-te-reqts-04.txt


Jim, Waisum,

At 09:44 05/06/2002 -0400, Jim Boyle wrote:

>Well, it's seems long-winded, but I suppose I can go along with that.
>
>Let's remove the reference, and add:
>
>(5) maximizes efficient use of the network.
>
>Is the WG ok with that?

I am OK with Jim's proposal. A few small comments/suggestions embedded 
below inside Waisum's initial proposal.

Francois


>   Waisum - would that be a workable compromise?
>
>Jim
>
>On Wed, 5 Jun 2002, Lai, Wai S (Waisum), ALASO wrote:
>
> > 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

Should we not replace "Bandwidth Constraints" by "Bandwidth Constraints 
models"?

>.  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.


Should we not replace "services" by "Class-Types" in the two occurances
above?


>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

I am not comfortable with that statement:
         - not sure what "works well" means.
         - not sure what is "overload conditions" in this context. I
guess 
this means "when there is contention across CTs, right?

If I understand correctly, perhaps we could rephrase into something
like:
"(2) addresses both the cases where CTs are contending against one
another 
for bandwidth reservation and the cases where CTs are not contending 
against one another".

If you mean something differnet, could you clarify?

> > (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
> > > >
> > >
> > >
> > >
> > >
> >