[hybi] Is there a traffic jam?

Mark Lentczner <markl@lindenlab.com> Mon, 13 April 2009 18:12 UTC

Return-Path: <markl@lindenlab.com>
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CCA93A68F3 for <hybi@core3.amsl.com>; Mon, 13 Apr 2009 11:12:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.552
X-Spam-Level:
X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 dFnvKjl8jupi for <hybi@core3.amsl.com>; Mon, 13 Apr 2009 11:12:13 -0700 (PDT)
Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id 8CD4C3A68B6 for <hybi@ietf.org>; Mon, 13 Apr 2009 11:12:13 -0700 (PDT)
Received: from nil.lindenlab.com (nil.lindenlab.com [10.1.16.4]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id BDB9B3DBC06C for <hybi@ietf.org>; Mon, 13 Apr 2009 11:13:24 -0700 (PDT)
Message-Id: <03BCE29D-7AA5-4128-9F61-446E0229479A@lindenlab.com>
From: Mark Lentczner <markl@lindenlab.com>
To: hybi@ietf.org
Content-Type: text/plain; charset="US-ASCII"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Date: Mon, 13 Apr 2009 11:13:24 -0700
X-Mailer: Apple Mail (2.930.3)
Subject: [hybi] Is there a traffic jam?
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hybi>
List-Post: <mailto:hybi@ietf.org>
List-Help: <mailto:hybi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Apr 2009 18:12:14 -0000

On Apr 11, 2009, at 7:27 PM, Greg Wilkins wrote:
> BEEP!
> ...
> BEEP!
> ...
> BEEP!
> ...
> BEEP!

As pointed out, BEEP has many attributes that make is seem a likely  
candidate for this space.

But, to summarize (and add to) the points against it:

Seems that each request/response would need its own BEEP channel. This  
is because of the synchronous nature of BEEP channels(*). Channel  
creation is mid-weight, but at least requires a round-trip before the  
actual request could even begin. It might be possible to encode the  
request within the channel creation request, but there is a 4k payload  
limit for such messages.

BEEP requires both XML and MIME parsers. Note that BEEP messages are  
not equivalent to HTTP messages.  BEEP has no address (URL) or method  
for the messages, and the headers of BEEP are MIME, whereas the  
headers of HTTP are not. One could imagine using the message/http MIME  
type to an HTTP message as the payload within a BEEP message. But then  
you'd need XML, MIME and HTTP parsers... This personally doesn't  
bother me, but it is getting rather heavyweight for something small.

There is no addressability in BEEP for channels or messages. I see two  
ways two add one to a profile: 1) Add the address (and perhaps method)  
as fields in the initialization message on channel create. This would  
require a new channel for every request. 2) Encode the address in each  
message (see above for using message/http)

Some unclear aspects:

The overhead of BEEP seems like it would greater, though I admit I  
haven't calculated it. I doubt it would be outrageous.

I don't know enough to know if flow control internally would be  
needed. If so, BEEP has it.  If not, it is a little scary to implement!

I think one could shoe-horn into BEEP via Upgrade with a little  
careful draftsmanship. Defining a fall-back mechanism might be  
considerably more difficult, as BEEP is considerably more general.

Lastly, we did consider BEEP about a year ago. The biggest thing  
against it was that libraries didn't seem widely available. I realize  
there is a chicken and egg thing here, but since BEEP didn't appear to  
really hit our use case dead on, we didn't feel like we'd be the best  
candidates to encourage its library development.

	- Mark

(*) There is a current draft addressing this: http://tools.ietf.org/html/draft-thomson-beep-async-02


Mark Lentczner
Sr. Systems Architect
Technology Integration
Linden Lab

markl@lindenlab.com

Zero Linden
zero.linden@secondlife.com