[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MEXT] Binary Filters and the nature of MIP Re: binary filtersdraft 0
Sorry to be unclear.
There are two aspects:
1) How do you encode filters on the wire, i.e., when carried in your
favorite mobility protocol (or other protocol; does not really matter that
much).
2) How are these filters implemented in a particular node?
Now, for item (2) folks have come up with quite sophisticated mechanisms
(typically dedicated languages that have an assembler like syntax) over time
that are (a) highly efficient and (b) quite compact in the encoding. I
provide a reference to the BSD packet filter system but the work obviously
did not stop in 1992.
Now, ideally you would want to select a format for (1) that allows easy
conversion to the format used with (2).
The problem now is that different implementations use different languages.
So, it is quite likely that you will have to convert the stuff you get via
(1) anyway to (2).
So, my conclusion is that the format for (1) does not really matter unless
you get to pick a format that is extremely close or equal to the format used
by (2) for most of the implementations.
This only matters if the translation from (1) to (2) is performance-wise an
issue. I am not sure it really is and in that case you could as well toss a
coin since it does not matter at all for the format for (1) is.
Does this description make any sense?
Ciao
Hannes
PS: Whatever you do it would be nice to have a reference library at the end
that folks could use in their implementation.
>-----Original Message-----
>From: George Tsirtsis [mailto:tsirtsis at googlemail.com]
>Sent: 13 May, 2009 17:05
>To: Hannes Tschofenig
>Cc: Michael Eriksson; mext at ietf.org
>Subject: Re: [MEXT] Binary Filters and the nature of MIP Re:
>binary filtersdraft 0
>
>Hannes,
>
>Just to make sure I am not missing your point this is an
>argument for the fact that one can do text based filters at
>user API level but still send them binary over the air, right?
>
>George
>
>On Wed, May 13, 2009 at 10:04 AM, Hannes Tschofenig
><Hannes.Tschofenig at gmx.net> wrote:
>> I would like to remind that the representation on the wire has very
>> little todo with the internal implementations of all sorts
>of filters.
>>
>> Packet filter implementations are very likely to use an virtual
>> machine alike syntax. A more classical example can be found with the
>> BPF packet
>> filter:
>> http://download.at.kde.org/pub/tcpdump/papers/bpf-usenix93.pdf
>>
>> Ciao
>> Hannes
>>
>>
>>>-----Original Message-----
>>>From: mext-bounces at ietf.org [mailto:mext-bounces at ietf.org] On Behalf
>>>Of George Tsirtsis
>>>Sent: 13 May, 2009 16:51
>>>To: Michael Eriksson
>>>Cc: mext at ietf.org
>>>Subject: [MEXT] Binary Filters and the nature of MIP Re:
>>>binary filtersdraft 0
>>>
>>>Michael,
>>>
>>>Trying to navigate through this thread, on one handle I am
>puzzled by
>>>the PRI discussion so I am going to ignore it for now, but on the
>>>other hand I now realize a fundamental issue which possibly
>causes the
>>>difference of opinion on the subject.
>>>
>>>You seem to think of MIP and even of Connectivity Managers as a high
>>>level applications that live at user level. This viewpoint alone
>>>pretty much defines your opinion. It is of course true that a lot of
>>>public and research-type implementations of such functions
>are at user
>>>level, possibly using high level programming languages.
>>>
>>>In the real commercial world, however, things are much different. To
>>>put any of this in a real world wireless, highly integrated device
>>>(think of iPhones, BBerrys, other smart phones and even
>netbooks etc)
>>>Connectivity Managers and Mobile IP will be highly optimized, low
>>>level application in C or even in Assembly. MIPv4 has been
>integrated
>>>in phones by Nextel as part of the Direct Connect system,
>and I have
>>>personally been involved in one assembly implementation of Mobile IP
>>>during my Flarion years, and am now involved with another such low
>>>level implementation in my current company.
>>>
>>>I hope this helps you understand where I (and probably others) come
>>>from when they are interested in binary filter rules, and why I keep
>>>saying that it is fine to have text filters too if people
>really want
>>>them but they cannot possibly be the default format.
>>>
>>>George
>>>
>>>On Wed, May 13, 2009 at 8:46 AM, Julien Laganier
>>><julien.laganier.ietf at googlemail.com> wrote:
>>>> Michael,
>>>>
>>>> On Wednesday 13 May 2009, Michael Eriksson wrote:
>>>>> [...]
>>>>> You are mixing up:
>>>>
>>>> OTOH, I have the impression that you are mixing things up
>>>quite a bit
>>>> here. See below -
>>>>
>>>>> 1. Determining the order of the rules. This is done at the
>>>MN, and is
>>>>> independent of the how the rules are expressed (binary
>or text).
>>>>> Determining whether the rules overlap or not is not necessary,
>>>>> as
>>>>> long as you sort them in priority order.
>>>>>
>>>>> 2. Transfering the ORDERED list of rules from the MN to the HA.
>>>>> This
>>>>> is where there is a difference between the text rules
>and binary
>>>>> rules transferred in the flow-binding format.
>>>>>
>>>>> - For the text format, this is trivial: Just append them
>>>in order.
>>>>
>>>> Exactly the same can be done with the binary format: Just
>>>append them
>>>> in order in a single BU.
>>>>
>>>> Defining a priority field is an optimization that allows
>not sending
>>>> the full ruleset in each BU, thus making it possible to
>order rules
>>>> that were sent in different BUs. You would need exactly
>the same for
>>>> your text format were you going to provide the same optimization.
>>>>
>>>>> - For the binary format, you have two choices:
>>>>>
>>>>> - Send them unordered (FID-PRI=0). Not a good idea, since it
>>>>> is
>>>>> most likely that the wrong rule will match some flows.
>>>>>
>>>>> - Enumerate the rules by using the FID-PRI field as a rule
>>>>> numerator (hence my BASIC remark).
>>>>>
>>>>> In practice, you will always have to enumerate the
>rules with
>>>>> the FID-PRI field. This is not very elegant, and adds
>>>complexity. For
>>>>> instance, the rules would have to be sorted according to their
>>>>> FID-PRI value after reception, while in the text format
>they always
>>>>> arrives in correct order.
>>>>
>>>> See above the point that FID-PRI is required only because
>>>there's the
>>>> optimization of sending the full ruleset in each BU.
>>>>
>>>> --julien
>>>> _______________________________________________
>>>> MEXT mailing list
>>>> MEXT at ietf.org
>>>> https://www.ietf.org/mailman/listinfo/mext
>>>>
>>>_______________________________________________
>>>MEXT mailing list
>>>MEXT at ietf.org
>>>https://www.ietf.org/mailman/listinfo/mext
>>>
>>
>>
>