[NTK_RFC 002] Bandwidth measurement revised

Here it is the revised NTK_RFC 002.

			== NTK_RFC 0002 ==
	  
	  http://lab.dyne.org/Ntk_bandwidth_measurement

Subject: bandwidth measurement

----
This text describes a change to the Npv7.
It will be included in the final documentation, so feel free to correct it.
But if you want to change the system here described, please contact us first.
----

== Link measurement issues ==

In the current version of the Npv7, the Radar measures the link quality using
only the rtt (round-trip time) and packets losses.
This isn't optimal, because the bandwidth capacity is ignored, thus a link
having a poor bandwidth, f.e 20Kbps, but a good latency, will be preferred
over a link with a big bandwidth but a medium latency.

== Improvement ==

A node must include in the Tracer Packets, not only the rtt of the traversed
link, but also the current bandwidth capacity.
In this way it will be possible to have a traffic shaping based also on the
real bandwidth of the links.

Questions

Hello everybody!

Yesterday at the Underscore_TO Hacklab in Turin, Italy, we (me and a
friend) presented Netsukuku to a few other interested people.
We collected some questions and doubts from the discussion, and I'm
forwarding them here to find some answers  and to let you update the
FAQ/docs, if worth.

In random order:
#1: how are the routes stored? Does Ntk just save the "next hop" or the
entire route until *every* other node?
#2: can someone show us how to calculate the numbers ("in the ipv4, all
the maps needs 144K of memory, while in the ipv6 1996K are required")
shown in the main_doc?
#3: Is a gnode a group of "physically near" nodes?
#4: is answer #3 is no, what would be the "lag" of every qspn round?
#5: in a qspn round of a higher level (i.e. level 2), who answers for
every gnode?
#6: how exactly is the RSA key used for ANDNA long?
#7: where are the fractals? Isn't all this just recursive? And the chaos
theory?

We would have many others, but mostly dependent on these. We'll wait for
the answers, and then come back for more 

Thank you very much and... complimenti!!! :-P
Saludos
_______________________________________________
Netsukuku mailing list
Netsukuku@...

Re: Questions

On Sat, Nov 04, 2006 at 06:51:29PM +0000, <brain@...>:
~> #1: how are the routes stored? Does Ntk just save the "next hop" or the
~> entire route until *every* other node?

The first one, because every node has a route to reach the desired 
destination.

~> #2: can someone show us how to calculate the numbers ("in the ipv4, all
~> the maps needs 144K of memory, while in the ipv6 1996K are required")
~> shown in the main_doc? 

Here there are some numbers:
http://lab.dyne.org/Netsukuku_scalability

Briefly, to calculate them: 
        1) go in map.h
        2) calculate the sizeof `struct map_node'
        3) multiply it per MAXGROUPNODE
        4) sum it to `(sizeof map_rnode) *MAXRNODEBLOCK`
	5) do the same things for gmap.h (map_gnode) and bmap.h

~> #3: Is a gnode a group of "physically near" nodes?

A gnode of level 0 is. If you're are talking of higher levels, then it is not
necessarily true.

~> #5: in a qspn round of a higher level (i.e. level 2), who answers for
~> every gnode?

The bnodes (border nodes) replies for their own gnodes. 

[NTK_RFC 0013] Caustic routing - A multipath generalization

		  == NTK_RFC 0013 ==

	http://lab.dyne.org/Ntk_caustic_routing

----
This text describes a possible expansion of the current Npv7 protocol.
It will be included in the final documentation, so feel free to correct it.
But if you want to change the system here described, please contact us first.
----

== Caustic routing ==

Multipath routing is method which sends packets of a same connection through
different paths.

Caustic Routing is a multipath generalization which aims to redistribute the
network traffic in an efficient way, imposing a small load on the interested
nodes.

Note that this RFC is not complete. If you want to contribute to its
development, DO IT! ;)

== Basic idea ==

The basic idea of the Caustic Routing (CR) is to apply recursively the
multipath routing: the source node S chooses one or more neighbours R as
gateways to reach the destination D. Each neighbour r_i of R chooses one or
more gateways R'(r_i) to reach the destination D. Each neighbour r'_i of
R'(r_i) chooses one or more gateways to reach the destination D. And so on,

Re: Utente interessato al testing di netsukuku su qemu.

On Wed, Nov 08, 2006 at 12:09:15PM +0100, <Dan>:
~> Vorrei fare da nodo però non utilizzando linux mi verrebbe alquanto scomodo.
~> A quanto sembra non è ancora stato testato il funzionamento su qemu.
~> Io sarei disponibile a tale testing.

Ottimo!

Allora, considera che "testare su qemu" equivale a "trovare un modo per usare
ntkd su qemu", quindi la tua missione e' questa:
	
	* installa qemu su windows

	* installaci sopra un distro che abbia linux-2.6.X. (non serve una
	  distro grossa, l'importate e che abbia almeno le iputils, bash,
	  libgmp, OpenSSL, iptables).

	* compila su un altro computer ntkd oppure scarica i binari statici da
	  http://netsukuku.freaknet.org/files/packages/netsukuku-0.0.9b-i486-9.tgz

	* a questo punto, prima di tutto devi configurare qemu per dargli una
	  o piu' schede di rete virtuali. Anzi, devi fare in modo che tu ti
	  possa connettere dall'interno di qemu alla tua LAN reale e anche a
	  Internet.
	  Sicuramente ci saranno diversi howto per fare questo.

	* nell'host (su windows) devi fare in modo di usare qemu come default
	  gw. Credo che devi settare l'ip di qemu come default gw sulle
	  proprieta' della connessione TCP/IP, o qualcosa del genere.
	  Inoltre setta come dns l'ip di qemu.

ANDNA on Windows Vista

Abnormal Netsukuku Domain Name Anarchy implemented on windows by 
microsoft.

http://www.microsoft.com/technet/itsolutions/network/p2p/pnrp.mspx

[8<--------------------------------]

Peer Name Resolution Protocol

In peer-to-peer environments, peers rely on name resolution systems to 
resolve each other's network locations (addresses, protocols, and 
ports) from names or other types of identifiers. Peer-to-peer name 
resolution has been complicated by transient connectivity and 
shortcomings in the Domain Name System (DNS).

The Microsoft® Windows® Peer-to-Peer Networking platform solves this 
problem with the Peer Name Resolution Protocol (PNRP), a secure, 
scalable, and dynamic name registration and name resolution protocol 
first developed for Windows XP and then upgraded in Windows Vista™ 
(now in beta testing). PNRP works very differently from traditional 
name resolution systems, opening up exciting new possibilities for 
application developers.

[-------------------------------->8]

http://netsukuku.freaknet.org/index.php?pag=documentation&file=main_documentation/netsukuku

[8<--------------------------------]

Re: Utente interessato al testing di netsukuku su qemu.

0;
-- 
:wq!
"I don't know nothing" The One Who reached the Thinking Matter   '.'

[ Alpt --- Freaknet Medialab ]
[ GPG Key ID 441CF0EE ]
[ Key fingerprint = 8B02 26E8 831A 7BB9 81A9  5277 BFF8 037E 441C F0EE ]

From: Dan <ketchup.suicide@...>
Subject: Re: Utente interessato al testing di netsukuku su qemu.
Date: 2006-11-08 16:59:03 GMT

Alpt ha scritto:
> On Wed, Nov 08, 2006 at 12:09:15PM +0100, <Dan>:
> ~> Vorrei fare da nodo però non utilizzando linux mi verrebbe alquanto scomodo.
> ~> A quanto sembra non è ancora stato testato il funzionamento su qemu.
> ~> Io sarei disponibile a tale testing.
>
> Ottimo!
>
> Allora, considera che "testare su qemu" equivale a "trovare un modo per usare
> ntkd su qemu", quindi la tua missione e' questa:
> 	
> 	* installa qemu su windows

Qspn.tex addition - non redundant routes

Here it is a little addition to the document:
http://netsukuku.freaknet.org/doc/main_doc/qspn.pdf (section 11.2)

----

\subsection{Disjoint routes}

The routing table of each node should be differentiated, i.e. it should not
contain redundant routes.

For example, consider these $S \rightarrow D$ routes:
\begin{align}
	& SBCFG_1G_2G_3G_4G_5G_6G_7 \dots G_{19} D	\\
	& SRTEG_1G_2G_3G_4G_5G_6G_7 \dots G_{19} D	\\
	& SZXMNO_1O_2O_3O_4O_5D				\\
	& SQPVY_1Y_2Y_3Y_4D
\end{align}
The first two are almost identical, indeed they differ only in the first three
hops. The last two are, instead, totally different from all the others.\\
Since the first two routes are redundant, the node $S$ should keep in memory only
one of them, saving up space for the others non-redundant routes.
\newline

Keeping redundant routes in the routing table isn't optimal, because if one of the
routes fails, then there's a high probability that all the other redundant
routes will fail too. Moreover when implementing the multipath routing to load
balance the traffic there won't be any significative improvements.
\newline

topology.tex work in progress

We've started to write topology.tex, the document which describes
in details the Netsukuku topology.

You can help in several ways:
	
	* if you have any questions, doubts, FAQs regarding the topology, the
	  maps and all this kind of stuff, ask it now!

	* if you already know something about it, write a bit of the
	  documentation
	
	* you can draw pictures which helps to comprhend better some concepts
	  of the topology (f.e. what is a bnode, a rnode, ...)

The current draft is here:
http://hinezumi.org/viewcvs/netsukuku/proto/doc/topology/

0;
--

-- 
:wq!
"I don't know nothing" The One Who reached the Thinking Matter   '.'

[ Alpt --- Freaknet Medialab ]
[ GPG Key ID 441CF0EE ]
[ Key fingerprint = 8B02 26E8 831A 7BB9 81A9  5277 BFF8 037E 441C F0EE ]
_______________________________________________
Netsukuku mailing list
Netsukuku@...
http://lists.dyne.org/mailman/listinfo/netsukuku

FAQ - Q: What about the security of my packets?

New FAQ added.

----

Q: What about the security of my packets? Everyone will be able to sniff them!
A: The situation in Ntk isn't much different from the current Internet:

        - in the Internet, only those few who have access to the ISPs, the
          routers and the backbones can sniff, alter and destroy your
          traffic.

        - in Netsukuku, only the nodes belonging to the temporary route, which
          you are using for your connection, will be able to sniff, alter
          and destroy your traffic. However  consider that:

                1) with the use of multipath your traffic is split among
                   different routes, thus each route will be able to read only
                   a partial part of your traffic.

                2) for each connection you have a potential different route

   The solution to avoid these problems are alike: use secure protocols https,
   SSH, SSL, and so on.

   Moreover in Netsukuku, there will be a complete cryptographic layer, see
   http://lab.dyne.org/Ntk_carciofo

--

-- 
:wq!