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

[Francois Le Faucheur <flefauch@cisco.com>]

Waisum,

At 17:14 05/06/2002 -0400, Lai, Wai S (Waisum), ALASO wrote:
>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.

I think I understand what you mean now.

It is not completetly clear to me how that would translate into an 
evaluation criteria for BC models, but I think the general idea is 
reasonable so I have no objection to adding something along those lines.

Additional suggestions on wording:
1)How about :
"Normal condition" means that the network is attempting to establish a 
volume of DS-TE LSPs for which it is designed.
"Overload condition" means that the network is attempting to establish a 
volume of DS-TE LSPs beyond the the one it is designed for.
(to me "carrying traffic" can be easily misunderstood as relating to the 
actual amount of packets transmitted , when here we are more focusing on 
the amount of tunnels versus what can be setup)

2)"Works well":
Personnaly I think the above definition for "works well" is trying to be 
too precise this time (it begs questions as to what sort of "performance" , 
can the BC Model itself control that ..). I would suggest again replacing 
"works well" by something like "maintain efficient use of the network both 
under normal condition and Overload condition".
("efficient use of the network " is something we use as an other evaluation 
criteria. Here we just want to make the point that this applies both under 
normal AND overload conditions.)

So, altogether, it would read:

"
(2) maintain efficient use of the network both under Normal Condition and 
Overload Condition".
"Normal condition" means that the network is attempting to establish a 
volume of DS-TE LSPs for which it is designed.
"Overload condition" means that the network is attempting to establish a 
volume of DS-TE LSPs beyond the one it is designed for.
"

What do you think?

Francois



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