I think for the current release a simple cookie based comparison will resolve bugs in this area.
From: [email protected] [mailto:[email protected]] On Behalf Of Muthukumaran K Sent: 04 January 2017 10:09 To: Anil Vishnoi <[email protected]>; Luis Gomez <[email protected]> Cc: [email protected] Subject: Re: [openflowplugin-dev] Using cookie as a flow-id Hi Anil, I was checking how the uniqueness of cookie would be influenced by cookie_mask. Also the rules of comparison in presence and absence of cookie_mask. Again, cookie_mask is something which applications could decide and specify while requesting cookie / cookie range reservation. If cookie_mask is ‘0’ then entire cookie field would be used for comparison while comparing cookie from stats to that of config flow. If cookie field is non-zero then comparison would follow the rule stated in section 6.4 of OF 1.3.1 spec. Some aspects on cardinality especially in presence of non-zero cookie_mask which we may have to bolt on to App : Cookie-Range ==> 1:1 Cookie-Range : Cookie_mask ==> 1:1 OR 1:Many App : Cookie ==> 1:1 Cookie : Cookie-mask ==> 1:1 OR 1:Many Contract between application and cookie-reservation service (of OFPlugin) would vary based on cardinality of cookie-mask wrt cookie or cookie-range. Unless applications use cookie-mask very extensively, simple 1:1 mapping could be less bug-prone Am I overlooking something grossly or being paranoid ? Regards Muthu From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Anil Vishnoi Sent: Wednesday, January 04, 2017 9:13 AM To: Luis Gomez <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> Subject: Re: [openflowplugin-dev] Using cookie as a flow-id On Tue, Jan 3, 2017 at 7:28 PM, Luis Gomez <[email protected]<mailto:[email protected]>> wrote: On Jan 3, 2017, at 6:52 PM, Anil Vishnoi <[email protected]<mailto:[email protected]>> wrote: Hi All, This thread is about the proposal I discussed during the openflowplugin meeting two weeks ago. Currently statistics collection use custom comparator to compare the flows that it fetches from the switch with the config flows. The main reason for that is because openflow flow definition don't have any unique id, like group and meters, so we have to compare the flows based on all the match tuples of the flow. This custom comparator is a can of worms, because of the two reasons (1) It tries to normalize the data coming from switch and compare with config data store. It's costly and buggy. (2) Currently flow comparison fails if flows are same on the standard match tuple, but differs only by the extensions match tuple. Also in my opinion we can't afford to use custom comparator till the level of extension match, as it will increase the matching complexity, hamper performance and possibly introduce more bugs. Also it will increase complexity for writing pluggable vendor specific extensions. So i want to put the following proposal on the table for the discussion to resolve this longstanding issue. Provide a config knob to user (e.g enable-cookie-based-comparison=true). when this flag is enabled, plugin will not use the custom comparators to match the switch and config flows, but will only use cookie value to match. By default it should be false, so it's going to be business as usual for the dependent project. Pros: It will resolve (1) and (2) and we will reduce lot of flow matching related bugs from our list. Cons: I won't say cons, but implementing this solution require to resolve one other problem-- who will make sure the uniqueness of the cookie? I think as a plugin, we should provide a simple contract that application should be responsible for using the unique cookie, plugin can probably write an error message to the operational data store if application uses the used cookie value. Now this actually pushes the problem to the application level and in my opinion it should be solved at the application level. Cookie management is kind of resource management problem and there are multiple way it can be done. At a plugin level we can write an application that can provide a vanilla implementation of cookie reservation (assign individual cookie, cookie range etc) for the application to use, but if application want to use it's own implementation, they are free to do that as well. I think your suggestion makes sense and it is probably enough work for this release, in future we could have an application in ofplugin or another project to proper handle and distribute cookies among applications. I think adding this flag is not a much of work, but writing the cookie management application is a bit of work. Note: We will still have alien-id in the operational data store, but those will only be present when user will use RPC for flow installation, because in this scenario flow is not present in the config data store, which i believe is a clear contract compared to the existing one.As an enhancement we can use cookie value itself as a alien-id so it's going to be easy for application to look for the respective flow in operational data store. Interesting idea, so you mean the plugin in "cookie-based-comparison" mode (i.e. all cookies are unique) will lookup received cookies in the config DS and: 1) in case of match, it will set oper flow-ID= config flow-ID, 2) if no match, it will set oper flow-ID=cookie. Yes, but minor correction, in case of (1), it won't look in config data store, it will internally maintain the cache, so we will avoid DS read operation. Also using cookie-id=flow-id to store the flow will be helpful for applications to find the flow in operational data store. They can even register a listener directly on the path, because they will exactly know the path of the flow (node/table/cookie-id). I think that will make application logic more simple. let me know your thoughts ? If committers think this proposal make sense i can open an enhancement bug and prioritize it. -- Thanks Anil -- Thanks Anil
_______________________________________________ openflowplugin-dev mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
