Re: [hybi] Multiplexing extension spec draft 03

Greg Wilkins <gregw@intalio.com> Wed, 29 February 2012 22:42 UTC

Return-Path: <gregw@intalio.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A45421E801F for <hybi@ietfa.amsl.com>; Wed, 29 Feb 2012 14:42:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.716
X-Spam-Level:
X-Spam-Status: No, score=-2.716 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CrDrSilVg+dG for <hybi@ietfa.amsl.com>; Wed, 29 Feb 2012 14:42:39 -0800 (PST)
Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id B60A021E800E for <hybi@ietf.org>; Wed, 29 Feb 2012 14:42:39 -0800 (PST)
Received: by obbeh20 with SMTP id eh20so5484092obb.31 for <hybi@ietf.org>; Wed, 29 Feb 2012 14:42:39 -0800 (PST)
Received-SPF: pass (google.com: domain of gregw@intalio.com designates 10.60.7.40 as permitted sender) client-ip=10.60.7.40;
Authentication-Results: mr.google.com; spf=pass (google.com: domain of gregw@intalio.com designates 10.60.7.40 as permitted sender) smtp.mail=gregw@intalio.com
Received: from mr.google.com ([10.60.7.40]) by 10.60.7.40 with SMTP id g8mr823400oea.69.1330555359454 (num_hops = 1); Wed, 29 Feb 2012 14:42:39 -0800 (PST)
MIME-Version: 1.0
Received: by 10.60.7.40 with SMTP id g8mr706828oea.69.1330555359323; Wed, 29 Feb 2012 14:42:39 -0800 (PST)
Received: by 10.60.55.166 with HTTP; Wed, 29 Feb 2012 14:42:39 -0800 (PST)
In-Reply-To: <CABLsOLD3M8kUpMWpX6nNV2AYEg95XFznt=GRJeGiYRGTakfD-Q@mail.gmail.com>
References: <CAH9hSJb1ewPO3EBgD78anD+=4XouToGR4X7C1wvWqonc2nYB6g@mail.gmail.com> <CAH_y2NFrvg-cjGAT-AsGS0B6+UvAjpvhhzwYa7jBQwQ+pVFOog@mail.gmail.com> <CAH9hSJa2yhyf_OXzgG5esvA3KaOZr5vO+=iD+Wm+hLj9Y9z1cg@mail.gmail.com> <CABLsOLBu9y-8i2yKxTMRKwG-LyKjYyacmKRszE8fbLC0wmUtrw@mail.gmail.com> <CAH_y2NGjcO08BfB03gcDC5mNDrMbm3e814+rg_2XP_KW9QOVwA@mail.gmail.com> <CABLsOLD3M8kUpMWpX6nNV2AYEg95XFznt=GRJeGiYRGTakfD-Q@mail.gmail.com>
Date: Thu, 01 Mar 2012 09:42:39 +1100
Message-ID: <CAH_y2NEwPghxJ01tt_gqw_UCAX4Qqxf=s=d=cypWdnZF2LOdWw@mail.gmail.com>
From: Greg Wilkins <gregw@intalio.com>
To: John Tamplin <jat@google.com>
Content-Type: multipart/alternative; boundary="e89a8fb1ef488be59d04ba220fef"
X-Gm-Message-State: ALoCoQkYecP3UTKCvL8zmq5VIjdzENKL2pXKQb46kuivT8ORn7Uw/wUneYRqA5Di4MCikRVz3O0J
Cc: hybi@ietf.org
Subject: Re: [hybi] Multiplexing extension spec draft 03
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 29 Feb 2012 22:42:40 -0000

On 1 March 2012 09:34, John Tamplin <jat@google.com> wrote:
>
> I think of a router or switch where you want to minimize the processing as
> you pass bits from an input to an output.  A WS mux intermediary is likely
> to be higher level than that, probably about the same as a load balancer so
> it doesn't necessarily apply at that level.  I can see the argument both
> ways, and I think we need to discuss the relative merits of both before
> deciding.
>

Sure - just advocating one side of it, but can live with nested if we
determine an advantage.

Note that an intermediary that is demuxing/remuxing will have little work
to do on the average data packet - it will simply need to maintain a
mapping of inbound channelId to outbound channelID and update the channel
ID in the packets as it forwards them (this may be an argument for fixed
length channelID encoding).  This like flow control wont need to be fully
implemented, as the intermediary can just pass back quotas to the source.

cheers