[e2e] About the primitives and their value

David P. Reed dpreed at reed.com
Wed Aug 9 06:31:30 PDT 2006

Excellent perspective!   I think you are describing "pub-sub" 
architectures and "blackboard" architectures, which are very interesting 
alternatives that have been known for a long time.   It's relevant to 
note that the fundamental "Ethernet" (on a single segment) is indeed a 
"pub-sub" architecture of sorts - everyone sees every packet, and 
patterns are set into the low-level pattern matcher to decide which 
addresses are received.   Similarly, radios do low-level pattern 
matching with matched filters (frequency or code or time-slot pattern 
matching) on a shared blackboard.

It is at least conceptually possible to scale pub-sub architectures and 
make them interoperable at the same scale as the send-receive Internet.

What worries me is that the word "attack" has been imputed to situations 
where the target of the attack is perhaps just as responsible as the 
source for the mishaps involved (the balance depends on context - I must 
use Microsoft Outlook because my company requires it, so I must use 
Windows, so I must open my life up to vulnerabilities that are shared 
because Windows is a dominant monoculture and Microsoft doesn't really 
act on an aggressive basis to take responsibility for that monoculture's 
inherent vulnerability - perhaps because its lawyers advise it that it 
need not assume such liability).

There is no meaning to the word "attack" at the packet level, 
independent of context, just as there is no difference between an 
Israeli killing with a gun and a Hezbollah member killing with a gun 
independent of context.

The same applies to network elements carrying packets.   Lacking a view 
of the context, one cannot consider the network elements (or collections 
of them) to be facilitating or harming the parties to communications.

It's all in the context.   Netheads seem to think packets are 
self-evident in their meaning, in isolation.   That's only because 
netheads are willing to assert that they know the context.  It's the old 
idea of a "security kernel" - the error of synecdoche (metaphorically 
confusing the property of a part with properties of the whole).

Pekka Nikander wrote:
> Joe,
>> Receivers are inherently passive. To do otherwise makes them senders,
>> subject to sender rules. To plug their inputs renders them deaf, period.
> A communication network is as transparent as it is made to be.  It is 
> not necessarily like "ether", open to anyone's noise.  Agreed, the 
> original Internet used to be open for anyone to send anything to 
> anyone, and that had great _value_ for the community.  However, that 
> is only _one_ example of network design.
> If I take your "ether"-like fully transparent network, then I must 
> agree with you.  In such a network a receiver is simply passive and 
> must receive whatever any sender sends to it.
> However, put the first bridge or router there, and you have to make 
> the choice of making the box fully transparent or _not_.  You can make 
> the box a "firewall", allowing the "receiver" instruct the box of what 
> information it wants to receive, by default, and what not.  Hence, 
> once you give up your fully-open network abstraction, stating that 
> "receivers are inherently passive" becomes a mere tautology.
> I have seen network designs where "to receive" is an active 
> primitive:  the "senders" are "passively" offering data or services in 
> the network, and a "receiver" must actively ask for such a piece of 
> data or service in order to get it.  The point is that the "receiver" 
> can only send the request to the "network", not to the "sender".  
> End-to-end data transfer will only take place if there is both a 
> willing sender and a willing receiver.  That is, unless there is 
> already someone willing to provide the piece of data or service, the 
> request to receive will go nowhere.  In other words, such a network is 
> _not_ designed to support the "send this datagram to this recipient" 
> primitive, but on two primitives like: "I am willing to 
> send/offer/distribute this <whatever>" and "I want to 
> receive/get/consume this <whatever>".
> [You can argue that in the previous paragraph I've got the roles 
> wrong, that the data or service providers are "receivers" willing to 
> receive requests and the clients are "senders" sending the requests.  
> Sure, one can see the situation as such if one wills, but it doesn't 
> change the point:  the requests are only delivered if there is someone 
> actively willing to act upon them.]
> Sure, such a design would not be the Internet as we used to know it 
> nor as we know it today.  So, the question goes to the relative 
> values.  What is the relative value of network based on the "send 
> datagram to recipient" primitive vs. other types of networks, based on 
> other primitives.  Since there _are_ active boxes in the network, we 
> do have the choice of selecting the primitives.  We should not be 
> bound to the "receivers are inherently passive" thinking; while true 
> in an ether-like shared medium, such thinking is meaningless as soon 
> as you put an active box between the "sender" and the "receiver".
> Hence, IMHO, what is needed is some kind of (micro)economic 
> understanding of the different systems.  There will be at least three 
> different types of parties (senders, receivers, network elements), 
> with different interests and incentives.  The communication 
> primitives, and the protocols implementing the primitives, will 
> regulate what kind of agreements the parties will be able to negotiate 
> and will affect the relative negotiating power of the parties (cf. 
> Lessig's "Code".)  It would be great if we got the 
> "regulation-through-protocol-design" right enough.
> The only thing that is somewhat clear to me at this time is that the 
> current primitive, "send this datagram to this recipient", independent 
> of the recipient's stated willingness or unwillingness of receiving 
> it, gets the incentives wrong, i.e., results in an undesirable dynamic 
> Nash equilibrium.
> --Pekka N.

More information about the end2end-interest mailing list