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

["Ligang Dong" <[e-mail]>]

hi,

The following is my opinion about the debate whether multicast (i.e., multiple addressing) of LFB Instance is required or not. 

(1) In past several months, I am engaged in the implementation of ForCES & GRMP. Till now, a basic prototype is already constructed. Also it has been shown to several guys in this research field. From the view of implementation, the multicast of LFB instance is easy. 
(2) Furthermore, multicast of LFB instance is more efficient than the "unicast" approach and the "virtualID" approach. Therefore, why not adopt multicast of LFB instance in the protocol. 
best regards
Ligang
----- Original Message ----- 
From: "Zsolt Haraszti" <[e-mail]>
To: "Wang,Weiming" <[e-mail]>
Cc: "Khosravi, Hormuzd M" <[e-mail]>; "Joel M. Halpern" <[e-mail]>; <[e-mail]>; "Steven Blake (petri-meat)" <[e-mail]>; "Alan DeKok" <[e-mail]>; "Jamal Hadi Salim" <[e-mail]>; <[e-mail]>; "Ellen M Deleganes" <[e-mail]>; "Yang,Lily L" <[e-mail]>
Sent: Friday, October 22, 2004 2:26 AM
Subject: Re: [Forces-protocol] RE: GET/SET in one msg ?


> 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
> 

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