Got it Anil. But given the condition of multiple applications co-existence would not having 2 different sources of cookie management, a recipe for more disasters, since in such cases the cookies can collide.
Br,shuva On Thu, Jan 5, 2017 at 1:26 PM, Anil Vishnoi <[email protected]> wrote: > contract is simple, whatever way user configures the flow, they should use > unique cookie value. To make sure the uniqueness either application can use > it's own cookie management or they can use the application provided by the > plugin or any other way. > > On Wed, Jan 4, 2017 at 10:55 PM, Shuva Kar <[email protected]> > wrote: > >> Sounds good Anil. But if the flow provisioned through the rpc uses an >> already existing cookie value, do we throw up while collecting stats saying >> that the cookie is duplicate or do we use Alien-id in that case? >> >> >> Br,shuva >> >> On Wed, Jan 4, 2017 at 11:52 PM, Anil Vishnoi <[email protected]> >> wrote: >> >>> I think we should use cookie based comparison only for the flows >>> installed through the data store. So as far as flow is added/deleted >>> through data store it's easy to maintain the cache. I think cookie_mask >>> based deletion is something that you can't do through data store, so we >>> won't get into the situation where we will have to maintain the cache based >>> on cookie_mask. For the flow that is installed through rpc, we should >>> directly augment the flow statistics to operational data store using the >>> cookie value. That's the current implementation as well but it uses alien >>> id, but augmenting it using the cookie value will help application to write >>> deterministic logic, because they will know where the operational data of >>> the flow will be written. Also we won't have to maintain any cache as well >>> for rpc. >>> >>> On Wed, Jan 4, 2017 at 9:33 AM, Shuva Kar <[email protected]> >>> wrote: >>> >>>> Missed the list, >>>> >>>> Br,shuva >>>> >>>> ---------- Forwarded message ---------- >>>> From: Shuva Kar <[email protected]> >>>> Date: Wed, Jan 4, 2017 at 11:00 PM >>>> Subject: Re: [openflowplugin-dev] Using cookie as a flow-id >>>> To: Anil Vishnoi <[email protected]> >>>> >>>> >>>> But we still need to update the cache maintained for the CRS(Cookie >>>> Reservation System) to do the comparison in case of flow deletes and >>>> modifications, wont that mess the mappings with a cookie_mask, or do for >>>> the simplistic approach assme the cookie mask is 0 and proceed for all the >>>> cookies assigned from/by the CRS ? >>>> >>>> Br,shuva >>>> >>>> On Wed, Jan 4, 2017 at 2:52 PM, Anil Vishnoi <[email protected]> >>>> wrote: >>>> >>>>> Hi Muthu, >>>>> >>>>> cookie_mask has no significance when it comes to flow add operation, >>>>> it's only used for wildcard matching for flow modification/deletion >>>>> operations. So as per my understanding of the spec, if you install flow >>>>> with cookie=1234 with mask=ff00 and fetch the stats from the switch it >>>>> should return the cookie=1234 and mask=ff00, rather then cookie=1200 ans >>>>> mask=ff00. So from uniqueness perspective we just have to look at the >>>>> cookie value only. Here are few snippets from the spec >>>>> >>>>> uint64_t cookie_mask; /* Mask used to restrict the cookie bits >>>>> that must match when the command >>>>> is >>>>> OFPFC_MODIFY* or OFPFC_DELETE*. >>>>> A value of 0 indicates no >>>>> restriction. */ >>>>> >>>>> >>>>> If the cookie_mask field is non-zero, it is used with the cookie field >>>>> to restrict flow matching while modifying or deleting flow entries. *This >>>>> field is ignored by OFPFC_ADD messages.* The cookie_mask field’s >>>>> behavior is explained in Section 6.4. >>>>> >>>>> So i think from plugin and stats collection perspective, just matching >>>>> based on the cookie value is enough. >>>>> >>>>> >>>>> On Tue, Jan 3, 2017 at 8:39 PM, Muthukumaran K < >>>>> [email protected]> wrote: >>>>> >>>>>> 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]] *On Behalf Of *Anil >>>>>> Vishnoi >>>>>> *Sent:* Wednesday, January 04, 2017 9:13 AM >>>>>> *To:* Luis Gomez <[email protected]> >>>>>> *Cc:* [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]> wrote: >>>>>> >>>>>> >>>>>> >>>>>> On Jan 3, 2017, at 6:52 PM, Anil Vishnoi <[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 >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Thanks >>>>> Anil >>>>> >>>>> _______________________________________________ >>>>> openflowplugin-dev mailing list >>>>> [email protected] >>>>> https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev >>>>> >>>>> >>>> >>>> >>>> _______________________________________________ >>>> openflowplugin-dev mailing list >>>> [email protected] >>>> https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev >>>> >>>> >>> >>> >>> -- >>> Thanks >>> Anil >>> >> >> > > > -- > Thanks > Anil >
_______________________________________________ openflowplugin-dev mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
