Subject: RE: [midcom] WG scope/deliverables

From: "Fleischman, Eric W" <[email-masked]>
Date: Wed, 31 Jan 2001 16:50:42 -0800

Would such a rendezvous service work if their were NATs between each of the participants and the service itself (regardless of whether it is hosted on a NAT or not)? If so, wouldn't such a solution alter peer-to-peer to become a hub-and-spoke service requiring ISP mediation in the Internet case as opposed to peer-to-peer?

-----Original Message-----
From: David T. Perkins [mailto:[email-masked]]
Sent: Wednesday, January 31, 2001 3:41 PM
To: Michael Richardson; [email-masked]
Subject: Re: [midcom] WG scope/deliverables 

HI,

On the list below, I believe that peer-to-peer applications like
napster can work in a NAT world. All you need is a registration
and rendezvous service to put the two peers together. This can
be part of the box that also provides the NAT service. 

At 05:54 PM 1/31/2001 -0500, Michael Richardson wrote:

>  NAT's work for web surfing. No dispute here.
>
>  NAT's make the Internet into TV.
>
>  NAT's suck for napster-type applications.
>  It was napster like (e.g. peer-to-peer) things that made the Internet
>popular. Based upon some data on "web ready cell phones" being used primarily
>to send text messages (e.g. do "peer-to-peer" type things), I'd say that
>the love for NATs will very soon decline.
>
>   :!mcr!:            |  Solidum Systems Corporation, http://www.solidum.com
>   Michael Richardson 

Regards,
/david t. perkins

---

From: [email-masked] (Sean Doran)
Date: Thu, 1 Feb 2001 05:34:31 +0100 (CET)

Bill Manning writes:

|  and tosses it w/o any abilitiy to notify the originating 
|  party. 

Why is it necessary that there be an inability to notify the
originating party?   dkerr already proved it's cheep cheep cheep
to maintain some types of state even with lots of flows per second,
and the whole point is to consider ways in which midcom boxes can
do speed-smarts trade-offs to help avoid such "inabilities" in
the first place.  No?

"Hm, now let's see, a router on the 'outside' just sent back this
odd ICMP message.  Whatever should I do with it?" may not be so
difficult to answer in a manner different than "ignore it, and hope
the sender up eventually stops whatever it's doing to trigger the
error message".

Translating & Mapping Gateways may be "tricky" enough to scare some
people, but this is kindergarten compared to this very issue in MPLS...

	Sean.