Re: [grobj] Referral definition and its purpose?

bo zhou <zhouboyj@gmail.com> Thu, 27 May 2010 07:40 UTC

Return-Path: <zhouboyj@gmail.com>
X-Original-To: grobj@core3.amsl.com
Delivered-To: grobj@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21B7E3A69D1 for <grobj@core3.amsl.com>; Thu, 27 May 2010 00:40:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.653
X-Spam-Level:
X-Spam-Status: No, score=0.653 tagged_above=-999 required=5 tests=[AWL=-0.838, BAYES_20=-0.74, HTML_MESSAGE=0.001, J_CHICKENPOX_61=0.6, SARE_PROLOSTOCK_SYM3=1.63]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1vKVaCk9L3q9 for <grobj@core3.amsl.com>; Thu, 27 May 2010 00:40:12 -0700 (PDT)
Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com [209.85.221.181]) by core3.amsl.com (Postfix) with ESMTP id C3E1D3A6897 for <grobj@ietf.org>; Thu, 27 May 2010 00:40:11 -0700 (PDT)
Received: by qyk11 with SMTP id 11so10990533qyk.13 for <grobj@ietf.org>; Thu, 27 May 2010 00:40:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=53zLGVJqK6eOIILCOTp62hLgZKh2yz4Tyn65SuG8QmI=; b=CgWQVG4Je0fzB5NCO9odeygCvTS6GKUoZisL/J3jikqqKFr193YqGxMrNk9K9qNGji eUc/0xw9o17rr8x0/QM7fFKyOckUCjtBm0iZ3wyrXkZMYuuIBYdY2IgKYLMdUnGF8z22 E7XEPmRd9mKeIK5yzm6GdimXkU0z30fwNd7A8=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=cUDOJcgV0n1EtP4rQsVIwUyBigiSSbYCZcOAt+mCYAsKvRAshQ5w5uzJ1PiBgKQD4B QQuYzoQSVvAM66SYZEIhG13427Stvgj24S2C+XvR3j1nPKArXzD2xszC/eLqwqpaPDof wN110g5pI1Ngn61MYF8M8fF8iMWPZVIvJsu0Y=
MIME-Version: 1.0
Received: by 10.224.110.11 with SMTP id l11mr5357853qap.334.1274945999758; Thu, 27 May 2010 00:39:59 -0700 (PDT)
Received: by 10.229.185.133 with HTTP; Thu, 27 May 2010 00:39:59 -0700 (PDT)
In-Reply-To: <115701cafd32$7cefc180$c4f0200a@cisco.com>
References: <004d01caf668$b33272e0$730c6f0a@china.huawei.com> <115701cafd32$7cefc180$c4f0200a@cisco.com>
Date: Thu, 27 May 2010 15:39:59 +0800
Message-ID: <AANLkTim069BFuD2MFi0P3hQv_di91f1kkp0wB7pXL4YW@mail.gmail.com>
From: bo zhou <zhouboyj@gmail.com>
To: Dan Wing <dwing@cisco.com>
Content-Type: multipart/alternative; boundary="000feaf20b096c679804878e7f8f"
Cc: grobj@ietf.org
Subject: Re: [grobj] Referral definition and its purpose?
X-BeenThere: grobj@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discuss Generic Referral Objects <grobj.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/grobj>, <mailto:grobj-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/grobj>
List-Post: <mailto:grobj@ietf.org>
List-Help: <mailto:grobj-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/grobj>, <mailto:grobj-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 May 2010 07:40:13 -0000

Hi Dan,

Some comments inline.

On Thu, May 27, 2010 at 8:21 AM, Dan Wing <dwing@cisco.com> wrote:

>
>
> > -----Original Message-----
> > From: grobj-bounces@ietf.org [mailto:grobj-bounces@ietf.org]
> > On Behalf Of Sheng Jiang
> > Sent: Tuesday, May 18, 2010 2:01 AM
> > To: grobj@ietf.org
> > Subject: [grobj] Referral definition and its purpose?
> >
> > Hi, all,
> >
> > We are now working on an referral PS draft, targeting to
> > submit end of May
> > or the beginning of June. We'd like to discuss the relevant
> > contents/topic
> > publicly in the mail list during our writing. Comments or
> > contributions are
> > more than welcome.
> >
> > The first target is to understand what is referral and its
> > purpose. There
> > may be different understanding, our goal here is to find a
> > common definition
> > for our PS draft. The following is my understanding and
> > what's in the draft
> > now.
> >
> > In abstract: The purpose of a referral is to enable a given
> > entity in a
> > multiparty Internet application to pass information to
> > another party. It
> > enables a communication initiator to aware relevant information of its
> > destination entity before launching the communication.
> >
> > In the introduction: A frequently occurring situation is that
> > one entity A
> > connected to the Internet (or to some private network using
> > the Internet
> > protocol suite) needs to inform another entity B how to reach either A
> > itself or some third-party entity C. This is known as a referral.
> >
> > Does everyone can agree on this Referral definition and its
> > purpose? Only if
> > consensus can reach here, our next discussion for referral
> > scenarios can make sense.
>
> The definition of referral should be tightened up slightly
> that the parties are exchanging the information via one
> channel (e.g., SIP signaling) but want to communicate (as)
> directly (as possible) with each other *not* using that
> channel.  I often get asked "if they can communicate referral
> information with each other, why don't they just use that
> communication channel for everything else?".
>
[bo]The path which they communicate referral information maybe not the
"best" path for the information they really want to communicate. Many
today's peer-to-peer applications are working like this way, one reason
could be avoiding monitor from operator or others and protect privacy.


>
> In SIP, this is often called the "SIP trapezoid".
> We can generalize this a bit resulting in the following
> figure:
>
>   +-----------+       +-----------+
>   |application|       |application|
>   | server(s) +.......+ server(s )|
>   +---+-------+       +-------+---+
>      /                         \
>     |                           |
>     |   referral information    |
>     |                           |
>     |                           |
>   +-+-+                       +-+-+
>   | A +-----------------------+ B |
>   +---+ direct communication  +---+
>
> The application server(s) might be one single server, a distributed hash
> table, two servers, or any sort of combination.  The referral data is
> carried
> on bewtween A and B on the top, through those servers.  A and B are trying
> to
> communicate directly with one another, using the communication line at the
> bottom.
>
> A simplier model which is good to think about is a simple protocol which
> collapses the model above, such as FTP.  FTP follows the same model as
> above,
> except the 'application server' is the FTP server and FTP control channel
> (TCP/21) is what carries the referral (PASV, EPSV, PORT, EPRT).  TFTP is
> another example of a collapsed model.
>
>   +-+-+                            +-+-+
>   |   |   FTP control connection   |   |
>   |   |   (referral information)   |   |
>   |   +............................+   |
>   |   |                            |   |
>   | A |                            | B |
>   |   |    FTP data connection     |   |
>   |   +----------------------------+   |
>   |   |                            |   |
>   +---+                            +---+
>
> -d
>
>
> > Best regards,
> >
> > Sheng
> >
> > _______________________________________________
> > grobj mailing list
> > grobj@ietf.org
> > https://www.ietf.org/mailman/listinfo/grobj
>
> _______________________________________________
> grobj mailing list
> grobj@ietf.org
> https://www.ietf.org/mailman/listinfo/grobj
>



-- 
Regards,

Bo Zhou
China Mobile