[hybi] Call for opinions on multiplexing (separate layer for multiplexing, again)

Takeshi Yoshino <tyoshino@google.com> Mon, 25 June 2012 08:46 UTC

Return-Path: <tyoshino@google.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 1E69021F84CE for <hybi@ietfa.amsl.com>; Mon, 25 Jun 2012 01:46:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.976
X-Spam-Level:
X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 Sb1k9vWrfeLn for <hybi@ietfa.amsl.com>; Mon, 25 Jun 2012 01:46:24 -0700 (PDT)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9A16521F848A for <hybi@ietf.org>; Mon, 25 Jun 2012 01:46:24 -0700 (PDT)
Received: by yenq13 with SMTP id q13so2875207yen.31 for <hybi@ietf.org>; Mon, 25 Jun 2012 01:46:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :x-system-of-record; bh=ZhtTkJrFkKWlMVTrtqO96cQCP7gvXsyoc89e4Zr89U4=; b=MlcwmWCmJ2TIqeHDsdqUvkfA1+cbxrtJb6SC2hGSb36+WEDReZ+Tp7ARkbmoixggPf aT3kPSs8sPYt0IvHzR6ydYa+qJ66ih11eoczVg3p8LruG9jMfyVIVZPFT9L7qHIwVL91 wfaLONsdSiaCXbKK4SrwNcuBvM1DTI2kiUTP37XKrYBUY0Xgff/zfrK7frqXc9H0Kzyq zbg3DnxV+GpNpKqOqZrln6PErOBCkVVO5lZfaIvC8o0cVvqgbwFASBlS9eLKJz9D/fup /3yj3KWT1ueGODEdJksYy06cIH8GHfKqJ3QPsutFsZTyQ9TbHdhnL8nKRGvofzId9bY3 npWg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :x-system-of-record:x-gm-message-state; bh=ZhtTkJrFkKWlMVTrtqO96cQCP7gvXsyoc89e4Zr89U4=; b=DbELKR+NWp/UKdKItG01aKV6JELUfKrgi8gO6Z++p/Itn7gEl4kKFm80QrijI0aOFS 10R3Kg6mLDNhyw+PHE0Ch33oPGycirxT7PM++07uQQ5sNNOn6+qY2dj5J1GIUaiyQQBI shsMcZxK+ajdyS6YNew4sVn5/ik4fe9k8ORwxRBvORp/0xQdpmYDRdBenf/74W/y4J2K 6UrE0QVGLIYDJ+K70xeENKgMmU7qyC3Yxtz3dLFnftN57SCDorBkuCKaCruBFVQdcYXa g40g3eQSSvg29cp7lk29Sd0G2PUns7pqWB1TPnr2wiWulZdspw7IHG+Bu5HE8OPWvT8B T3XQ==
Received: by 10.50.178.33 with SMTP id cv1mr4693767igc.1.1340613983957; Mon, 25 Jun 2012 01:46:23 -0700 (PDT)
Received: by 10.50.178.33 with SMTP id cv1mr4693759igc.1.1340613983869; Mon, 25 Jun 2012 01:46:23 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.231.66.7 with HTTP; Mon, 25 Jun 2012 01:46:03 -0700 (PDT)
From: Takeshi Yoshino <tyoshino@google.com>
Date: Mon, 25 Jun 2012 17:46:03 +0900
Message-ID: <CAH9hSJY5_ByHXmCgTBOhTv4uVTnAjgVu3sNxycKyNz2ZOqBgiQ@mail.gmail.com>
To: hybi@ietf.org
Content-Type: multipart/alternative; boundary="e89a8f3bad134a18d304c3480441"
X-System-Of-Record: true
X-Gm-Message-State: ALoCoQmv599hOgOmQrb/2BtcjDXnVt3dmtQgeWNFf++XwWtDn4CrZ2uDPi85MF+sk39jS0LvRHe3VHbRLayoZI71+1zAYVXm4FVBk5UQPPrT8tqnKwCL8Zu7i2u/LBe1I33UsL4jPnyYYC5MJ6dU+J4Tty4UFj8mvwYbRCycoGJq2FPRGZ5DmmE=
Subject: [hybi] Call for opinions on multiplexing (separate layer for multiplexing, again)
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: Mon, 25 Jun 2012 08:46:29 -0000

Recently some issue with integration between compression and multiplexing
was pointed out on the list.

See this thread:
http://www6.ietf.org/mail-archive/web/hybi/current/msg09679.html

In summary,

a) current per-frame compression locks down fragmentation since it flips
RSV1 for each frame and it requires frame boundary unchanged to apply
decompression algorithm correctly
b) multiplexing needs to have control over fragmentation to flush data
within given send quota and to give time slots fairly

a) and b) conflicts when compression is used before multiplexing (i.e.
applying compression for each logical channel separately)

Ad-hoc solutions would lead to dead locking, bad implementation,
interoperability issue. We need clear and simple one.

One solution is to change the compression to per-message basis (flip the
RSV1 bit only on the first fragment. SYNC_FLUSH at the end of message). But
then, the changed compression cannot be applied to the stream after
multiplexing. So, then we need two different compressions (current one and
changed one) for use before mux and after mux.

Another approach is encapsulating multiplexed frames. This idea got lots of
objection due to it's extra overhead when the base framing was discussed.
Taking into account the issue, and possible layering problems in the
future, how about revisiting multiplex layering now?

Issues with encapsulation
- extra overhead
- channel ID will be included to compression target
...

Takeshi