[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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
> > > >
> > >
> > >
> > >
> > >
> >