retune FV message blocking/squelching logic

[billsnow]

Status: Open Project: Flowvisor Component/s: Core Affects Version/s: 0.7.2 Fix Version/s: Long Term

Type: New Feature Priority: Major Reporter: Nick Bastin Assignee: Rob Sherwood Resolution: Unresolved Votes: 0 Labels: None Remaining Estimate: Not Specified Time Spent: Not Specified Original Estimate: Not Specified

Description
Problem: If a flowspace rule is incomplete, e.g., specifies IP address but not dl_type = IP, then the corresponding drop rule is also incomplete, but switches will either ignore it or ignore the IP bits (possibly broken switch implementation). Possible solution #1: only block the exact match from the packet, not the entire flowspace rule Possible solution #2: rewrite all incomplete flowspace rules to being complete Possible solution #3: reject incomplete FS rules

Comments
Comment by Josh Smift [ 06/Jul/11 ] It occurs to me that this bug is exacerbating the problems that we're seeing with large numbers of flowspace rules in Expedient-managed FlowVisors, in that this bug is the only reason we have <dl_type> settings in rspecs at all, and things like <dl_type from="2048" to="2054"/> (as a shortcut to catch both IP and ARP) are multiplying the number of rules in Expedient-controlled FlowVisors by a factor of seven. I like Solution 2, personally: I think that if you match against nw_dst or nw_src, you're implicitly matching against IP or ARP (or any dl_type that matches those fields, I suppose). Whether you write that into the flowspace rules (which seems like it would lead to more flowspace rules again), or deal with it only at drop time (which might make it more CPU-intensive to compute drop rules), I don't have a strong feeling about, although the latter seems simpler to me – if you're about to send a drop rule, just check and sanitize it to make sure it won't block more things than you intend. In any case, is there any chance this could be prioritized? It would both help with the Expedient flowspace explosion problem, and make rspecs simpler for experimenters. Comment by Rob Sherwood [ 06/Jul/11 ] So, I think there are a couple of things being confused here. When you specify Flowspace via omni with a range, e.g., <dl_type from="2048" to="2054"/>, then it will be expanded out to seven rules by the time it gets to flowvisor (OM does the expansion, IIRC), so in that case, the dl_type is specified and this bug doesn't really apply. Also, for other reasons, we've actually changed to solution 1, and it seems to work pretty well. Was there some concern with that solution? That said, it is news to me that you're doing the <dl_type from="2048" to="2054"/> expansion instead of just having two rules, one for IP and one for ARP. It seems like you're paying a pretty stiff penalty (7/2 or 3.5x more rules than you need) at the seemingly low benefit of having to type less in the rspec. If this is really the main cause of the flowspace explosion, there are better ways of handling this. Comment by Josh Smift [ 06/Jul/11 ] Sorry, my explanation there might not have been very clear. The only reason we started specifying dl_type in rspecs in the first place was because of this bug: When we left dl_type off, and just included nw_dst, then FlowVisor would send a drop rule for the whole port, which was disastrous for shared ports like on MyPLC plnodes. So we started adding <dl_type from="2048" to="2048">, to limit the drop rule to only the IP subnet being matched. That just added one line to each of the existing elements in the rspecs, which wasn't a big deal. We then wanted to add dl_type 2054, to catch ARP; but since you can't do an OR in a element in the rspec, this isn't just adding one line – it's duplicating every flowspace element, because you need a separate flowspace element (which may include a dozen lines of ports, etc) per different dl_type that you want to match. ...unless you use the range technique, which keeps the rspec short and manageable, but explodes the flowspace. (In ways that we think shouldn't kill FV, but which, at the moment, are.) Does that make more sense? Comment by Rob Sherwood [ 06/Jul/11 ] I think I understood you the first time What you're saying is that you're requesting flowspace for dl_type=2048,2049,2050,2051,2052,2503, and 2054, not because you actually want 2049-2053-- you only want 2048 and 2054, but because it's less work to specify. I'm saying that it might be less work to specify, but it is inherently more work for the flowvisor because you're asking for extra flowspace that you will never use (the range 2049-2053) . More flowspace == more work. Now, I suspect the real flowspace explosion comes from the cartiesian product of: foreach switch foreach port foreach dl_type in 2048,2054 foreach actual flowspace that I want so my guess is that we're better off focusing on reducing the two outer loops with https://openflow.stanford.edu/bugs/browse/FLOWVISOR-71 So if the problem is really flowspace explosion, the question is really: are we better off spending our time on this or on FLOWVISOR-71 where I think the real problem is. Comment by Josh Smift [ 06/Jul/11 ] Ah, ok; I thought you were misunderstanding how much more work it was for the user to specify the two exact dl_types. (grin) My bias in cases where there's a choice between "make the software do a lot of work" and "make the user do a lot of work" is definitely in favor of making things easier for users. But I don't have to write the software. (grin) You're right that the explosion is in the product of those things. And you left off the x9 multipler that Expedient adds when it turns a /24 into nine rules (https://openflow.stanford.edu/bugs/browse/EXPEDIENT-1), but that's not a FV bug, so there's only so much we can do about that here. I can't tell for sure from the description how much https://openflow.stanford.edu/bugs/browse/FLOWVISOR-71 will help with FV efficiency, but I'm happy to take your word for it. But I'm still mostly interested in experimenter efficiency; so if fixing that bug will make it less problematic for experimenters to do things that are efficient for them (and inefficient for FV), then that's probably fine... But if fixing this bug would allow experimenters to do things that are efficient for them without making FV more inefficient, that seems ideal.

Original issue: https://openflow.stanford.edu/bugs/browse/FLOWVISOR-35