RE: [NSIS] GIMPS features

["Hancock, Robert" <robert.hancock at roke.co.uk>]

hi,

comments on comments:

> -----Original Message-----
> From: Xiaoming Fu [mailto:fu at cs.uni-goettingen.de] 
> Sent: 27 May 2004 10:59
> To: Hancock, Robert
> Cc: nsis
> Subject: Re: [NSIS] GIMPS features
> 
> 
> Hi Robert,
> 
> Some comments below:
> 
> Hancock, Robert wrote:
> > 8.7 State teardown - the ability to allow GIMPS
> > (or someone above GIMPS) to signal in the protocol
> > that state *at the GIMPS level* isn't needed any
> > more. My impression is that GIMPS level state itself
> > is not so expensive that we need to be able to remove it 
> efficiently, 
> > and that soft-state is good enough to handle cleanup. Allowing 
> > explicit teardown then also means we have an extra security 
> threat to 
> > worry about.
> 
> One related issue is how to deal with mobility (the current 
> GIMPS spec does clearly talk about this) and whether we need 
> teardown in GIMPS and/or NSLP level at all.
> 
> I agree that GIMPS level state is probably cheap so that 
> there is no need to remove them once a normal route change 
> which happens every several hours or days, or even a 
> mobility-caused route change. However, state at NSLP level 
> could be sensitive to mobility, which can happen in seconds.
> 
> - If NSLP state needs to be torn down, who triggers this? 
> GIMPS or (whatever reason caused) route change event? I think 
> GIMPS could be a natural candidate as it does message routing 
> and does local repair upon certain detecting mechanism.

GIMPS can provide triggers to the NSLP, but it is not the only
trigger source. Note that it does *not* do local repair, only
message routing.

> 
> - If so, does GIMPS rely on a tear down message to remove all 
> NSLP state in the obsoleted path (cross-layering but looks 
> efficient), or GIMPS just notifies associated NSLP(s) to tear 
> down their state by their own teardown messages (should we 
> allow such possibility for the GIMPS/NSLP interface)?

The second would be my assumption - GIMPS doesn't know what
state the NSLPs are storing, let alone when is the right time
to tear it down (for example, there may be other cleanup operations
to be done first). All that GIMPS can do is provide the trigger.
I think the NSLPs designs currently take the same viewpoint 
(further input could be provided). 

> > 8.8 Single shot message support - some facility
> > provided by GIMPS to deliver a single message in some
> > reliable way without going through the whole C-mode
> > procedure. I'm not sure (in reality) how much more efficient
> > this can be made than C-mode, and how often an NSLP will
> > want to deliver just one message like this; so, my feeling
> > would be say it is 'all or nothing'. (We could reflect
> > such a potentiality in the conceptual API provided by
> > GIMPS, but actually just implement it with C-mode.) 
> 
> In our experiments if a C-mode connection has been previously 
> established & the link is not congested, delivering a "one-short" 
> message does not add discernable latency than in D-mode. 

We would expect this (if the messaging association protocols
have been efficiently implemented).

> However, if you 
> need call the discovery function or make a connection 
> beforehand every 
> time in C-mode, this can cost more time. Nevertheless, this 
> depends on, 
> as you pointed out, the frequency of such messages.

Basically, this is saying that if you have a lot of single-shot
messages, you should leave the C-mode association up rather than
tearing it down. This is a matter of good GIMPS implementation.

> 
> Cheers,
> Xiaoming
> 
> _______________________________________________
> nsis mailing list
> nsis at ietf.org
> https://www1.ietf.org/mailman/listinfo/nsis
> 

_______________________________________________
nsis mailing list
nsis at ietf.org
https://www1.ietf.org/mailman/listinfo/nsis