Re: GSE IDs [Re: IETF multihoming powder: just add IPv6 and stir]

[Iljitsch van Beijnum <iljitsch@muada.com>]

On dinsdag, mei 13, 2003, at 10:11 Europe/Amsterdam, Kurt Erik 
Lindqvist wrote:

> What worries me as ex-operator is that state in a network comes at a 
> cost. Normally state is actually among the most costly components of 
> network design. So, I agree that I would like to avoid any stateful 
> mapping. Now, that said I agree that a stateless mechanism is going to 
> harder to design and implement.
I think we should more carefully define the word "state". A BGP routing 
table is state. An IPsec security association is state. An ARP table 
entry is state. A TCP control block is state. A socket bound to a UDP 
port is state. We use all of this (maybe with the exception of IPsec) 
every day, so apparently keeping all this state is worth it.

Assume we have A and B that want to communicate, and they have C and D 
sitting between them passing along the packets. There are also E - Z 
who are connected to A, B, C and D but they aren't involved in this 
particular communication. My position is:

State in A and B: perfectly acceptable. Applications and transport 
layer protocols keep state anyway.

State in C and D: not good, but not entirely inconceivable.

State in E - Z: unacceptable.

Which part were you talking about?

And in another message you said:

> > Also, we can't assume that users will universally prefer a stateless 
> > solution with per-packet overhead over a stateful one that doesn't 
> > have extra overhead.
> I would like to argue that per-packet overhead is cheaper than 
> stateful mappning.
I'm sure this is true for you. However, I regularly connect to the net 
with my laptop over GSM at 960 bytes per second costing me 11 cents per 
minute, and when I do that every byte counts. If you're sitting behind 
gigabit ethernet where you can do 100000 packets per second regardless 
of how big they are, you'd rather throw away 10% of the usable data in 
each packet than add extra processing that halves the number of packets 
per second you can do. What I'm saying is that it is impossible to 
determine that globally, EVERYONE will always prefer either state or 
overhead.

Another important point is that the additional information can't be 
trusted so it must be authenticated. This means crypto, which is harder 
to do fast than state. Obviously some people will implement very fast 
crypto but for others even a moderate amount of crypto is extremely 
undesireable because either they simply don't have the CPU power or 
they don't want to use it (CPU costs energy, not nice when running on 
the battery).

But I think we should revisit this when there is an actual proposal 
that adds extra headers to packets because only then we'll be able to 
see how this helps us and how it hurts us.

Finally, I want to warn everyone that there is a very dangerous "who 
cares about the overhead" attitude in some circles. (Not just IETF, but 
also IEEE and others.) I did some calculations on VoIP over IPsec and 
it turns out that even with a factor 4 compression of the data, the 
total number of bits used by this is larger than regular TDM for voice. 
Don't forget we have more than 5 layers, if every one of those adds 3% 
overhead, that's 16% total. If they all do 5% it's 28% and if they all 
do 10% it's no less than 61%. It adds up very quickly. A good example 
of what can happen hee is 802.11g that has a 54 Mbps bitrate but 
delivers little more than 20 Mbps. (But that's partially because of 
some radio stuff obviously.)