[hybi] Channel ID encoding of multiplexing extension

Takeshi Yoshino <tyoshino@google.com> Thu, 29 March 2012 08:00 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 E384421F8971 for <hybi@ietfa.amsl.com>; Thu, 29 Mar 2012 01:00:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.955
X-Spam-Level:
X-Spam-Status: No, score=-102.955 tagged_above=-999 required=5 tests=[AWL=0.021, 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 EYl4YuzedoK8 for <hybi@ietfa.amsl.com>; Thu, 29 Mar 2012 01:00:25 -0700 (PDT)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0C8C021F895B for <hybi@ietf.org>; Thu, 29 Mar 2012 01:00:24 -0700 (PDT)
Received: by iazz13 with SMTP id z13so3126199iaz.31 for <hybi@ietf.org>; Thu, 29 Mar 2012 01:00: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:cc:content-type :x-system-of-record; bh=YoPaFAU6oDQBV1lATilY7c8P2JCZTxhQrx6EBtpzEwM=; b=d/yURDQYSOMInxPUHBEkw2dWIJ4dHcv94JLK8Mp/B8ouNDeS7R93a8Eq+itqSUobPG Ig/RYp0YVBuNFQgRToy0HSMY05wLApo/kvPP4N2r9aDrErOrRZyhXAwGCx6LJvLmMbpL JQwCbM7Y+1PpHrUNS9mPvfPVTQujLp7I1YjEf86iThp1BQbmspYukLkQSpxy98VTfrQd ev9Xv4oeJC5TblvZUX9Ps4EfpSwMb4UvxG8pw3uoeOOj5kOLRcnFSfItC0ktwxw8DPXQ nEwsfjUifUA0YgsknzZwclVjX2pGW3cKLn0leHpQGqIr4Gr6aJ/+S5oIeX3/+cR7hS7N S10g==
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:cc:content-type :x-system-of-record:x-gm-message-state; bh=YoPaFAU6oDQBV1lATilY7c8P2JCZTxhQrx6EBtpzEwM=; b=VG4hT8M5hwYzYXpe+kHxJ5vDRlyvRxEcv+VZwXD0v7p0yeINE+8vQeRiLx6VM2oT1o d9DEJL0HvUGhLxFjOSTmNVm2FODEdsbnhJ0FdtG/nhu78UpevTAhXS64MMLYKTzsdk22 xCrL1So2/+86TIveMgtgus7b2F4IvWD8jLBI88Fp1By7B2MebAQpChto1LCfmddcf1p4 HWGqra7uFLQzZgq1p8WVSfXrun7F8N1pxic/96Bx8cJ1VBDhSLisYWg1r8VYOskzoRkk lqy8Xn0SrmITnrKNNvdIVKUTG2ykM88K2Ev6aua1VyW0CEanRTAX+3b8EbYi4a63GE8N NtBQ==
Received: by 10.50.89.200 with SMTP id bq8mr239639igb.45.1333008024678; Thu, 29 Mar 2012 01:00:24 -0700 (PDT)
Received: by 10.50.89.200 with SMTP id bq8mr239634igb.45.1333008024604; Thu, 29 Mar 2012 01:00:24 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.231.178.203 with HTTP; Thu, 29 Mar 2012 01:00:00 -0700 (PDT)
From: Takeshi Yoshino <tyoshino@google.com>
Date: Thu, 29 Mar 2012 10:00:00 +0200
Message-ID: <CAH9hSJbP1NJmrD1nhYUWhGdJ7t2jDZ=-+xGKmVpPXKkoROUOwQ@mail.gmail.com>
To: hybi@ietf.org
Content-Type: multipart/alternative; boundary="e89a8f3ba32dca0e9d04bc5d1d53"
X-System-Of-Record: true
X-Gm-Message-State: ALoCoQkLrvbByQfuGuNMYg8WhPUOCDC0cZ6pP2nhnxwaKCCDXg8CRxSXlrOWuFMLz3OG/EYRUtt8DLRs8sHjVpGW5mNGPe73r7iE2xcsF3qi+7//LxeeXExt14ll+um61p1ooaxT7CFB
Subject: [hybi] Channel ID encoding of multiplexing extension
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: Thu, 29 Mar 2012 08:00:26 -0000

In the latest mux extension draft, we're using a new 4-mode integer
encoding for channel ID field.
http://tools.ietf.org/html/draft-tamplin-hybi-google-mux-03#section-6

ID : field length
0 - : 1 octet
128 (2^7) - : 2 octet
16384 (2^14) - : 3 octet
2097152 (2^21) - 536870912 (2^29 - 1) : 4 octet

It's designed and put in the spec by John considering that distribution of
channel ID would have distribution different from payload.

In the f2f meeting yesterday, Gabriel showed concern about introduction of
a new variable length encoding as we already have 1 a bit complicated
encoding for the payload length.

Here I want to call for opinions and alternative suggestions on this
specific point. Thoughts?