Re: multiplexing -- don't do it
Peter Lepeska <bizzbyster@gmail.com> Thu, 05 April 2012 16:45 UTC
Return-Path: <ietf-http-wg-request@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B59F921F86DE for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 5 Apr 2012 09:45:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.568
X-Spam-Level:
X-Spam-Status: No, score=-10.568 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
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 Ed3zLdSEoFOK for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 5 Apr 2012 09:45:40 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 3A4C321F86DF for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 5 Apr 2012 09:45:40 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.69) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1SFpnX-0006FU-B5 for ietf-http-wg-dist@listhub.w3.org; Thu, 05 Apr 2012 16:44:35 +0000
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.69) (envelope-from <bizzbyster@gmail.com>) id 1SFpnP-0006Do-2B for ietf-http-wg@listhub.w3.org; Thu, 05 Apr 2012 16:44:27 +0000
Received: from mail-wi0-f173.google.com ([209.85.212.173]) by maggie.w3.org with esmtp (Exim 4.72) (envelope-from <bizzbyster@gmail.com>) id 1SFpnL-0001S7-FL for ietf-http-wg@w3.org; Thu, 05 Apr 2012 16:44:25 +0000
Received: by wibhq7 with SMTP id hq7so1446489wib.8 for <ietf-http-wg@w3.org>; Thu, 05 Apr 2012 09:43:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gyk8ABuV2tiZWwqY/L5ju0sz5zlh9xXJjurf7o91pq0=; b=yI+c14XiVCQQgoySRI3m2x0r2JMb/DWV/Coxn2vglq+3QPv8imjm7ccaYzSAs/dGuL zSgqrrm7vfGFpTCFigDs0jOVhjKFS9HeNYzu+jMOszGJfbEMIZ1FgjkPaBXQ1JD/6+6a azl4gvfFiJSmfFACMIiQ8M6RrmmwFc7z71Pd8KDDiR+lqlwJ4i1pPecS/S/oEEV7hRrh 2qrlhHygC44Liz5ob7kY4ys2o47sNU9JRkU4fQUVr1LA9hC3GizfS2qRHh20d4VGb252 0hUpS1G80K/A3mDnXKfElyHkMRVQrcOxj2QX5B9AjK6k73cKEXqWEAVOPEgRUJzMt0ff zgxg==
MIME-Version: 1.0
Received: by 10.180.85.69 with SMTP id f5mr6343091wiz.18.1333644236266; Thu, 05 Apr 2012 09:43:56 -0700 (PDT)
Received: by 10.216.1.204 with HTTP; Thu, 5 Apr 2012 09:43:56 -0700 (PDT)
In-Reply-To: <4F7DB391.3050002@cis.udel.edu>
References: <58913.1333522938@critter.freebsd.dk> <1333544863.2147.446.camel@ds9> <CANmPAYE0LSa4_t9C663BBdnbRgAX-tXNqmjrQ0CFNTUv9Q6g=A@mail.gmail.com> <CABaLYCtVKPJP5GQqkeOHtwpHonPBBzqx0zL_xJjiNs_XrSF1Cg@mail.gmail.com> <4F7DB391.3050002@cis.udel.edu>
Date: Thu, 05 Apr 2012 12:43:56 -0400
Message-ID: <CANmPAYHD4igjazfF5ctDOyZMXbbWsAfZ_QbAYNdgCfVnt_+cxw@mail.gmail.com>
From: Peter Lepeska <bizzbyster@gmail.com>
To: leighton@cis.udel.edu
Cc: Mike Belshe <mike@belshe.com>, Patrick McManus <pmcmanus@mozilla.com>, Poul-Henning Kamp <phk@phk.freebsd.dk>, Willy Tarreau <w@1wt.eu>, "William Chan (?????????)" <willchan@chromium.org>, "Roy T. Fielding" <fielding@gbiv.com>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="f46d043bde66f59f3104bcf13ec9"
Received-SPF: pass client-ip=209.85.212.173; envelope-from=bizzbyster@gmail.com; helo=mail-wi0-f173.google.com
X-W3C-Hub-Spam-Status: No, score=-2.7
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001
X-W3C-Scan-Sig: maggie.w3.org 1SFpnL-0001S7-FL 32fe51cbed36a2e3cd4430bf9eeaea61
X-Original-To: ietf-http-wg@w3.org
Subject: Re: multiplexing -- don't do it
Archived-At: <http://www.w3.org/mid/CANmPAYHD4igjazfF5ctDOyZMXbbWsAfZ_QbAYNdgCfVnt_+cxw@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/13323
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>
Resent-Message-Id: <E1SFpnX-0006FU-B5@frink.w3.org>
Resent-Date: Thu, 05 Apr 2012 16:44:35 +0000
What's the main reason for the benefit? If it's just that SCTP is less of a good citizen in how it handles a lost packet and backs off slower than TCP then it's not something to get excited about. Have you done much analysis to explore the reason for SCTP being faster? Peter On Thu, Apr 5, 2012 at 11:00 AM, Jon Leighton <leighton@cis.udel.edu> wrote: > ** > On 04/04/2012 06:05 PM, Mike Belshe wrote: > > > > On Wed, Apr 4, 2012 at 1:58 PM, Peter Lepeska <bizzbyster@gmail.com>wrote: > >> As long as SPDY is sent over TCP, it also suffers from HOL problems, just >> not as bad as pipelining. >> >> I think SPDY (or whatever the HTTP 2.0 muxing protocol is) should >> framed in such a way that if running over a protocol like SCTP, that solves >> the HOL problems, we should be able to take advantage of it. Due to gzip >> compression of headers, even if the transport allowed me to grab messages >> out of order, I'd still have to wait for all packets prior in order to >> decode the HTTP headers. >> > > > I think people have confusion about layering on top of transport > protocols. Any time you have an app protocol that wants to take advantage > of new transport features you *MUST* change the definition of how the app > protocol is bound to the lower level transport. This absolutely applies to > HTTP and TCP/SCTP (not talking about SPDY yet). For example, RFC2616 does > *not* specify how to use HTTP over SCTP, and a whole I-D exists for that: > http://tools.ietf.org/html/draft-natarajan-http-over-sctp-01 This I-D > defines one possible binding between HTTP and SCTP, but others could exist > too. > > Why is this necessary? Well, TCP has a single, bidirectional stream. > SCTP doesn't have bi-directional streams at all, and instead only has > multiple, uni-directional streams. So, if you want to leverage the new > feature (streams) you need to define how you're going to bind onto it. > It's trivial, but doable. > > If we had SCTP, we wouldn't do MUX and SPDY. It's redundant. That's > not to say that HTTP/2.0 is worse with multiplexing, its just to say that > we wouldn't need to consider it if the transport already had it. But SCTP > is not viable today or even within the next decade. > > Google sponsored a project at the Univ of Delaware where they > investigated SPDY over SCTP already. A couple of bindings for SPDY over > SCTP were considered: use stream 0 for a control stream, and send the > headers over that stream. This has the nice property that it binds the > stateful compression to a single, in-order stream. Also, as you can > imagine, it introduces a small amount of HoL there. Another solution was > to use N SCTP streams, with M mux'd SPDY streams on top of it. Other such > bindings could be considered. Overall, SCTP was too immature to really > benchmark. The FreeBSD and Linux implementations of SCTP have many > problems already. The UoD guys might want to comment, I found the whole > thing non-conclusive. > > > For anyone interested, here's a link to a summary of the work > http://www.eecis.udel.edu/~leighton/SPDY.html. Under the conditions > tested, SPDY over SCTP was clearly faster than SPDY over TCP. This is true > regardless of which mapping was used. Though the data is not provided in > the summary, using SCTP stream 0 as a control stream for SPDY headers was > only very slightly faster than sending headers on the same SCTP stream as > the data. There were some issues with the linux implementation of SCTP that > had to be worked around (most since fixed), but I can't comment on any > issues with SCTP on FreeBSD as we decided against trying to port Chrome and > the flip_in_mem_edsm_server to FreeBSD. The results were inconclusive with > regard to how best to map SPDY to SCTP. Regarding the benefit of using SCTP > to avoid HOL blocking, the results are pretty straightforward - SPDY > performed better over SCTP than TCP. Increasing the delay and loss > increases SCTP's advantage. > > > My recommendation: > Designing HTTP/2.0 for SCTP is a mistake and should NOT be a requirement. > SCTP is not a viable transport over the Internet today, and will not be in > the foreseeable future. When it is available, an appropriate binding for > HTTP/2.0 can be determined, trivially, and we can worry about it then. > This is the same approach that was taken for HTTP with > http://tools.ietf.org/html/draft-natarajan-http-over-sctp-01. > > Mike > > > > >> >> Peter >> >> >> On Wed, Apr 4, 2012 at 9:07 AM, Patrick McManus <pmcmanus@mozilla.com>wrote: >> >>> On Wed, 2012-04-04 at 07:02 +0000, Poul-Henning Kamp wrote: >>> > In message <20120404054903.GA13883@1wt.eu>, Willy Tarreau writes: >>> > >>> > >> I'm starting to get data back, but not in a state that I'd reliably >>> > >> release. That said, there are very clear indicators of >>> intermediaries >>> > >> causing problems, especially when the pipeline depth exceeds 3 >>> requests. >>> > >>> > I always thought that the problem in HTTP/1.x is that you can never >>> > quite be sure if there is an un-warranted entity comming after at GET, >>> >>> its not uncommon to have the consumer RST the whole TCP session when >>> asked to recv too far beyond the current request it is processing. For >>> some devices "too far" appears to be defined as "any new packet". I >>> presume some variation of this is where Will's data point comes from. >>> (Often 3 uncompressed requests fit in 1 packet). >>> >>> That class of bug sounds absurd, but its really a pretty common pattern. >>> As an example: hosts that fail TLS False Start (for which I understand >>> second hand that Chrome needs to keep a black-list), react badly because >>> there is TCP data queued when they are in a state that the expect their >>> peer to be quiet. Same pattern. >>> >>> The lesson to me is that you want to define a tight set of functionality >>> that is reasonably testable up front - and that's what you can depend >>> widely on later. Using anything beyond that demands excessive levels of >>> pain, complexity, and cleverness. >>> >>> (and all this pipelining talk as if it were equivalent to spdy mux is >>> kind of silly. Pipelining's intrinsic HOL problems are at least as bad >>> of an issue as the interop bugs.) >>> >>> -Patrick >>> >>
- Re: multiplexing -- don't do it Adrien W. de Croy
- multiplexing -- don't do it Peter L
- Re: multiplexing -- don't do it Brian Pane
- Re: multiplexing -- don't do it J Ross Nicoll
- Re: multiplexing -- don't do it Mike Belshe
- RE: multiplexing -- don't do it Peter L
- RE: multiplexing -- don't do it Peter L
- Re: multiplexing -- don't do it Brian Pane
- Re: multiplexing -- don't do it Roberto Peon
- RE: multiplexing -- don't do it Peter L
- RE: multiplexing -- don't do it Peter L
- Re: multiplexing -- don't do it Adrien W. de Croy
- Re: multiplexing -- don't do it Alexey Melnikov
- Re: multiplexing -- don't do it Mike Belshe
- Re: multiplexing -- don't do it Julian Reschke
- Re: multiplexing -- don't do it Willy Tarreau
- Re: multiplexing -- don't do it Poul-Henning Kamp
- Re: multiplexing -- don't do it Willy Tarreau
- Re: multiplexing -- don't do it Ian Fette (イアンフェッティ)
- Re: multiplexing -- don't do it Willy Tarreau
- Re: multiplexing -- don't do it Adrien W. de Croy
- Re: multiplexing -- don't do it Mike Belshe
- Re: multiplexing -- don't do it Willy Tarreau
- Re: multiplexing -- don't do it Mark Nottingham
- Re: multiplexing -- don't do it Peter L
- Re: multiplexing -- don't do it Peter L
- Re: multiplexing -- don't do it Adam Barth
- Re: multiplexing -- don't do it Roberto Peon
- Re: multiplexing -- don't do it Willy Tarreau
- Re: multiplexing -- don't do it Peter Lepeska
- Re[2]: multiplexing -- don't do it Adrien W. de Croy
- Re: Re[2]: multiplexing -- don't do it Peter L
- Re[4]: multiplexing -- don't do it Adrien W. de Croy
- Re: Re[4]: multiplexing -- don't do it William Chan (陈智昌)
- Re: multiplexing -- don't do it Amos Jeffries
- Re: Re[2]: multiplexing -- don't do it Willy Tarreau
- Re: multiplexing -- don't do it Amos Jeffries
- Re: multiplexing -- don't do it Adrien W. de Croy
- Re: multiplexing -- don't do it Mike Belshe
- Re: multiplexing -- don't do it Poul-Henning Kamp
- Re: multiplexing -- don't do it Mark Nottingham
- Re: multiplexing -- don't do it Mike Belshe
- Re: multiplexing -- don't do it Adrien W. de Croy
- Re: multiplexing -- don't do it Mike Belshe
- Re: multiplexing -- don't do it Mike Belshe
- Re: multiplexing -- don't do it Peter Lepeska
- Re: multiplexing -- don't do it Mike Belshe
- Re: multiplexing -- don't do it Adrien W. de Croy
- breaking TLS (Was: Re: multiplexing -- don't do i… Stephen Farrell
- Re: multiplexing -- don't do it Roberto Peon
- Re: breaking TLS (Was: Re: multiplexing -- don't … Adrien W. de Croy
- Re: breaking TLS (Was: Re: multiplexing -- don't … Roberto Peon
- Re: multiplexing -- don't do it Adrien W. de Croy
- Re: multiplexing -- don't do it Roberto Peon
- Re: multiplexing -- don't do it Ray Polk
- Re: multiplexing -- don't do it Roberto Peon
- Re: multiplexing -- don't do it Mark Nottingham
- Re: breaking TLS (Was: Re: multiplexing -- don't … Stephen Farrell
- Re: multiplexing -- don't do it J Ross Nicoll
- Re: multiplexing -- don't do it Roberto Peon
- Re: multiplexing -- don't do it Adrien W. de Croy
- Re: multiplexing -- don't do it Adrien W. de Croy
- Re: breaking TLS (Was: Re: multiplexing -- don't … Adrien W. de Croy
- Re: multiplexing -- don't do it Mike Belshe
- Re: multiplexing -- don't do it William Chan (陈智昌)
- Re: breaking TLS (Was: Re: multiplexing -- don't … Mike Belshe
- Re: multiplexing -- don't do it Robert Collins
- Re: breaking TLS (Was: Re: multiplexing -- don't … Stephen Farrell
- Re[2]: multiplexing -- don't do it Adrien W. de Croy
- Re: breaking TLS (Was: Re: multiplexing -- don't … William Chan (陈智昌)
- Re: multiplexing -- don't do it William Chan (陈智昌)
- Re[3]: multiplexing -- don't do it Adrien W. de Croy
- Re: multiplexing -- don't do it patrick mcmanus
- Re: Re[3]: multiplexing -- don't do it Robert Collins
- Re: multiplexing -- don't do it William Chan (陈智昌)
- Re: breaking TLS (Was: Re: multiplexing -- don't … Stephen Farrell
- Re: multiplexing -- don't do it Amos Jeffries
- Re: multiplexing -- don't do it Stephen Farrell
- Re: multiplexing -- don't do it Amos Jeffries
- Re: breaking TLS (Was: Re: multiplexing -- don't … William Chan (陈智昌)
- Re: breaking TLS (Was: Re: multiplexing -- don't … Stephen Farrell
- Re: multiplexing -- don't do it William Chan (陈智昌)
- Re: multiplexing -- don't do it patrick mcmanus
- Re: breaking TLS (Was: Re: multiplexing -- don't … Amos Jeffries
- Re[2]: breaking TLS (Was: Re: multiplexing -- don… Adrien W. de Croy
- Re: breaking TLS (Was: Re: multiplexing -- don't … Martin Thomson
- Re[2]: multiplexing -- don't do it Adrien W. de Croy
- Re: multiplexing -- don't do it Stephen Farrell
- Re[2]: multiplexing -- don't do it Adrien W. de Croy
- Re: breaking TLS (Was: Re: multiplexing -- don't … Willy Tarreau
- Re: multiplexing -- don't do it Mike Belshe
- proxy config (was Re: multiplexing -- don't do it) Daniel Stenberg
- Re: multiplexing -- don't do it Roberto Peon
- Re: multiplexing -- don't do it J Ross Nicoll
- Re: multiplexing -- don't do it Stephen Farrell
- Re: breaking TLS (Was: Re: multiplexing -- don't … Henry Story
- Re: multiplexing -- don't do it Mike Belshe
- RE: proxy config (was Re: multiplexing -- don't d… Eric Lawrence
- Re: multiplexing -- don't do it Roy T. Fielding
- Re: multiplexing -- don't do it Poul-Henning Kamp
- Re: multiplexing -- don't do it William Chan (陈智昌)
- Re[2]: multiplexing -- don't do it Adrien W. de Croy
- Re: multiplexing -- don't do it Mike Belshe
- Re: multiplexing -- don't do it Willy Tarreau
- Re: multiplexing -- don't do it Poul-Henning Kamp
- Re: multiplexing -- don't do it Willy Tarreau
- Re: multiplexing -- don't do it Mike Belshe
- Re: multiplexing -- don't do it Willy Tarreau
- Re: multiplexing -- don't do it Patrick McManus
- Re: multiplexing -- don't do it Peter Lepeska
- Re: multiplexing -- don't do it Peter Lepeska
- Re: multiplexing -- don't do it Mike Belshe
- Re: multiplexing -- don't do it Mike Belshe
- Re: multiplexing -- don't do it Peter L
- Re: multiplexing -- don't do it Peter L
- Re: multiplexing -- don't do it William Chan (陈智昌)
- Re: multiplexing -- don't do it Roberto Peon
- Re: multiplexing -- don't do it William Chan (陈智昌)
- options or protocols? Eliot Lear
- Re: options or protocols? Adrien W. de Croy
- Re: options or protocols? Willy Tarreau
- Re: options or protocols? Adrien W. de Croy
- Re: options or protocols? Willy Tarreau
- Re: options or protocols? Adrien de Croy
- Re: options or protocols? William Chan (陈智昌)
- Re: options or protocols? Willy Tarreau
- Re: multiplexing -- don't do it Patrick McManus
- Re: multiplexing -- don't do it William Chan (陈智昌)
- Re: multiplexing -- don't do it Peter Lepeska
- Re: multiplexing -- don't do it Peter Lepeska
- Re: multiplexing -- don't do it Peter Lepeska
- Re: multiplexing -- don't do it William Chan (陈智昌)
- Re: multiplexing -- don't do it Jon Leighton
- Re: multiplexing -- don't do it Roberto Peon
- Re: multiplexing -- don't do it Peter Lepeska
- Re: breaking TLS (Was: Re: multiplexing -- don't … Nicolas Mailhot
- HTTP -> Messages -> Transport factoring Mark Nottingham
- Re: HTTP -> Messages -> Transport factoring Mike Belshe
- Re: multiplexing -- don't do it Mike Belshe
- RE: HTTP -> Messages -> Transport factoring Henrik Frystyk Nielsen
- Re: HTTP -> Messages -> Transport factoring Mark Nottingham
- Re: multiplexing -- don't do it Jon Leighton
- Re: HTTP -> Messages -> Transport factoring Poul-Henning Kamp
- Re: HTTP -> Messages -> Transport factoring Willy Tarreau
- Re: HTTP -> Messages -> Transport factoring Willy Tarreau
- Re: HTTP -> Messages -> Transport factoring Carsten Bormann
- Re: HTTP -> Messages -> Transport factoring Poul-Henning Kamp
- Re: HTTP -> Messages -> Transport factoring Carsten Bormann
- Re: options or protocols? Adrien de Croy
- Re: HTTP -> Messages -> Transport factoring Mike Belshe
- Re: HTTP -> Messages -> Transport factoring David Morris
- Re: HTTP -> Messages -> Transport factoring Mike Belshe
- Re: multiplexing -- don't do it Nicolas Mailhot
- Re: multiplexing -- don't do it William Chan (陈智昌)
- Re: breaking TLS (Was: Re: multiplexing -- don't … Nicolas Mailhot
- Re: breaking TLS (Was: Re: multiplexing -- don't … William Chan (陈智昌)
- Re: multiplexing -- don't do it Nicolas Mailhot
- Re: breaking TLS (Was: Re: multiplexing -- don't … Nicolas Mailhot
- Re: breaking TLS (Was: Re: multiplexing -- don't … Mike Belshe
- Re: multiplexing -- don't do it Mike Belshe
- Re: multiplexing -- don't do it Nicolas Mailhot
- Re: multiplexing -- don't do it William Chan (陈智昌)
- Re: breaking TLS (Was: Re: multiplexing -- don't … Stephen Farrell
- Re: multiplexing -- don't do it Stephen Farrell
- Re: multiplexing -- don't do it William Chan (陈智昌)
- Re: multiplexing -- don't do it Stephen Farrell
- Re: multiplexing -- don't do it William Chan (陈智昌)
- Re: multiplexing -- don't do it Poul-Henning Kamp
- Re: multiplexing -- don't do it Roberto Peon
- RE: multiplexing -- don't do it Henrik Frystyk Nielsen
- Re: multiplexing -- don't do it Stephen Farrell
- Re: multiplexing -- don't do it Nicolas Mailhot
- Re: multiplexing -- don't do it Willy Tarreau
- Re: breaking TLS (Was: Re: multiplexing -- don't … Willy Tarreau
- Re: breaking TLS (Was: Re: multiplexing -- don't … Roberto Peon
- Re: breaking TLS (Was: Re: multiplexing -- don't … Stephen Farrell
- Re: breaking TLS (Was: Re: multiplexing -- don't … Willy Tarreau
- Re: breaking TLS (Was: Re: multiplexing -- don't … Poul-Henning Kamp
- Re: breaking TLS (Was: Re: multiplexing -- don't … Willy Tarreau
- Re: breaking TLS (Was: Re: multiplexing -- don't … Daniel Stenberg
- Re: breaking TLS (Was: Re: multiplexing -- don't … Poul-Henning Kamp
- Re: breaking TLS (Was: Re: multiplexing -- don't … Roberto Peon
- Re: multiplexing -- don't do it tom
- Re: multiplexing -- don't do it tom
- Re: multiplexing -- don't do it patrick mcmanus
- Re: multiplexing -- don't do it tom
- Re: multiplexing -- don't do it Jamie Lokier
- Re: multiplexing -- don't do it Jamie Lokier
- Re: multiplexing -- don't do it David Morris
- Re: multiplexing -- don't do it Peter Lepeska
- Re: multiplexing -- don't do it Roberto Peon
- Re[2]: multiplexing -- don't do it Adrien W. de Croy
- Re[2]: multiplexing -- don't do it Adrien W. de Croy
- Re: Re[2]: multiplexing -- don't do it Poul-Henning Kamp
- Re[4]: multiplexing -- don't do it Adrien W. de Croy
- Re: multiplexing -- don't do it Nicolas Mailhot
- Re: multiplexing -- don't do it Jamie Lokier
- Portal authorization (was: Re: multiplexing -- do… Martin J. Dürst
- Re: multiplexing -- don't do it Nicolas Mailhot
- Re: Portal authorization (was: Re: multiplexing -… Nicolas Mailhot
- Re: Portal authorization (was: Re: multiplexing -… Nicolas Mailhot
- Re: Portal authorization Julian Reschke
- Re: Portal authorization Julian Reschke
- Re: Portal authorization Nicolas Mailhot
- Re: Portal authorization Julian Reschke
- Re: multiplexing -- don't do it Salvatore Loreto
- Re: multiplexing -- don't do it Amos Jeffries
- Re: Portal authorization Amos Jeffries