Subject: [P2PSIP] Fw: I-D Action:draft-bryan-p2psip-app-scenarios-00.txt

From: Spencer Dawkins <[email-masked]>
Date: Tue, 06 Nov 2007 20:07:01 -0600

Just as a heads-up - we've redone the Use Case draft (as "application 
scenarios") and submitted the document - should be available now.

Please feel free to express opinions (and outrage - flaming torches and 
pitchforks will work better in cyberspace than in damp Vancouver :-)

Thanks,

Spencer

>A New Internet-Draft is available from the on-line Internet-Drafts 
>directories.
>
> Title           : Application Scenarios for Peer-to-Peer Session 
> Initiation Protocol (P2PSIP)
> Author(s)       : D. Bryan, et al.
> Filename        : draft-bryan-p2psip-app-scenarios-00.txt
> Pages           : 19
> Date            : 2007-11-06
>
> This document attempts to identify and classify application scenarios
> of P2P based SIP.  It does not attempt to exhaustively enumerate
> these scenarios, and is focused exclusively on scenarios related to
> real-time IP communication.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-bryan-p2psip-app-scenarios-00.txt
>
> To remove yourself from the I-D Announcement list, send a message to
> [email-masked] with the word unsubscribe in the body of
> the message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
>
> Internet-Drafts are also available by anonymous FTP. Login with the
> username "anonymous" and a password of your e-mail address. After
> logging in, type "cd internet-drafts" and then
> "get draft-bryan-p2psip-app-scenarios-00.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
> [email-masked].
> In the body type:
> "FILE /internet-drafts/draft-bryan-p2psip-app-scenarios-00.txt".
>
> NOTE:   The mail server at ietf.org can return the document in
> MIME-encoded form by using the "mpack" utility.  To use this
> feature, insert the command "ENCODING mime" before the "FILE"
> command.  To decode the response(s), you will need "munpack" or
> a MIME-compliant mail reader.  Different MIME-compliant mail readers
> exhibit different behavior, especially when dealing with
> "multipart" MIME messages (i.e. documents which have been split
> up into multiple messages), so check your local documentation on
> how to manipulate these messages.
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>

--------------------------------------------------------------------------------

> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/i-d-announce
> 

_______________________________________________
P2PSIP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/p2psip

---

From: JiangXingFeng <[email-masked]>
Date: Mon, 26 Nov 2007 16:56:56 +0800

Hi, Spencer:

Thanks for the analysis work of application scenarios from you guys.

Application scenarios vary tremendously in its attributes you have
classified. Do you want our resulting protocol support all or most of the
application scenarios? 

IMHO, the more valuable work is to find the commonalities among them and try
to get some conclusions like that: whether all or most of peers are behind
NAT; whether centralized server could be available in every application
scenarios, what is the suitable churn rate for the various applications,
etc. 

If we could reach consensus on these issues, we could make it as a input to
the design of the peer and/or client protocol.

Regards!
--
Jiang XingFeng

> -----Original Message-----
> From: Spencer Dawkins [mailto:[email-masked]]
> Sent: Wednesday, November 07, 2007 10:07 AM
> To: P2PSIP Mailing List
> Subject: [P2PSIP] Fw: I-D Action:draft-bryan-p2psip-app-scenarios-00.txt
> 
> > implementation to automatically retrieve the ASCII version of the
----------------------------------------------------------------------------
----

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 26 Nov 2007 08:28:00 -0500

I'm sorry, but none of these questions are likely to be answerable  
with any degree of specificity, so delaying work or hoping for answers  
is not too helpful. Like in many other circumstances, we have to  
design robust and extensible protocols that recognize that protocol  
designers almost always fail to predict the range of use for their  
creations.

We already know
- that some fraction of peers may be behind NATs, but there's no way  
to predict whether that's 0.1% or 100% and what kind of NATs
- that we may or may not have central servers
- that churn rates may be very high or close to zero

Henning

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 26 Nov 2007 09:13:23 -0800

On Nov 26, 2007, at 5:28 AM, Henning Schulzrinne wrote:

> We already know
> - that some fraction of peers may be behind NATs, but there's no  
> way to predict whether that's 0.1% or 100% and what kind of NATs

I think what I am seeing is more or less the same as Henning.

Cullen <with my individual contributor hat on>

---

From: JiangXingFeng <[email-masked]>
Date: Tue, 27 Nov 2007 10:56:03 +0800

Hi, Henning:

Does it mean that a resulting peer protocol is an all-weather one? Does it
mean that we should work out various building blocks and it is up to the
operator to choose what kinds of combination of these building blocks which
will work well in the given scenario?

Regards!
--
Jiang XingFeng

> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Monday, November 26, 2007 9:28 PM
> To: JiangXingFeng
> Cc: 'Spencer Dawkins'; 'P2PSIP Mailing List'
> Subject: Re: [P2PSIP] Fw: I-D
Action:draft-bryan-p2psip-app-scenarios-00.txt

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 26 Nov 2007 22:31:23 -0500

Yes, in the sense that all Internet protocols have to operate in all  
kinds of "weather". Ideally, they'll be able to make use of "sunshine"  
to perform better.

However, I wouldn't use the term "operator" - there may not be an  
operator in the traditional sense. Also, I would hope that smart  
implementations are adaptive, rather than requiring manual  
configuration. We don't want a system that needs a dozen parameters to  
be tweaked by a user or "operator".

---

From: JiangXingFeng <[email-masked]>
Date: Tue, 27 Nov 2007 11:39:42 +0800

> kinds of "weather". Ideally, they'll be able to make use of "sunshine"

One further question: We try to make each building block work well in all
kinds of weather as much as possible. But it may be harder to achieve this
goal. Does it mean that we could develop some complementary building blocks
each of which may perform better in different scenarios? 

> be tweaked by a user or "operator".
Right. One of the advantage of the P2P system is self-organization. What I
want to say here: it is up to the implementers to choose a given combination
of building blocks to be used in a given scenarios.

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 26 Nov 2007 22:53:38 -0500

> each of which may perform better in different scenarios?

I don't know how one can answer such a question in general. More  
building blocks can be useful, but you pay in terms of overall system  
complexity and interoperability problems, since there are now more  
likely to be many more combinations of feature sets to contend with.

Henning