Subject: RE: [Diffserv] TCB or not TCB

From: "Yoram Bernet" <[email-masked]>
Date: Fri, 7 Jul 2000 08:42:03 -0700

i'm jumping in a little late and have not read all the preceding debate
(though i have seen plenty fly past my inbox). so - i may not be
qualified to participate in this debate at this point. on the other hand
- i was the original auther of the draft and did create the tcb concept.

first of all - i don't know how or when it came to have a single input
and a single ouput. i remember specifically stating in the original
draft that it has an arbitrary number of inputs and outputs and believe
that it should remain so. i understand that this is fixed ina more
recent version of the draft anyway. the single input, single output
complaint was the only one i read and i agree with it - the tcb should
have an arbitrary number of i/os.

second - the utility of the tcb is simply in being a macro. as you can
see from the draft, it's cumbersome to draw schematics of traffic
conditioning fucntionality. furthermore, in many cases, a router will
have 1800 blocks with the same tc functionality. so - the tcb macro
enables the definition of a collection of tc components that can be sued
again and again. it is possible that the pib doesn't need this, nor the
mib. however - i can imagine a ui that enables the network manager to
create a string of traffic conditioning components with a given
functionality. at the ui level, i would be really unhappy if i had to
recreate this string every time i wanted to add it to an interface. so -
at the ui level (and at the conceptula level) - i find it essential to
be able to think in terms of these macros.

keep the tcbs. call 'em macros if you like. they exist at the conceptual
level whether we acknowledge it or not.

y

> -----Original Message-----
> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Thursday, July 06, 2000 3:18 PM
> To: John Strassner
> Cc: [email-masked]
> Subject: [Diffserv] TCB or not TCB
> 
> 
> John,
> 
> Can I try and throw the question back to you?
> 
> Since we've established that the TCB has no realisation in 
> the MIB or PIB data
> structures, and presumably not in the policy information 
> model, it is clearly 
> positioned as a descriptive aid for understanding the 
> conceptual model.
> 
> Are you arguing 
> 1) that it is incorrect or misleading as a descriptive aid 
> (assuming Andrew
>    fixes the specific inconsistencies you found)?
> or
> 2) we should not have descriptive aids that do not translate 
> into MIB or
>    PIB data structures?
> 
> If it's 1) we need to fix it.
> 
> If it's 2) we will need to put it to the WG as a consensus question.
> 
>    Brian
> 
> _______________________________________________
> diffserv mailing list
> [email-masked]
> http://www1.ietf.org/mailman/listinfo/diffserv
> Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/
>

---

From: "John Strassner" <[email-masked]>
Date: Sun, 9 Jul 2000 18:34:08 -0700

RE: [Diffserv] TCB or not TCBHi Yoram,

first, I think that you are pre-qualified, so let's get that out of the way ;-)

Second, a lot of my objections and confusion have to do with implementing the TCB as a single input, single output construct. If the next revision of this does have multiple inputs and outputs, then that would be a good first step towards alleviating some of the problems that I had.

Third, you bring up an important new point that is not really present in the existing draft - that of using the TCB not just to implement PIBs and MIBs, but for other purposes as well (e.g., UI). This does, as you say, help make the design of UIs easier and better.

But I submit that this is a new issue and isn't really talked about in the draft. Therefore, I would recommend that you help get that into place in the new version of the text, and that you consider relaxing or removing previously identified statements that link the model to "just" the PIB, MIB, and other similar interfaces.

So, if we could just get someone to start responding to the set of issues I raised, and if we can solve them, I would be happy to help work with and eventually endorse the TCB.

regards,
John
  ----- Original Message ----- 
  From: Yoram Bernet 
  To: Brian E Carpenter ; John Strassner 
  Cc: [email-masked] 
  Sent: Friday, July 07, 2000 8:42 AM
  Subject: RE: [Diffserv] TCB or not TCB

  i'm jumping in a little late and have not read all the preceding debate (though i have seen plenty fly past my inbox). so - i may not be qualified to participate in this debate at this point. on the other hand - i was the original auther of the draft and did create the tcb concept.

  first of all - i don't know how or when it came to have a single input and a single ouput. i remember specifically stating in the original draft that it has an arbitrary number of inputs and outputs and believe that it should remain so. i understand that this is fixed ina more recent version of the draft anyway. the single input, single output complaint was the only one i read and i agree with it - the tcb should have an arbitrary number of i/os.

  second - the utility of the tcb is simply in being a macro. as you can see from the draft, it's cumbersome to draw schematics of traffic conditioning fucntionality. furthermore, in many cases, a router will have 1800 blocks with the same tc functionality. so - the tcb macro enables the definition of a collection of tc components that can be sued again and again. it is possible that the pib doesn't need this, nor the mib. however - i can imagine a ui that enables the network manager to create a string of traffic conditioning components with a given functionality. at the ui level, i would be really unhappy if i had to recreate this string every time i wanted to add it to an interface. so - at the ui level (and at the conceptula level) - i find it essential to be able to think in terms of these macros.

  keep the tcbs. call 'em macros if you like. they exist at the conceptual level whether we acknowledge it or not. 

  y