Re: [Forces-protocol] RE: GET/SET in one msg ?

[Zsolt Haraszti <[e-mail]>]

Weiming,

I have a very hard time to resonate with your examples, and therefore
with your reasoning.

For one, if you end up needing 64k LFBs from the same class, I think
you or we did something wrong with the model.  Sure you mean it an
extreme case, but I think it is a misleading one.  I envision
practical LFB models having up to a few hundred LFB instances, where
multiple instances of the same class will be in very different roles
(e.g., a Classifier LFB supporting Diffserv versus a Classifier
LFB supporting IPsec, etc.), hence more often not sharing any config
data than sharing some.

For two, displacing the two parts of the LFB address (class ID and
instance ID) in the protocol is a much bigger concern to me than to
allow ad-hoc/state-less multicast addressing.  It would be in some
sense similar to if in the IP header the (sub-)network address and
host-address part of the IP address were placed in distant offsets.

For three, on state-less versus state-ful multicast:  Your example
below is based on the very extreme case when you have a SINGLE
config message addressed to a VERY LARGE number of LFB instances
of the same class.  I have not yet seen a practical case for this
scenario.  I reiterate that multicast groups are not ad-hoc, and
there will be typically a large number of config updates sent to a
group after the group is formed.

Regards,
Zsolt

On Wed, 2004-10-20 at 01:56, Wang,Weiming wrote:
> Joel,
> 
> ----- Original Message -----
> From: "Joel M. Halpern" <[e-mail]>
> Subject: Re: [Forces-protocol] RE: GET/SET in one msg ?
> 
> 
> > I do think that there may be thousands of instances.
> > I do not think that this requires multiple addressing.
> >
> > I think that there are some interesting cases prompted by the possibility
> > of very large numbers of LFBs, but they do not drive multiple addressing.
> >
> > My reasoning is based on the following premise.
> > Firstly, if there are many LFBinstances s of a class, then it is likely
> > that many fields of the LFB instances will be the same, but it is extremely
> > unlikely that all fields of the LFB instances will be the same.
> [Weiming]That's just why explicit multipul addressing is needed. For the case of
> fields of all LFBinsatnces are the same, we can simply use a broadcast to do so.
> Let me try to show a scenario why multipul addressing is needed for different
> fields case.
> 
> Firstly, because we have assumed the 16bit insatnce Id is not enough, we can
> reasonably assmue there is a case where there are 64k or more instances (say
> 64k). Further, we suppose Id1 to Id32k need to config parameter 1, Id(32k+1) to
> Id 64k to set parameter2.
> 
> Then, by using single instance addressing, the protocol becomes horrible, either
> using one message or using separate messages. I just show the one message case.
> The message format would like like:
> 
> Msghdr
> LFBselect
> LFBClassID
> Instance ID1
> Parameter1
> Instance ID2
> Parameter1
> ...
> ...
> Instance ID 32k
> Parameter1
> Insatnce ID (32k+1)
> Parameter2
> ....
> Instance ID 64k
> Parameter 2
> 
> Remember we then have 64k pair of instance and parameter in the protocol text.
> In some cases, I'm just worried this make protocol unpractical.
> 
> By using multipul addressing, the only text is as:
> Msghdr
> LFBselect
> LFBClassID
> Instance ID1 to ID 32k
> Parameter1
> Instance ID (32k+1) to ID 64k
> Parameter2
> 
> By using multicast scheme supposed by Zsolt, I suppose we need following steps:
> 1. send a FE attribute to FE object to setup a virtualID1 for Instance 1 to
> Instance 32k
> 2. send a FE attribute to FE object to setup a virtualID2 for Instance (32k+1)
> to Instance 64k
> 3. config:
> Msghdr
> LFBselect
> LFBClassID
> Virtual ID1
> Parameter1
> Virtual ID2
> Parameter2
> 4. send a message to release virtual ID1
> 5. send a message to release virtual ID2
> 
> I can see the advatage of above explicit multipul addressing scheme very
> clearly.
> 
> > The simplest case to understand when one would need to setup all those LFBs
> > at once is in a power recovery situation  (the FE lost power, then
> > recovered to an empty state.)  The CE needs to send the configuration
> > information to the FE.
> [Weiming]Yes, that's the one case but not the only.
> 
> > Secondly, I believe that transaction count is much more important than data
> > volume.  The FE is going to have to set every field in every LFB.  Encoding
> > is not going to change that.
> [Weiming]I'm not sure if you mean for every operation, we should maintain a
> transaction count. If is, then I have to say our current one message with
> multiple Operation definitions has already be against the requirement. My
> opinion is transaction maintenance is moderate, while multicast and multiple
> operation are more important.
> 
> > Given that there are distinct values in each LFB instance, there must be an
> > operation against each LFB instance.
> I don't think multicast will loose operation individuality.
> >
> > The marginal gain from having a single transaction to update the identical
> > fields, and then individual transactions for the distinct fields is very
> > small.  It does not reduce the number of IOs or the core transaction rate.
> [Weiming]At least it saves bits greatly and makes protocol practical. Remember
> the capability between CE and FE are quite limited, especially in muli-hop
> ForCES application.
> >
> > If it is desired to optimize for this case, we may want to introduce (in a
> > future version of the protocol) some kind of block checkpoint / restart
> > mechanism.  The CE would record its full state about the FE, and then ask
> > the FE for a dump suitable for restoral of the FE state.  Upon restart, the
> > CE would rebuild its state from its stored representation, and would ship
> > the dump back to the FE to enable efficient rebuilding there.  I can see
> > significant value in such a mechanism.  I do not however see a need to
> > include this in the first deliverable of the protocol.
> [Weiming]I suppose this is only for restart case, I can see many cases where
> multiple addressing can apply, such as delete, change of LFB parameter, load and
> unload of LFBs, etc. And also I think the scheme above is much more complex than
> multiple addressing. So, my conclusion is, with a little bit expansion, we can
> gain much, then why not we adpot it?
> 
> Best regards,
> Weiming
> >
> > Yours,
> > Joel M. Halpern
> 
-- 
Zsolt Haraszti                Phone:  [phone]
Modular Networks              Mobile:      [phone]
                              Email:  [e-mail]


_______________________________________________
Forces-protocol mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/forces-protocol