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

[George Tsirtsis <tsirtsis at googlemail.com>]

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
>