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

[Kurt Erik Lindqvist <kurtis@kurtis.pp.se>]

On tisdag, maj 13, 2003, at 11:10 Europe/Stockholm, Iljitsch van 
Beijnum wrote:

> 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.
Absolutely, we do! But some of those examples cost more than others. 
And the total costs quite a lot. No need to add to this.

> 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?
Just to be clear in the example above, is A, B, C, D, E-Z sites, or 
nodes?
"
My answer would say that it depends. As (I think it was) Brian pointed 
out, you have a problem to "distribute the state" as well. And if that 
state should sit in in the sending/receiving nodes or the edge nodes, 
or in all of the nodes of the sending/receiving sites - is a good 
question. And one of the questions we need to solve.

My point was merely that I want to minimize state at all. We most 
likely will have to allow some state, but the cost of that state will 
depend on the protocol (type of state) and where that state is.

> 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.
True. I made a very general comment. And it is true that there are 
cases where conservation of bit's would be preferred, I my self use 
GPRS quite a lot and then I would also like to have the cheapest option.

However, this actually comes down to another issue. This is seen from 
the POV of the user. From the POV of the network operator, the cost of 
state will be higher. That cost will be taken out of the users, but it 
will not be as visible to the users as more bits would.

> Finally, I want to warn everyone that there is a very dangerous "who 
> cares about the overhead" attitude in some circles.
Agreed. But it's a trade-off.

- kurtis -