Re: [MEXT] Binary Filters and the nature of MIP Re: binary filtersdraft 0

[George Tsirtsis <tsirtsis at googlemail.com>]

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