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

[Michael Eriksson <[e-mail]>]

First, Julien, please excuse me if I offended you with my last mail.
That was not my intention. I think that our discussion had a sound
dose of tounge-in-cheek (which I appreciated), and I thought that you
wouldn't mind a rude joke. I am sincerely sorry.


On Wed, May 13, 2009 at 17:45:45 +0200, Julien Laganier wrote:
> On Wednesday 13 May 2009, Michael Eriksson wrote:
> > 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?
> 
> Since in order to match actual packets the MIPv6 stack will _anyway_ 
> have to deal with binary representation of IP addresses, protocol 
> numbers, flow labels, port numbers, ICMP types and codes,  IPsec SPIs, 
> you will have to pick these elements out of your text rules and 
> translate them to binary _anyway_ thus I do not see where is the added 
> complexity.

Yes, the text will have to be parsed somewhere. But the beatiful thing
with doing it at the HA is that you can completely avoid to encode and
decode the message to and from an ad hoc binary format just for the MN
to HA transport!


> And yes it saves bits. It's not because a resource is cheap that we 
> should consume it without regards. For an illustration, see Fallacy #3 
> in <http://en.wikipedia.org/wiki/Fallacies_of_Distributed_Computing>.

I think that it is funny that you want to save some bytes in a
signaling message that is sent maybe once a minute (at most), when
MIPv6 tunnels every user data packet...

If you really want to save bytes, I think that you should focus on
separating the rule updates from the binding updates.
Resending/refreshing all rules, whether in binary or text format, at
every handover is wasteful -- both in terms of transmitted bytes and
complexity. The same goes for refreshing all bindings just because you
change the rules.


> > Have you done any ballbark calculations: How many bytes would a
> > binary format really save? How many percents of the available
> > bandwidth?
> 
> I do not have the charge of the proof since I propose to follow the 
> current practice of using binary encoding for network layer protocols.

It is your argument that the text protocol is too verbose, and that a
binary format is needed.


> You are on the other hand free to compute how much complexity is saved 
> by translating text to binary in the MIPv6 stack (as pointed out above 
> is implied by your proposal) rather than in your connexion manager (as 
> I argue you could do if you really want a text based language).

It would save exactly the complexity of encoding and decoding to and
from a binary format. Given the existing suggested binary rule and
transport formats, I would say that that is quite a lot...


> > Unfortunately, it is all too common. How could we possibly advance
> > out of the 1970's if everybody argued like that?
> 
> Is this your argument?
> 
> Mind you, many bright principles originates in the 70's and are still 
> valid today.

OK, I should have added one or two smileys, but I thought that was
obvious.

But I actually think that I do have a point about the tendency to
always do things as they have always been done. That is not the way to
make real progress. More of the same is not always the best thing.

In this particular case, the available bandwidth have increased with
about 2 to 3 decimal magnitudes (i.e., a factor of 100 to 1000) in the
13 years that have passed since draft-ietf-mobileip-ipv6-00 was
published in January 1996. Back then we used 28.8 kbps modems and the
9.6 kbps GSM circuit switch data service. Today, we use 8000-100000
kbps fixed accesses at home, and 3G HSPA with 7200 kbps.


> It's the right thing to do to follow past design principles unless 
> better ones are found. So far you have not provided any valid evidence 
> that motivate the need to use text encoding in a network layer 
> protocol. 

I am arguing that the text format is a better design. I happen to
think that I actually have put forward some reasonable arguments.


> You keep insisting on the "complexity" of "translat[ing] the rules from 
> text to a binary format before transmission" while it is clear that, as 
> soon as you introduce a text rule language, translating between binary 
> and text is required to match actual packets no matter what rule 
> encoding we choose for on-the-wire protocol encoding .

I think I replied to a similar remark above.


Regards,
Michael