Subject: [p2p-sip] Revised Draft Charter for P2PSIP

From: RADHIKA.R.ROY at saic.com (Roy, Radhika R.)
Date: Thu, 21 Sep 2006 15:35:58 -0400

M:
 
The ONLY reason is this: It is an unsolvable problem.
 
All IETF WGs have been trying, and have been failing successully!!!
 
The word UNFORTUNATE is there to discourage for spending too much time for
this technically nonsense problem. That is, p2p-SIP may not be even p2p-SIP
WG anymore at the end of the solution - all fear is this: It might make
p2p-SIP NAT crossing solution as non-p2p-SIP NAT crossing protocol. 
 
I hope I would be  be wrong! Who knows what is coming out of by SIP,
SIPPING, NSIS, IPSEC, DIAMETER, and others almost after 6-10 years!  Now,
MMUSIC has turned their attention to ICE-xxxxxx versions.
 
Let us wait for ICE (versions # infinite) to see whether it could be used
for p2p-SP!!! How about this?
 
RRR

  _____  

From: Michael Slavitch [mailto:slavitch at gmail.com]
Sent: Thu 9/21/2006 2:32 PM
To: Roy, Radhika R.
Cc: David A. Bryan; p2p-sip at cs.columbia.edu
Subject: Re: [p2p-sip] Revised Draft Charter for P2PSIP

The "NAT is evil" argument is a matter of faith and belief, a moral
statement that has no place in a protocol working group charter.   
Engineering solutions emerge from the judicious study of discernible
reality. NAT exists, therefore it must be dealt with. Period.
>From an engineering standpoint, it creates problems that need to be solved
with solutions that reflect the facts on the ground.
 
The P2PSIP Working Group must be part of the reality-based community, rather
than part of an ideological community, therefore the working group charter
must distinguish consensus external reality from ideologically created
reality if the working group is to be at all successful.  There is ample
evidence that creating one's own reality despite evidence to the contrary
results in failure. 
 
Given that, the word "unfortunate" has no place in an engineering document.
By definition it must be struck. 
 
Regards,
 
M

 
On 9/21/06, Roy, Radhika R. RADHIKA.R.ROY at saic.com
<mailto:RADHIKA.R.ROY at saic.com>  wrote:

Mike and all:

I am commenting on NATs.

>From IETF point of view, the use of NATs as it is done these days is 
"unfortunate."

Let us see what had been the history of NAT standardization in the IETF? 

The IETF charter had been to help the "scarcity" of IPv4 addresses (before
IPv6 even been proposed). It was hoped that, by the time IPv6 is 
standardized, there is will be no more requirements of NATs to provide more
address spaces.

Now, people have forgot the original usage of NATs. People are using NATs as
a part of "security" for hiding the configurations behind NATs. It is 
completely an "illusion" to be happy to know that people are "secured" by
using NATs. It is still going on in a mass scale throughout the world, and
no one knows when this will be stopped.

Should the purpose of the NAT standardization be "SECURITY" or "TOPOLOGY
HIDING in the name of security," IETF would NEVER standardized NATs for
these purposes. The rest is history!!!

So, it is UNFORTUNATE so far the MIS-use of NATs is concerned because NATs
are not needed anymore due to shortage of IPv4 addresses or NATs cannot
provide security through hiding configurations.

Therefore, the draft charter is CORRECT in this context to use the word 
"UNFORTUNATE."

Best regards,
Radhika

---

From: slavitch at gmail.com (Michael Slavitch)
Date: Fri, 22 Sep 2006 09:45:29 -0400

It is certainly not a nonsense problem outside of some rare circles as
nearly all consumer and business networks fall behind NATs. Without NAT
crossing P2PSIP is useless. I agree that in a deterministic system a perfect
solution is required.

That is why deterministic systems are always so brittle. The world is a
messy fractal place.

By definition P2PSIP will not be deterministic so a perfect solution is not
only unnecessary, it is not desirable if the cost of complexity exceeds the
apparent benefit.

The solutions that exist are statistical and fractal, not perfect and
deterministic. Skype is living proof of a broadly used implementation that
shows that the problem is solved in a matter that meets the requirements for
P2P systems.  Since all P2P systems share a common fractal nature a fractal
solution is perfectly suited to the domain.

For all the criticism of ICE, and I've done my fair share, it is getting
simple enough to implement from the draft to be expressed in BNF notation.
It is now fairly easy to build ICE into a finite state machine, as ICE now
describes a completion mechanism where the protocol is complete.
That encourages  interoperability from the start.

Any inadequacies that remain result from the fact that client-server SIP is
the only official user of the protocol.  These are minor issues that can
only be addressed by MMUSIC once we have a P2PSIP WG that can request
changes.  That is a diplomatic problem, not an engineering problem, if the
underlying protocol in ICE can meet base P2PSIP requirements.  That is why
WG chairs are chosen carefully.

Regarding unsolved problems:  If the underlying system is fractal then a
statistical solution with a high probability of success meets the
requirements for the system. This is true for all fractal systems.   The
only issue is determining the probability of success of different solutions
and either choosing one that meets the circumstances at hand or
modifying another to make it an appropriate choice.

I further argue that the fractal nature of ICE is far more suited to the
fractal P2P world than it is to the assumed-deterministic IMS/CS model. It
may be not ever be solved perfectly enough for IMS but for self-organizing
P2PSIP it won't have to be perfect as the nature of a self-organizing
systems is to work around their own shortcomings.   P2PSIP will be rugged
enough such that perfect solutions are not needed.  If the other working
groups are failing it may be because the systems they are building towards
may be broken and brittle and not rugged enough to tolerate statistical
solutions. Given the talent at hand that will certainly not be the case with
P2PSIP.

Regards

M

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060922/0693a998/attachment.html

---

From: hsinnrei at adobe.com (Henry Sinnreich)
Date: Fri, 22 Sep 2006 07:13:16 -0700

This may not fit into the charter discussion, but joining Michael
Slavitch, I would be interested if any or what modifications ICE would
be required for P2P systems, where most peers reside behind a NAT.

Any opinions? Jonathan?

Thanks, Henry

________________________________

From: p2p-sip-bounces at cs.columbia.edu
[mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Michael Slavitch
Sent: Friday, September 22, 2006 9:45 AM
To: Roy, Radhika R.
Cc: p2p-sip at cs.columbia.edu; David A. Bryan
Subject: Re: [p2p-sip] Revised Draft Charter for P2PSIP

It is certainly not a nonsense problem outside of some rare circles as
nearly all consumer and business networks fall behind NATs. Without NAT
crossing P2PSIP is useless. I agree that in a deterministic system a
perfect solution is required. 

By definition P2PSIP will not be deterministic so a perfect solution is
not only unnecessary, it is not desirable if the cost of complexity
exceeds the apparent benefit.

The solutions that exist are statistical and fractal, not perfect and
deterministic. Skype is living proof of a broadly used implementation
that shows that the problem is solved in a matter that meets the
requirements for P2P systems.  Since all P2P systems share a common
fractal nature a fractal solution is perfectly suited to the domain.  

For all the criticism of ICE, and I've done my fair share, it is getting
simple enough to implement from the draft to be expressed in BNF
notation. It is now fairly easy to build ICE into a finite state
machine, as ICE now describes a completion mechanism where the protocol
is complete. That encourages  interoperability from the start.  

Any inadequacies that remain result from the fact that client-server SIP
is the only official user of the protocol.  These are minor issues that
can only be addressed by MMUSIC once we have a P2PSIP WG that can
request changes.  That is a diplomatic problem, not an engineering
problem, if the underlying protocol in ICE can meet base P2PSIP
requirements.  That is why WG chairs are chosen carefully. 

Regarding unsolved problems:  If the underlying system is fractal then a
statistical solution with a high probability of success meets the
requirements for the system. This is true for all fractal systems.   The
only issue is determining the probability of success of different
solutions and either choosing one that meets the circumstances at hand
or modifying another to make it an appropriate choice.  

I further argue that the fractal nature of ICE is far more suited to the
fractal P2P world than it is to the assumed-deterministic IMS/CS model.
It may be not ever be solved perfectly enough for IMS but for
self-organizing P2PSIP it won't have to be perfect as the nature of a
self-organizing systems is to work around their own shortcomings.
P2PSIP will be rugged enough such that perfect solutions are not needed.
If the other working groups are failing it may be because the systems
they are building towards may be broken and brittle and not rugged
enough to tolerate statistical solutions. Given the talent at hand that
will certainly not be the case with P2PSIP. 

Regards

M

M:

The word UNFORTUNATE is there to discourage for spending too much time
for
this technically nonsense problem. That is, p2p-SIP may not be even
p2p-SIP
WG anymore at the end of the solution - all fear is this: It might make 
p2p-SIP NAT crossing solution as non-p2p-SIP NAT crossing protocol.

I hope I would be  be wrong! Who knows what is coming out of by SIP,
SIPPING, NSIS, IPSEC, DIAMETER, and others almost after 6-10 years!
Now, 
MMUSIC has turned their attention to ICE-xxxxxx versions.

Let us wait for ICE (versions # infinite) to see whether it could be
used
for p2p-SP!!! How about this?

RRR

_____

From: Michael Slavitch [mailto: slavitch at gmail.com]
Sent: Thu 9/21/2006 2:32 PM
To: Roy, Radhika R.
Cc: David A. Bryan; p2p-sip at cs.columbia.edu
Subject: Re: [p2p-sip] Revised Draft Charter for P2PSIP 

The P2PSIP Working Group must be part of the reality-based community,
rather 
than part of an ideological community, therefore the working group
charter
must distinguish consensus external reality from ideologically created
reality if the working group is to be at all successful.  There is ample

evidence that creating one's own reality despite evidence to the
contrary
results in failure.

Given that, the word "unfortunate" has no place in an engineering
document.
By definition it must be struck. 

Regards,

M

Mike and all:

I am commenting on NATs.

"unfortunate."

The IETF charter had been to help the "scarcity" of IPv4 addresses
(before
IPv6 even been proposed). It was hoped that, by the time IPv6 is
standardized, there is will be no more requirements of NATs to provide
more 
address spaces.

Now, people have forgot the original usage of NATs. People are using
NATs as
a part of "security" for hiding the configurations behind NATs. It is
completely an "illusion" to be happy to know that people are "secured"
by 
using NATs. It is still going on in a mass scale throughout the world,
and
no one knows when this will be stopped.

So, it is UNFORTUNATE so far the MIS-use of NATs is concerned because
NATs
are not needed anymore due to shortage of IPv4 addresses or NATs cannot
provide security through hiding configurations. 

Best regards,
Radhika

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060922/78eff884/attachment-0001.html

---

From: philip_matthews at magma.ca (Philip Matthews)
Date: Fri, 22 Sep 2006 13:24:03 -0400

Henry:

Eric Cooper and I have spent quite a bit of time recently working on  
ICE to make sure it is suitable for P2PSIP systems.

Back in April, when we first looked at ICE, it worked well when one  
peer was behind a NAT and the other had a public IP address, but was  
somewhat inefficient due to duplicated checks when both endpoints  
were behind (separate) NATs. We published a draft just before the  
Montreal meeting that proposed changes to the state machine to  
eliminate that problem (draft-matthews-mmusic-ice-eliminating- 
duplicates-00), and have since collaborated with Jonathan on this  
issue so that the current version of ICE (ICE-10) handles this case  
much better.

At present, I don't believe that any changes are required to ICE-UDP  
itself to make it more suitable for P2PSIP systems. (I haven't looked  
at ICE-TCP in detail yet). The only questions now are around how one  
uses ICE in a P2PSIP network, and here at Avaya we are currently  
investigating this issue, building on our proposals in draft-matthews- 
p2psip-nats-and-overlays-00.

- Philip

On 22-Sep-06, at 10:13 , Henry Sinnreich wrote:

> Slavitch, I would be interested if any or what modifications ICE  
> would be required for P2P systems, where most peers reside behind a  
> NAT.
>
>
>
> Any opinions? Jonathan?
>
>
>
> Thanks, Henry
>
>
>
> From: p2p-sip-bounces at cs.columbia.edu [mailto:p2p-sip- 
> bounces at cs.columbia.edu] On Behalf Of Michael Slavitch
> It is certainly not a nonsense problem outside of some rare circles  
> as nearly all consumer and business networks fall behind NATs.  
> Without NAT crossing P2PSIP is useless. I agree that in a  
> deterministic system a perfect solution is required.
>
>
>
> That is why deterministic systems are always so brittle. The world  
> is a messy fractal place.
>
>
>
> By definition P2PSIP will not be deterministic so a perfect  
> solution is not only unnecessary, it is not desirable if the cost  
> of complexity exceeds the apparent benefit.
>
>
>
> The solutions that exist are statistical and fractal, not perfect  
> and deterministic. Skype is living proof of a broadly used  
> implementation that shows that the problem is solved in a matter  
> that meets the requirements for P2P systems.  Since all P2P systems  
> share a common fractal nature a fractal solution is perfectly  
> suited to the domain.
>
>
>
> For all the criticism of ICE, and I've done my fair share, it is  
> getting simple enough to implement from the draft to be expressed  
> in BNF notation. It is now fairly easy to build ICE into a finite  
> state machine, as ICE now describes a completion mechanism where  
> the protocol is complete. That encourages  interoperability from  
> the start.
>
>
>
> Any inadequacies that remain result from the fact that client- 
> server SIP is the only official user of the protocol.  These are  
> minor issues that can only be addressed by MMUSIC once we have a  
> P2PSIP WG that can request changes.  That is a diplomatic problem,  
> not an engineering problem, if the underlying protocol in ICE can  
> meet base P2PSIP requirements.  That is why WG chairs are chosen  
> carefully.
>
>
>
> Regarding unsolved problems:  If the underlying system is fractal  
> then a statistical solution with a high probability of success  
> meets the requirements for the system. This is true for all fractal  
> systems.   The only issue is determining the probability of success  
> of different solutions and either choosing one that meets the  
> circumstances at hand or modifying another to make it an  
> appropriate choice.
>
>
>
> I further argue that the fractal nature of ICE is far more suited  
> to the fractal P2P world than it is to the assumed-deterministic  
> IMS/CS model. It may be not ever be solved perfectly enough for IMS  
> but for self-organizing P2PSIP it won't have to be perfect as the  
> nature of a self-organizing systems is to work around their own  
> shortcomings.   P2PSIP will be rugged enough such that perfect  
> solutions are not needed.  If the other working groups are failing  
> it may be because the systems they are building towards may be  
> broken and brittle and not rugged enough to tolerate statistical  
> solutions. Given the talent at hand that will certainly not be the  
> case with P2PSIP.
>
>
>
> Regards
>
>
>
> M
>
>
>
>
> _______________________________________________
> p2p-sip mailing list
> p2p-sip at cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060922/4111d22f/attachment-0001.html