Re: [MEXT] offline Re: binary filters draft 0

[Michael Eriksson <michael.eriksson at ericsson.com>]

On Wed, May 13, 2009 at 14:34:30 +0200, Julien Laganier wrote:
> On Wednesday 13 May 2009, Michael Eriksson wrote:
> > With "simple" I don't mean "more efficient", I mean that it is better
> > (easier) when developing, debugging and maintaining the system.
> 
> FWIW I don't think it would be reasonable to run in a production 
> environment code written by someone who doesn't know how to code a 
> byte-and-bit parser :-)

I, on the other hand, don't think it would be reasonable to run in a
production environment code written by someone who only knows how to
code a byte-and-bit parser :-)


> > In my view, dynamic flow rules will not be generated by the "MIP
> > stack" itself. They will be determined by a higher level function,
> > e.g, a connection manager. The connection manager shouldn't even have
> > to care about what mobility solution is used (MIPv6, shim6, MOBIKE,
> > ...). One of the ideas and explicit goals with our text-based rule
> > language is that it is mobility mechanism agnostic.
> 
> You can very well have a mobility protocol agnostic language to describe 
> you rules in your implementation. 
> 
> What we're talking about here is how the rules are transmitted by MIPv6, 
> not how they are transmitted by the Agnostic Protocol.

But then you would have to translate the rules from text to a binary
format before transmission. Are the few saved bits (if any) really
worth the cost in added complexity?

Have you done any ballbark calculations: How many bytes would a binary
format really save? How many percents of the available bandwidth?


> > > I do no think a network layer stack implementation is the place to
> > > implement formal grammars, parse and validate regular expressions.
> >
> > Why not? Because it is not "efficient" enough? Please note that most
> > (all?) MIP signaling implementations are user space programs, and are
> > not involved in packet forwarding.
> 
> Why? 
> 
> Because that's how things are done. What I recommend is that you find 
> out 1) what is most deployed network layer protocol, and 2) which 
> encodings its use.

That was one of the weakest arguments I have ever heard! :-) (sorry)

Unfortunately, it is all too common. How could we possibly advance out
of the 1970's if everybody argued like that?


> > Also, see my comment above regarding that the rules will not be
> > generated by the "MIP stack" itself.
> 
> That's internal to your implementation. I am talking about 
> bits-on-the-wire. 

See my reply to Gerardo on why it is nice to use a rule format
suitable for the connection manager all the way to the HA.


> > In this regard, the text format has two advantages:
> >
> > 1. The rule order is well defined.
> 
> Same can be done with a binary format. Order of IPsec TS in IKE is well 
> defined.

I agree, but as I said before: Your are guilty by association with the
flow-binding draft, since that is what your binary format targets.
When you define a better transport format (please, please, please do
that!), I will disregard this argument.


> > 2. The action to be taken at a rule match is given inline.
> 
> Same can be done with a binary format.
> 
> > Thus, rules in the text format are completely self contained.
> 
> Same can be done with a binary format.

I agree again. Please, please, please design a better transport format
where this would fit!


> > OK. I will just note that you will need yet another tool.
> 
> Exactly as you need another tool to crunch, resolve, save, edit your 
> text rules!

Oh, you mean Emacs. Fortunately, rms developed that already in the
80's :-).


> MH is not a transport protocol. It is a network layer mobility (or 
> routing) protocol.

We can argue about that, but I don't think it is important. The thing
is that it is not used to transfer user data, and thus it is a
suboptimization to compress out the last bit at the cost of added
complexity.


> > > control plane, application... what are talking about?
> >
> > Other architectures (GSM/3GPP for instance) separates user data from
> > control data in different vertical planes, the user plane and the
> > control plane. In such an architecture, MH and rule exchange would be
> > control plane protocols.
> 
> Thanks for explaining the difference b/w user plane and control plane, I 
> am sure this will be useful to many of us. 

Well, you did ask!


> As you're mentionning 3GPP I will simply note that the control plane for 
> the network mobility core (GTP-C) does not use text encoding. It uses 
> binary, because it is network layer control protocols.

See my comment above about weak arguments :-).

I am trying to teach my kids that "everybody else does that" is not a
good excuse for bad behavior...


> > What I am really after is that exchanging rules isn't a network layer
> > function, it is a control function. Thus the balance between
> > compressing away the last bit and other aspects changes, compared to
> > a (user plane) network layer protocol.
> 
> Exchanging mobility routing rules is both a control and a network 
> protocol thus I do not know what you're after.

Again: I am after that it is more important to be bit efficient for
"user traffic", of which there is a lot. For control traffic, it is
not very important. Reduced complexity is much more important.


Regards,
Michael