[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

Another perspective ... hope it makes sense.

The binary format on the wire can be chosen to save bytes on the wire.
But the binary format on the wire is in general not the binary format
used in the receiving node, and so a translation will have be made from
the wire-binary format to the node-binary format.  (Hannes's argument)

My concern about sending text description is not the wire and not
the conversion.  It is the scale.  Allow me to draw in an example
from routing.  A router does no longer dump its routing table to its
peers whenever there is a change, instead it sends increments of
specific changes.  If the future of flow bindings is the exchange of
many bindings, scalability becomes an issue and sending individual
flow rules with a priority seems best.  If instead the future is
expected to be only a few rules because that is all a mobile node
will care about, all rules can be sent when there is a change.

Christian






--- Den tors 14/5/09 skrev George Tsirtsis <tsirtsis at googlemail.com>:


Fra: George Tsirtsis <tsirtsis at googlemail.com>
Emne: Re: [MEXT] Binary Filters and the nature of MIP Re: binary filtersdraft 0
Til: "Glen Zorn" <gwz at net-zen.net>
Cc: "Hannes Tschofenig" <Hannes.Tschofenig at gmx.net>, "Michael Eriksson" <michael.eriksson at ericsson.com>, mext at ietf.org
Dato: torsdag 14. maj 2009 15.43


Agreed, which is again why binary makes sense as the default.

George


On Wed, May 13, 2009 at 11:57 PM, Glen Zorn <gwz at net-zen.net> wrote:
> Hannes Tschofenig [mailto://Hannes.Tschofenig at gmx.net] writes:
>
>> 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?
>
> Total sense.  I'd just add that if we are to worry about performance issues
> at all they should be issues that we have some control over (i.e.,
> efficiency on the wire) rather than those we do not (for example, the
> algorithms used at either end to create or process the filters).
>
> ...
>
>
>
_______________________________________________
MEXT mailing list
MEXT at ietf.org
https://www.ietf.org/mailman/listinfo/mext



      Trænger du til at se det store billede? Kelkoo giver dig gode tilbud på LCD TV! Se her http://dk.yahoo.com/r/pat/lcd