NSTF - Naming the stack

Dear roaring IOTlers,

after some discussion with Kaspar yesterday, we came to the conclusion that it would probably make sense to give a name to the new IPv6 network stack. The rational (aside from making it easier to refer to it) is that some parts of its implementation can serve as common ground for other network stacks, while other parts are specific to this particular stack. If someone wants to implement another IPv6 module, he/she could re-use, for instance, the IPv6 header structs. Hence, splitting the implementation in some common part and some implementation specific part seems to be most sensible to me.

However, the current approach intends to rename ng_ipv6* to ipv6*, which means that the developer pulls in the full IPv6 implementation of the currently developed stack. Instead it should be possible select a module "IPv6" for common features and a module that includes the concrete implementation. (Actually, it might be unnecessary to define a module "IPv6" if it just contains header definitions, but maybe, e.g., checksum functions can be reused, too.)

After thinking just for some minutes over a new name for the stack, I thought that "NG" (pronounced Angie? ;)) may be not a bad idea after all and would save us from quite some renaming... All we would have to do then is to extract the common functionality and move it generic IPv6 and co. files.

What do you think?

Cheers, Oleg

Hi,

After thinking just for some minutes over a new name for the stack, I thought that "NG" (pronounced Angie? ;)) may be not a bad idea after all and would save us from quite some renaming... All we would have to do then is to extract the common functionality and move it generic IPv6 and co. files.

What do you think?

Due to its known meaning "ng" is as bad a name as "new" or "next", because it will loose this meaning in the foreseeable future.

I'm not sure if naming is necessary at all. I think public/shared headers can be used without a problem, and non-default implementations (I assume the current "ng" implementation will be the default) can as well get a characterizing suffix like "_light" or "_tiny" if and when they arrive.

Cheers, Ludwig

Hi!

> What do you think?

Due to its known meaning "ng" is as bad a name as "new" or "next", because it will loose this meaning in the foreseeable future.

Star Trek TNG hasn't lost its meaning even after twenty years... But I'm really not in favor of any particular name.

I'm not sure if naming is necessary at all. I think public/shared headers can be used without a problem, and non-default implementations (I assume the current "ng" implementation will be the default) can as well get a characterizing suffix like "_light" or "_tiny" if and when they arrive.

As long as there are only headers to be shared, no problem, but for functions it's getting more complicated.

Cheers, Oleg

Hi, I’m not in favor of keeping the prefix. Three reasons:

  1. https://github.com/RIOT-OS/RIOT/pull/2731#discussion_r27350056
  2. I’m really looking forward to the day when I don’t need to prepend the ng_ prefix anymore
  3. “Angie” sounds to me like a political statement :wink:

In all seriousness: I think Ludwigs proposal is better.

Cheers, Martine

Hi!

I'm not in favor of keeping the prefix. Three reasons:

Forget about the ng, that's unrelated to the question that we need a name for the stack.

Cheers, Oleg

Hi Oleg,

Hi,

In all seriousness: I think Ludwigs proposal is better.

In other words: the new stack will be the default one, while smaller implementations can be called `tiny_`, `micro_` or whatever. The proposed architecture, that other implementations can use `ipv6/hdr.h`, `ipv6/addr.h` or similar is mostly in place already.

IMHO we should put implicit headers, like an ipv6 network header .h, into net/something. Everything stack related should go somewhere else, like "net/tiny/*" or even "net/angie/*".

The idea is that if someone uses another stack, he should be able to remove e.g., the "tiny" folder in order to check for unintended dependencies.

I'm not saying that we shouldn't have this default stack, I just have the feeling that we should make sure that we don't re-implement the wheel multiple times, and clear but independend stuff (like header definitions, address parsing) should end up in "common" directories.

I'm afraid that having an un-seperated default network stack leads to confusion.

Is it that much of a hassle to name the default stack and move the specific includes & implementations into subfolders?

Kaspar

Hi Kaspar,

Hey,

Hi,

Hi,

Perfect. Still, what do we refer to when talking about "this new tack"? "the default stack"?

Yes.

The problem here is that the interfaces someone uses will imply the implementation.

For example, if someone includes "net/udp.h", after dropping the "ng_" prefix, you get the "default stack" udp include file.

IMHO that file should include a stack agnostic interface whose implementation is selected by e.g., USEMODULE.

Same for all other developer-accessible protocols.

I'm happy with having a default network stack. I'm not happy if that stack's specific interface ends up as de-facto standard interface, making switching stacks practically impossible.

Kaspar

Hi everyone,

giving the ng_stack a name sounds like a very good idea to me (and as far as I remembered I already mentioned this last summer...). Though finding a name is tough and I don't like the obvious once (flexnet_, default_, riotnet_, etc...).

Also 'cutting' out the re-usable parts as headers, header parsing, checksum calculation and some others might make sense, though with this I think we have to keep in mind, that not every network stack implementation has to use those 'generic' building blocks, as these implementations might have their own requirements to certain function signatures etc...

When it comes to protocol header files, as 'net/udp.h', I would be even more careful. I don't think we will have a generic udp header, that each network stack will comply to. In my opinion, each network stack should just define it's own header files, as these will differ depending on their internal implementation...

The only important thing is, that we will have a clearly defined interface for applications (e.g. RIOT sockets, CoAP or whatever).

So I would say: let's find a name?!

Cheers, Hauke

Hi!

giving the ng_stack a name sounds like a very good idea to me (and as far as I remembered I already mentioned this last summer...). Though finding a name is tough and I don't like the obvious once (flexnet_, default_, riotnet_, etc...).

To make it easier, I think we can even discard the name prefix. It's very unlikely that we want to have to have two IPv6 implementations running parallel. So, assume we have `default_stack` and `tiny_stack`, it's fine if both define `ipv6_send()` instead of `default_ipv6_send()`.

Also 'cutting' out the re-usable parts as headers, header parsing, checksum calculation and some others might make sense, though with this I think we have to keep in mind, that not every network stack implementation has to use those 'generic' building blocks, as these implementations might have their own requirements to certain function signatures etc...

Sure, that remains to be seen, but I think for some basic functionalities it might be possible.

When it comes to protocol header files, as 'net/udp.h', I would be even more careful. I don't think we will have a generic udp header, that each network stack will comply to. In my opinion, each network stack should just define it's own header files, as these will differ depending on their internal implementation...

Things like protocol headers will be exactly the same for every implementation of this protocol, so cutting these out is a MUST. Everything implementation specific should, of course, stay in separate headers.

Cheers, Oleg

Hi,

I just stumbled across ng_netconf - we should rename this to avoid confusion with RFC 6241 [1]. If the stack would have a name, we could simply call it <NAME>_conf...

Cheers, Oleg

[1] https://tools.ietf.org/html/rfc6241

Hi,

Martine and me had the same discussion yesterday. Until we have a name, NG_NETOPT would be the natural choice I guess…

Cheers, Hauke

Hey,

Hey,

what about ipc_stack due to its utilization of the former? But still: I’m still not convinced of the reason to give it a name. All operating systems have a default stack but no one is bound to use it and can use their ultra stack etc. (in Linux e.g. as a library). The naming of uIP is mainly historic, since it started out as a seperate project. As far as I know TinyOS’ stack has no name either.

Cheers, Martine

Hi!

what about `ipc_stack` due to its utilization of the former? But still: I'm still not convinced of the reason to give it a name. All operating systems have a default stack but no one is bound to use it and can use their `ultra` stack etc. (in Linux e.g. as a library). The naming of uIP is mainly historic, since it started out as a seperate project. As far as I know TinyOS' stack has no name either.

Contiki has uIP and RIME, TinyOS has BLIP if I remember correctly. We have ccn-lite, OpenWSN, and this one. I think we cannot compare to Linux, BSD, and the like here. They can afford to make different modules somehow interoperable at cost of memory, we cannot.

Won't repeat the arguments for naming.

Cheers, Oleg

Hi,

Hi!

what about `ipc_stack` due to its utilization of the former? But

still: I'm

still not convinced of the reason to give it a name. All operating

systems

have a default stack but no one is bound to use it and can use their `ultra` stack etc. (in Linux e.g. as a library). The naming of uIP is mainly historic, since it started out as a seperate project. As far

as I

know TinyOS' stack has no name either.

Contiki has uIP and RIME, TinyOS has BLIP if I remember correctly. We have ccn-lite, OpenWSN, and this one.

Isn't ccn-lite using the lower layer(s) (MAC, LLC, driver - correct me if I'm wrong) of the old stack and should be upgraded to use the lower layer(s) of the new stack? (What about OpenWSN?) Or are those layers not considered part of the stack?

I think we cannot compare to Linux, BSD, and the like here. They can afford to make different modules somehow interoperable at cost of memory, we cannot.

As far as I remember, the modularization of the new stack had exactly this as a goal.

Cheers, Ludwig

Hi Ludwig!

Isn't ccn-lite using the lower layer(s) (MAC, LLC, driver - correct me if I'm wrong) of the old stack and should be upgraded to use the lower layer(s) of the new stack? (What about OpenWSN?) Or are those layers not considered part of the stack?

Yes, you're right, ccn-lite can run directly on top of Link Layer (and actually more or less any other layer) and should be upgraded.

OpenWSN provides a full network stack from Link to Application Layer.

>I think we cannot compare to Linux, >BSD, and >the like here. They can afford to make different modules somehow >interoperable >at cost of memory, we cannot.

As far as I remember, the modularization of the new stack had exactly this as a goal.

Yes, that's correct. However, there will - as Kaspar pointed out - still exist other stack implementations. Actually, this might be another reason for a name: if one implements a new module for this stack, one should indicate that it is compatible to stack XYZ.

Cheers, Oleg