[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GSE IDs [Re: IETF multihoming powder: just add IPv6 and stir]
On dinsdag, mei 13, 2003, at 10:11 Europe/Amsterdam, Kurt Erik
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
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
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
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.)