Subject: [arch-d] A straw man analysis of why send-receive packet paradigm is unsustainable

From: Pekka Nikander <[email-masked]>
Date: Fri, 1 Dec 2006 11:37:56 +0200

[This is _really_ long term.  If you are not interested in 10+ years  
things, don't bother reading.]

It is a well established view that smart ends and a dumb, open,  
neutral network are good, for a number of well-known reasons.  Herein  
I present a claim that if we want to retain that approach, we will  
have to give up the current send-receive packet paradigm, sooner or  
later.  While there are ample experimental evidence for my claim, I  
will skip that and focus on a techno-economic analysis.

The current Internet is based on what I call the send-receive packet  
paradigm.  That is, the fundamental primitives in the network are  
"send" and "receive", on the packet level.  More importantly, what is  
built in into this paradigm is the idea that anyone can send anything  
to anybody, and the network will do its best to get that through.   
While that is very simple and well known, let me dissect it a little  
bit:

1. The paradigm implies that any packet sent is delivered, or at  
least tried to get delivered.

2. The paradigm implies that the sender is free to select the  
receiver.  Sender's consent.

3. The paradigm implies that the receiver need to process, at least  
minimally, any traffic sent to it by any sender.

Of those, the last one appears to be the most important one.  Think  
about it!

The fundamental reason why I claim, below, that the current paradigm  
is unsustainable, in the longer run, is the following:

    Sending packets is cheaper than receiving and processing them

I think that the claim could probably be based on physics, entropy,  
and energy, but I won't go into that; I'm not an expert there.   
Instead, let's consider two well known examples: spam and DDoS.

Sending spam costs the sender relatively little, even if they are not  
using zombie farms.  They basically create a single message, and send  
it repeatedly, often even allowing the network to replicate it.   
Receiving, on the other hand, is expensive.  The receiver must  
decide, somehow, whether the received message is spam and should be  
ignored, or not.  To make the decision, quite a lot of processing is  
needed, if not by the machines, then by the user.

In a DDoS attack, sending is even cheaper to the attacker due to  
utilising zombie farms.  The receiver pays heavily, both on  
legitimate traffic lost due to congestion and on even minimally  
processing those attack packets that actually reach the attacked  
system.  More importantly, however, if we consider the packet level  
we can see the same pattern as in the spam case.  The attacker  
doesn't need to spend much energy in generating packet contents; in  
many cases the packets can contain whatever garbage.  On the other  
hand, the receiver needs to spend at least some energy in deciding  
whether the received packet is legitimate or not.

That leads to the following corollary:

    Receiving packets is expensive because of the associated decision  
process

Note that it is possible to send mindlessly, without needing to make  
any decisions at the packet level.  The malicious send can make all  
the decisions in advance.

The implication is clear:  The original, open, neutral end-to-end  
network based on the send-receive packet paradigm is unsustainable in  
the face of large amounts of malicious players.

Note that this is fundamental.  It is impossible to allow anyone to  
send any packets to anyone, without some people being able to abuse  
it in a way or another.  Conversely, if we want to also in the more  
distant future have a network that is built on the core values of the  
original Internet, we need to give up its fundamental technical  
foundation, the send-receive packet paradigm.

I think what's above is enough for a single message.  I'll leave the  
wider implications and options for action to another message.

--Pekka Nikander

_______________________________________________
Architecture-discuss mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/architecture-discuss

---

From: Andrew McGregor <[email-masked]>
Date: Fri, 1 Dec 2006 23:31:33 +1300

On 01/12/2006, at 10:37 PM, Pekka Nikander wrote:

> The fundamental reason why I claim, below, that the current  
> paradigm is unsustainable, in the longer run, is the following:
>

It's a very simple argument:

Transmission of a packet *increases* the entropy of the network.

Reception *decreases* the entropy of the network.

The second law of thermodynamics (the same one that prohibits  
perpetual motion machines) guarantees that the latter operation is  
more expensive than the former.  TANSTAAFL.

Practical considerations imply that the actual cost of reception is  
many times higher than in transmission; in wireless systems, it can  
be millions of times higher.

QED.

Andrew

---

From: <[email-masked]>
Date: Fri, 1 Dec 2006 12:35:22 +0200

Andrew 

>Practical considerations imply that the actual cost of 
>reception is many times higher than in transmission; in 
>wireless systems, it can be millions of times higher.

Actually, with some wireless radios, transmiting is more
expensive (from a power consumption point of view) than
receiving.

John

---

From: Scott W Brim <[email-masked]>
Date: Fri, 01 Dec 2006 08:50:49 -0500

>    Receiving packets is expensive because of the associated decision

...

> the face of large amounts of malicious players.

The EME RG could help here.  In theory, it can push some of the cost
of receiving packets (I agree with you btw) into a setup phase, with
establishment of trust etc.

Scott

---

From: Jefsey_Morfin <[email-masked]>
Date: Fri, 01 Dec 2006 15:04:24 +0100

At last! Welcome to virtual circuit switching and to retrieve function!
The most important e-Human Right is to NOT receive.

But you must give up some other paradigms too.

1) the "dumb" network is not dumb, it is cramed with routing 
intelligence. Get rid of it. Split routing from transport.
2) end to end is nice, as is plug to plug, but the real interest in 
networking is brain to brain/cpu. Stop mixing the two.
3) change the RFC 3935 core value and use "distributed" rather than 
"decentralised" and adopt "user centric"
4) do not focus on the internode protocol but start from the network 
operating system
5) the root server system

Now, I am not sure at all that all this is for 10+ years from now. 
This was the way it worked internationally 30 years from now, and the 
way you can manage today _at_usage_level_. The digital ecosystem is 
not a monolith. You can implement a store-retrieve email and culture 
based upon SMTP, etc. You can read IP in a second degree way to use 
it differently.
jfc

---

From: Pekka Nikander <[email-masked]>
Date: Sat, 2 Dec 2006 10:44:33 +0200

> establishment of trust etc.

Maybe.  Interestingly, if you look at the current set of still- 
evolving EME requirements, you'll notice that something like Hi3  
would relatively beautifully fulfil most of them.  More generally, to  
me it looks like that the EME security requirements will be easier to  
reach if we adapt a new cryptographic name space, such as in HIP or  
SHIM6 with CGAs.

But, if we do so, we will give up some of our core values in order to  
stay within the current paradigm.  By taking the EME/Hi3/overlay/...  
route, we retain the basic send-receive packet paradigm while giving  
up some parts of the idea of an dumb, open, neutral network.  At  
minimum, the network is no more dumb as it has the ability to heavily  
filter traffic.  Nor it is any more open or neutral as some traffic  
will be allowed and other not.

The overall issue is very hard to swallow.  I'm sure I'll need to  
repeat the point umpteen times before it starts to sink in general in  
this community.  Basically, we have two choices:

1. Give up some of our core values, or

2. Give up the send-receive packet paradigm.

In my opinion, our almost "holy" long-term challenge is to find a new  
paradigm that will be able to sustain as much as possible of our core  
values: http://www.isoc.org/pubpolpillar/principles.shtml

Consider especially the bullets #3, #6, and #7 on the above ISOC  
page.  Any approach that injects discriminative intelligence into the  
network will have difficulties in sustaining at least those three of  
the values.

Finding a new paradigm is, well, hard.  Furthermore, once one is  
found, most people will fight bitterly against it, in the same way  
the bellheads fought (and are still fighting :-) against the send- 
receive packet paradigm.  How long it took for the packet paradigm to  
get accepted as main stream?  Something like 30 years?  (1961 to 1992?)

That all said, I also happen to think that in the short/medium term  
something like HIP or SHIM6+CGA is most probably the right way to  
go.  As I've written already, if properly adopted, something like  
that will give the current paradigm some 10-20 years more time.  It  
will help us to build the needed new functionality at the transport  
and up.  And, as a very important short-term benefit, it will buy us  
more flexibility to the routing and addressing system.

I think Noel was able to put this very nicely in
http://www1.ietf.org/mail-archive/web/architecture-discuss/current/ 
msg00881.html

> Expanding on this a bit, I see HIP as potentially part of an  
> alternative strategy for how to evolve a large, in-service  
> architecture. I am frankly dubious about fork-lift upgrades, where  
> one replaces an entire layer with something else. I think a much  
> better strategy is a "piece-by-piece" one, where one tries to  
> deploy some (hopefully well-architected) new pieces that, while  
> each stands on its own, both in terms of functionality to give you  
> some new capability, as well as cost/benefit, *together* add up to  
> a coherent new whole.

What I'd like to see would be some kind of "requirements" (gasp) or  
goals, from two very different points of view:

1. What do the apps and users need?  The EME requirement list seems  
like a reasonably good start.

2. What can be done at the routing and addressing side if the  
forwarding addresses are freed from their application/transport level  
identity function, making the whole addressing system much more  
flexible than it is today.

Such "requirement" lists would help us to see what is missing from  
the current HIP and/or SHIM6+CGA approaches.  Given the time we've  
spent on HIP and SHIM6+CGA (HIP was conceived in 1999, the base ideas  
which later became CGA and SHIM6 around 2001 if not earlier), I'd be  
very dubious if we decided to start from scratch in our short/middle  
term approach.

--Pekka Nikander

---

From: John Leslie <[email-masked]>
Date: Sat, 2 Dec 2006 19:18:50 -0500

> will be allowed and other not.

   Frankly, I don't think we ever _had_ a "dumb, open, neutral" network.
But we were perhaps "close enough," and that is what I would prefer to
get from my upstreams and supply to my customers.

> 1. Give up some of our core values, or

   Which, for example?

> 2. Give up the send-receive packet paradigm.

   I don't think packet transport is going away. What does Pekka think
we _will_ lose?

> page.

   I think Pekka means:
] 
] (3) The genius of the Internet is that its decentralized architecture
]     maximizes individual users' power to choose (or create) and use
]     the hardware, software, and services that best meet their needs,
]     and if the Internet is to continue to be a platform for innovation
]     and creativity, its open, decentralized nature must be preserved.
] 
] (6) The social, political, and economic benefits of the Internet are
]     substantially diminished by excessively restrictive governmental
]     or private controls on computer hardware or software,
]     telecommunications infrastructure, or Internet content.
] 
] (7) Rewarding and productive use of the Internet depends on the
]     ability to trust critical services.

> Any approach that injects discriminative intelligence into the network
> will have difficulties in sustaining at least those three of the values.

   Clearly, NATs and firewalls do violence to "openness". For the most
part, I consider these to be _at_ the edge, and thus "not my problem".

   Governments _will_ try to control things -- it's their very nature.
We have traditionally looked upon this as the censorship problem --
indistinguishable from "damage" and needing to be "routed around".

   Private controls are a newer issue. As the "big telcos" have
discovered a market, they have largely succeeded in effectively
monopolizing the "broadband" market. There is a real danger that
these near-monopolies will make government controls more effective.

   What "critical services" need to be "trusted", and what we mean
by "trusted" are pretty open questions...

> found, most people will fight bitterly against it,

   I basically agree. Thus, I'm not inclined to look for solutions
from "new paradigms".

> go.

   Neither of these, of course, should be our concern: we should be
talking architecture. (There are plenty of other lists where folks
can discuss band-aids!) But I must confess to being increasingly
irritated by well-intentioned folks discussing the merits of
different brands of band-aids on this list.

> http://www1.ietf.org/mail-archive/web/architecture-discuss/current/ 

   Noel is a good fellow. And, frankly, his discussion of the merits
of different brands of band-aids is very good -- better than I could
have done. But that discussion still belongs elsewhere: which brands
are offered for sale won't be decided here, and the marketplace won't
seek our advice on which to buy.

>> alternative strategy...

   No thank you. (Well, not now anyway...)

   However, speaking for myself only, I'd be happy to see a number of
alternatives for identifying hosts being actively developed. I think
we'd be poorly advised to (try to) limit the format of host names.

> like a reasonably good start.

   Actually, it seems like a perfectly _dreadful_ start for developing
an architecture. I'm willing to stipulate that this is, no doubt, what
user say today that they want. An architecture, however, must look to
enable _future_ wants.

   (In particular, use of the term "middlebox" suggests placement of
entirely inappropriate intelligence within the routing infrastructure.)

> flexible than it is today.

   The important point is what responsibilities can be _removed_ from
the routing infrastructure. Especially when we hear worries about
"meltdown", we should keep lower layers "as simple as possible".

> the current HIP and/or SHIM6+CGA approaches.

   We already know what's missing form them: consideration of the
overall evolving of an Internet architechure.

   (Not to criticize them: it wasn't their job.)

> Given the time we've spent on HIP and SHIM6+CGA (HIP was conceived
> in 1999, the base ideas which later became CGA and SHIM6 around 2001
> if not earlier), I'd be very dubious if we decided to start from
> scratch in our short/middle term approach.

   Wasn't there another list started to talk about immediate steps?

--
John Leslie <[email-masked]>

---

From: Peter Sherbin <[email-masked]>
Date: Sun, 3 Dec 2006 18:38:06 -0800 (PST)

> the face of large amounts of malicious players.

What if nodes are protected so an outsider can not make them zombie. This leaves a
sender with only a single uplink to send. If a sender pays for each sent packet she
would send only when her need justifies associated costs.

Because there are many senders a receiver would still get a large number of packets.
To minimize decision costs a receiver must be able to set "unwanted sender" criteria
to automatically discard packets from such senders.

>anyone can send anything to anybody, and the network will do its best to get that
through

Here is how the paradigm should work economically (=physically=logically):
Bob sends to Alice holiday greetings of 100KB for which he pays e.g. 0.0001 dollars
Alice sends to Bob a movie present of 3GB and she pays 3.00 dollars

Slowly but surely providers are moving towards the usage based charges. For now they
bill total GB of upload + download. This unjustly penalizes heavy downloaders.
Nevertheless usage based pricing is a way to go.

Thanks,

Peter

> wider implications and options for action to another message.

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

---

From: Peter Sherbin <[email-masked]>
Date: Sun, 3 Dec 2006 18:46:55 -0800 (PST)

> Reception *decreases* the entropy of the network.

Network entropy applies to its physical elements only. I.e. wires and nodes get warm
while working. Bits oder does not change by itself as long as the strength of the
pulse is preserved. As somebody rightly noted data has no mass.

Thanks,

Peter

> be millions of times higher.

____________________________________________________________________________________
Want to start your own business?
Learn how on Yahoo! Small Business.
http://smallbusiness.yahoo.com/r-index

---

From: Andrew McGregor <[email-masked]>
Date: Mon, 4 Dec 2006 15:48:21 +1300

> Nevertheless usage based pricing is a way to go.

Living in a country where this is presently the norm and we are  
moving away from it, this is NOT the way to go.

Why?  What happens if your machine does get taken over as part of a  
botnet or whatever, and it sends flat out for six weeks until you get  
your bill and notice?  How about a bill for $40,000.00?  And the ISP  
will ignore your plea that the machine was virus infected... because  
after all, it did send the traffic, and that was the deal.

This is only the way things are going because the telcos got into the  
internet.  It isn't how things should be.  I don't want to be  
monitoring my net usage by the byte, and having to check every day  
that something hasn't happened.  That reduces the utility of the  
network by a major fraction, IMO.

Andrew

---

From: Peter Sherbin <[email-masked]>
Date: Sun, 3 Dec 2006 20:20:53 -0800 (PST)

This is a plain evidence of the Internet beign marketed while the product is unsafe.
On the other side there is an opportunity to sell security.

> after all, it did send the traffic, and that was the deal.

That was not the deal if I can not control my machine. I should keep ISP responsible
for letting the thief into my premises.

> I don't want to be  monitoring my net usage by the byte, and having to check every
day that something hasn't happened.

And I do. For ISP money is in bits sent by users.

Thanks,
Peter

 
____________________________________________________________________________________
Do you Yahoo!?
Everyone is raving about the all-new Yahoo! Mail beta.
http://new.mail.yahoo.com

---

From: Peter Sherbin <[email-masked]>
Date: Mon, 4 Dec 2006 07:05:26 -0800 (PST)

> these near-monopolies will make government controls more effective.

Current distribution of IP addresses depends on "big telcos". Current architecture
works sort of:
IETF: Here is the Internet that let you communicate via a pre-determined hierarchy
EU: What do I need?
IETF: You need addresses and connection.
EU: Where do I get them?
IETF: You get them from your provider usually for a fee.
EU: Can I change my provider and keep addresses?
IETF: No!
PROVIDER: I love that!
EU: I hate it! But I need the Internet...

To mitigate the above here are Principles of a Flexible Architecture:
1. Communicating entities = applications
2. Application name = any
3. Application address = Node's name
4. Node's name = unique, e.g. MAC
5. Node's address = Interface name
6. Interface name = unique IPvN
7. Interface address = IPvN+ASN
8. ASN hierarchy = Local, Metro, Regional, NE Hemisphere, NW Hemisphere, SE
Hemisphere, SW Hemisphere, Planet, Star, Galaxy, Cluster
9. Local, Metro, Regional ASN could be mobile, ASN above Regional must have static
geophysical coordinates
10. Interface hierarchy = interface, node, subnet, network

Thank you,

Peter

 
____________________________________________________________________________________
Yahoo! Music Unlimited
Access over 1 million songs.
http://music.yahoo.com/unlimited

---

From: John Day <[email-masked]>
Date: Mon, 4 Dec 2006 10:27:07 -0500

>EU: I hate it! But I need the Internet...

This was a conscious choice by the IETF and one of the ground rules 
for the IPng.  There were proposals at the time to avoid this.  But 
the experts know best.

>4. Node's name = unique, e.g. MAC

Interface name.  Not node name.

MAC and IP address are the same thing.  Why both?

>5. Node's address = Interface name

This is the root of the problem.

>7. Interface address = IPvN+ASN

Which protocol carries this?

>Hemisphere, SW Hemisphere, Planet, Star, Galaxy, Cluster

Just a fun nit:  4 *hemi*spheres!  ;-)

>10. Interface hierarchy = interface, node, subnet, network

All in all, this seems to be the status quo.  As near as I can tell a 
node and an interface are synonyms.

Take care,
John

---

From: Peter Sherbin <[email-masked]>
Date: Mon, 4 Dec 2006 08:14:07 -0800 (PST)

> MAC and IP address are the same thing.  Why both?

IEEE designed MAC identifies a node. IETF designed IP address identifies an
interface. One node may have several interfaces. 

> Which protocol carries this?

A new one that needs to be designed.

> Just a fun nit:  4 *hemi*spheres!  ;-)

A quartersphere indeed, thank you :) 

> node and an interface are synonyms.

A big enough node carries several interfaces. Each interface is node's address that
could be used in different communication contexts. Network and ASN are two
independent worlds that intersect only when the packet needs to travel between AS.

Thanks,

Peter

---

From: Fred Baker <[email-masked]>
Date: Mon, 4 Dec 2006 08:31:41 -0800

On Dec 4, 2006, at 8:14 AM, Peter Sherbin wrote:

> IEEE designed MAC identifies a node.

actually, no. The IEEE-defined MAC Address is stored in a rom on the  
interface card and is intended to be applied to the interface. The  
system can of course do anything it wants, but generally a MAC  
Address identifies an interface.

---

From: Fred Baker <[email-masked]>
Date: Mon, 4 Dec 2006 08:32:59 -0800

On Dec 3, 2006, at 6:38 PM, Peter Sherbin wrote:
> What if nodes are protected so an outsider can not make them zombie?

That's the theory behind a firewall. The problem is, so I'm told,  
that some 80% of attacks are from behind the firewall, very possibly  
from a system directly connected electrically to the target of the  
attack. At the end of the day, the system receiving the potential  
attack is responsible for its own defense.

---

From: "william(at)elan.net" <[email-masked]>
Date: Mon, 4 Dec 2006 09:46:46 -0800 (PST)

On Mon, 4 Dec 2006, Fred Baker wrote:

> interface card and is intended to be applied to the interface.
> The system can of course do anything it wants, but generally a MAC 

Could you define what "an interface" is?
[it seems to have different meaning depending on who is talking here...]

BTW - In my view MAC address is unique id of the network card itself
designed to avoid collisions when multiple cards are put on the same
L2 network segment and its made globally unique so that people did not
have to program the cards every time they are used. L2 routing on the
other hand need not be based on MAC address although traditionally it
has been [nor does this routing even need to be globally similar -
it is only necessary that it work locally].

Now we can try to apply parallels to L3 ip routing for current or future 
work on IPv? protocol(s). However one thing to note is that it may not 
necessarily help in solving problem with increase in global routing table.

But I actually said before (like many others) that it would be great
if we could do everything based entirely ASN routing - that does reduce 
the global routing table a bit, but unfortunately it does not actually 
reduce the proportions for long-term - i.e. if we just cut table size
and its increase by 1/2 (or some other linear fraction), does it solve 
the problem when the increase seems to be defined by exponential curve?
[its probably not exponential, but it certainly does not seem linear...]

But it might help in shorter term (10-20 years) and should be considered 
as it maybe enough until we have better techniques and data from new 
research efforts (such as GENI which is supposed to allow for global 
routing research, it has not even started in serious way yet and probably 
10+ years before results from it find it way to to IETF engineering).

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: John Day <[email-masked]>
Date: Mon, 4 Dec 2006 12:51:43 -0500

>interface. One node may have several interfaces.

See Fred Baker's comment.  I agree with Fred. It has always been an interface.

>A new one that needs to be designed.

Interesting.

>A quartersphere indeed, thank you :)

I believe they would be quadraspheres!  ;-)

>independent worlds that intersect only when the packet needs to 

You keep saying that a node can have several interfaces and I agree. 
But when you then do is quite the opposite.  ASNs were a kludge. 
Give some thought to what they should have been.

I think you are converging.  Take another look at 1498.

Take care,
John

---

From: Peter Sherbin <[email-masked]>
Date: Mon, 4 Dec 2006 10:39:10 -0800 (PST)

> but generally a MAC Address identifies an interface.

What was the reason/need then in creating IP addresses?

Thanks,
Peter

 
____________________________________________________________________________________
Cheap talk?
Check out Yahoo! Messenger's low PC-to-Phone call rates.
http://voice.yahoo.com

---

From: Peter Sherbin <[email-masked]>
Date: Mon, 4 Dec 2006 10:54:09 -0800 (PST)

> attack is responsible for its own defense.

This is fine. All I need is a system that is protectable with a reasonable amount of
effort from/by an average non-programmer who just wants to run an application. 

Thanks,

Peter

---

From: Peter Sherbin <[email-masked]>
Date: Mon, 4 Dec 2006 11:03:48 -0800 (PST)

> I think you are converging.

What is your idea of a scalable architecture? Could you please define it in one or
two sentences?

Thanks,

Peter

 
____________________________________________________________________________________
Have a burning question?  
Go to www.Answers.yahoo.com and get answers from real people who know.

---

From: John Day <[email-masked]>
Date: Mon, 4 Dec 2006 14:03:47 -0500

>What was the reason/need then in creating IP addresses?

Interesting question, isn't it?

Well, MAC addresses are flat and IP addresses weren't suppose to be 
but really were until CIDR came along 15 years later.  IP addresses 
were suppose to be the addresses of "gateways" which turned out to be 
routers.  So they went back to naming switch interfaces. MAC 
addresses were in IEEE and IP addresses were in the DoD.  It has 
always been odd that a data link address had more scope than a 
network layer address. Or as I said before, that an *Internet* 
address named a *subnet* point of attachment.

But we really don't worry about that as long as the implementation 
works, right?  If the implementation works, it must be right.

Apparently very few people had enough OS experience to realize that 
we had made a mistake with ARPANet host addresses until Saltzer's 
paper came along, even though we had been talking about since the 
Tinker AFB IMP in '72.

(Okay, yes, I am being a little facetious but only a little.  And you 
do have to allow for the fact that we were figuring all this out as 
we went.  We didn't have a complete theory of networking that we were 
building to.  Sometimes what we thought the relation between things 
was when we first created them turned out not to be quite what we 
thought it was a few years later.)

We were going to fix it with IPng, but by then everyone was so 
attached to naming the interface and there were probably only 25 
people who knew why we shouldn't, and of course to air all the dirty 
laundry CLNP did distinguish point of attachments and node addresses. 
So that was one more reason not to.

Gosh, I don't know maybe we don't need IP and we just need this new 
protocol you were talking about.  ;-)

Take care,
John

---

From: David Barak <[email-masked]>
Date: Mon, 4 Dec 2006 11:13:07 -0800 (PST)

> What was the reason/need then in creating IP

Logical addressing - MAC is to provide a unique
physical hardware address, IP is to provide
aggregatible logical groups of addresses, and to hide
the MAC information from distant subnets (for which it
is not relevant).

-David

David Barak
Need Geek Rock?  Try The Franchise: 
http://www.listentothefranchise.com

---

From: Fred Baker <[email-masked]>
Date: Mon, 4 Dec 2006 11:27:13 -0800

> What was the reason/need then in creating IP addresses?

Tell me this: what kinds of interfaces do we use in the Internet? Is  
every single interface an IEEE 802.3 interface? What other kinds of  
interfaces are supported?

---

From: Peter Sherbin <[email-masked]>
Date: Mon, 4 Dec 2006 12:10:29 -0800 (PST)

> interfaces are supported?

802.5, 802.6, 802.11? For the Internet does it matter what goes on at Layer 2?
A situation with 1+ interfaces per node is common e.g. router with interface 1
facing LAN and interface 2 facing WAN. Or a PC with a LAN card and a wireless LAN
card. Interfaces are different when the node is the same. Outside applications may
use interfaces 1 and 2 to talk to different applications within same node. Node
seems just a housing for applications. Does it make a concept of a node irrelevant
to networking?

Thanks,

Peter

---

From: Fred Baker <[email-masked]>
Date: Mon, 4 Dec 2006 12:22:04 -0800

> 802.5, 802.6, 802.11? For the Internet does it matter what goes on  

no, it doesn't, because we have an IP address rather than a layer 2  
address. To answer your question, that's specifically *why* we have  
an IP address. We need something that is *not* the lower layer  
address that we can use regardless of the type of lower layer in use.

---

From: "Bound, Jim" <[email-masked]>
Date: Thu, 7 Dec 2006 07:05:26 -0500

> Interesting question, isn't it?

IEEE was not working on the Internet and MAC addresses were owned by
that organization. THey also identified the NIC which is different than
layer 3 in a model and definitely for implementation, and I agree with
what was done completely.  The trick is to adjust it now.  We also
thought 32bits were enough.  I also agree with the IP subnet model.

> 
> But we really don't worry about that as long as the 
> implementation works, right?  If the implementation works, it 
> must be right.

Once a standard is accepted widely in the market by paying customers
that is exactly what happens yes.

> 
> Apparently very few people had enough OS experience to 
> realize that we had made a mistake with ARPANet host 
> addresses until Saltzer's paper came along, even though we 
> had been talking about since the Tinker AFB IMP in '72.

I still do not think it was a mistake it was required at the time the
proof is the success of the Internet today.  Billions of dollars flowing
and users all in cyberspace that is a good thing.  Dreams of
architecture are nice but reality is unless the market adopts them they
were purely an academic exercise, which is not a bad thing.

> We were going to fix it with IPng, but by then everyone was 
> so attached to naming the interface and there were probably 
> only 25 people who knew why we shouldn't, and of course to 
> air all the dirty laundry CLNP did distinguish point of 
> attachments and node addresses. 

Not quite.  We had no intention of fixing it with IPng and the resulting
consensus objective was to do as little harm to the current IPvN as
possible and all proposals had to provide a transition plan (possibly
today our term "jack-up").  

All please see RFC 1752 for the record.

CLNP never worked ever as widely as IP, and I agree the IP layer should
be connectionless and what we do here for the future should remain
connectionless.  This had many and healthy debates I was integral them
as you know.

Best,
/jim

---

From: "Bound, Jim" <[email-masked]>
Date: Thu, 7 Dec 2006 07:05:51 -0500

Well stated.
/jim 

> -----Original Message-----
> From: David Barak [mailto:[email-masked]] 
> Sent: Monday, December 04, 2006 2:13 PM
> To: Peter Sherbin; [email-masked]
> Subject: Re: [arch-d] A straw man analysis of why 
> send-receive packet paradigmis unsustainable
> 
> 
> Logical addressing - MAC is to provide a unique physical 
> hardware address, IP is to provide aggregatible logical 
> groups of addresses, and to hide the MAC information from 
> distant subnets (for which it is not relevant).
> 
> -David
> 
> David Barak

---

From: "Bound, Jim" <[email-masked]>
Date: Thu, 7 Dec 2006 07:06:54 -0500

Yep WiFi, WIMAX, ATM, X.25, SDLC.........................
/jim 

> From: Fred Baker [mailto:[email-masked]] 
> Sent: Monday, December 04, 2006 2:27 PM
> To: Peter Sherbin
> Cc: Pekka Nikander; [email-masked]; John Day
> Tell me this: what kinds of interfaces do we use in the 
> Internet? Is every single interface an IEEE 802.3 interface? 
> What other kinds of interfaces are supported?
>