Re: New network implementation proposal [was: Re: ipv6 on hurd]

[Olivier Péningault]

le ven 25-10-2002 à 11:16, Stephan Trebels a écrit :
> BTW:  the Plan9 approach to this separation is pretty similar:
> [...]
I didn't know it, it is an interessant way of implementing things.

> Personally I'd make one translator responsible for the ANY-IP
> translation for a physical or virtual device, including ANY-specific
> address-resolution handling (e.g. ARP on EtherNet or some ATM
> flavours) if needed.  This is very different for CLIP, bridged/routed
> 1483 ATM, Ethernet, PPP....  ANY-IP needs to provide interfaces for
> both IPv4 and IPv6, IMO.  I cannot imagine a clean separation there,
> and the translator graph should be a tree. I.e. I would not do
> something like
This might be a good approach. But I don't think the icmp issue is so
important. It can be used by itself (ping), in this case there is no
problem of too many rpc calls. When running a layer 4 protocol, icmp is
not used very often IMHO. And when we need icmp, if it is integrated in
the ip translator, it will not increase the rpc stuff, because the reply
will come from the icmp part of the ip translator, instead of coming
from the ip part of the ip translator.

> as this would create unnecessary locking problems.
I don't think so.
For tcp, when establishing a new session, we open a new port to the ip
translator, which remains open while the session is alive.
For tcp, we can create one port while udp and ip translators are running
(it is open when the first datagram is sent/received), if there is a
connection context, udp will not know it, it is the program's job.

> On top of the IPv? abstraction I'd put protocol abstractions, that
> provide groups of protocols where similar protocols should be grouped
> together.  You cannot separate TCP, UDP, ICMP IMHO without sacrificing
> speed.  As long as the total call/RPC overhead is limited (no stack of
> 10 translators until you send a frame) and not too much inter-protocol
> communication needs to happen (GRE for VPNs, ...), protocol groups can
> be in separate translators.
Here is a big problem. Do we want speed, or do we want features
(replacement of network protocols by users in a per-protocol basis). I
prefer the second point of view. But you also can run a translator, with
all protocols grouped, which will implement all needed interfaces.

> Just an outside view of things, Stephan
This is very nice, thanks. This kind of information is very usefull.
"Inside views" are sometime partial... :)

olivier