Re: TML Service Primitive Update

Jamal,

Thanks very much for the response. Pls see reply in line.

----- Original Message ----- 
From: "Jamal Hadi Salim" <[email protected]>

> On Tue, 2006-07-11 at 20:46 +0800, Wang,Weiming wrote:
> 
> > How about others (also the authors) thoughts?
> > 
> 
> I agree with Joel's view; in addition, the text still has a lot of
Jamal, the text as "...A ForCES PL implementation must be portable across..." were originally added by you :). (I'm not sure it is also for the protocol document). That's why I asked your thought. 

> "howto" type of "features". 
> I think you still have too many "features" that end up
> tying things to some specific operations in some specific OSes. 
> This document should be making recommendations, not say "this is how it
> is done". It must never be imposing the how-to achieve things.
> I sent you private emails on the topic already but didnt receive
> responses - so a few of the thoughts are below:
Jamal, I have sent you a bunch of emails with the responses regarding this. I don't know if something wrong with the emails or not, or other reasons? Maybe we have to use this list also for the private comm.:)
May be I need to resend you these emails.

> 
> 1) In the events section where there are some events that are described
> such as congestion alert, DOS alert etc. It is not defined how such
You mean we lack detailed definition? I'm afraid it may really lead to too 'featured' specific operations,which is as you opposed in above text.

> things get detected by the TML. It is also not mentioned how  such
> information is used by the PL. An example of what would be useful would
> have been something like:
> 
> "In cases where the OS is capable of detecting ECN (Early/explicit
> congestion notification) where the underlying IP protocol is capable of
> of passing information to the application, then the TML could pass such
> information to the PL. The PL could use this information for example to
> adjust its sending rates or increase or reduce the priority of certain
> PL messages, etc"
This text has already been added in the new update. Pls check it.

>  
> This needs to be done for all events.
> 
> 2) Again on events; you mention things like "sustained events". I think
> the correct terminology is level-triggered vs edge-triggered. 
> Again, there are a lot of OSes which may be capable of one vs the other.
> You could say " It is suggested that error events are delivered as
> level-triggered" but not impose they are delivered that way.
Maybe 'sustained' is not a good word for it, but I think level-triggered/edge-triggered is more implementation oriented. Whereas, if you persist it, we can change to.

> 
> My recommendation is to really cut off a lot of this stuff off for now
> and then we can have discussions where we can restore some pieces. 
Can you show more on which part we should cut off? From above two points, it seems we may add something more.

> 
> There are a lot more issues like the above (which held me back from
> editing before the deadline since i didnt hear from you). 

> We also need
> to improve readability in a big way.
Much thanks if anyone can help do this.

Please do let me know if the email can only be received via the list rather than your private account.
 
lots thanks,
Weiming

> 
> cheers,
> jamal