[e2e] new network architecture idea -

[Jon Crowcroft]

pub/sub in the original implementation by tibco et al mapped straight onto multicast 
AND had its own transport (PGM) which was a neat architecture

BUT i am not talking about simply pub-/sub - that was for illustration reasons...

at the end of th day, the receiver has some stuff they are interstd in - you buy
newspaer x, or you tune to tv or radio station y/z OR you subscribe to some 
belief....all of this is *AND should be* receiver interst based, not sender based

even email (I'm not interested in most the spam i get  - this is an indication of a major architectual error
that the cost of an activity for a pasrticipant doesnt match the need - 
and the resource expended isnt paid for by the right party)

packet swarming is a simple idea - you need to buy into some complete changes of 
ways of building net s (you dont send to an address - you percolate traffic to a repository
cloud which intersted parties may pick packets out of  - this works even for 1-1 commnication
(if you send an email to e2e but cc: me, i might see it as i probably "subscribe" to messages
with some field about me - hey, i am sufficiently egomaniacal to want to see stuff like that:)

the technoligy exiwts now to do this at a packet level, not just an application level

In missive <D5775030-CA8B-4329-A7EC-BFC1A56DD3D4 at cisco.com>, Fred Baker typed:

 >>
 >>On May 20, 2006, at 4:17 PM, Fergie wrote:
 >>
 >>> pub/sub how, exactly?
 >>
 >>I think of pub/sub as an application concept:  I have content I am  
 >>willing to share, and someone else tells me that they are interested.  
 >>In this context, I should think the receiving node would tell the  
 >>sending node that it was interested if the other guy wanted to talk.
 >>
 >>So now I wonder how this works. I walk into a meeting room and open  
 >>my laptop. It joins a wireless network, and voila! the peers and  
 >>servers I am interested in all tell me that they are publishing  
 >>something to which I might subscribe?
 >>
 >>I think this is going to require some work to describe. At the end of  
 >>the day, it is never the receiver that knows there is content out  
 >>there to receive; it is always the one who sends it who has that  
 >>knowledge.

 cheers

   jon