Subject: [rrg] The Pouzin Society

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 27 Apr 2009 12:54:34 +0200

[Disclaimer: not involved with these people.]

http://www.pouzinsociety.org/

The Pouzin Society's purpose is to provide a forum for developing
viable solutions to the current Internet architecture
crisis. Membership is open to qualified members of the networking
community, both academic and commercial. Please send an email to
[email-masked] to introduce yourself and request more
information.  Through an ongoing series of meetings, collaborative
efforts and publications, we seek to guide the emergence of a new
network architecture that will support user needs for the decades to
come.

Please read our Challenge for Researchers and Challenge for Businesses
and consider getting involved.

Also, see <http://www.itwire.com/content/view/24655/1231/> "New
society aims to 'save' the Internet"

---

From: Marshall Eubanks <[email-masked]>
Date: Mon, 27 Apr 2009 07:26:49 -0400

> [Disclaimer: not involved with these people.]

Me neither, but note :

John Day Founder

Mike O'Dell Founder and Chair

Chris Williams  Evangelist

Regards
Marshall

> _______________________________________________
> rrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/rrg
>

Regards
Marshall Eubanks
CEO / AmericaFree.TV

---

From: William Herrin <[email-masked]>
Date: Wed, 29 Apr 2009 20:52:41 -0400

> http://www.pouzinsociety.org/

As we consider radical changes to the Internet architecture, I would
observe that there are a couple of things which are likely to remain
true.

1) The communications which leave the host and move through the system
will be in the form of packets of data of one sort or another.

2) Each computer in the path between the user's computer and the
computer providing the service the user wants to access will receive a
packet, consult a data structure to determine if and how to modify,
combine and/or split the packet, consult a data structure to determine
which next hop(s) to send the packet to, and then transmit the packet.

I read http://02d7097.netsolhost.com/images/IPCPaper_Madrid_MattarJD1569144094.pdf
. At first it seemed like a strategy-B variant but on a closer read it
seems like Day wants to do something different at the forwarding layer
too. I'm really not following how the n-layer DIFs go about forwarding
packets.

Now, I relate to a network protocol in terms of the linear,
step-by-step action on individual packets. So, for someone who
understands this IPC-based architecture proposal better than I do, I
would ask the following question:

Would you explain to me how the data packet gets from my machine to
Google's machine, listing the changes in the packet at each hop and
with particular attention to the nature and contents of the data
structures consulted at each hop along the way?

Here's an example of what I'm looking for using the the current
Internet architecture as a basis:

Source: Set the destination IP to Google's server. Consult the routing
table which contains two routes: local LAN and Everything Else.
Address matches Everything Else. Consult the ARP table for the
ethernet MAC address of the next hop for everything else. Modify the
packet inserting an Ethernet header at the front containing the
destination MAC address of the router for Everything else. Transmit on
the Ethernet.

First Hop: Pick the destination IP address from the packet. Consult
the routing table which contains a few routes including Everything
Else. Address matches Everything Else. Consult the ARP table for the
ethernet MAC address of the next hop for everything else. Modify the
packet replacing the Ethernet header at the front with one containing
the destination MAC address of the router for Everything else.
Transmit on the Ethernet.

Second hop: Repeat.

Third hop: Pick the destination IP address from the packet. Consult
the routing table which contains 300,000 routes including a route
covering multiple servers at Google. Address matches the Google route.
Consult the ARP table for the ethernet MAC address of the next hop for
Google. Modify the packet replacing the Ethernet header at the front
with one containing the destination MAC address of the router for
Google. Transmit on the Ethernet.

Fourth hop: Repeat.

Fifth hop: Repeat.

Sixth hop: Pick the destination IP address from the packet. Consult
the routing table which contains a few routes including Everything
Else. Address matches one of the others, the Google route. Consult the
ARP table for the ethernet MAC address of the next hop for Google.
Modify the packet replacing the Ethernet header at the front with one
containing the destination MAC address of the router for Google.
Transmit on the Ethernet.

Seventh hop: Repeat.

Eighth hop: Pick the destination IP address from the packet. Recognize
the destination IP address as myself.

Done.

Thanks in advance,
Bill Herrin

-- 
William D. Herrin ................ [email-masked]  [email-masked]
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004

---

From: Toni Stoev <[email-masked]>
Date: Thu, 30 Apr 2009 04:50:58 +0300

Hey RRG,

In a network of devices why would we route between processes?

Toni

---

From: Marshall Eubanks <[email-masked]>
Date: Mon, 27 Apr 2009 07:23:43 -0400

Me neither, but note :

John Day Founder

Regards
Marshall

Regards
Marshall Eubanks
CEO / AmericaFree.TV